Linux Netzwerk Skript Netzwerk

Linux Netzwerk Skript Grundkurs II

Netzwerk

u.a. Dirk von Suchodoletz [email protected] u ¨berarbeitet von Antonia Blanke [email protected] redigiert und zusammengestellt von Dieter Kirchner [email protected]

1. März 2007

2

Inhaltsverzeichnis 1 Einleitung 1.1 Zu diesen Unterlagen . . . . . . . . . . . . . . 1.2 Bezeichnung von Dateien und Verzeichnissen 1.3 Begriffserkl¨ arungen - Bereich Netzwerk . . . . 1.4 Begriffserkl¨ arungen - Telefonie . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 2 2 5

2 LAN Hardware 2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Ethernet-Adapter . . . . . . . . . . . . . . . . . . . 2.1.2 Koaxialkabelbasierte Netze f¨ ur 10 MBit . . . . . . 2.1.3 Twisted-Pair-basierte Verkabelungen 10/100 Mbit . 2.1.4 1000 Mbit . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Ethernet unter Linux . . . . . . . . . . . . . . . . 2.2 Funk-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 TokenRing . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Netzwerk-Interfaces von Linux . . . . . . . . . . . . . . . 2.5 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

9 9 11 11 12 12 12 14 16 18 19 19

3 WAN Hardware 3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Leistung und Kosten der einzelnen Technologien . . . 3.2.1 Leistung / Datendurchsatz . . . . . . . . . . . 3.2.2 Kosten . . . . . . . . . . . . . . . . . . . . . . . 3.3 Telefonnetze . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Das klassische Telefonnetz . . . . . . . . . . . . 3.3.2 Digitale Telefonnetze - ISDN . . . . . . . . . . 3.3.3 Mobilfunknetze nach dem GSM-Standard . . . 3.3.4 GPRS . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 HSCSD . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Mobilfunknetze der dritten Generation - UMTS 3.4 Modem . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Design¨ uberlegungen . . . . . . . . . . . . . . . ¨ 3.5.2 Ubertragungsmethoden . . . . . . . . . . . . . 3.5.3 Vorteile der neuen Technik . . . . . . . . . . . 3.5.4 Benutzung unter Linux . . . . . . . . . . . . . 3.6 ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Die ATM-Zelle . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

21 21 22 22 22 22 23 24 24 24 25 25 26 26 26 27 28 29 29 30

3

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

4

INHALTSVERZEICHNIS 3.7 3.8 3.9

FDDI . . . . . . . . . . . . . . . . . . . . Mobilfunknetze . . . . . . . . . . . . . . . 3.8.1 GSM, HSCSD, GPRS und UMTS Netzwerkadapter f¨ ur Mobilfunknetze . . .

4 OSI-Schichtenmodell 4.1 Kategorisierungen . . . . . . . 4.2 Protokollhierarchien . . . . . . 4.2.1 Hierarchie . . . . . . . . 4.3 Motivation . . . . . . . . . . . 4.4 Die einzelnen Schichten . . . . 4.4.1 Bit¨ ubertragungsschicht 4.4.2 Sicherungsschicht . . . . 4.4.3 Vermittlungsschicht . . 4.4.4 Transportschicht . . . . 4.4.5 Sitzungsschicht . . . . . 4.4.6 Darstellungsschicht . . . 4.4.7 Verarbeitungsschicht . . 4.5 Konzepte . . . . . . . . . . . . 4.5.1 Protokolle . . . . . . . . 4.6 Einordnungen . . . . . . . . . . 4.7 Aufgaben . . . . . . . . . . . . 4.7.1 OSI . . . . . . . . . . . 4.7.2 Netzwerke . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

5 TCP-IP 5.1 Schaffung von ”Inter-Nets” . . . . . ¨ 5.2 Uberblick u ¨ ber TCP/IP . . . . . . . 5.3 Design . . . . . . . . . . . . . . . . . 5.4 Internet Protocol (IP) . . . . . . . . 5.5 Spezifikation . . . . . . . . . . . . . 5.5.1 IPv4-Standard . . . . . . . . 5.5.2 Notation . . . . . . . . . . . . 5.5.3 Adressbereiche . . . . . . . . 5.5.4 Spezielle IP-Adressen . . . . 5.5.5 Private IP-Adressen . . . . . 5.6 Der IP-Header . . . . . . . . . . . . 5.6.1 Fragmentierung . . . . . . . . 5.7 IP-Routing . . . . . . . . . . . . . . 5.7.1 Prinzip der IP-Netze . . . . . 5.7.2 Routing (Die Wege im Netz) 5.7.3 Einfaches Hostrouting . . . . 5.7.4 Routingentscheidung . . . . . 5.7.5 Subnetting und Supernetting 5.7.6 QoS-Routing . . . . . . . . . 5.8 Address Resolution Protocol . . . . . 5.8.1 ARP - Hilfsprotokoll des IP . 5.8.2 Funktionsweise . . . . . . . . 5.8.3 ARP unter Linux . . . . . . . 5.8.4 Eingebaute Sicherheitsl¨ ucken

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

31 32 32 32

. . . . . . . . . . . . . . . . . .

35 35 35 35 36 38 38 38 38 39 39 39 39 39 40 40 41 41 42

. . . . . . . . . . . . . . . . . . . . . . . .

43 43 44 46 46 48 48 48 49 50 51 52 53 53 54 55 56 56 58 60 61 61 62 64 66

INHALTSVERZEICHNIS

5.9 5.10 5.11 5.12 5.13 5.14

5.8.5 Gefahrenabwehr . . . . . . . . . . . 5.8.6 ARP und doppelte IP-Adressen . . . 5.8.7 Proxy-ARP . . . . . . . . . . . . . . 5.8.8 Probleme durch Proxy-ARP . . . . . ICMP - Internet Control Message Protocol Domain-Name-Service (DNS) . . . . . . . . Transmission Control Protocol (TCP) . . . User Datagram Protocol (UDP) . . . . . . . Ports . . . . . . . . . . . . . . . . . . . . . . Aufgaben . . . . . . . . . . . . . . . . . . . 5.14.1 Internets . . . . . . . . . . . . . . . 5.14.2 Internet Protokoll / Header . . . . . 5.14.3 IP-Netze . . . . . . . . . . . . . . . . 5.14.4 Fragmentierung . . . . . . . . . . . . 5.14.5 IP-Routing . . . . . . . . . . . . . . 5.14.6 ARP . . . . . . . . . . . . . . . . . .

6 Linux im Netzwerk 6.1 IP-Konfiguration unter Linux . . . . . . . . 6.1.1 Die traditionellen Tools . . . . . . . 6.1.2 Routing . . . . . . . . . . . . . . . . 6.1.3 Next Generation IP-Config . . . . . 6.1.4 Das Kommando ip . . . . . . . . . . 6.1.5 Erste Schritte mit ip . . . . . . . . . 6.2 Weitergehende Anwendungen von IProute2 6.2.1 Weitere Tools . . . . . . . . . . . . . 6.2.2 Routing Policy Database . . . . . . 6.2.3 Generelle 2-Wege-Routen . . . . . . 6.2.4 Dienste-basiertes Routing . . . . . . ¨ 6.3 Uberpr¨ ufung der Konfiguration . . . . . . . 6.4 Aufgaben . . . . . . . . . . . . . . . . . . . 6.4.1 IP-Konfiguration und Erreichbarkeit 6.4.2 Datenverkehr z¨ ahlen . . . . . . . . . 7 Wichtige Netzwerkkommandos 7.1 Offene Dateien und Netzwerkverbindungen 7.2 netstat . . . . . . . . . . . . . . . . . . . . . 7.3 Systemprogramme . . . . . . . . . . . . . . 7.3.1 D¨ amonen . . . . . . . . . . . . . . . 7.4 Netzwerkkonfiguration . . . . . . . . . . . . 7.4.1 Netzwerktests . . . . . . . . . . . . . 7.4.2 Netzwerk¨ uberwachung . . . . . . . .

5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Domain Name Service 8.1 Einstieg . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Enstehungsgeschichte . . . . . . . . . . . 8.1.2 DNS - Das virtuelle IP-Telefonbuch . . . 8.1.3 Regeln f¨ ur die Namensgebung . . . . . . . 8.1.4 Registrieren und Verwalten von Domains 8.2 Implementation . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

68 69 70 71 72 73 75 77 78 78 78 78 79 79 80 80

. . . . . . . . . . . . . . .

81 81 81 82 83 83 85 86 87 88 89 91 91 91 91 92

. . . . . . .

93 93 93 94 94 95 95 97

. . . . . .

99 99 99 101 101 102 103

6

INHALTSVERZEICHNIS

8.3

8.4 8.5

8.6

8.2.1 Nameserver und Zust¨ andigkeiten . . . . 8.2.2 Caching . . . . . . . . . . . . . . . . . . 8.2.3 Prim¨ arer und sekund¨ are Nameserver . . DNS-Server mit Linux . . . . . . . . . . . . . . 8.3.1 Der D¨ amon . . . . . . . . . . . . . . . . 8.3.2 Die DNS-Datenbank . . . . . . . . . . . 8.3.3 Starten und Anhalten des Nameservers 8.3.4 Slave-Server . . . . . . . . . . . . . . . . 8.3.5 Delegation einer Subdomain . . . . . . . Dynamische Updates der Zonendateien . . . . . 8.4.1 Sicherheit . . . . . . . . . . . . . . . . . DNS bekommt neue Aufgaben . . . . . . . . . 8.5.1 ENUM . . . . . . . . . . . . . . . . . . . 8.5.2 IPv6 . . . . . . . . . . . . . . . . . . . . 8.5.3 DNS als Bannerfilter . . . . . . . . . . . Aufgaben . . . . . . . . . . . . . . . . . . . . . 8.6.1 Rechnernamen im Internet . . . . . . . 8.6.2 Domain Name Service (DNS) . . . . . . 8.6.3 DNS Server . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

103 105 105 105 106 107 109 109 110 111 111 113 113 114 114 115 115 116 116

9 Ressourcenverwaltung 9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . 9.2 NIS . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Zielsetzung . . . . . . . . . . . . . . . . . 9.2.2 NIS-Datenbanken . . . . . . . . . . . . . . 9.2.3 NIS-Server . . . . . . . . . . . . . . . . . 9.2.4 NIS-Client . . . . . . . . . . . . . . . . . . 9.3 Hierarchischer Verzeichniszugriff: LDAP . . . . . 9.3.1 Intro . . . . . . . . . . . . . . . . . . . . . 9.3.2 Was kann mit LDAP abgebildet werden . 9.3.3 Das Datenmodell . . . . . . . . . . . . . . 9.3.4 Das Protokoll . . . . . . . . . . . . . . . . 9.4 LDAP praktisch . . . . . . . . . . . . . . . . . . 9.4.1 Server- und Clientprogramme unter Linux 9.4.2 Eine einfache Beispielkonfiguration . . . . 9.4.3 Absicherung durch SSL . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

117 117 117 117 118 118 118 118 118 119 120 123 123 123 124 127

10 Mail 10.1 SMTP . . . . . . . . . 10.1.1 E-Mail-Adresse 10.1.2 Versenden einer 10.1.3 Mail-Body . . . 10.1.4 E-Mail Header 10.1.5 Open-Relay . . 10.1.6 Sicherheit . . . 10.2 sendmail . . . . . . . . 10.3 exim . . . . . . . . . . 10.4 POP . . . . . . . . . . 10.5 IMAP . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

133 134 135 135 136 137 138 138 140 140 141 143

. . . . . . . . . . E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

INHALTSVERZEICHNIS

7

10.6 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.6.1 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 11 DHCP 11.1 Automatische IP-Zuweisung . . . . . . . . . . 11.2 Implementation . . . . . . . . . . . . . . . . . 11.3 DHCP-Server . . . . . . . . . . . . . . . . . . 11.3.1 DHCP-Standardoptionen . . . . . . . 11.3.2 DHCP-DNS-Verbindung . . . . . . . . 11.4 Benutzerdefinierte Optionen . . . . . . . . . . 11.5 Die Verwendung von Vendor-Code-Identifiern 11.6 DHCP-Client . . . . . . . . . . . . . . . . . . 11.7 DHCP mit LDAP-Backend . . . . . . . . . . 11.8 Aufgaben . . . . . . . . . . . . . . . . . . . . 11.8.1 DHCP . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

145 145 145 148 149 150 151 152 153 156 158 158

12 Fileserver 12.1 Unix-Netzwerkdateisystem - NFS . . . . . . . 12.1.1 NFS-Server . . . . . . . . . . . . . . . 12.1.2 NFS-Clients . . . . . . . . . . . . . . . 12.1.3 NFS und Portmapper . . . . . . . . . 12.1.4 NFS und (Un)Sicherheit . . . . . . . . 12.2 Andrew Filesystem (AFS) . . . . . . . . . . . 12.2.1 Die Clientseite . . . . . . . . . . . . . 12.3 File Transfer Protocol . . . . . . . . . . . . . 12.3.1 Dateiarchiv - FTP-Server . . . . . . . 12.3.2 FTP-Clients . . . . . . . . . . . . . . . 12.4 Das Minimal-FTP (TFTP) . . . . . . . . . . 12.5 Weitere Fileserver-Konzepte . . . . . . . . . . 12.6 Network Block Devices . . . . . . . . . . . . . 12.7 NBDs im Einsatz . . . . . . . . . . . . . . . . 12.7.1 Erste Versuche mit NBD . . . . . . . 12.7.2 NBD und Filesysteme . . . . . . . . . 12.7.3 DNBD - eine spezialisierte Alternative 12.8 Spezielle Blockdevice-Erweiterungen . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

159 159 160 161 161 163 163 163 167 167 167 168 170 171 172 172 173 174 176

. . . . . . . . .

179 179 180 180 181 183 183 184 185 186

13 Firewall 13.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . 13.2 Ein- und Austragen von chains und Filter-Regeln 13.2.1 Pakete genauer spezifizieren . . . . . . . . 13.2.2 ”Match Extensions” und Erweiterbarkeit 13.3 von ”masquerading” und ”packet mangling” . . . 13.3.1 Network Address Translation . . . . . . . 13.3.2 packet mangling . . . . . . . . . . . . . . 13.4 connection tracking . . . . . . . . . . . . . . . . . 13.5 Referenzen . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

8 14 Webserver ¨ 14.1 Uberblick . . . . . . . . . . . . . . . . . . . . 14.2 HTTP-Kommunikation . . . . . . . . . . . . 14.3 Was ist ein Webserver? . . . . . . . . . . . . . 14.4 Apache 2 . . . . . . . . . . . . . . . . . . . . 14.4.1 Erweiterbare Funktionalität . . . . . . 14.5 Konfiguration . . . . . . . . . . . . . . . . . . 14.5.1 Optionen . . . . . . . . . . . . . . . . 14.5.2 Laden von Modulen . . . . . . . . . . 14.6 Webserver Erweiterungen . . . . . . . . . . . 14.6.1 Die Benutzer-Homepage - mod userdir 14.6.2 URL-Umschreiber mod rewrite . . . . 14.6.3 Zugriffskontrollen . . . . . . . . . . . . 14.6.4 Kompression . . . . . . . . . . . . . . 14.6.5 Das Web-DAV Modul . . . . . . . . . 14.6.6 Virtuelle Webserver . . . . . . . . . . 14.7 SSL (Secure Socket Layer) . . . . . . . . . . . 14.7.1 Funktionsweise . . . . . . . . . . . . . 14.7.2 Zertifikate . . . . . . . . . . . . . . . . 14.7.3 Zertifikate erzeugen . . . . . . . . . . 14.7.4 Integration . . . . . . . . . . . . . . . 14.8 CGI (-Modul) . . . . . . . . . . . . . . . . . . 14.9 PHP . . . . . . . . . . . . . . . . . . . . . . . 14.9.1 Das Apache-PHP-Modul . . . . . . . . 14.10SSI (Server Side Includes) . . . . . . . . . . . 14.11Dokumentation . . . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

15 Netzwerku ¨ berwachung ¨ 15.1 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2 SNMP - Das Simple Network Mangement Protocol . . . . . . . . . . . . . ¨ 15.2.1 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Die Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.1 Der SNMP-Namensraum und die Management Information Bases . 15.3.2 Die SNMP-Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.3 Der Kommunikations-Code der Agenten . . . . . . . . . . . . . . . 15.4 SNMP-Implementierungen unter Linux . . . . . . . . . . . . . . . . . . . . 15.5 Kommandos zur Datenbeschaffung . . . . . . . . . . . . . . . . . . . . . . 15.6 Konfiguration des UCD-SNMP . . . . . . . . . . . . . . . . . . . . . . . . 15.6.1 Der Kopf definiert die Zugriffs-Policies . . . . . . . . . . . . . . . . 15.6.2 Parameter der ”Enterprise”-Erweiterungen . . . . . . . . . . . . . 15.6.3 Erweiterung durch externe Skripten und Programme . . . . . . . . ¨ 15.7 Uberwachung weiterer Parameter . . . . . . . . . . . . . . . . . . . . . . . 15.7.1 Weitergehende Erg¨ anzungen . . . . . . . . . . . . . . . . . . . . . . 15.7.2 Parameter der Host-Ressource-Erweiterungen . . . . . . . . . . . . 15.8 MRTG als Frontend zur Anzeige von Zeitreihen . . . . . . . . . . . . . . . 15.9 Einige abschließende Worte zu SNMP . . . . . . . . . . . . . . . . . . . . 15.10Weiterf¨ uhrende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

187 187 188 189 189 189 190 190 191 192 192 193 193 195 195 196 197 198 198 198 199 199 200 201 202 202

. . . . . . . . . . . . . . . . . . .

205 205 205 205 206 207 208 208 209 209 210 210 211 211 212 213 214 215 216 216

INHALTSVERZEICHNIS 16 Netzwerkanalyse ¨ 16.1 Uberblick . . . . . . . . . . . . . . . . . . . . . 16.1.1 Aufgabenfelder . . . . . . . . . . . . . . 16.1.2 Namensaufl¨ osung - ja oder nein . . . . . 16.2 Erreichbarkeit von Diensten und Maschinen . . 16.2.1 Ping und Erweiterungen . . . . . . . . . 16.2.2 M¨ ogliche weitere Probleme . . . . . . . 16.3 NMAP - offene Maschinen und Netze . . . . . . 16.3.1 Scan-Methoden . . . . . . . . . . . . . . 16.3.2 Aufruf und Benutzung . . . . . . . . . . 16.3.3 OS-Fingerprinting . . . . . . . . . . . . 16.4 Die eigenen Dienste und Verbindungen kennen 16.5 Schn¨ uffeln im Datenverkehr . . . . . . . . . . . 16.5.1 Analysen auf der Kommandozeile . . . . 16.5.2 Das Ganze in Bunt . . . . . . . . . . . . 16.6 Sammeln im Hintergrund - trafmond . . . . . . 16.7 Wegeanalysen in IP-Netzwerken . . . . . . . . . 16.7.1 Routenverfolgung . . . . . . . . . . . . . 16.8 Statistiken . . . . . . . . . . . . . . . . . . . . . 16.8.1 iptraf . . . . . . . . . . . . . . . . . . . 16.8.2 TrafShow und NetWatch . . . . . . . . . 16.8.3 Analysen webbasiert - ntop . . . . . . . 16.8.4 Top f¨ urs Netzwerk . . . . . . . . . . . . 16.8.5 MRTG . . . . . . . . . . . . . . . . . . . 16.8.6 Bandbreiten messen . . . . . . . . . . . 16.9 Aufgaben . . . . . . . . . . . . . . . . . . . . . 16.9.1 Erreichbarkeit . . . . . . . . . . . . . . . 16.9.2 Paketanalyse . . . . . . . . . . . . . . . 16.9.3 Datenverkehr z¨ ahlen . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

219 219 219 220 220 220 222 223 224 225 226 227 229 229 231 233 234 234 236 236 238 238 239 240 242 243 243 243 243

17 Samba 17.1 Samba - Br¨ ucke zwischen Microsoft- und Unix-Welt 17.1.1 Einsatzgebiete von Samba . . . . . . . . . . . 17.2 Erste Versuche . . . . . . . . . . . . . . . . . . . . . 17.2.1 Windows-Server - Linux-Client . . . . . . . . 17.2.2 Linux-Server - Windows-Client . . . . . . . . 17.3 Weitergehende Konfiguration . . . . . . . . . . . . . 17.3.1 Homeverzeichnisse f¨ ur Windows und Linux . 17.3.2 Druckerfreigaben . . . . . . . . . . . . . . . . 17.3.3 Nachrichtendienst auf Linux-Clients . . . . . 17.4 Die zentrale Samba-Konfigurationsdatei . . . . . . . 17.4.1 Struktur . . . . . . . . . . . . . . . . . . . . . 17.4.2 Wichtige Optionen in der Sektion [global] . . 17.4.3 Wichtige Optionen der anderen Abschnitte . 17.4.4 Virtuelle Samba-Server . . . . . . . . . . . . 17.5 Controller-Funktionalit¨ at . . . . . . . . . . . . . . . 17.5.1 Der Windows Namensdienst . . . . . . . . . . 17.5.2 NetBIOS Namen . . . . . . . . . . . . . . . . 17.5.3 Der Nameserver (WINS) . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

245 245 245 246 246 248 249 251 252 252 252 253 253 254 255 255 255 256 258

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

INHALTSVERZEICHNIS 17.6 Samba als PDC . . . . . . . . . . . . . . . . 17.6.1 Benutzerprofile und Logon-Skripten 17.7 Samba und LDAP . . . . . . . . . . . . . . 17.7.1 Konfiguration des LDAP-Servers . . 17.7.2 Die neue Samba-Konfiguration . . . 17.7.3 Die IDEALX-Skripten . . . . . . . . 17.7.4 Fazit von Samba-LDAP-Aktionen .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

259 260 262 262 262 264 270

18 Sicheres IP 18.1 Sicherheitsprobleme des derzeitigen IP-Standards 18.1.1 Intro . . . . . . . . . . . . . . . . . . . . . 18.1.2 Offener Datentransport . . . . . . . . . . 18.1.3 Absicherung - L¨ osungsansätze . . . . . . . 18.2 VPNs - Sichere Netze u ¨ber das Internet . . . . . 18.3 CIPE . . . . . . . . . . . . . . . . . . . . . . . . 18.3.1 Idee . . . . . . . . . . . . . . . . . . . . . 18.3.2 Aufsetzen von CIPE . . . . . . . . . . . . 18.4 IPsec-Theorie . . . . . . . . . . . . . . . . . . . . 18.5 IPsec praktisch - FreeSWAN . . . . . . . . . . . . 18.5.1 Konfigurationsm¨ oglichkeiten von IPsec . . 18.5.2 Einrichtung von IPsec unter Linux . . . . 18.5.3 Einschaltbare Optionen . . . . . . . . . . 18.5.4 Konfiguration von IPsec-Verbindungen . . 18.6 Kommerzielle VPN-L¨ osungen . . . . . . . . . . . 18.6.1 Cisco-VPN . . . . . . . . . . . . . . . . . 18.6.2 Verwendung der Cisco-Tools . . . . . . . . 18.6.3 Einsatzszenarien . . . . . . . . . . . . . . 18.6.4 Fazit . . . . . . . . . . . . . . . . . . . . . 18.7 Literatur . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

271 271 271 271 273 275 275 275 277 278 280 281 282 283 284 285 285 288 290 291 291

19 Drahtlose Netzwerke 19.1 Funk-Netze . . . . . . . . . . . ¨ 19.2 Uberblick WLAN-Standards . . 19.2.1 Betriebsmodi . . . . . . 19.3 Physikalische Grundlagen . . . 19.3.1 Verbesserte Anpassung . 19.3.2 Modulationsverfahren . 19.3.3 Kollisionsvermeidung . . 19.4 WLAN-Sicherheit . . . . . . . . 19.5 WLAN unter Linux . . . . . . . 19.6 Bluetooth mit Linux . . . . . . 19.6.1 Bluetooth testen . . . . 19.6.2 Kontakt aufnehmen . . 19.7 Aufgaben . . . . . . . . . . . . 19.7.1 WLAN-Technik . . . . . 19.7.2 WLAN Kommandos . . 19.7.3 WLAN Hardware . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

293 293 293 293 295 296 296 298 300 300 300 301 302 303 303 304 304

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

INHALTSVERZEICHNIS

11

20 Programmentwicklung 20.1 Intro . . . . . . . . . . . . . . . . . . . . . . . . 20.2 CVS zur Projektverwaltung . . . . . . . . . . . 20.2.1 Die Idee und das Konzept . . . . . . . . 20.2.2 CVS Begriffswelt und Kommandos . . . 20.2.3 Einige Vorbereitungen . . . . . . . . . . 20.2.4 Anlegen eines neuen Projektes . . . . . 20.2.5 Eine Arbeitskopie erstellen . . . . . . . 20.2.6 Laufende Ver¨ anderungen . . . . . . . . . 20.2.7 L¨ oschen von Dateien und Verzeichnissen 20.2.8 Markieren von Zwischenständen . . . . 20.3 Betrieb eines CVS-Servers . . . . . . . . . . . . 20.3.1 Installation . . . . . . . . . . . . . . . . 20.3.2 Archive anlegen . . . . . . . . . . . . . . 20.3.3 Netzwerkverbindungen . . . . . . . . . . 20.3.4 Authentifizierung . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

305 305 305 305 308 310 310 311 313 315 316 317 317 317 317 318

21 Virtualisierung mit VMware ¨ 21.1 Uberblick . . . . . . . . . . . . . . . . . . . . . 21.2 Virtuelle Hardware . . . . . . . . . . . . . . . . 21.2.1 Peripherie-Schnittstellen . . . . . . . . . 21.2.2 Festplatten, CD/DVD und Floppies . . 21.2.3 Grafik-Controller . . . . . . . . . . . . . 21.2.4 Virtuelle Netzwerkkarten . . . . . . . . 21.3 VMware als Linux-Applikation . . . . . . . . . 21.3.1 Installation und Einrichtung . . . . . . . 21.4 Gäste in VMware . . . . . . . . . . . . . . . . . 21.4.1 Netzwerkanbindung . . . . . . . . . . . 21.5 Die Konfigurationsdateien . . . . . . . . . . . . 21.5.1 GUI Konfiguration . . . . . . . . . . . . 21.5.2 Die (Hardware-)Konfigurationsdateien . 21.5.3 Laufwerkskonfiguration . . . . . . . . . 21.6 VMware-Tools . . . . . . . . . . . . . . . . . . 21.6.1 Unter Windows . . . . . . . . . . . . . . 21.6.2 Unter Linux . . . . . . . . . . . . . . . . 21.7 Spezielle Probleme . . . . . . . . . . . . . . . . 21.7.1 Mausbefreiung und Vollbildmodus . . . 21.7.2 Zugriff auf USB . . . . . . . . . . . . . . 21.7.3 Datenaustausch zwischen Host und Gast

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

319 319 320 321 321 323 323 323 323 325 327 327 328 329 332 333 334 334 336 336 337 337

22 Drucken im Netzwerk 22.1 Einleitung . . . . . . . . . . . . . 22.1.1 Anforderungen . . . . . . 22.1.2 Grundlagen . . . . . . . . 22.2 CUPS . . . . . . . . . . . . . . . 22.2.1 Client-Server-Architektur 22.2.2 IPP . . . . . . . . . . . . 22.2.3 Funktionsweise . . . . . . 22.2.4 Filter . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

339 339 339 340 340 341 341 342 342

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

12

INHALTSVERZEICHNIS 22.2.5 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 22.3 Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

23 IPv6 23.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1.1 Die Vorgeschichte . . . . . . . . . . . . . . . . . . . . . . . . 23.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2.1 Das neue Headerformat . . . . . . . . . . . . . . . . . . . . 23.2.2 Destination Options Header . . . . . . . . . . . . . . . . . . 23.2.3 Encapsulating Security Payload und Authentication Header 23.3 IPv6 Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.3.1 Verschiedene Arten von Unicast Adressen . . . . . . . . . . 23.4 IPv6 unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.4.1 Adresszuweisung . . . . . . . . . . . . . . . . . . . . . . . . 23.4.2 Verbindungen testen . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

345 345 346 346 347 352 353 353 354 356 356 356

Kapitel 1

Einleitung 1.1

Zu diesen Unterlagen

Der Kurs ”Linux und Netzwerke” soll in die Begriffswelt vernetzter Rechner einf¨ uhren. 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¨ uhrungen zu derzeitig verf¨ ugbarer Netzwerkhardware, wie Ethernet oder Funk-Lan und verf¨ ugbaren Netzwerkanschl¨ ussen, wie Modem, ISDN, ATM und ADSL. Alle Erl¨ auterungen 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¨ uhrung in IP-Netzwerke” zusammengestellt. Sie sind inzwischen ein gemeinsames Projekt des Rechenzentrums der Universität Freiburg und der mathematischen Fakult¨ at G¨ ottingen. Die Unterlagen werden permanent aktualisiert, jedoch können einige Teile durchaus ¨ alteren 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¨ ur andere Projekte Verwendung finden. Ich m¨ ochte dann nur auf den Haftungsausschluss hinweisen und bitten, die Quellen zu u ufen und gegebenenfalls zu kennzeichnen. Deshalb möchte ¨ berpr¨ ich die GPL auf diese Unterlagen angewandt sehen. Das Skript erhebt keinen Anspruch auf Vollständigkeit oder Originalität. Vieles findet man im Internet oder in Lehrb¨ uchern ebenso gut oder besser. Dort nachzuschlagen und zu vergleichen, sei den Lesern nachdr¨ ucklich ans Herz gelegt. Dennoch wird immer wieder ein ”eigener” Weg der Darstellung begangen, wobei manches u ¨ ber den normalen Umfang einer Einf¨ uhrung hinausgehen kann. Daf¨ ur kommen manche traditionell breits abgehandelten Gebiete hier recht kurz weg. Manches fehlt auch ganz, weil man es woanders leicht finden kann. Dieses Skript will und kann kein Lehrbuch ersetzen (das brauchen Sie außerdem), sondern ergänzen. Das “Self-Linux”-Projekt2 bietet eine vern¨ unftige Ergänzung zu den vorliegenden Unterlagen. Einiges wird anders als gewohnt pr¨ asentiert. Es werden Beispiele und auch zusätzliche Informationen angeboten, die nicht unbedingt zum Pr¨ ufungsstoff gehören, aber gut zu wis1 2

beispielsweise per Mail an [email protected] www.selflinux.org

1

2

KAPITEL 1. EINLEITUNG

sen sind (oder die man hier bequemer findet). Daf¨ ur entfallen viele Aspekte, die in den Standard-Lehrb¨ uchern gut dargestellt oder weitgehend bekannt sind. Die weiterf¨ uhrende 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¨ onnen Fehler enthalten sein, die ich dann zu entschuldigen bitte ...

1.2

Bezeichnung von Dateien und Verzeichnissen

Zur Erhöhung der Lesbarkeit werden alle auf¨ uhrbaren 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¨ oren, werden viele Erläuterungen als Fussnoten angef¨ ugt. Auch alle Links zu den entsprechenden Webseiten sind hier zu finden.

1.3

Begriffserkl¨ arungen - Bereich Netzwerk

Im folgenden werden einige Begriffe und Abk¨ urzungen erläutert, die im Bereich Linux im Netzwerk und Internet h¨ aufig vorkommen. Bandbreite wird in mehreren Bedeutungen benutzt: Zum einen ist die Bandbreite ein Maß f¨ ur die Breite eines Frequenzbands. Die Differenz zwischen einer oberen und einer unteren Grenzfrequenz, die nie u ¨ber- oder unterschritten wird. So hat beispielsweise ein analoges Telefonsignal, das in einem Frequenzbandbereich von 300 Hz bis 3400 Hz u ¨ bertragen wird, eine Bandbreite von 3100 Hz. Andererseits ist die Bandbreite ein Maß f¨ ur die Anzahl Bits pro Sekunde, die gleichzeitig u ¨ 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¨ ur bestimmte Broadcast-Netze, wie Ethernet oder TokenRing. Dabei gibt es zwei wichtige Ausprägungen: CD steht f¨ ur Collision Detection, das Erkennen und CA f¨ ur Collision Avoidance - das Vermeiden von Paketzusammenst¨ oßen. Ersteres ist charakteristisch f¨ ur Ethernet, das Zweite f¨ ur TokenRing oder FDDI. Datenu ubertragungsrate R lässt sich gemäss dem ¨ bertragungsrate Die maximale Daten¨ Nyquist-Theorem folgendermassen berechnen: Wenn das Signal aus V diskreten Stufen besteht: R = 2Hlog2V Bit/s. Nach Shannon beträgt die maximale Daten¨ ubertragungsrate 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 u ¨blicherweise die Maßeinheit Dezibel (dB) zum Einsatz. Das Dezibel ist ein logarithmisches Maß. Es vereinfacht die Berechnung der D¨ ampfung oder Verstärkung. Damit m¨ ussen f¨ ur 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. BEGRIFFSERKLARUNGEN - BEREICH NETZWERK

3

des Senders/Empf¨ angers zur Leistung eines eventuell verwendeten Verstärkers und der Antennenleistung. Von diesem Wert zieht man den Leistungsverlust durch Kabel, Stecker und eventuellem Blitzschutz ab. Eine Veränderung um 3 dB entspricht immer einer Leistungsverdoppelung oder Halbierung. Die Einheit Dezibel Milliwatt (dBm) beschreibt den Leistungspegel bezogen auf ein Milliwatt. Die Einheit ist eine absolute Angabe. 20 dBm entsprechen einer Leistung von 100 mW, 0 dBm entsprechen 1 mW. Der Antennengewinn in dBi beschreibt die Leistungsverbesserung gegen¨ uber einem isotrophen Kugelstrahler. Sobald die Leistung nicht mehr in alle Richtungen gleichmäßig, sondern bezogen auf ein bestimmtes Raumsegment abgegeben wird, erh¨ alt 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¨ uhren 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¨ ur 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¨ usste, um die gleiche Wirkung zu erzielen wie die Richtantenne in ihrer Hauptsenderichtung. FTP Das File Transfer Protocal ist eine der ältesten Möglichkeiten u ¨ ber TCP/IP Dateien zwischen Rechnern zu kopieren. Es verwendet das verbindungsorientierte TCP und auf Port 23. LAN Local Area Network. Meint Netzwerke einer geringen bis mittleren Ausbreitung, die sich u ¨ 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¨ uck 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 u ¨ ber ein TCP/IP-Netzwerk zur Verf¨ ugung stellen kann.

4


Nyquist-Theorem besagt, dass ein Signal mit der Bandbreite H durch 2H Abtastwerte pro Sekunde vollst¨ andig rekonstruiert werden kann. Anders ausgedr¨ uckt 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¨ ubertragungen und veranschaulicht die ebenenorientierte Denkweise in der Informatik. Port Neben der IP-Adresse verf¨ ugt ein Rechner u ¨ber jeweils 65.535 TCP bzw. UDPPorts. Damit wird es m¨ oglich 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¨ ugung. Benutzer können sich an einem Server anmelden, werden aber nur in den seltensten F¨ allen physisch vor dem Gerät sitzen. Signal-Rausch-Abstand (englisch: Signal Noise Ratio (SNR) beschreibt das Verhältnis der Signalstärke S zur Rauschst¨ arke N , also die Intensität des thermischen Rauschens in ¨ einem Ubertragungskanal: S/N , und wird in Dezibel (dB) gemessen. Es ist ein Maß f¨ ur die Reinheit eines Signals. SSH Secure Shell Verbindung. Diese ist dem Telnet auf jeden Fall vorzuziehen, da sie verschl¨ usselt erfolgt. Das Programm auf der Serverseite heisst u ¨ blicherweise sshd, die Clientapplikation ssh. Telnet Eines der ersten Protokolle der TCP/IP-Suite, um sich an entfernten Rechnern anmelden zu k¨ onnen. 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 u ¨ blicherweise (in.)telnetd und wird meistens u ¨ber den Internet-SuperDaemon (x)inetd gestartet. Die Clientapplikation heisst einfach telnet. Heutzutage aus Sicherheitsgr¨ unden 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, z.B. ein Browser an einen Web-Server. WAN Wide Area Network. Meint Netzwerke mit großer räumlicher Ausdehnung, die sich u ¨ blicherweise der ISDN oder ATM Technologie bedienen. (Lichtwellenleiter, Kupferkabel)

¨ 1.4. BEGRIFFSERKLARUNGEN - TELEFONIE

5

XDMCP Das X display message control protocol steuert die Grafikschnittstelle auf UnixSystemen. Diese Schnittstelle ist netzwerktransparent. Dabei erfolgt die Ausgabe des Grafikoberfläche des Servers lokal auf der Maschine. Die Benutzereingaben durch Tastatur und Maus werden u ¨ber XDMCP an den Server weitergereicht.

1.4

Begriffserkl¨ arungen - Telefonie

Im folgenden werden einige Begriffe und Abk¨ urzungen 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 Tele¨ fonanrufes erfolgt ist. Ublicherweise erh¨ alt 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¨ ur 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¨ ubertragung auf 14,4 kBit/s erh¨ oht, in der GSM-Phase-2+ ist die B¨ undelung mehrerer Kanäle möglich. DTAP Der Direct Transfer Application Part ist das Call Control Protocol zwischen MS und MSC. FCI Der Forward Call Indicator ist ein ISUP Parameterfeld.

6


GPRS Der General Packet Radio Service benötigt keine eigene Infrastruktur, sondern ist lediglich eine Erweiterung der bestehenden GSM-Netze. GPRS-Mobiltelefone stellen f¨ ur den schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt (APN = Acces Point Name) ins Netz her. F¨ ur die Datenkommunikation wird es Endgeräten erlaubt mehrere GSM-Kan¨ ale zusammenzufassen und f¨ ur 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¨ ur jeden einzelnen die erreichbare Datenrate. In der Einf¨ uhrungsphase von GPRS wurde netzseitig eine Bandbreite von 53,6 kbit/s (4 Kan¨ ale ` a 13,4 kbit/s) pro Funkzelle vorgesehen. Stehen alle acht Kanäle f¨ ur GPRS zur Verf¨ ugung, w¨ urde die Bandbreite auf 107,2 kbit/s steigen. Weitere Steigerungen durch bessere Fehlerprotokolle 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¨ at zwei bis drei Kan¨ ale 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 Ubertragungstechnik. Wie bei einer Telefonleitung steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verf¨ ugung. Die Zahl der gleichzeitig aktiven Teilnehmern ist f¨ ur die verf¨ ugbare Bandbreite nicht relevant und nur durch die maximale Zellkapazit¨ at (bezogen auf aktive Teilnehmer) beschränkt. IAM steht f¨ ur 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¨ ur die MCC und die folgenden zwei oder drei Ziffern f¨ ur 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¨ ur 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¨ ur die Funkverbindung zwischen MS und BTS. Im Bereich des ISDN bezeichnet S0 die Schnittstelle zwischen

¨ 1.4. BEGRIFFSERKLARUNGEN - TELEFONIE

7

NTBA und den Endger¨ aten, wie ISDN-Telefon oder AB-Wandler. Uk0 ist die ZweidrahtKupferschnittstelle zwischen NTBA und Vermittlungsstelle. ISDN Integrated Services Digital Network ist ein weltweiter Standard der leitungsvermittelten (circuit-switched) Telefonie. Endbenutzer haben es mit dem sogenannten Basic Rate Interface (BRI) zu tun. Große Nebenstellenanlagen sind mittels Primary Rate Interfaces (PRI) mit dem ¨ offentlichen Telefonnetz verbunden. ISUP Der ISDN User Part regelt die Inter-Circuit-Signalisierung von Anrufen und ist f¨ ur deren Auf- und Abbau zust¨ andig. Diese kann mittels SS7 oder alternativ mittels D-Kanal (Q.931) erfolgen. ISUP beinhaltet folgende Felder: IAM, CgPN, CdPN, USI, FCI, CPC, CCI. MSC Das Mobile Service Switching Centre ist die zentrale Schaltstelle im TelefonieNetzwerk. Es ist verbunden mit dem Radio Access Network (RAN), welches von den BTS und BSCs gebildet wird, welche wiederum das Public Land Mobile Network (PLMN) bilden.

MISDN Die Mobile Station ISDN Number wird dazu verwendet Benutzer zu identifizieren, wenn Verbindungen aufgebaut werden. Sie besteht aus maximal 15 Ziffern,3 wobei die ersten eins, zwei oder drei Ziffern f¨ ur den Country Code (CC) und anschliessende Ziffern f¨ ur den National Destination Code (NDC) stehen. Letzterer bezeichnet u ¨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¨ urlich irgendwo hin speichern, was aber f¨ ur 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¨ uber 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¨ ur PLMNs. GSM unterscheidet hier noch in Home PLMN (HPLMN), Visited PLMN (VPLMN) und Interrogating PLMN (IPLMN) 3

Im Gegensatz zu den bekannten IP-Adressen handelt es sich hier um aufeinanderfolgende Dezimalziffern. Das liegt an der langen Historie von Telefonnetzen, die traditionell Teilnehmern Ziffernfolgen des Dezimalsystems zuordnen.

8


POTS Plain Old Telephony System bezeichnet oft die klassische ”Analog”-Teleonie u ¨ ber die 2-Draht-Kupferleitung. PSTN Das Public Switched Telephone Network meint das klassische System der (digita¨ len) Telefonie. Ublicherweise wird hierf¨ ur 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¨ uck Plastik, das in das ME gesteckt wird), welcher den sogenannten Subscriber (Mobilfunkbenutzer) gegen¨ uber 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¨ ur interaktive Dienste wie Telefonie, Video-Conferencing oder Multi-User-Games zur Verf¨ ugung stellen kann. SS7 Das Signalisierungs System (Signaling System) 7 ist ein Standard der Out-of-BandSignalisierung in digitalen Telefonnetzen. UTMS Hinter der Abk¨ urzung Universal Mobile Telecommunications System steckt der 1998 von der ETSI (Abk¨ urzung f¨ ur 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 Ubertragung von ¨ Sprache und Audiodaten, die Ubermittlung von multimedialen Inhalten sowie der schnelle Zugriff auf das Internet. UMTS erm¨ oglicht Daten¨ ubertragungsraten von 364 kbit/s bis zu ¨ 2 Mbit/s, womit Streaming Video und Audio Ubertragung, sowie Bildtelefonie ermöglicht ¨ werden sollen. Diese Ubertragungsraten 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

LAN Hardware 2.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¨ unstig, was, zusammen mit Ubertragungsraten von bis zu 1000 Megabit pro Sekunde, zu seiner starken Popularität gesorgt hat. ISO/OSI

IEEE 802.3 reference model

Application Presentation Session

Upper-layer protocols

Transport Network

MAC-Client

Data Link

Media Access (MAC)

Physical

Physical (PHY)

IEEE 802-spcific IEEE 802.3-spcific Media-specific

Abbildung 2.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¨ urfen 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 u ¨ bertragen kann. Ein Host wird dabei u 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 9

10

KAPITEL 2. LAN HARDWARE Transmission order: left-to-right, bit serial FCS error detection coverage FCS generation span

PRE

SFD

DA

SA

7 1 6 6 Field length in bytes

Length/Type 4

Data 46

Pad -

1500

FCS 4

Abbildung 2.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¨ ahrend das letzte Byte mit dem Wert 10101011 das Ende der Präambel ank¨ undigt. Es folgen die Ziel und Quelladresse (jeweils 6 octets lang) und die Art des dar¨ uberliegenden Protokolls (kodiert in 2 octets). Nach den minimal 46 und maximal 1500 Byte Daten schliesst sich eine Pr¨ ufsumme (4 octets lang). Unterschreitet eine Datagrammgröße 46 Bytes, so muss mit Zusatz-Bits erweitert werden. Die Vermittlungsschicht verwendet das L¨ angen-Feld im Header, um die F¨ ullbits zu erkennen. Durch das CRC-Feld wird u uft, ob irgendwelche Bits im Rahmen durch äußere Einfl¨ usse (z.B. Dämpfung ¨ berpr¨ der Signalstärke, elektromagnetische Umgebungsstörungen, usw.) gekippt (komplementiert) wurden. Der Client berechnet den Wert des CRC-Feldes aus den u ¨brigen Bits im Rahmen einschließlich der Pr¨ aambelbits. Der Server wendet auf die empfangenden Bits im Rahmen dieselbe Berechnung an (CRC-Pr¨ ufung) und u uft damit den vom Client eingetragenen ¨ berpr¨ Wert. Ethernet arbeitet nach dem CSMA/CD-Verfahren, was ”Carrier Sense Multiple Access/Collision Detection” bedeutet. Bevor eine Daten¨ ubertragung beginnt, wird der Zustand des Netzes von der sendewilligen Station u uft. Jede Station darf immer dann ¨ berpr¨ senden, wenn in diesem Moment keine andere Station Daten u ¨ 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 u uft - zur Sicherstellung, dass sie alleine sendet - ob das ¨ berpr¨ gesendete Signal gleich dem empfangenen ist. Sollte dies nicht der Fall sein, so verschickt die Station ein St¨ orsignal (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¨ ugung stellen, an dem eine bestimmte MAC anliegt (hierzu haben diese Geräte

2.1. ETHERNET

11

u ¨ blicherweise einen Speicher von 1000 - 8000 MAC-Adressen) und zum anderen wird per Store&Forward das Zusammentreffen von Paketen vermeiden.

2.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 Control), 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¨ uckt. Somit leitet die Vermittlungsschicht des sendenden Clients Datagramme an den Adapter der Sicherungsschicht weiter, während dieser dann die Erweiterung des Ethernet-Headers u ¨bernimmt und den so entstandenen Rahmen auf der Kommunikationsleitung u agt. ¨ bertr¨ Der Adapter des empfangenden Servers extrahiert dann die Datagramme aus den Rah¨ men und leitet sie nach der Uberpr¨ ufung 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¨ ussen. Ein wesentlicher Grund daf¨ ur, 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¨ utzten könnten und somit ihre Flexibilität verlieren w¨ urden. Adressaufl¨ osungsprotokolle wie ARP, dienen den Sende-Adaptern, aus den Ziel-IPAdressen die MAC-Adressen der entsprechenden Empfangs-Adapter zu ermitteln. Es ist zu erwähnen, dass ARP nur die IP-Adressen in MAC-Adressen auflöst, deren Hosts sich im gleichen LAN befinden.

2.1.2

Koaxialkabelbasierte Netze fu ¨r 10 MBit max. 30 Stationen pro Segment

PC 1 TERM CHEAPER-NET 50Ohm 2,5m

10Base2

max. 100 Stationen pro Segment

TERM 50Ohm

PC 2

WS 1

WS 2

MAUI

YELLOW-CABLE

max. 4 Repeater 185m

WS 3

TERM 50Ohm

T-Connector

Repeater

TERM 50Ohm

10Base5 500m

Abbildung 2.3: Regeln in BNC-Netzen Thin Ethernet, Cheaper Net oder auch BNC bezeichnet die inzwischen veraltetete Vernetzung mittels 50 Ohm abgeschirmten Koaxialkabel (wie beim Rundfunk; Verbindungsst¨ ucke und -kupplungen sind in BNC-Technik ausgef¨ uhrt. Die Enden m¨ ussen mit Endwiderständen ”terminiert”, d.h. abgeschlossen werden.). Diese Topologie ist preiswert und recht einfach; neue Knoten sind mit geringem Aufwand einzuf¨ ugen. Die Nachteile liegen jedoch in der primitiven Technik und seiner Empfindlichkeit. Die Unterbrechung des Kabels an einer Stelle f¨ uhrt zum Ausfall des ganzen Netzwerk(-segment)es. Bezeichnet wird dieser Standard mit 10Base2. Mittels Cheapernet können bis zu 185 m u uckt werden. Der ¨ berbr¨ ursrp¨ ungliche Standard 10Base5 basiert auf dickerem Koaxialkabel, wobei die Anschl¨ usse

12

KAPITEL 2. LAN HARDWARE

der Endgeräte mittels Transceiver erfolgte. Hiermit sind bis zu 500 m Gesamtlänge erreichbar.

2.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¨ ange liegt hier bei 100 m. Bei mehr als zwei Rechnern ist nun u atzliche Hardware notwendig, die als ”Hub” bezeichnet ist. Die Verkabe¨ blicherweise zus¨ lung erfolgt sternf¨ ormig 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 u ¨blicherweise die Kabelpaare 1,2 und 3,6 verwendet. M¨ ochte man zwei Rechner direkt mittels TP-Kabel verbinden, muss dieses gekreuzt sein, damit Empfangs- und Sendeanschl¨ usse entsprechend miteinander verbunden werden. Diese Aufgabe wird u ¨blicherweise von einem Hub bzw. Switch u oglichkeit ist die beiden Rechner mit einem “Cross¨bernommen. Eine andere M¨ Connect-Kabel” zu verbinden. ¨ Damit Endger¨ ate und Netzwerkkomponenten mit unterschiedlichen Ubertragungsraten in einem Netz betrieben werden k¨ onnen, sind Komponenten, die 100 Mbit transferieren können, mit einem Media Independent Interface (MII) ausgestattet. Dieses handelt beim ¨ Aufbau der Verbindung die Ubertragungsrate, sowie den Verbindungsmodus (Voll- oder Halbduplexbetrieb) aus.

2.1.4

1000 Mbit

F¨ ur Ethernetverbindungen mit 1000 Mbit (Gigabit) benötigt man vier verdrillte Kupferadernpaare. Das hat zur Folge, dass ¨ altere Kabel aufgrund ihrer Beschaltung und elektrischen Eigenschaften nicht mehr genutzt werden können. Gigabitnetzwerkkomponenten verf¨ ugen analog zu 100 Mbit Ger¨ aten u ¨ber ein Gigabit Media Independent Interface (GMII), welches die Aushandlung der Verbindungsart vornimmt. Auf diese Weise können a¨ltere Geräte weiterhin in einem solchen Netz betrieben werden. Das GMII ist in der Lage automatisch zwischen gekreuzten und ungekreuzten Kabelverbindungen zu unterscheiden und die Verbindung entsprechend zu schalten. 416 byte for 1000Base-X 520 byte for 1000Base-T

PRE

SFD

DA

SA

Length/Type

7 1 6 6 Field length in bytes

4

Data 46

Pad -

1500

FCS

Extension

4

Abbildung 2.4: Erweiterungen des Ethernet-Standards f¨ ur Gigabit

2.1.5

Ethernet unter Linux

Fast immer h¨ angen vernetzte Linux-Maschine an einem Ethernet. F¨ ur mobile Endgeräte wie Laptops oder Tablet-PC gilt, dass dieses noch nicht permanent der Fall sein muss. Wenn auch Ethernets zu den fehlerfreiesten Netzwerken zählen, so m¨ ussen 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.

2.1. ETHERNET

13

Weniger dramatisch ist eine Netzwerkkarte im Fullduplex-Mode an einem Hub. Hier leidet die Verbindungsqualit¨ at 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. Als Systemadministrator ruft man ethtool eth0 auf und erhält einen umfas¨ senden Uberblick zum Ethernet-Interface eth0. Hierzu gehören die unterst¨ utzten InterfaceGeschwindigkeiten, die aktuell benutzte Geschwindigkeit, der Duplex-Status, welche Art des Mediums angeschlossen ist, ob ein Link besteht und weiteres. Wenn es Probleme mit der automatischen Aushandlung der Parameter gibt, lässt sich diese ausschalten: s02:~ # ethtool -s eth0 autoneg off s02:~ # ethtool -s eth0 speed 10 s02:~ # ethtool -s eth0 duplex half Anschliessend kann die Geschwindkeit und die Art des Links manuell eingestellt werden. Das Ergebnis der letzten beiden Kommandos sorgt f¨ ur eine Netzwerkverbindung in der Qualität des alten BNC-Ethernets - 10 Mbits half duplex. Unterst¨ utzt die Netzwerkkomponente ¨ Hub oder Switch die Anzeige der Geschwindigkeit, kann man die Anderung 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¨ urlich auch Schritt-f¨ ur-Schritt in der Kommandozeile vornehmen, indem er die eben gezeigten Befehle umkehrt. ¨ Ein gezogenes Kabel quittiert ethtool mit der Meldung ”Link detected: no”. Ahnliche Informationen liefert auch mii-diag. hermes:~ # mii-diag eth0 Basic registers of MII PHY #1: 1000 796d 0020 6162 05e1 41e1 0005 2001. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. ethtool kann bei einer Reihe von Netzwerkkarten, beispielsweise einigen Onboard ViaRhine, dazu verwendet werden, Wake-on-LAN einzuschalten. Dieses erreicht man durch ethtool -s eth0 wol g. Der Parameter ”g” steht f¨ ur ”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¨ onnen, auch u ¨ber Router hinweg. Möchte man permanent den Link-Status u ¨berwachen, weil man beispielsweise nicht zum Ablesen der LEDs an der Karte auf die Rechnerr¨ uckseite krabbeln will, können hier die Nic-Tools weiterhelfen. So u ur eine SMC Epic100-Karte (83c170) ¨ berwacht beispielsweise f¨ ”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¨ onnen weitere Informationen, beispielsweise u ¨ ber den Inhalt des Konfigurations-EEPROMs oder Device-Register ausgeben: via-diag -e oder rtl8139-diag -a.

14


2.2

Funk-Netze

Drahtlose lokale Kommunikationssysteme, sogenannte Wireless LANs, finden bei zunehmender Produktvielfalt eine immer gr¨ ossere Verbreitung. Sie basieren u ¨blicherweise auf ¨ Funk als Ubertragungsweg. 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¨ ugbarer drahtloser Technik sind eine ganze Reihe von Mobilitätsanspr¨ uche 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 u ¨bergreifendes Signalerkennen möglich ist oder stark erschwert wird. Zusätzlich soll eine Bewegung zwischen verschiedenen Zellen erm¨ oglicht werden. Diese Fähigkeit von Netzen wird als Roaming bezeichnet. Um die beschriebenen Probleme in den Griff zu bekommen, wird ein MAC-SublayerProtokoll implementiert. Damit wird ein einheitliches Netz u ¨ber verschiedene Sender möglich. Ein naiver Ansatz w¨ are Verwendung des CSMA/CD-Verfahrens, wie es beim drahtgebundenen Ethernet geschieht. Jedoch h¨ ort 3 nichts bei einem Transfer zwischen 1 & 2 und könnte zu 2 u ¨ 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¨ aßt einen gleichzeitigen Transferversuch zu 4, obwohl dadurch keine gegenseitige St¨ orung auftreten w¨ urde. Auf diese Weise wird Bandbreite verschenkt: ”Exposed Station Problem”. Deshalb wird ein neues Zugriffsverfahren eingef¨ uhrt. 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¨ undigung des großen Datenblocks. Die Zielstation antwortet mit einem CTS (Clear To Send). Reichweite von 1

3

1 RTS 2

4

3

1

5

CTS 2

4

5

Reichweite von 2

MACA (W) Zugriffsverfahren für WLAN

Abbildung 2.5: Sichtbarkeitsproblem Alle Stationen, die ein RTS-Signal hören, m¨ ussen 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

2.2. FUNK-NETZE

15

• 802.11g bis 54M bit/s jedoch im 2,4 GHz Band ¨ Mit dem derzeitig verf¨ ugbaren Standard sind bei 11 Mbit/s nominaler Ubertragungsrate aufgrund von Protokolloverheads real ca. 6 Mbit/s erreichbar. Verwendet wird das f¨ ur Forschung, Medizin und private Zwecke freigegebene Frequenzband bei 2,4 GHz. Die Leistung der verwendeten Ger¨ ate, 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 u uckbar. ¨berbr¨ Ein Funknetz kann in verschiedenen Modi aufgebaut werden: AdHoc, Managed, Master, AccessPoint. Hiervon h¨ angt ab, ob die Netzwerkkarten auf eine feste Frequenz eingestellt werden m¨ ussen oder sie nach einem gemeinsamen Kanal suchen. Beim AccessPoint-Modus u ¨ 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¨ undelung, womit insgesamt weniger Kanäle f¨ ur verschiedene Netze zur Auswahl stehen. Die Aufteilung des zur Verf¨ ugung stehenden Frequenzspektrums erfolgt auf bis zu 13 Kanäle1 Bei einem engmaschigem Netz von AccessPoints ist eine geschickte Kanalaufteilung notwendig, um Signalst¨ orung 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 u ugung. Die nutzbare Bandbreite hängt also von den Teilneh¨ ber Koaxialkabel, zur Verf¨ mern pro Funkzelle ab. Es ist jedoch möglich mehrere Zellen parallel zu betreiben. Die Kennung erfolgt u ¨ 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 2.6: Kanalaufteilung 1

Die Verteilung ist in verschiedenen L¨ andern unterschiedlich, so dass nicht immer alle Kan¨ ale genutzt werden d¨ urfen.

16


Ein wesentliches Problem haben WLANs gegen¨ uber 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¨ uhrt. Es arbeitet mit 64 bzw. 128 Bit Schl¨ usseln. 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¨ ur sich anmeldende Geräte betrieben, die meist so konfiguriert sind, dass jeder Host eine Adresse erh¨ alt. Deshalb gibt es inzwischen eine Art Volkssport: WarDriving (oder WarChalking - Suchen nach offenen WLAN-Netzen).

2.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 (¨ ublicherweise 4 oder 16 Mbit) kann auch mit einer gr¨ osseren Zahl von Maschinen besser ausgenutzt werden, als im ungeswitchten Ethernet. Die Verz¨ ogerungszeiten in einem TokenRing liegen u ¨blicherweise unter 250 ms. In der Regel berechtigt der Besitz des Tokens nur zur Sendung eines Blocks (non exhaustive). Im anderen Extremfall k¨ onnte auch definiert werden, dass die Station soviele Datenblöcke senden kann, wie sie m¨ ochte (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 u ¨bernimmt eine von ihnen als ”aktiver Monitor” besondere ¨ Uberwachungsaufgaben im Netz. Eine andere Station u ¨ berwacht als ”passiver Monitor” den aktiven Monitor und kann gegebenenfalls dessen Aufgaben u ¨ bernehmen. Die Aufgaben des aktiven Monitors sind: • Erzeugen des Ringtaktes ¨ • Uberwachen 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¨ andig senden kann, bevor sie ihn wieder empfängt. In regelm¨ aßigen Abst¨ anden sendet der aktive Monitor einen “Active Monitor Present Frame” an alle Stationen im Ring. Gleichzeitig wird dadurch eine Prozedur in Gang gesetzt,

2.3. TOKENRING

17

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¨ uhrung 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¨ unf Schritten: 1. Ist ein Adapter vom Ring getrennt, sind gleichzeitig Eingangs- und Ausgangsleitung kurzgeschlossen. Es erfolgt zun¨ achst ein Adaptertest. Nach dem Test versorgt der Adapter die Relais mit Strom und wird in den Ring eingegliedert. 2. Die Station h¨ ort nun den Ring ab. Wenn sie innerhalb einer festgelegten Zeit keine Aktivit¨ at des aktiven Monitors wahrnimmt, startet sie den Prozeß zur Auswahl des aktiven Monitors. 3. Durch Aussenden eines ”Duplicate Address Test Frame” pr¨ uft die Station die Eindeutigkeit ihrer Adresse. Ist sie nicht eindeutig, koppelt sich die Station wieder ab. 4. Durch den NAUN-Prozeß erf¨ ahrt 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¨ otig ist. Die Funktionen von Monitor und von den eingegliederten Stationen m¨ ussen nicht nur einmalig initiiert, sondern auch st¨ andig u ¨ berwacht werden. In vielen Fällen sind dies zahlreiche Aktionen, die auch viele Bl¨ ocke 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¨ angt, 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¨ alt die Adresse des Senders (SA) und die Zieladresse (DA). Wenn die Zieladresse mit der eigenen Adresse u ¨ 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¨ at vorab reserviert werden:

18

KAPITEL 2. LAN HARDWARE Priorit¨ at 0 1-3 4 5,6 7

Anwendung frei verf¨ ugbar, von den meisten Anwendungen verwendet frei verf¨ ugbar von Bridges verwendet reserviert, jedoch nicht verwendet f¨ ur die Administration des Ringes verwendet Tabelle 2.1: Prioritätslevel bei TokenRing

Nur die Station mit der h¨ ochsten reservierten Priorität erhält somit das Senderecht. Diese Priorit¨ aten, zusammen mit der festgelegten maximalen Umlaufzeit eines Paketes, ermöglichen eine garantierte Daten¨ ubertragung kontinuierlicher Medientypen.

2.4

Netzwerk-Interfaces von Linux

Auf irgendeine Weise m¨ ussen Netzwerkdatenpakete in eine Linuxmaschine hineinkommen oder diese verlassen k¨ onnen. Dies geschieht u ¨ 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¨ ur alle Ethernet-Interfaces die Bezeichnung ethN. Das ”N” ist eine nat¨ urliche Zahl zwischen ”0” f¨ ur das erste Interface und ”n-1” f¨ ur die letzte Netzwerkkarte, die in eine Maschine eingebaut ist. Ein Rechner kann durchaus u ¨ber etliche Interfaces auch von verschiedenen Typen verf¨ ugen. Die Verf¨ ugbarkeit eines bestimmten Interfaces hängt meistens von einem Kerneltreiber ab. Mit dem Laden des entsprechenden Moduls f¨ ur einen TokenRing, Ethernet oder ugung. Dabei hängt die ähnliche Adapter steht sodann das entsprechende Interface zur Verf¨ 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 Netz¨ werkinterface vom Typ tr0 und folgende f¨ ur weitere Adapter dieser Art bereit. Ahnliches geschieht bei den entsprechenden Modulen f¨ ur ATM, FDDI und andere Netzwerkhardware. Eine Besonderheit ist das Loopback-Interface, welches mit dem Einschalten der TCP/IP Unterst¨ utzung, im Kernel automatisch zur Verf¨ ugung steht. Es wird mit lo bezeichnet und existiert nur in einfacher Ausf¨ uhrung. Weiterhin gibt es eine Reihe von Software-Interfaces, wie ppp0 f¨ ur PPP-Verbindungen verschiedener Art, slip0 f¨ ur Serial-Line-IP, dummy0 f¨ ur Testzwecke, ipsec0 f¨ ur IPsec-Verbindungen und weitere. dirk@linux:~/kurs> /sbin/ifconfig cipcb0 Link encap:IPIP Tunnel HWaddr inet addr:192.168.2.2 P-t-P:192.168.2.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth0

Link encap:Ethernet HWaddr 00:02:B3:87:53:43 inet addr:132.230.9.124 Bcast:132.230.9.255 Mask:255.255.255.0 inet6 addr: fe80::202:b3ff:fe87:5343/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5323418 errors:0 dropped:0 overruns:0 frame:0 TX packets:6567650 errors:0 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100

2.5. AUFGABEN

19

RX bytes:795523375 (758.6 Mb) TX bytes:2554637681 (2436.2 Mb) Interrupt:10 Base address:0xec00 Memory:dffff000-dffff038 lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8401120 errors:0 dropped:0 overruns:0 frame:0 TX packets:8401120 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:802796349 (765.6 Mb) TX bytes:802796349 (765.6 Mb)

vmnet8

Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fec0:8/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:4297 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Mit dem Kommando ifconfig erh¨ alt man z.B. obige Ausgabe, welche ein Interface f¨ ur CIPE (cipcb0 ), ein klassisches Ethernet-Interface (eth0 ), das Loopback-Interface (lo) und ein virtuelles Ethernet-Interface f¨ ur die Software VMware (vmnet8) als konfiguriert anzeigt. Die angezeigten Zusatzinformationen variieren in Abhängigkeit vom Interface-Typ. Die Maximum Transfer Unit (MTU) h¨ angt 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 u ¨ bertragen. Hardwaredaten, wie verwendeter Interrupt und Speicherbereiche findet man nat¨ urlich nur bei Interfaces, die direkt mit einer Hardware zu identifizieren sind.

2.5

Aufgaben

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

20


Kapitel 3

WAN Hardware 3.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, Uberweisungen (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¨ ubertragung eingesetzt werden kann. Die folgenden Abschnitte wollen deshalb versuchen, dem Leser einem Blick hinter die Kulissen der physikalischen Daten¨ ubertragung zu verschaffen. Dabei wird insbesondere auf die eingesetzten Technologien und Methoden der Daten¨ ubertragung eingegangen. Wie aus dem Namen bereits ersichtlich, bilden Computernetzwerke einen Verbund von mehreren Computern. Dabei k¨ onnen diese Computer sich alle in einem Raum befinden und u ¨ ber sogenannte Netzwerkkabel direkt miteinander verbunden sein oder sich in unterschiedlichen Teilen der Welt aufgestellt sein und u ¨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 u ¨ ber ein lokales Netz (LAN) miteinander verbunden sind. Umfangreiche Netzwerke sind beispielsweise Unternehmensnetzwerke, Firmennetzwerke oder Universitätsnetzwerke. Das ber¨ uhmteste 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¨ ahnt - die Hosts sich in den verschiedensten Teilen der Welt befinden können und in jedem Land unter Umständen andere Standards bez¨ uglich der eingesetzten Computertechnologien existieren, beschäftigte man sich schon in den fr¨ uheren Jahren der Netzwerkeinf¨ uhrung mit der Frage des reibungslosen Ablaufes der Kommunikationen zwischen den verschiedenen Hosts. 21

22

3.2 3.2.1

KAPITEL 3. WAN HARDWARE

Leistung und Kosten der einzelnen Technologien Leistung / Datendurchsatz

In Tabelle 3.1. sind die h¨ aufig verwendeten Verbindungsprotokolle aufgef¨ uhrt. 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. Medium Funk-LAN ADSL ATM Ethernet (TP) Ethernet (BNC) ISDN loopback Modem GPRS/HSCSD UMTS Serieller Port Tokenring

Reichweite einige 100m mehrere km mehrere km 100 m 185 m 0 mehrere km mehrere km 30 m 100 m

Knoten ca. 20 - 50 2 - ... ca. 35 1 2 2 8

Durchsatz 2 - 11 Mbits 0.5 - 7.6 Mbit 2 - 622 Mbits 10 - 1000 Mbits 10 Mbits 64 Kbits 100 Mbits 0.3 - 56 Kbits 0.3 - 56 KBit 128 - 386 KBit 300 - 112000 Bits 4, 16 Mbits

Tabelle 3.1: Leistung und Datendurchsatz einiger Netzwerke

3.2.2

Kosten

Die Kosten f¨ ur die verschiedenen Netzwerktypen sind in Tabelle 3.2. aufgelistet. Sie lassen sich hier nat¨ urlich nur grob angeben. Bei Festinstallationen wird man noch die Aufwendungen f¨ ur Anschlussdosen (5 - 20 EUR/St¨ uck), die Unterverteiler (Patchpanel (20 - 300 EUR), Datenschränke (200 - 600 EUR), Patchkabel (TP 1-4 EUR/m, LWL 12 EUR/m ...) mit einplanen m¨ ussen. Wenn Lichtwellenleiter zum Einsatz kommt, sind die Aufwendungen noch etwas höher anzusetzen, da f¨ ur den Anschluss (das Spleissen) in den meisten Fällen eine Firma beauftragt werden muss. Bei einer Funkvernetzung entfallen die Kosten f¨ ur eine Festinstallation, jedoch sind die weitaus höheren Aufwendungen f¨ ur die Netzwerkkarten und die Access-Points zu ber¨ ucksichtigen. Einige Netzwerk-Technologien wird man nur noch in bestehenden Installationen oder Computer-Flohm¨ arkten antreffen. Hierzu gehören sicherlich BNC-Ethernet, TokenRing oder auch Parallelport-Verbinder.

3.3

Telefonnetze

Telefonnetze geh¨ oren zu den ¨ altesten Weitverkehrsnetzen u ¨ berhaupt. Die ersten ZweidrahtKupfer-Telefonnetze wurden bereits Ende des 19. Jahrhunderts eingerichtet. Die Versorgung mit Telefonanschl¨ ussen liegt in Deutschland inzwischen bei nahe 100 Prozent. Datennetze kamen deutlich sp¨ ater. Deshalb wurden die ersten Datenleitungen u ¨ber Telefonnetze geschaltet. Die meisten Internet-Benutzer verwenden in irgendeiner Form Telefonleitungen

3.3. TELEFONNETZE Medium ATM Parallelport Ethernet (TP 1000) Ethernet (TP 100) Ethernet (TP 10) Ethernet (BNC 10) Funk-LAN (2/11 Mbit) ISDN Modem GPRS HSCSD UMTS Serieller Port TokenRing

23 Adapter 300 - 600 EUR 5 - 10 15 - 100 EUR 4 - 40 EUR – – 100 - 200 EUR 20-90 EUR 10 - 200 EUR 40 - 300 EUR 40 - 200 EUR 80 - 300 EUR – –

Kabel 4/m (LWL) 10 0.70/m 0.70/m 0.70/m 0.20/m 500/AccessPoint 5 0.70/m

Geb¨ uhren (ca. EUR) Grosskunde Telefongeb¨ uhren Telefongeb¨ uhren saftige Volumengeb¨ uhr saftige Zeitgeb¨ uhr saftige Volumengeb¨ uhr 0 -

Tabelle 3.2: Kosten einiger Netzwerke f¨ ur die Verbindung. Dabei geht der Trend jedoch eindeutig weg von den alten ”analogen” Telefonanschl¨ ussen u ¨ber ISDN hin zu DSL. Jedoch bleibt der Anbieter der Zweidraht-Leitung in den meisten F¨ allen identisch. Die Zeit der analogen Telefonnetze in Deutschland ist Mitte der 90er Jahre abgelaufen. Wenn auch die meisten Endger¨ ate in den Haushalten nach den Prinzipien der Telefone von ¨ vor 70 Jahren arbeiten, so findet die Gesprächsvermittlung und Ubertragung im Hintergrund meistens nur noch digital statt.

3.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. ¨ Ubertragungsmethoden Analoge Modems IDSN Symmetrisches DSL ADSL (DMT) ADSL (CAP) VDSL Kabelmodems

Datenrate Upstream 33.6 kbps 128 kbps 2048 kbps 768 kbps 64 kbps 640 kbps 640 kbps 1,6 bis 2,3 Mbps 768 kbps

Datenrate Downstream 56 kbps 128 kbps 2048 kbps 8 Mbps 1,54 Mbps 6,14 Mbps 13 Mbps 52 Mbps 30 Mbps

Reichweite in Meter etliche km etliche km 4000 6000 6000 4000 1500 300 je nach Kabel

Verf¨ ugbarkeit in Deutschland verf¨ ugbar verf¨ ugbar verf¨ ugbar verf¨ ugbar verf¨ ugbar verf¨ ugbar Testphase Testphase Testphase

¨ Tabelle 3.3: Protokolle auf 2-draht Kupferleitungen im Uberblick

24


3.3.2

Digitale Telefonnetze - ISDN

Meistens wird ISDN f¨ ur einen Zugang zum Internet verwendet; es ist f¨ ur interne Vernetzungen fast nur im Bereich der WAN’s (Wide Area Networks) anzutreffen. ISDN wird u ¨ blicherweise von Telefongesellschaften zur Sprachkommunikation angeboten und findet sich auch im Umfeld gr¨ osserer Firmentelefonanlagen. Die Primärbandbreite beträgt 64 kbit, welches von der digitalen Sprachvermittlung herr¨ uhrt. 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¨ ur den jeweiligen Adapter muss eine Treiberunterst¨ utzung 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¨ ugung. Diese können sodann mit den klassischen Netzwerktools eingerichtet und gesteuert werden.

3.3.3

Mobilfunknetze nach dem GSM-Standard

GSM - der Global Standard for Mobile Communication definiert ein digitales Mobilfun¨ knetz, was in der u dieses ¨ berwiegenden Zahl der Länder weltweit eingesetzt wird. Uber Telefonnetz ist es ebenfalls m¨ oglich Daten zu u ¨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.

3.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¨ ur den schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt1 ins Netz her. F¨ ur die Datenkommunikation wird es Endgeräten erlaubt, mehrere GSMKanäle zusammenzufassen und f¨ ur 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¨ ur jeden einzelnen die erreichbare Datenrate. ¨ Ublicherweise haben Sprachverbindungen Vorrang, so dass die verf¨ ugbare 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¨ ale gleichzeitig nutzen. In der Einf¨ uhrungsphase 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¨ ale f¨ ur GPRS zur Verf¨ ugung, w¨ urde die Bandbreite auf 107,2 kbit/s steigen. Weitere Steigerungen durch bessere Fehlerprotokolle erlaubten theoretische 171,2 kbit/s (8 Kan¨ ale a 21,4 kbit/s). Handys arbeiten momentan mit 13,4 kbit/s pro Kanal. Sie k¨ onnen je nach Ger¨ at zwei bis drei Kanäle zusammenfassen. Aktuelle Ger¨ ate unterst¨ utzen auch vier Kanäle und können damit auf eine Bandbreite von 53,6 kbit/s kommen. Die Angaben beziehen sich jedoch meistens nur auf den DownloadKanal. Im Upload k¨ onnen 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¨ ale nutzen kann. Class 8 deutet auf vier Down- aber nur einen Upstream hin. 1

APN = Access Point Name

3.3. TELEFONNETZE

25

GPRS selbst arbeitet schon mit starker Datenkompression. Deshalb kann der Endanwender auf eine Kompression auf h¨ oheren Protokollschichten verzichten. GPRS verwendet zur ¨ Paketvermittlung gleich das Internet-Protokoll. Ublicherweise stellen die Mobilfunkanbieter ihren Datenkunden dabei eine private Netzwerkadresse zur Verf¨ ugung. Die Aushandlung der IP-Parameter u bernimmt das von anderen Diensten wohlbekannte Point-to-Point-Protokoll ¨ (PPP). Jedes Datenpaket besitzt somit eine eindeutige Empfängeradresse im Funknetz, um zu dem Endger¨ at zu gelangen. Hierf¨ ur ist es unerheblich, u ¨ber welchen der Funkkanäle es u ¨ bertragen wird. Wie beim GSM auch halten alle eingebuchten GPRS-Teilnehmer permanent u ¨ber Signalisierungskan¨ ale Kontakt mit dem Netz. Der Teilnehmer ist u ¨ ber den Zeitraum der Einbuchung immer online. Hierf¨ ur m¨ ussen die Kanäle nicht aufgebaut sein. Die notwendigen Kanäle werden erst zugeschaltet, wenn tatsächlich Daten abgerufen werden. Die Einf¨ uhrung von GPRS erfolgte in Deutschland schrittweise ab dem Jahr 2000. GPRS wurde dabei technisch gesehen u ¨ ber das bestehende GSM-Netz gelegt. Wesentliche Teile der GSM-Infrastruktur kommen auch f¨ ur das GPRS-Netz zum Einsatz.

3.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¨ ubertragung auf 14,4 kBit/s erh¨ oht, in der GSM-Phase-2+ die B¨ undelung 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 Ubertragungstechnik. Wie bei einer Telefonleitung steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verf¨ ugung. Das macht sich im Abrechnungsmodell bemerkbar: HSCSD-Anbieter offerieren dem Teilnehmer einen zeitabhängigen Tarif, der unabh¨ angig 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¨ ur die gewohnte Internet-Nutzung nahe. HSCSD lohnt sich nur bei permanenten gleichm¨ aßig hohen Datenraten.

3.3.6

Mobilfunknetze der dritten Generation - UMTS

Hinter der Abk¨ urzung UTMS (Universal Mobile Telecommunications System) steckt der 1998 von der ETSI (Abk¨ urzung f¨ ur 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 Ubertragung von ¨ Sprache und Audiodaten, die Ubermittlung von multimedialen Inhalten sowie der schnelle Zugriff auf das Internet. UMTS erm¨ oglicht Daten¨ ubertragungsraten von 364 kbit/s bis zu ¨ 2 Mbit/s, womit Streaming Video und Audio Ubertragung, sowie Bildtelefonie ermöglicht werden sollen. ¨ Diese Ubertragungsraten erreicht UMTS durch den asynchronen Transfermodus kurz ATM-Verfahren im sogenannten Codemultiplexverfahren. Als Funk-Technologie kommt Wideband CDMA (WCDMA) im Frequenzbereich um die 2 GHz zum Einsatz. UMTS-Hotspots existieren bereits in Ballungszentren und Großstädten. Ob eine flächendeckende Einf¨ uhrung

26


stattfindet, muss abgewartet werden. Nicht mehr alle Bieter um die Lizenzen im Jahr 2000 sind am Start und die Aktivit¨ aten der verbliebenen sind von Zur¨ uckhaltung gekennzeichnet.

3.4

Modem

Ein ”Modem” empf¨ angt Daten von der seriellen Schnittstelle und verschickt sie u ¨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¨ ankt und liegt zur Zeit höchstens bei 56 kbit. Modems waren sehr lange Zeit traditionell u ¨ ber die serielle Schnittstelle an Computer oder entsprechende Ger¨ ate angeschlossen. Unter Linux erfolgt der Zugriff auf diese Schnittstellen u ¨ 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¨ ur Netzwerkinterfaces aufgesetzt und ausgelesen werden kann. Handelt es sich um ein USB-Modem, wird es nicht mehr u ¨ber eine Device-Datei vom Typ ttySn, sondern u ¨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.

3.5

ADSL

¨ Die Grenzen der Ubertragungskapazit¨ at der analogen Telefonleitungen sind durch das Nyquistund das Shannon-Theorem beschrieben. Das Nyquist-Theorem besagt, dass die Schrittge¨ schwindigkeit bei der verzerrungsfreien Ubertragung von Impulsen maximal doppelt so groß ¨ sein darf wie die Bandbreite des benutzten Ubertragungskanals. Das Shannon-Theorem zeigt Zusammenh¨ ange zwischen der verf¨ ugbaren Bandbreite - dem Verhältnis zwischen Signal- und Rauschpegel - und der maximal möglichen Anzahl u ¨bertragbarer Bits pro Sekunde. Beim derzeitigen analogen Telefonnetz ist die Bandbreite auf 4 kHz beschränkt und ¨ das Signal-/Rauschverh¨ altnis liegt bei 30 bis 35 dB. Daraus resultiert eine Ubertragungsrate von maximal 35 kBit/s (f¨ ur Modems!)

3.5.1

Designu ¨berlegungen

¨ Allerdings ist das Erreichen der maximalen Ubertragungsgeschwindigkeit von verschiedenen Faktoren abh¨ angig: Insbesondere die L¨ ange und der Querschnitt des Kupferkabels, sowie die Dämpfung begrenzen die theoretisch möglichen Transferraten. In der Praxis bedeutet das f¨ ur 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¨ ur ist, dass im Gegensatz zu FDM die Kanäle f¨ ur Up- und Downstream nicht komplett getrennt, sondern u ¨berlagert werden. Dies erhöht den technischen Aufwand zur Signaltrennung wesentlich und verteuert die Endgeräte.

3.5. ADSL

27

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¨ ur die Trennung des Frequenzspektrums in entsprechende Kanäle, schaffen also nur die Grundlage f¨ ur den eigentlichen Datentransfer. Dieser kann wieder¨ um durch verschiedene Ubertragungsmethoden realisiert werden. Auch hier läßt die ADSLSpezifikation - die in H¨ anden 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. Ahnlich 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 Ubertragungsverfahren beschrieben.

3.5.2 3.5.2.1

¨ Ubertragungsmethoden 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¨ ager-Bandpaß¨ ubertragungsverfahren, das ein Trägersignal mit einem Symbolstrom moduliert. Bei diesem Verfahren wird der Datenstrom in zwei ¨ einzelne Ströme mit halber Ubertragungsrate 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¨ angerseite passiert ¨ ahnliches: 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 Ubertragung aufgetretene Verzerrungen des Leiterpaares r¨ uckgängig und filtert die Frequenzanteile (f0) heraus. Danach liegt wieder das urspr¨ ungliche Basisbandsignal vor. Dieses wird f¨ ur das jeweilige Signal getrennt dekodiert, um die Teilsignale schließlich in einem Multiplexer (zur Serialisierung der Signale) zusammenzufassen. 3.5.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 u ¨bertragen wird, noch eigene Informationen beinhaltet. Auch CAP z¨ ahlt zu den Eintr¨ ager-Bandpaß¨ ubertragungsverfahren. Schon die Bezeichnung des Modulationsverfahren deutet seine Besonderheit an: Es wird eine trägerlose Am¨ plituden/ Phasenmodulation durchgef¨ uhrt, wobei ein technischer Kniff die Ubertragung der

28


Trägerfrequenz verhindert. Zus¨ atzlicher Unterschied zu QAM: Modulation und Demodulation erfolgen beim Sender und Empf¨ anger u ¨ber digitale Filter. An die Stelle der orthogonalen Tr¨ agerfunktionen von QAM treten digitale Filter, um die Teilströme zu modulieren. Das zu u ¨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.

3.5.2.3

DTM

(Discrete Multi-Tone Modulation) beschreibt ein Verfahren, bei dem mehrere Trägersignale ¨ f¨ ur die Ubermittlung eingesetzt werden. Die u ¨bermittelten Daten verteilen sich also auf eine Vielzahl von Tr¨ agern, 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¨ ahlt Discrete-Multi-Tone-Modulation zu den sogenannten Mehrtr¨ ager-Bandpaß¨ ubertragungsverfahren. Dieses Verfahren findet bei den Her¨ stellern derzeit breite Unterst¨ utzung. Zur Umsetzung wird der gesamte Ubertragungskanal in mehrere Teilkan¨ ale unterteilt, die - theoretisch - die gleiche Bandbreite aufweisen. Im einfachsten Fall findet bei jedem dieser Teilkanäle das gleiche Modulationsschema Verwen¨ dung. Die Ubertragungsrate ist daher identisch. Allerdings hat dies einen entscheidenden Nachteil gegen¨ uber den zuvor beschriebenen Modulationsmethoden: Wenn Teilkanäle in ¨ hohen Frequenzbereichen liegen, so schlagen sich die schlechten Ubertragungseigenschaften von Kupfer auf den Datentransfer nieder. Daher legen die Hersteller die Bitrate des jeweiligen Teilkanals entsprechend seiner St¨ oranfälligkeit fest. Nur so ist eine optimale Nutzung ¨ des Ubertragungsmediums Kupfer m¨ oglich. 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 u ¨ ber die Leitung schickt.

3.5.3

Vorteile der neuen Technik

Bei hinreichend kleiner Teilkanalbandbreite ist die Dämpfung f¨ ur 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 Kabels auf das u ¨ bertragene Signal in einem Teilkanal vernachlässigbar ist. Damit ist die Herstellung derartiger ADSL-Modems relativ preiswert. Allerdings setzt ein Mehrtr¨ ager-Modulationsverfahren Orthogonalität zwischen den verschiedenen Teilkan¨ alen 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¨ ahnt, kann die Anzahl der Bits, die u ¨ber einen Teilkanal gesendet werden, bei DMT variieren. Daraus ergibt sich eine verbesserte Performance, da störanfällige Fre¨ quenzen außen vor bleiben. Die m¨ ogliche Ubertragungsrate beim Upstream-Kanal erhöht sich dabei auf 256 kBit/s.

3.6. ATM

3.5.4

29

Benutzung unter Linux

Klassischerweise verf¨ ugen ADSL-Ger¨ ate beim Endnutzer u ¨ ber Ethernet- oder ATM-Schnittstellen, wobei u ¨ blicherweise nur erstere benutzt werden (können). ADSL stellt die Grundlage f¨ ur das Tunneln von Ethernetframes bereit. Damit eine benutzerbasierte Authentifizierung erfolgen kann - die Ethernet selbst nicht bereitstellt - wird ein spezielles Protokoll, das PPPoE2 , eingesetzt. Linux kommuniziert auf dem unteren, dem Ethernet-Layer, klassischerweise u ¨ ber die eingebaute Ethernet-Netzwerkkarte. Diese sollte vom Kernel treiberseitig unterst¨ utzt sein, womit ein Netzwerk-Interface vom Typ eth0 und folgende (f¨ ur weitere Netzwerkkarten) zur Verf¨ ugung steht. Dar¨ uberhinaus wird ein Software-Treiber benötigt, der das PPPoEProtokoll zur Verf¨ ugung stellt. Als Netzwerk-Interface steht anschließend eines vom Typ ppp0 (und weitere) zur Verf¨ ugung. Damit wird u ¨ ber das broadcastfähige Medium “Ethernet” eine Punkt-zu-Punkt-Verbindung zwischen zwei Rechnern aufgebaut.

3.6

ATM

Unter der Zielsetzung, die Grundlagen f¨ ur 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¨ agung gezogen wurde, entschied sich die ITU 1987 f¨ ur 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¨ undung eines weiteren Gremiums, welches sich ausschließlich mit der Standardisierung von ATM befaßt, dem ATM-Forum. Gegr¨ undet 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¨ ugiges Voranbringen des Standards ATM in enger Zusammenarbeit mit der ITU und der Industrie. Bei der Normierung fr¨ uherer Standards war es aufgrund des langwierigen Normierungsprozesses oft zu einem Auseinanderdriften von ITU-Norm und von der Industrie entwickelten Quasistandards gekommen. ¨ Wie auch andere Ubertragungsverfahren basiert ATM grundsätzlich auf einer Paket¨ u bzw. Ergänzun¨ bertragungstechnik. Hierbei sind jedoch folgende wesentliche Anderungen gen zu bisherigen Paketvermittlungsverfahren festzuhalten: ¨ • Feste Paketl¨ ange: ATM nutzt zur Ubertragung ausschließlich Pakete mit einer festen ¨ Länge von 53 Bytes. Diese kleinste unteilbare Ubertragungseinheit wird daher ATMZelle genannt. • Qualitätsparameter der Verbindung: ATM unterst¨ utzt 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. 2

PPP u ¨ber Ethernet: PPP-Pakete werden als Ethernetframes geschickt, welche selbst wiederum u ¨ ber den ADSL-Layer laufen. Damit erfolgt in den beiden unteren Schichten des OSI-Modells nochmals eine Untergliederung.

30

KAPITEL 3. WAN HARDWARE • Verzicht auf eine abschnittsweise Fehlersicherung: Die sehr geringen Bitfehlerwahrscheinlichkeiten heutiger Lichtwellenleiter ermöglichen den Verzicht auf eine abschnitts¨ weise Fehlersicherung zugunsten einer höheren Ubertragungsrate. ¨ • Verzicht auf eine abschnittsweise Flußsteuerung: Aufgrund der hohen Ubertragungsund 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.

3.6.1

Die ATM-Zelle

Die ATM-Zelle ist eine starre Einheit von 53 Bytes. Sie besteht aus einen 5 Bytes langen Header sowie 48 Bytes Nutzinformation (Payload). Es wird zwischen zwei Arten von ATM-Zellen unterschieden, die sich in der Belegung der Bits 5-8 des ersten Headerbytes unterscheiden: 0

1

2

3

Flow Control (GFC)

4

5

6

7

8 Bit

Channel Identifier

Channel Identifier (VCI) Path Identifier (VPI) Path Identifier

PT

CLP

HEADER CHECKSUM (CRC)

Header einer User Network Interface Zelle Abbildung 3.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 Ubertragungsmedium. Es ist daher nur im Bereich lokaler ATM-Netze von Relevanz und wird von ATMVermittlungsstellen und Cross-Connects am NNI-Interface u ¨berschrieben. Eine Standardisierung zur Nutzung des GFC Feldes steht bislang aus. Zur Adressierung stehen die Felder VPI (Virtual Path Identifier) und VCI (Virtual Channel Identifier) zur Verf¨ ugung. 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 Uberwachung des Systems. Sie ermöglichen die Aufdeckung und Behebung von Fehlfunktionen auf allen ATM-Ebenen. Das Feld CLP (Cell Loss Priority) definiert die Priorität einer Zelle. Bei auftretender ¨ Uberlast an Netzwerkschnittstellen werden Zellen mit niedriger Priorität (CLP=1) zuerst verworfen. Eine Priorisierung bzw. Markierung von Zellen erfolgt, wenn die sie erzeugende

3.7. FDDI

31 PT-Feld 000 001 010 011 100 101 110 111

Bedeutung ¨ Benutzerzelle, keine Uberlast festgestellt, SDU-Type=0 ¨ Benutzerzelle, keine Uberlast festgestellt, SDU-Type=1 ¨ Benutzerzelle, Uberlast festgestellt, SDU-Type=0 ¨ Benutzerzelle, Uberlast festgestellt, SDU-Type=1 Segment-OAM-F5-Zelle End-to-End-OAM-F5-Zelle Reserviert f¨ ur zuk¨ unftiges Lastmanagement Reserviert f¨ ur zuk¨ unftigen Gebrauch Tabelle 3.4: M¨ ogliche Nutzlasttypen von ATM

Anwendung Resourcen in h¨ oherem 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¨ ufsumme werden dabei nur die 32 Bits des Zellheaders (ohne CRCFeld) ber¨ ucksichtigt. Die Bildung einer Headerpr¨ ufsumme 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 3.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 Rech¨ nung, sowie der Tatsache, dass hier eine direkte Zugriffskontrolle auf das Ubertragungsmedium nicht benötigt wird.

3.7

FDDI

F¨ ur Backboneverbindungen in grossen LAN’s kam bis zum Ende der 90er Jahre u ¨blicherweise FDDI (Fiber Distributed Data Interface) zum Einsatz. FDDI erlaubt maximale Kabellängen

32


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¨ ubertragung, bei dem eine Reihe sogenannter Tokens ausgesandt werden. Eine Station darf nur dann ein Paket u ¨ bertragen, wenn sie eines dieser Tokens auffangen konnte. Somit entfällt wie bei TokenRing das Problem der Paketkollisionen.

3.8

Mobilfunknetze

Das Interesse an “Internet u ¨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¨ ur 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 u ¨ber die Mobilfunknetze erst mit der Einf¨ uhrung von UMTS wieder größere Aufmerksamkeit. Mobilfunknetze decken zu fast 100% das Land ab und erlauben damit fast u ¨berall und jederzeit online zu gehen.

3.8.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 u ¨ 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¨ uberhinaus gibt es HSCSD. Dieses belegt f¨ ur 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¨ ur die Lizenz wieder einzusammeln, so ist es jetzt schon f¨ ur den Internet-Zugriff eine ernstzunehmende Alternative. Die erreichbaren Geschwindigkeiten, so eine Zelle verf¨ ugbar und 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¨ ur GPRS und UMTS. Die entsprechenden Netzwerkadapter f¨ ur UMTS beherrschen daher bei¨ de Ubertragungsverfahren.

3.9

Netzwerkadapter fu ¨ r Mobilfunknetze

Wie f¨ ur jedes andere Netzwerk auch, benötigt man einen passenden Netzwerkadapter. Der Adapter f¨ ur Mobilfunknetze kommt u ¨ blicherweise als PCMCIA- oder Cardbus-Karte daher.

¨ MOBILFUNKNETZE 3.9. NETZWERKADAPTER FUR

33

Alle neueren Mobiltelefone bringen GPRS-Unterst¨ utzung 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¨ utzen 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¨ ussen 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¨ usten kann. Die drahtlose Verbindung zwischen den Geräten hat den Vorteil, dass sich das Telefon f¨ ur optimalen Empfang leicht positionieren lässt. Jedoch sorgt Bluetooth gerade auf der Seite des Mobiltelefons daf¨ ur, dass sich dessen Akkulaufzeit oft deutlich reduziert. Ebenfalls sollte man die Datensicherheit im Blick haben. Unter Umständen ist ein Mobiltelefon in einem weiten Umkreis sichtbar. Wenn dann auch noch die Firmware einige gravierende Sicherheitsl¨ ucken 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 u ¨ blicherweise einem halben Meter beschr¨ ankt. Ein weiterer Vorteil: Steckt das Mobiltelefon irgendwo in der Tasche, ist es f¨ ur 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. Altere Mobiltelefone beherrschen nur die serielle, neuere Ger¨ ate auch USB-Verbindungen. Die entsprechenden PC-Gegenst¨ ucke sind eigentlich immer vorhanden. Leider gibt es jedoch kaum Telefone bei denen das Kabel schon beiliegt.

34


Kapitel 4

OSI-Schichtenmodell 4.1

Kategorisierungen

Computernetze sind durchaus komplex aufgebaut. Nicht jede Applikation soll diese Komplexität jeweils nachvollziehen m¨ ussen. 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 u ¨berschaubar. Deshalb ist ein strukturierter Aufbau notwendig. Hierf¨ ur erfolgt die Vereinbarung von Protokollen und die Definition von Schnittstellen. F¨ ur 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.

4.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¨ oglich. Ein Beispiel f¨ ur ein Protokoll ”aus dem täglichen Leben” ist z.B. der Sprechfunkverkehr: Die Kommunikationspartner best¨ atigen 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”. ¨ Ahnliche 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¨ oheren Komplexit¨ at 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.

4.2.1

Hierarchie

Jede Schicht n enth¨ alt Instanzen f¨ ur 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 35

36

KAPITEL 4. 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¨ ur das Senden und Empfangen eines nicht formatierten Bitstroms zuständig ist) die erhaltenen Daten in einen Umschlag steckt, in dem zusätzlich Informationen f¨ ur die korrespondierende Schicht auf der anderen Maschine stecken, die f¨ ur die korrekte Wiederherstellung der Daten nötig sind. Auf der untersten Schicht (Schicht 1) findet die tats¨ achliche 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 u ¨ bergeben. Diese öffnet den Umschlag und stellt mit den darin enthaltenen Informationen die korrekte Nachricht f¨ ur 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.

4.3

Motivation

Der Name des Modells lautet “Open Systems Interconnection”. Dieses Referenzmodell ist als Vorschlag f¨ ur die Standardisierung von Netzwerkprotokollen durch die ISO entstanden. Es wurde etwas sp¨ ater bzw. in gewissem Maße zeitgleich zu TCP/IP vorgeschlagen. Es sollte deshalb eher als theoretisches Konzept denn als technische Leitlinie der Entwicklung von Netzwerkschichten verstanden werden. Layer 7

Name of Unit Application

Application ftp,http,smtp,pop3

6

Presentation

Presentation

A 5

Session

4

Transport

3

Network

Session

TCP, UDP, SPX, Appleshare Transport

IP, IPX, Appletalk Network

Packet

Data link

Frame

N Ethernet-, ATM-Switch 2

Data link

1

Physical

Ethernet, TokenRing, ISDN Physical

Host A

Bit

Host B Real Connection Virtual Connection

A

User-Application

N

Network-Protocol

Flow of Data from A to B

Abbildung 4.1: OSI-Schichtenmodell Kaum ein Protokoll f¨ ur Internets setzt alle Vorschläge des Schichtenmodells um. Trotzdem ist es hilfreich f¨ ur die Strukturierung und Abgrenzung von Netzwerkprotokollen und zum Verständnis f¨ ur die Funktion von Netzwerken.

4.3. MOTIVATION

37

Hardware (-nahe) Protokolle f¨ ur LANs und WANs lassen sich mit OSI erklären und einordnen. Auch die Abbildung der Dienste der TCP/IP-Suite kann innerhalb des OSIModells erfolgen. Die Kommunikation zwischen verschiedenen Hosts läßt sich anhand von OSI gut veranschaulichen. Deshalb wird dieses durchaus immer noch erwähnt bzw. gelehrt. Die sieben Schichten entstammen folgenden Designprinzipen: • Eine Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird • Jede Schicht soll genau definierte Funktionen erf¨ ullen • Bei der Funktionswahl sollte die Definition international genormter Protokolle ber¨ ucksichtigt werden • Grenzen zwischen Schnittstellen so wählen, dass möglichst wenig Informationsfluß u ¨ ber Schnittstellen notwendig wird • Es sind so viele Schichten vorzusehen, dass keine Notwendigkeit besteht mehrere verschiedene Funktionen in einer Schicht zu implementieren Schichten von unten nach oben (d.h. ausgehend von der Hardware hoch zur Applikation) sind in der Tabelle dargestellt. # 7

Schicht

Layer (engl.) Anwendungs- application -

Orientiert

Aufgabe

Anwen-dungs-

Verbindung zwischen Benutzern und deren Tätigkeiten Datenformat des Informationsaustausches Verbindung zwischen Prozessen auf verschiedenen Rechnern Zusammensetzung der Nachrichten Adressierung der Nachrichten zwischen Rechnern Beseitigung von ¨ Ubertragunsfehlern durch Störungen Betrieb der Netzkarten

6

Darstellungs- presentation Anwendungs-

5

Kommunika- session tionssteuer-

Anwendungs-

4

Transport-

Transport-

3

Vermittlungs- network -

Transport-

2

Sicherungs-

data link -

Transport-

1

Bit¨ ubertragungs-

physical -

Transport-

transport -

Prot.

FTP

TCP

TCP IP

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

38


4.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 u ¨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¨ ugung stellt. Die Aufgaben der einzelnen Schichten lassen sich wie folgt beschreiben:

4.4.1

Bitu ¨bertragungsschicht

¨ regelt die Ubertragung von ”rohen” Bits u ¨ber den Kommunikationskanal. Dabei handelt es sich um einen unstrukturierten Bitstrom. Die Bit¨ ubertragungsschicht enthält die Definition, welcher elektrischer, also physikalischer Zustand einer binären ”Null” bzw. einer ”Eins” entspricht. Dazu z¨ ahlt 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¨ urfen, 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¨ ahlt dazu die Festlegung von Kabeltypen und -qualitäten (optisch bzw. elek¨ trisch) oder die Definition von Funkstandards f¨ ur drahtlose Ubermittlung. Bestandteil ist weiterhin die Definition von Steckern und Buchsen, die Anzahl benötigter Adern und die full- oder halfduplex Datenkommunikation.

4.4.2

Sicherungsschicht

u ubertragungsschicht in eine ¨ bernimmt die Umwandlung des rohen Datenkanals der Bit¨ ¨ Leitung, welche virtuell frei von unerkannten Ubertragungsfehlern ist. Dies geschieht durch die Aufteilung des Datenstroms in Frames1 . Dabei erfolgt das Setzen von Rahmengrenzen durch spezielle Kontrollbits. Weiterhin werden einfache Pr¨ ufmechanismen geschaffen z.B. durch die Einf¨ uhrung von CRC-Pr¨ ufsummen. Die Sicherungsschicht erlaubt weiterhin eine ¨ Datenverkehrskontrolle. Sie kann Meldungen von Uberschwemmungen eines Empfängers generieren. Dar¨ uberhinaus regelt sie die Zugriffssteuerung in Broadcastnetzen.

4.4.3

Vermittlungsschicht

sichert die Steuerung des Teilnetzbetriebes. Sie ist sozusagen verantwortlich f¨ ur 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¨ ur jede Sitzung festgelegt werden. Es geht auch noch dynamischer: F¨ ur jedes Paket einer Sitzung wird eine Route generiert. ¨ Bei Uberlastungen der Teilnetze mit zuvielen Paketen muss eine Engpass- bzw. Stausteuerung erfolgen. Dar¨ uberhinaus k¨ onnen Abrechnungsfunktionen2 in dieser Schicht implementiert sein. Die Vermittlungsschicht u ¨berwindet verschiedene Hardwareprotokolle. Sie kann Pakete in die angepaßte Gr¨ oße f¨ ur jedes Teilnetz umbauen. 1

anderer Name f¨ ur Paket, um die Daten”h¨ appchen” der verschiedenen Schichten unterscheiden zu k¨ onnen z.B. f¨ ur die Paketdurchleitung; da kaum ein Anbieter jede End-zu-Endverbindung im eigenen Netz realisieren kann 2

4.5. KONZEPTE

4.4.4

39

Transportschicht

ist f¨ ur die Entgegennahme der Daten aus der Sitzungsschicht verantwortlich. Die Transportschicht regelt gegebenenfalls die geeignete Zerst¨ uckelung 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¨ alt 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¨ ome, da ein Host durchaus mehrere Verbindungen unterhalten kann.

4.4.5

Sitzungsschicht

soll den Benutzern an verschiedenen Maschinen erlauben, Sitzungen miteinander aufzubauen, d.h. einerseits einen gew¨ ohnlichen 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.

4.4.6

Darstellungsschicht

realisiert Funktionen, die sich mit Syntax und Semantik der u ¨ bertragenen Informationen beschäftigen. Hierzu z¨ ahlt die Kodierung der Daten auf vereinbarte Weise3 . In der Darstellungsschicht erfolgt die Umwandlung spezieller Daten- und Objektstrukturen eines Rechners in die f¨ ur die Netz¨ ubertragung geeignete Form.

4.4.7

Verarbeitungsschicht

wird in einigen Darstellungen auch Anwendungsschicht genannt. Sie bezieht sich auf die letztendlich auf einem Host ablaufenden Netzwerk-Applikationen. Diese können z.B. eine einheitliche Terminalemulation4 umfassen, die eine Vielzahl sehr unterschiedlicher Terminaltypen darstellen kann. Damit wird anderen Programmen (und deren Programmierern) die Ausgaben von Text und die Entgegennahme von Tastatureingaben erleichtert. Weiterhin k¨ onnte die Verarbeitungsschicht den Dateitransfer u ¨ ber verschiedene Standards von Dateisystemen und Namenskonventionen hinweg organisieren. Diese Erörterungen lassen sich ebenso auf Email-, Webdienste etc. anwenden.

4.5

Konzepte

F¨ ur den Zusammenschluss verschiedener Netze sind spezielle Hardwarekomponenten not¨ wendig. Diese regeln die Uberg¨ ange zwischen verschiedenen Teilnetzen und Netzwerktechnologien, die sich sowohl im Medientyp, den Adressierungsschemata und den Frameformaten unterscheiden k¨ onnen. 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¨ ate an Workstations oder Mainframes gemeint.

40


Diese Hardwarekomponenten k¨ onnen wie Hosts mit mindestens zwei Interfaces aufgefaßt werden. Sie sollen sich wie ein Host5 im jeweiligen Teil-Netz verhalten, wobei die Zahl von ¨ Uberg¨ angen zwischen verschiedenen Netzwerken möglichst nicht begrenzt sein sollte. Hierf¨ ur 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, d.h. Soft- und Hardwarelösungen bilden eine Illusion eines gemeinsamen u ¨ bergreifenden Netzes

4.5.1

Protokolle

”Protokoll” dient als gemeinsame Vereinbarung (Standard) u ¨ber die Kommunikationsparameter. Es wurden verschiedene Protokolle f¨ ur 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¨ ur WAN-Technologien, Angebot von Telefongesellschaften Diese Protokolle besitzen Routingf¨ ahigkeit, d.h. verschiedene Netze können u ¨ber spezielle Rechner (Router) miteinander gekoppelt werden. Sie bieten einen einheitlichen bzw. ”globalen” Adressraum und sind f¨ ur verschiedene Netzwerkhardware verf¨ ugbar. Andere Protokolle, z.B. NetBIOS von Microsoft, sind nur im LAN einsetzbar, weil sie u ¨ber kein globales Adressschema verf¨ ugen, nicht routingf¨ ahig sind und nur auf bestimmte Netzwerkhardware anwendbar sind. Mit der Ausdehnung der Firmennetze, dem Ausbruch des Rechners aus dem Rechenzentrum und der Popularisierung von Computern spielen Netzwerke eine immer größere Rolle. Deshalb wurde ein allgemein standardisiertes, nichtproprietäres Netzwerkprotokoll gesucht, welches gleichzeitig die Unabh¨ angigkeit 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.

4.6

Einordnungen

Nach dem Aufbau eines Theorieger¨ ustes 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¨ ur die Umsetzung bestimmter Aufgaben benötigt werden. 5

einfaches Mitglied in einem Netzwerk

4.7. AUFGABEN

41

Ethernet, TokenRing, ADSL, ISDN oder Modem definieren in erster Linie verschiede¨ ne Typen von Bit¨ ubertragungsschichten. Sie stellen die Ubertragungsstandards, 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¨ ur beste Erkennung und h¨ ochste 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¨ aßt sich der Vermittlungsschicht zuordnen. Es u ¨bernimmt die Paketadressierung der End-zu-End-Zustellung und implementiert die Routingfunktionalitäten. IP kann dabei auf austauschbare Bit¨ ubertragungs- bzw. Sicherungsschichten zur¨ uck¨ greifen. Es kann u ¨ber Ethernet, GPRS, ADSL, ISDN oder Modem ohne Anderungen im Protokoll arbeiten. Dabei nimmt es evtl. Paketgrößenanpassungen vor. Dies geschieht durch die Steuerung der Paketfragmentierung auf dem Weg und durch den Zusammenbau im Zielhost. Der Weg eines Paketes von Rechner A zu Rechner B durch ein Netzwerk liesse sich im OSI-Modell wie folgt veranschaulichen. Weg eines Datenpaketes von Host A zu B über einen Router Schicht

7

6

5

4

3

2

1 Host A

Eth-HUB

Router

Switch

Host B

Abbildung 4.2: Weg eines Paketes durch OSI-Schichten

4.7 4.7.1

Aufgaben OSI

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

Carrier Sense Multiple Access with Collision Detection bzw. Collision Avoidance

42

KAPITEL 4. OSI-SCHICHTENMODELL 2. Warum kann es passieren, dass einzelne Schichten vielfach nochmal unterteilt wurden? 3. Was sind Gr¨ unde um geschichtete Protokolle zu verwenden? 4. Ein System verwendet eine n-Layer Protokollhierarchie. Eine Applikation generiert eine Nachricht von der L¨ ange N Bytes. Auf jeder Schicht wird ein H Byte langer Header angef¨ ugt. Welcher Anteil der Netzwerkbandbreite wird allein durch die Headerinformation belegt? 5. Welche OSI-Schicht handelt die folgenden Aufgaben ab: a) Aufteilung des zu u ¨ bertragenden Datenstroms in Frames und b) festzustellen, welche Route durch das Netzwerk benutzt werden soll?

4.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¨ ogerung zusammen? Annahme: Pakete bewegen sich entlang einer festgelegten Route.

Kapitel 5

TCP-IP 5.1

Schaffung von ”Inter-Nets”

In den bisherigen Abschnitten erfolgte die Einf¨ uhrung in das Thema Netzwerke, in die Konzepte der paketorientierten Daten¨ ubertragung, der Signalisierung und der Kodierung. Als Protokolle der Hardwareebene wurden Ethernet und sehr kurz aus historischen Gr¨ unden TokenRing besprochen. Diese Netzwerkhardware wird u ur Local Area Net¨ berlicherweise f¨ works verwendet, da die u uckbaren Entfernungen nur wenige einhundert Meter und ¨ berbr¨ mit optischen Medien nur wenige Kilometer betragen. Ethernet 10Base-T

803.11a #2

192.168.2.0/22

#1 Router 2

Ethernet 1000Base-X ATM over ADSL

Internet

ATM over ADSL #1

192.168.6.0/24

#3

Router 1 #2

Router n

Ethernet 100Base-T

#2 #1

FDDI

Router 3

TokenRing 192.168.1.0/24 192.168.10.0/24

172.16.1.0/24

Abbildung 5.1: IP als Universalservice F¨ ur Weitverkehrsnetze greift man auf u ¨berall verbreitete Telefonnetze in ihrer analogen oder digitalen Auspr¨ agung zur¨ uck. Dann kommt entweder ein Modem oder ein ISDNAdapter als Netzwerkanschluss zum Einsatz. Auf diese Weise lassen sich verschiedene Hardwareausprägungen f¨ ur die Paket¨ ubertragung nutzen. Jedoch besteht dadurch auch ein Problem: Ethernet ist zwar f¨ ur fast alle Medientypen implementiert1 aber z.B. nicht f¨ ur ZweiDraht-Verbindungen f¨ ur weite Entfernungen. Die WAN-Techniken, wie z.B. ISDN und analoges Modem eignen sich kaum f¨ ur die Vernetzung vieler Maschinen bzw. Komponenten. ISDN und Modem k¨ onnen weite Entfernungen realisieren, bieten aber nur Punkt-zuPunkt-Verbindungen zwischen jeweils zwei dedizierten Interfaces2 . Verschiedene physikali1

Es existieren jeweils Standards f¨ ur Koaxialkabel (10Base5 ThickEthernet/Yellow-Cable bzw. 10Base2 f¨ ur Cheapternet), TwistedPair-Kabel (4 bzw. 8 adrig), Lichtwellenleiter, Funkwellen im 2.4 GHz-Bereich 2 In den typischen Einwahlsituationen von Internet-Providern handelt es sich dabei um spezielle Hardware, welche eine große Anzahl von Netzwerkinterfaces in einer Maschine vereint.

43

44

KAPITEL 5. TCP-IP

sche Netze sind unumg¨ anglich, da keine Technologie sich f¨ ur alle Einsatzszenarios eignet. Weiterhin sind Trennungen an bestimmten ”Grenzen”, wie abgeschlossene Firmen- oder Abteilungsnetze durchaus gew¨ unscht und aus Sicherheitsgr¨ unden notwendig. Deshalb wird ein ”Universaldienst” geschaffen, welcher Verbindungen zwischen beliebigen Rechnern erlaubt. Dabei soll die Kommunikation u ¨ ber unterschiedliche Entfernungen, durch unterschiedliche Netze (LAN oder WAN) und u ¨ber verschiedene Medien realisierbar sein. Virtuell soll jede Verbindung f¨ ur die kommunizierenden Maschinen ”gleich” aussehen, d.h. es sollen keine anderen Applikationen oder Protokolle in Abhängigkeit davon verwendet werden m¨ ussen, ob sich die Maschinen im gleichen LAN befinden oder u ¨ber Kontinente hinweg Daten austauschen. Dabei soll keine Entscheidung f¨ ur eine bestimmte Technologie3 getroffen werden, sondern ein Universalnetz u ¨ ber mehrere heterogene Netze hinweg geschaffen werden. Ein solcher Universaldienst wird als ”Inter-Net” bezeichnet.

5.2

¨ Uberblick u ¨ ber TCP/IP

Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In den nun folgenden Abschnitten soll nun das Referenzmodell f¨ ur die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen TCP und IP der Netzarchitektur, beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSIReferenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI-Standardisierung eingeflossen. Als Ziele der Architektur wurden bei der Entwicklung definiert: • Unabhängigkeit von der Architektur der Hostrechner. • Universelle Verbindungsm¨ oglichkeiten 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¨ oherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen SSH (f¨ ur virtuelle Terminals), FTP (Da¨ teitransfer), SMTP (zur Ubertragung 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 Internet u ¨bermittelt werden kann. UDP ist ein unzuverlässiges verbindungsloses 3

Netzwerkhardware mit bestimmten darauf laufenden hardwarenahen Protokollen

¨ ¨ 5.2. UBERBLICK UBER TCP/IP

45

Protokoll, das vorwiegend f¨ ur Abfragen und Anwendungen in Client/Server- Umgebungen verwendet wird, in denen es in erster Linie nicht um eine sehr genaue, sondern schnelle Da¨ ten¨ ubermittlung geht (z.B. Ubertragung von Sprache und Bildsignalen). Diese Protokolle werden gleich noch ausf¨ uhrlicher 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 Ubertragung von Diagnose- und Fehlerinformationen f¨ ur das Internet Protocol.

Netzwerkschicht (network layer): Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionsl¨ ucke. Das Referenzmodell sagt auf dieser Ebene nicht ¨ viel dar¨ uber aus, was hier passieren soll. Festgelegt ist lediglich, daß zur Ubermittlung von IP-Paketen ein Host u ¨ ber ein bestimmtes Protokoll an ein Netz angeschlossen werden muß. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B. Ethernet (IEEE 802.3), PPP, etc. SSH

FTP

HTTP

Transmission Control P. (TCP)

DNS

DHCP

User Datagram Protocol (UDP)

Internet Protocol (IP) ICMP / ARP

Ethernet

ATM

FDDI

Modem

Application Layer

Transport Layer

Internet Layer

ISDN

Network Layer

Abbildung 5.2: Der TCP/IP-Protokoll-Stapel Um Datenpakete im großen Umfang und möglichst schnell an verschiedenste Empfänger schicken zu k¨ onnen, 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¨ arformat (denn Host- und Domänennamen zu analysieren kostete zuviel Zeit!) Maschinen-intern entsprechen dem u ¨blichen, dezimalen Format der IPAdressen (a.b.c.d) pro Zahl 8-bits. IP-Adressen sind also insgesamt 32-bit lang, wobei die Unterteilung in 8 bit Bl¨ ocke nur der Lesbarkeit halber eingef¨ uhrt wurde. Dieses Format wird auch Dotted Quad Notation genannt: 192.168.22.3 entspricht 11000000.10101000.00010110.00000011 In dieser simplen Form kann die Adresse von sehr primitiven und enorm schnellen LogikBausteinen analysiert werden und sehr schnell mit Netzmasken und Broadcastadressen zum Routing berechnet werden.

46

KAPITEL 5. TCP-IP

5.3

Design

F¨ ur 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 u ¨ 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¨ uhrt wird, laufen. Das Adressierungsschema bildet dabei die zentrale Komponente der Abstraktion. Zum einen können die physikalischen Adressen nicht ausreichen,4 zum anderen können sie sehr unterschiedliche Schemata5 verwenden. Die Zustellung von IP-Paketen erfolgt analog zur Zustellung von Frames auf Hardwareebene. Die Adressierung der virtuellen Ebene läßt sich gut mit der physikalischen Adressierung vergleichen. Der Host tr¨ agt die Zieladresse in den Header6 des zu verschickenden Datenpaketes ein und vermerkt seine eigene Adresse als Absenderkennung. Das Zielsystem, welches durchaus ein Zwischenziel in Form eines Routers auf dem Weg eines Datenpaketes ¨ sein kann, u uft die Adresse auf Ubereinstimmung mit der eigenen. Anhand dieser wird ¨ berpr¨ 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¨ ur 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¨ angig von der verwendeten Hardware ein einheitliches Adressschema verwenden. Die Beschr¨ ankung auf Ethernet verbietet sich allein schon wegen der begrenzten Kabellängen im LAN. Der Hauptvorteil von IP besteht also darin, dass es physikalisch verschiedene Netzwerke zu einem scheinbar homogenen Netzwerk zusammenfaßt. Die Zusammenarbeit verschiedener Netze wird als ”Internetworking” bezeichnet, die Kommunikation verläuft u ¨ 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¨ uckgrat (wie der Name Backbone ja schon sagt) des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher Bandbreite und schnellen Routern gebildet. An die Backbones sind wiederum größere regionale Netze an4

Obwohl das MAC-Adressierungsschema des Ethernets z.B. mit 248 mehr Adressen umfaßt als das Internet-Protokoll der Version 4. Hier besteht jedoch die Schwierigkeit, dass die Adressen fest mit einem Netzwerkadapter verkn¨ upft sind, d.h. eine beliebige Abstraktion nicht m¨ oglich ist. 5 Die Zuordnung von Modem- oder ISDN-Leitungen k¨ onnte z.B. anhand der Telefonnummer erfolgen, TokenRing und Ethernet verwenden MAC-Adressen. 6 speziell gekennzeichneter Kopf eines Datenpaketes, welcher keine Nutzdaten enh¨ alt, sondern Zustellvermerke speichert

5.4. INTERNET PROTOCOL (IP)

47

geschlossen, die LANs von Universit¨ aten, Behörden, Unternehmen und Service-Providern verbinden. ¨ IP stellt die Basisdienste f¨ ur die Ubermittlung 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¨ uhen (”best effort”) von der Quelle zum Ziel bef¨ ordert, unabh¨ angig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enth¨ alt keine Funktionen f¨ ur die Ende-zu-Ende-Sicherung oder f¨ ur die Flußkontrolle. Das Internet-Protokoll muss eine Reihe von Aufgaben erf¨ ullen, um eine End-zu-EndZustellung von Datenpaketen zu gew¨ ahrleisten. Dazu zählt die Definition von Datagrammen, welche die Basiseinheiten zur Daten¨ ubermittlung in Internets bilden. Weiterhin wird das bereits angesprochene Adressierungsschema benötigt. Eine weitere Aufgabe besteht in der ¨ Ubermittlung der Daten von der Transportschicht zur Netzwerkschicht.7 Die Datagramme m¨ ussen 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¨ ussen Mechanismen zur Verf¨ ugung 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¨ ur die Ubermittlung von Daten im Internet bilden. • Definition des Adressierungsschemas. ¨ • Ubermittlung 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 u ¨blicherweise durch vier Dezimalzahlen, eine f¨ ur jeden 8-Bit-Anteil, die durch Punkte voneinander getrennt sind. IP ist ein verbindungsloses Protokoll, d.h. zur Daten¨ ubertragung wird keine Ende-zuEnde-Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein unzuverlässiges Protokoll, da es u ugt. Un¨ber keine Mechanismen zur Fehlererkennung und -behebung verf¨ zuverlässig bedeutet aber keinesfalls, dass man sich auf das IP Protokoll nicht verlassen kann. Unzuverl¨ assig bedeutet in diesem Zusammenhang lediglich, dass IP die Zustellung der Daten nicht garantieren kann. Sind die Daten aber beim Zielhost angelangt, sind diese Daten auch korrekt. 7

Das zugeh¨ orige OSI-Schichtenmodell ist Thema eines eigenen Kapitels

48

KAPITEL 5. TCP-IP

5.5

Spezifikation

5.5.1

IPv4-Standard

Mit den erfolgten Design¨ uberlegungen 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¨ ur 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¨ ugt damit u ¨ 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¨ afixes bedeutet verschiedene Netze; Gleiches Pr¨ afix 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 u ufen. Neben der Erreichbarkeit von Rechnern gibt es ¨ berpr¨ eine weitere Funktion f¨ ur 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¨ urzeren Weg gibt. Weil dieses aber stark in die Funktionen des Hosts eingreift, ist das Ganze mit Vorsicht zu geniessen. In einigen F¨ allen 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¨ ur die Protokollsoftware ist die Bin¨ ardarstellung entscheidend, nur in dieser kann eine effiziente Analyse der Adressen erfolgen. Jedoch besitzt diese auch Nachteile: F¨ ur Menschen, die diese Adressen in ihren Applikationen verwenden, ist die Binärnotation schwer lesbar und Verwechselungen leicht m¨ oglich. Deshalb f¨ uhrt man die sogenannte Dotted-Quad-Notation ein. Die IP-Adresse wird in vier Byte-Bl¨ ocke aufgeteilt, z.B. 11000000.10101000.00011001.11111110. Die PunktDezimal-Notierung liefert dann eine f¨ ur das menschliche Auge leicht erfassbare, Darstellung. Im Beispiel bleibend schreibt sich die genannte IP-Adresse nun: 192.168.25.254. Jeder Block besteht dabei aus einem vorzeichenlosen Ganzzahlwert im Bereich 0 - 255.

5.5. SPEZIFIKATION

5.5.3

49

Adressbereiche

Der gesamte IP-Adressbereich erstreckt sich damit von Adresse 0.0.0.0 bis 255.255.255.255. In der Binärdarstellung bedeutet dieses die Spannbreite von allen 32 Stellen ”Null” gesetzt bis zu allen Stellen ”Eins” gesetzt. Die zuteilende Stelle f¨ ur IP-Adressen bzw. -Bereiche muss f¨ ur jeden Adressanteil die Zahl der Bits festlegen, welche f¨ ur das Präfix bzw. das Suffix reserviert werden. 8 bits

8 bits

8 bits

8 bits

host

host

host

network

host

host

network

network

host

D 11 10

multicast

multicast

multicast

E 11 11

experi mental

experi mental

experi mental

Class A 0

network

B 10

C

net work

11 0

net work

Abbildung 5.3: Adressbereiche des IPv4 Die Zuordnung von einer gr¨ oßeren Zahl von Bits in einem Bereich bedeutet automatisch die Verf¨ ugbarkeit 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 u ¨ 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¨ unglich festgelegte Adressraum erschien gross genug um alle damaligen Anforderungen abdecken zu können8 . Weiterhin sollten IP-Adressen selbstbezeichnend sein, d.h. ohne weitere Angaben sollte die Netzgr¨ oße, d.h. die Anzahl maximal enthaltener Hosts als Information bereits beinhaltet sein. Die fr¨ uhe 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 u ¨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¨ atzte die Weiterentwicklung bei weitem nicht so st¨ urmisch ein, wie sie sp¨ ater erfolgen sollte.

50

KAPITEL 5. TCP-IP Bezeichnung Class A Class B Class C

Pr¨ afix 7 bit 14 bit 21 bit

Suffix 24 bit 16 bit 8 bit

Netze 128 16.38 2.097.152

Hosts pro Netz 16.777.216 65.536 256

Tabelle 5.1: Aufteilung der IP-Adressklassen

5.5.4

Spezielle IP-Adressen

Besondere Adressierungen sollen im gemeinsamen Adressraum abgebildet werden. Deshalb wurde eine Reihe von Spezialadressen definiert. Dazu zählen die Netzwerkadressen: Um den Netzen einen ”Namen” zu geben, d.h. um sie direkt ansprechen zu können, erhalten diese Adressen im Prefix die Netzwerk-Nummer und im Suffix Nullen. F¨ ur den direkter Broadcast, d.h. um alle Rechner in einem gemeinsamen physikalischen Netz eine Nachricht schicken zu k¨ onnen, 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¨ oglichkeit haben, die Adresse irgendwo abzulegen. Dieses gilt auch f¨ ur mobile Maschinen, die zwischen verschiedenen Netzen wechseln. Die ”Loopback Address” bietet eine auf jeder Maschine einheitliche Adresse. Viele Programme verwenden zur Kommunikation TCP/IP, selbst wenn die Maschine nicht an ein Netzwerk angeschlossen ist. Zur schnellen IP-Kommunikation innerhalb der Maschine ist als höchstes das Class-A Netzwerk9 definiert. Dieses erscheint aus heutiger Sicht durchaus als Verschwendung, da in einem solchen Netz mehrere Millionen Rechner Platz finden. Router erhalten auch IP-Adressen obwohl sie selten Applikationen zur Host-zu-HostKommunikation ausf¨ uhren. Sie haben Verbindung in verschiedene physikalische Netze und m¨ ussen 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¨ at 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¨ ullt. So beschreibt die spezielle IP-Nummer, z.B. 192.168.20.0 ein Klasse-C-Netzwerk mit max. 254 Teilnehmern. Broadcastadresse f¨ ur einen direkten Broadcast, d.h. ein Datenpaket an alle Teilnehmer eines Teilnetzes, besteht aus dem Pr¨ afix mit Einsen am Ende, die den Hostteil auff¨ ullen. Im o.g. Beispiel w¨ are dieses die spezielle IP-Nummer 192.168.20.255. 9

127.0.0.0

5.5. SPEZIFIKATION

51

Defaultrouter heißt der Standard¨ ubergang 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¨ onnte 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¨ aren Nullen endet. Der Ubergang bezeichnet die Grenze zwischen Prä- und Suffix und sollte eindeutig sein. F¨ ur 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¨ ur Netze mit nur einem Rechner besteht ausschliesslich aus ”Einsen”, die Netzwerkmaske f¨ ur das gesamte Internet nur aus ”Nullen”. 0.0.0.0 bezeichnet deshalb die Defaultroute. Weiterhin lautet die Netzwerkmaske z.B. f¨ ur 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¨ andliche Darstellung mit der Angabe der Anzahl der ”Einsen” in ihrer jeweiligen Darstellung abgek¨ urzt. Klasse Class A Class B Class C

Beispiel 10.0.0.0 132.230.0.0 192.168.20.0

Anzahl der Einsen 8 16 24

Tabelle 5.2: Kurzdarstellung f¨ ur Netze Wenn man classless Routing einf¨ uhrt, 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¨ urlich versucht sein, kompliziertere Muster von Netzmasken zu bauen und statt ein Klasse C-Netz in der Mitte zu teilen, entlang der geraden und ungeraden IP-Nummern spalten. Dieses trägt jedoch extrem dazu bei, Routingtabellen nicht mehr durchschauen zu können und sei daher nur dem erfahrenen Netzwerkadministrator als Option genannt. Weiterhin wird man sich nicht immer darauf verlassen können, dass jede TCP/IP-Implementation sauber mit dieser Art von Netzmasken umgehen kann.

5.5.5

Private IP-Adressen

Der gesamte Adressbereich 127.b.c.d ist dem Loopback-Netz10 zugeordnet, dabei handelt es sich um ein per Software simuliertes Netz. Einzige Maschine auf diesem loopback-Netz ist die eigene; evtl. mit verschiedenen Namen. Die Adresse 127.0.0.1 bezieht sich stets auf die eigene Maschine; sie kann zu keinen anderen Zwecken gebracht werden, als zur Definition des ”das sind wir selbst”. Die Adresse a.b.c.0 ist f¨ ur das lokale Netz (Netz”name”) reserviert. Die Adresse a.b.c.255 ist f¨ ur Nachrichten ”an alle” (Broadcast) reserviert11 . Folgende Adreßbereiche sind zum Aufbau privater, nicht mit dem Internet verbundener Netzwerke freigegeben: • 10.0.0.0 - 10.255.255.255 10

siehe hierzu die Anmerkungen im vorherigen Abschnitt Das Beispiel bezieht sich auf ein Class-C Netzwerk, bei einem Class-B s¨ ahe die der Netzname wie a.b.0.0 und die Broadcastadresse wie a.b.255.255 aus. 11

52

KAPITEL 5. TCP-IP • 172.16.0.0 - 172.31.255.255 • 192.168.0.0 - 192.168.255.255

Diese Adressen werden im Internet nicht geroutet (d.h. die Pakete werden spätestens am Router des eigenen LAN zum Internet wegegeworfen).

5.6

Der IP-Header

IP hat mehrere Aufgaben, daf¨ ur werden einige Informationen benötigt: Die Quell- und Zieladresse; Informationen zum Weiterreichen an die höhere Netzwerkschicht; Fragmentierung12 ; ”Verfallsdatum”13 ; L¨ ange des Pakets und die Pr¨ ufsumme. 32 bit

VERS.

IPHL

TYPE OF SERV. D M F F

IDENTIFICATION TIME TO LIVE

TOTAL LENGTH

PROTOCOL

FRAGMENT OFFSET HEADER CHECKSUM

SOURCE ADDRESS DESTINATION ADDRESS OPTIONS (ZERO OR MORE WORDS)

Abbildung 5.4: IP Paket-Header Die einzelnen Header-Bestandteile: • Version (4 bit) - Die Versionsnummer steht f¨ ur die zu verwendende IP-Protokollversion. Derzeit u ¨blicherweise verwendet wird IPv4. • H-Länge (4 bit): Die Header-L¨ ange gibt an, wie viele 32 bit-Zeilen der gesamte IPHeader besitzt. Dadurch, dass das Optionen-Feld unterschiedlich lang werden kann, ist es sinnvoll zu wissen, ab wo das Protokoll der nächst höheren Schicht beginnt. • Service-Type (8 bit): Das TOS-Feld (Type of Service) bestimmt, um welche Art von Daten es sich bei diesem Datagramm handelt. Diese Information ist hauptsächlich zu Zeiten von u utzlich. Hier macht es Sinn die Anwen¨ berlastetem Netzwerkverkehr n¨ dungsart (HTTP-Typ, FTP-Typ,...) der Daten zu wissen, um entsprechende Prioritäten beim Transport der Datagramme u ¨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 u ¨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¨ agt, ist es Dritten durchaus möglich verschiedene Maschinen hinter einem Masquerading-Router zu identifizieren. 12 13

nicht alle darunterliegenden physikalischen oder logischen Netze haben die gleichen Eigenschaften Unzustellbare Pakete m¨ ussen irgendwann das Netz wieder verlassen - also entsorgt werden

5.7. IP-ROUTING

53

• Flags (3 bit): Flags werden f¨ ur 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¨ ugt 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): Hier wird angegeben, um welches Protokoll es sich in der nächsth¨ oheren Schicht, also der Transportschicht, handelt. Ein Wert von 6 bedeutet, dass das TCP-Segment u ¨ 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¨ ufsumme (16 bit): Dieses Feld besitzt dieselbe Funktion wie das Pr¨ ufsummen-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¨ ufsumme berechnet wird. Ein offensichtlicher Grund daf¨ ur ist, dass sowohl auf der Vermittlungsschicht als auch auf der Transportschicht andere, wenn auch nicht häufig verwendete Protokolle existieren, die keine Pr¨ ufsummenberechnung durchf¨ uhren, so dass es sinnvoll sein kann, die ¨ Uberpr¨ ufung der Korrektheit mittels der Pr¨ ufsummenberechnung auf beiden Schichten durchzuf¨ uhren. • Quell-IP-Adresse (32 bit): Gibt an, von welcher IP-Adresse das Datagramm urspr¨ unglich 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¨ onnen nicht mit beliebigen Datagrammgrößen hantieren. Jedes Netzwerkteilst¨ uck besitzt deshalb eine maximale Datagrammgröße MTU (Maximal Transmission Unit). Die Router, die Datagramme zu diesen Routern senden, m¨ ussen also stets u berpr¨ u fen, ob die Gr¨ o ße der zu sendenden Datagramme die MTU der empfangenden ¨ Router nicht u ¨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¨ ugt werden muss. Beim letzten Fragment ist das Fragment-Flag gelöscht, um anzuzeigen, dass keine weiteren Fragmente mehr folgen.

5.7

IP-Routing

Eine entscheidende Aufgabe des Internet-Protkolls ist die Verbindung verschiedener Teilnetze untereineinder. Hierzu muss es eine geeignete Paketweiterleitung implementieren. Diese

54

KAPITEL 5. TCP-IP

wird als Routing bezeichnet. Zur Einordnung sei wiederholt, dass IP ein verbindungsloses paketorientiertes Protokoll ist, welches definiert wurde, um die exklusive Belegung eines Datenkanals zu verhindern. Erst auf dar¨ uberligenden Schichten kann der Nutzer entscheiden, ob er verbindungsorientierte oder -lose Kommunikation w¨ unscht. TCP arbeitet verbindungsorientiert, UDP schafft einen einfachen Datagrammrahmen, der direkt auf IP aufsetzt. Die Weiterleitungsentscheidung erfolgt beim Internet-Protokoll f¨ ur jedes einzelne Paket neu. Damit das Routing m¨ oglichst effizient erfolgen konnte, sollten IP-Adressen selbsterklärend sein, d.h. sie besitzen ein Pr¨ afix zur Netzwerkkennung. Mit dem Suffix wird der Host im Teilnetz identifiziert. Deshalb erfolgte urspr¨ unglich eine Klasseneinteilung des gesamten IP-Adressraumes in Klassen. Die Klassen A bis C definierten dabei g¨ ultige Adressen mit fest vorgegebenen Pr¨ a- und Suffixl¨ angen. Spezielle Adressen werden f¨ ur die Netzwerkkennung eingef¨ uhrt. 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¨ oglich.

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 u ¨ ber den Router (sonst unnötige Belastung und Verz¨ ogerung) Begrenzung der ”Reichweite” der Datenpakete auf das kleinst-mögliche Teil-Netz (aus Sicherheitsgr¨ unden und zum Schutz anderer Teil-Netze vor unnötiger Belastung) Die Einstellungen zum Umsetzen dieser Ziele sind: Bezeichnung networkaddress subnet-mask ip-address

Beschreibung Adresse des eigenen Teil-Netzes, Vergleich mit IPAdresse gibt an, ob ein Datenpaket zum lokalen Netz geh¨ ort oder nicht Bitmaske zum Herausstanzen der Netzwerk- Adresse aus der IP-Adresse einer Maschine Eigene Adresse der Maschine

Tabelle 5.3: Abgrenzung der ”Reichweite” des lokalen Netzes

address 192.168.25.3

11000000.10101000.00011001.00000011

netmask 255.255.255.0

11111111.11111111.11111111.00000000

network 192.168.25.0

11000000.10101000.00011001.00000000

In diesem Beispiel bilden alle 254 Maschinen mit der Adresse 192.168.25.N ein gemeinsames Netzwerk. Dar¨ uberhinaus gibt es noch die ”broadcast-address”, die eine Adresse f¨ ur Nachrichten ”an alle” in diesem Teil-Netz ist. Rechnet man die Netzadresse14 und die Broadcast-Adresse15 hinzu, kommt man f¨ ur ein Class-C-Netz, wie hier dargestellt, auf 256 8 IP-Adressen (= 2 ). 14 15

die kleinste Adresse im Teilnetz, dieses ist eine nicht vergebbare IP! die gr¨ osste Adresse im Teilnetz, auch diese IP sollte nicht f¨ ur Rechner vergeben werden!

5.7. IP-ROUTING

5.7.2

55

Routing (Die Wege im Netz)

Der Datenverkehr findet zwischen den Netzwerkschnittstellen der Internet-Rechner statt. Ein Linux-PC kann mehrere Netzwerkschnittstellen besitzen und als Vermittlungsstelle zwischen verschiedenen Netzen (Router) dienen. Dann kann es jedoch notwendig sein, die Routing-(d.h. Paketforwarding-)F¨ ahigkeit des Kernels einzuschalten. Dieses kann f¨ ur jedes Interface einzeln definiert werden. Der Name einer Netzwerkschnittstelle hängt von der verwendeten Netzwerktechnik ab (nicht etwa vom Hersteller der Einsteckkarte, wie bei anderen Systemen). Der Befehl route zeigt an, wie der Betriebssystemkern Datenpakete an die verschiedenen Empfänger verschickt: shuttle:~/ > /sbin/route -n Kernel IP routing table Destination Gateway 10.1.1.11 10.2.13.254 10.8.4.0 0.0.0.0 10.2.13.0 0.0.0.0 127.0.0.0 127.0.0.1 0.0.0.0 0.0.0.0

Genmask 255.255.255.255 255.255.255.0 255.255.255.0 255.0.0.0 0.0.0.0

Flags UGH U U UG U

Metric 0 0 0 0 0

Ref 0 0 0 0 0

Use 0 0 0 0 0

Iface wlan0 eth0 wlan0 lo tun0

Alle gerade aktuellen Routen im Einzelnen kann man sich mit route -C anzeigen lassen. Diese Liste wird aber in gr¨ osseren Netzen bzw. auf Gatewayrechnern sehr schnell sehr lang werden. Informationen zum Routing können auch mit den Kommandos ip route oder netstat -r erhalten werden. Jedes dieser Programme greift dabei auf das Kernel-ProcInterface zu. Eine klassische Konfiguration sieht wie angezeigt aus: Es ist das lokale Ethernet definiert, in dem alle teilnehmenden Systeme ohne Router/Gateway erreicht werden können. Alles was in diesem Bereich nicht zugestellt werden kann, wird dem Defaultrouter zur weiteren Zustellung u ¨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¨ uber definierten Routingeintrag bekannt gemacht worden sein (Mitglied im entsprechenden Subnetz sein), da es sonst nicht erreicht werden kann! So gen¨ ugt 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¨ anger einschlagen, z.B. zu traceroute www.heise.de: shuttle:~ # traceroute www.heise.de traceroute to www.heise.de (193.99.144.85), 30 hops max, 40 byte packets 1 10.1.1.11 4.992 ms 4.318 ms 6.315 ms 2 132.230.120.142 8.262 ms 10.373 ms * 3 nsc-rz-gwn.fun.uni-freiburg.de (132.230.0.141) 7.938 ms 7.307 ms \ 7.639 ms 4 Freiburg1.Belwue.DE (129.143.15.141) 7.641 ms 9.846 ms 10.699 ms 5 Stuttgart1.BelWue.DE (129.143.1.7) 17.109 ms 17.503 ms 17.258 ms 6 Frankfurt1.belwue.de (129.143.1.26) 20.153 ms 20.314 ms 21.000 ms 7 de-cix.ffm.plusline.net (80.81.192.132) 20.998 ms 20.211 ms \ 20.627 ms 8 heise2.f.de.plusline.net (213.83.57.57) 14.674 ms * 13.516 ms

56 9 10

KAPITEL 5. TCP-IP * heise2.f.de.plusline.net (213.83.57.57) 13.433 ms 13.599 ms * * heise2.f.de.plusline.net (213.83.57.57)(N!) 13.537 ms

Ein weiteres Tool, auch zur grafischen Visualisierung, ist mtr, ”My Traceroute”. ”Router” leiten Datenpakete an entfernte Maschinen und sorgen f¨ ur den Datenaustausch zwischen Teilnetzen. U.U. m¨ ussen die Pakete bis zum Ziel u ¨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¨ ussen manuell u ¨ ber das Kommando route erfolgen, was f¨ ur den obigen Fall (ungek¨ urzt) so aussehen w¨ urde: 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¨ ochte, k¨ onnen 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¨ otigt eine eigene IP-Nummer, z.B. 192.168.20.2. Dieses ist eine g¨ ultige Adresse aus dem Bereich des genannten Beispielnetzes von 192.168.20.1 - 192.168.20.254. Insgesamt k¨ onnen 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 u uft, ob bestimmte Adressen bereits vergeben wurden. F¨ ur die dynamische Zuweisung ¨ berpr¨ 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¨ alt Routingtabelle. Diese fällt je nach Zahl der Interfaces und angeschlossenen Netzwerke unterschiedlich komplex aus. Netzwerk 192.168.20.0 127.0.0.1 0.0.0.0

Netzmaske 255.255.255.0 255.0.0.0 0.0.0.0

Router-IP 192.168.20.254

Interface Ethernet, TokenRing, ... Loopback-Interface Defaultroute

Tabelle 5.4: Routingtabelle eines Hosts Die Defaultroute dient f¨ ur alle anderen Adressen, die im eigenen Netz nicht zustellbar sind. Deshalb wurde die Bezeichnung Defaultroute gewählt. Damit Pakete weitergeleitet werden können, muss jedoch mindestens ein Router Mitglied des jeweiligen Teilnetzes sein.

5.7.4

Routingentscheidung

Routingentscheidungen erfolgen meistens entlang komplexerer Tabellen, als den in Hosts verwendeten. Viele Pakete an Knotenroutern mit vielen Interfaces und hohen Bandbreiten legen eine hardwarenahe Implementierung nahe. Durch die Bildung eines “logischen UND” 16

Die Konzepte unterscheiden sich dabei von Distribution zu Distribution durchaus erheblich.

5.7. IP-ROUTING

57

aus Ziel-IP und Netzmaske wird durch den Vergleich mit den Netzadressen ermittelt, ob eine Route verwendet wird oder nicht. Z.B. f¨ ur das Ziel: 192.168.20.5 & 255.255.255.0 ergibt 192.168.20.0. Dieses wird mit der Netzadresse verglichen. Wenn diese passt, wird dort verschickt, sonst wird die nächste probiert, z.B. bei 24.46.192.77 & 255.255.255.0 ergibt 24.46.192.0 , also nächster Versuch 24.46.192.77 & 0.0.0.0 errechnet sich zu 0.0.0.0 - die Defaultroute. Dabei startet man bei der kleinsten Netzmaske, also dem Netz mit den wenigsten Hosts. Dann arbeitet man sich sukzessive bis zur größten Netzmaske17 alle eingetragenen Routen ab. Die Defaultroute ist dabei eine Konvention zur Vereinfachung der Routingtabellen. Kein Router kennt alle die Wege zu allen Internet-Adressen direkt, da fast jeder Router nur einen Bruchteil des Adressbereiches verwaltet. Jeder dieser Router hat eine Route f¨ ur alle restlichen Bereiche. Auch ein einfacher Host kann mehrere Routen f¨ ur 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 u ¨ ber Reihenfolge der Einträge in der Routingtabelle. Im Extremfall kann es also passieren, dass ein Paket gegen jede Regel gepr¨ uft wird. Netz 192.168.20.128 192.168.20.0 10.10.2.0 10.10.0.0 10.4.0.0 10.0.0.0 0.0.0.0

Netzmaske 255.255.255.128 256.255.255.128 255.255.255.0 255.255.0.0 255.252.0.0 255.0.0.0 0.0.0.0

Gateway/Router 192.2.2.2 193.2.2.3 10.10.255.254 10.10.0.254 10.10.0.254 192.168.2.5 10.10.0.254

Interface #1 #1 #2 #3 #4 #1 #3

Tabelle 5.5: Beispiel einer möglichen Routingtabelle Eine Verwaltung von Routinginformationen in größeren Netzwerken wird sehr schnell recht aufwändig. Deshalb wurden Protokolle entwickelt, um einige Aspekte automatisieren zu können. Dynamisches Routing soll Ausf¨ alle erkennen und Alternativrouten finden und eintragen. Hierzu sind verschiedene Strategien m¨ oglich: Hop-Count: Wieviele Router liegen auf dem Weg von A nach B (was ist jedoch, wenn der Weg u urzer ist, als der ”Umweg” u ¨ ber eine langsame ISDN-Leitung viel k¨ ¨ ber ein viel schnelleres LAN) Open Shortest Path First: Routingmetrik nimmt weitere Kennzahlen einer Route auf BGP: Border-Gateway-Protokolle f¨ ur Router an den Grenzen großer Netzwerke Obwohl Adressen zentral vergeben werden, erreicht man kaum eine nähere geografische Zuordnung18 als auf L¨ ander oder Kontinentebene. Lokal nahe beieinander liegende Firmen oder Organisationen k¨ onnen durchaus netzwerktopologisch gewaltige Entfernungen besitzen, wenn sie u ber verschiedene Provider angeschlossen sind. IP-Netze sind eher daher eher ¨ als ”provider-based” zu bezeichnen. 17

0.0.0.0 das gesamte Internet Auch wenn es Firmen gibt, die zu jeder IP-Adresse eine ungef¨ ahre bis genaue geografische Koordinate liefern k¨ onnen. 18

58

KAPITEL 5. TCP-IP

5.7.5

Subnetting und Supernetting

Fr¨ uhe 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 u ¨blicherweise ein Subnetting zur besseren Abtrennung verschiedener Netze untereinander betrieben. Damit reduziert sich die Broadcast-Domain und es wird eine Strukturierung des Netzes erreicht. Mit der Knappheit der IP-Adressen im Netzmaske 255.255.0.0 255.255.128.0 255.255.192.0 255.255.224.0 255.255.240.0 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0

Bitmuster der Netzmaske 11111111.11111111.00000000.00000000 11111111.11111111.10000000.00000000 11111111.11111111.11000000.00000000 11111111.11111111.11100000.00000000 11111111.11111111.11110000.00000000 11111111.11111111.11111000.00000000 11111111.11111111.11111100.00000000 11111111.11111111.11111110.00000000 11111111.11111111.11111111.00000000

Teilnetze 1 2 4 8 16 32 64 128 256

Anzahl IP’s 65.536 32.768 16.384 8.192 4.096 2.048 1.024 512 256

Tabelle 5.6: Subnetting in ”Klasse-B-Netzwerken” derzeitigen IPv4-Adressraum von 232 (weniger etlicher Spezialadressen, siehe dazu bisherige Ausf¨ uhrungen) 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¨ ur die Routinginformationen wird nun jedoch immer die Subnetzmaske mit zu u ¨bermitteln sein, da sich diese nicht mehr aus der ersten Bitfolge der IP ergibt. Damit: Ein flexibleres Schema ist notwendig. Klassen d¨ urfen beliebig in Subklassen aufgeteilt werden, z.B. kann das RZ der Uni-Freiburg einzelnen Bereichen sog. Subnetze zuweisen. Aus der Aufteilung der h¨ oheren Klassen entstehen aus einem Klasse B Netz mit 65.535 Rechnern werden dann 256 Klasse C Netze mit 254 Rechnern pro Netz. Trotzdem m¨ ussen 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¨ ur dieses dann die Maske 255.255.254.0 verwenden. Supernetting kann damit ”Adressverschwendung” verhindern: Ausgabe eines Klasse B Netzes f¨ ur eine Organisation mit 500 Rechnern. Dann: IP-Adresse ist nicht mehr wie urspr¨ unglich selbsterklärend deklariert, denn nun muss die Netzmaske zwingend mit u ¨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 u ¨ber ARP kommunizieren. Dabei sollten in der Folge nur ”1” gefolgt von nur ”0” stehen19 , z.B.: 19

Daraus folgt, dass nur die Zahlen 0, 128, 192, 224, 240, 248, 252, 254, 255 in der Netzmaske vorkommen k¨ onnen. Andere Muster w¨ aren m¨ oglich aber eventuell ordentlich verwirrend. Siehe Anmerkungen dazu weiter

5.7. IP-ROUTING netmask 255.255.255.0 netmask 255.255.252.0 netmask 255.255.0.0

59 11111111.11111111.11111111.00000000 11111111.11111111.11111100.00000000 11111111.11111111.00000000.00000000

Die erste Beispielmaske ist eine Class-C-Maske und die letzte, die eines Class-B-Netzes. Es spielt nun aber keine Rolle mehr, wie das erste Bitmuster der IP-Adresse aussieht. Geht man z.B. davon aus, dass ein Class-B-Netz aufgeteilt werden soll, dann geschieht das wie folgt: Das gezeigte Muster kann nat¨ urlich auch ausgehend von einem Class-A-Netz durchgef¨ uhrt werden, wobei dann der letzte Tabellenwert mit 256 zu multiplizieren ist. Geht man von einem Class-C-Netz aus, muss der letzte Wert hingegen durch 256 geteilt werden. Wendet man dieses Beispiel nun auf ein konkretes Teilnetz an, z.B. auf das Class-BNetz 134.76.0.0, dann ergibt sich das Bild (Tabelle 5.7.5) bei gleichmässiger Aufteilung. Die Tabellen k¨ onnten nat¨ urlich noch weiter fortgesetzt werden, aber das Prinzip sollte klar Teilnetze 1 2 4

8

Netzadresse(n) 134.76.0.0 134.76.0.0 134.76.128.0 134.76.0.0 134.76.64.0 134.76.128.0 134.76.192.0 134.76.0.0 134.76.32.0 134.76.64.0 134.76.96.0 134.76.128.0 134.76.160.0 134.76.192.0 134.76.224.0

Netzmaske 255.255.0.0 255.255.128.0 255.255.128.0 255.255.192.0 255.255.192.0 255.255.192.0 255.255.192.0 255.255.224.0 255.255.224.0 255.255.224.0 255.255.224.0 255.255.224.0 255.255.224.0 255.255.224.0 255.255.224.0

Broadcastadresse(n) 134.76.255.255 134.76.127.255 134.76.255.255 134.76.63.255 134.76.127.255 134.76.191.255 134.76.255.255 134.76.31.255 134.76.63.255 134.76.127.255 134.76.159.255 134.76.191.255 134.76.191.255 134.76.223.255 134.76.255.255

Zahl der IP’s 65.536 32.768 32.768 16.384 16.384 16.384 16.384 8.192 8.192 8.192 8.192 8.192 8.192 8.192 4.096

Tabelle 5.7: Beispiele einer Aufteilung in bis zu acht Teilnetze geworden sein. Es ist jedoch nicht erforderlich ein Netz in gleiche Teile zu untergliedern, sondern es k¨ onnen auch unterschiedlich grosse Teilbereiche definiert werden, wobei sich jedoch jeder Teilbereich in die seinem Bitmuster passenden Blöcke einf¨ ugen muss20 . Das angegebene Beispiel k¨ onnte also auch so aussehen, wie in Tabelle 5.7.5 gezeigt. Subnetting und Supernetting haben wesentlich dazu beigetragen, dass IPv4 immer noch reicht. Dadurch wird Routing aufw¨ andiger, da Router nicht mehr anhand der ersten vier Stellen der Adresse u ur ¨ ber deren Maske entscheiden können. Router benötigen mehr Speicher f¨ 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¨ ultig ist. Die Startadresse kann 134.76.[0,7,15,23,...].0 sein.

60

KAPITEL 5. TCP-IP Teilnetze 16

Netzadresse(n) 134.76.0.0 134.76.16.0 134.76.32.0 134.76.48.0 134.76.64.0 134.76.80.0 134.76.96.0 134.76.112.0 134.76.128.0 134.76.144.0 134.76.160.0 134.76.176.0 134.76.192.0 134.76.208.0 134.76.224.0 134.76.240.0

Netzmaske 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0 255.255.240.0

Broadcastadresse(n) 134.76.15.255 134.76.31.255 134.76.47.255 134.76.63.255 134.76.79.255 134.76.95.255 134.76.111.255 134.76.127.255 134.76.143.255 134.76.159.255 134.76.175.255 134.76.191.255 134.76.207.255 134.76.223.255 134.76.239.255 134.76.255.255

Zahl der IP’s 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096 4.096

... Tabelle 5.8: Beispiele einer Netzaufteilung mit verschiedenen Subnetzmasken

5.7.6

QoS-Routing

IP selbst und die meisten Netzwerktechnologien kennen kein oder nur sehr beschränktes Quality of Service (QoS). Paketorientierte Netzwerke sind zuallererst f¨ ur gleichberechtigten Zugriff ohne Ressourcen-Monopolisierung ausgelegt. ATM unterst¨ utzt zwar QoS, jedoch keine einfache Verkn¨ upfung mit IP u ¨ber Schichtgrenzen hinweg. IP ist verbindungslos, mit dem Verlassen des Paketes der Maschine ist kein Einfluss mehr möglich. IP-Header enth¨ alt ein Optionenfeld f¨ ur 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¨ ussen Felder auswerten; Prioritäten können sich auf dem Weg atzung des Kostenfaktors von Leitungen); Pakete können auf ihrem ändern (z.B. Einsch¨ Weg umgeschrieben werden. Trotzdem kann QoS-Routing beim Anschluss von LANs an das Internet u ¨ 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¨ ohen. Deshalb: Meistens ist es wieder ”einfacher” die Bandbreite zu ¨ erhöhen, als aufw¨ andiges QoS-Routing einzusetzen. Im LAN-Bereich gibt es Uberlegungen zu QoS bei Ethernet - IPv6 soll einiges mehr an QoS implementieren.

5.8. ADDRESS RESOLUTION PROTOCOL

5.8

61

Address Resolution Protocol

Jede Ethernet-, Funk- TokenRing-Karte besitzt eine eindeutige Hardware-Adresse, die auch als MAC-Adresse bezeichnet wird. LAN-Karten bedienen sich dieser MAC-Adresse, die f¨ ur die Aussendung und den Empfang von Datagrammen u ber das Netzwerk unerl¨ a 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ätes fest. Sie ist fest einkodiert z.B. in einer Netzwerk-Karte. Sie ¨ andert 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¨ ur jede Karte eines Herstellers.

5.8.1

ARP - Hilfsprotokoll des IP

Das Address Resolution Protocol wird als Bindeglied zwischen der eigentlichen NetzwerkHardware einerseits und dem Internet Protokoll (IP) anderseits benötigt. Anders als bei Punkt-zu-Punkt-Verbindungen, wie beispielsweise ISDN agieren in einem Ethernet viele Maschinen gleichberechtigt. Damit reicht es nicht, einfach das Paket an einem Ende der Leitung ”abzuliefern” und nach kurzer Verzögerung am anderen Ende zu erwarten. IP-Adressen kann man nicht einfach nehmen, da man ja beim Kauf einer Ethernet-Karte noch gar nicht wissen kann, in welchem Netz eine Maschine betrieben wird. Ebenso wollte sicherlich keiner einsehen, dass ein Laptop entweder nur zu Hause oder im Firmennetz an einer bestimmten Stelle angeklemmt werden kann, oder dass man sich einen neuen Netzwerkadapter kaufen muss, wenn sich die IP ändert. Deshalb verwendet man beim Ethernet einen eigenen Adressraum mit Eigenschaften, die sich zum IP-Adressraum stark unterscheiden. Die IP-Adresse ist, wie bereits oben erläutert, im OSI-Schichtenmodell der Vermittlungsschicht zugeordnet und von der individuellen MAC-Adresse unabhängig. Jede Kommunikation mittels TCP/ IP wird durch die IP-Adresse eingeleitet, wodurch f¨ ur den Aufbau des Dialogs die MAC-Adresse als sekund¨ ar zur¨ uckgestuft 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¨ ahige 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) u ¨bersetzt die IPAdressen in Ethernet-Adressen. So gesehen gehört es eigentlich auch nicht vollständig in den Link Layer, sondern ist irgendwo zwischen Link und Network Layer einzuordnen. In den ersten beiden 16 bit Feldern des ARP-Paketes stehen der Hardwaretyp und die benutzten Protokolladressen. Im Falle von IP auf der Basis von Ethernet steht im ersten Feld eine 1 f¨ ur Ethernet und im zweiten Feld 0x0800 f¨ ur das IP-Protokoll, wie es auch im EthernetRahmen markiert wird. Die beiden 8 bit Felder zu Beginn der nächsten Zeile bestimmen die Anzahl der Bytes f¨ ur die Hardware- und Protokolladressen, in diesem Fall 6 Byte f¨ ur die Ethernetadresse und 4 Byte f¨ ur die IP-Nummer. Das sich anschließende ”Operation”-Feld

62

KAPITEL 5. TCP-IP 32 bit

HARDWARE ADDRESS TYPE HADDR LENGHT

PADDR LENGHT

PROTOCOL ADDRESS TYPE OPERATION

SENDER HARDWARE ADDRESS (first 4 Byte) SENDER HADDR (last 2 Byte)

SENDER PROTOCOL ADDRESS (first 2 Byte)

SENDER PROTOCOL ADDRESS (last 2 Byte)

TARGET HADDR (first 2 Byte)

TARGET HARDWARE ADDRESS (last 4 Byte)

TARGET PROTOCOL ADDRESS (all 4 Byte)

Abbildung 5.5: Aufbau eines ARP Pakets bestimmt, ob es sich um eine Anfrage (Wert 1) oder eine Antwort (Wert 2) handelt. ARP beinhaltet Felder f¨ ur 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¨ ahigen Rechnern wurde eine manuell erstellte Tabelle verwen21 det , die die Zuordnung zwischen MAC- und IP-Adresse indirekt automatisieren sollte. In den meisten broadcast-f¨ ahigen 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¨ agen.

5.8.2

Funktionsweise

ARP arbeitet dabei ziemlich ger¨ auschlos im Hintergrund. Man muss nichts extra installieren, da diese F¨ ahigkeit eigentlich in jeden Linuxkernel schon hineinkompiliert ist. Die Programme zur Konfiguration und Abfrage des ARP-Caches sind auf fast jedem LinuxRechner installiert: mobile:~ # ip neighbor show 10.8.4.1 dev eth0 lladdr 00:0a:e4:35:33:7a REACHABLE 10.8.4.2 dev eth0 lladdr 00:0c:6f:45:03:0d REACHABLE 10.8.4.254 dev eth0 lladdr 00:09:37:31:3a:13 REACHABLE

In einem gegebenen Subnetz, hier 10.8.4.0/255.255.255.0, werden alle Pakete, die eine Maschine verlassen sollen u ¨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¨ angen. Maschinen in diesem Subnetz verf¨ ugen meist u ¨ber genau eine Netzwerkkarte, ausser sie stellen Gateway-Funktionen in andere Netze bereit. Dann bezeichnet man sie u ¨ blicherweise als Router. So gibt es zwei Szenarien: 1. Die Maschine A will mit einer Maschine B im selben Subnetz kommunizieren. Die Pakete k¨ onnen ohne die Beteiligung weiterer Maschinen direkt u ¨ber das Ethernet hin- und hergeschickt werden. 21

Diese F¨ ahigkeit ist heute noch vorhanden: Mit dem Kommando arp k¨ onnen der Kernel-ARP-Tabelle statische Eintr¨ age hinzugef¨ ugt oder welche gel¨ oscht werden.


63

2. Die Maschine A will ein Paket an irgendeine Maschine ausserhalb des Subnetzes schicken. Da nur der Router R, der deshalb auch als Default-Gateway bezeichnet wird, den Weg in die weite Welt kennt, liefert A die Daten an R. R k¨ ummert sich dann um die Weitersendung und leitet A eventuell zur¨ uckommende Antwortpakete oder Fehlermeldungen zu. Die Art der Daten, die ausgetauscht werden, spielt auf den unteren Netzwerkschichten unterhalb von IP keine Rolle. Jedes IP-Paket wird an den Data-Link Layer weitergereicht, um dort versendet zu werden. Mit der IP-Adresse von B, die als bekannt vorausgesetzt wird, kommt A hier nicht weiter und muss deshalb die MAC-Adresse von B in Erfahrung bringen. Der Ablauf einer ARP-Sitzung folgt normalerweise einem strikten Protokoll: 10.8.4.1

A 00:01:AA

10.8.4.2

B 00:01:BB

ARP-Reply: "10.8.1.2 is at 00:01:BB..."

Abbildung 5.6: Die Station mit der passenden IP-Adresse schickt ein ARP-Reply 1. Zu allererst schaut A in seinem ARP-Cache nach, ob es nicht vielleicht bereits dasgesuchte Adress-Paar bzw. die gesuchte MAC-Adressen kennt. In diesem Cache werden festgestellte Paarungen aus fr¨ uheren Sitzungen f¨ ur eine Weile vorgehalten, um nicht ständig wieder neu fragen zu m¨ ussen. Dieses w¨ urde unnötigen Netzwerk-Verkehr produzieren. 2. Falls kein Eintrag vorhanden ist, wird vom Initiator mit Hilfe von ARP die MACAdresse der fraglichen IP-Adresse zu ermitteln versucht. In der Hoffnung diese Frage wenigstens tempor¨ ar 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¨ altnism¨ assig globalen Anforderung seinen eigenen EthernetTyp 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten wahrgenommen wird. Dieses Rundschreiben ”Ich kenne die MAC-Adresse X, die IPAdresse A und ich suche die MAC-Adresse desjenigen, der die IP-Adresse B hat.” wird von allen aktiven Maschinen im Netzwerk bemerkt. Falls innerhalb eines definierten Timeouts im Sekundenbereich keine Antwort auf die Broadcast-Anfrage eingeht, so wird die Anforderung erneut gestellt. 3. Der Rechner B, und nur dieser, wird auf dieses Broadcast-Request antworten: ”Die IP-Adresse von B ist unter der MAC-Adresse Y zu erreichen”. In der ARP-Antwort sind dann alle Felder entsprechend gesetzt. 4. F¨ ur 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¨ ussen, merkt sich die befragte Maschinen ebenfalls diese Paarung, solange der Cache ¨ nicht aufgrund potentieller Uberf¨ ullung u ¨ berschrieben wird. Sie tut es auf ”Vorrat” f¨ ur den Fall, dass sie sp¨ ater ebenfalls Pakete an B schicken will. Bei einer eventuell nachfolgenden Anforderung ist es daher auch nicht mehr nötig den ARP-Dialog

64

KAPITEL 5. TCP-IP in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem bereits bekannt sind. 10.8.4.1

10.8.4.2

B

A 00:01:AA

00:01:BB

Ethernet-Kommunikation 00:01:AA 00:01:BB IP-Kommunikation 10.8.4.1 10.8.4.2

Abbildung 5.7: Nach dem Austausch der MACs erfolgt die IP-Kommunikation ARP-Datagramme werden von Routern nicht weitergeleitet, da sie in der IP-Schicht operieren und auf MAC-Broadcasts grundsätzlich nicht reagieren können und d¨ urfen. Router stellen daher verwertbare Puffer zwischen einzelnen Rundsende-Subnetzen dar. Mit ihrer Hilfe kann u ussiger Traffic im gesamten Netzwerk eingedämmt und auf effektiv betrof¨berfl¨ fene Subnetze minimiert werden.

5.8.3

ARP unter Linux

Unter Linux erf¨ ahrt 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¨ ultige Adresse, Loopback (lo) und das TunnelInterface (sit0) ben¨ otigen keine. Zum Netzwerkgerät zugeordnete IP-Adressen haben das bekannte Format bestehend aus vier durch drei Punkte getrennte Blöcke von Dezimalzahlen 10.8.4.254. Zwar arbeiten die Rechner intern mit der Binärdarstellung, trotzdem sind die Unterschiede zwischen MAC- und IP-Adresse groß. ARP arbeitet beim Dolmetschen geräuschlos im Hintergrund. Man muss nichts extra installieren, da diese Fähigkeit im Linux-Kernel vorhanden ist. Die Programme arp und ip zur Konfiguration und Abfrage des ARP-Caches sind auf fast jedem Linux-Rechner installiert. mobile root # arp -n Address HWtype 10.8.4.222 ether 10.8.4.204 ether 10.8.4.254 ether mobile root # arp -d 10.8.4.204 mobile root # arp -n Address HWtype 10.8.4.222 ether 10.8.4.204 10.8.4.254 ether

HWaddress 00:03:47:B9:DE:36 00:02:B3:C2:55:91 00:0C:6E:15:03:0E

Flags Mask C C C

Iface eth0 eth0 eth0

HWaddress 00:03:47:B9:DE:36 (incomplete) 00:0C:6E:15:03:0E

Flags Mask C


C

5.8. ADDRESS RESOLUTION PROTOCOL mobile root # arp -n Address HWtype HWaddress 10.8.4.222 ether 00:03:47:B9:DE:36 10.8.4.204 ether 00:02:B3:C2:55:91 10.8.4.254 ether 00:0C:6E:15:03:0E mobile root # arp -s 10.8.4.204 00:11:22:33:44:55 mobile root # arp -n Address HWtype HWaddress 10.8.4.222 ether 00:03:47:B9:DE:36 10.8.4.204 ether 00:11:22:33:44:55 10.8.4.254 ether 00:0C:6E:15:03:0E mobile root # ping 10.8.4.204 PING 10.8.4.204 (10.8.4.204) 56(84) bytes of data.

65

Flags Mask C C C


Flags Mask C CM C


--- 10.8.4.204 ping statistics --1 packets transmitted, 0 received, 100% packet loss, time 0ms mobile root # arp -s 10.8.4.204 00:02:B3:C2:55:91 mobile root # ping 10.8.4.204 PING 10.8.4.204 (10.8.4.204) 56(84) bytes of data. 64 bytes from 10.8.4.204: icmp_seq=1 ttl=64 time=0.164 ms --- 10.8.4.204 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.164/0.164/0.164/0.000 ms

ARP verl¨ asst sich auf die MAC-Adresse des Ethernet-Adapters, so wie sie vom Betriebssystem mitgeteilt wird. Wenn man die MAC-Adresse eines Interfaces ändern will, kann man als Administrator dazu das Kommando ip link set verwenden: linux:~ # ip link set eth0 down linux:~ # ip link set eth0 address 00:20:AA:20:AA:20 linux:~ # ip link show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:20:AA:20:AA:20 brd ff:ff:ff:ff:ff:ff

Das Ganze geht auch mit ifconfig: linux:~ # ifconfig eth1 eth1 Protokoll:Ethernet Hardware Adresse 00:00:0E:7D:71:DF BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenl¨ ange:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) linux:~ # ifconfig eth1 down linux:~ # ifconfig eth1hw ether 00:4F:0E:7D:71:DF linux:~ # ifconfig eth1 eth1 Protokoll:Ethernet Hardware Adresse 00:4F:0E:7D:71:DF inet6 Adresse: fe80::24f:eff:fe7d:71df/64 G¨ ultigkeitsbereich:Verbindung UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenl¨ ange:0 RX bytes:0 (0.0 b) TX bytes:70 (70.0 b)

Das bedeutet schlicht und einfach, dass man sich nicht darauf verlassen kann, dass die im Netz sichtbare MAC-Adresse wirklich die auf dem Netzwerkadapter programmierte ist. Im

66

KAPITEL 5. TCP-IP

WLAN lässt sich die MAC-Adresse scheinbar auch auf diese Weise ändern. Da sie jedoch von der Firmware der Karte noch in anderen Schichten benutzt wird, kommt nach dieser ¨ Art der Anderung 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 Sicherheitslu ¨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¨ ache von ARP liegt in seiner Vertrauensseligkeit. ARP stammt aus den fr¨ uhen 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 abgelegt, unabh¨ angig davon, ob zuvor nach dieser Adresse gefragt wurde. Hierin verbirgt sich die grundlegende Sicherheitsl¨ ucke. Aber auch ein scheinbar folgerichtiger Ansatz, eine Adresse nur dann zu speichern, wenn vorher genau nach dieser Adresse gefragt wurde, l¨ asst sich leicht austricksen, indem ein potenzieller Angreifer einfach schneller antwortet, als der Inhaber der Adresse. So kann der Angreifer nat¨ urlich eine beliebige Antwort geben, wie beispielsweise seine eigene Adresse. Ausgangssituation f¨ ur das 00:b0:11:11:11:11

00:b0:11:22:22:22

10.8.4.2

10.8.4.1

B

A

ARP-Reply: "10.8.1.1 is at 00:b0:11:33..."

10.8.4.50

ARP-Reply: "10.8.1.1 is at 00:b0:11:33..."

P 00:b0:11:33:33:33

Abbildung 5.8: im folgenden beschriebene ARP-Spoofing sei die folgende: Die beiden Hosts A und B kommunizieren miteinander. A benutzt die IP-Adresse 10.8.4.1 und die MAC 00:b0:11:11:11:11, B 10.8.4.2 und MAC 00:b0:11:22:22:22. Der angreifende Host P hat die IP 10.8.4.3 und dazugehörige MAC 00:b0:11:33:33:33. Er möchte ablauschen, was A und B miteinander zu schnacken haben. Host P startet seinen Angriff, indem er die ARP-Caches der Opfer A und B ”vergiftet”22 , d.h. er injiziert gef¨ alschte ARP-Antworten in das lokale Subnetz. P schickt an A ein ARPReply, dass die Information enth¨ alt, 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¨ ur 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¨ ur B statt direkt zu B in Wirklichkeit zu P. Bei B gestaltet es sich genauso, er schickt seinen Verkehr f¨ ur 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¨ urde auffallen, dass der Weg von A nach B plötzlich um 22

hiervon stammt der Ausdruck ”Poisioning”


00:b0:11:11:11:11

10.8.4.1

67

00:b0:11:22:22:22

IP-Kommunikation 10.8.4.1 10.8.4.2

A

10.8.4.50

Ethernet-Kommunikation 00:b0:11:11... 00:b0:11:33...

P

10.8.4.2

B

Ethernet-Kommunikation 00:b0:11:33:33:33 00:b0:11:22:22:22

00:b0:11:33:33:33

Abbildung 5.9: mindestens einen Router l¨ anger 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¨ achtiger macht. Da der Angreifer sozusagen direkt auf dem logischen Verbindungspfad zwischen den Opfern sitzt, wird diese Art eines Angriffs auch als ”ManIn-The-Middle” bezeichnet. 00:b0:11:11:11:11

00:b0:11:22:22:22

10.8.4.2

10.8.4.1

IP-Kommunikation 10.8.4.1 10.8.4.2

A

B

Paketlaufzeit2

Paketlaufzeit1

10.8.4.50 Hop-Count: TTL-1

P 00:b0:11:33:33:33

Abbildung 5.10: Wenn der Angriff wieder beendet wird, muss der ARP-Cache der Opfer wieder aufgeräumt werden, d.h. es m¨ ussen 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¨ allt 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 u ¨ 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¨ onnte. Tats¨ achlich 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 u ¨ berein mit der Absender-Adresse des umschließenden Ethernet-Frames. Hier kann man den Angreifer entdecken und seine MAC-Adresse ablesen. Das ”Standardwerkzeug” f¨ ur ein ARP-Angriff ist das Programm ettercap. Das kann inzwischen eine ganze Reihe von ”Man-in-the-Middle” Angriffe durchf¨ uhren. 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¨ ochte man nun den Verkehr zwischen den beiden Maschinen 10.8.4.204 und 10.8.4.204 mitschneiden, dann erreicht man das u ¨ ber den Aufruf: ettercap -C -M arp

68

KAPITEL 5. TCP-IP

Abbildung 5.11: Ettercap in der Ncurses-Ausf¨ uhrung /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¨ ur 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 u ¨ber das Gateway geroutet wird. Ettercap dient nicht nur als Cracker-Werkzeug, es kann ebenso Administratoren eingesetzt werden, um Schwachstellen im eigenen Netz aufzusp¨ uren. 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¨ uhrt wird, also wenn der HOP-Count manipuliert wird, kaum bzw. höchstens, wenn er beendet wird. Es gibt M¨ oglichkeiten, ARP-Angriffe zu entdecken, aber es gibt kein wirksames Mittel gegen einen solchen Angriff außer einer Verschl¨ usselung. Das ändert nat¨ urlich 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¨ usselt sind, kann P nicht mehr viel damit anfangen. F¨ ur den Fall, dass P den Inhalt manipulieren will, insofern das u ¨ berhaupt Sinn macht, wenn er den Inhalt nicht lesen kann, wird das auch auffallen. Verschl¨ usselung ist die einzige wirksame Möglichkeit. ¨ In kleinen Netzwerken, mit seltenen Anderungen der angeschlossenen Maschine ist es sogar mit vertretbaren Aufwand m¨ oglich, 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¨ agt in einer Tabelle die Paarungen ein und vergibt entsprechend dieser Tabelle freie IP-Adressen. Diese Informationen stehen allen Endsystemen zum Routing zur Verf¨ ugung und sie k¨ onnen, außer durch den Admin, durch niemanden geändert


69

werden. Die Verwendung von ARP wird schlichtweg u ussig und damit fällt auch die ¨berfl¨ Sicherheitsl¨ ucke 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¨ aufige Anderungen, die zum einen kommuniziert werden m¨ ussen, aber zum anderen vor allem u ussen. Angenommen ¨ berhaupt erstmal vorgenommen werden m¨ der Admin ist gerade nicht da, dann kann man z.B. keine Netzwerk-Karte auswechseln, weil man f¨ ur die neue Karte keine IP-Adresse hat. Deshalb wurde ARP ja erfunden. In großen Netzwerken f¨ allt 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¨ urlich auf, wenn ständig ARP-Replies geschickt werden, zumal es f¨ ur diese Replies nie ein Request gab. Die gefälschten Replies m¨ ussen ja auch ständig neu geschickt werden, denn der ARPCache wird nicht ewig vorgehalten, irgendwann fällt der Eintrag von alleine wieder heraus. Eine zur statische Festlegung der der ARP-Tabelle mindestens gleichwertige Alternative stellt der Einsatz von arpwatch von Craig Leres dar, welches nach Veränderungen der IP¨ /Ethernet-Mappings Ausschau h¨ alt. Werden Anderungen bemerkt, findet eine Alarmierung per E-Mail statt. Zudem werden die Manipulationen f¨ ur 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¨ ur kurze Zeit nicht auf die Dienste des Hosts zugreifen. Die verschiedenen Komponenten 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 einer zur letzten Darstellung ¨ ahnlichen 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¨ angerem Nichtgebrauch ausgeschaltet. In diesem Fall taucht das Problem nur gelegentlich, zum Beispiel w¨ ahrend den Arbeitszeiten des Benutzers am Host B, auf. Dies kann f¨ ur 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¨ ahlt, bei jeder Phase des Netzwerkdesigns auf individuelle IP-Adressen zu achten. Hierbei hilft beispielsweise die Verwendung von DHCP.

70

5.8.7

KAPITEL 5. TCP-IP

Proxy-ARP

Mit Proxy ARP wird eine von IP-Routern genutzte Technik betitelt, die mit der Entwicklung von TCP/IP spezifiziert wurde. Der Sinn der Methode liegt in der Beseitigung einiger Probleme des begrenzten IP-Adressraums von IPv4. Durch dieses Verfahren können Router unsichtbar gemacht werden und Teilnetze bequem auf andere Interfaces geroutet werden. Der Linuxkernel unterst¨ utzt 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¨ uhrung 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¨ ucken, konnten zwei Kabelsysteme nur mit einem f¨ ur zwei verschiedene IP-Ranges konfigurierten Router verbunden werden. Repeater waren aufgrund des Fehlens der Notwendigkeit von Filterungsfunktionen f¨ ur 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¨ ugung. Da man jedoch Ethernet einsetzt, können maximal 1’024 Host in einem Segment eingebunden werden. Die Implementierung weiterer Systeme erfordert das Nutzen eines Routers oder einer Bridge. Um nun trotzdem die erste angestrebte Anzahl Host zu erreichen, muss ein zweites autonomes Kabelsystem angelegt werden, welches aufgrund des regen Datenverkehrs mittels Router an das erste angeschlossen wird. Konventionelle Router erfordern, dass den jeweiligen Schnittstellen differente IP-Adressen zugeteilt werden. Obwohl von den 65’534 Adressen der Klasse B nur 1’024 gebraucht wurden, können die restlichen 64’510 Adressen nicht verwendet werden; also offenbahrt sich eine Vergeudung in höchstem Maße. Damit der Router einwandfrei arbeiten kann, muss ihm eine zweite IPAdresse der Klasse B zugeteilt werden, und damit sind erneut ganze 65’510 IP-Adressen verschwendet. Dieses Vorgehen ist aus technischer Sicht in keinster Weise akzeptabel; abgesehen von privaten autonomen Netzwerksystemen ohne registrierte IP-Adressen. Das Internet Protokoll bedient sich ARP, um die MAC-Adresse einer Einheit zu ermitteln, sofern die Netznummer in der eigenen IP-Adresse der des Empfängerknotens entspricht. Andernfalls kommt ein routendes Element (Router oder Gateway) zum Einsatz. Damit möglichst wenige IP-Adressen verschleudert werden, ist es aus technischer Sicht w¨ unschenswert 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¨ ussel. 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¨ onnen, 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¨ ussen. Damit kann der u ussige Netzwerk¨ bersch¨ verkehr einged¨ ammt und die Performance gewahrt werden. Die einzigen Hops, die die elementaren Bits zur Kennzeichnung der verschiedenen Subnetze erkennen können m¨ ussen, sind die Proxy ARP-Ger¨ ate. Nat¨ urlich erfordert das erreichen dieses Ziels eine durchdachte Zuweisung des richtigen Adressbereichs von seiten des Netzwerkadministrators. Beispiels-


71

weise könnten die ersten vier Bits des Host-Anteils der IP-Adresse zur Identifizierung der verschiedenen Subnetze eingesetzt werden. Dabei wird jedoch nicht, wie von vielen vielleicht vermutet, mit Subnetz-Masken gearbeitet oder die Adressenstruktur des Endknotens ist bekannt. Es können nun also 14 Subnetze dadurch definiert werden (Die Subnetze 0 und 15 finden in diesem Beispiel aus Gr¨ unden der Einfachheit keine Verwendung!). Empfängt nun die Schnittstelle 1 eine ARP-Anforderung, u uft die Proxy ARP-Vermittlungseinheit ¨berpr¨ 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 u ¨blicher ARP-Broadcast ins Neuland geblasen. Die j¨ ungst von der ganzen Aktion betroffene Proxy ARP-Einheit speichert die in der ARP-Antwort vermerkte MAC-Adresse des Absender-, sowie des Empf¨ angerknotens 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¨ angeradresse der Proxy ARP-Einheit. Das Datagramm wird daher direkt von der Proxy ARP-Einheit angenommen. Die Proxy ARP-Einheit ersetzt nun wiederum die tats¨ achliche MAC-Adresse des Empfängerknotens und sendet das modifizierte Datagramm an die Schnittstelle 2. Diese Methode funktioniert nur, wenn die beiden Endknoten die G¨ ultigkeit der MAC-Adressen in den jeweiligen ARP-Antworten nicht u ufen. Es ist durch dieses ganze Prozedere möglich, mit einer beliebigen MAC¨ berpr¨ 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 SubnetzAdressierungs-Schema zum Einsatz kommen. Das Router-Element greift insofern beim Empfang einer ARP-Anforderung f¨ ur ein anderes Netz oder Subnetz manipulativ in das Geschehen ein, indem es seine eigene MAC-Adresse in der ARP-Antwort zur¨ uckschickt. Zur ¨ Ubermittlung des Datagramms an den Empfänger werden die herkömmlichen RoutenwahlMechanismen eingsetzt. Dieser Fall kann jedoch nur eintreten, wenn ein verwirrter oder falsch konfigurierter Rechner das Gef¨ uhl 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¨ ur kann die Wahl unterschiedlicher SubnetzMasken sein. Die beiden Ger¨ ate w¨ urden so mit einer Netzstruktur arbeiten, die f¨ ur die Opposition nicht erkennbar und verst¨ andlich ist. Denial of Service durch ARP-Stu ¨ rme Der Denial of Service-Angriff mittels ARP¨ Sturm hat die Uberlastung einer Netzwerkkomponente oder eines Netz(abschnitt)es zur Folge, was unter Umst¨ anden 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 ARPR¨ uckantworten der nicht existierenden Adresse versendet werden, die wiederum von den Gateways per Broadcast zur finalen Verstopfung des Netzes weiterverbreitet werden. Sol-

72

KAPITEL 5. TCP-IP

che Broadcast-St¨ urme 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¨ ur UNIX/Linux ist ein beliebtes Tool zum Erzwingen von ARP-St¨ urmen. Denial of Service durch ARP-Fehlimplenetierungen Auch auf Fehlimplementierungen der ARP-Funktionalit¨ at k¨ onnen Denial of Service-Attacken abzielen, wie im NetBSD Security Advisory 1999-010 (ARP table vulnerability) berichtet wird: obsd fun.c schickt u ¨ 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 Microsoft Windows, welches eine Menge Code von BSD direkt u ¨bernommen haben muss, kann mit den C-Scripts winarp.c und poink.c auf die Pelle ger¨ uckt werden. Diese Angriffs-Form wird ¨ im Thread von Joel Jacobson in Bugtraq erstmals vorgestellt. Ahnliche Diskussionen finden sich in den beiden Threads von Andrew Lancashire und Lisa Napier u ¨ber DoS-Attacken ¨ auf Cisco-Systeme, und von Scott Blake u der ¨ber Cabletron-Router, durch das Uberfluten ARP-Tabelle.

5.9

ICMP - Internet Control Message Protocol

¨ Das ICMP dient zur Ubermittlung 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¨ uck. ICMP ist im Network Layer an¨ gesiedelt, ist aber eigentlich kein wirklich eigenständiges Protokoll, da die Ubermittlung ¨ von ICMP-Nachrichten durch IP-Pakete erfolgt und dazu dient, die Ubertragung 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 u ¨ 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¨ oglicht, in einen Rechner oder ein Netz einzubrechen. Dennoch stellt das Tunneling eine Bedrohung f¨ ur das Sicherheitskonzept eines Netzes dar. Eine recht bekannte Anwendung von ICMP ist das Programm ping, mit dem man die Erreichbarkeit eines anderen Rechners pr¨ ufen kann. Dazu wird ein ICMP echo request an den Zielrechner geschickt, dieser sendet ein ICMP echo reply zur¨ uck, wenn er denn verf¨ ugbar ist. Ping ist ein einfaches Shell-Kommando und wird mittels ”ping Zieladresse” aufgerufen. dirk@linux:~/nwak> ping 134.76.60.86 PING 134.76.60.86 (134.76.60.86) from 132.230.9.124 : 56(84) bytes of data. 64 bytes from 134.76.60.86: icmp_seq=1 ttl=47 time=21.1 ms 64 bytes from 134.76.60.86: icmp_seq=2 ttl=47 time=23.2 ms 64 bytes from 134.76.60.86: icmp_seq=4 ttl=47 time=20.9 ms --- 134.76.60.86 ping statistics --4 packets transmitted, 3 received, 25% loss, time 3019ms

5.10. DOMAIN-NAME-SERVICE (DNS)

73

rtt min/avg/max/mdev = 20.952/21.774/23.243/1.041 ms ICMP wird meistens von IP f¨ ur den Benutzer unsichtbar verwendet, zum Beispiel um herauszubekommen, wie groß ein Paket sein kann, das von Link Protokoll u ¨ 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¨ andigt den Absender eines Datengramms dar¨ uber, dass das Paket aufgrund einer fehlerhaften Angabe im IP-Header verworfen werden musste. • Redirect - Wird ausgesendet, wenn ein Router feststellt, dass ein Paket falsch weitergeleitet wurde. Der sendende Host wird damit aufgefordert, die angegebene Route zu a¨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¨ ur, dass Pakete in einem Zyklus wandern, dass Netz u ¨ berlastet ist oder die Lebensdauer f¨ ur 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 erfasst 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¨ uck.

5.10

Domain-Name-Service (DNS)

Der Domain-Name-Service ist ein auf TCP/IP basierender Dienst und kein Bestandteil der Vermittlungs- bzw. Transportschicht. Jedoch werden vielfach Maschinen nicht primär u ¨ 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

74

KAPITEL 5. TCP-IP K¨ urzel gov de net

Bedeutung governemental Deutschland Netzwerk

K¨ urzel com edu org

Bedeutung Unternehmen (”commercial”) Ausbildungseinrichtung Organisation

Tabelle 5.9: Die traditionellen Domänenendungen K¨ urzel name eu ws

Bedeutung Privatpersonen Europa ”WebSite”

K¨ urzel biz info int

Bedeutung Unternehmungen Informational Internationale Organisationen

Tabelle 5.10: Die von der IANA beschlossenen/vorgesehenen neuen Domänenendungen symbolischen Namen (Hostname). ”Nameserver” kennen die zu den symbolischen Namen gehörenden IP-Adressen und umgekehrt. Wenn man Nameserver direkt abfragen will, kann man das mit den Kommandos host oder nslookup machen. Mittels DNS (Domain-NameService) werden die Hostnamen in einen hierarchischen Namensraum eingegliedert, wobei geografische Gesichtspunkte (L¨ anderdomains, wie ”de”) oder organisatorische Gr¨ unde (Firmen) Ausrichtungskriterien abgeben k¨ onnen. 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 u origkeit des Rechners Auskunft geben. ¨ ber den Namen und die Zugeh¨ Das erste Wort des FQDN ist der sogenannte ”hostname”, der hintere Teil des FQDN ist der ”domainname”. W¨ ahrend 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¨ uhmte Personen, antike Götter usw. sehr beliebt. Dem Rechner kann man auch weitere Namen verpassen, sogenannte Aliase, die meistens die Funktion der Maschine ausdr¨ ucken, 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¨ urzel angesprochen wurden: ”ping test” w¨ urde 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¨ anzungen der Suchreihenfolge und maximal drei Nameserver angegeben werden. Der zweite und dritte DNS werden nur befragt, wenn der erste nicht reagierte, nicht jedoch, wenn die Anfrage auf dem ersten keinen Erfolg brachte.

5.11. TRANSMISSION CONTROL PROTOCOL (TCP)

5.11

75

Transmission Control Protocol (TCP)

¨ Mit der Ubertragung 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¨ ur eine zuverlässige Verbindung die Voraussetzung. Der Datenstrom wird zum Transport in Pakete aufgeteilt, da grosse Dateien 32bit

SOURCE PORT

DESTINATION PORT SEQUENCE NUMBER ACKNOWLEDGEMENT NUMBER

TCP-H Length

U A R C G K

unused

P R S S H T

S Y N

F I N

CHECKSUM

WINDOW SIZE URGENT POINTER

OPTIONS (0 or more 32bit words) BEGINNING OF DATA (optional)

Transmission Control Protocol (TCP)

Abbildung 5.12: TCP Paket-Header nicht ”in einem St¨ uck” 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¨ assig. Uberlastungen im Netzwerk werden durch das ”Vergessen” von Paketen gel¨ ost. Die Verantwortung f¨ ur die Integritätspr¨ ufung und die Vollständigkeit der Daten u ¨ bernehmen die beiden kommunizierenden Rechner, die fehlerhafte Daten erkennen sollen und diese im Fehlerfall erneut anfordern. Diesen Part u ¨ bernimmt ein weiteres Protokoll, das Transmission Control Protocol (TCP). Dieses stellt einen zuverl¨ assigen Dienst u ¨ 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¨ ur Netzwerkverbindungen vorstellen. Diese Adressierung kann man mit einem Haus (IP-Nummer) und den verschiedenen T¨ urklingeln (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 u ¨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-Verbindung auf einem unzuverlässigen Netzverbund aufzubauen. TCP nimmt Datenstr¨ ome von Benutzerapplikationen entgegen und teilt diese in maximal 64 kByte grosse Bl¨ ocke 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¨ ocken der Hardwareschicht ”Frames” und den Datenbl¨ ocken der Vermittlungsschicht ”Packet”

76

KAPITEL 5. TCP-IP

weitergeleitet. Da IP selbst keine Zustellbest¨ atigung 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¨ ur sogenannte ”well-known services” reserviert. Hier findet man die Standarddienste. Weitere sechs Ein-Bit-Felder des HeaService ftp ssh telnet smtp http ldap

Port-Nummer 21 22 23 25 80 389

Service pop3 ntp rsync imaps pop3s ldaps

Portnummer 110 123 873 993 995 636

Tabelle 5.11: TCP-basierte Standardservices ders sind f¨ ur diverse Flags vorgesehen. Sie steuern das Verbindungsverhalten eines TCPDatenkanals. Das Flag Push signalisiert, dass keine Datenpufferung stattfinden soll, d.h. dass die Datagramme nicht vollst¨ andig aufgef¨ ullt werden sollen. Dieses ist bei interaktiven Verbindungen, wie ssh, telnet und dem Steuerkanal von ftp sinnvoll. Sonst m¨ uß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¨ ur die Header-L¨ ange 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¨ uhren, anzunehmen, dass eine TCP-Sitzung sicher vor bewußter Manipulation oder Mitlauschen ist. Da alle Daten offen, d.h. unverschl¨ usselt, u ¨ bertragen werden, können Angreifer versuchen die Acknowledge- und Sequencenummern zu raten und damit einen Datenstrom u ¨ bernehmen. Diese Nummern werden quasi zuf¨ allig beim Verbindungsaufbau gesetzt24 und dann jeweils um eins (bzw. in sp¨ ateren 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¨ atigungen verschickt werden. Hierbei findet das Sliding24

Da das Verfahren m¨ oglichst schnell und effizient arbeiten soll, wurde bei fr¨ uheren TCPImplementationen die Zahl einfach erh¨ oht, 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¨ ur 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¨ ur Verbindungsabbau erfolgt ein ”geordneter Abschluss” analog zum Aufbau.

5.12

User Datagram Protocol (UDP)

¨ In vielen Fällen der Netzwerkkommunikation gen¨ ugt die Ubertragung eines einzigen Paketes zur Informations¨ ubermittlung in jede Richtung. Der Aufwand w¨ urde durch das vorgeschaltete 3-Wege-Handshake, welches TCP implementiert, und den geordneten Abbau der Verbindung gewaltig angehoben. Dadruch entst¨ unde 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¨ ur 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¨ uber TCP erheblich geringer. Beispiele f¨ ur 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 u ¨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¨ ugbar sind. Diese k¨ onnen komplett parallel zu den TCP-Ports verwendet werden. Weiterhin wird die Paketl¨ ange und eine Pr¨ ufsumme vermerkt. UDP kennt keine Bestätigungsmeldungen und keine Pr¨ ufung auf Reihenfolge. Der UDP-Header ist immer 8 Byte lang25 . Deshalb erh¨ alt man sehr geringe Latenzzeiten. Es eignet sich gut f¨ ur Broadcasts. Alle weiteren Aufgaben, die TCP zusätzlich implementiert, m¨ ussen bei der Verwendung von UDP von der Applikation u ¨ bernommen werden. UDP-Pakete k¨ onnen auch per Broadcast an alle Hosts des lokalen Netzes versandt werden, die IP-Adresse des Empf¨ angers ist dann 255.255.255.255. Das Programm rwhod verwendet dieses Verfahren, um eingeloggte Benutzer und die Uptime der Maschinen in einem Netzwerk zu ermitteln. Auf diese Weise können recht einfach Systeme realisiert werden, die bestimmte Listener suchen. Diese melden sich auf einen solchen Broadcast dann mit einem 25

zum Vergleich: TCP hat 20 Byte plus evtl. Optionen

78

KAPITEL 5. TCP-IP

entsprechenden Paket; alle anderen bekommen das Paket erst gar nicht oder m¨ ussen sich einfach an ”alle” wenden. Broadcast-Pakete gehen nur einmal u ¨ ber die Netzwerk-Leitung. Es wird also nicht f¨ ur jeden Teilnehmer ein getrenntes Paket verschickt. Die LeitungsBelastung ist also gleich der beim Versenden eines Pakets an nur einen Peer.

5.13

Ports

Ports wurden im Zusammenhang der Transportprotokolle UDP und TCP bereits kurz ¨ erwähnt, aber kaum erkl¨ art. Dies soll an dieser Stelle nachgeholt werden. Uber das TCP und UDP Protokoll k¨ onnen Daten zu einem anderen Rechner u ¨bertragen werden. Nun hat man aber häufig mehrere Dienste auf einem Rechner, und möchte gleichzeitig mit mehreren Diensten kommunizieren k¨ onnen. 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 u ¨ ber TCP Port 21, Telnet läuft u ¨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 u ¨ 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¨ uhrt.

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¨ anze 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¨ ohere Netzwerkschicht der Inhalt dieses Pakets (die sog. Payload) weitergereicht werden soll?

5.14. AUFGABEN

79

5. Welches Protokoll auf welcher Schicht des TCP/IP-Stacks benutzt das Kommando ping (zur Feststellung der Erreichbarkeit von Rechnern)? 6. Was macht das ToS (Type of Service) Feld im IP-Header? Weshalb wird es meistens ignoriert?

5.14.3

IP-Netze

1. Was unterscheidet die folgenden IP-Nummern im Netz 134.76.60.0/24: 132.230.4.0, 132.230.4.232, 132.230.4.255, 132.230.4.254, 132.230.4.1 voneinander? 2. Wie konnte ein Router fr¨ uher schon an der IP-Adresse erkennen, um was f¨ ur 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¨ onnen 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¨ unde 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¨ oglichkeit Pakete zu fragmentieren? 2. Was versteht man unter Path MTU Discovery (PTMUD)? Die MTU (Maximum Transfer Unit) gibt die maximale Paketgröße auf dem Data Link/physikalischen Layer an. 3. Wodurch kann PMTUD von Routern (ungewollt) verhindert werden?

80

KAPITEL 5. TCP-IP 4. Warum arbeitet man bei der Fragmentierung mit Offsets und schreibt nicht einfach die Größe des Fragments in das Feld? 5. Man betrachte die Verschickung eines 4000 Byte Datagramms u ¨ ber ein Netzwerk mit einer MTU von 900 Byte. Dabei sei das Original mit der Identifikationssnummer 345 bezeichnet worden. Wieviele Fragmente werden generiert? F¨ ur jedes Fragment gebe man die Identifikation, die Payload ohne IP-Header, Offset und den Inhalt des ”More Fragments” Flags an!

5.14.5

IP-Routing

1. Ein Router hat die folgenden Einträge in seiner (statischen) Routing-Tabelle: Address/Netmask 135.46.56.0/22 135.46.60.0/22 192.53.40.2/23 87.23.16.0/20 0.0.0.0/0

Next Hop Interface 0 (direkt) Interface 1 (direkt) Router 1 Router 2 Router 3

Wo schickt der Router Pakete mit folgenden Zieladressen lang: 135.46.63.10, 192.53.45.12, 87.23.33.189, 135.46.52.2, 87.23.19.55, 192.53.40.7?

5.14.6

ARP

1. Warum wird eine ARP-Anfrage in einem Broadcast-Frame (Ethernet, TokenRing, ...) geschickt? Wie sieht so ein spezielles Frame aus? 2. Warum kommt die ARP-Antwort in einem Frame mit einer spezifischen Zieladresse zur¨ uck? 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¨ uhrenden Betriebssysteme entwickelt, welches auch und gerade wegen seiner vielf¨ altigen Eigenschaften auch auf Routern1 eingesetzt wird. Router sind die zentralen Vermittlungs- und Weiterleitungsstellen im verbindungslosen, paketorientierten Internet. Linux kann neben TCP/IP auch in AppleTalk, IPX/SPX, Decnet und weiteren Netzwerken betrieben werden. Die folgenden Ausf¨ uhrungen werden sich jedoch nur am Rande mit anderen Netzen als dem Internet-Protokoll (IP) auseinandersetzen. Die folgenden Ausf¨ uhrungen zum OSI-Modell und TCP/IP haben nat¨ urlich nicht nur mit Linux zu tun, sondern betreffen alle Rechner, die u ¨ 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, ist mit den aktuellen Kernels bedeutend mehr m¨ oglich.

6.1

IP-Konfiguration unter Linux

Die Einbindung von Linux in ein IP-Netzwerk geschieht durch die Zuweisung einer eindeutigen Adresse. Diese ist entweder weltweit erreichbar oder zumindest im lokalen Netzwerk nur einmal vorhanden.

6.1.1

Die traditionellen Tools

Die Konfiguration der Netzwerkschnittstellen unter Linux erfolgt mit dem Kommando ifconfig. Aufgerufen ohne Optionen liefert es die konfigurierten Schnittstellen: shuttle:~/ > /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:60:08:38:C7:29 inet addr:10.10.156.2 Bcast:10.10.159.255 Mask:255.255.252.0 inet6 addr: fe80::240:c7ff:fe99:35ad/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3841 errors:0 dropped:0 overruns:0 frame:0 TX packets:2437 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:448759 (438.2 Kb) TX bytes:804 (804.0 Kb) Interrupt:9 Base address:0xe400 1

beispielsweise im Consumer-Bereich auf DSL- oder WLAN-Routern

81

82

KAPITEL 6. LINUX IM NETZWERK

lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:3840 Metric:1 RX packets:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:118360005 (12.8 Mb) TX bytes:118360005 (12.8 Mb)

In der Ausgabe sieht man je nach Interface die Angaben zur definierten IP, die Hardwareadresse, wenn es sich um ein Ethernetinterface handelt, sonst den Point-to-Pointpartner (z.B. bei Modem und ISDN). Weiterhin wird angezeigt, welche Protokolle auf dem Interface registriert sind (z.B. Appletalk und IPv6 sind neben dem klassischen IPv4 denkbar), wieviel Byte die maximale Paketgr¨ osse 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¨ ur 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¨ ur 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¨ ochte, 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 Quell- zur Zieladresse. Jeder Netzknoten (Internet-Router) muss f¨ ur jedes IP-Paket neu entscheiden wo es langgeschickt wird. Routingentscheidungen m¨ ussen jedoch schon auf dem Quellrechner eines Paketes getroffen werden. Dieses gilt f¨ ur jede Linux-Maschine mit installiertem TCP/IP-Stack. Ist das Paket • f¨ ur das Loopback-Interface bestimmt • soll es im lokalen Ethernet zugestellt werden • soll es u ¨ 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¨ ur alle ausgehenden Pakete entscheiden, in welches Netzwerk er die Pakete schicken soll. Hierzu verwaltet der Kernel eine eigene Routing Tabelle. Diese enthält Informationen u ¨ber Routen zu anderen Netzwerkknoten speichert. Jeder Eintrag einer Route besitzt dabei einen eindeutigen Schl¨ ussel bestehend aus der Netzwerkadresse und der Netzmaske des verbundenen Netzwerks. Der nächste Hop f¨ ur 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. Ublicherweise läßt sich der Admin diese Tabelle durch route -n oder netstat -rn:

6.1. IP-KONFIGURATION UNTER LINUX linux:~ # route -n Kernel IP Routentabelle Ziel Router 10.8.1.0 0.0.0.0 192.168.15.0 0.0.0.0 169.254.0.0 0.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0 192.168.15.1

Genmask 255.255.255.0 255.255.255.0 255.255.0.0 255.0.0.0 0.0.0.0

83

Flags U U U U UG

Metric 0 0 0 0 0

Ref 0 0 0 0 0

Use 0 0 0 0 0

Iface eth0 eth1 eth1 lo eth1

ausgeben. In den SuSE-Linux-Distributionen werden die IP-Einträge unterhalb des Konfigurationsverzeichnisses /etc/sysconfig/network gespeichert und u ¨ber das Runlevel-Skript /etc/init.d/ network start2 mittels ip aktiviert. Bezieht der Rechner seine IP dynamisch per DHCP, so wird statt ip ein DHCP-Client-Tool, wie dhclient, pump oder dhcpcd ausgef¨ uhrt. Diese Dienste beziehen die IP-Konfiguration u ¨ 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¨ at. IProute2 ist seit Kernel-Version 2.2 standardmässig f¨ ur das Routing von IP-Paketen zust¨ andig. Es beherrscht eine ganze Reihe neuer Fähigkeiten: • des Weiterleitens • des Filterns • der Klassifikation von IP-Paketen. Hierzu z¨ ahlen beispielsweise das Einrichten von Backup-Gateways und das Verwenden von mehreren Default-Gateways. Wo fr¨ uher nur die Zieladresse eines Paketes bei der Routing-Entscheidung eine Rolle spielte, können nun auch die Absendeadressen hierf¨ ur in Betracht gezogen werden. Ebenfalls lassen sich verschiedene Wege und Prioritäten anhand von eingesetzten h¨ oher liegenden Protokollen (TCP und UDP) und deren Ports festlegen. Auf diese Weise erh¨ alt 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¨ uhrt 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¨ alt weitere Kommandos, wie nstat, ifstat, routel, rtstat. Sie generieren ¨ Statistiken und Uberblicke.

6.1.4

Das Kommando ip

IProute2 wurde von Alexey Kuznetsov entwickelt. Das Projekt besteht seit 1999 und wird seit Kernel 2.2 f¨ ur das lokale Routing von IP-Paketen benutzt. Folgende Aktionen kann ein Sysadmin mit IProute2 vornehmen: • Management von IP-Adressen (IPv4, IPv6) 2

Die Runlevel-Skripten sind auch direkt mit rcnetwork aufrufbar, da dieses Links aus dem Verzeichnis /usr/sbin auf die entsprechenden Runlevelskripten sind.

84

KAPITEL 6. LINUX IM NETZWERK • ARP Tabellen Management • Routing Tabellen Management • Routing Policy Database Management • IP Tunnel Konfiguration • Paket und Routen Monitor • Traffic Shaping (QoS)

ip ist ein zusammengesetztes Kommando. Seine Funktion wird durch das zu bearbeitende Objekt bestimmt. Allgemein setzt sich der Aufruf von ip wie folgt zusammen: ip [OPTIONS] OBJECT [COMMAND[ARGUMENTS]|help] Die OPTIONS beeinflussen wie bei gewohnten Kommandos auch das generelle Verhalten und die Ausgabe die ip Befehls. Optionen folgen direkt nach dem Kommando und sind mit dem ”-” Zeichen eingeleitet. Sie k¨ onnen nicht hinter dem Objekt stehen. • -V[ersion] - gibt die aktuelle ip-Version aus. • -s[tatistics] zeigt passend zum Objekt ausf¨ uhrlichere Informationen an. • -f[amily] inet, inet6, link legt die die Protokollfamilie fest. • -o[neline] sorgt f¨ ur die Ausgabe aller Informationen in einer Zeile. So läßt sich die Ausgabe in Skripten oft besser bearbeiten. • -r[esolve] schaltet die Namensaufl¨ osung 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¨ ur 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¨ oglichen Aktionen hängt dabei vom Objekttyp ab. Ublicherweise lassen sich Objekte hinzuzuf¨ ugen (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¨ onnen durch ein einzelnes Schl¨ usselwort abgek¨ urzt werden. • parameters - bestehen aus einem Schl¨ usselwort gefolgt von einem Wert. help liefert immer eine Kurzhilfe f¨ ur das Kommando generell oder die Anwendung des Kommandos auf einzelne Objekte, z.B. ip help oder ip route help.

6.1. IP-KONFIGURATION UNTER LINUX

6.1.5

85

Erste Schritte mit ip

Die folgenden Beispiele sollen demonstrieren, wie ip die Standardaufgaben von route, arp und ifconfig u uhrt. Dazu sollte man ¨ bernimmt, die ein Sysadmin u ¨blicherweise damit ausf¨ 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 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff inet 10.8.4.254/24 brd 10.8.4.255 scope global eth0 inet 10.2.13.248/32 scope global eth0 inet6 fe80::2e0:29ff:fe0b:f938/64 scope link valid_lft forever preferred_lft forever 3: eth1: 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 IPErfahrung werden sich schnell zurecht finden und die Vorteile von ip schätzen lernen. Das Setzen einer IP-Adresse auf ein Interface oder das Hinzuf¨ ugen einer weiteren, durchaus auf dasselbe, geschieht mit: linux02:~ # ip addr add 10.8.1.10/24 broadcast 10.8.1.255 dev eth0 linux02:~ # ip addr add 10.8.2.10/24 broadcast 10.8.2.255 dev eth0 linux02:~ # ip addr show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff inet 10.8.1.10/24 brd 10.8.1.255 scope global eth0 inet 10.8.2.10/24 brd 10.8.2.255 scope global eth0

86


Die Angabe der Netzwerkmaske ist einigen vielleicht etwas ungewohnt. Statt in der klassischen Form einer IP-Adresse (hier w¨ are es die 255.255.255.0) erfolgt die Beschreibung durch die Zahl der Einsen im Pr¨ afix (hier 24). Die (Hardware-)Daten zu einem einzelnen Interface zeigt: linux02:~ # ip link show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff linux02:~ # ip link set eth0 down linux02:~ # ip link set eth0 address 00:20:AA:20:AA:20 linux02:~ # ip link set eth0 mtu 1400 linux02:~ # ip link set eth0 name dsl0 linux03:~ # ip link show dsl0 2: dsl0: 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 a ¨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¨ ur die Reduktion der MTU um 100 Byte oder f¨ ur das Setzen eines anderen Interface-Namens. Das macht dann Sinn, wenn der Admin Interfaces beispielsweise nach ihrer Funktion kennzeichnen möchte. Anschliessend erfolgt die Anzeige der Konfiguration mit dem neuen Interface-Namen (hier dsl0). Das Interface ist abgeschaltet - zu sehen daran, dass in der Anzeige bei den Flags ”UP” fehlt. In jedem der gezeigten Aufrufe wurde das Interface direkt hinter dem Kommando (set oder show) angegeben. Mit der gesetzten Option ”-s” gibts etwas mehr zu sehen: linux02:~ # ip -s link show eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 162342126 915844 0 0 0 0 TX: bytes packets errors dropped carrier collsns 1020902001 1147698 0 0 0 0 Die Statistiken zum Interface kennt man schon von ifconfig. ip zeigt sie in einer Tabelle, was die skriptbasierte Auswertung erleichtert. Mehr Informationen gibt es bei Wiederholung der Option (”-s -s”). Dann schl¨ usselt ip noch die Art der aufgetretenen Fehler auf. Der ARP-Cache kann mit: linux02:~ # ip neighbor show 10.8.4.220 dev eth0 lladdr 00:10:a4:8d:56:0a nud delay 10.8.4.1 dev eth0 lladdr 00:0f:66:c7:73:e8 nud stale 10.8.4.204 dev eth0 lladdr 00:08:74:4d:6f:3f nud stale ausgelesen werden.

6.2

Weitergehende Anwendungen von IProute2

In den ersten Abschnitten wurden einige IP- und Routingkonfigurationen gezeigt. Mit den IProute2-Kommandos ist jedoch noch einiges mehr drin.

6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE2

6.2.1

87

Weitere Tools

Das IProute2-Paket enth¨ alt einige weitere n¨ utzliche Programme. So liefert das Kommando nstat Statistiken des Kernels zum IP-Verkehr. linux02:~ # nstat #kernel IpInReceives IpForwDatagrams IpInUnknownProtos IpInDelivers IpOutRequests IpReasmReqds IpReasmOKs IpFragOKs IcmpInErrors IcmpInDestUnreachs IcmpInTimeExcds IcmpInParmProbs IcmpInEchoReps IcmpInTimestamps IcmpOutErrors IcmpOutTimeExcds IcmpOutTimestamps TcpActiveOpens TcpPassiveOpens [ ... ]

1011352 48960 3 953958 1255516 16824 8412 2 5437 5 222 4736 476 3 26789 26313 476 1258 323

0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

Diese Informationen kennen einige vielleicht schon von der SNMP-Standard-MIB. Letztendlich macht beispielsweise NetSNMP unter Linux nichts anderes, als diese Kernel-Informationen auszulesen. So erh¨ alt 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¨ oherschichtige Protokolle oder Ports nicht erreichbar sind (IcmpInDestUnreachs). Ping benutzt mit Echo und Reply diesen Dienst f¨ ur 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¨ uhrliche Kernel-Routing-Table aus. ifstat fasst die Statistiken zu Datenraten der einzelnen Netzwerkinterfaces zu einer Tabelle zusammen: linux02:~ # ifstat ifstat: history is aged out, resetting #kernel Interface RX Pkts/Rate TX Pkts/Rate RX Errs/Drop TX Errs/Drop lo 3905 0 3905 0 0 0 0 0 eth0 915949 0 1120K 0 0 0 0 0 tun0 9071 0 13359 0 0 0 0 0

RX Data/Rate RX Over/Rate 393392 0 0 0 158546K 0 0 0 3535K 0 0 0

TX Data/Rate TX Coll/Rate 393392 0 0 0 996987K 0 0 0 1090K 0 0 0

Der Befehl ss zeigt die aktuell bestehenden TCP-Verbindungen an: linux02:~ # ss State Recv-Q

Send-Q

Local Address:Port

Peer Address:Port

88 ESTAB ESTAB ESTAB

KAPITEL 6. LINUX IM NETZWERK 0 0 0

0 0 0

132.230.129.7:56946 10.8.4.254:57051 132.230.129.7:56687

132.230.1.142:ssh 10.8.4.205:microsoft-ds 134.76.63.80:ssh

Zu weiteren Kommandos und ausf¨ uhrlicheren Beschreibungen sei auf die mitgelieferte Dokumentation oder weiterf¨ uhrende 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¨ unscht. Da sich einzelne Dienste gut an ihren Portnummern untscheiden lassen, soll vielfach auch der nächste Header in Betracht gezogen werden. Der Port steht im TCP oder UDP-Kopf. Diese Art des Routings bezeichnet man als Policy Routing. Viele Admins kennen dieses Konzept bereits von der Einrichtung einer Firewall. In IProute2 wird das Policy Routing durch eine Routing Policy Database (RPDB) und einem Set von Regeln implementiert. Die RPDB besteht aus 255 Tabellen, mit denen IPPakete die bestimmten Mustern folgen, geroutet werden können. Die Muster lassen sich mit dem Befehl ip rule und die Routing Tabellen mit ip route manipulieren. Immer eingerichtet sind drei vorkonfigurierte Tabellen ”local”, ”main” und ”default”. Dazu gehören drei Regeln, die bestimmen wann diese Tabellen f¨ ur 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¨ ur 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. Es sei ein kleines Firmennetz u ¨ ber zwei Provider an das Internet angeschlossen. Ein Provider biete 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) u ¨ ber den schnellen Provider 192.168.1.254 geleitet werden. Alle anderen Pakete nehmen den verz¨ ogerten Weg u ¨ 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, u onnen beispielsweise kleine integrierte DSL/ISDN-Router sein) ¨ ber welchen Router (das k¨ ein Paket seinen weiteren Weg nimmt. F¨ ur dieses Regelset wird zuerst eine neue Tabelle ”SourceRouting” in der Datei /etc/ ur muss eine Regel erstellt werden, die f¨ ur alle Pakete iproute2/rt tables eingetragen. Hierf¨ 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

6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE2

89

Abbildung 6.1: Default-Gateway mit zwei Wegen zu verschiedenen Routern linux02:~# ip rule show 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 SourceRouting eingetragen. Ab dann werden alle Pakete von der IP-Adresse 192.168.100.100 u ¨ 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 u ¨ 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 u ¨ber eine Leitung kommen wieder u ¨ ber dieselbe verschickt werden (Split Access)? • Wie kann eine Backup-Default-Route definiert werden, die nur bei Ausfall der DefaultRoute benutzt wird? In einem ersten Schritt legt man zwei neue Routing Tabellen Route1 und Route2 in /etc/iproute2/rt tables an, identisch zum eben beschriebenen Verfahren. Route1 sei dabei die Tabelle f¨ ur Provider 1 und entsprechend Route2 die f¨ ur Provider 2. linux02:~# linux02:~# linux02:~# linux02:~#

ip ip ip ip

route route route route

add add add add

132.230.129.0/28 dev eth0 src 132.230.129.1 table Route1 default via 132.230.129.15 table Route1 80.168.20.0/25 dev eth1 src 80.168.20.125 table Route2 default via 80.168.20.126 table Route2

90


Abbildung 6.2: Szenario mit zwei Routen u ¨ber Provider 1 und 2 Die Routing Rules legen fest, welche Tabelle f¨ ur welche IP herangezogen wird. 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¨ ur 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¨ ur die ”main” Routing Table gesetzt. Da der Verkehr gleichm¨ aßig auf beide Anschl¨ usse verteilt werden soll, muss die Route jetzt als Multipath-Route angelegt sein. Der ”weight” Parameter dient dazu die Verteilung u ¨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 u ¨ bernimmt, kann man das u ¨ ber die Angabe einer Metrik3 regeln. Der Kernel benutzt als Gateway immer die Route mit der kleinsten Metrik, solange er sie erreichen kann. Falls diese nicht mehr verf¨ ugbar ist, greift er automatisch auf die Route mit der nächstkleineren Priorit¨ at zur¨ uck. F¨ ur das Beispiel soll Gateway 80.168.20.126 als Gateway f¨ ur eventuelle Ausf¨ alle von Gateway 132.230.129.14 dienen. F¨ ur diese Aufgabenstellung gen¨ ugt es, die Route zum Router 1 mit einer Metrik 1 zu definieren. Die Route zum Backup-Gateway erh¨ alt eine h¨ ohere 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¨ uhrt. 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¨ aferenz einer Route - je kleiner der Wert desto besser

¨ ¨ 6.3. UBERPR UFUNG DER KONFIGURATION

6.2.4

91

Dienste-basiertes Routing

Wenn sich Dienste und deren Administratoren an Standards halten, kann man sie anhand ihrer verwendeten Portnummern identifizieren. Die Datei /etc/services listet die Zuordnung von Portnummern zu Diensten auf. ip hat selbst keine Möglichkeit direkt in folgende Header, TCP oder UDP eines Datenpaketes zu schauen. Das können entweder tc oder besser das Netfilter Paket u ¨ 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¨ unstigeren Weg nehmen. Als erstes, werden alle ausgehenden SSH-Pakete mit dem Netfilter-Tool iptables durch eine ”1” gekennzeichnet. Das Label kann eine beliebige Zahl sein. linux02:~# --set-Mark linux02:~# linux02:~# linux02:~#

iptables -A OUTPUT -i eth0 -t mangle -p tcp --dport 22 -j MARK \ 1 echo 200 ssh >> /etc/iproute2/rt_tables ip rule add fwmark 1 table ssh ip route add default via 192.168.1.254 dev eth0 table ssh

Dann wird wieder eine Regel in der RPDB erstellt, die besagt, dass f¨ ur 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 u ¨ ber den schnellen Router 1.

6.3

¨ Uberpr u ¨ fung der Konfiguration

Den Erfolg einer IP-Konfiguration kann man am besten im Netz mit dem Befehl ping testen (das setzt einen weiteren Rechner mit garantiert funktionierender Netzwerkkonfiguration voraus!). ping IP-Adresse/Hostname sendet Datenpakte im Sekundenabstand an die angegebene IP-Adresse oder Rechnernamen4 . Ping5 kennt einige interessante Kommandoparameter, die sich auch zum Testen der Leistungsfähigkeit eines LAN’s eigenen. So lässt sich mit ”-c Zahl” die Anzahl der verschickten Pakete festlegen, ”-f” lässt den Systemadministrator so viele Pakete versenden, wie nur irgendwie geht und mit ”-s Zahl” lässt sich die Paketgrösse, die zum Test verschickt wird, variieren. Meldet ping keinen Erfolg6 , kann man mit dem Kommando tcpdump u ufen, ob ¨berpr¨ u ¨ berhaupt Datenpakete auf dem Netzwerkinterface eintreffen und vom Kernel registriert werden.

6.4 6.4.1

Aufgaben IP-Konfiguration und Erreichbarkeit

1. Wie bekommt man folgende Informationen heraus: IP Adresse, Routing Tabelle, eigene MAC-Adresse(n)? 2. Wie lautet die Netzwerkmaske des eigenen Subnetzes und wie kann diese verändert werden? 4

Dieses setzt jedoch einen funktionierenden Nameservice voraus! weitere Informationen kann man sich u ¨ ber den Aufruf der Manualseiten mit man ping anzeigen lassen. 6 das meint eine Meldung wie ”100” packet loss” 5

92

KAPITEL 6. LINUX IM NETZWERK 3. Warum muss die eigene Netzwerkmaske zu den Einstellungen des Subnetzes passen, in dem man sich befindet? Was passiert, wenn die Maske des Subnetzes kleiner oder größer als die auf der eigenen Maschine eingestellte ist? 4. Man organisiere sich die IP vom Nachbarn und versuche diesen per Ping zu erreichen. Wie erf¨ ahrt man seine eigene Default-Gateway-Adresse? 5. Wie erfahre ich die MAC-Adressen meiner Kommunikationspartner? Wie lauten die MAC-Adressen f¨ ur goe.net oder www.spiegel.de?

6.4.2

Datenverkehr z¨ ahlen

1. Welche ganz einfachen M¨ oglichkeiten hat man, um festzustellen, wieviel Datenverkehr von einer Maschine ins Netz geschickt oder empfangen wurde?

Kapitel 7

Wichtige Netzwerkkommandos 7.1

Offene Dateien und Netzwerkverbindungen

Das Kommando lsof (ListOpenFiles) zeigt die geöffneten Dateien (zum Lesen oder Schreiben) an und die dazugeh¨ orenden Prozesse. Weiterhin werden offene Sockets (Netzwerkverbindung mit Portadresse), sowie verwendete Pipes und Filesockets angezeigt.

7.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¨ uhrt 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 Uberblick verschaffen, welche Netzwerkverbindungen gerade maskiert werden: root@server:/ # netstat -M IP masquerading entries prot expire source tcp 0:40.46 1234.test.local tcp 0:45.64 1234.test.local tcp 0:49.43 1234.test.local

destination 210.24.30.216 210.24.30.216 210.24.30.216 93

ports 3592 -> 2183 (64155) 3593 -> 2187 (64156) 3594 -> 2188 (64157)

94

KAPITEL 7. WICHTIGE NETZWERKKOMMANDOS

tcp tcp ...

1:03.12 1234.test.local 210.24.30.216 3596 -> 2195 (64159) 0:54.57 1234.test.local 210.24.30.216 3595 -> 2192 (64158)

Wird die Option “-n” beim Aufruf des Kommandos aufgef¨ uhrt, wird keine Namensauflösung durchgef¨ uhrt, 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¨ ur 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 u ¨berschriebenen Spalten geben an, wie viele Pakete: • RX-OK/TX-OK fehlerfrei empfangen bzw. gesendet wurden • RX-ERR/TX-ERR wie viele besch¨ adigt 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¨ ur die Schnittstelle gesetzt sind. Das sind einbuchstabige Versionen der langen Flagnamen, die ifconfig ausgibt: Buchstabe B L M O P R U

Bedeutung BROADCAST LOOPBACK PROMISC NOARP POINTOPOINT RUNNING UP

Tabelle 7.1: Bezeichner

7.3 7.3.1

Systemprogramme D¨ amonen

Dämonen sind Programme, die sich nach Start von der Konsole lösen und im Hintergrund weiterlaufen. Sie bieten Serverdienste an oder f¨ uhren eine System¨ uberwachung durch. Die Steuerung erfolgt u ¨ ber die Start/Stopskripten.

7.4. NETZWERKKONFIGURATION

95

Als Superserver werden D¨ amonen bezeichnet, die weitere Serverdienste starten, wenn eine Anfrage auf dem entsprechenden Port erfolgt. Neben dem inetd wird der xinetd eingesetzt. Der Start von Serverdiensten bei Bedarf schont Ressourcen und wird vor allem bei ein¨ fachen Diensten genutzt. Ubliche Dienste sind daytime, time (beide u ¨ bermitteln die Uhrzeit), talk (damit k¨ onnen sich Konsolenbenutzer unterhalten), finger (Login-Informationen von Anwendern abfragen), ident (Identifikation von Anwendern) und gelegentlich auch ftp oder samba. Meist wird der Name des Programms aus dem Protokoll und einem angehängten d gebildet. Wird das Programm in der Regel u ¨ber einen Superserver gestartet, wird ausserdem ein in. vorangestellt. Aus dem Protokoll talk ergibt sich so der Name der ausf¨ uhrbaren Datei, in.talkd . Etliche dieser Dienste werden in diesem Skript in eigenen Kapiteln behandelt.

7.4

Netzwerkkonfiguration

Die Konfiguration von Netzwerkschnittstellen wird mit ifconfig erledigt, bei WLAN hat iwconfig einige zus¨ atzliche Optionen f¨ ur den Funkbetrieb. Das Tool ip ist die modernere Version von ifconfig und erlaubt deutlich mehr Einstellungen, auch von Routen. route erlaubt die Manipulation und das Anzeigen der Routinginformationen. Das alte nslookup und modernere dig dienen der Abfrage von DNS in Kommandozeile.

7.4.1

Netzwerktests

Das Kommando ping ist Teil jeder Linux-Distribution. Das Programm sendet ein spezielles Datagramm u ¨ber das Netzwerk an einen anderen Rechner. Wenn dieser eingeschaltet ist und es empf¨ angt sendet er es wieder zur¨ uck und man weiß, dass Rechner und Netzwerk in Ordnung sind. In der einfachsten Form sieht das so aus: dirk@randy2:~/vorlesung/lak> ping login PING login (132.230.1.143) from 132.230.9.124 : 56(84) bytes of data. 64 bytes from login3 (132.230.1.143): icmp_seq=1 ttl=63 time=4.44 ms 64 bytes from login3 (132.230.1.143): icmp_seq=2 ttl=63 time=0.219 ms 64 bytes from login3 (132.230.1.143): icmp_seq=3 ttl=63 time=0.217 ms 64 bytes from login3 (132.230.1.143): icmp_seq=4 ttl=63 time=0.218 ms ^C --- login.ruf.uni-freiburg.de ping statistics --4 packets transmitted, 4 received, 0% loss, time 3030ms rtt min/avg/max/mdev = 0.217/1.275/4.448/1.831 ms

ping sucht zun¨ achst die richtige IP-Adresse zu dem angegebenen Rechnernamen heraus1 und sendet dann in regelm¨ aßigen Abst¨ anden ein bestimmtes Datagramm an diese Adresse. F¨ ur jeden dieser icmp echo requests wird der andere Rechner dann ein icmp echo reply als Antwort zur¨ ucksenden. Jede der Zeilen 64 bytes from ... stellt eine solche empfangene R¨ uckantwort 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¨ ur die Geschwindigkeit des Netzwerkes. ping w¨ urde endlos weiter seine Pakete senden, deshalb muß es abgebrochen werden. Dies geschieht durch gleichzeitiges Dr¨ ucken der Tasten Control (Strg) und C. Danach gibt 1

Voraussetzung ist nat¨ urlich, dass /etc/hosts und der Nameserver richtig konfiguriert sind

96


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¨ urzeste, längste und mittlere Antwortzeit. Eine hohe Verlustrate an Paketen deutet auf Probleme mit der Verbindung hin, diese k¨ onnen durch schlechte Verbindungen, u ¨ berlastete Router oder Kollisionen im lokalen Ethernet verursacht werden. Man kann mit ping die schadhafte Stelle lokalisieren, indem man nacheinander alle Knotenpunkte der Verbindung anpingt 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¨ ucklegen, testen und anzeigen. Wie auch ping verwendet traceroute dazu das icmp Protokoll. Es verwendet jedoch einen Trick, um von jeder durchlaufenen Knotenstelle eine R¨ uckmeldung zu bekommen, und das geht so: Das Feld time to live eines icmp-Datagramms dient eigentlich dazu, zu verhindern, dass das Datenpaket ewig im Netz herumgeschickt wird, z.B. wenn es in eine RoutingEndlosschleife ger¨ at. 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¨ unglichen Absender des Datagramms senden um ihm mitzuteilen, dass das Datagramm ‘abgelaufen’ ist. traceroute sendet nun nacheinander Datagramme ab, deren time to live (beginnend bei eins) jeweils um eins erhöht wird. Indem es nun die eingehenden “icmp time to live expired Meldungen” auswertet, kann es genau den Weg, den die Datagramme nehmen, verfolgen - bis der wirkliche Zielrechner erreicht ist. Das sieht dann so aus: dirk@test:~/vorlesung/lak> /usr/sbin/traceroute goe.net traceroute to goe.net (134.76.60.86), 30 hops max, 40 byte packets 1 132.230.22.254 2.735 ms 5.013 ms 7.667 ms 2 132.230.223.254 0.707 ms 0.832 ms 0.721 ms 3 nsc-rz-gwn.fun.uni-freiburg.de (132.230.0.141) 0.386 ms 0.355 ms \ 0.307 ms 4 Freiburg1.Belwue.DE (129.143.15.141) 0.576 ms 0.545 ms 0.496 ms 5 Stuttgart1.BelWue.DE (129.143.1.7) 3.813 ms 4.605 ms 0.573 ms 6 Stuttgart2.BelWue.DE (129.143.1.34) 4.523 ms 4.521 ms 4.520 ms 7 Frankfurt1.BelWue.DE (129.143.1.26) 8.393 ms 8.335 ms 8.304 ms 8 ffm-b2-geth0-1.telia.net (213.248.79.41) 8.592 ms 8.668 ms 8.713 ms 9 ffm-b2-geth0-1.telia.net (213.248.68.33) 8.558 ms 8.531 ms 8.503 ms 10 ffm-bb2-pos2-3-0.telia.net (213.248.64.177) 8.745 ms 8.692 ms 8.662 ms 11 hbg-bb2-pos1-1-0.telia.net (213.248.65.2) 18.104 ms 18.057 ms 18.129 ms 12 hbg-b1-pos1-0.telia.net (213.248.68.6) 18.047 ms 18.000 ms 17.993 ms 13 dante-01616-hbg-b1.c.telia.net (213.248.103.98) 17.439 ms 17.800 ms \ 17.487 ms 14 cr-hannover1.g-win.dfn.de (188.1.18.178) 199.467 ms 199.447 ms \ 199.511 ms 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¨ ur drei aufeinanderfolgende Datagramme an diesen Rechner. Der erste Punkt in der Verbindung ist also der Rechner 22.254. Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales Ethernet. Am nächsten Router kommen die Datagramme sehr viel langsamer zur¨ uck als von dem

7.4. NETZWERKKONFIGURATION

97

ersten Hop. Der Grund ist hier eine sehr langsame Verbindung u ¨ ber eine Funkstrecke. Der letzte Knoten ist der gesuchte Rechner, goe.net. Auch hier kommen die Antworten nur sehr langsam. Dies liegt aber daran, dass die Antwortzeit jedes Rechners nat¨ urlich die Summe der Verbindungszeiten aller dazwischenliegenden Teilstrecken ist. Ber¨ ucksichtigt man diese Aufsummierung der Zeiten, so sieht man, dass die letzte Verbindung ebenfalls sehr schnell ist. Diese beiden Rechner h¨ angen 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¨ ur, dass ein Router nicht wußte, wohin er das Datagramm weiterleiten soll. Er sendet dann ein network unreachable Datagramm an den Absender zur¨ uck. 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).

7.4.2

Netzwerku ¨berwachung

tcpdump kann die gesamte Aktivit¨ at auf dem Netzwerk u ¨berwachen indem es sämtliche Datagramme auf dem Weg in den eigenen 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¨ uche aufzusp¨ uren. 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 u ¨ ber die richtige Schnittstelle verlassen oder, um zu u ufen, ob irgendwelche Datagramme von ¨ berpr¨ 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 18:25:52.649154 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25:54.648119 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25:56.650810 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25:58.182266 132.230.9.254 > OSPF-ALL.MCAST.NET: OSPFv2-hello 44: rtrid 132.\ 230.200.141 backbone dr 132.230.9.254 [ttl 1] 18:25:58.183882 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain: 25558+ PTR? 254.9.230.132.in-addr.arpa. (44) (DF) 18:25:58.186580 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: 25558 NXDomain* 0/1/0 (137)

98


18:25:58.187051 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain: 25559+ PTR? 5.0.0.224.in-addr.arpa. (40) (DF) 18:25:58.189666 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: 25559 1/4/4 PTR [|domain] 18:25:58.207177 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain: 25560+ PTR? 141.200.230.132.in-addr.arpa. (46) (DF) 18:25:58.210175 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: 25560 NXDomain* 0/1/0 (141) 18:25:58.210747 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain: 25561+ PTR? 200.200.230.132.in-addr.arpa. (46) (DF) 18:25:58.213119 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: 25561* 1/2/2 (173) 18:25:58.649731 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 14 packets received by filter 0 packets dropped by kernel

Wenn tcpdump ohne Argumente gestartet wird, wird das Netzwerk-Device mit der kleinsten Nummer, das kein Loopback-Device ist, u ¨berwacht. Es kann aber - wie im Beispiel auch ein spezielles Device angegeben werden. tcpdump dekodiert dann jedes Datagramm das u ¨ ber diese Device u ¨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 u ¨ bermittelt wurde (es zeigt vom Sender zum Empfänger). 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 8

Domain Name Service 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 u ¨ 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¨ uber 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¨ ummert sich der Domain Name Server. Auch f¨ ur diese Aufgabe bietet sich Linux an.

8.1.1

Enstehungsgeschichte

DNS ist inzwischen untrennbar mit dem Internet verkn¨ upft. Rechner im weltweiten Internet werden in der u ¨ berwiegenden Zahl u ¨ber ihren Namen und nicht u ¨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¨ onnen sich schliesslich Namen besser merken als Telefonnummern. Wenn auch das Beispiel sich nicht direkt u ¨bertragen lässt, zeigt es die Bedeutung. Jeder kennt www.google.de. Kaum aber jemand weiss, dass beim Ansurfen der Seite aus Deutschland1 der Browser eine Verbindung zu IP 66.102.9.99 oder 66.102.9.104 aufbaut. Wer wissen möchte, wie der Browser den Namen zur Adresse mit Hilfe der Systembibliotheken auflöst, gibt einfachmal das Kommando host ein. dirk@linux:~> host www.google.de www.google.de is an alias for www.google.com. www.google.com is an alias for www.google.akadns.net. www.google.akadns.net has address 66.102.9.99 www.google.akadns.net has address 66.102.9.104

Das Netz kann aber ausschliesslich mit Binäradressen umgehen - auch die besser lesbare ¨ Dotted Quad Notation aus dem Beispiel ist nur eine Ubersetzung f¨ ur den menschlichen 1

je nach Provider, da es oft erstmal ein Proxy ist

99

100

KAPITEL 8. DOMAIN NAME SERVICE

Benutzer. Deshalb wird ein System f¨ ur die Zuordnung von Namen zu Adressen - und umgekehrt benötigt. Am Anfang ging es mit einer einfachen Textdatei los. Diese Textdatei gibt es immer noch. In kleinen Netzen oder zu Zeiten in denen Ihre Maschine keine Netzwerkverbindung zu einem DNS-Server hat, soll sie trotzdem Namen und IPs zuordnen können: # /etc/hosts # Syntax: # IP-Address ::1 fe00::0 ff00::0 ff02::1 ff02::2

Full-Qualified-Hostname Short-HostnamePv6 addresses ipv6-localhost ipv6-loopback ipv6-localnet ipv6-mcastprefix ipv6-allnodes ipv6-allrouters

127.0.0.1 localhost 10.8.4.101 dionysos.mydomain.site dionysos # resolv other machines without DNS 10.8.4.205 aphrodite.wg.site 10.8.4.206 athene.wg.site [ ... ] 10.8.4.250 thetis.wg.site

aphrodite athene thetis

¨ Ublicherweise 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¨ ur 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¨ osen. Da gehen dann schnell die Probleme los: Nicht immer sind alle Rechner gleichzeitig an. Dann ist die Verteilung unvollst¨ andig. Bei häufigen Updates steigt mit der Zahl der Rechner und der Eintr¨ age die Fehlerwahrscheinlichkeit und ziemlich schnell hat der Admin keine Lust mehr. Das ging den Betreibern der fr¨ uhen IP-Netze genau so. Das fr¨ uhe 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 ei¨ ner einzigen ”flachen” Datei liess sich nicht mehr aufrecht erhalten. Fragen der Ubersichtlichkeit, Ausfallsicherheit und Redundanz liessen sich mit dem Dateikonzept nicht u ¨ 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¨ osen liesse. Das neue System sollte dabei dezentral verteilt, ausfallsicher sein und die Datenbest¨ ande 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¨ ugbar. 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¨ uheren Versionen auf 255 Maschinen beschränkt war. WINS ist ein System f¨ ur LANs - ohne große Benutzereingriffe verständigen sich die beteiligten Maschinen u ¨ ber ihre Namen. Sie verursachen dabei aber einen nicht unerheblichen

8.1. EINSTIEG

101

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¨ urzel. 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¨ urzel nach ISO 3166. Die Vergabe der TLDs wird vom ICANN koordiniert. Unterhalb dieser Hierarchiestufe kann man selbst, als Organisation oder Firma Domains registrieren, wobei die Vergabe durch das jeweils zust¨ andige NIC (Network Information Center) erfolgt. Ab den folgenden Hierarchiestufen habt der Admin dann fast volle Freiheit, wenn er sich nur an die Benennungsstandards h¨ alt. 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¨ agstrich (/), durch einen Backslash (\) bei Windows voneinander getrennt. Diese Struktur findet sich in weiteren Bereichen. Telefonnummern folgen international einem ¨ ahnlichen Prinzip: Zuerst findet man den Ländercode (+49), dann die Orts-Vorwahl (551) und schliesslich die Anschlussnummer (654321). Genauso setzt sich der komplette Rechnername2 aus mehreren Teilen zusammen. Ausser dass als Trennelement der einzelnen Ebenen der Punkt (.) verwendet wird. Anders als in den beiden vorgenannten Beispielen dreht sich die Reihenfolge von Allgemein zu Speziell um: Der Rechnername steht links, gefolgt von den Zwischenebenen bis zur Wurzel, die rechts steht. So ist beispielsweise in www.goe.net ”www” ein Name f¨ ur 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 fu ¨r die Namensgebung

Damit am Ende die selbstgetauften Rechner der eigenen Domain im weltweiten Netz auch gefunden werden k¨ onnen, geht es nicht ohne Standards ab. F¨ ur die Zusammensetzung eines g¨ ultigen 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¨ ange des FQDN darf 255 Zeichen inklusive der Punkte nicht u ¨ berschreiten. • Erlaubt sind die alphanumerischen Zeichen 0-9 und a-z. Groß- und Kleinschreibung spielt keine Rolle. Zus¨ atzlich m¨ oglich 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¨ ur 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

102


F¨ ur 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¨ ur die Abfrage an den Nameserver um. Das Ergebnis des Beispiels sieht dann so aus xn–jrg-sna.xn–hnssler-5wa.de. Viele Web-Browser beherrschen inzwischen den Umgang mit IDN, viele andere ClientProgramme jedoch nicht. So liefert zwar www.m¨ uller.de ein Ergebnis im Konqueror, ein ping www.m¨ uller.de jedoch nur ein lapidares ”unknown host www.m¨ uller.de”. Ein ping auf die ACE-Umschrift (hier www.xn–mller-kva.de) klappt nat¨ urlich. Die Längenbegrenzung des Teilstrings bleibt bestehen. So können Umlautdomains nicht die Länge von 63 Zeichen erreichen, da noch Platz f¨ ur die Umschrift einzuplanen ist. F¨ ur nicht ¨ offentliche Netze ist man nicht zwangsläufig an vorgegebene Toplevel-Domains gebunden, man kann sich einfach eine aussuchen. Wenn man jedoch f¨ ur sein privates Netz einfach eine offizielle Domain w¨ ahlt, wie beispielsweise testnetz.de, dann könnten Nutzer verwirrt werden. Sie w¨ urden 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¨ ur selbstkonfigurierende lokale Netze3 gedacht

8.1.4

Registrieren und Verwalten von Domains

Organisationen, Privatpersonen, Firmen registrieren immer eine Second-Level-Domain, die unterhalb einer dieser Toplevel-Namen liegt. Mit der Registrierung beispielsweise von ”goe” unterhalb von ”net” wurde dem Autor die Domain goe.net zugeordnet. Damit folgt nicht automatisch auch die Existenz von Domains, wie goe.org oder das Nutzungsrecht darauf. So musste beispielsweise die Firma Google die verschiedenen Domains google.com, google.net, google.de oder google.us einzeln registrieren. Die Abbildung zeigt einen symbolischen Auscountry

generic

Toplevel Domains de

fr

Second Level Domains

gwdg

net mil

uk

goe

org

com

kernel

edu

google

uni-freiburg ftp

www www

ftp

www

ftp

www

linux

ks

Part of Domain Name Space www

Abbildung 8.1: Ausschnitt aus dem Namensraum schnitt aus dem DNS-Namensraum des Internets. Neben den urspr¨ unglich festgelegten dreibuchstabigen generischen Toplevel-Domains und den Länderk¨ urzeln sind in j¨ ungster 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 u ¨ber verschiedene Registrare eingetragen werden. 3

Apple nennt diesen Dienst Rendevouz. Unter Linux gibt es daf¨ ur den mdnsd Dienst, der dynamisches DNS in lokalen Netzen bereitstellt.

8.2. IMPLEMENTATION

103

F¨ ur die einzelnen Toplevel-Domains ist nicht eine Organisation oder Firma zuständig. F¨ ur 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¨ ur den Betrieb des Nameservers dieser Domain zuständig ist und weitere Daten sind in der sogenannten whois-Datenbank gespeichert. Fr¨ uher liessen sich diese Informationen per Kommandozeilen-Tool direkt abfragen, nun geht es nur noch u ¨ 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¨ ugung eine Domain zu ”konnektieren”, d.h. im Internet erreichbar zu machen. Der u ¨ bliche Weg ist die ”Delegation”. Das bedeutet, dass in den DENIC-Datenbanken die Adressen von mindestens zwei (maxi¨ mal f¨ unf) Nameservern vermerkt werden. Ublicherweise 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 sich deshalb in folgendem Spektrum bewegen (Angaben in Sekunden): Eine alternative Möglichkeit eine Domain Variable refresh retry expire ttl

Geforderte Zeiten in Sekunden 10000 - 86400 1800 -28800 604800 - 3600000 180 - 345600

Tabelle 8.1: Einstellungen im SOA zu konnektieren besteht darin, dass auf dem Nameserver des Registrars ein bis zu einige ”Dienste”, die mit dieser Domain zusammenhängen direkt eingetragen werden. So können beispielsweise www.¡Name der Domain¿.de oder ftp.¡Name der Domain¿.de direkt mit einer IP-Adresse registriert werden. Dieses Verfahren wird als Konnektierung mittels NSentryEinträgen bezeichnet. Das spart den eigenen Nameserver und macht bei kleinen Domains mit wenigen Diensten Sinn.

8.2

Implementation

Ein Nameserver ist niemals f¨ ur 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¨ ummert, 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¨ ane 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¨ andigkeiten

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¨ ussen aber nicht in einem gemeinsamen IP-Subnetz liegen. Sie haben auch sonst nicht viel gemein oder m¨ ussen in irgendeiner weitergehenden Beziehung zueinander stehen.

104


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¨ ur eine solche Domain zuständig oder deren Eigent¨ umer, betreibt man einen Nameserver. In diesem kann man dann beliebige Rechnernamen eintragen oder SubDomains festlegen. So ist ks.uni-freiburg.de eine Subdomain von uni-freiburg.de. Wenn man sich diese Organisation n¨ aher anschaut, stellt man fest, dass die Domainnames hierarchisch aufgebaut sind. Trotzdem ist nur ein Nameserver f¨ ur diese Domain verantwortlich. Dieser Nameserver ist ”autoritativ”. Die bis zu vier weiteren Nameserver, die man bei der Registrierung angeben kann, erf¨ ullen 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¨ urzester Verzögerung beantwortet werden. Durch Delegation wird die Autorität f¨ ur Subdomains auf andere Nameserver u ¨ 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 u ¨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¨ ost werden soll? Die oberste Ebene bei den Nameservern bilden die sogenannten Root-Nameserver. Sie sind gleichzeitig autoritativ f¨ ur die Top Level Domains. Diese kennen wiederum die verantwortlichen Nameserver f¨ ur 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¨ osung 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¨ origen 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¨ ur eine gewisse Hierarchie (solange die Subnetzaufteilung entlang der Punkte erfolgt) der IP-Adressen: 134.76.0.0 ist als IP-Netz an die Universit¨ at G¨ ottingen 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¨ ur die umgekehrte Auflösung das Konzept der hier-

8.3. DNS-SERVER MIT LINUX

105

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¨ onnen selbstst¨ andig Anfragen weiterleiten, falls sie nicht selbst f¨ ur 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¨ ur eine gewisse Zeit zwischen (Caching). Die Aufbewahrungsdauer f¨ ur einen Eintrag ist jedoch nicht trivial zu bestimmen. Es gibt Server deren IP-Adressen sich jahrelang nicht ¨ andern. Es gibt aber auch Maschinen, die beispielsweise per DHCP eine dynamische Adresse beziehen und nur f¨ ur eine gewisse (kurze) Zeit aktiv sind. Oder Site-Betreiber nutzen DNS zur Lastverteilung verschiedene Server und reichen deshalb verschiedene IPs f¨ ur dieselbe Adresse heraus4 . Wie lange dieser Eintrag beibehalten werden soll, legt der verantwortliche Serverbetreiber der Zone mit der Time-To-Live (TTL) fest. Welche Möglichkeiten einem hier zur Verf¨ ugung stehen, kl¨ art der Abschnitt zur Einrichtung eines BIND DNS-Servers. Dar¨ uber hinaus merkt sich der anfragende Server den autoritativen Nameserver f¨ ur die jeweiligen Zonen. So vermeidet er, dass bei der Auflösung nicht alle Instanzen der Hierarchie durchlaufen werden m¨ ussen. 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¨ ur einen bestimmten Zeitraum gemerkt, damit nicht jedes Mal auf ein Timeout gewartet werden muss - diese Zeit wird allerdings vom urspr¨ unglich befragten Nameserver selbst vorgegeben.

8.2.3

Prim¨ arer und sekund¨ are Nameserver

Beim Entwurf von DNS wurde sehr viel Wert auf Ausfallsicherheit gelegt. Aus diesem Grund ist es u ur eine Zone zu betrei¨blich, statt eines einzigen gleich mehrere Nameserver f¨ ¨ ben. Sekundäre Nameserver werden bei Anderungen der Zonendaten durch den primären benachrichtigt. Sie holen sich dann die aktuellen Zoneninformationen (Zonentransfer). Generell gilt: Es gibt immer nur ein prim¨ arer aber bis zu vier sekundäre Nameserver. Heute haben sich allerdings f¨ ur den primären Master-Nameserver die Bezeichnung Master und f¨ ur die sekund¨ aren 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¨ ur unterschiedliche Zonen sein kann, ist diese Unterscheidung nicht immer eindeutig.

8.3

DNS-Server mit Linux

Nameserver geh¨ oren 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 u ¨berhaupt gefunden wird. Damit ist nicht der Eintrag in Suchmaschinen gemeint, sondern die Auflösung des Domain-Namens in eine IP-Adresse. F¨ ur eine ganze Reihe von Anwendungen, wie Mail ist auch die umgekehrte Auflögung von einer IP zu einem FQDN erw¨ unscht. 4

siehe das Eingangsbeispiel f¨ ur google.de

106


Ein Großteil der weltweiten DNS-Server laufen inzwischen auf einer Kombination von Linux und BIND. Bind9 besteht aus mehreren Paketen und ist f¨ ur alle aktuellen LinuxDistributionen verf¨ ugbar.

8.3.1

Der D¨ amon

¨ Ublicherweise wird f¨ ur den DNS der Bind verwendet. Der Dienst, der später als Daemon im Hintergrund l¨ auft heisst named. Das dazugehörige Startskript /etc/init.d/bind9 unter Debian und /etc/init.d/named f¨ ur 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¨ ur die bessere ¨ Ubersichtlichkeit in eine weitere Datei named.conf.options oder ähnliche ausgelagert. In dieser Datei kann man beispielsweise die Forwarder definieren und Access Control Lists (ACLs) f¨ ur den Zugriff auf den Server festlegen. Auf diese Weise legt beispielsweise das Keyword ”listen-on” f¨ ur das u ¨ 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¨ ur externe Anfragen offen ist. So können Angreifer nicht per DNS erfahren, wie das interne Netz strukturiert sein k¨ onnte. Statt der Angaben von IP-Adressen oder Netzen lassen sich vor dem ”options”-Block auch ACLs definieren: acl localnet 10.8.4.0/24; 10.8.10.0/24; ; Diese tr¨ agt man dann direkt ein: listen-on port 53 localnet; ; Das Keyword ”listen-on-v6” regelt das Ganze f¨ ur 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¨ uhren. ; /etc/bind/named.conf include "/etc/bind/named.conf.options"; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; 5

Andere Distributionen legen die Konfigurationsdateien und Daten oft woanders ab, beispielsweise unterhalb von /var/lib/named. Wenn man sich an der named.conf orientiert, findet man alle weiteren Dateien schnell, weshalb in der Darstellung nicht weiter auf Spezialit¨ aten einzelner Distributionen eingegangen wird.

8.3. DNS-SERVER MIT LINUX

107

}; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; include "/etc/bind/named.conf.local";

In der named.conf sind eine Reihe spezieller Zonen bereits definiert. So enthält die Datei db.root die Liste aller 16 Root-Nameserver. Ein Großteil dieser Maschinen steht in den USA, einige in Europa und eine Maschine in Japan. Ihre IP-Adressen sind fix. Diese Server werden iterativ befragt, wenn der eigene DNS eine Adresse nicht auflösen kann. Die Zone ”.” ist deshalb vom Typ ”hint” - der Nameserver ist f¨ ur 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¨ ur 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 u ¨ berhaupt ins Netz gelangen. Jeder Rechner mit installiertem IP-Stack hat auf dem Loopback-Interface u ¨blicherweise die IP-Adresse 127.0.0.1 definiert. Auch mit solchen Anfragen sollten keine entfernten Nameserver behelligt werden. Das gilt ebenfalls f¨ ur IP-Adressen, die 6 mit einer 0 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 Ubersichtlichkeit 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¨ ur die Master-Zonen ist der Server authoritativ, die SlaveZonen kopiert er definiert durch die Update-Festsetzungen vom f¨ ur 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¨ ur die R¨ uckw¨ artsaufl¨ osung 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¨ ur 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

108


Wie bereits erw¨ ahnt wurde, ist es m¨ oglich 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¨ upft 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¨ ur die Aufl¨ osung von Hostnamen nach IP-Nummern: ; /etc/bind/wg.site $TTL 360 ; 6 minutes @ IN SOA

IN NS 10 mail.wg.site. IN MX ns IN A nameserver IN CNAME $TTL 86400 ; 1 day mail IN A mail-backup IN A anphrodite IN A dionysos IN A $TTL 360 ; 6 minutes demeter IN A hermes IN A IN HINFO IN TXT

ns.wg.site. dirk.wg.site. ( 2005011002 ; serial 28800 ; refresh (8 hours) 1800 ; retry (30 minutes) 3600000 ; expire (5 weeks 6 days \ 16 hours) 86400 ; minimum (1 day) ) ns.wg.site.

IN MX

20 mail-backup.wg.site. 10.8.4.25 ns 10.8.4.21 10.8.4.22 10.8.4.203 10.8.4.204 10.8.4.251 10.8.4.252 "AMD Opteron" "Linux" "WG-DNS for PE28"

In den Zonendateien ist jeder mit einem Punkt ”.” endende Rechnername ein exakter Rechnername. Alles, was ohne den abschließenden Punkt geschrieben wird, bezieht sich auf den Ursprung (hier wg.site). Damit w¨ urde aus dem Namen ns.wg.site f¨ ur BIND ns.wg.site.wg.site werden, sicherlich nicht die Intention des Zonenadmins. hermes steht daher f¨ ur ”hermes.Ursprung”. In der Beispielzonendatei ist wg.site. der Ursprung, damit wird aus hermes hermes.wg.site. Ein Beispieleintrag f¨ ur die umgekehrte Auflösung: $TTL 360 @

254 $TTL 86400 21 22 203

; 6 minutes IN SOA ns.wg.site. dirk.goe.net. ( 2005011002 ; serial 28800 ; refresh (8 hours) 1800 ; retry (30 minutes) 3600000 ; expire (5 weeks 6 days 16 hours) 86400 ; minimum (1 day) ) IN NS ns.wg.site. IN PTR ns.wg.site. ; 1 day IN PTR mail.wg.site. IN PTR mail-backup.wg.site. IN PTR aphrodite.wg.site.

8.3. DNS-SERVER MIT LINUX 204 $TTL 360 251 252

109

IN PTR dionysos.wg.site. ; 6 minutes IN PTR demeter.wg.site. IN PTR hermes.wg.site.

TTL gibt die Lebensdauer aller Eintr¨ age in der Zone an, die kein ausdr¨ uckliches TTL besitzen, welches vor dem IN als Integer-Sekunden-Wert eingetragen werden w¨ urde.

8.3.3

Starten und Anhalten des Nameservers

Nachdem Sie Ihre Zonendateien f¨ ur die Vorwärts- und R¨ uckwä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 u ¨ ber ”stop” oder ”restart”. Eventuell auftretende Fehlermeldungen liefert named in der Datei /var/log/syslog ab. Hier u uft man, ob alle Ihre Zonenfiles ohne Beschwerden akzeptiert wurden. Im ¨berpr¨ Logfile liefert named Informationen auf welchen Interfaces er lauscht, wieviele Prozessoren er in Anspruch nimmt und welche Zonenfiles er erfolgreich eingelesen hat. Wenn Sie den Dienst automatisch beim Hochfahren der Maschine starten wollen, sollten Sie einen entsprechenden Link in den Runlevelverzeichnissen auf das Startskript /etc/init.d/bind9 anlegen. Feb 11 21:17:57 linux04 named[13692]: starting BIND 9.2.4 -u bind Feb 11 21:17:57 linux04 named[13692]: using 1 CPU Feb 11 21:17:57 linux04 named[13694]: loading configuration from ’/etc/bind/named.conf’ Feb 11 21:17:57 linux04 named[13694]: no IPv6 interfaces found Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0, 10.8.4.254#53 Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0:1, 192.168.1.2#53 Feb 11 21:17:57 linux04 named[13694]: zone ’wg.site’ allows updates by IP address, which is insecure Feb 11 21:17:57 linux04 named[13694]: zone ’4.8.10.in-addr.arpa’ allows updates by IP address, which is insecure Feb 11 21:17:57 linux04 named[13694]: command channel listening on 127.0.0.1#953 Feb 11 21:17:57 linux04 named[13694]: zone 0.in-addr.arpa/IN: loaded serial 1 Feb 11 21:17:57 linux04 named[13694]: zone 4.8.10.in-addr.arpa/IN: loaded serial 2002100405 Feb 11 21:17:57 linux04 named[13694]: zone 127.in-addr.arpa/IN: loaded serial 1 Feb 11 21:17:57 linux04 named[13694]: zone 255.in-addr.arpa/IN: loaded serial 1 Feb 11 21:17:57 linux04 named[13694]: zone localhost/IN: loaded serial 1 Feb 11 21:17:57 linux04 named[13694]: zone wg.site/IN: loaded serial 2002100405 Feb 11 21:17:57 linux04 named[13694]: running

8.3.4

Slave-Server

Bisher beschäftigte sich die Darstellung mit dem Aufsetzen eines primären DNS und dem Anlegen der Zonen-Dateien. Wenn nicht lediglich ein privater DNS betrieben wird, sollte

110


man unbedingt aus Gr¨ unden 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¨ ur 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 u ugen. Hier landen die Daten ¨ber Schreibrechte verf¨ 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 Anderung vorgenommen wurde. Quasistandard ist ein JJJJMMTTRR-Format, um die Seriennummer festzulegen. 2005011002 steht also f¨ ur den 10.01.2005, die beiden letzten Stellen f¨ ur die zweite Modifikation der Zonendatei an diesem Tag. Nun ist diese Zahl oft nicht so u bersichtlich, ¨ als dass man nicht versehentlich einen Fehler macht und eine Stelle zuviel drin hat. Wenn die Slaves eine solche Seriennummer u ¨bernommen haben und anschliessend auf dem Master wieder eine korrigierte Nummer eingetragen ist, bekommen sie kein Update mehr mit. Ihre Nummer ist immer gr¨ oßer als die des Masters. Um dieses Dilemma in den Griff zu bekommen, kann man den folgenden Trick anwenden: Man trage 231 − 1 (=2147483647) ein. BIND arbeitet mit vorzeichenbehafteten 32 bit Zahlen. So ist diese der größtmögliche Wert und in der n¨ achsten Runde wird wieder jede beliebige Seriennummer von den Slaves als Grund f¨ ur ein Update akzeptiert. In den Beispielen wurde eine strenge Trennung von Master- und Slave-Servern angenommen. Das muss nat¨ urlich in der Realit¨ at nicht so sein. Hier sind viele Server authoritativ f¨ ur eine Reihe von Zonen und sekund¨ ar f¨ ur eine Anzahl anderer Zonen.

8.3.5

Delegation einer Subdomain

In den bisherigen Beispielen stimmte eine Zone immer mit einer Domain u ¨ berein. Ein Nameserver war f¨ ur den gesamten Namensraum zuständig. Dieser war einfach strukturiert: maschinenname.domain.topleveldomain, z.B. hermes.wg.site. Nun erlaubt DNS aber Teile seines Namensraumes an andere Nameserver zu delegieren. So können Admins bestimmter organisatorischer Einheiten ”ihre” Zone verwalten. Mit folgendem Eintrag in der Zonendatei des Beispiels (/etc/bind/db.wg.site) delegiert der Nameserver die Zone, in diesem Fall die Subdomain sub.wg.site an die Server ns1.sub.wg.site und ns2.sub.wg.site. [ ... ] sub ns1.sub ns2.sub [ ... ]

IN IN IN IN

NS NS A A

ns1.sub.wg.site. ns2.sub.wg.site. 10.8.5.1 10.8.5.2

Der Resource-Record NS regelt die Delegation. Damit weiss der Nameserver, dass Anfragen auf *.sub.wg.site an die daf¨ ur zust¨ andigen Server ns1 und ns2.sub.wg.site weitergereicht werden. Deren Namen m¨ ussen nat¨ urlich ebenfalls zu IP-Adressen aufgelöst werden können. Deshalb sind die beiden Nameserver ebenfalls mit einem A-Record vertreten.

8.4. DYNAMISCHE UPDATES DER ZONENDATEIEN

8.4

111

Dynamische Updates der Zonendateien

Mit steigender Anzahl verwalteter Zonen und Hosts wird das Verfahren der händischen Manipulation der Zonendateien f¨ ur Admins schnell aufwändig. Nebenher hat sich die Zahl mobiler Endger¨ ate deutlich ausgeweitet. Das sind Hosts, die oft in verschiedenen Netzen betrieben werden. Zudem sind sie oft nicht sehr lange angemeldet. Hier w¨ unscht man sich ein Verahren, was a hnlich zu WINS dynamisch arbeitet. ¨ ¨ Mit BIND seit Version 8 kann man dynamische Anderungen an den Resource Records vornehmen (lassen), ohne daf¨ ur Dateien editieren und diese neu laden zu m¨ ussen. Solche ¨ Anderungen k¨ onnen auch durch externe Dienste, wie DHCP angestoßen werden. Um dieses zu erlauben, muss der Admin eine zus¨ atzliche Zeile in die Zonendefinition einf¨ ugen: zone "wg.site." IN { ... allow update { 172.0.0.1; }; }

Im Beispiel ist nur das Update von der Loopbackadresse erlaubt. Man kann nat¨ urlich auch Listen von IP-Adressen oder ACLs angeben. Dabei ist jedoch zu beachten, dass bei der Daten¨ ubertragung u usselt. Wie man dieses ¨ ber das Netz DNS nicht automatisch verschl¨ 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¨ ugt 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¨ ugen eines Eintrages angelegt. Alle 15 Minuten macht BIND einen Dump der Zonendatei mit den neuen oder ohne die zwischendurch entfernten Einträge und erh¨ oht dabei die Seriennummer automatisch.

8.4.1

Sicherheit

Wie man im Beispiel sehen konnte, benötigte nsupdate keine besondere Authentifizie¨ rung, um Anderungen an den DNS-Daten vorzunehmen. Eine Absendeadresse ist leicht zu fälschen, weshalb man sich schnell einen besseren Schutz w¨ unscht. 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¨ ussel abh¨ angig. Der Hashwert wird u ¨ 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.

112


Das Bastelset zum Erzeugen der Schl¨ ussel liefert BIND mit dnssec-keygen. Der Aufruf dnssec-keygen -b 128 -a HMAC-MD5 -n HOST hermes.wg.site generiert einen 128bitSchl¨ ussel, 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 ¨ offentlichen Schl¨ ussel in der anderen *.private den privaten. Den offentlichen Schl¨ ussel l¨ aß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¨ ussels herangezogen werden. Den privaten Schl¨ ussel hinterlegt man in der Datei mit den Zonendefinitionen /etc/bind/named.conf.local: key hermes.wg.site. { algorithm hmac-md5; secret "Geq/RRYhuAIrlUzJKj49MQ=="; }; und sorgt daf¨ ur, dass nur noch ein Update unter Angabe des Schl¨ ussels erfolgen darf: zone "wg.site" in { type master; file "/etc/bind/db.wg.site"; allow-update { key hermes.wg.site.; }; };

¨ Nach den Anderungen 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¨ ussel: nsupdate -k Khermes.wg.site.+157+23873.private Die Transaktionen werden nun mit dem Schl¨ ussel signiert. Ohne Angabe des Schl¨ ussels w¨ urde die Aktion mit einem ”REFUSED” fehlschlagen. nsupdate ist sicherlich nicht die allt¨ agliche Anwendung. Bei den Fragen der Sicherheit geht es eher um Zonentransfers. Hierzu muss der private Schl¨ ussel sowohl auf dem Masterals auch auf dem Slave-DNS-Server eingetragen sein. F¨ ur Zonentransfers heisst die Option statt ”allow-update” ”allow-transfer” unter Beibehaltung der restlichen Syntax. Auf dem Slave sehen die Eintragungen nun wie folgt aus: key hermes.wg.site. { algorithm hmac-md5; secret "Geq/RRYhuAIrlUzJKj49MQ=="; }; server 10.8.4.254 { keys { hermes.wg.site.; }; }; zone "wg.site" IN { type slave; masters { 10.8.4.254; }; file /etc/named/secondary/db.wg.site; }

8.5. DNS BEKOMMT NEUE AUFGABEN

8.5 8.5.1

113

DNS bekommt neue Aufgaben ENUM

Voice-over-IP hat im zweiten Anlauf nach den ersten Startversuchen Ende der 90er Jahre richtig Schwung bekommen. Sp¨ atestens seit der letzten Cebit 2004 hat der Hype um die Te¨ lefonie u erreicht. Nun waren Telefonie und IP-Netze ¨ber das Internet die breite Offentlichkeit lange Zeit zwei v¨ ollig getrennte Dienste, ein Zustand mit dem große Telefonie-Anbieter, wie die Telekom gut leben konnten. W¨ ahrend im Hintergrund beide Dienste konvergieren, steht nach aussen noch ein entscheidender Unterschied: International erreicht man jeden Teilnehmer am öffentlichen Telefonnetz u ¨ 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¨ agt hier nun die Br¨ ucke und f¨ uhrt 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¨ ur 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 u bernimmt das die Regulierungsbeh¨ orde f¨ ur Telekommunikation. Sie hatte beispielsweise ¨ Ende letzten Jahres mit der Entscheidung u ur SIP¨ ber die ortsunhabhängige Vorwahl 032 f¨ Telefonanschl¨ usse von sich h¨ oren lassen. Damit Telefonnummern im DNS-System darstellbar sind, werden sie in eine eindeutige Domain verwandelt. Hierzu wurde die Domain ”e164.arpa” eingef¨ uhrt analog zu ihrem IPPendant ”in-addr.arpa” der Reverse-Auflösung. Unterhalb dieser Domain trägt man nun einfach Subdomains f¨ ur jede Ziffer einer Telefonnummer ein. Anders als bei IP-Adressen und Telefonnummern steht bei DNS die spezifischte Information ganz links: Die ToplevelDomain ist immer die ganz rechte, die Secondlevel-Domain die zweite von Rechts und Subdomains sind dann weitere bis der Rechnername ganz links kommt. Deshalb dreht man die die Telefonnummer um. So wird aus +49-551-654321 ein Eintrag der Form 1.2.3.4.5.6.1.5.5.9.4.e164.arpa. 1. Zunächst entferne man alle optischen Strkturierungen, wie ”+”, ”-”, Leerzeichen: 49551654321 2. Man ordne die Ziffernfolge um: Aus 49551654321 erhält man 12345615594 3. Man setze Punkte zwischen die Ziffern: 1.2.3.4.5.6.1.5.5.9.4 4. Am Ende f¨ ugt 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¨ andigen Domainnamen kann DNS nun ganz normal wie eine IP auch im Nameservicebetrieb verwenden. RFC2915 definiert f¨ ur das ENUM-Protokoll spezielle Nameserver-Eintr¨ age, um auf die einzelnen Kommunikationsadressen (Telefon, Mail...) zu verweisen. Zum Einsatz kommen sogenannte ”Naming Authority Pointer Records” (NAPTR). F¨ ur jede Domain lassen sich mehrere dieser NAPTR-Einträge angeben. Sie erlauben ebenfalls Priorit¨ aten (Preferenzen) festzulegen.

114


Mit ENUM ¨ andert sich der Charakter eines Anrufes grundsätzlich: Zunächst wird u ¨ 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¨ ate und ¿Applikationen anzusprechen.

8.5.2

IPv6

Die nächste Generation der IP-Adressen steht schon länger vor der T¨ ur. F¨ ur den Endbenutzer sicherlich noch nicht relevant, so tut sich jedoch schon hinter den Kulissen einiges. Entsprechend schreitet auch die Auf- und Umr¨ ustung 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¨ uckwärts aufzul¨ osen. F¨ ur IPv6 wurde ein neuer Ressourcentyp eingef¨ uhrt: AAAA repräsentiert eine IPv6 Adresse (A entsprach 32bit, 4*A entsprechend 128bit). Einträge in der Zonen-Datei zur Vorwärtsauflösung könnten also so aussehen: [ ... ] aphrodite aphrodite-ipv6 dionysos dionysos-ipv6

IN IN IN IN

A AAAA A AAAA

10.8.4.203 3ffe:701:10:200:22:feb5:3456 10.8.4.204 3ffe:701:10:200:22:feb5:3457

Die R¨ uckwärtsaufl¨ osung landet in einer eigenen Zonendatei (beispielsweise 5.b.e.f.2.2.0.0. 0.0.2.0.0.1.0.0.4.e.f.f.3.ip6.arpa): [ ... ] 3456 3457

IN PTR IN PTR

aphrodite-ipv6.wg.site. dionysos-ipv6.wg.site.

Ein Problem entsteht nun nat¨ urlich bei der Auflösung von Namen zu IP: Welche Informationen sollen zur¨ uckgeliefert werden: Beide IP-Adressen oder jeweils die eine oder andere? Dar¨ uberhinaus 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¨ ur 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 u ¨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 u ¨ ber das IPv6-Interface und holt seinerseits Erkundigungen u ¨ 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¨ aufig benutzte Domain falsch auflöst. Wenn man im eigenen LAN einen DNS betreibt, den alle Maschinen benutzen (m¨ ussen), kann man diesen f¨ ur alle möglichen Zonen als authoritativ deklarieren. Hierzu trägt man einfach eine Zone f¨ ur die entsprechende Domain nach und verweist auf ein daf¨ ur speziell definiertes Master-File. zone "google.de" in { type master; file "master/empty.zone"; };

8.6. AUFGABEN

115

zone "falkag.de" in { type master; file "master/empty.zone"; }; zone "doubleclick.net" in { type master; file "master/empty.zone"; };

Dabei spielt es u ¨ berhaupt keine Rolle, wenn alle diese Zonen die identische Datei benutzen. In dieser wird lediglich daf¨ ur gesorgt, dass auf jede Anfrage eine 127.0.0.1 zur¨ uckgeliefert 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¨ ur jeden Namen ein Eintrag existieren, diese k¨ onnen so einfach zusammengefaßt werden. Wenn man den Nameserver beispielsweise f¨ ur 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¨ onnen 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¨ urlich 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¨ urde.

8.6 8.6.1

Aufgaben Rechnernamen im Internet

1. Welche Aufgabe hat der DNS? 2. Warum kann man nicht einfach bei der alten /etc/hosts als einfache Zuordnung zwischen IP und Hostnamen bleiben? 3. Warum kann man zwar auf der lokalen Maschine den Hostnamen ändern; es hat aber keine Auswirkungen f¨ ur alle anderen Rechner? ¨ 4. Man a¨nder den Hostnamen! Wo m¨ usste die dauerhafte Anderung eingetragen sein? Man a¨ndere nun einen Eintrag f¨ ur einen Rechner in der /etc/hosts, warum kann man

116

KAPITEL 8. DOMAIN NAME SERVICE diesen Rechner nun unter dem neuen Namen anpingen, obwohl der “Besitzer” dieses Rechners den Namen nicht ge¨ andert 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¨ ungerer 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¨ anomen am besten nachvollziehen? 2. Wieviele Root-Nameserver gibt es? Wo stehen diese? Wodurch ist deren Zahl begrenzt?

Kapitel 9

Ressourcenverwaltung 9.1

Einleitung

In sehr großen Netzen mit vielen gleichartigen Maschinen und vielen Benutzern, die sich an fast allen Maschinen anmelden k¨ onnen, ist die klassische dezentrale Verwaltung von Benutzern und Resourcen nicht mehr leistbar. Daher sind zentrale Server notwendig, die je nach Arbeitsumgebung eine oder mehrere Verwaltungsaufgaben u ¨bernehmen können. Die Hauptaufgabe ist fast immer die Authentifizierung der Benutzer, aber auch die Zuweisung von Ressourcen an die Anwender oder die Konfiguration von Systemen können so vereinfacht werden. Neben dem hier vorgestellten NIS und dem Verzeichnisdienstprotokoll LDAP werden unter anderem auch Radius f¨ ur Einwahlsysteme und ADS (Active Directory Server) in der Windowswelt genutzt. ADS basiert auf LDAP und ist der Nachfolger der Windows NT Domäne, die mit Samba emuliert werden kann (Samba wird hier in einem eigenen Kapitel behandelt).

9.2 9.2.1

NIS Zielsetzung

Wenn ein lokales Netzwerk betrieben wird, besteht ein Ziel u ¨ blicherweise darin, allen Benutzern eine Umgebung zur Verf¨ ugung zu stellen, die u ¨ berall gleich konfiguriert ist. Die Benutzer sollen ein einheitliches Homeverzeichnis vorfinden und u ¨berall den gleichen Account verwenden, f¨ ur den das gleiche Passwort g¨ ultig ist. Hierzu sind die lebenswichtigen Daten wie Account-Informationen zwischen allen Hosts zu synchronisieren. Dar¨ uberhinaus lassen sich auch weitere Dateien synchronisieren, wie die /etc/hosts, /etc/services, /etc/groups ... Deshalb entwickelte Sun vor etlichen Jahren 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¨ ur 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¨ angen, und so lebt YP als Präfix f¨ ur die Namen der meisten NIS-Befehle wie ypserv, ypbind, ypset etc. weiter. 117

118

9.2.2

KAPITEL 9. RESSOURCENVERWALTUNG

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¨ auft. Clients können die Informationen dann von diesem Server u 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¨ ussel. Zum Beispiel k¨ onnen Sie die Datei hosts nach einem Hostnamen ebenso wie nach einer IP-Adresse durchsuchen. Entsprechend werden zwei NIS-Maps daraus erzeugt: hosts.byname und hosts.byaddr. Im folgenden wird eine Aufstellung der gängigen Maps sowie der Dateien, aus denen sie generiert werden, gezeigt: Master-Datei /etc/hosts /etc/networks /etc/passwd /etc/group /etc/services /etc/rpc /etc/protocols /etc/aliases

Mapfile(s) hosts.byname, hosts.byaddr networks.byname, networks.byaddr passwd.byname, passwd.byuid group.byname, group.bygid services.byname, services.bynumber rpc.byname, rpc.bynumber protocols.byname, protocols.bynumber mail.aliases Tabelle 9.1: NIS-Maps

9.2.3

NIS-Server

9.2.4

NIS-Client

Die Konfigurationsdatei f¨ ur NIS ist yp.conf. # Syntax: # ypserver ypserver 134.76.60.23 Der NIS-Domain-String enthalten in der DHCP-Variablen ”option-domain ”dxs”;” wird mittels des Kommandos ”domainname name der nis domain” eingetragen. Alternativ kann dieser Eintrag auch direkt nach /proc/sys/kernel/domainname geschrieben werden.

9.3 9.3.1

Hierarchischer Verzeichniszugriff: LDAP Intro

In verteilten Umgebungen werden Informationen u ¨ber Personen, Anwendungen, Dateien, Drucker und andere, u angliche Ressourcen oft in einer speziellen Daten¨ber das Netz zug¨ bank, einem sogenannten Directory oder auch Verzeichnis gespeichert. Ein Directory Service ist ein Name Service, der neben der Zuordnung Name-Objekt auch Metadaten enthält. X.500 wurde 1988 von der CCITT spezifiziert als ”eine Menge offener Systeme, die gemeinsam eine Datenbank halten, in der Informationen u ¨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

9.3. HIERARCHISCHER VERZEICHNISZUGRIFF: LDAP

119

Protocol), mit dem die Kommunikation zwischen Servern durchgef¨ uhrt wird, und DISP (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¨ andig 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¨ artigen Nutzung hinderlich ist - denn schließlich spielt ein Verzeichnisdienst erst mit der allgemeinen Verwendung seine Stärken aus. LDAP schlägt eine Br¨ ucke.

9.3.2

Was kann mit LDAP abgebildet werden

LDAP speichert seine Informationen in einer Baumhierarchie. Diese Hierarchie kann diverse ¨ Informationen enthalten. Einen Uberblick 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¨ ur 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. Mit den heute u ¨ blichen heterogenen Umgebungen, deren vielfältigen Authentifizierungsanforderungen (z.B. die Anmeldung an einem Radius-Server f¨ ur Modem- oder ISDN-Einwahl) und den gestiegenen Sicherheitsanforderungen konnte NIS nicht mehr mithalten. Neben den inzwischen recht umf¨ anglichen Daten, die die Verwaltung eines Benutzers erfodert, kommen weitere W¨ unsche nach einer zentralisierten Organisation von Rechner-Pools hinzu. Diese Daten sollen meist ebenfalls geeignet abgelegt und komfortabel zugänglich gemacht werden. Solche Aufgaben u ¨ bernehmen ab einem bestimmten Umfang der Anforderungen Datenbanken.

120

9.3.3


Das Datenmodell

Bevor eine Datenbank mit Inhalten best¨ uckt 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¨ ater 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¨ age 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¨ ur eine einfache Benutzerverwaltung ben¨ otigt 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¨ onliche Webseite, B¨ uro und weiteres können gespeichert werden, wenn aus der Datenbank auch die Adressb¨ ucher der Mitarbeiter gef¨ uttert werden sollen. Ist der u bergeordnete Container f¨ u r das jeweilige Objekt bereits bestimmt, gen¨ ugt zur ¨ Angabe auch ein “Relative Distinguished Name” ’rdn’. Der Distinguished Name kann mit dem Primärschl¨ ussel 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¨ urzt dn. Ein Eintrag kann eine Reihe weiterer Attribute besitzen, die einen Typ und einen bzw. mehrere Werte haben. Syntax bin ces cis tel dn

Bedeutung Daten im Bin¨ arformat, Bilder, Ausf¨ uhrbare Dateien CaseSensitive, Textfelder CaseInSensitive, Textfelder Telefonnummer Distinguished Name Tabelle 9.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¨ at Freiburg,c=DE. Diese Informationen bzw. Teilb¨ aume k¨ onnen dann u ¨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

9.3. HIERARCHISCHER VERZEICHNISZUGRIFF: LDAP Attribute CommonName

Alias cn

surname

sn

TelephoneNumber organizationalUnit ou Organization

o

Country Owner

c dn

Syntax cis

Beschreibung Name eines Eintrages cis Nachname einer Person tel Telefonnummer cis Name einer Abteilung cis Name der Organisation cis Name des Landes Ausgezeichneter cn=Sandra BuchName des Ein- fink, o=Universität tragbesitzers Freiburg,c=DE

121 Beispiel Sandra Buchfink Buchfink 01-12345 Informatik Universität Freiburg Deutschland, DE

Tabelle 9.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¨ ort (es kann sogar zu mehreren Klassen gehören). Klassen von Objekten Es sind nun Klassen f¨ ur Personen definiert. Zu einer Person (”person”) geh¨ oren zwingend objectClass (die Objektklasse selbst), sn (der Nachname) und cn (commonName, etwa: u ¨blicher Name, hier wird u ¨ blicherweise Vor- und Nachname verwendet). Zus¨ atzlich gibt es optionale Attribute, die nicht unbedingt angegeben werden m¨ ussen. 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¨ upft 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¨ uhrt) und nat¨ urlich Klassen f¨ ur Organisationen/Firmen, Abteilungen, Bilder, Dokumente, Ger¨ ate 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¨ urliche Person zu mehreren Klassen gehört: person, organizationalPerson und newPilotPerson. Eine weitere Klasse ist top. Im Prinzip geh¨ ort 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¨ ussen, und welche vorhanden sein k¨ onnen. 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.

122


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¨ ullzeichen möglicherweise keine Rolle. Passwörter hingegen m¨ ussen genau u ¨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¨ at finden: In L¨ andern 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¨ ur country), Firmen (organisations mit der Eigenschaft o), Abteilungen (Organisations Einheit, organisationalUnit mit der Eigenschaft ou). Hierbei enthalten diese Objekte normalerweise viele weitere Eigenschaften; eine Firma hat zum Beispiel eine Postanschrift.

Schema Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu gehören die Beschreibungen vieler Klassen und der verwendeten Typen. Es gibt verschiedene Schemata, und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) was jedoch nicht interoperabel mit anderen Diensten sein muss. Das liegt außerhalb der Betrachtungen dieses Textes. Der LDAP-Server speichert seine Informationen in einer baumartigen Struktur. Diese wird auch “Directory Information Tree” genannt, kurz DIT. Root

dn: dc=local

dn: dc=wg,dc=local

rdn: ou=user

rdn: ou=group

rdn: ou=devices

dn: uid=test01,ou=user,dc=wg,dc=local (rdn: uid=test01) dn: uid=test02,ou=user,dc=wg,dc=local (rdn: uid=test02)

dn: uid=...

Abbildung 9.1: Aufbau der LDAP-Datenstruktur f¨ ur 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¨ urfnisse 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.

9.4. LDAP PRAKTISCH

9.3.4

123

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¨ unglich wurde die Entwicklung von Netscape vorangetrieben, um den eigenen Kunden ein u ur Mail- und Webanwendungen anbieten zu können. ¨ bergreifendes Directory f¨ 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 u ¨blicherweise den niedrigsten Privilegienlevel hat) 3. unbind - Verbindung mit dem Server geregelt beenden 4. abandon - Verbindung mit dem Server (ungeregelt) abbrechen 5. add - Hinzuf¨ ugen von Objekten und Attributen 6. search - Suchen ¨ 7. modify - Andern von Objekten und Attributen 8. compare - Vergleich 9. delete - L¨ oschen von Objekten oder Attributen Die ersten vier Operationen dienen zum Verbinden, Abmelden und wechseln des Benutzerlevels. Mit verschiedenen Benutzerleveln sind u ¨blicherweise verschiedene Zugriffsrechte verkn¨ upft. 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¨ ur den Passwort-Check zur¨ uck, so muss das Passwort zum Vergleich die Datenbank nie verlassen. ’search’ gestattet das Suchen. ’read’ f¨ ur Lesen ist die Kombination von ’compare’ und ’search’, ’write’ erlaubt das Schreiben und ’delete’ das Löschen von Attributen und Eintr¨ agen.

9.4 9.4.1

LDAP praktisch Server- und Clientprogramme unter Linux

Es existieren eine ganze Reihe von verf¨ ugbaren 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¨ ugung 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 u ¨ blicherweise unterhalb von /etc/openldap. Die Datenbankdateien

124


landen u ¨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¨ ur direkte Transformation des LDIFFormats in das Datenbankformat und umgekehrt. Dazu wird kein laufender Server benötigt. F¨ ur Operationen auf der LDAP-Datenbank finden sich die Werkzeuge ldapsearch, ldapadd, ldapdelete und ldapmodify. Diese implementieren die im Abschnitt zum Protokoll genannten Operationen.

9.4.2

Eine einfache Beispielkonfiguration

Damit ein erster kleiner Eindruck gewonnen werden kann wie LDAP funktioniert, folgt ein einfaches Beispiel f¨ ur 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¨ usselten Verbindungen, da die gesamte Kommunikation 1 u ¨ ber das Loopback-Interface abgewickelt wird. Die Serverkonfigurationsdatei /etc/openldap/slapd.conf könnte wie folgt aussehen: # LDAP Server Konfigurationsdatei: /etc/openldap/slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema pidfile argsfile

/var/run/slapd/slapd.pid /var/run/slapd/slapd.args

access to attr=userpassword by anonymous auth by self write access to attr=objectclass,entry,mail,cn,sn,loginShell,userPassword by self write by * read access to attr=objectclass,entry,uid,mail,cn,sn,uidNumber,gidNumber,\ homeDirectory,loginShell by * read access to * by users read by anonymous auth database ldbm directory /var/lib/ldap suffix "dc=wg,dc=local" rootdn "cn=Manager,dc=wg,dc=local" rootpw nicht-weitersagen Nachdem die Konfigurationsdatei angelegt, die Existenz des Datenverzeichnisses und dessen Rechte u uft wurden, kann der Dienst einfach einmal gestartet werden: ¨ berpr¨ 1

Interfacename: lo, IP-Adresse: 127.0.0.1

9.4. LDAP PRAKTISCH

125

/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 u uft werden. Hier ¨berpr¨ landen Meldungen zu Fehlern in der Konfigurationsdatei. Die Datei f¨ ur 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¨ uck, solange die Datenbank noch nicht gef¨ ullt wurde. Am schnellsten geht die Best¨ uckung der Datenbank durch das Anlegen einer Datei im LDAPAustauschformat LDIF (Lightwight Directory Interchange Format). Die Objekte werden von der Wurzel aus folgend definiert und eingetragen: # LDIF-Datei zur Definition von zwei Beispielnutzern: user.ldif dn: dc=wg, dc=local objectClass: organization o: wg dn: ou=user, dc=wg, dc=local ou: user objectclass: organizationalUnit dn: ou=group, dc=wg, dc=local ou: group objectclass: organizationalUnit dn: cn=user, ou=group, dc=wg, dc=local objectClass: posixGroup objectClass: top cn: user userPassword: crypt gidNumber: 100 dn: uid=test01, ou=user, dc=wg, dc=local uid: test02 cn: Test-User Nr. 1 sn: Test-User 1 objectclass: person objectclass: posixAccount objectclass: shadowAccount objectclass: top userPassword: secret shadowLastChange: 11472 shadowMax: 99999 shadowWarning: 7 uidNumber: 1001

126


gidNumber: 100 homeDirectory: /home/test02 loginShell: /bin/ksh dn: uid=test02, ou=user, dc=wg, dc=local uid: test02 cn: Test-User Nr. 2 sn: Test-User 2 objectclass: person objectclass: posixAccount objectclass: shadowAccount objectclass: top userPassword: topsecret shadowLastChange: 11472 shadowMax: 99999 shadowWarning: 7 uidNumber: 1002 gidNumber: 100 homeDirectory: /home/test02 loginShell: /bin/bash ¨ Die Ubertragung 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¨ ur 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¨ ur den SSH-Login angepasst: # /etc/pam.d/sshd auth required auth sufficient auth required account required password required password required password required session required session required session required session optional

pam_nologin.so pam_ldap.so pam_unix2.so pam_unix2.so pam_pwcheck.so pam_ldap.so pam_unix2.so pam_unix2.so pam_limits.so pam_env.so pam_mail.so

use_first_pass # set_secrpc

use_authtok use_first_pass use_authtok

Weiterhin muss nun noch dem Name Service Switch die alternative zu den klassischen Dateien passwd und shadow mitgeteilt werden: # /etc/nsswitch.conf

9.4. LDAP PRAKTISCH

127

[ ... ] passwd: files ldap group: files ldap [ ... ] Anschliessend ben¨ otigt 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¨ ugung. Die Liste der mittels LDAP zur Verf¨ ugung gestellten Benutzerkennungen kann mittels getent angezeigt werden. Diese Eintr¨ age erscheinen nach den Daten aus der /etc/passwd.

9.4.3

Absicherung durch SSL

Wenn die Datenkommunikation u ¨ber das Loopback-Interface direkt auf der Maschine stattfindet, ist die Sicherheit der u ¨ bertragenen Daten ausreichend gewährleistet. Anders sieht es aus, wenn LDAP-Pakete u ¨ 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¨ usselerstellung bzw. -verwaltung gestaltet sich dieses etwas aufwändiger. Der schnellste Weg ginge u ¨ber die Generierung eines selbstunterschriebenen Serverzertifikats. Da jedoch eine Reihe von Fehlern auftreten können und LDAP selbstunterschriebene Zertifikate bem¨ angelt, wird von diesem Weg abgeraten. Besitzt man bereits ein von einer Certificate Authority (CA) unterschriebenes Serverzertifikat, kann man den n¨ achsten Schritt u ¨berspringen. Da diese Zertifikate Geld kosten und in regelm¨ aßigen Abst¨ anden verl¨ angert werden m¨ ussen, besitzen meistens nur Betreiber großer Webserver solche. Das OpenSSL-Paket liefert die Lösung f¨ ur dieses Problem mit ein Shell-Skript f¨ uhrt 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

128


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¨ ur den Dateinamen kann mit Enter einfach ein Defaultwert u ¨ bernommen werden, alle anderen Abfragen k¨ onnen wie oben gezeigt ausgef¨ ullt und mit entsprechenden Werten u ussel sollte sich f¨ ur später ¨ bernommen werden. Das Passwort zur Absicherung der Schl¨ gemerkt werden. Im definierten Verzeichnis finden sich unter demoCA/cacert.pem und demoCA/private/cakey.pem das Zertifikat unserer CA und der private Schl¨ ussel. Im nächsten Schritt wird das Serverzertifikat generiert: openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key ............................++++++ ..........................................................++++++ writing new private key to ’newreq.pem’ ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ’.’, the field will be left blank. ----Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:BaWue Locality Name (eg, city) []:Freiburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:WG Organizational Unit Name (eg, section) []:WG-LDAP Common Name (eg, YOUR name) []:wg.local Email Address []:. Please enter the following ’extra’ attributes to be sent with your certificate request A challenge password []: 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¨ ussel noch von unserer CA signiert werden. Hierzu kommt das bereits von der CA-Erstellung bekannte Skript zum Einsatz: /usr/share/ssl/misc/CA.sh -sign Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature

9.4. LDAP PRAKTISCH

129

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

130

KAPITEL 9. RESSOURCENVERWALTUNG DirName:/C=DE/ST=BaWue/L=Freiburg/O=WG/OU=WG-LDAP/CN=wg.\ local serial:00

Signature Algorithm: md5WithRSAEncryption 64:2f:46:48:e2:2b:e9:d4:99:47:5e:35:69:d2:1c:8f:33:c5: [ ... einige weitere Zeilen ... ] 7c:9f:b2:ee:da:dc:26:fc:08:6f:2e:e6:07:4c:72:b0:88:89: d8:3a -----BEGIN CERTIFICATE----MIIDJTCCAo6gAwIBAgIBATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJERTEO MAwGA1UECBMFQmFXdWUxETAPBgNVBAcTCEZyZWlidXJnMQswCQYDVQQKEwJXRzEQ [ ... etliche Zeilen ... ] 1qZZj7c5u5UJHrngC/fRUr5nCgI0fJ+y7trcJvwIby7mB0xysIiJ2Do= -----END CERTIFICATE----Signed certificate is in newcert.pem Damit liegt nun mit newcert.pem das Server Zertifikat unterschrieben von der eigenen CA mit dem privaten Schl¨ ussel newreq.pem vor. Nun ist alles soweit vorbereitet und das Zertifikat kann in das entsprechende Verzeichnis f¨ ur 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 u ur das Verzeichnis, da ¨bergibt dem LDAP-Nutzer die Rechte f¨ sonst der Serverschl¨ ussel 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¨ ussen noch drei Zeilen am Anfang der Server-Konfigurationsdatei slapd.conf eingef¨ ugt 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¨ ur die netzweite Benutzung zur Verf¨ ugung 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

9.4. LDAP PRAKTISCH

131

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.

132


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¨ ur eine ganze Reihe von Programmen zur Verf¨ ugung; 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¨ ur den lokalen Zugriff auf dem System des Benutzers ablegen. Hierzu z¨ ahlt beispielsweise fetchmail. Serverprogramme, die Mails verschicken und verteilen, nennt man MTA (Mail Transfer Agent). F¨ ur die Zustellung in das Postfach kommen mit dem MTA gelieferte oder externe Programme zum Einsatz, die dann MDA (Mail Delivery Agent) heissen. MTAs lassen sich selbstverst¨ andlich mit Linux als Server aufsetzen. Es stehen dabei mehrere Implementierungen des SMTP (Simple Mail Transfer Protocol) zur Verf¨ ugung. Das älteste und umfangreichste MTA-Paket ist sicherlich ”Sendmail” (sendmail), wobei wegen der kryptischen Bedienbarkeit sich weitere Implementationen, wie ”Exim” (exim) oder auch ”Postfix” (postfix) durchsetzen konnten. Als externe MDA werden ”procmail” (procmail) oder ”maildrop” (maildrop) eingesetzt. 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 Ubertragungsprotokoll 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¨ uber POP wesentlich mehr Flexibilität bei der Verwaltung der Post, so z.B. die Möglichkeit, Eingangsk¨ orbe auf dem Server zu verwalten oder auch Roaming Users, also Anwender, die von verschieden Orten aus auf den Server zugreifen wollen. 133

134

KAPITEL 10. MAIL • LDAP (Lightweight Directory Access Protocol) Eine “leichte” Variante des DAP (Directory Access Protocol), welches von X.500 f¨ ur den Zugriff auf die Datenbasis benutzt wird. LDAP wird derzeit von den neueren Mailclients (Outlook, Netscape) unterst¨ utzt, 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 Protocol) ist ein Protokoll ¨ zur Ubertragung von E-Mail zwischen zwei MTAs. Ein MTA kann als Client (SMTP-Client) oder als Server (SMTP-Server) an einer SMTP-Kommunikation beteiligt sein1 . Der SMTPClient baut u ¨ber Netzwerk eine Verbindung zu dem SMTP-Server auf, um an diesen E¨ Mail zu u einer E-Mail, inklusive der relevanten Daten, wird als ¨ bertragen. Das Ubertragen Mailtransfer bezeichnet. Eine abgeschlossene Kommunikation per SMTP wird als SMTPSitzung bezeichnet. W¨ ahrend einer SMTP-Sitzung können mehrere E-Mails u ¨ 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¨ alt mittlerweile deutlich mehr Funktionalitäten, als zum einfachen Ubertragen von E-Mail n¨ otig 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 u uft. 2 ¨berpr¨ EHLO hostname|domain Identisch zu HELO, nur dass der Client damit zu verstehen gibt, dass er einen erweiterten SMTP-Befehlssatz (des ESMTP) unterst¨ utzt. Der Server soll daraufhin mitteilen, welche Erweiterungen des Befehlssatzes f¨ ur die Kommunikation zur Verf¨ ugung stehen. ¨ MAIL Dieser Befehl leitet das Ubertragen einer E-Mail ein. Als Parameter muss die Absenderadresse u ¨ bergeben werden. RCPT Dieser Befehl kann beliebig oft auf MAIL folgen. Mit jedem Aufruf wird eine Empfängeradresse u ¨ bergeben. Es muss mindestens ein Aufruf von RCPT erfolgen. DATA Mit DATA signalisiert der SMTP-Client, dass er den Inhalt (Mail-Body) der EMail u ochte. Nach einer positiven Antwort des Servers wird die E-Mail ¨ bertragen m¨ zeilenweise u ucklauf, Zeilenvorschub, ei¨ bertragen. Ein Zeichenfolge, die aus Wagenr¨ nem Punkt (’.’) und wieder Wagenr¨ ucklauf und Zeilenvorschub besteht, beendet die ¨ Ubertragung des Inhalts der E-Mail. QUIT Um die Kommunikation zu beenden, sendet der SMTP-Client den Befehl QUIT. 1 2

siehe Client-Server-Modell Zu den Begriffen Host und Domain siehe Kapitel DNS.

10.1. SMTP

135

Eine ersch¨ opfende Beschreibung von SMTP liefert RFC 2821. RFCs (Requests for Comments) sind o¨ffentlich zug¨ angliche Dokumente, die Standardprotokolle (in IP-basierten Netzen) definieren. Diese Dokumente werden von der Internet Engineering Task Force (IETF) veröffentlicht und sind u ugbar3 . ¨ ber verschiedene Webseiten verf¨ ¨ Die Ubertragung von E-Mail ist einer der ältesten und meist genutzten Netzwerk¨ Dienste. 1971 entwickelte Ray Tomlinson ein Verfahren zur Ubertragung von Textnachrichten u ber ein Netzwerk. Mit den Programmen SNDMSG und READMAIL war die erste ¨ Komunikation per E-Mail m¨ oglich. Im Laufe der Jahre entwickelte sich das Verfahren stark weiter. Jonathan B. Postel ver¨ offentlichte 1981 die erste Spezifikation von SMTP als RFC 788. 1982 wurde diese durch RFC 821 (auch von Postel) ersetzt. Anfang der 90er Jahre (19931995) wurden mehrere Erweiterungen zu SMTP spezifiziert, die 2001 schliesslich zu RFC 2821 f¨ uhrten, 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¨ anger-, bzw. die Absenderdomain. Er besteht aus einer weltweit eindeutigen Domainbezeichnung. Diese Domainbezeichnung identifiziert das empfangende System und muss u osbar sein (siehe DNS). (RFC 2142) ¨ber DNS aufl¨

10.1.2

Versenden einer E-Mail

Am Versand einer E-Mail sind mehrere sogenannte Agenten beteiligt. Ein Programm zum Lesen und Verfassen von E-Mail wird als Mail User Agent (MUA) bezeichnet. Eine EMail kann während des Transfers mehrere Mail Transfer Agents (MTA, siehe Kapitel SMTP) durchlaufen. Der Mail Delivery Agent (MDA) kann die E-Mail dann noch bearbeiten (Filtern). Der MDA bekommt die E-Mail von dem lokalen MTA u ¨ bergeben und 4 speichert diese in der Inbox des Empf¨ angers. Als Outgoing-SMTP-Server einer Domain bezeichnet man einen MTA, an den alle zu versendenden E-Mails einer Domain per SMTP u ¨ bertragen werden. Dieser u ¨ bernimmt die weitere Auslieferung. Ein Mailexchanger ist ein MTA, der f¨ ur die Annahme von E-Mail f¨ ur eine bestimmte Domain zust¨ andig ist. Der Name und damit die IP-Adresse des Mailexchangers einer Domain muss u ugbar sein (siehe Kapitel DNS). Der ¨ ber DNS in einem MX-Record verf¨ Mailexchanger verf¨ ugt u ¨ 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 u ¨bergeben, der sie per SMTP an den Outgoing-SMTP-Server seiner Domain u ¨bermittelt5 . Dieser wiederum sendet sie an den Mailexchanger der Empfängerdomain, welcher f¨ ur die lokale Zustellung der E-Mail in die Inbox des Empf¨ angers zuständig ist. ¨ Tabelle 10.1 zeigt eine typische einfache SMTP-Sitzung zum Ubertragen einer E-Mail. Der SMTP-Client nimmt Kontakt zum SMTP-Server auf, der die Kontaktaufnahme mit dem Antwort-Code 220 und Informationen u ¨ber sich selbst bestätigt. Daraufhin leitet der 3

http://www.ietf.org/rfc, http://www.faqs.org/rfcs u.a. Im Deutschen oft einfach als Posteingang bezeichnet. 5 Viele MUAs sind in der Lage, die Aufgabe eines SMTP-Clients selbst zu u ¨ bernehmen. 4

136

KAPITEL 10. MAIL

Server: Client: S: C: S: C: S: C: S: C:

220 golem.ehlers-schwichtenberg.info ESMTP Postfix HELO schwichtenberg.net 250 golem.ehlers-schwichtenberg.info MAIL FROM: 250 Ok RCPT TO: 250 Ok DATA 354 End data with . Der Mail-Body . S: 250 Ok: queued as C1AD92BC346 C: QUIT S: 221 Bye ¨ Tabelle 10.1: Einfache Ubertragung eine E-Mail mit SMTP

Client die Kommunikation mit HELO ein. Die mit HELO u ¨bergebene Zeichenkette soll der Identifikation dienen, wird aber an dieser Stelle ungepr¨ uft u ur ¨bernommen. Wie es sich f¨ einen höflichen Server geh¨ ort, antwortet dieser mit seiner eigenen Identifikation. Mit dem ¨ Befehl MAIL wird die Ubertragung der eigentlichen E-Mail - der Mailtransfer - begonnen. Als Parameter werden ’FROM:’ und die Absenderadresse in spitzen Klammern u ¨ bergeben. Nun kann der Client wiederholt Empf¨ angeradressen mit dem Befehl RCPT und ’TO:’ und der Empfängeradresse in spitzen Klammern u ¨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 u ufen die Existenz der Absenderadresse. In jedem Fall ¨berpr¨ sollte der Server u ufen, ob er f¨ ur die Zustellung von E-Mail f¨ ur die Empfängeradressen ¨ berpr¨ 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¨ ur jegliche Empfängeradresse annimmt, bezeichnet man als Open-Relay (siehe Kapitel 10.1.5). Sind alle Empf¨ angeradresse u ¨ bermittelt, wird die eigentliche Nachricht, der Mail-Body (siehe Kapitel 10.1.3) u ¨ bertragen. Der Client teilt dem Server mit dem Befehl DATA mit, dass er den Mail-Body u ochte. Der Server sendet den Antwort-Code 354, um ¨bertragen m¨ ¨ zu signalisieren, dass der Client mit dem zeilenweisen Ubertragen der Nachricht fortfah¨ ren kann. Diese Ubertragung 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¨ atigt. 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 u ¨ber die E-Mail und - getrennt durch eine Leerzeile - dem eigentlichen Text der Nachricht. Die meisten Headerzeilen werden

10.1. SMTP

137

Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] 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: [email protected] To: undisclosed-recipients:; Der Mail-Body Tabelle 10.2: Die E-Mail aus Tabelle 10.1 von MUAs nicht angezeigt6 . Die w¨ ahrend der SMTP-Sitzung u ¨bertragen E-Mail-Adressen dienen in erster Linie den MTAs zur Auslieferung bzw. zur R¨ uckf¨ uhrung einer E-Mail. Steht nach einem Mailtransfer in dem Mail-Body noch keine mit ’From:’ beginnende Zeile, weil diese lokal erzeugt wurde - z.B. von dem Webserver u ¨ ber ein CGI-Skript - kann der MTA diese Zeile mit der Absenderadresse erzeugen. Date, Subject, To, From oder ¨ Aquivalente 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¨ uhrt dazu, dass die E-Mail aus Tabelle 10.2 in der Inbox des Empf¨ angers 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¨ ugt zu jeder empfangenen E-Mail Headerzeilen hinzu, die dann als Bestandteil des Mail-Body per SMTP weiter u ¨bertragen werden.

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¨ ussen die folgenden Textzeilen mit einem Whitespace beginnen. Bezeichner f¨ ur Headerzeilen, die in keinem Standart definiert sind, m¨ ussen mit ’X-’ beginnen (RFC 2821).

Return-Path Ein MTA, der eine E-Mail endg¨ ultig zustellt7 , muss die Zeile Return-Path: an den Anfang der E-Mail setzen. Die einzutragende Adresse ist die während des Mailtransfers mit MAIL u ¨ bergebene Absenderadresse (RFC 2821). 6

Meistens ist es m¨ oglich, die Darstellung des kompletten Haeders einzuschalten. “final delivery”; wenn der MTA die E-Mail an einen MDA u ¨ bergibt oder in anderer Form aus dem SMTP-System nimmt. 7

138

KAPITEL 10. MAIL

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 unterteilt: 1. Informationen u ¨ 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 u ¨bergebene Zeichenkette. Zus¨ atzlich sollen in runden Klammern TCP-Informationen u ¨ber den Client eingef¨ ugt werden. Die meisten MTAs f¨ ugen die IP-Adresse des SMTP-Client (in eckigen Klammern) und den daraus resultierenden Hostnamen ein. 2. Informationen u ¨ ber den SMTP-Server selbst. Beginnend mit “by” werden der Hostname des Servers und Informationen u ¨ber den Empfang (meistens Art der Software, Empfangsprotokoll und Identifikationsnummer der E-Mail im Server) eingef¨ ugt. 3. Informationen u ¨ ber den Empfang der E-Mail mit “for”, gefolgt von der mit RCPT u angeradresse und - getrennt durch ein Semikolon - der Zeitpunkt ¨ bergebenen Empf¨ 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¨ ugen. Die Eintr¨ age “X-Original-To:” und “Delivered-To:” aus Tabelle 10.2 werden speziell von dem MTA Postfix eingef¨ ugt. Sie registrieren die auf dem Umschlag der E-Mail vermerkten Adressen, wenn virtuelle Domains benutzt werden, bei denen Adressen auf andere Domains umgeschrieben werden (eine Art Nachsendeantrag).

10.1.5

Open-Relay

Ein Open-Relay ist ein Mailexchanger oder ein Outgoing-SMTP-Server, der E-Mail von beliebigen MTAs f¨ ur beliebige Empf¨ angeradressen annimmt und weiterleitet. Da die Angabe der Absenderadressen w¨ ahrend einer SMTP-Sitzung nur unzureichend oder gar nicht u uft wird, erm¨ oglicht ein Open-Relay jedermann das anonyme Versenden von E-Mail ¨ berpr¨ (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¨ usselt u ¨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¨ anger ankommt (siehe Kapitel 10.1.3) und wie SMTP mißbraucht werden kann.

10.1. SMTP

139

Das Abholen von E-Mail eines Benutzers von seiner Inbox ist nicht Bestandteil der ¨ SMTP-Ubertragung. 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. 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 u ¨ bertragen. Die Ubermittlung an einen Outgoing-SMTP-Server des Providers ist unproblematisch, da der Provider seine Kunden kennt und den Zugriff u ¨ber die Kenntnis der IP-Adresse des Kundenrechners oder u ur den Outgoing¨ber die Vergabe eines Passwortes einschränken kann. Gleiches gilt f¨ SMTP-Server einer Domain, wobei hier die SMTP-Kommunikation sogar u ¨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¨ uhen Zeiten des Internet war es notwendig, E-Mail u ¨ ber eine Kette von SMTPServern zu u ¨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¨ uckf¨ uhren. 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 u ¨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¨ alschen 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¨ anger der E-Mail ihm antworten kann und möchte auch ¨ benachrichtigt werden, wenn bei der Ubertragung der Nachricht etwas schief geht. Ein Versender von unerw¨ unschter 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¨ are es unter bestimmten Bedingungen möglich, ihn juristisch zur Verantwortung zu ziehen. ¨ Alle anderen Werte einer E-Mail sind schon während der Ubertragung Bestandteil des Mail-Body (siehe Kapitel 10.1.3). Der Versender einer E-Mail kann sich Werte f¨ ur Absender 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¨ anden nicht erreichbar, obwohl sie sich im eigentlichen Sinn im Internet befinden. Nur bedeutet die Tatsache, dass ein Rechner einen Verbindungsaufbau ablehnt, nat¨ urlich nicht, dass man ihn nicht erreichen kann. 9 Was f¨ ur einen Nutzen das Versenden einer solchen Nachricht f¨ ur den Absender haben kann, soll hier nicht diskutiert werden. Es reicht aus, dass sowohl die Betreiber von Mailservern als auch die Empf¨ anger maßgeblich bel¨ astigt werden.

140

KAPITEL 10. MAIL

(“From:”), Empf¨ anger (“To:”), Betreff (“Subject:”) usw. und beliebige “Received:”-Zeilen ausdenken. Die einzigen verl¨ asslichen 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 vertrauen. Kommando HELO MAIL RCPT DATA HELP VRFY EXPN RSET NOOP QUIT

Argument Systemname From: Absenderadresse To: Empf¨ angeradresse Daten... Topic Mailadresse Mailadresse

Beschreibung Beginn, Name des sendenden Systems ¨ Beginn der Ubermittlung Adressat der E-Mail Brieftext, Ende durch eine Zeile mit ”.” Hilfestellung Mailadresse verifizieren Mailadresse expandieren (z. B. Liste) Senden abbrechen, Zur¨ ucksetzen nichts tun Verbindung beenden

Tabelle 10.3: Grundsätzliche SMTP-Befehle

10.2

sendmail

Das Paket sendmail ist eines der ¨ altesten INTERNET-Programme und wohl auch das mit dem schlechtesten Ruf. Am Anfang war es aufgrund diverser Sicherheitsl¨ ucken ein beliebtes Einfalltor f¨ ur Hacker und Co.; bei den Administratoren ist es wegen seiner schwierigen Konfiguration gef¨ urchtet. Dennoch hat es sich zum Standard f¨ ur 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¨ ugung 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¨ achst z.B. exim neu konfiguriert werden (z.B. mittels eximconfig. Hierf¨ ur muss man u ugen.): ¨ber SuperUser-Rechte verf¨ 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.

10.4. POP

141

[---Press return---]

10.4

POP

Kommando USER PASS QUIT

Argument Name String

Beschreibung Das Argument identifiziert eine Mailbox Der String enthält ein Mailbox-spezifisches Passwort Beendet die Verbindung

Tabelle 10.4: Kommandos im ”Authorization State” Kommando Argument STAT LIST

Nummer

RETR

Nummer

DELE NOOP

Nummer

RSET QUIT

Beschreibung Liefert die Anzahl der gespeicherten Mails und die Größe der Mailbox zur¨ uck (in Byte) Liefert die Nummer und Größe (in Bytes) aller Mails zur¨ uck Wird als Argument eine Mail-Nummer angegeben, wird nur die Größe dieser Mail ausgegeben Gibt die Mail mit der als Argument u ¨bergebenen Nummer aus L¨ oscht die Mail mit der u ¨bergebenen Nummer Bewirkt die Antwort ”+OK”. Dient zur Aufrechterhaltung der Verbindung, ohne daß ein Time-Out auftritt Setzt die aktive Verbindung zur¨ uck. Noch nicht aus¨ gef¨ uhrte Anderungen werden verworfen Beendet die Verbindung und f¨ uhrt alle gespeicherten ¨ Anderungen aus

Tabelle 10.5: Kommandos im ”Transaction State” F¨ ur den Transport bis zum Server mit dem E-Mail Postfach findet i.d.R. das SMTPProtokoll Anwendung. Da Benutzerrechner, auch in Zeiten totaler Vernetzung, nicht per¨ manent im Netz sind wird die Ubertragung 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 Postfaches (durch Postfachname und Kennwort authentifiziert) Clients zur Verf¨ ugung. 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 Ubertragung vom Server gelöscht. Dies f¨ uhrt zu Inkonsistenzen beim gleichzeitigen Einsatz verschiedener Clients f¨ ur ein Postfach. Denn Mails, welche bereits abgerufen wurden, sind f¨ ur 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 Ubermittlung 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... Local Process ---Pakete die u ¨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¨ onnte so aussehen: target ACCEPT

prot opt source all -- anywhere

destination anywhere

Diese recht nutzlose Regel akzeptiert alle Pakete, unabhängig von Protokoll sowie Ursprung und Ziel. Das target k¨ onnte auch REJECT, DROP oder FORWARD sein, oder 179

180

KAPITEL 13. FIREWALL

allgemein der Name einer chain (die vordefinierten targets sind in Grossbuchstaben). Alle anderen Datenfelder zeigen hier ”menschenlesbare” Schl¨ usselworte (sofern dieses Verhalten nicht durch Zusatzparameter unterdr¨ uckt 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¨ ahlen (z.B. !icmp), diese Möglichkeit besteht auch bei vielen anderen Schaltern. Ebenso ist ”anywhere” nur ein anderer Ausdruck f¨ ur die Netzmaske 0.0.0.0/0.

13.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¨ onnen jedoch nicht gelöscht werden.

1. Alle Regeln in einer chain listen (-L). 2. Alle Regeln in einer chain l¨ oschen (-F). 3. Alle Pakete und Paketz¨ ahler in der chain zur¨ ucksetzen (-Z). 4. Eine neue chain erzeugen (-N). 5. Die Policy f¨ ur eine eingebaute chain ändern (-P). 6. Eine leere chain l¨ oschen (-X).

Es existieren mehrere M¨ oglichkeiten, eine Regel in einer chain zu verändern:

1. Eine Regel in einer chain einf¨ ugen (insert, d.h. oben in die Liste einhängen) (-I). 2. Eine Regel an eine chain anf¨ ugen (append, d.h. unten in die Liste einf¨ ugen) (-A). 3. Eine Regel in einer chain ersetzen (replace) (-R). 4. Eine (bzw. die erste passende) Regel in einer chain löschen (delete) (-D).

13.2.1

Pakete genauer spezifizieren

Die meisten Regeln bestehen aus einer (beliebigen) Kombination der folgenden Parameter:

13.2. EIN- UND AUSTRAGEN VON CHAINS UND FILTER-REGELN

181

”-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¨ oglichen 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¨ angen 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¨ osse 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¨ achen verschiedener Betriebssysteme ausnutzen.

13.2.2

”Match Extensions” und Erweiterbarkeit

iptables unterst¨ utzt 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¨ ussen. So wird durch die Angabe ” -p tcp” eine Reihe von TCP bezogenen Filterangaben verf¨ ugbar:

182


”–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¨ ur ”–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¨ ankung 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¨ ankt werden kann. Damit kann verhindert werden, das eine (entsprechend konfigurierte) firewall sich durch das Loggen von zu vielen Paketen selbst ¨ behindert. Dar¨ uber hinaus existieren viele ”Denial of Service” Angriffe (”Uberschwemmen einer Leitung mit vielen Paketen”) die zwar nicht vollkommen ausgeschaltet werden können ¨ (die Bandbreite zur Ubertragung ist verloren), deren Auswirkungen (stabiler Betrieb der Computer, Netz¨ uberlastung durch Antwortpakete) aber erheblich reduziert werden. Das Modul kann zus¨ atzlich 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 u ¨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¨ urden 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¨ uckgewonnen; nach 100 Minuten ohne Aktivit¨ at w¨ are 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”

13.3. VON ”MASQUERADING” UND ”PACKET MANGLING”

183

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¨ oglicht. Durch Laden des Moduls wird ein weiterer Schalter ”[!] –state STATE” verf¨ ugbar, die Angabe ”STATE” kann dabei entweder ”NEW”, ”ESTABLISHED”, ”RELATED” oder ”INVALID” sein. (siehe connection-tracking)

13.3

von ”masquerading” und ”packet mangling”

Neben dem Filtern von (unerw¨ unschten) Paketen sollte eine moderne firewall auch die Header von bestimmten Paketen ver¨ andern 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.

13.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¨ ur alle folgenden Pakete verwendet. 1. Source NAT (SNAT): Die Quelladresse des ersten Paketes einer Verbindung wird verändert, bevor es durch das Netzger¨ at 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ändert, 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:

184


--->[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¨ urfen 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¨ ur eine Spezialfall des SNAT: MASQUERADE. Die Angabe der –to Adresse entfällt hier. iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE DNAT erm¨ oglicht es, eine auf der firewall eingehende Verbindung an einen anderen Rechner weiterzuleiten. H¨ aufig m¨ ussen bestimmte Dienste auch vom Internet her verf¨ ugbar sein, meistens werden daf¨ ur einige Rechner in einem (vom eigentlichen lokalen Netzwerk) getrenntes Netzsegment untergebracht (DMZ, demilitarized zone) das ebenfalls u ¨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¨ urde auf eth0 eingehenden Traffic (an Port 80) an den Webserver auf Rechner 5.6.7.8 (in der DMZ) weiterleiten.

13.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¨ ultig. 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 Ubertragung verwendet werden sollte.

13.4. CONNECTION TRACKING

185

Diese Werte sind jedoch nur als ”Vorschlag” zu verstehen, IPV4 bietet keine Möglichkeit derartige Zusicherungen wirklich einzuhalten (”Quality of Service” oder kurz QoS). Der Wert ist als 4-Bit Feld definiert, von dem immer nur ein Bit gesetzt ist: 1000 0100 0010 0001 0000

------

minimize delay maximize throughput maximize reliability minimize monetary cost normal service

Der ”–set-mark” Parameter wird meistens verwendet, um die Lesbarkeit der firewall Logdateien durch Schl¨ usselworte zu verbessern.

13.4

connection tracking

Unter diesem Begriff versteht man die F¨ ahigkeit einer firewall Statusinformationen u ¨ber alle aktiven Netzwerkverbindungen zu verwalten, bzw. Pakete einzelnen Verbindungen zuzuordnen. Dabei werden die Quell- und Ziel-adressen, die Portnummern, verwendete Protokolle und jeweils ein ”Zustand” (state) der Verbindungen im Speicher gehalten. Eine Firewall mit dieser Eigenschaft wird als ”stateful” bezeichnet. Zustand NEW ESTABLISHED RELATED INVALID

allgemeine Bedeutung bezeichnet Pakete, die eine neue Verbindung aufbauen, bzw. die zu einer Verbindung gehören, der bisher noch keine Pakete zugeordnet wurden. eine Verbindung gilt als ESTABLISHED, wenn in beide Richtungen mindestens ein Paket geflossen ist. auch diese Pakete bauen eine neue Verbindung auf, sind jedoch im Kontext zu einer existierenden Verbindung zu betrachten (FTP Datenverbindung, ICMP Fehlermeldung). bezeichnet Pakete die zu keiner bekannten Verbindung gehören.

Je nach Protokoll der Verbindung haben diese Zustände unterschiedliche technische Bedeutung, oder sind nur teilweise anwendbar. UDP Pakete haben keine Sequenznummern, allgemein wird UDP ”stateless” genannt. Wenn bisher nur ein Paket in eine Richtung geschickt wurde, wird die Verbindung intern als ”UNREPLIED” markiert; wenn innerhalb einer gewissen Zeit (timeout) ein Antwortpaket eintrifft wird diese Markierung gel¨ oscht und die Verbindung gilt als ”ESTABLISHED”. Nach einer vorkonfigurierten Anzahl von Paketen (in beide Richtungen) gilt die Verbindung intern als ”ASSURED” und der timeout Wert wird heraufgesetzt. TCP Verbindungen werden durch einen ”3-way handshake” aufgebaut, dies ist eine Folge von Anfrage- und Antwort-paketen, bei denen bestimmte Kombinationen an TCP flags gesetzt sind. Analog zu UDP gilt eine Verbindung als ”ESTABLISHED” (intern ASSURED) sobald das abschliessende ACK empfangen wurde. ICMP Verbindungen bestehen entweder aus einer Anfrage (request, NEW) und der Antwort (reply, ESTABLISHED) oder aus einem einzelnen Paket (RELATED). Die Beachtung der internen Zust¨ ande kann bei Computern mit relativ wenig Hauptspeicher notwendig sein, da die Anzahl der gleichzeitig u ¨ berwachbaren Verbindungen durch

186


den verf¨ ugbaren Hauptspeicher begrenzt ist. Wenn die Resourcen erschöpft sind und weitere Verbindungen u ussen, werden bevorzugt Verbindungen im Zustand ¨ berwacht werden m¨ ”UNREPLIED” gel¨ oscht und der Verbindungsaufbau damit unterbrochen. Die konfigurierte Anzahl gleichzeitig verfolgbarer Verbindungen ist in /proc/sys/net/ipv4/ip conntrack max gespeichert. Dar¨ uber hinaus werden Verbindungen spezieller Dienste (z.B. FTP) durch zusätzliche Kernelmodule (ip conntrack ftp) u ¨ berwacht, um damit bestimmte Pakete als ”RELATED” zu klassifizieren und den Verbindungsaufbau zuzulassen, ohne das die exakten Filterangaben dieser Pakete f¨ ur die Konfiguration der firewall bekannt sein m¨ ussen. 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¨ uber 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.

13.5

Referenzen

1. die iptables man page 2. das netfilter, packet filtering sowie NAT HOWTO http://www.netfilter.org/documentation/

Kapitel 14

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

14.1

¨ Uberblick

Im Zusammenhang mit WWW und dem daf¨ ur 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 Namen f¨ ur eine Ressource. z.B http://www.goe.net/index.php) • URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name f¨ ur die Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar. • URN - Uniform Ressource Name, ein spezieller Typ von URI, auch weltweit 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 weiter zu einem Standard entwickelt wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DELETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wurde genauer spezifiziert. HTTP/1.0 erm¨ oglicht die Beschr¨ ankung des Zugriffes auf Ressourcen. Es handelt sich jedoch nur um eine rudiment¨ are Authentifizierung, da das Passwort unverschl¨ usselt u ¨bertragen wird und der Server sich dem Client gegen¨ uber nicht authentifizieren kann. 187

188

KAPITEL 14. WEBSERVER

Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich auf die Korrektur der Designfehler, das Spezifizieren von Semantik und einige PerformanceOptimierungen. So k¨ onnen jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. F¨ ur ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher f¨ ur jede Resource eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads ¨ fortgesetzt werden. Uber 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 wurden auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver u ¨ berwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver u ¨ ber die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene. HTTP/1.1 umfasst auch Unterst¨ utzung f¨ ur die höher entwickelten Netzanwendungen und Entwicklungen, die in den sp¨ aten neunziger Jahren dazu kamen.

14.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 u ¨bergebenen Daten in die URL einkodiert und sind somit f¨ ur 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 u ¨ bergeben. Dabei lassen sich wesentlich mehr Daten u ¨bergeben als in einer GET-Anfrage. Das Versenden der Daten an den Server geschieht f¨ ur 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 ¨ andert. Daraus ergibt sich auch, dass solche Seiten im Cache angelegt werden k¨ onnen. Mit POST-Seiten ist es jedoch genau andersherum, diese sind nicht idempotent und werden deshalb nicht im Cache abgelegt.

14.3. WAS IST EIN WEBSERVER?

14.3

189

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 Typ 1 diese Dateien sind) u ¨ber Netzwerk aus. Unter Umständen wird bei der Entscheidung, welche Dateien ausgeliefert werden, nach der angefragten Adresse unterschieden. Grundsätzlich wird auf die Anfrage http://host.domain/directory/example.html mit der Auslieferung von “Content-Type Text-html” und dem Inhalt der Datei: /usr/local/httpd/htdocs/directory/example.html2 von dem Webserver auf host.domain reagiert.

14.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¨ atzlich eingebunden werden (teilweise mit und teilweise ohne Neustart des Apache). Vielfach sind noch ¨ altere Varianten des Servers mit Versionsnummern 1.3.X im Einsatz. Neu in der Version 2.0 ist vor allem, dass plattformspezifischer Code (z.B. Schreib- Lesezugriffe auf die Festplatte) in eine APR (Apache Portable Runtime) ausgelagert wurde. Dies ermöglicht es, dass f¨ ur 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¨ uhrungseinheiten 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¨ urlich auch). Ebenso neu eingef¨ uhrt in der Version 2.0 wurden Multi-Protokoll-Unterst¨ utzung auf Transportebene und IPv6-Unterst¨ utzung.

14.4.1

Erweiterbare Funktionalit¨ at

Apache wird durch Module in seiner Funktionalität erweitert. Eine kleine Anzahl von Modulen wird immer mit installiert, alle weiteren Funktionen werden durch Installation eines entsprechenden Moduls hinzugef¨ ugt. Die Konfiguration des Apache ist daher idealerweise auf die globale Konfigurationsdatei, modulspezifische Konfigurationsdateien und hostspezifische Einstellungen (f¨ ur die Virtuellen Hosts) verteilt. Direktiven f¨ ur ein Modul sind nur dann verf¨ ugbar, wenn dieses auch geladen wurde. Es gibt neben großen Modulen f¨ ur interaktive Inhalte wie PHP, SSI, CGI und Perl ein großes Archiv kleiner Helfer - URL-Tippfehlerkorrektur, Erkennung der Browsersprache, Logdateieinstellungen und zur Verwendung aller möglichen Authentifizierungsquellen sind nur einige von mehreren hundert. Im folgenden werden einige Module vorgestellt. 1 2

zB.: Content-Type Text-html Wenn DocumentRoot auf ’/usr/local/httpd/htdocs’ gesetzt ist. Dazu sp¨ ater mehr.

190


14.5

Konfiguration

Je nach Distribution hat Apache eine Konfigurationsdatei httpd.conf (wenn er selbst kompiliert wurde) oder einen eigenen Ordner wie /etc/apache. Andere Dateien werden mit Include eingebunden. Die Verteilung auf viele Dateien ist notwendig, damit u ¨ ber den jeweiligen Paketmanager (apt,yast) einzelne Funktionen nachinstalliert werden können, ohne die vorhandene Konfiguration zu manipulieren. 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.: ...). Der G¨ ultigkeitsbereich ist auf die Container beschränkt. Verzeichniskontext In zus¨ atzlichen Konfigurationsdateien innerhalb der Verzeichnisstruktur. Der Name dieser Dateien kann mit AccessFileName festgelegt werden 3 . Direktiven k¨ onnen in unterschiedlichem Kontext stehen, aber nicht jede Direktive kann in jedem Kontext verwendet werden. Die Apache-Dokumentation gibt f¨ ur 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¨ ur 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.

14.5.1

Optionen

Eine wichtige Direktive ist die Options-Direktive mit der man festlegen kann, welche ServerFeatures verf¨ ugbar sind. Optionen k¨ onnen im Konfiguration-, Container- und VerzeichnisKontext gesetzt werden. ExecCGI : Ausf¨ uhrbarkeit von CGI-Programmen (mod cgi) 3

Standard ist AccessFileName .htaccess

14.5. KONFIGURATION

191

Includes : Ausf¨ uhrung von ServerSideInclude-Befehlen (SSI) (mod include) Indexes : Verzeichnislisting anzeigen (mod index Optionen k¨ onnen gesetzt, hinzugef¨ ugt(+) oder entfernt(-) werden. Im Beispiel 14.1 wird f¨ ur das Verzeichnis /home/www/ die Option Indexes zu den allgemein g¨ ultigen Optionen hinzugef¨ ugt und die Option Includes von den allgemein g¨ ultigen Optionen entfernt (abgezogen). Mit AllowOverride k¨ onnen die Optionen Verzeichnisweise anderes eingestellt werden. Dazu werdenn alle ver¨ anderbaren Optionen nach AllowOverride aufgef¨ uhrt, und in dem Verzeichnis wird eine .htaccess mit den veränderten Direktiven angelegt. Options +Indexes -Includes Abbildung 14.1: Options hinzug¨ ugen/entfernen Im Beispiel 14.2 werden f¨ ur das Verzeichnis /home/www2/ nur die Optionen Indexes und Includes gesetzt. Unabh¨ angig von den allgemein g¨ ultigen Optionen. Options Indexes Includes Abbildung 14.2: Options setzen

14.5.2

Laden von Modulen

Zusätzliche Funktionalit¨ aten k¨ onnen in Form von Modulen hinzugef¨ ugt werden. Module m¨ ussen mit einer entsprechenden Zeile im Global-Kontext geladen werden, f¨ ur mod cgi z.B. so LoadModule cgi_module /usr/lib/apache/mod_cgi.so AddModule mod_cgi.c Module bringen ihre eigenen Direktiven mit, die nach dem Laden verf¨ ugbar sind. Mit der Direktive IfModule kann man Container erzeugen, deren Direktiven nur ausgef¨ uhrt werden, wenn das entsprechende Modul geladen ist (siehe 14.3, S. 193). Module können auch direkt in den Apache einkompiliert werden und sind dann ohne geladen werden zu m¨ ussen verf¨ ugbar. F¨ ur Apache gibt es eine Vielzahl Module, die nicht zur Standard-Distribution gehören. W¨ unscht man sich eine zus¨ atzliche Funktion f¨ ur seinen Webserver, lohnt es sich im Internet nach einem Modul zu suchen, das diese Funktionalität bereitstellt. Sollte man nicht f¨ undig werden, kann man sich dank der offenen Quelltexte daran machen, selber ein solches Modul zu schreiben.

192


14.6

Webserver Erweiterungen

Die Anforderungen an den Apache Webserver sind in den letzten Jahren gestiegen, so dass das eigentliche ausf¨ uhrbare Programm permanent erweitert werden muss. Die Apache4 Foundation 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¨ ugt. Durch diese M¨ oglichkeit bleibt der Webserver ”schlank” und verwendet je nach Konfiguration nur die Module, welche wirklich gebraucht werden. Dieses vermeidet unnötige Sicherheitsl¨ ucken. In der Apache Modul Datenbank sind momentan (November 2005) u ¨ 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¨ ugen oder Entfernen eines solchen Moduls kommt der Admin um eine Neukompilierung des Webservers nicht herum. Durch die feste Integration kann sich die Ausf¨ uhrungsgeschwindigkeit beim Starten des Apache und wärend der Laufzeit erhöhen, da keine zus¨ atzlichen Initialisierungen f¨ ur 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¨ ugt 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¨ ugen.

14.6.1

Die Benutzer-Homepage - mod userdir

In klassischen Multi-User-Umgebungen wie Universitäten und Schulen haben Benutzer mit Linux-Account u ¨ blicherweise auch die Möglichkeit eine eigene Homepage in ihrem HomeVerzeichnis anzulegen. Das Modul k¨ ummert sich darum, dass der Webserver mit geeigneten Rechten auf ein Unterverzeichnis im User-Home, welches sonst ja vor unauthorisiertem Zugriff gesch¨ utzt sein sollte, hineinschauen darf. Das Modul muss lediglich einmal konfiguriert werden. Anschliessend sind sämtliche Homepage-Verzeichnisse u ¨ber den Webserver von außen erreichbar. Klassischer Weise erreicht man die Seiten der einzelnen Benutzer unter der URL http://www.mywebserver.site/ username oder u ur bestimmte Ver¨ber http://www.mywebserver.site/˜username. Das hierf¨ zeichnis 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 4

Der erste Apache-Webserver entstand aus dem damals aktuellen NCSA httpd 1.3 und zus¨ atzlichen 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.

14.6. WEBSERVER ERWEITERUNGEN

193

UserDir public_html AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec Abbildung 14.3: User-Webdirectory

14.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¨ one” URLs ver¨ andern, um sie zum Beispiel f¨ ur 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¨ amtlichen 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¨ ur die Umschreibung. Der erste Parameter bildet das Suchmuster und der zweite Parameter das Ersetzungsmuster. Das Suchmuster lässt soch mittels regulärer Ausdr¨ ucke formulieren. Beim Ersetzungsmuster kann es sich um einfachen Text, aber auch Variablen des regul¨ aren Ausdrucks enthalten. Im gezeigten Beispiel steht $1 f¨ ur das erste Klammerpaar im Suchmuster.

14.6.3

Zugriffskontrollen

Die Module mod auth basic und mod auth digest erlauben die Einrichtung einer einfache Zugriffskontrolle u ¨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¨ agen der Passwort- und Gruppendatei ab. Besitzt der Benutzer die nötigen Rechte, gew¨ ahrt der Webserver dem Benutzer den Zugriff. Um ein Verzeichnis auf dem Webserver vor unauthorisiertem Zugriff zu sch¨ utzen, gibt es zwei Möglichkeiten: Zentral in der httpd.conf oder mit Hilfe von .htaccess-Dateien in den zu sch¨ utzenden Verzeichnissen. F¨ ur den zentralen Ansatz muss der Webadmin in der httpd.conf die nachfolgenden Zeilen hinzuf¨ ugen.

194


AuthType Digest AuthName "privat" AuthDigestFile /srv/www/.htpasswd Require valid-user

Dabei handelt es sich bei /srv/www/htdocs/secure das zu sch¨ utzende Verzeichnis, das mit der Digest-Methode abgesichert wird. F¨ ur 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 valid-user Require Group webadmins

Mit der Direktive AuthType wird die Authentifizierungsmethode festgelegt, wobei der Webadmin zwischen Basic und Digest w¨ ahlen kann. Der Unterschied zwischen beiden Module liegt in der Art der Daten¨ ubertragung. W¨ ahrend die Basic Authentifizierung (mod auth basic) die Daten im Klartext u agt und damit ein recht hohes Risiko eingeht, verschl¨ usselt ¨bertr¨ ¨ das Modul mod auth digest die Daten vor der Ubertragung mittels MD5. Da jedoch das Chiffrat abgefangen und mittels Bruteforce-Attacke interpretiert werden kann, empfiehlt ¨ sich bei sensiblen Bereichen die Ubertragung zusätzlich mit Hilfe von SSL zu sichern. AuthType Basic AuthName "Mit BasicAuth nicht wirklich gesicherter Bereich" AuthUserFile /srv/www/.htpasswd Require valid-user

AuthName definiert den Namen des gesch¨ utzten Bereichs. Der hier definierte String wird dem Benutzer bei der Passwort-Abfrage präsentiert. Mit den Direktiven AuthUserFile und AuthGroupFile, beziehungsweise im Fall der Digest Authentifizierung AuthDigestFile und AuthDigestGroupFile wird der Pfad zu der Passwort- und Gruppendatei definiert. Die letzte Zeile des Beispiels legt zus¨ atzlich fest, welche Benutzer berechtigt sind in das Verzeichnis zu wechseln. Hierzu verwendet man die Direktive Require, welche wie bei der Basic Authentifizierung einen g¨ ultigen 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¨ ur die Basic Authentifizierung und htdigest2 f¨ ur 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¨ ugen von Benutzern in bestehende Dateien geschieht durch das Weglassen des Parameters ”-c”. # .htgroup webadmins:user01 user02 normal_user:user03

14.6. WEBSERVER ERWEITERUNGEN

195

Bei sehr vielen Benutzern wird es wie bei der normalen Linux-User-Administration auch, irgendwann aufw¨ andig die Informationen in einzelnen Dateien zu verwalten. Als Alternative bietet sich LDAP an.5 Eine Basic Authentication kann auch gegen eine LDAP-Quelle laufen, die .htaccess zeigt die entsprechenden Einträge: AuthType Basic AuthName "Gegen LDAP authentifizierter Bereich" LDAP_Server localhost LDAP_Port 389 Base_DN "ou=user,dc=mydomain,dc=site" Require valid-user

14.6.4

Kompression

uhrt und erlaubt die KomDas Modul mod deflate wurde mit der Apache Version 2 eingef¨ pression von Webinhalten durch Angabe eines Filters. Das Modul kann ausgehende, sowie auch eingehende Daten komprimieren. Der Datenverkehr wird hierzu u ¨ ber diesen Filter umgeleitet. Um dieses Modul zu aktivieren, trägt ein Admin die folgende Direktiven in der Apache-Konfigurationsdatei ein: SetOutputFilter DEFLATE .. . Abbildung 14.7: PHP-Code

14.10

SSI (Server Side Includes)

Apache stellt mit SSI eine M¨ oglichkeit zur Verf¨ ugung, Internetseiten mit dynamischen Inhalten zu versehen. Um SSI verf¨ ugbar zu machen, muss zumindest f¨ ur einen Teil der Dateihierachie innerhalb von DocumentRoot die Option Include (siehe Kapitel 14.5.1) gesetzt sein. Ausserdem muss ein Dateityp an die Funktionalität gebunden werden (Abbildung 14.8). AddHandler server-parsed AddType text/shtml Options +Include

.shtml .shtml

Abbildung 14.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¨ uhren und beinhaltet Befehle zur Flusskontrolle (Abbildung 14.9).

14.11

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¨ utzt eine ganze Reihe von Skriptsprachen, wie Perl und PHP u ¨ ber Module, Sicherungsmechanismen, wie SSL und weitere Plugins. Die Konfigurationsdateien (Hauptdatei: httpd.conf und SSL-Keys sind unterhalb von /etc/httpd zu finden.

14.11. DOKUMENTATION

203

... ... Abbildung 14.9: SSI-Code

204


Kapitel 15

Netzwerku ¨ berwachung 15.1

¨ Uberblick

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 u ¨ 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¨ altigen Aufgaben u ¨berwachen lassen. Mit diesem Wachstum der LANs (Local Area Networks) entsteht die Notwendigkeit sich ¨ einen schnellen und umfassenden Uberblick u ¨ber den Zustand eines Netzes und der angeschlossenen Maschinen verschaffen zu k¨ onnen. Deshalb existieren inzwischen einige, teilweise ¨ konkurrierende Protokolle zur Uberwachung von Workstations und aktiven Netzwerkkom¨ ponenten. Das am h¨ aufigsten verwendete Verfahren zur Uberwachung und Konfiguration eingesetzter Komponenten ist das Simple Network Management Protocol (SNMP). Eine Reihe ernsthafter Leute hat sich eine Reihe wichtiger Gedanken f¨ ur 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 Ubertragung von Datenpaketen zur Zustandsbeschreibung von Netzwerkgeräten. Jedoch gen¨ ugt es in einigen Fällen nicht, festzustellen, dass ein bestimmter Dienst aktiv ist, indem man u uft, ob der entspre¨berpr¨ chende Prozess in der Liste laufender Programme auftaucht. Es geht nicht darum, eine Innenansicht einer Maschine festzustellen, sondern den Zustand zu u ufen, wie er sich ¨ berpr¨ aus Sicht des Benutzers darstellt. Vielfach ist erst dann eine Aussage sinnvoll, wenn ein Testzugriff u uhrt wurde. F¨ ur diese Art des Monito¨ber das Netzwerk erfolgreich durchgef¨ ring bieten sich Web-, FTP- und Mailserver sowie Authentifizierungsdienste an, da nur so eine Nutzbarkeit aus Sicht des Users emuliert werden kann.

15.2

SNMP - Das Simple Network Mangement Protocol

15.2.1

¨ Uberblick

Das Konzept von SNMP beinhaltet eine verteilte Management Architektur. Das Managementproblem wird in zwei Teile aufgespalten und es werden f¨ ur jeden Teil separate Standards definiert. Der erste Teil befaßt sich mit dem Austausch von Informationen. SNMP 205

¨ KAPITEL 15. NETZWERKUBERWACHUNG

206

basierende Netzwerkmanagementl¨ osungen 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¨ ankt, 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¨ aßig auf Port 161. Die Management Station kann Daten von den zu u ¨berwachenden Agenten (zyklisch) pollen, welche als Server fungieren. Die MIB-Informationen k¨ onnen dann grafisch aufbereitet, dargestellt oder anders verarbeitet werden. Die Host sind jedoch auch in der Lage, gewisse Ereignisse mittels sogenannter Traps (”Fallt¨ uren”) an die Management Station u ¨ ber Port 162 zu melden. Der Informationsaus¨ tausch zwischen den Agenten und dem Uberwachungs-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¨ angern gering und die meisten Befehle und Strukturen abwärts kompatibel.

15.3

Die Datendefinition

Ein u ¨berwachtes Objekt muss bestimmte Zustands- und Kontrolldaten vorhalten, da sie vom Manager abgefragt werden k¨ onnen. Dazu gehören bei Routern sicherlich die Routingtabellen, sowie einkommender und ausgehender Datenverkehr. Switches werden bestimmte Portstatistiken zu transferierten Paketmengen und dabei aufgetretenen Fehlern vorhalten; 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¨ uber 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¨ uhrt werden können und welche Werte sie annehmen können. So hat ein Paketz¨ ahler f¨ ur 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¨ angig von SNMP zu definieren, liegt darin, dass Hersteller von Netzwerkkomponenten neue Variablen einf¨ uhren können. Ein Benutzer kann dieselbe Netzwerkmanagementsoftware, wie f¨ ur die bekannten MIBs verwenden. Nat¨ urlich 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¨ utzt. Dar¨ uberhinaus definiert jeder Anbieter von netzwerkfähiger Hardware weitere MIBs, z.B. die Host-MIB (MIB f¨ ur Endgeräte).

15.3. DIE DATENDEFINITION MIB system interfaces ip tcp udp snmp host

207

Informationen zu/¨ uber ¨ Uberwachtes Ger¨ at, Standort, Eigent¨ umer, Software, Uptime, Ansprechpartner ... Eingebaute reale und virtuelle Netzwerkinterfaces: Mehrere bei Routern und Switches, meistens eines bei Rechnern, Druckern ... IP-Daten, wie Routingtabelle, Paketzähler ... TCP-Daten, wie offene Verbindungen, Paketzähler UDP-Daten, wie offene Ports, Paketzähler Statistiken und Z¨ ahler des SNMP-Agenten Statistiken und Daten klassischer Workstations, wie Speicher, Festplatten, Zahl der Nutzer ... Tabelle 15.1: Einige Standard-MIBs

15.3.1

Der SNMP-Namensraum und die Management Information Bases

Der SNMP-Datenraum ist großz¨ ugig und universell erweiterbar angelegt. Große Teile sind f¨ ur zuk¨ unftige Erg¨ anzungen reserviert und f¨ ur 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¨ oren z.B. der Z¨ ahler (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.1Standard (Abstract Syntax Notation der ISO). Dieses ist eine formale Sprache mit zwei Ausprägungen: Einem kompakten maschinenlesbaren Teil f¨ ur die Verwendung im Kommunikationsprotokoll und einer f¨ ur 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 u ¨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¨ ur SNMP interessanteste Teil des Namensraums wird mittels der sogenannten MIBs aufgespannt. Sie definieren die unterschiedlichen Daten-Domains, die mittels SNMP abgefragt werden k¨ onnen. Sie beinhalten das Schema der abfragbaren Informationen und ¨ die Ubersetzung der OIDs in ihre jeweiligen Namen. Dabei sind die obersten Ebenen des Datenbaumes f¨ ur die Definition der Berechtigungen an einzelne Gruppen reserviert. Der spannendere Abschnitt des SMI-Baumes startet mit OID 1.3.6.1, welcher den Namen


208

”iso.org.dod.internet” tr¨ agt. Hier finden sich die System-, Interface-, TCP/IP, hostspezifische und weitere (herstellerdefinierte) MIBs. Ansehen kann man sich die MIBs mit einem Texteditor, komfortabel wird es jedoch erst mit grafischen Tools. Cheops und TKined haben eingebaute Funktionen um MIBs zu visualisieren, richtig komfortabel wird es mit Mbrowser (siehe [7]), welcher auf NetSNMP aufsetzt und ein GTK-GUI verwendet. Mit mbrowser lassen sich auch die StandardSNMP-Kommandos, wie get, set, walk absetzen, die weiter unten in ihrer Kommandozeilenausf¨ uhrung besprochen werden.

15.3.2

Die SNMP-Agenten

Jeder einzelne Knoten im Netz - Netzwerkkomponenten oder auch Endgeräte, welche sich mittels SNMP verwalten lassen, verf¨ ugen u ¨ber einen Management Agenten. Dieser stellt In¨ formationen in strukturierter Form zur Verf¨ ugung. Anhand dieser erfolgt die Uberwachung und Konfiguration des jeweiligen Ger¨ ates. Die Datenstruktur wird als Management Information Base (MIB) bezeichnet. Die Agenten sind u ¨blicherweise als Softwarelösung in den Netzknoten und Endger¨ aten umgesetzt. Diese Implementation erfolgt bei den Anbietern aktiver Netzwerkkomponenten meistens herstellerspezifisch. Auf einer Linux- bzw. UnixWorkstation stehen daf¨ ur mehrere Implementationen zur Verf¨ ugung. 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¨ utzten MIBs sowie den Werkzeugen zur Erlangung und Visualisierung der Daten.

15.3.3

Der Kommunikations-Code der Agenten

Nun sind die Datentypen und die Struktur der zur Verf¨ ugung 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¨ ur die erw¨ unschte Information beinhalten. Das Schreiben und Lesen von Feldern auf einem Knoten der SMIHierarchie erfolgt mit set und get. Mittels get-next lassen Tabelleninformationen schrittweise anfordern. Die Berechtigung zum Lesen bzw. Schreiben der einzelnen OIDs erfolgt bei SNMPv1 bzw. v2 mittels ”Communitystring” und die Angabe der zum Lesen berechtigten Hosts oder Netzwerke. Die Funktion ”set” ist nicht ganz unkritisch, da es die eine Steuerung von Geräten erlaubt, wie z.B. das Abschalten von Ports auf Switches oder Routern. Dieses ist jedoch unter Sicherheitsaspekten nicht unproblematisch, da die Daten meistens unverschl¨ usselt u ¨ bertragen werden und erst die Spezifikation von SNMPv3 komplexere Authentifizierung erlaubt. Eine Trap (Kommando trap) geht den umgekehrten Weg. Sie erlaubt es Benachrichtigung unabh¨ angig von einer Anfrage des Clients an diesen zu u ¨ bermitteln. Dieses kann f¨ ur das Auftreten bestimmter Ereignisse oder Bedingungen festgelegt werden, läßt sich jedoch nicht f¨ ur beliebige Felder definieren. Standard-Traps sind z.B. die Information zum Start des Servers, Traps, die Ausf¨ alle oder Wiederbelebungen von Netzwerkverbindungen kundgeben und einige Authentifizierungsprobleme. Der Mechanismus zur Definition von Trap-Nachrichten h¨ angt von der jeweiligen Server-Implementierung ab. Switches und Router kennen andere und meistens weitaus mehr verschiedene Traps als Endgeräte, die jedoch

15.4. SNMP-IMPLEMENTIERUNGEN UNTER LINUX

209

meistens nicht genormt sind. Auf einer Linux-Workstation ist es schließlich einfacher andere Konzepte als SNMP-Traps zur Behandlung von Ausnahmesituationen umzusetzen.

15.4

SNMP-Implementierungen unter Linux

Wie bereits kurz erw¨ ahnt stehen unter Linux einige Implementierungen von SNMP zur Verf¨ ugung. 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 u ¨ ber die Projekthomepage (siehe netsnmp.org) bezogen werden. In den meisten Fällen wird man es nicht mehr selbst kompilieren m¨ ussen, da es Bestandteil vieler Linuxdistributionen ist. Gr¨ unde es selbst zu u onnten in notwendigen Bugfixes oder experimentellen ¨bersetzen, k¨ 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 das Programm MRTG zur Darstellung der Auslastung von Netzwerkinterfaces (siehe 15.8) bezieht seine 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.

15.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¨ uber 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 SNMPVersion (1,2 oder 3) f¨ ur die Anfrage angeben sowie Spezifika f¨ ur einzelne Versionen setzen. Da¨ uberhinaus 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¨ ur

210


Tests und einfache Shellskripten. F¨ ur die visuelle Darstellung z.B. der Auslastung einzelner Ports eines Linuxrouters oder eines Switch kommt MRTG (Multi Router Traffic Grapher, siehe Kap. 15.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 Ubersetzung zwischen Nummer und Name auslesen. Dar¨ uberhinaus 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¨ andig ist, sich mittels snmpget oder snmpgetnext einen umfassenden ¨ Uberblick u ugbarer Daten eines Endgerätes oder Netzwerkknotens zu ¨ ber den Baum verf¨ verschaffen, bringt snmpwalk Erleichterung. Dieses Programm erlaubt es den gesamten Datenbaum eines Agenten sukzessive abzufragen oder Unterbäume vollständig abzulaufen. Letzteres geschieht u ¨ 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¨ urzer wird die Ausgabe.

15.6

Konfiguration des UCD-SNMP

15.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 u ¨ blicherweise durch ein Runlevel-Skript in /etc/init.d gestartet. Die ersten vier Abschnitte ([A]-[D]) der Konfigurationsdatei dienen der Authentifizierung, wobei jeweils zu u urfen. In den ¨berlegen ist, welche Hosts welche Daten pollen d¨ meisten Fällen gen¨ ugt eine Beschr¨ ankung auf das lokale Subnetz, wobei jedoch auch aus¨ schließlich die Management Station (also der Rechner, von dem die Uberwachung 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

15.6. KONFIGURATION DES UCD-SNMP

211

ein Zugriff f¨ ur die Nutzergruppe gestattet ist. Festgelegt wird weiterhin der Zugriffsmodus, welcher im Beispiel f¨ ur 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¨ ur die aktuelle Anfrage sichtbar sind oder modifiziert werden d¨ urfen. Wird das eigene LAN als unsicher eingeschätzt, kann eine Authentifizierung nach SNMPv3 eingestellt werden. Die Steuerung erfolgt mit den Kommandos snmpusm f¨ ur die Benutzer- und snmpvacm f¨ ur Zugriffsrechteverwaltung. Jedoch sind Probleme mit Clients zu erwarten, welche nicht SNMPv3 beherrschen. Ohne weitere Konfiguration stellt Net-SNMP die meisten der u ¨blichen Variablen der Standard-MIB unter Linux zur Verf¨ ugung. Abschnitt [E] erlaubt das Setzen der Standardvariablen Location- und Kontakt OID. Wer einen näheren Blick auf die unterschiedlichen MIBs werfen m¨ ochte, 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.

15.6.2

Parameter der ”Enterprise”-Erweiterungen

¨ Uber 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¨ usselwort ”proc” das zu u ¨ 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¨ angigkeit 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

15.6.3

Erweiterung durch externe Skripten und Programme

Abschnitt [G] besch¨ aftigt 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¨ uhren und das Resultat zur¨ uckzumelden. 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

212


liefert eine Ergebnisliste zur¨ uck, wobei die Ergebnisse die Shell-Variable des R¨ uckgabewertes ($?) repräsentieren: enterprises.ucdavis.extTable.extEntry.extResult.1 = 34 enterprises.ucdavis.extTable.extEntry.extResult.2 = 33 enterprises.ucdavis.extTable.extEntry.extResult.3 = 28 enterprises.ucdavis.extTable.extEntry.extResult.4 = 0 enterprises.ucdavis.extTable.extEntry.extResult.5 = 0 enterprises.ucdavis.extTable.extEntry.extResult.6 = 0 enterprises.ucdavis.extTable.extEntry.extResult.7 = 252 enterprises.ucdavis.extTable.extEntry.extResult.8 = 253 enterprises.ucdavis.extTable.extEntry.extResult.9 = 254 enterprises.ucdavis.extTable.extEntry.extResult.10 = 255 enterprises.ucdavis.extTable.extEntry.extResult.11 = 153

Dieses Ergebnis l¨ aß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¨ uhren, welche wiederum das /proc-Device des Kernels auslesen und die evtl. erhaltenen Daten u uckgeben. Die Erweiterung hier dazu ¨ ber den Returnwert zur¨ benutzt, Informationen des System Management Busses (SMB, spezieller Bus moderner ¨ Mainboards zur Steuerung und Uberwachung von Komponenten) zu CPU-Temperatur und Drehzahl der verschiedenen L¨ ufter 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¨ ankung besteht jedoch im maximalen Return-Wert, welcher 255 nicht u ¨ 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:

15.7

¨ Uberwachung weiterer Parameter

Der anschließende Abschnitt ([H]) definiert das Verhalten eines weiteren Astes in der UCDSNMP-MIB. Mit den Object Identifiers diesen Bereiches läßt sich der verbleibende Festspeicherplatz nach Lage im Dateisystembaum beobachten. Der Zahlenwert definiert die untere

¨ 15.7. UBERWACHUNG WEITERER PARAMETER

213

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¨ usselwort 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¨ urlich 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).

15.7.1

Weitergehende Erg¨ anzungen

Wem die einzeilige Ausgabe nur des R¨ uckgabewertes in Abschnitt [G] nicht gen¨ ugte, findet seine Vorstellungen evtl. in [J] gel¨ ost. Mit diesem MIB-Bereich ist es möglich mehrzeilige Ausgaben zuzulassen, die als entsprechende Tabelleneinträge zur¨ uckgeliefert 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¨ otig macht. Eine Konfigurationszeile ist so aufgebaut, dass nach dem Schl¨ usselwort ”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¨ ankungen bez¨ uglich der verwendeten Datenfelder (nur TextFelder oder Return-Codes bis zum maximalen Wert von 255 sind erlaubt), so dass nach einer Testphase (z.B. der Auswertung der Meldungen des SMB) u ¨ber eine feste Einbindung als Modul nachgedacht werden sollte. Eine Anleitung, wie ein Modul f¨ ur den UCD-SNMP zu schreiben ist und wie die dazugeh¨ orige 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¨ urSchrittanleitung ein Makefile, der Beispiel-Code einer SNMP-Applikation und eine TutorialMIB mit Headerdatei und eine C-Sourcedatei. Header und C-Source sind zum größten Teil mit mib2c erstellt worden, was einen guten Ausgangspunkt f¨ ur eigene Versuche liefert. Beim Neu¨ ubersetzen des Agenten kann das experimentelle Modul eingef¨ ugt werden. Auf diesem Wege k¨ onnte der Umweg u ber das oben beschriebene Shellskript zugun¨ sten einer festen Implementierung abgelöst werden. Damit w¨ urden sich weiterhin die Beschränkungen der Variablen aufheben lassen, da man deren Deklaration mittels MIB selbst in der Hand hat.


214

15.7.2

Parameter der Host-Ressource-Erweiterungen

Wurden die SNMP-Bibliotheken und der Agent mit der Unterst¨ utzung f¨ ur die HOSTRESOURCES-MIB u ugung. ¨bersetzt, stehen weitere Informationen zur Verf¨ Unterhalb des Datenbaumes .1.3.6.1.2.1.25, wird diese MIB eingehängt und (unter der Voraussetzung, dass die Werte beschafft werden können) werden die Variablen ausgegeben. Siehe Tabelle 14.4 Beispielkonfiguration, Listing von /etc/ucdsnmpd.conf: # [A] Access Control com2sec local localhost public com2sec mynetwork 172.16.30.0/22 public com2sec mynetwork 10.0.0.0/8 public # [B] group group group group group group

Second, map the security names into group names: MyRWGroup v1 local MyRWGroup v2c local MyRWGroup usm local MyROGroup v1 mynetwork MyROGroup v2c mynetwork MyROGroup usm mynetwork

# [C] Third, create a view for us to let the groups have rights to: view all included .1 # [D] Finally, grant the # write permissions: # context access MyROGroup "" access MyRWGroup ""

2 groups access to the 1 view with different sec.model sec.level match any noauth exact any noauth exact

# [E] System contact information syslocation Internet-AG Universitaet Goettingen syscontact # [F] Process checks. proc automount 2 2 proc X 2 1 proc kdm 1 1 proc ypbind 4 1 proc sshd 10 1 proc axnet 1 0 proc rwhod 1 0 proc cron 1 0 proc xinetd 1 0 proc chooser 1 0 # [G] Executables/scripts exec sensors /bin/sh /usr/share/snmp/sensors exec sensors /bin/sh /usr/share/snmp/sensors exec sensors /bin/sh /usr/share/snmp/sensors exec sensors /bin/sh /usr/share/snmp/sensors exec sensors /bin/sh /usr/share/snmp/sensors exec sensors /bin/sh /usr/share/snmp/sensors exec empty /bin/echo 252 exec empty /bin/echo 253

temp1 temp2 temp3 fan1 fan2 fan3

read all all

write none all

notif none none

15.8. MRTG ALS FRONTEND ZUR ANZEIGE VON ZEITREIHEN

215

exec empty /bin/echo 254 exec empty /bin/echo 255 exec user_activity /bin/sh /usr/share/snmp/uabic # [H] disk checks disk / 100000 disk /tmp 20000 # [I] load average checks load 5 4 4 # [J] Extensible sections exec .1.3.6.1.4.1.2021.51 users /usr/bin/who exec .1.3.6.1.4.1.2021.52 pci_devices /sbin/lspci exec .1.3.6.1.4.1.2021.53 cpuinfo /bin/cat /proc/cpuinfo

15.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¨ ate zu u ¨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¨ anzung 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¨ oglich, da MRTG allen Daten, die es aus dem Router ausließt, in eine Log-Datei schreibt. F¨ ur 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 u ¨ber die zu u ëberwachenden 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 u ¨bersetzt hat, findet man cfgmaker in dem Unterverzeichnis ./run. Ein Aufruf zur Erzeugung der Konfigurationsdatei k¨ onnte 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

216


# 2048kBit leased line # ---------------#Title[leased]: a 2048kBit leased line #PageTop[leased]:
Our 2048kBit link to the rest of the internet
#Target[leased]: 1:[email protected] #MaxBytes[leased]: 200000

15.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 u ¨ ber den man mit dem Netzwerk verbunden ist. Schwierig wird es auch aufkommende objektorientierte Ans¨ atze, wie die Beschreibung mittels XML in SNMP umzusetzen. SNMP war lange Zeit die Spezialit¨ at weniger Netzwerkadministratoren und Programmierer, so dass das Wissen dar¨ uber immer noch nicht sehr weit verbreitet ist. Inzwischen wurde die erdr¨ uckende Vormacht der Kommandozeile durch eine Reihe grafischer Erweiterungen aufgelöst, so dass auch SNMP-Neulingen ein z¨ ugiger Einstieg gelingen kann. Trotz der genannten Probleme ist SNMP aus Sicht des Autors das beste Protokoll zur Netzwerk¨ uberwachung. 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¨ ur Wireless LAN, verf¨ ugen u ¨ ber eine entsprechende Schnittstelle. SNMP in der dritten Version, wie es vor einiger Zeit spezifiziert wurde, erlaubt bessere Authentifizierungsverfahren und Verschl¨ usselung der Daten. Dar¨ uberhinaus ist es mittels Modularisierung u ber Sub-Agenten flexibler geworden. ¨ Die Popularit¨ at von Linux und die inzwischen mit Net-SNMP und anderen frei zur Verf¨ ugung 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 Uberwachungsfunktionen SNMP zum Sammeln der Daten einbezieht, soll im zweiten Teil dieses Artikels besprochen werden.

15.10

Weiterfu ¨ 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 Uberwachung 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

¨ 15.10. WEITERFUHRENDE LITERATUR

OID Standard-OIDs (MIBII) system.sysDescr

Datentyp Beschreibung

system.sysLocation system.sysUpTime system.syscontact system.sysName

text int text text

interfaces.ifNumber interfaces.ifTable

int table

at.atTable ip.ipforwarding

table int

ip.ipAddrTable

table

icmp.* tcp.tcpConnTable

int table

udp.udpTable snmp.* OIDs der UCD-SNMPMIB prTable.*

table int

memory.memTotalReal

int

extTable.*

table

laTable.*

int

systemStats.*

int

ucdExperimental.*

text

table

217

Geräteinformation: Hersteller, Name des Modells, Version der SOftware o.ä. Aufstellungsort des Gerätes Millisekunden seit dem Start des Agenten Kontakt zum Admin des Gerätes Name der Maschine; u ¨blicherweise der DNSName Zahl der vorhandenen Netzwerkschnittstellen Array der verschiedenen Infos pro Schnittstelle (Name, Typ, Geschwindigkeit, MTU) ARP-Tabelle Bei Geräten mit mehreren Interfaces: 1, falls IP-Forwarding stattfindet, sonst 2 IP-Informationen der versch. Interfaces (Broadcast-, Routeradressen, Netzmasken und Metrik) Eine Menge von ICMP-Statistiken Liste der bestehenden TCP-Verbindungen mit Status Liste der offenen UDP-Sockets Eine Menge von SNMP-Statistiken

Tabelle der auf minimal und maximal laufende Instanzen zu u ¨berwachende Prozesse Menge des zur Verf¨ ugung stehenden Arbeitsspeichers Ausbaubare Spezial-MIB zur Ausf¨ uhrung von Programmen und Skripten Load Average Werte (1, 5, 15 Minuten Intervall) Eine Menge systemspezifischer Variablen und Maximalwerte Eintrag f¨ ur die später beschriebene eigene MIB-Erweiterung

Tabelle 15.2: Beispieldaten (OIDs) der Standard-MIBs


218

Kommando get-request get-nextrequest get-bulkrequest response set-request inform-request trap

Bedeutung Ermittele den Wert einer bestimmten Variablen Ermittele den Wert der nächsten Variablen ohne ihren genauen Namen zu kennen Ermittele einen Block von Variablen (z.B. Tabellen) Anwort auf o.g. Requests Speichere einen bestimmten Wert in eine Variable Referenz zu weiteren z.B. Proxy-Daten Antwort, ausgelöst durch einen Event-Trigger

Tabelle 15.3: Das SNMP-Kommando-Set

OID hrSystem hrStorage hrDevice hrSWRun hrSWRunPerf hrSWInstalled

Bedeutung Zahl der laufenden Prozesse und angemeldeten Benutzer Speicher der verschiedensten Form, wie Real Memory, Swap, Memory Buffers Liste verf¨ ugbarer Geräte, wie Drucker, Prozessor, Mainboardchipset Liste der laufenden Prozesse (wie ”ps”) CPU-Verbrauch der laufenden Prozesse Liste der installierten RPM-Pakete (setzt ein System auf Basis des Redhat-Package-Managers voraus) mit Installationsdatum Tabelle 15.4: Variablen der Host-MIB

Kapitel 16

Netzwerkanalyse 16.1

¨ Uberblick

Schon mit einer recht u ¨berschaubaren Anzahl von Werkzeugen läßt sich vielen Netzwerkproblemen qualifiziert zu Leibe r¨ ucken. Eine ganze Reihe sehr einfacher Tools, wie ping, telnet oder netstat steht eigentlich in jeder Grundinstallation einer Linux-Maschine dem Admin zur Verf¨ ugung. Dabei wird das Kommando telnet häufig als Relikt alter Remote-Shells unterschätzt. Es erlaubt einfache Verbindungstests auf TCP-Dienste, um bespielsweise die Erreichbarkeit von Maschinen zu testen, die ICMPs selbst oder deren Firewalls ICMP blockieren. Mit nmap sieht der Admin sich sein Netz und seine Maschinen mit den Augen eines potenziellen Angreifers an. Diesen Hammer muss man jedoch nicht sofort schwingen, wenn man selbst Admin auf der zu untersuchenden Maschine ist. lsof oder netstat zeigen auf Server selbst an, welche Verbindungen gerade offen sind und welche Dienste diese anbieten. Abgerundet wird die Tool-Suite durch Paketsniffer, wobei ethereal fast keine W¨ unsche mehr offen läßt und den Vergleich mit teuren kommerziellen Produkten kaum scheuen muss. F¨ ur das Verst¨ andnis der meisten Aspekte der Netzwerkanalyse sind einige Grundkenntnisse des Aufbaus und der Funktionsweise der Netzwerkprotokolle ganz n¨ utzlich.

16.1.1

Aufgabenfelder

Netzwerkanalysen k¨ onnen sehr unterschiedliche Fragestellungen beantworten. So möchte man vielleicht wissen, ob eine entfernte Maschine, beispielsweise der Webserver, den man nebenbei betreut, u ¨ berhaupt noch erreichbar ist. Oder man fragt sich, weshalb die Daten nur durch die Leitung tr¨ opfeln, obwohl die gemietete DSL-Verbindung mit 2 Mbit/s nicht die langsamste ist. In anderen Szenarien wollen Admins vielleicht wissen, was f¨ ur Informationen ein Client mit einem Server austauscht. F¨ ur den weiteren Verlauf wurden die Fragestellungen in drei Bereiche aufgeteilt. Diese sind nicht völlig streng voneinander abzutrennen. Die Aufteilung soll aber helfen das sehr weite Feld der Netzwerkanalyse zum besseren Verständnis etwas zu strukturieren. Eine klassische Fragestellung ist die Erreichbarkeit von Maschinen und Diensten im Netz. Wenn im Webbrowser die Seite einer bestimmten Site nicht angezeigt wird, kann das verschiedene Ursachen haben. Ein Rechner mit einer Internet-Adresse muss korrekt konnektiert sein, damit er von u ¨berall aus dem Netz erreicht werden kann. Ist dieses gegeben, kommt es im n¨ achsten Schritt darauf an, dass die richtigen Dienste an den richtigen Ports auf Anfragen warten. Nicht nur die b¨ osen Jungs im Netz verwenden Paketsniffer. Diese Klasse von Tools hilft, den Inhalt von Paketen sichtbar zu machen. So werden nicht nur unverschl¨ usselte Standard219

220

KAPITEL 16. NETZWERKANALYSE

protokolle in ihrer Nutzung aufgedeckt, sondern können auch komplexere Fehler gefunden werden. So melden Protokolle wie DHCP selten die kompletten Anfragen eines Clients im Logfile. Ebenfalls haben Clients, die mittels ROM booten gar nicht die Möglichkeit viel Code f¨ ur Debugging im ROM unterzubringen. Hier kann der Netzwerkadministrator herausbekommen, was f¨ ur eine Anfrage der Client mit welchen Parametern gestellt hat. Genauso kann er sehen, ob der Server u ¨ berhaupt geantwortet hat und was den Inhalt dieser Antwort ausmachte. Oft sind Maschinen erreichbar, die Client-Applikation spricht mit dem Server und trotzdem sind die Nutzer im eigenen Netz alles andere als zufrieden mit der Performance. Besonders kritisch wird es beim Telefonieren u ¨ber das Netz via Voice-over-IP oder Online-Spielen. Hier kommt es darauf an, wie eine Leitung oder ein Router ausgelastet ist, in welcher Richtung die Daten haupts¨ achlich fliessen und ob es zu Staus kommt. Nicht immer lassen sich alle Probleme beeinflussen, besonders wenn sie ”irgendwo anders” im Netz auftreten. Oft kann man jedoch den Benutzern eine qualifizierte Auskunft geben, warum beispielsweise die eine VoIP-Verbindung sehr gut, die andere jedoch eher lausig funktioniert.

16.1.2

Namensaufl¨ osung - ja oder nein

Bei der Netzwerkkommunikation sind u ¨blicherweise Maschinen beteiligt, die u ¨ber einen sogenannten Full Qualified Domain Name (FQDN) verf¨ ugen. Sie können damit neben ihrer ¨ IP auch u zwischen Na¨ ber diesen Namen weltweit angesprochen werden. Die Ubersetzung 1 men und IP-Adressen u ¨bernimmt im Hintergrund das Domain Name System . DNS ist ein Dienst, der auf der Basis von IP funktioniert. IP funktioniert ohne DNS, DNS jedoch nicht ohne IP. Bei der Netzwerkanalyse kann es hilfreich sein, sich den Namen der miteinander Daten austauschenden Maschinen anzeigen zu lassen. Eine WWW-Verbindung zu www.google.com erhält je nach Netzteilnehmer sicherlich eine andere Einschätzung, als eine Verbindung zu der etwas kryptischen Adresse s0106000c6ed855d2.vs.shawcable.net. Aber auch der zweite Name gibt ziemlich gut Auskunft u ¨ber die Funktion der Maschine. Jedoch generiert jede Aufl¨ osung einer Adresse in einen Namen zusätzlichen IP-Verkehr. Dieser kann schmale Bandbreiten zus¨ atzlich belasten oder zu hohen Verzögerungen in den Analyse-Tools f¨ uhren, wenn diese auf eine Antwort des jeweiligen DNS-Servers warten m¨ ussen. Bei starker Auslastung von Maschine und Netzwerkinterface gehen dem MonitorTool bei eingeschalteter DNS-Aufl¨ osung auch schon mal Pakete durch die Lappen, da der Aufwand höher ist, als nur IP-Adressen direkt aus dem jeweiligen Paket auszulesen. Deutlich geschickter ist es in vielen F¨ allen die Auflösung nach Namen abzuschalten und später manuell f¨ ur die interessant oder problematisch erscheinenden Verbindungen dieses nachzuholen.

16.2

Erreichbarkeit von Diensten und Maschinen

Die Erreichbarkeit von Maschinen im Internet ist eine Grundvoraussetzung f¨ ur eine erfolgreiche Kommunikation.

16.2.1

Ping und Erweiterungen

In der Schifffahrt senden so genannte Echolote ein Ultraschallsignal aus, um U-Boote und Hindernisse im Wasser zu orten. Das Signal wird reflektiert und mittels speziellem 1

DNS - siehe eigenes Kapitel zu diesem Thema

16.2. ERREICHBARKEIT VON DIENSTEN UND MASCHINEN

221

Empfänger h¨ orbar gemacht. Es ist ein kurzes ”Ping” zu hören. Diesem Mechanismus ist das Kommando ping nachempfunden. Es benutzt das Internet Control Message Protocol, ein IP-Hilfsprotokoll f¨ ur Fehler- und Kontrollmeldungen, wie Ping-Requests und -replys. Ping nimmt als Argument entweder eine IP-Adresse oder einen Hostnamen. Der Name wird per DNS zur IP aufgel¨ ost und diese dann angezeigt: linux02:~> ping google.de PING google.de (216.239.39.104) 56(84) bytes of data. 64 bytes from 216.239.39.104: icmp_seq=1 ttl=240 time=104 ms 64 bytes from 216.239.39.104: icmp_seq=2 ttl=240 time=105 ms --- google.de ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 104.370/104.694/105.018/0.324 ms

Dar¨ uberhinaus meldet ping den (Mis-)Erfolg der Aktion und wie lange die Pakete im Schnitt f¨ ur ihre Reise durchs Netz ben¨ otigten. Man kann zudem probieren auf die Broadcast-Adresse des eigenen Netzes zu pingen. Hier sollte keine Maschine antworten. Andernfalls ist das Subnetz f¨ ur Flood-Pings, eine Denial-of-Service-Attacke zum Vervielfachen von Paketen, anfällig. Ping kennt eine Reihe von Optionen, mit denen sich sein Verhalten anpassen läßt. Mit der Option ”-s” legt man die Paketgr¨ oße fest. Große Pakete brauchen länger als sehr kurze. Sehr große Pakete m¨ ussen fragmentiert werden, bevor sie verschickt werden können. linux02:~> ping -c 1 -s 1400 132.230.9.254 PING 132.230.9.254 (132.230.9.254) 1400(1428) bytes of data. 1408 bytes from 132.230.9.254: icmp_seq=1 ttl=255 time=1.12 ms --- 132.230.9.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.126/1.126/1.126/0.000 ms linux02:~> linux02:~> ping -c 1 -s 50 132.230.9.254 PING 132.230.9.254 (132.230.9.254) 50(78) bytes of data. 58 bytes from 132.230.9.254: icmp_seq=1 ttl=255 time=0.436 ms --- 132.230.9.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.436/0.436/0.436/0.000 ms linux02:~> linux02:~> ping -c 1 -s 14000 132.230.9.254 PING 132.230.9.254 (132.230.9.254) 14000(14028) bytes of data. 14008 bytes from 132.230.9.254: icmp_seq=1 ttl=255 time=5.21 ms --- 132.230.9.254 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.214/5.214/5.214/0.000 ms

Wenn man ein bestimmtes ”Ping” auf der Strecke mit einem Packet-Sniffer identifizieren will, hilft die Option ”-p ”. Damit kann man ein Pattern, ein Muster angeben. Eine grobe Performance-Messung im Netzwerk läßt sich durch Flooding testen ping -f Ziel-Rechner schickt soviele Pakete, wie die Schnittstelle versenden kann. Diese Option ist deshalb nur dem Administrator vorbehalten. Wenn eine ganze Reihe von Maschinen hintereinander angepingt werden sollen, macht es Sinn, nach beispielsweise drei Versuchen abzubrechen und einen Timeout anzugeben. Das regeln ”-c” f¨ ur Count und ”-W” f¨ ur die Wartezeit.

222


Das klassische ping wurde f¨ ur Einzelrechner entworfen, auf Broadcast-Pings sollten Maschinen nicht mehr antworten. F¨ ur das Pingen vieler Maschinen gibt es deshalb das Kommando fping. hermes:~ # fping -C 3 10.8.4.1 : 1.24 0.67 10.8.4.2 : 0.83 0.27 10.8.4.3 : - - 10.8.4.4 : - - 10.8.4.5 : - - 10.8.4.6 : - - 10.8.4.7 : 1.34 0.61 10.8.4.8 : - - 10.8.4.9 : - - 10.8.4.10 : - - -

-q -g 10.8.4.1 0.67 0.25

10.8.4.10

1.02

Im Beispiel wurden alle Maschinen im IP-Bereich von 10.8.4.1 - 10 drei Mal angepingt und das Ergebnis in netter Tabellenform mit den ermittelten Werten dargestellt. Die Option ”-C 3” sorgte f¨ ur Anzahl der Pings und deren Tabellendarstellung, ”-g” nimmt als Argument IP-Listen entgegen. Alternativ zum Beispiel ginge auch 10.8.4.0/29 f¨ ur die ersten acht IPAdressen von 10.8.4.0 - 7. Mit ”-q” beschränkt sich fping auf die Ergebnisdarstellung. Die Nichterreichbarkeit wurde durch das ”-” angedeutet. Fping kennt noch eine ganze Reihe weiterer Optionen, die sich in der ausf¨ uhrlichen Manpage finden. Auf der anderen Seite von ping und traceroute steht das kleine Programm icmpmon. Es protokolliert auf einer Maschine eintreffende ICMP-Pakete. Diese beantworten nicht nur Ping-Anfragen, wie im Beispiel oben. Die Zahl der ”v” steuert die ”Geschwätzigkeit” der Ausgabe. s02:/tmp # icmpinfo -vvv icmpinfo: Icmp monitoring in progress... Apr 12 22:09:39 ICMP_Echo < 132.230.1.142 [login2.ruf.uni-freiburg.de] sz=64(+20) 0000 : 4500 0054 0000 4000 3E01 B037 84E6 018E E..T..@.>..7.... 0010 : 84E6 8117 0800 297E 8248 0001 8D29 5C42 ......)~.H...)\B 0020 : 71C9 0600 0809 0A0B 0C0D 0E0F 1011 1213 q............... 0030 : 1415 1617 1819 1A1B 1C1D 1E1F 2021 2223 ............ !"# [ ... ] Apr 12 22:13:44 ICMP_Time_Exceeded < 129.143.15.141 [Freiburg1.Belwue.DE] > 134.76.60.86 [stud9.stud.uni-goettingen.de] sp=64009 [vcnet-link-v10] dp=33443 seq=0x003037aa sz=36(+20) 0000 : 4500 0038 0000 0000 FC01 27AB 818F 0F8D E..8......’..... 0010 : 84E6 8117 0B00 4078 0000 0000 4500 0044 [email protected] 0020 : 6553 0000 eS.. [ ... ]

Angreifer könnten versuchen durch ICMP-Redirects die Kernel-Routing-Tabelle zu verandern. Weniger dramatisch sind die durch traceroute bewusst ausgelösten Time-Exceeded¨ Meldungen. Sie weisen darauf hin, dass bei einem von der Maschine abgeschickten Paket wärend des Transports die TTL abgelaufen ist.

16.2.2

M¨ ogliche weitere Probleme

Meldet (f)ping die Unerreichbarkeit einer Maschine, kann dieses mehrere Ursachen haben. Es kann beispielsweise ein Fehler im Routing vorliegen. Dann hilft das Kommando traceroute beim Nachverfolgen der Strecke. Oder der Admin der Maschine hat ICMP per Firewall geblockt. Dann gibts f¨ ur den einfachen Test von TCP-Ports Telnet oder das Super-Tool

16.3. NMAP - OFFENE MASCHINEN UND NETZE

223

nmap. Telnet ist eine Netzwerk-Applikation, die TCP benutzt. Als Remote-Login sollten Sie es auf keinen Fall verwenden, da es unverschl¨ usselt arbeitet. Die Auswirkungen sehen Sie weiter hinten bei ethereal. Es eignet sich jedoch gut, auf die Erreichbarkeit von TCPPorts zu testen. An einer Konsole gibt man ein: telnet Ziel-Host Ziel-Port. Ziel-Host kann eine IP-Adresse oder ein Rechnername sein. Der Zielport ist eine Zahl zwischen 0 und 65535 oder das Dienstk¨ urzel. Die Zuordnung der Portnummern zu Namen f¨ ur TCP und UDP findet sich in der Datei /etc/services. Nicht nur das Programm Telnet macht von dieser Datei Gebrauch. So liefert ein ”get” auf Port 80 (alternativ: http) eines HTTP-Servers oft eine mehr oder weniger sinnvolle Antwort, SMTP-Server melden sich mit ihrer Kennung und Dienste, die SSL verwenden, lehnen zumindest die Verbindung nicht ab. Lauscht kein Dienst am angesprochenen Port, dann lehnt der Ziel-Host die Verbindung ab. dirk@mobile ~ $ telnet rz.uni-freiburg.de smtp Trying 132.230.2.42... Connected to rz.uni-freiburg.de. Escape character is ’^]’. 220 uni-freiburg.de ESMTP CommuniGate Pro 4.2.9 is glad to see you! ^] telnet> close Connection closed.

Im Beispiel meldete sich der SMTP-Server mit seiner Versionsnummer. Aus der TelnetSitzung kommt man mit dem Tastaturk¨ urzel [Strg]-[AltGR]-[9]” (”ˆ]”) wieder heraus.

16.3

NMAP - offene Maschinen und Netze

Jeder Dienst, der sich ansprechen l¨ asst und jedes Netz, in das man eindringen kann, bietet zwangsläufig Angriffspunkte. Das ”Hacker-Werkzeug” schlechthin ist nmap. Es dient dazu, offene Netze und auf den enthaltenen Maschinen offene Ports zu finden. Beim Portscanning geht es bildlich gesehen um das ”Anklopfen an die verschiedenen T¨ uren” des Zielrechners, um festzustellen ob sich etwas Interessantes dahinter befindet. Genauer gesagt will ein Angreifer u ¨ blicherweise herausfinden welche TCP und UDP-Dienste auf dem Zielsystem laufen, um sich durch diese gegebenenfalls unauthorisierten Zugang zum System zu erlangen. Um Problembereiche in eigenen Netzen selbst aufzusp¨ uren, sollte man die Tools kennen und unter Umst¨ anden benutzen, da sie Auskunft geben, was potenzielle Angreifer reizvoll finden könnten. Die gescannten Ports einer Maschine klassifiziert Nmap in der folgenden Weise: • open: Ein Dienst akzeptiert an diesem Port eingehende TCP oder UDP-Connects. Ein offener Port kann gegebenenfalls missbraucht werden, um Zugang zum Zielsystem zu erlangen • closed: Ein Port, der als ”closed” festgestellt wurde, ist zwar erreichbar, aber unbenutzt. Es arbeitet kein Dienst dahinter. Dennoch kann es sinnvoll sein, solche Port zur OS-Erkennung mit einzubeziehen. • unfiltered: Dieser Zustand kann nur beim ACK Scan auftreten, bei dem versucht wird die Firewall-Regeln zu mappen. Mit ”unfiltered” bezeichnet Nmap erreichbare Ports von denen es nicht entscheiden kann ob sie offen oder nicht benutzt sind. • filtered: Wenn der Portscanner nicht in der Lage ist zu erkennen, ob ein Port ”open” oder ”closed” ist, wird er als ”filtered” eingestuft. In solchen Fällen verhindert eine Firewall (als Paketfilter) das Erreichen des Ports.

224

KAPITEL 16. NETZWERKANALYSE • open, filtered: Dieser Zustand tritt bei Scans ein, bei welchen von offenen Ports keine Antwort erwartet wird. Hierbei kann die fehlende Antwort auch Resultat einer Firewall sein, die den Port blockiert. • closed, filtered: Nmap ist sich unsicher, ob der Port als ”offen, filtered” einzustufen ist.

16.3.1

Scan-Methoden

Nmap implementiert eine weitreichende Sammlung von Scan-Methoden, die in Abhängigkeit eines erwarteten Dienstes an einem Port, benötigt werden um eine korrekte Identifizierung zu erreichen. Dar¨ uberhinaus erlaubt Nmap die Offensichtlichkeit eines Scans zu reduzieren. Die nachfolgende Liste stellt die wichtigsten Scans zusammen: • TCP SYN ”-sS” Der SYN Scan wird auch als halboffener Scan bezeichnet, da auf den kompletten Three-Way-Handshake verzichtet wird. Wenn nach dem senden des TCP Paketes mit dem SYN-Flag ein ACK als Antwort folgt, geht Nmap von einem offenen Port aus. Kommt als Antwort ein RST, wird der Port als geschlossen deklariert und wenn keine Antwort oder ein ICMP UNREACHABLE Fehler folgt, kann man vermuten, dass eine Firewall den Datenverkehr kontrolliert. F¨ ur den SYN Scan braucht der Nmap-Benutzer Admin-Rechte, da sogenannte Raw-Packets verschickt werden. SYN Scans sind nur schwer zu erkennen, da keine vollständige TCP Verbindung aufgebaut wird. Diese Methode arbeitet sehr schnell. • TCP Connect() ”-sT” Der TCP Connect() Scan kommt dann zum Einsatz, wenn ein SYN Scan nicht m¨ oglich ist. Es wird eine komplette TCP Verbindung zum jeweiligen Port aufgebaut. Nmap verwendet hierf¨ ur den connect() Systemaufruf, wie er auch von Web-Browsern und in P2P Netzwerken verwendet wird um eine Verbindung zu initiieren. Diese Methode arbeitet deutlich langsamer als der SYN Scan und hinterlässt zudem Spuren in den Log-Dateien des Zielsystems. • TCP Null ”-sN” Bei dieser Methode wird ein TCP Paket ohne gesetzte Flags abgeschickt. H¨ alt das Zielsystem RFC 793 ein, sendet es ein RST f¨ ur alle geschlossenen Ports und keine Antwort f¨ ur alle offenen Ports zur¨ uck. • TCP FIN ”-sF” Bei dieser Methode wird ein TCP Paket mit gesetztem FIN-Flag abgeschickt. Wird das RFC 793 auf dem Zielsystem eingehalten, kommt ein RST f¨ ur geschlossene Ports und keine Antwort f¨ ur offene Ports zur¨ uck. Dieser Ansatz funktioniert normalerweise nur bei UNIX basierten TCP/IP Stack Implementationen, da sich Microsoft nicht an die Standards gehalten hat. • TCP Xmas ”-sX” Bei dieser Methode wird ein TCP Paket mit gesetztem FIN-, URGund PSH-Flag abgeschickt. Es gilt das oben zu RFC 793 gesagte. • TCP Ack ”-sA” Diese Methode wird dazu verwendet mehr u ¨ber die Firewall herauszufinden. Durch schicken eines TCP Paketes mit gesetztem ACK Flag sieht es so aus als wenn vom internen Netz ein SYN Paket geschickt worden wäre und wird somit von einem normalen Paketfilter durchgelassen. Ein zustandsbezogener Paketfilter merkt hingegen, dass kein SYN Paket vom internen Netz gesendet wurde und blockiert das Paket.

16.3. NMAP - OFFENE MASCHINEN UND NETZE

225

• Individual ”–scanflags” Nmap erlaubt es TCP Pakete mit individuellen Flags abzuschicken. Dies kann sinnvoll sein, da viele Intrusion Detection Systeme StandardScans entdecken k¨ onnen. So schickt man mit der Option --scanflags FINURG ein TCP Paket mit gesetztem FIN und URG Flag ab. Zusätzlich wird festgelegt, wie R¨ uckmeldungen interpretiert werden sollen. Zum Beispiel wird bei ”-sA” keine R¨ uckmeldung als ”Port offen” interpretiert. • UDP ”-sU” UDP Scans sind sehr zeitaufwendig, jedoch unumgänglich um UDPbasierte Dienste wie beispielsweise TFTP, DHCP, DNS oder SNMP zu entdecken. Der UDP Scan kann mit einem der TCP-Scans kombiniert werden. Eine technisch gesehen interessante Untersuchung ist der Idle-Scan. Hierbei handelt es sich um einen ”blinden” TCP Scan. Bei dieser Methode wird die IP Fragmentation-ID ausgenutzt um u ¨ ber eine weitere Maschine das Zielsystem auszuspionieren. Die untersuchte ¨ Maschine darf zum Uberpr¨ ufungszeitpunkt nicht im Netzwerk ativ sein. Dann erhöht sich die Fragment-ID nur um +1 wenn der angesprochene Port beim Zielsystem geschlossen ist und um +2 wenn der Port offen ist. Abgesehen von der Unsichtbarkeit des Angreifers, da es so aussieht als ob die dritte Maschine den Scan initiiert hat, können auf diese Weise Vertrauensbeziehungen zwischen Systemen ermittelt werden. Wenn beispielsweise der Zugriff auf eine Datenbank auf einer anderen Maschine nur dem Web-Server gestattet ist, jedoch nicht dem normalen Internet-Nutzer, zeigt ein direkter Portscan keine offenen Ports an, ein Idlescan mit dem Web-Server als Zombie jedoch sehr wohl. Eine weitere M¨ oglichkeit besteht mit FTP Bounce Scans ”-b user:passwort@ftpserver:port” bei schlecht konfigurierten FTP-Servern. So ist es möglich diese als Portscan-Proxys zu missbrauchen. Der FTP-Server kann angewiesen werden eine Datei an Ports eines dritten Systems zu schicken. Anhand der resultierenden Fehlermeldung kann herausgefunden werden ob der entsprechende Port ge¨ offnet oder geschlossen ist. Vorteil ist die Verschleierung des Scans gegen¨ uber des Zielsystems, ausserdem kann, wenn ein FTP-Server aus dem Zielnetz missbraucht wird, die Firewall umgangen werden.

16.3.2

Aufruf und Benutzung

Nmap arbeitet in der klassischen Ausgabe auf der Kommandozeile. Es gibt aber auch ein GTK-Frontend - nmap-fe, welches die Benutzung unter einer grafischen Oberfläche erleichtert. Es blendet am unteren Bildrand die Befehlszeile ein, wie es nmap aufruft. So läßt sich die Wirkung der einzelnen Schalter im User-Interface sehen. Auch auf der Kommandozeile kennt nmap einen interaktiven Modus; aufzurufen durch nmap --interactive. Um festzustellen, wieviele Maschinen ein Netz enthält, kann man ein ganzes Subnetz pingen, was einfacher als der direkte Versuch mit ping ist. Hierzu ruft man nmap wie folgt auf: hermes:~ # nmap -sP 10.8.4.0/24 Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2005-09-29 00:42 CEST Host 10.80.4.0 seems to be a subnet broadcast address (returned 1 extra pings). Host 10.80.4.1 appears to be up. MAC Address: 00:0F:66:C7:73:E8 (Cisco-Linksys) Host dell.wg.site (10.8.4.204) appears to be up. MAC Address: 00:08:74:4D:6F:3F (Dell Computer) Host 10.80.4.212 appears to be up.

226


MAC Address: 00:02:B3:C2:55:91 (Intel) Host 10.80.4.220 appears to be up. MAC Address: 00:10:A4:8D:56:0A (Xircom) Host hermes.wg.site (10.8.4.254) appears to be up. Host 10.80.4.255 seems to be a subnet broadcast address (returned 1 extra pings). Nmap run completed -- 256 IP addresses (5 hosts up) scanned in 5.475 seconds

Nmap scannt ganze Netze in der Form 192.168.2.0/24 f¨ ur ein Klasse-C-Netz oder IP-Netze durch Angabe von Wildcards und Reichweiten: 192.168.1-11.* Man kann auch nur einzelne Rechner durch Angabe der Host-IP oder des Namens direkt ansprechen. F¨ ur die meisten Scans werden Root-Rechte ben¨ otigt: wie f¨ ur ”-sS”, den SYN Port-Scan oder ”-sU”, den UDP-Scan. Nmap kann sein Timing f¨ ur Scans durch die Angabe von ”-T Art” sehr unterschiedlich intensiv gestalten. Es existieren eine Reihe weiterer Optionen von nmap, die ein effektives Untersuchen von Zielsystemen erleichtern: • Dont Ping ”-P0” Dies ist eine M¨ oglichkeit Nmap anzuweisen ein Zielsystem zu scannen ohne dieses vorher ”anzupingen”. Da viele Systeme im Internet nicht auf ICMP ”Echo Requests” antworten, ist es oft sinnvoll diesen Parameter zu benutzen. • Timing ”-T0-5” Der default Timingwert von Nmap steht auf -T3. Wenn man u ¨ ber einen schnellen Internetzugang verf¨ ugt, lässt sich zur Beschleunigung des Scans die Option ”-T4” verwenden. Mit der Option ”-T5” gehen meist zu viele Antworten des Zielsystems verloren, da Nmap nicht lange genug auf Antwortpakete wartet. Um bei hohen Sicherheitsstandards des Zielsystems zu verhindern, dass ein IDS den Scan bemerkt, kann das Timing mit ”-T0” oder ”-T1” herunter gesetzt werden. Dieses erhöht selbstredend die Dauer eines Scans. ¨ • Ports ”-p ports” Ublicherweise scannt nmap nicht alle 65535 Ports, da dieses wegen der abzuwartenden Timeouts viel zu lange dauern w¨ urde. Es beschränkt sich auf die privilegierten niedrigen Portnummern. Wenn ein bestimmter Dienst gesucht wird, ist es effektiver wenn der Scan nur bestimmte vordefinierte Ports eingeschränkt wird. Das regelt die Option ”-p 1-1023,1080,2237,5060,6667”. • Versionserkennung ”-sV” Da Dienste nicht unbedingt auf ihrem Standard-Port lauschen m¨ ussen, verf¨ ugt nmap u ¨ ber eine umfangreiche Versions-Erkennung von unterschiedlichen Diensten. Dazu greift es auf die eigene ”service probes” Datenbank zur¨ uck, welche es erlaubt viele Dienste anhand ihres Verhaltens zu identifizieren. Wenn man mit nmap ein Netz regelmäßig u ufen will, startet es am besten skript¨berpr¨ gesteuert im Hintergrund. Man kann mit ”-iL Datei” die Ziele aus einer Datei lesen und mit ”-oN/-oX/-oG Log-Datei” die Ergebnisse im Normal-, XML- oder grep-optimierten Format in ein Logfile schreiben lassen. Die DNS-Auflösung lässt sich wie von anderen Netzwerkkommandos gewohnt mit der Option ”-n” abschalten.

16.3.3

OS-Fingerprinting

Wenn man feststellen m¨ ochte, was f¨ ur ein Betriebssystem sich hinter einer Maschine verbirgt, hilft die Option ”-O” f¨ ur den OS-Fingerprint. TCP/IP ist zwar standardisiert, aber nicht jedes Betriebssystem antwortet gleich. Beim sogenannten Stack-Fingerprinting wird anhand von spezifischen Reaktionen auf bestimmte auch ”kaputte” Anfragen erkannt, welches Betriebssystem auf dem Zielsystem installiert ist. Es gibt zahlreiche Hinweise, die zur Erkennung der unterschiedlichen Betriebssysteme f¨ uhren können:

16.4. DIE EIGENEN DIENSTE UND VERBINDUNGEN KENNEN

227

• TCP ISN Muster: Hierbei wird nach Mustern in der initialen Sequenznummer, welche von der TCP-Implementation ausgewählt wird, gesucht. • IP oder Fragment-ID: Die meisten Betriebssysteme erhöhen eine systemweite FragmentID im IP-Header f¨ ur jedes abgeschickte Datenpaket. OpenBSD geht hier anders vor und wählt die Fragment-ID zuf¨ allig. Bei Windows wird das Header-Feld f¨ ur jedes Paket um 256 erh¨ oht. Vorhersagbare ID’s können zu Sicherheitsproblemen f¨ uhren, da sie beispielsweise Scans u ber Dritte erlauben. ¨ • Dont Fragment Bit: Viele Betriebssysteme verwenden das ”Dont fragment” Feld im IP-Header in einigen F¨ allen zur Optimierung des Datentransfers. Jedoch wird dies auch nicht von allen Betriebssystemen unterst¨ utzt und von manchen nur in bestimmten Fällen eingesetzt. • FIN Sonde: Sendet ein TCP FIN Paket und wartet auf Antwort. Nach RFC 793 sollte keine Antwort zur¨ uck kommen, jedoch senden viele schlampige Implementationen des TCP-Protokolls, wie bei Microsoft Windows, ein RST-Paket zur¨ uck. • Bogus Sonde: Es wir ein TCP SYN Paket mit undefiniertem Flag auf Bit 7 oder ¨ 8 geschickt. Altere Linux Kernel schicken in ihrem Antwort Paket das undefinierte Flag wieder mit. Andere Betriebssysteme brechen die Verbindung ab, wenn in einem TCP-Paket ein SYN zusammen mit einem undefinierten Flag eintrifft. • TCP Zeitstempel: Der TCP Zeitstempel ist ein optionaler Wert. Manche IP-Stacks unterst¨ utzen ihn nicht, andere erh¨ ohen den Zeitstempel in bestimmten Frequenzen. Nmap kann mithilfe des Zeitstempels auch die ”uptime” einer Maschine bestimmen. • TCP Initiales Fenster: Nmap kann oft schon durch die alleinige Bestimmung der ”inital window size” ermitteln, welches Betriebssystem antwortet, da diese meistens sehr spezifisch ist. • ICMP Behandlung: Einige Betriebssysteme regulieren die Rate des Sendens von Fehlermeldungen. Bei ICMP Fehlermeldungen wird von manchen Betriebssystemen ein Teil der Nachricht zur¨ uckgeschickt, welche den Fehler verursacht hat. Auf diese Weise können sogar Systeme ohne offene Ports identifiziert werden. • Type of Service: Bei ICMP PORT UNREACHABLE Nachrichten wird normalerweise das ToS Feld im IP-Header auf 0 gesetzt. Linux verwendet hier aber zum Beispiel 0xC0 als Wert. • Fragmentation Handling: In vielen TCP-Implementationen werden u ¨ berlappende IPFragmente unterschiedlich behandelt. Entweder wird das alte Fragment mit dem Neuen u ¨berschrieben oder das alte Fragment bleibt erhalten. Die verschiedenen Anfragen ausgewertet und zusammengefasst, liefern eine Art Fingerabdruck eines Betriebssystems. Das funktioniert ganz gut, aber selten mit letztg¨ ultiger Sicherheit.

16.4

Die eigenen Dienste und Verbindungen kennen

Ist man auf einer Maschine Root, muss man nicht mit nmap die verschiedenen NetzwerkInterfaces abscannen, um zu wissen, welche Dienste gerade laufen. Hierzu helfen die Programme netstat und lsof weiter.

228


netstat ist ein Statistik-Tool, welches die Kernelnetzwerkschnittstellen ausliest. Netstat mit der Option ”-t” liefert alle bestehenden TCP, mit der Option ”-u” alle UDPVerbindungen. Es zeigt jedoch nur zusammen mit der Option ”-a” alle offenen Server-Ports an. Die letzte Option alleine aufgerufen, zeigt eine vollständige Liste aller Ports und Sockets, auch die verwendeten Unix-Domain-Sockets im Dateisystem. Die Liste wird u ¨blicherweise recht lang ausfallen. M¨ ochte man nicht auf die Namensauflösung f¨ ur bestehende Verbindungen warten, kann man diese mit ”-n” abschalten. Die Paketstatistik erf¨ ahrt man mit netstat -s. Auch diese Ausgabe fällt länger aus: linux02:~ # netstat -s Ip: 58239052 total packets received 418723 forwarded 0 incoming packets discarded 53456498 incoming packets delivered 50859142 requests sent out 1 outgoing packets dropped 68 dropped because of missing route 3 fragments dropped after timeout 123341 reassemblies required 82569 packets reassembled ok 1 packet reassembles failed 3 fragments received ok Icmp: 3537 ICMP messages received [ ... ]

Anhand dieser Statistiken lassen sich bereits Unregelmäßigkeiten feststellen. Wenn viele Fehler in bestimmten Kategorien auftreten, könnte beispielsweise ein Scanversuch gelaufen oder gezielt kaputte Pakete geschickt worden sein. Netstat kennt eine ganze Reihe weiterer Optionen, um die Ausgaben beispielsweise f¨ ur einzelne Interfaces zu verfeinern. Auskunft gibt wie u ¨blich die umfangreiche Man-Page. Ist das IProute2-Paket installiert, liefert das Kommando ntop ebenfalls eine ausf¨ uhrliche ¨ Ubersicht, die sich etwas anders als bei Netstat darstellt: linux02:~ # nstat #kernel IpInReceives IpInDelivers IpOutRequests IpReasmReqds IpReasmOKs IpFragOKs IcmpInErrors IcmpInDestUnreachs IcmpInTimeExcds IcmpInParmProbs IcmpInEchoReps IcmpInTimestamps IcmpOutErrors IcmpOutTimeExcds IcmpOutTimestamps TcpActiveOpens TcpPassiveOpens TcpAttemptFails TcpEstabResets

489769 489663 637864 10 1 1 184367 92113 184618 1 31 7 155388 145357 31 94469 56 95419 133

0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

¨ 16.5. SCHNUFFELN IM DATENVERKEHR TcpInSegs TcpOutSegs TcpRetransSegs TcpInErrs TcpOutRsts UdpInDatagrams UdpNoPorts UdpOutDatagrams Ip6InReceives Ip6InDelivers Ip6OutRequests Ip6OutMcastPkts [ ... ]

245980 455926 92354 1 1229 93009 60 6521 6 6 18 12

229 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

lsof ist ebenfalls ein vielseitiges Analyse-Tool. Normalen Benutzern zeigt es beim Aufruf Dateien und Verbindungen an, die sie selbst geöffnet oder in Verwendung haben. Dem Systemadministrator offenbart es s¨ amtliche Verbindungen, offenen Ports und Dateien. lsof kennt wie die meisten Netzwerkkommandos die Option ”-n” f¨ ur die Unterdr¨ uckung der Namensauflösung. Dasselbe f¨ ur Ports erreicht man mit ”-P”. Alle Netzwerkverbindungen lassen sich mit ”-i” anzeigen, mit ”-i6” schränkt man diese f¨ ur IPv6 und entsprechend mit ”-i4” f¨ ur IPv4 ein: hermes root # lsof -i4 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME dhcpcd 8607 root 4u IPv4 8377 UDP *:bootpc ssh 24599 dirk 3u IPv4 28337 TCP 10.8.4.220:3934-> \ ns.wg.site:ssh (ESTABLISHED) ssh 28138 dirk 3u IPv4 32029 TCP 10.8.4.220:1188-> \ ns.wg.site:ssh (ESTABLISHED)

16.5

Schnu ¨ ffeln im Datenverkehr

In den bisherigen Betrachtungen ging es um die Erreichbarkeit von Maschinen und ihrer Dienste. Dabei lag der Fokus auf den Endpunkten der Kommunikationsverbindungen. Die meisten Netzwerkdienste laufen als Client-Server-Applikation. Dabei können Clients und Server komplett unterschiedliche Maschinen sein und Betriebssysteme fahren. Damit sich beide korrekt verst¨ andigen, kommt es darauf an, dass sie die ”richtige Sprache” miteinander reden. Da das verbindende Element das dazwischenliegende TCP/IP-Netzwerk ist, lassen sich durch die Beobachtung des Paketaustausches schon R¨ uckschl¨ usse auf bestimmte Fehler ziehen. Wenn man sich vielleicht wundert, weshalb die Namensauflösung in Ihrem Netz so lange dauert, oder was beim Teilumstieg auf IPv6 schief gegangen ist, reicht oft nicht das Debugging an der Applikation aus. Da hilft dann vielleicht der Blick auf die Netzwerkschnittstellen und in die Pakete hinein. Hierbei wird auch offenbar, wie einfach es ist, die Daten mitzulesen, die Applikationen unverschl¨ usselt austauschen.

16.5.1

Analysen auf der Kommandozeile

F¨ ur die Kommandozeile existiert schon sehr lange das Programm tcpdump. Es basiert wie das im Anschluss vorgestellte grafische Ethereal auf der Libpcap-Bibliothek. Diese stellt Schnittstellen zur Verf¨ ugung, die es erlauben Pakete in ”Rohform” beispielsweise auf einem Ethernet-Interface abzugreifen und zu interpretieren. Die Netzwerkschnittstelle, an die sich tcpdump h¨ angen soll, legt man mit der Option ”-i Interface” fest, z.B. tcpdump -i eth1 f¨ ur die zweite Ethernet-Karte. Im Augenblick des Starts beginnt tcpdump Pakete

230


mitzuschreiben und in die Konsole auszugeben. Dabei schreibt es nicht den gesamten Paketinhalt heraus, sondern reduziert die Information auf wichtige IP-Header-Informationen, wie Quell- und Zieladressen, sowie Quell- und Zielports. Neben diesen Daten stellt es die Zeit des Paketempfanges sowie Teile des Inhalts, die es interpretieren konnte, dar. Eine einfache Ausgabezeile ist somit wie folgt aufgebaut: ”Zeit Protokoll Quelle.Port ¿ Ziel.Port: Kurzinterpretation des Inhalts” Will man statt der IP-Adressen die Link-Layer-Adressen, z.B. MACs im Ethernet sehen, geschieht das durch die Angabe der Option ”-e”. linux02:/tmp # tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:24:06.921126 IP fay1.test.site.netbios-dgm > 10.17.9.255.netbios-dgm: NBT UDP PACKET(138) 17:24:06.945264 IP linux022.test.site.32838 > dns1.wg.site.domain: 62160+ PTR? 255.9.230.132.in-addr.arpa. (44) 17:24:06.946275 IP dns1.wg.site.domain > linux022.test.site.32838: 62160 NXDomain* 0/1/0 (137) 17:24:06.946396 IP linux022.test.site.32838 > dns0.wg.site.domain: 62161+ PTR? 44.9.230.132.in-addr.arpa. (43) 17:24:06.947295 IP dns0.wg.site.domain > linux022.test.site.32838: 62161* 1/3/3 (212) 17:24:06.947546 IP linux022.test.site.32838 > dns1.wg.site.domain: 62162+ PTR? 201.200.17.10.in-addr.arpa. (46) 17:24:06.948799 IP dns1.wg.site.domain > linux022.test.site.32838: 62162* 1/3/3 (208) 17:24:06.954624 IP linux022.test.site.32838 > dns0.wg.site.domain: 62163+ PTR? 200.200.17.10.in-addr.arpa. (46) 17:24:06.955777 IP dns0.wg.site.domain > linux022.test.site.32838: 62163* 1/3/3 (208) 17:24:07.296782 802.1d config 8000.00:d0:95:7e:ec:3a.7205 root 8000.00:09:97:30:38:0a pathcost 4 age 1 max 20 hello 2 fdelay 15 17:24:07.922224 IP fay1.test.site.netbios-dgm > 10.17.9.255.netbios-dgm: NBT UDP PACKET(138) 11 packets captured 11 packets received by filter 0 packets dropped by kernel

Nun ist trotz stark verk¨ urzten Inhalts auch bei geringem Traffic die Konsole sehr schnell voll. Hier gibts nun einige M¨ oglichkeiten. Die mitgeschnittenen Daten kann tcpdump mit der Option ”-w Datei” in ein Logfile schreiben. Statt von einer Schnittstelle kann es mit ”-r Datei” Daten zur Analyse aus einer Datei aufbereiten. Wenn alles mitgeschnitten wird, können später auch wirklich alle Informationen angesehen werden; bei großen Datenmengen ist jedoch der Plattenplatz irgendwann ein begrenzender Faktor. Eine sinnvolle Alternative bietet sich durch die Benutzung von Filtern. So schneidet man nur jene Informationen mit, die Ihnen in der gegebenen Situation (hoffentlich) weiterhelfen und ignorieren die anderen Daten einfach. Filter können bei tcpdump hinter den Optionen angegeben werden. Sie werden als Pseudo-Code geladen und bez¨ uglich der eintreffenden Pakete interpretiert. Filterausdr¨ ucke k¨ onnen sich auf die verschiedenen Header beziehen. Es gibt eine Reihe von Schl¨ usselworttypen: • Typ 1 bestimmt den oder die zu identifizierenden Rechner. Hierzu zählen die Schl¨ usselwörter host, net und port. Mit ”host 10.8.4.1” wird festgelegt, dass man alle Daten sehen will, die an diese Maschine gehen oder von dieser kommen. Das geht auch f¨ ur ganze Netze in der Form ”net 192.168.200.0/23” oder f¨ ur bestimmte Ports ”port 25”.

¨ 16.5. SCHNUFFELN IM DATENVERKEHR

231

¨ • Typ 2 - F¨ ur Typ 1 war die Ubertragungsrichtung egal. Soll diese eine Rolle spielen, stehen die K¨ urzel src und dst zur Verf¨ ugung. Durch ”src host 10.8.4.23” fängt man nur IP-Pakete von der Adresse 10.8.4.23 ein. Auf den Ausdruck ”dst port 22” passen alle Pakete an den Standardport von SSH. • Typ 3 k¨ ummert sich schliesslich um die verschiedenen Protokolle. Er kennt die Ausdr¨ ucke arp, ether, fddi, ip, ip6, rarp, tcp, udp und wlan. Um alle ARP-Pakete auf dem ersten Ethernet-Interface zu sehen, startet man einfach tcpdump -i eth0 arp. Nun ist die Welt vielleicht doch noch etwas komplexer. Um feiner abgestimmte Abfragen zu bauen, lassen sich Filterausdr¨ ucke mittels logischem UND (and) sowie logischem ODER (or) miteinander verkn¨ upfen. Die Negation von Ausdr¨ ucken ist ebenfalls möglich. Mit tcpdump host 10.8.4.254 and 10.8.4.1or10.8.4.2 hält man die Kommunikation von 10.8.4.254 mit den beiden Maschinen 10.8.4.1,2 fest. tcpdump net 10.8.4.0/24 and \!10.8.4.254 greift alle Pakete des Subnetzes auf, die nicht die Maschine 10.8.4.254 zum Ziel oder als Quelle haben. Weitere Filter, beispielsweise das Matchen auf Paketlängen oder die Erkl¨ arungen zus¨ atzliche Optionen finden sich in der ausf¨ uhrlichen Hilfe zum Programm; man tcpdump.

16.5.2

Das Ganze in Bunt

So richtig komfortabel ist tcpdump sicherlich nicht. Es hat den entscheidenden Vorteil, dass es nicht auf eine grafische Umgebung angewiesen ist. Steht diese aber zur Verf¨ ugung, läßt sich das Leben mit ethereal stark erleichtern. Es macht eigentlich ziemlich genau das gleiche, wie tcpdump. Nur stellt es die Ergebnisse in einem dreiteiligen Benutzerinterface sehr gut lesbar dar. Im oberen Teil der Applikation sind alle mitgeschnittenen Pakete auf-

Abbildung 16.1: DNS-Anfrage - man sieht, dass der Client zuerst nach einer IPv6 und dann nach einer IPv4 Adresse anfragt gelistet, die sich leicht nach fortlaufender Nummer, Quelle, Ziel oder Protokoll umsortieren lassen. Dazu muss man lediglich auf den Tabellenkopf klicken. Im mittleren Teil ist das oben

232


markierte Paket nach seinen Schichten aufgegliedert zu sehen. Der oberste Eintrag bezieht sich auf das gesamte Frame im Rohformat. Anschließend folgt der Ethernet-Header oder andere Layer2-Header. Dann kommt IP, IPv6 oder ein anderes Protokoll der Verbindungsschicht. Darauf folgend der Transport-Kopf, also meistens der TCP- oder UDP-Header. Zum Schluss sieht man die Applikationsdaten, die ethereal versucht weitestgehend zu interpretieren. Im unteren Fensterdrittel stellt ethereal das Paket als Hexdump dar und markiert den Protokollteil, der in der Mitte markiert wurde. Die Paketanalyse wird denkbar einfach: Man starte Ethereal und wählen u u ¨ber das Men¨ ”Capture > Start” aus. Hier tr¨ agt man noch das Interface ein, das mitgeschnitten werden soll und los gehts mit ”OK”. Es erscheint ein neues Fenster ”Capture from ...”. Hat man genug Pakete eingefangen stoppt man hier das Mitschneiden. Ethereal baut nun eine Liste der Pakete auf und stellt sie wie oben beschrieben zur weiteren Betrachtung dar. Auch ethereal erlaubt wie tcpdump das Laden und Speichern von Mitschnitten. Das geht ganz einfach u u. ¨ ber das File-Men¨ Auch hier hat man vielleicht irgendwann soviele Daten mitgeschnitten, dass man mit einfachem Umsortieren nicht mehr weiterkommt. Es lassen sich dazu Filter angeben, die man entweder direkt in das Eingabefeld unterhalb der Men¨ uzeile einf¨ uttert oder den Assistenten ”Expression” neben dem Feld erstellen läßt. Letzterer erlaubt einem sehr einfach Filter zu bauen. Dabei kann man dann fast nichts mehr falsch machen. Das Filtern auf eine MAC-Quelladresse sieht dann beispielsweise so aus: ”eth.src == 00:10:A4:8D:56:0A”. Will man auf IP Pakete filtern, die keine TCP-Payload haben, erreicht man das mit: ”ip.proto != 6”. Will man alle DNS-Antworten sehen, gebe man als Filter: ”dns.flags.response == 1” an. Grenzen gibt es praktisch keine. Wenn ein Filter nichts matcht, sind nach dem Druck auf den Button ”Apply” die unteren Fensterteile leer. Andernfalls finden sich dort alle Pakete auf den der Filter passte. Sagte einem der Filter nicht zu, löscht man ihn mit ”Clear” und schon sieht man wieder den urspr¨ unglichen Mitschnitt. Um wirklich zu rea-

Abbildung 16.2: TCP-Sessions lassen sich einfach verfolgen, daf¨ ur muss nur ein Paket der interessierenden Verbindung markiert werden

16.6. SAMMELN IM HINTERGRUND - TRAFMOND

233

lisieren, wie einfach ein Netzwerkmitschnitt und dessen Analyse ist, starte man auf einer Maschine eigener Wahl den Telnet-Dienst. Dieser muss meist erst noch nachinstalliert und dann aktiviert werden. Keine aktuelle Distribution bindet ihn standardmäßig mehr ein Telnet ist der sicherheitsm¨ aßige S¨ undenfall schlechthin. Wem das Beispiel sinnlos erscheint, schneide einfach mal die Anmelde-Prozedur an einen GMX-Account per Webinterface mit. Die Datenmenge ist h¨ oher, da ja die ganzen Banner noch geladen werden m¨ ussen, aber das Passwort ist dann leicht zu finden. Man klicke einfach auf ein Paket welches zur Sitzung gehört und gehe anschliessend in das Men¨ u ”Analyze - Follow TCP Stream”. Man sieht einen Mitschnitt in dem die Senderichtung in roter und die Empfangsrichtung in blauer Schrift dargestellt ist. In Frage kommen alle Protokolle, die Passw¨ orter unverschl¨ usselt austauschen. Dass auch noch der Inhalt der Sitzung so einfach nachvollzogen werden kann, ist eine andere Sache - die Dienste auf dem Weg werden es einem danken. Damit sind die Möglichkeiten von Ethereal längst

Abbildung 16.3: Die Analyse des Datenstroms offenbahrt Passwort und Sitzungsdaten nicht erschöpft. Der Admin kann sich u u diverse Statistiken zu den ¨ber das gleichnamige Men¨ eingefangenen Daten generieren lassen, die verschiedenen Kommunikationen zur besseren Identifikation bunt einf¨ arben und vieles andere mehr.

16.6

Sammeln im Hintergrund - trafmond

Während sich beispielsweie icmpmon lediglich mit dem gleichnamigen Protokoll beschäftigte, beobachtet der trafmond den Netzwerkverkehr (dauerhaft) im Hintergrund. Bei einigen Distributionen ist Trafmon schon mit einem Runlevel-Skript vertreten und kann gleich beim Start eines Rechners mit hochgefahren werden. Der im Hintergrund laufende trafmond sammelt still und leise seine Daten und hinterlegt sie in einer Bin¨ ardatei /var/log/trafmon platzsparend ab. Diese Datei läßt sich mit

234


dem Kommandozeilenwerkzeug trafmon auswerten. Die Zahl der ”v” bestimmt wiederum die Menge der Ausgaben: hermes:~ # trafmon -vv 20040423 10:21:31/00h00m04s 10.8.4.220:4303 -> login2.uni-goettingen.de:ssh 1518 63K 20040423 10:22:40/00h00m48s 10.8.4.220:4304 -> login2.uni-goettingen.de:ssh 2638 1680K 20040423 12:03:58/00h00m02s 10.8.4.220:gsi -> stud9.stud.uni-goettingen.de:http 5 952 20040423 12:04:19/00h00m00s 10.8.4.220:jdl-dbkitchen -> www.Goettingen.DE:http 5 954 20040423 12:05:06/00h01m02s 10.8.4.220:2182 -> rz.uni-freiburg.de:smtp 0 69 20040423 12:37:37/00h00m04s 10.8.4.220:iiw-port -> mail.uni-math.gwdg.de:cvspserver 897 2350

Trafmon ist daf¨ ur da dauerhaft bei geringem Footprint im System zu laufen und nicht nur f¨ ur Einzelanalysen ad-hoc gestartet zu werden. Die Menge der gesammelten Informationen ist kleiner, als bei den zuvor beschriebenen (Mammut-)Werkzeugen tcpdump oder ethereal.

16.7

Wegeanalysen in IP-Netzwerken

Das Internet Protokoll wurde daf¨ ur geschaffen, u ¨ ber verschiedenste reale und virtuelle Netzwerke Verbindungen herzustellen. Dabei spielt es f¨ ur IP keine Rolle, ob die Daten u ¨ ber schnelle Glasfaserleitungen auf dem Grund eines Ozeans laufen, per GPRS oder WLAN durch die Luft vermittelt werden oder auf unterschiedlichsten Arten von Kupferkabeln zu ihren Endpunkten oder Vermittlungsstellen zu gelangen. F¨ ur den Benutzer hat es den Vorteil, dass er eine Webseite aus den Staaten u ¨ ber das gleiche Netzwerkprotokoll erhält, wie seine Email von seinem Provider um die Ecke. Jedoch hängt das Verhalten einer Netzwerkapplikation stark davon ab, wie schnell und mit welchen Bandbreiten die Daten u ¨ ber eine gewisse Teilstrecke gelangen. Geht man per GPRS ins Netz spielt es keine Rolle, ob der angesprochene Webserver per Gigabit-Glasfaser an den Rest der Welt angeschlossen ist. Stattdessen kann man sich auf niedrige Bandbreiten bei hohen Verz¨ ogerungen einstellen. So kann es Ihnen auch umgekehrt passieren, dass man hinter einem schwach ausgelasteten DSL-Anschluss sitzt aber die FTPSitzung trotzdem nicht in Schwung kommt. Um festzustellen, was auf der Strecke so passiert, welche Verzögerungen und Paketverluste auftreten, stehen Ihnen eine Reihe von Programmen zur Verf¨ ugung. Dieser Artikel ¨ gibt einen Uberblick dar¨ uber, wie sie als interessierter Linux-Nutzer oder Administrator sich Informationen zu ihrer n¨ aheren und weiteren Netzwerkumgebung verschaffen.

16.7.1

Routenverfolgung

Ein klassisches Kommandozeilen-Tool, welches eigentlich immer zur Grundausstattung einer Maschine geh¨ ort ist traceroute. Dieses Programm ist dem Kommando ping eng verwandt, da es ¨ ahnliche Informationen sammelt und ICMP benutzt. Es benötigt keine RootRechte zur Aus¨ uhrung, liegt aber f¨ ur Normalbenutzer meistens nicht im Suchpfad der Shell (/usr/sbin). traceroute zeichnet den Weg eines Paketes entlang seiner Route zum Ziel auf und stellt die Ergebnisse in einer Liste dar. Hierf¨ ur setzt traceroute lediglich ein funktionierendes UDP-Modul am Ziel voraus - eine besondere Applikation auf der Gegenseite

16.7. WEGEANALYSEN IN IP-NETZWERKEN

235

benötigt es nicht. Wichtig ist jedoch, dass ICMP am Ziel nicht durch eine Firewall blockiert wird. traceroute nutzt f¨ ur das Ermitteln der Route das TTL-Feld des IP-Headers. Der Absender initialisiert das TTL-Feld mit ”1” und schickt das erste Paket ab. Passiert ein IP-Paket einen Router, z¨ ahlt dieser das TTL-Feld um eines herunter. Erreicht das Feld den Wert Null, verwirft der Router das Paket und schickt eine TTL-Exceeded an den Absender. So erfährt traceroute vom ersten Router. Anschliessend erhöht es das Feld um eins und schickt das nächste Paket. Die Aktion wird solange wiederholt, bis das Ziel erreicht ist. s02:~ # traceroute www.spiegel.de traceroute to www.spiegel.de (195.71.11.67), 30 hops max, 40 byte packets 1 10.1.1.11 4.753 ms 5.273 ms 6.134 ms 2 132.230.120.142 4.799 ms 6.439 ms 6.149 ms 3 nsc-rz-gwn.fun.uni-freiburg.de (132.230.0.141) 8.592 ms 5.977 ms 5.611 ms 4 Freiburg1.belwue.de (129.143.15.141) 6.563 ms 12.260 ms 15.243 ms 5 Stuttgart1.belwue.de (129.143.1.7) 16.740 ms 20.804 ms 15.209 ms 6 Frankfurt1.belwue.de (129.143.1.26) 22.202 ms 23.175 ms 24.137 ms 7 129.143.200.42 23.237 ms 26.502 ms 25.844 ms 8 rmws-frnk-de07-gigaet-0-0.nw.mediaways.net (213.20.255.4) 30.913 ms 30.517 ms 30.180 ms 9 rmwc-frnk-de01-pos-1-2.nw.mediaways.net (213.20.249.201) 30.205 ms 29.389 ms 30.864 ms 10 rmwc-gtso-de01-pos-1-0.nw.mediaways.net (195.71.254.121) 27.959 ms 31.603 ms 23.201 ms 11 217.188.58.204 24.364 ms 24.707 ms 23.578 ms 12 195.71.11.67 22.980 ms 23.742 ms 23.209 ms

Traceroute ohne die Option ”-n” aufgerufen versucht jede IP-Adresse in einen Hostnamen aufzulösen. Sie steht dann in Klammern hinter dem Namen. Gelingt keine Auflösung gibt es nur die IP an. Traceroute nummeriert die einzelnen Zwischenstationen durch und gibt hinter jeder drei Paketlaufzeiten an. Diese können deshalb variieren. Kam ein Paket abhanden, druckt traceroute ein Stern ”*”. Antwortet ein Router gar nicht, druckt es drei Sterne und springt zum n¨ achsten. Befindet sich das Ziel irgendwo in einem gesch¨ utzten Netz, sind die Aussagen zu den letzten Hops mit Vorsicht zu geniessen. Gibt es ein ”N!” aus, dann tauchte der Router zum erneuten Mal in der Liste auf. Das kann auf ein Routingproblem oder eine Firewall hinweisen. Eigentlich sollten die Paketlaufzeiten von Hop zu Hop ansteigen. Da aber Router viel besch¨ aftigte Systeme sind und f¨ ur die eigene Paketeverarbeitung länger brauchen k¨ onnen als f¨ ur das Durchleiten kommen bei sehr schnellen Netzen Zeiten zustande, die nicht in einer aufsteigenden Reihenfolge liegen m¨ ussen. Eine komfortable Erweiterung von traceroute ist mtr (My traceroute). Es gehört meistens nicht zum Standardinstallation, so dass man es bei Bedarf nachinstallien muss. Dieses Programm schickt nicht nur drei Pakete in Folge an eine Zwischenstation, sondern wiederholt diesen Vorgang bis es abgebrochen wird. Die Tabelle zeigt in der Grundeinstellung in der ersten Spalte den Host, in der zweiten den Paketverlust f¨ ur jede Zwischenstation und daneben die Zahl der gesendeten Pakete. F¨ ur diese einzelnen Pings wird der letzte Wert, der Durchschnitt, die beste und die schlechteste Zeit aufgef¨ uhrt. Man kann durch wiederholtes Dr¨ ucken von ”d” den Anzeigemodus interaktiv ¨ andern. Mit ”o” wählt man weitere Werte zur Darstellung in der Tabelle aus. s02 (0.0.0.0)(tos=0x0 psize=64 bitpattern=Tue Sep 29 16:02:26 2005 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 132.230.9.254 0.0% 16 0.6 0.7 0.5 1.5 0.2 2. nsc-rz-gwn.fun.uni-fre 0.0% 16 3.2 1.5 0.3 4.1 1.2 3. Freiburg1.belwue.de 0.0% 15 1.1 2.0 0.4 6.4 1.9

236


Abbildung 16.4: Hier sieht man ganz deutlich, wie beim dritten Router sehr viele Pakete verloren gehen 4. 5. 6. 7. 8. 9. 10. 11. 12.

Stuttgart1.belwue.de Stuttgart2.belwue.de ar-stuttgart4-ge3-2.gcr-stuttgart1-ge5-0.gcr-frankfurt1-po3-0.gcr-hannover1-po3-1.g-w ar-goettingen1-po0-0.g 188.1.46.202 stud9.stud.uni-goettin

0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

15 15 15 15 15 15 15 15 15

5.2 5.1 5.1 4.7 26.2 13.7 16.6 15.6 16.0

6.4 8.6 12.1 11.8 14.6 13.8 15.7 16.2 15.7

4.6 4.6 4.4 4.6 7.7 13.0 14.7 14.9 15.1

12.1 21.2 26.6 44.8 47.7 15.8 17.5 23.8 16.7

2.3 4.8 8.7 11.6 12.0 0.7 0.8 2.2 0.5

Von mtr gibts auch eine grafische Ausgabe. Diese muss jedoch oft separat installieren werden. Gestartet wird das Programm dann durch die Eingabe von xmtr.

16.8

Statistiken

Es gibt eine Reihe von Informationen, die sich mit Ethereal zwar beschaffen lassen, wo die ¨ Darstellung jedoch nicht optimal ist. Geht es um den generellen Real-Time-Uberblick, ist f¨ ur einige Fragestellungen der Paket- und Port-Statistiksammler iptraf eine gute Wahl. Dieses Programm recht m¨ achtig. Es gibt auch kleinere Geschwister, die nicht ganz so viel Funktionsumfang mitbringen: trafshow und netwatch.

16.8.1

iptraf

Das Programm ist ncurses-basiert, also in einer normalen Shell lokal oder remote benutzbar. Eine grafische Oberfl¨ ache ist daf¨ ur nicht erforderlich. Das Tool gehört u ¨blicherweise nicht zum Standardinstallationsumfang, so dass ein Admin es meist erst installieren muss. Beim Start des Programms erscheint eine kurze Begr¨ ussungsmeldung, weiter gehts zum Hauptmenu mit einer beliebigen Taste. Dort lässt sich zwischen den folgenden Funktionen auswählen: • Der ”IP traffic monitor” verf¨ ugt u ¨ber ein zweigeteiltes Interface. Im oberen zeigt IPTraf bestehenden TCP-Verbindungen mit ihren Endpunkten und deren Status an. Im

16.8. STATISTIKEN

237

Abbildung 16.5: Das Hauptmen¨ u von iptraf unteren Drittel l¨ auft der Non-TCP-Traffic, also in erster Linie UDP, ICMP und ARP durch. Unter dem Menupunkt ”General interface statistics” listet IPTraf f¨ ur jedes

Abbildung 16.6: Das IP Traffic Monitor mit dem zweigeteilten Interface Interface die Zahl der ein- und ausgegangenen (Non-)IP-Pakete und die Datenrate f¨ ur jedes Interface auf. • ”Detailed interface statistics” liefert Informationen zu einem vor ausgewählten Interface. Es z¨ ahlt ein und ausgehende Pakete und Bytes. Zusätzlich listet es die Datenraten f¨ ur ankommende und abgehende Datenströme und die Gesamtrate auf. Dieses Interface zeigt beispielsweise sehr gut, ob und wie eine DSL-Leitung ausgelastet ist. Hier ist die Unterscheidung zwischen ankommenden und abgehenden Paketen besonders interessant, da der Upstream deutlich kleiner als der Downstream ist. So kann man beispielsweise feststellen, ob der Download wegen verstopften Upload-Kanals mager ausfällt. Zur Optimierung von Traffic-Shaping bietet sich ebenfalls der Blick in dieses

238

KAPITEL 16. NETZWERKANALYSE Interface an. • Die ”Statistical breakdowns...” bieten Informationen, die sich mit anderen Tools eher schlecht beschaffen lassen. Die Zusammenfassungen nach der Paketgröße zeigt, in 75 Byte Schritten, in welche Kategorie u ¨ bertragene Pakete fallen. Viele recht kleine Pakete lassen auf andere Applikationen schliessen als viele große. Ersteres deutet auf die Nutzung von Voice-over-IP hin, letzteres eher auf große Downloads via HTTP oder ¨ FTP. Ebenso sind Uberblicksstatistiken f¨ ur TCP und UDP abfragbar: Nach Protokoll und Port sortiert baut IPTraf Listen auf und schl¨ usselt dabei wieder ankommendem und abgehendem Datenverkehr auf. • Der ”LAN station monitor” beobachtet Ereignisse auf dem Layer unterhalb der IPEbene2 . Hier z¨ ahlt IPTraf Pakete anhand ihrer MAC-Adresse und schl¨ usselt die Ergebnisse nach ankommenden und abgehenden IP- und generellen Paketen und Bytes auf. • Im Konfigurationsmen¨ u lassen sich eine ganze Reihe Parameter einstellen, wie die umgekehrte DNS-Aufl¨ osung, Farben, Timer, Port-Ranges und etliches mehr.

16.8.2

TrafShow und NetWatch

Mit etwas weniger Funktionsvielfalt wartet trafshow auf. Es zeigt nach dem Start im Konsolenfenster bestehende IP-Verbindungen und die Zahl der darin gesendeten Pakete an. Am unteren Fensterrand stellt es eine Statistik aus der insgesamt seit Start u ¨bertragenen Paketmenge, der Zahl der Pakete pro Sekunde und der Zahl der Bytes pro Sekunde auf. Das Programm kann u ¨ber Kommandozeilenoptionen gesteuert werden: So verhindert das vielfach bekannte ”-n” eine Aufl¨ osung in Rechnernamen und die Darstellung der Quellund Zieladressen erfolgt als numerische IP-Adresse. Als letztes Argument kann beim Aufruf optional ein Ausdruck angegeben werden, der zum Filtern auf bestimmte Pakettypen analog zu tcpdump funktioniert. Gestartet mit der Option ”-e” gibt trafshow den EthernetVerkehr aus. Mit trafshow -i wlan0 legt der Administrator fest, dass das Programm die Schnittstelle wlan0 u ¨berwachen soll. Weitere Informationen enthält die Manpage. Ebenfalls in die Sparte der ncurses-basierten Programme fällt netwatch. Anders als iptraf oder trafshow w¨ ahlt NetWatch eine andere Bildschirmaufteilung. Links werden die Verbindungen im LAN und rechts die entfernten aufgelistet. Mit den Links- und RechtsCursortasten kann die Art der Anzeige verändert werden: Zählen der ein und ausgehenden Pakete, empfangene und gesendete Bytes oder Art der Verbindung. Mit der Option ”-e eth1” legt man fest, dass NetWatch auf dem zweiten Ethernet-Interface lauscht, ”-n” unterdr¨ uckt die Auflösung von IP-Adressen in DNS-Namen. Zur Unterscheidung von LAN- und entferntem Datenverkehr kann mit ”-i IP” eine bestimmte lokale IP und mit ”-m Netmask” eine lokale Netzmaske f¨ ur die geeignete Auswahl des Traffics festgelegt werden: netwatch -i 10.1.2.3 -m 255.192.0.0 sieht alle Pakete im Netz von 10.0.0.0 bis 10.63.255.255 als lokal und alle anderen als remote an.

16.8.3

Analysen webbasiert - ntop

Mit ntop gibt es ein weiteres Werkzeug, um Netzwerkschnittstellen bis ins Detail zu u ¨ berwachen und den Datenverkehr auszuwerten. Es ist bei den meisten Distributionen als Paket verf¨ ugbar, muss aber wie viele der anderen hier vorgestellten Tools extra installiert werden. 2

Dieses kann der Data Link Layer bei Ethernet-Verbindungen sein aber auch PPP bei PPPoEVerbindungen

16.8. STATISTIKEN

239

s02:~ # ntop -A -u wwwrun Tue Apr 12 22:46:30 2005 Initializing gdbm databases Please enter the password for the admin user: Tue Apr 12 22:46:59 2005 Admin user password has been set s02:~ # Tue Apr Tue Apr Tue Apr Tue Apr Dec Tue Apr Tue Apr Tue Apr Tue Apr Tue Apr Tue Apr Tue Apr Tue Apr Tue Apr [ ... ]

ntop 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 11 2004 20:07:17. 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:04 2005 19 10:21:05 2005

Initializing gdbm databases ntop will be started as user nobody ntop v.3.0.053 MT (SSL) Configured on Dec 11 2004 20:05:20, built on \ Copyright 1998-2004 by Luca Deri Get the freshest ntop from http://www.ntop.org/ Initializing ntop No default device configured. Using eth0 Checking eth0 for additional devices Resetting traffic statistics for device eth0 DLT: Device 0 [eth0] is 1, mtu 1514, header 14 Initializing gdbm databases VENDOR: Loading MAC address table.

Einmal das Passwort festgelegt und anschliessend gestartet, stellt ntop u ¨ber Port 3000 als Web-Service etliche statistische Daten zur Verf¨ ugung. Als Grundlage beobachtet das Programm den Datenverkehr und wertet ihn f¨ ur die Statistik aus. Der Zugriff auf das Interface steht erst einmal offen, da ntop defaultmäßig auf allen Interfaces startet. Nur bestimmte Bereiche, wie das Filtern, Abschalten oder der Statistik-Reset sind dem ”admin” vorbehalten, dessen Passwort man eingangs gesetzt hat. Das Programm braucht zum Betrieb einiges an Speicher, sehr knapp dimensionierte Systeme können hier Probleme bekommen. Das Verhalten und die F¨ ahigkeiten von ntop kann man u ¨ber die Kommandozeile beim Aufruf des Daemons steuern. Hierzu gibt die ausf¨ uhrliche Manpage Auskunft. Die Informationen, die ntop sammelt unterscheiden sich nicht stark von den bereits vorgestellten Programmen. Es geht wieder um bestehende Verbindungen, generierten ausgehenden und ankommenden Traffic, Rechner mit ihren Hostnamen, IP- und MAC-Adressen. Einzelne Aspekte, wie die Aufschl¨ usselung der Pakete nach der Größe der TTL im Bereich ”Traffic” kennt man vielleicht noch nicht. Der wesentliche Vorteil liegt in der vom Linux-Router v¨ ollig unabh¨ angigen Darstellung auf jedem Webbrowser. So ist eine grafische Aufbereitung der Information auch ohne X11 problemlos möglich.

16.8.4

Top fu ¨rs Netzwerk

Das Programm iftop orientiert sich an dem f¨ ur Prozesse bekannten top. Es arbeitet in der Konsole und besitzt einen zweigeteilten Aufbau: Im oberen Bildteil listet iftop die bestehenden Netzwerkverbindungen und deren u ¨ber kurze Zeit gemittelten ankommenden und abgehenden Datenverkehr auf. Am oberen Bildrand stellt das Netzwerk-Top ein Skala mit Kilobit-Aufteilung dar. Diese dient dazu f¨ ur jede Verbindung durch schwarze Balken, die von links aus wachsen, den aktuellen Traffic symbolisch darzustellen. Im unteren Fensterteil gibt IfTop eine Zusammenfassung u ¨ ber alle bestehenden Verbindungen an.

240


Abbildung 16.7: Top f¨ ur die Netzwerkauslastung, Anzeige durch die Länge der schwarzen Balken

16.8.5

MRTG

¨ Das Programm Multi Router Traffic Grapher (MRTG) dient zur Uberwachung der Auslastung von Netzwerkinterfaces. MRTG setzt ein Perl-Skript ein, mittels Simple Network Management Protocol (SNMP) den Durchsatz einzelner Netzwerkschnittstellen zu ermitteln. Es erzeugt mit einem kleinen C-Programm HTML-Seiten, welche die Auslastungsgrafen der u ¨berwachten Interfaces im PNG-Format zusammenfassen. Die Grafen bleiben nicht statisch, sondern werden bei jedem Durchlauf von MRTG fortlaufend erzeugt. F¨ ur längerfristige Analysen erzeugt MRTG Grafen, die den Datenduchsatz der letzten Woche, des letzten Monats und des letzten Jahres wiedergeben. MRTG schreibt hierf¨ ur eine spezielle Log-Datei, welches es sukzessive konsolidiert. Damit wächst die Datei nicht unaufhörlich und trotzdem sind alle erforderlichen Daten enthalten, um auch langzeit Sta¨ tistiken erstellen zu k¨ onnen. Die Einrichtung von MRTG erfordert etwas Uberlegung und höheren Aufwand als f¨ ur die meisten bisher gezeigten Tools. Als erstes muss man eine Konfigurationsdatei erstellen. In dieser Datei sind nicht nur die Pfade zur Datenablage enthalten, sondern auch das grunds¨ atzliche Layout der später generierten Webseiten. Hier besteht die Chance einige Anpassungen vorzunehmen. Die Datensammelei geschieht durch SNMP - deshalb muss MRTG wissen, wie es an die Daten herankommt. Man kann damit jeden beliebigen Router oder Switch u ¨ berwachen, die SNMP sprechen. Hierzu gibt man die Interfaces an, f¨ ur die MRTG Statistiken schreiben soll und den SNMP-Community-String f¨ ur das jeweilige Ger¨ at. Die Ger¨ ate lassen sich u ¨ ber ihre IP oder den Rechnernamen ansprechen. Eine recht einfache Konfiguration erzeugt das mitgelieferte Tool cfgmaker durch den folgenden Aufruf: cfgmaker --interfaces eth0 ppp0 public@localhost > /etc/mrtg.conf Anschliessend sollte man noch einen Blick in die Konfiguration werfen und mindestens den Pfad f¨ ur die Ablage der Webseiten anpassen. Zugreifen kann man auf der Maschine selbst nat¨ urlich an einem Webserver vorbei, in dem man einfach das Verzeichnis und die

16.8. STATISTIKEN

241

Abbildung 16.8: Langzeitdaten sammeln mit MRTG HTML-Dateien im Browser direkt aufruft. Sollen die Statistiken auch remote zugänglich sein, kommt der Admin am Betrieb eines Webservers nicht vorbei. MRTG stellt anders als ntop kein eigenes Webinterface zur Verf¨ ugung. Es muss daf¨ ur auch nicht permanent laufen. F¨ ur den Einsatz von MRTG muss der SNMP-Service auf Ihrer Maschine gestartet sein, sowohl f¨ ur den Konfigurationsvorgang als auch den späteren regelmäßigen Lauf von MRTG selbst. Zum Testen kann man mrtg auf der Kommandozeile aufrufen. Als Argument nimmt es die zu verwendende Konfigurationsdatei.

hermes:~ # env LANG=C mrtg /etc/mrtg.conf

Da das Tool mit UTF8 nicht klarkommt, sollte die Language-Environment-Variable beim Start entsprechend modifiziert sein. Ging alles glatt, kann ein Admin mrtg per Cron regelmäßig, beispielsweise alle f¨ unf Minuten, Daten sammeln schicken. Ist die Zahl der u ¨ berwachten Interfaces sehr hoch, sind längere Intervalle sicherlich sinnvoll.

242

16.8.6


Bandbreiten messen

Die eine Seite ist die Beobachtung der Auslasung von Netzwerkstrecken und Interfaces. Man kann nat¨ urlich auch aktiv an die Sache herangehen und schauen, was eine gegebene Strecke potenziell leisten kann. Die Programme iftop oder iptraf konnten Aussagen zur gerade realisierten Bandbreite auf einem bestimmten Interface machen. Nun ist es aber vielleicht etwas lästig erst einen FTP-Server zu installieren oder scp dazu zu verwenden, um die Bandbreite einer Verbindung zu messen. In diese Nische springt das Werkzeug bing. Die Namensabwandlung von ping leugnet die Verwandschaft nicht. W¨ arend ping sich um die Erreichbarkeit k¨ ummert und Paketlaufzeiten mißt, ist bing f¨ ur die Ermittlung der realisierbaren Bandbreite eines Links zuständig. Bing nutzt dazu zwei verschiedene Paketgrößen, um ein etwas realitätsnäheres Ergebnis zu bekommen. s02:~ # bing -e 8 -S 1450 -s 100 10.8.3.254 10.8.3.220 BING 10.8.3.254 (10.8.3.254) and 10.8.3.220 (10.8.3.220) 100 and 1450 data bytes 21600 bits in 0.320ms: 67500000bps, 0.000015ms per bit 21600 bits in 0.358ms: 54271357bps, 0.000018ms per bit 21600 bits in 0.399ms: 53992084bps, 0.000019ms per bit 21600 bits in 0.419ms: 50811736bps, 0.000019ms per bit 21600 bits in 0.436ms: 49541284bps, 0.000020ms per bit --- 10.8.3.254 statistics --bytes out in dup loss 100 8 8 0% 1450 8 8 0%

rtt (ms): min 0.069 0.050

avg 0.114 0.054

max 0.389 0.075

--- 10.8.3.220 statistics --bytes out in dup loss 100 8 8 0% 1450 8 8 0%

rtt (ms): min 0.293 0.729

avg 0.460 0.764

max 0.617 0.819

--- estimated link characteristics --warning: rtt big host1 0.050ms < rtt small host2 0.069ms estimated throughput 49601284bps minimum delay per packet 0.193ms (9504 bits) average statistics (experimental) : packet loss: small 0%, big 0%, total 0% warning: rtt big host1 0.054ms < rtt small host2 0.114ms average throughput 71052632bps average delay per packet 0.312ms (14517 bits) weighted average throughput 71043532bps resetting after 8 samples.

Im Beispiel sorgte die Option ”-s 8” dazu, dass acht Testläufe durchgezogen wurden. Mit ”-s 100” setzt man die kleinen Testpakete auf 100 Byte fest, mit ”-S 1450” die großen auf 1450 Byte. Im Beispiel errechnete bing f¨ ur eine 100 Mbit-Verbindung ohne starke Belastung zwischen einer 2 GHz P4 und einer 600 MHz PIII Maschine eine Bandbreite von geschätzten 70 Mbit.Mehrere Aufrufe erbringen durchaus verschiedene Ergebnisse. Dabei muss die Maschine auf der bing gestartet wird nicht einer der beiden Testendpunkte sein. F¨ ur eine 802.11b WLAN-Strecke wurden im Beispiel 3,7 Mbit gemessen. Somit stimmen zumindest die Größenordnungen u ¨berein. Bing ist von einer ganzen Reihe von Faktoren abhängig. Die

16.9. AUFGABEN

243

Hardware des Rechners und der Ethernetkarte spielen ebenso wie Treiberg¨ ute und Maschinenbelastung ins Ergebnis hinein.

16.9

Aufgaben

16.9.1

Erreichbarkeit

1. Man organisiere sich die IP vom Nachbarn und versuche diesen per Ping zu erreichen. Wie erf¨ ahrt man seine eigene Default-Gateway-Adresse? 2. Wie kann man die Erreichbarkeit von Maschinen im Netz u urfen? ¨berp¨ 3. Welche M¨ oglichkeiten hat man, wenn ICMP von Firewalls blockiert wird? 4. Welche Rolle spielt ICMP bei der Benutzung von traceroute, ping, nmap? Was wird dabei ausgenutzt? 5. Wozu dient das IP-Header-Feld TTL? Welcher Unterschied besteht beim Anpingen des eigenen Default-Gateways und einer Adresse wie www.google.de oder goe.net? 6. Welche Informationen lassen sich mittels nmap u ¨ber eine Maschine beschaffen? 7. Wie funktioniert der FTP-Bounce-Scan? Wann wendet man diesen an? 8. Warum gelingt es nmap (und mit welcher Option?) mit einer guten Trefferquote herauszubekommen, welches Betriebssystem auf einer bestimmten Maschine oder einem Netzwerkger¨ at l¨ auft? 9. Woran kann man alles erkennen, dass eine Maschine hinter einer NAT-Firewall sitzt? Wie kann man herausbekommen, wieviele aktive Rechner sich hinter einer NATFirewall angeschlossen sind?

16.9.2

Paketanalyse

1. Man starte das Kommandozeilenprogamm tcpdump. Wie kann man die Analyse auf ein bestimmtes Interface, eine bestimmte Quell-IP oder einen festgelegten Ziel-Port beschränken? 2. F¨ ur die grafische Oberfl¨ ache, deutlich bunter und leichter zu bedienen ist das Programm ethereal. Man finde heraus, von welchem Typ die ICMP-Meldungen sind, die durch ping generiert werden! 3. Wie kann man beispielsweise den gesamten ARP-Verkehr aus der Analyse im Ethereal herausfiltern?

16.9.3

Datenverkehr z¨ ahlen

1. Welche ganz einfachen M¨ oglichkeiten hat man, um festzustellen, wieviel Datenverkehr von einer Maschine ins Netz geschickt oder empfangen wurde? 2. Wie w¨ urde man eine detaillierte Statistik auf einer Linux-Maschine erhalten, die NATRouter f¨ ur zehn weitere Maschinen spielt?

244


Kapitel 17

Samba 17.1

Samba - Bru ¨ cke zwischen Microsoft- und Unix-Welt

F¨ ur viele geh¨ oren 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¨ ucken zwischen der Linux/Unix und Windowswelt. Dieses beginnt bei einfachen Verzeichnis- und Druckerfreigaben und l¨ aßt sich fortsetzen bis zu Single-Password- oder Single-Sign-OnLösungen und komplexen Domaincontroller-Aufgaben, die ein Linux-Rechner u ¨ bernehmen kann. ”Samba” steht f¨ ur die freie Implementierung eines Server Message Block Protokollservers. Samba spricht sich einfach besser aus und klingt netter als die Abk¨ urzung des Protokollnamens ”SMB”. Microsoft-Rechner benutzen dieses Protokoll untereinander, um auf Dateien und Drucker u ¨ ber ein Netzwerk zuzugreifen. In dieses Netzwerk können sich auch Linux oder Unixrechner dank Samba einklinken. Sie k¨ onnen dabei dank Samba als Client agieren oder auch tragendere Rollen u ¨ 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¨ ugung. Jeder kann ihn anpassen, untersuchen und testen. F¨ ur Administratoren in Firmen und Organisationen das Wichtigste: Samba ist frei. Anders als f¨ ur jede Microsoft Installation fallen f¨ ur das Aufsetzen eines Samba-Servers oder die Benutzung der Samba-Dienste unter Linux keinerlei Lizenzgeb¨ uhren an.

17.1.1

Einsatzgebiete von Samba

SMB beschränkt sich nicht auf die Funktion als Netzwerkdateisystem oder Remote-Printer. Allein schon f¨ ur diese beiden Aufgaben gibt es in der Unixwelt zwei verschiedene Dienste: Beispielsweise LPD f¨ ur Drucker und NFS f¨ ur Netzwerkdateisysteme. SMB kann eine ganze Menge mehr: • Das Samba-Paket enth¨ alt 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¨ ugung, die von anderen Programmen genutzt werden kann, bsp. dem KDE-Konqueror. F¨ ur die Kommandozeile liefert Samba die Tools smbmount, smbclient und mount.cifs mit. • Samba realisiert einige Erweiterungen des SMB-Dateisystems, damit bestimmte UnixDateien auf entfernten SMB-Freigaben abgelegt werden können. 245

246

KAPITEL 17. SAMBA • Samba kann die Aufgaben des Windows-Namens-Dienstes (WINS) u ¨bernehmen: Als NetBIOS-Nameserver kann es Namen auf IP-Nummern und umgekehrt abbilden. Zusätzlich unterst¨ utzt 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¨ arer Dom¨ anen-Controller f¨ ur Windows-Clients eingesetzt werden. • Samba bringt Werkzeuge f¨ ur entfernte Administrationsaufgaben f¨ ur Windows-NTund Samba-Server mit.

17.2

Erste Versuche

Wenn Samba schon auf der Maschine installiert ist, kann der Anwender schonmal erste Schritte wagen. Wenn nicht, u ummert sich ersteinmal ¨berspringt er diesen Abschnitt und k¨ um die Installation. Samba funktioniert in ”beide Richtungen”: Es stellt Client- und Serverfunktionalität bereit. F¨ ur 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 17.1: Freigeben eines Verzeichnisses unter WindowsXP und Setzen der Zugriffsrechte

17.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¨ unden unter Linux nur vom Benutzer ”root” ausgef¨ uhrt werden. Jedoch gibt es auch M¨ oglichkeiten dieses normalen Usern zu erlauben. In der Standardinstallation liefert smbmount bei unpriveligiertem Aufruf die Fehlermeldung smbmnt must be installed suid root for direct user mounts (500,500). Dem kann man unter

17.2. ERSTE VERSUCHE

247

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 ”SharedFiles” an das Unterverzeichnis win. Die Verbindung erfolgt mit der Windows-UserID ”dirk”, das Passwort fragt smbmount dann interaktiv ab. Anschliessend gibt das Kommando mount das eingebundene Verzeichnis in seiner Liste mit an: dirk@linux:~> mount /dev/hdb2 on / type ext3 (rw) proc on /proc type proc (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hdc2 on /home type ext3 (rw) //10.8.4.204/SharedFiles on /home/dirk/win type smbfs (0)

Der Inhalt des Verzeichnisses win sind die Dateien, die sich auf der Windows-Maschine im freigegebenen Ordner befinden. Es gibt jedoch einige Einschränkungen: Dateien und Ordner kann der Nutzer wie gewohnt anlegen. Die Dateien gehören immer ihm, das UnixRechtemuster wird nur zum Teil abgebildet. Nicht möglich sind spezielle Dateien, wie Links, Sockets oder Named Pipes. Der Vorteil von Samba: Anders als mit NFS oder Geräten muss kein passender Eintrag in der /etc/fstab stehen, um Benutzern das Einbinden von WindowsFreigaben zu erlauben. Umgekehrt wird der Nutzer das eingebundene ”Share” durch den Befehl smbumount wieder los: smbumount win meldet die Freigabe ab und die Liste des Mount-Kommandos reduziert sich um den entsprechenden Eintrag. F¨ ur diese kleinen Experimente ist es nicht notwendig, dass die beiden Samba-D¨ amonen 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¨ uckt sich auch im Mount-Kommando f¨ ur 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¨ aumt 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 FTPa ¨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

248

KAPITEL 17. SAMBA

IM01OLYM D 0 Mon Nov 17 16:37:14 Mail D 0 Mon Sep 26 18:07:45 OpenOffice.org1.1 D 0 Wed Oct 20 09:44:31 PDFs D 0 Mon Jan 10 19:06:34 PostScripts D 0 Wed Mar 31 13:41:28 Slides D 0 Fri Sep 10 14:28:28 artikel D 0 Wed Dec 22 14:48:45 [ ... Haufen weitere Dateien und Verzeichnisse ... ] 32784 blocks of size 262144. 8028 blocks available smb: \> smb: \> put einstieg.txt putting file einstieg.txt as \einstieg.txt (1488,4 kb/s) (average 1488,5 kb/s) smb: \> get ToDo

2003 2005 2004 2005 2004 2004 2004

Dieses Beispiel benutzt einen Standard-Fileserver auf Samba-Basis. Eine Die Verbindung zu einer Freigabe erfolgt in der bekannten Windows-Syntax: //Rechnername/Freigabe oder //IP-Adresse/Freigabe, wobei einfach die Backslashes in Slashes umgeändert werden. Erstere haben in der Shell eine besondere Bedeutung. Wenn die Verbindung unter einer vorgegebenen UserID erfolgen soll, kann der Anwender diese mit der Option -U mitteilen. Bei der Verbindungsaufnahme fragt dann smbclient nach dem Passwort. Eine Verbindung auf eine Windows-Maschine unterscheidet sich bis auf die Statuszeile nicht: dirk@linux02:~> smbclient -U dirk //10.20.90.60/SharedFiles Password: Domain=[MYLAPTOP] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] smb: \> quit

Nach erfolgter Verbindung liefert das Kommanod ls Dateien und Verzeichnisse in der Freigabe. Der Verzeichniswechsel erfolgt wie gewohnt mit cd. Mit put lassen sich Dateien auf das ”Share” hochladen, mit get welche in das lokale Verzeichnis kopieren, von wo aus smbclient gestartet wurde. Am Ende verlässt man die Samba-Shell mit quit.

17.2.2

Linux-Server - Windows-Client

Dieser Fall ist der in der Realit¨ at 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¨ unstige Alternativen gibt? Die Serverfunktionalität stellen zwei Hintergrundsdienste, die D¨ amonen smbd und nmbd bereit. Letzterer k¨ ummert 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 u ur ¨ blicherweise im Unterverzeichnis /etc/samba. F¨ einen ersten Test legt der Admin eine Minimalkonfiguration dieser Datei an oder ändert die Vorgabe der liefernden Distribution passend ab. F¨ ur 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

17.3. WEITERGEHENDE KONFIGURATION

249

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, u ist die Groß- oder ¨bereinstimmen. Im Ubrigen Kleinschreibung in der smb.conf mit Ausnahme der Pfadangaben unter Linux irrelevant. Die beiden Benutzer ”test1” und ”test2” m¨ ussen lediglich als System-Accounts existieren. User benötigen f¨ ur Samba nicht zwingend Linux-Loginrechte oder einen Eintrag in der /etc/shadow. Da Linux und Windows verschiedene Verschl¨ usselungsverfahren f¨ ur Passwörter benutzen, muss selbst bei Existenz eines g¨ ultigen 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 u ¨ 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¨ ur 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. 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¨ ugt der Admin server string = Kommentar mit seinem Kommentar in der [global] Sektion ein.

17.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¨ ugung gestellt. Soll eine Anmeldung f¨ ur diese Freigabe auch ohne Passwort möglich sein, kann der Admin das Schl¨ usselwort ”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 [2004/11/10 16:09:36, 5] lib/debug.c:debug_dump_status(369)

250

KAPITEL 17. SAMBA

Abbildung 17.2: Durch die direkte Eingabe der IP-Nummer umgeht der Anwender eventuelle Probleme bei der Windows-Namensauflösung 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 doing parameter valid users = test1 test2

17.3. WEITERGEHENDE KONFIGURATION

251

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¨ urfnis gen¨ ugt ein Loglevel von 0 bis 3 f¨ ur die wichtigsten Ereignisse. Meldungen u ¨ ber Fehler in der Konfigurationsdatei landen in jedem Fall hier. ¨ Eine weitere M¨ oglichkeit der Uberpr¨ ufung des Server-Zustandes bietet das Kommando smbstatus. Einfach aufgerufen liefert es eine Liste der aktuell g¨ ultigen 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

17.3.1

Homeverzeichnisse fu ¨r Windows und Linux

Sollen Benutzer ein gemeinsames Homeverzeichnis unter Linux und Windows benutzen, erlaubt dieses die spezielle Sektion [homes] in der Konfigurationsdatei /etc/samba/smb.conf: [homes] comment = Home Directories valid users = %S browseable = Yes read only = No create mask = 0640 directory mask = 0750

Möchte man einer Benutzergruppe das gemeinsame Zugriffsrecht auf eine Freigabe einräumen, muss diese vorher in /etc/group definiert sein. [gruppenfreigabe] comment = Beispiel einer Gruppenfreigabe read only = No browseable = No valid users = @testgroup force group = testgroup path = /gruppenfreigabe create mask = 0770 force create mode = 0770 directory mask = 0770 force directory mode = 0770

252

KAPITEL 17. SAMBA

In diesem Beispiel d¨ urfen alle Mitglieder der Gruppe ”testgroup” sich mit dem Share verbinden. Alle Dateien und Verzeichnisse werden so angelegt, dass nur Gruppenmitglieder sie andern d¨ urfen. Die Maske 0770 erzwingt Gruppenschreibrechte und verhindert gleichzeitig, ¨ dass Dateien nur vom Erzeuger selbst geändert werden d¨ urfen. Die Option browseable = No sorgt daf¨ ur, dass die Freigabe nicht in der Netzwerkumgebung auftaucht.

17.3.2

Druckerfreigaben

Bis zu diesem Punkt wurden verschiedene Arten der Verzeichnisfreigaben diskutiert. Das SMB-Protokoll erlaubt es aber auch, Drucker im Netz gemeinsam zu benutzen. Hierzu gibt es die Sektion [printers] in der /etc/samba/smb.conf. [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No writable = yes public = yes

Viele der Optionen sind nun schon von den anderen Beispielen bekannt. Die Pfadangabe dient nun nicht als Freigabe, sondern als Spoolverzeichnis. In diesem landen die abzuarbeitenden Jobs der berechtigten Benutzer. In den Globaleinstellungen der smb.conf sind zwei weitere Variablen zu definieren. Der Admin legt fest, welches Drucksystem Verwendung findet. Auf modernen Distributionen greift er u ¨blicherweise auf das Common Unix Printer System (CUPS) zur¨ uck: printing = CUPS printcap name = CUPS

Der Dienst CUPS muss vor Samba gestartet werden. Dieses u uft insserv beim Anlegen ¨berpr¨ 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¨ ugung.

17.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¨ utzlich sein. Damit auch ein LinuxClient Windows-Nachrichten empfangen kann, muss ein Samba laufen. Dieses wurde in der [global]-Sektion um den Eintrag message command = sh -c ‘/opt/kde3/bin/kpopup ’’%s’’ ’’%f’’‘ erweitert. Das Programm kpopup ist meistens ein eigenes Paket, welches unter Umst¨ anden nachinstalliert werden muss. Je nach Distribution können Pfad und Paketname variieren.

17.4

Die zentrale Samba-Konfigurationsdatei

In den bisherigen Abschnitten kamen schon Beispiele f¨ ur 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).

17.4. DIE ZENTRALE SAMBA-KONFIGURATIONSDATEI

17.4.1

253

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¨ ur sorgen, dass ihre Nutzer sowohl unter Linux als auch unter Windows auf das selbe Homeverzeichnis zugreifen k¨ onnen. Mit [printers] erfolgt die Freigabe der auf einem Linuxrechner verf¨ ugbaren Drucker. [print$] ist eine spezielle Freigabe, die es Administratoren erlaubt, Druckertreiber bereit zu stellen. So m¨ ussen diese dann nicht mittels CD eingespielt werden, wenn ein Windows-Client auf einen Linuxdrucker zugreift f¨ ur den dieser noch keinen Treiber installiert hat. Die Sektion [netlogon] spielt dann eine Rolle, wenn Samba u ¨ ber Datei- und Druckerfreigaben hinaus reichende Aufgaben u ¨bernehmen soll. Zusätzlich kann ein Samba-Administrator weitere Bl¨ ocke 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¨ ande voneinander getrennt.

17.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¨ uber mit welchem Wert sich Samba f¨ ur Browse-Wahlen anbietet. Das entscheidet beispielsweise u ¨ber die Chance ein lokaler Masterbrowser einer Arbeitsgruppe zu werden. • unix extensions = Yes - dieser Parameter stellt ein, ob Samba die CIFS Extensions f¨ ur Unix unterst¨ utzt. Damit stehen dann Symbolische Links, Hard Links, ... zur Verf¨ ugung. Nur interessant f¨ ur Unix-Clients. • encrypt passwords = Yes - neuere Windows-Clients erwarten verschl¨ usselte 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 - u ¨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.

254

KAPITEL 17. SAMBA • bind interfaces only = Yes - definiert, auf welchen Netzwerkschnittstellen der Samba-Server seine Dienste anbietet. Diese Option arbeitet mit der folgenden eng zusammen. • interfaces = 127.0.0.1 10.8.4.254/24 - legt fest, dass sowohl das LoopbackInterface und das Interface mit der IP 10.8.4.254 bedient werden. Letzeres umfasst ein Netzwerk von 256 Maschinen (Netzmaske 255.255.255.0). • hosts allow = All - legt keine Beschränkungen auf bestimmte Maschinen fest. Hier könnte sonst auch eine leerzeichengetrennte Liste von IP-Nummern stehen, die auf den Service zugreifen d¨ urfen. • 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.

17.4.3

Wichtige Optionen der anderen Abschnitte

• comment = All Printers oder comment = Gemeinsame Daten - setzen ein Kommentar f¨ ur eine Freigabe fest, die an die Clients u ¨ bermittelt wird. • path = /win-export - legt f¨ ur Dateifreigaben fest, welches Verzeichnis im LinuxDateibaum Samba bereitstellen soll. F¨ ur 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¨ upft. Das Muster entspricht dem von chmod bekannten. • force create mask = 0600 - erzwingt das Setzen eines bestimmten Bitmusters f¨ ur die Zugriffsrechte. Im Bespiel w¨ urde 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¨ urfen. 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¨ ur jeden der vielleicht viele hundert oder tausend Benutzer umfassenden Maschine eine eigene Freigabe definiert werden. • browseable = No - kontrolliert, ob die Freigabe in einer Browse-Liste der Netzwerkumgebung angezeigt wird oder nicht. • read only = No oder writable = Yes - erlaubt dem Benutzer eines Services Dateien oder Verzeichnisse anzulegen und zu verändern. • printable = Yes - erlaubt dem Client auf das Drucker-Spooler-Verzeichnis zu schreiben.

¨ 17.5. CONTROLLER-FUNKTIONALITAT

255

• public = Yes alternativ guest ok = Yes - legen fest, ob eine Verbindung ohne Passwort m¨ oglich ist. Die Rechte sind dann die des Gast-Accounts.

17.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¨ at gleichzeitig anzunehmen. Auch das SMB-Protokoll kann namensbasierte virtuelle Server anzubieten. Dabei befinden sich alle in der gleichen Arbeitsgruppe. Sinn und ¨ Zweck dieser Ubung - 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¨ ur diesen. Der Name der Datei lautet am besten auf smb.conf + Servername = smb.conf.virtual01. Hierin k¨ onnen nun wieder beliebige Freigaben eingestellt werden. Damit Samba weitere Konfigurationsdateien beim Start ber¨ ucksichtigt, f¨ ugt 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¨ ur alle virtuellen Server gelten.

17.5

Controller-Funktionalit¨ at

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¨ allen kann es f¨ ur Administratoren attraktiv sein, den Samba-Server auch zur Namensaufl¨ osung als WINS-Server oder als Ersatz eines Primary Domain Controllers zu verwenden. Dann möchte er jedoch häufig auch Ziele, wie SingleSign-On verwirklichen. Hierzu l¨ aßt sich Samba mit dem Directory-Dienst LDAP verbinden. Die notwendigen Konfigurationen sind dann jedoch deutlich komplexer.

17.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¨ upft - 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 a¨ndert sich. Hier m¨ ochte man ein Telefonbuch haben, welches Namen Nummern zuordnen kann. Diese Aufgabe u ¨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¨ ane etwas ganz anderes sieht als ein Domain-Name, wie in WebAdressen. 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 we-

256

KAPITEL 17. SAMBA

sentliche Hauptunterschiede. NetBIOS-Namen existieren in einem flachen Namensbereich. Das ist beim DNS v¨ ollig 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¨ urfen 63 und der Gesamtname nicht 255 Zeichen u berschreiten. Damit lassen sich einige Hierarchiestufen ¨ erreichen. Unter WindowsXP gibt es zwei M¨ oglichkeiten einen WINS-Server einzutragen. Zum einen kann der Admin des Netzes diese Information mittels DHCP an alle Clients verteilten: Abfragen l¨ asst sich diese Information beispielsweise mit ipconfig -all in der ”Eingabeaufforderung”. Alternativ kann man die IP f¨ ur WINS auch fest bei der Alternativen Konfiguration von TCP/IP eintragen.

Abbildung 17.3: Zwei Wege der Zuweisung der WINS-Server-Adresse

17.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¨ atzlich d¨ urfen 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

¨ 17.5. CONTROLLER-FUNKTIONALITAT ID < 00 > < 03 > < 06 > < 1B >

< 1F > < 20 > < 21 > < BE > < BF >

257

Bedeutung NetBIOS Name eines Rechners (Freigabename einer Workstation) ¨ Messenger Service Name - verwendet zum Empfangen und Ubertragen von Nachrichten, sowohl f¨ ur User- als auch Rechnernamen Routing und Remote Access Service (RAS) - Name des Servers Domain Masterbrowser Name - wird von Maschinen im Netz genutzt, um den Primary Domain Controller (PDC) einer Windows-Domain zu kontaktieren Network Dynamic Data Exchange (NetDDE) Dienst Server-Dienstname - Zugriffspunkte f¨ ur freigegebene Dateien und Verzeichnisse RAS-Client Network Monitor Agent Network Monitor Utility Tabelle 17.1: Eindeutige Namen

oder sie sind Gruppennamen. Letztere können gemeinsam benutzt werden. Der NetBIOSName MYSMB< 00 > aus dem Beispiel des vorangegangenen Abschnitts ist ein eindeutiger Name. Er beschreibt den Computer ”MYSMB”. Die Bezeichnung SAMBA-TESTNETZ< 1E > hingegen ist ein Gruppenname. Ihn benutzen Browsing-Clients, um einen MasterBrowser unter sich zu bestimmen. NetBIOS-Namen spannen nur einen flachen Namensbereich auf. Trotzdem sind in einm gleichen logischen Subnetz mehrere Namensbereiche erlaubt. Diese werden durch den NetBIOS-Scope unterschieden. Der NetBIOS-Scope ist ein String, der zusammen mit dem NetBIOS-Namen 256 Zeichen nicht u ¨ berschreiten darf. ID < 1D > < 1E >

Bedeutung Masterbrowser-Name - wird vom Client benutzt, um auf den Masterbrowser zuzugreifen (je nach Netz lokaler Masterbrowser) Gruppenname - kommt bei der Wahl von Browse-Mastern zum Einsatz Tabelle 17.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¨ ur 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. NetBIOS kennt zwei Methoden f¨ ur 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¨ osung 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 Windowsmaschinen nicht sehr clever, da sehr viel Datenverkehr generiert wird. Diese Methode kam implizit in den Konfigurationsbeispielen der vorangegangenen Abschnitte zum Einsatz.

258

KAPITEL 17. SAMBA

ID < 00 > < 1C >

< 1E > < 20 >

Bedeutung Zum Empfang von Browser-Broadcasts Arbeitsgruppenname - wird vom Domain Controller registriert und enth¨ alt eine Liste von Computern, die sich unter dieser Gruppe registriert haben Internet Gruppe Gleiche Bedeutung, wie bei Gruppenressourcen Identifikation eine Gruppe von Rechnern f¨ ur administrative Zwecke Tabelle 17.3: Domänennamen

17.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 u ¨ bliche Beschränkung der Broadcasts auf ein logisches Subnetz. Das f¨ uhrt dazu, dass Rechner in verschiedenen Subnetzen nicht u ¨ ber die Namen miteinander kommunizieren k¨ onnen. WINS löst beide Probleme. Die Aufgabe eines WINS u ¨ 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¨ upfen. Wenn Samba als WINSServer (wins support = Yes) agiert, kann der nmbd alle Namensanfragen im DNS versuchen zu finden, wenn er keinen entsprechenden Eintrag in der lokalen WINS-Datenbank gefunden hat. Der Parameter ”dns proxy” bestimmt dieses Verhalten. Samba befragt standardmäßig den DNS, wenn ein Name nicht in WINS gefunden wird. Dieses Verhalten entspricht: dns proxy = Yes. Gibt es kein DNS im eigenen Netzwerk, macht Sambas ”dns proxy” nicht viel Sinn. Mittels dns proxy = No läßt er sich deaktivieren. Eine Methode zur Namensaufl¨ osung in sehr kleinen Netzwerken ist der Weg u ¨ ber eine Textdatei. Das Konzept der lmhosts Datei kennt der Admin vielleicht schon WindowsRechnern. Sie kann auch von Samba verwendet werden und entspricht funktionell der von Linux bekannten Datei /etc/hosts. Der einzige Unterschied: Sie ordnet IP-Adressen NetBIOSNamen zu anstelle von Hostnamen. Samba schaut in der lmhosts nur f¨ ur eigene Fragen nach, nicht f¨ ur 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¨ urde Samba selbst keine Namensanfragen per Broadcast aussenden und nicht versuchen, Namen u urde nur in der lokalen ¨ ber den DNS aufzulösen. Es w¨ lmhosts Datei nachschauen und bei Misserfolg den konfigurierten WINS-Server befragen. Eine NetBIOS-Namensanfrage macht nmblookup -R -U localhost MYSMB. Die Optionen sorgen daf¨ ur, 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 u ¨ber Router hinweg fehlschlägt. Unter WindowsXP liegt diese ¨ Datei in /WINDOWS/system32/drivers/etc. Ublicherweise sieht ein Eintrag so aus: 10.8.4.254 MYSMB #PRE #DOM:SAMBA F¨ ur einfache Hosts reicht die Kombination aus IP-Nummer und NetBIOS-Name.

17.6. SAMBA ALS PDC

17.6

259

Samba als PDC

Zur großen Form l¨ auft 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¨ at eingetragen sind. Hierzu f¨ uhrte Microsoft das Konzept der Domäne ein. Eine Dom¨ ane definiert eine Gruppe von Rechnern, die eine gemeinsame Benutzerdatenbank verwenden. Diese Benutzerdatenbank stellen sogenannte Primary (PDC) und Backup Domain Controller (BDC) zur Verf¨ ugung. F¨ ur jedes Domänenmitglied - dieses können Benutzer und Rechner sein - wird ein zentrales Konto angelegt. F¨ ur 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 u ¨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¨ ur, 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¨ ussen 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 Computer¨ namen. Hierin erlaubt der Knopf ”Andern” die Aufnahme der Maschine in eine WindowsDomäne. Im nun erscheinenden Dialog legt man den NetBIOS-Namen der Maschine fest und tritt der Dom¨ ane bei. Daf¨ ur muss der Radio-Button ”Mitglied von Dommäne” aktiviert und der Name der beizutretenden Domäne daneben eingetragen werden. Nach dem

260

KAPITEL 17. SAMBA

Abbildung 17.4: WindowsXP-Maschine in eine Domäne aufnehmen Bestätigen durch ”OK” erscheint ein Anmeldedialog f¨ ur 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. ??). 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”.

17.6.1

Benutzerprofile und Logon-Skripten

Beim ersten Test-Login sehen die Benutzerprofile der beiden ”test1” und ”test2” noch sehr nackt aus. Es erscheint lediglich die Windows-Voreinstellung des Desktops. Damit ein Benutzer an verschiedenen Workstations stets das gleiche Profil vorfindet, läßt sich das Profil serverbasiert speichern. Es wird dann wärend des Anmeldevorganges auf die ClientMaschine kopiert, vor der der Benutzer sitzt. Dieses kann nicht einfach umgangen werden, da viele Anwendungsprogramme ein lokales Profil verlangen, das nicht einfach, wie von Linux gewohnt, im Homeverzeichnis liegt. Da sich die Einstellungen im Laufe einer Sitzung ändern können, m¨ ussen sie auch wieder zur¨ uckgesichert werden. Das geschieht beim Abmelden von der Arbeitsstation. Will der Administrator ganz neue Benutzer hinzuf¨ ugen, muss er diese erst als LinuxAccounts anlegen und anschliessend mit smbpasswd -a UserID in die Samba-Benutzerdatenbank kopieren. Nun m¨ ussen noch einige Eintragungen in der smb.conf vorgenommen werden. Mit dem Eintrag

17.6. SAMBA ALS PDC

261

Abbildung 17.5: Dom¨ anen-Aufnahme - Passwortdialog logon path = \\%N \%U\profile (f¨ ur NT/2000/XP) ; alternativ: logon home = \\%N \%U\profile (f¨ ur Windows 9x) in der [global]-Section der smb.conf wird im Heimatverzeichnis des Benutzers ein Verzeichnis namens profile erstellt und das Profil dort gespeichert. Der Service erhält eine eigene Sektion in der Konfigurationsdatei: [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700

Zur Aktivierung dieses Features ist ein Neustart des Servers erforderlich. Damit bei der Benutzeranmeldung noch Anpassungen seiner Umgebung vorgenommen werden können, kann ein Logon-Skript ausgef¨ uhrt werden. Dieses definiert der Admin mittels logon script = scripts/default.bat Dieses Skript wird unter Windows ausgef¨ uhrt, 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

262

KAPITEL 17. SAMBA create mask = 0664 directory mask = 0775 browsable = No

Ein Beispielskript f¨ ur NT findet sich je nach eingesetzter Linux-Distribution im SambaDoku-Paket unter: .../doc/.../samba/examples/ntlogon/ntlogon.conf.

17.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¨ ur große Netze mit vielen Linux- und Windows-Rechnern, an denen sich ein Nutzer anmelden kann, zu umst¨ andlich. Hier hilft ein hierarchisches Verzeichnis weiter, die sich f¨ ur solche Zwecke geradezu anbietet. LDAP - das Lightwight Directory Access Protocol (vgl. Kap. 9.3) ist ein verabschiedeter Internet-Standard. Microsoft verwendet dieses als Grundlage f¨ ur seine Active Directory Service. OpenLDAP ist eine OpenSource-Implementierung, die standardm¨ aßig bei Ihrer Linuxdistribution dabei sein sollte. LDAP arbeitet im ClientServer-Modell u ¨ber TCP/IP. Samba kann als LDAP-Client agieren und alle Informationen, die es f¨ ur seinen Betrieb braucht aus dem Directory beziehen und veränderte Daten wieder zur¨ uckschreiben. 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¨ ur den Server und die Client-Programme benötigt die Installation zus¨ atzlich ”pam ldap”, ”nss ldap” und ”ldapsmb”, wenn auch die Verwaltung der Linux-Benutzer mittels LDAP erfolgen soll.

17.7.1

Konfiguration des LDAP-Servers

Es gibt ein eigenes Kapitel dieses Skriptes 1 . Im nächsten Schritt erweitert man die Liste der standardm¨ aßig benutzten Schemas um eines f¨ ur Samba3. Dieses installiert SuSE bereits automatisch in das richtige Verzeichnis. K¨ ummert sich Ihre Distribution nicht darum, findet man sicherlich das Schema als Beispiel in der Dokumentation des Samba-Paketes. Minimalkonfiguration der /etc/openldap/slapd.conf inlcude [ ... ] suffix rootdn rootpw

/etc/openldap/schema/samba3.schema "dc=my-domain,dc=site" "cn=Manager,dc=my-domain,dc=site" GeheiM

Zusätzlich passen Sie die Benennung Ihrer LDAP-Wurzel an (suffix), definieren entsprechend den Datenbank-Manager (rootdn) und setzen f¨ ur diesen ein Passwort (rootpw). Einige dieser Einstellungen finden Sie auch in der neuen smb.conf wieder (ldap *).

17.7.2

Die neue Samba-Konfiguration

F¨ ur 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. 1

zumindest in den meisten Kompilationen. (vgl. Kap. 9.3) Sonst gibt es das evtl. extra oder u ¨ ber http://goe.net per CVS zu beziehen.

17.7. SAMBA UND LDAP [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 set primary group script = /var/lib/samba/sbin/smbldap-usermod.pl -g ’% add machine script = /var/lib/samba/sbin/smbldap-useradd.pl -w ’%u’ logon script = scripts\logon.bat logon path = \\%L\profiles\%U logon drive = H: printcap name = CUPS printing = cups printer admin = Administrator [homes] comment = Home Directories valid users = %S read only = No inherit permissions = Yes browseable = No [profiles] comment = Network Profiles Service path = %H read only = No create mask = 0600 directory mask = 0700 store dos attributes = Yes [users] comment = All users path = /home read only = No inherit permissions = Yes [groups]

263

264

KAPITEL 17. SAMBA comment = All groups path = /home/groups read only = No inherit permissions = Yes

Vor dem Neustart des Samba-Servers mit der umgebauten Konfiguration entfernt der Admin am besten noch die alten *.tdb und *.dat Dateien aus den beiden oben angebenen Verzeichnissen. Da der Samba-Server mit dem LDAP-Server kommuniziert und Einträge anlegt, benötigt Samba das Manager-Passwort: linux2:/etc/samba # smbpasswd -w GeheiM Setting stored password for "cn=Manager,dc=my-domain,dc=site" in secrets.tdb

Dann wird es Zeit die Server mit: rcsmb (re)start; rcnmb (re)start; rcldap (re)start; - oder passend zur jeweiligen Distribution - neu zu starten. Am besten wirft man einen kurzen Blick ins Logfile /var/log/samba/log.smbd, ob keine Fehler aufgetreten sind. Der Befehl smbclient -L localhost -U% sollte nun eine Serverstatusmeldung generieren. Mit dem Kommando linux2:/etc/samba # net getlocalsid [2004/11/22 19:51:17, 0] lib/smbldap.c:smbldap_search_suffix(1101) smbldap_search_suffix: Problem during LDAP search: (No such object) SID for domain MYSMBLDAP is: S-1-5-21-2420552454-2742262544-3303448865 linux2:/etc/samba # ls -la secrets.tdb -rw------- 1 root root 8192 Nov 22 19:45 secrets.tdb

erzeugt man einen eindeutigen Idenfier f¨ ur die Maschine. Anschliessend gibts auch wieder eine secrets.tdb.

17.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¨ uhrt 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 o ¨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";

17.7. SAMBA UND LDAP

265

$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¨ ur $usersou und $groupsou m¨ ussen nat¨ urlich mit den Definitionen in der smb.conf u ¨ bereinstimmen. Man ist jedoch nicht auf ”user” und ”group” festgelegt und ¨ können geändert werden. Ahnliches gilt f¨ ur den NetBIOS-Namen des Samba-Servers und den Buchstaben f¨ ur das Home-Laufwerk. F¨ ur die meisten der derzeit aktuelle Samba-Versionen und Idealx-Skripten m¨ ussen 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¨ anenbeitritt fehl, da eine Maschine zwar sauber in den LDAP eingetragen, danach aber nicht wiedergefunden wird. Dieses Problem scheint mit den neuesten

266

KAPITEL 17. SAMBA

Samba-Versionen und Idealx-Skripten2 behoben. Ebenfalls entfallen die Ergänzungen der Objektklassen. Daf¨ ur 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¨ ur den Netzwerkzugriff des Samba auf LDAP nat¨ urlich noch IP und Port oben in der Datei anzugleichen. Generell f¨ ugt das Skript umfangreichere Informationen ein, als f¨ ur ein reines Samba-Backend benötigt w¨ urden. Zusätzlich sind auch alle Informationen f¨ ur 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¨ ugen zweier struktureller LDAPObjektklassen in die Datei smbldap-populate.pl Zeilen 323 und folgende: dn: cn=Domain Admins,$groupsdn objectClass: posixGroup +objectClass: top +objectClass: namedObject objectClass: sambaGroupMapping gidNumber: 512 cn: Domain Admins Das Ergebnis sieht dann so aus: linux2:/var/lib/samba/sbin # ./smbldap-populate.pl Using builtin directory structure 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 Durchlauf von smbldap-populate.pl muss der LDAP-Server neu gestartet werden: rcldap restart. Als n¨ achstes benötigt der LDAP-Server ein Container-Objekt f¨ ur IDMAP-Informationen. Dieser ist u ¨ berlicherweise nicht vorhanden und muss per Hand erzeugt werden. Dazu legen Sie eine Datei idmap.ldif mit folgendem Inhalt an: 2

www.idealx.org - Version 0.8.5, die 0.8.4 funktioniert nicht korrekt


267

dn: ou=Idmap,dc=my-domain,dc=site objectClass: top objectClass: organizationalUnit ou: Idmap Diese Datei liegt im sogenannten LDIF vor - ein Austauschformat zwischen LDAP-Datenbanken. Mit dem Kommando ldapadd -x -D "cn=Manager,dc=my-domain,dc=site"-w GeheiM -f idmap.ldif f¨ ugt 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: top objectClass: organizationalUnit ou: Idmap # search result search: 2 result: 0 Success # numResponses: 21 # numEntries: 20

Es sollte eine ziemlich lange Liste liefern. Dann wird es Zeit sich um den Name Service Switch zu k¨ ummern, 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

268

KAPITEL 17. SAMBA

Die Einstellungen in dieser Datei als auch die LDAP-Client-Konfiguration kann ebenfalls mit YaST2 vorgenommen werden (Abb. yast2-ldap-client Erreichbar in YaST2 u ¨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¨ urde aber den Rahmen des hier Beschriebenen sprengen. Auf diesem Wege k¨ onnen Administratoren jedoch ein ”single-password” realisieren. Bisher waren nur Systembenutzer automatisch angelegt worden. Mit den entsprechenden Tools können nun weitere hingezuf¨ ugt werden: linux2:/var/lib/samba/sbin # linux2:/var/lib/samba/sbin # Changing password for test1 New password : Retype new password : linux2:/var/lib/samba/sbin # linux2:/var/lib/samba/sbin # Changing password for test1 New password : Retype new password :

./smbldap-useradd.pl -m -a test1 ./smbldap-passwd.pl test1

./smbldap-usermod.pl -u 0 Administrator ./smbldap-passwd.pl Administrator

Der Administrator hat vorerst noch eine UID ungleich null. Das a¨ndert man mit smbldapusermod.pl wie im Beispiel gezeigt. F¨ ur ihn brauchen Sie auch noch ein Passwort f¨ ur den späteren Dom¨ anenbeitritt. Mittels - der im smb.conf Beispiel auskommentierten - ”username map” kann der Administrator auch auf den Unix-Admin ”root” abgebildet werden. Diese


269

Nutzer stehen sofort auch unter Linux zur Verf¨ ugung, wie getent passwd oder id test13 zeigen. Dass der User auch f¨ ur 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 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¨ uhrenden 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¨ ur smbldussen zwei Zuweisungen hinzugef¨ ugt werden: ap tools.pm nicht erspart: Ab Zeile 283 m¨ objectClass => ’top’, objectClass => ’namedObject’, die die Objektklasse ”posixGroup” erg¨ anzen. Treten weitere Probleme mit einem der anderen Tools auf, liegt es h¨ aufig an den Einstellungen zu den LDAP-Objekten. Ein letzter Test u uft die korrekte Zuweisung der Gruppen: net groupmap list. ¨ berpr¨ Damit sollte nun das Setup abgeschlossen und ein PDC mit verändertem Backend aufgesetzt worden sein. Nun k¨ onnen Sie die Schritte wie im Abschnitt ”Samba als PDC” beschrieben wiederholen. Die Dom¨ ane heisst nun etwas anders, um den Unterschied herauszustellen. F¨ ur den Windows-Client ¨ andert sich nicht viel (Abb. smbldap-domain ”Einf¨ ugen einer Windows-XP Maschine in eine Domäne mit Samba/LDAP-Backend” und ”Anmeldung an der neuen Dom¨ ane” Abb. xp-sambatestnetz). 3

siehe hierzu auch den Teil zur Benutzerverwaltung mit LDAP

270

17.7.4

KAPITEL 17. SAMBA

Fazit von Samba-LDAP-Aktionen

Der Aufwand f¨ ur eine solche Aktion ist deutlich höher als ohne Verwendung von LDAP, da eine ganze Reihe von Schritten durchzuf¨ uhren 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¨ osung zum bequemen Management einer WindowsDomäne ohne hierf¨ ur teure Microsoft-Server-Lizenzen beschaffen zu m¨ ussen. Fast nebenbei fällt ein elegantes ”single-password” f¨ ur Windows- und Linuxmaschinen ab. Zusätzlich kann LDAP dazu benutzt werden zentrale Adressb¨ ucher bereitzustellen oder eine generelle Verwaltung bestimmter IT-Ressourcen zu realisieren.

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¨ uck. Sicherheitserw¨ agungen spielten bei der Entwicklung des IP zu Beginn nur eine nachrangige Rolle bzw. wurden bewußt auf höhere Protokollschichten verlagert. Die Datenpakete, in die Datenstr¨ ome aufgeteilt werden, passieren auf ihrem Weg zwischen Sender und Empf¨ anger 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 u ¨ berschreiten. An der Weiterleitung dieser Datenströme sind dann meistens mehrere Provider beteiligt, die u ¨ ber sehr unterschiedliches Know-How und Sicherheitsvorstellungen verf¨ ugen k¨ onnen.

18.1.2

Offener Datentransport

F¨ ur den Transport von Daten in einem Netzwerk, d.h. eine Kommunikation zwischen zwei Rechnern A und B, ben¨ otigt man offene und gemeinsame Standards, damit eine Verbindung zustande kommen kann. Hierf¨ ur reicht es aus, dass jeweils die Datenheader der verwendeten Protokolle genormt und f¨ ur alle am Transport Beteiligten interpretierbar sind. Da Empfänger und Absender nicht direkt miteinander kommunizieren, sondern ihre Pakete nur an den n¨ achsten Router (meistens einfach an das Default-Gateway) ausliefern, lassen sich Aussagen u at und die Richtigkeit des Inhaltes von Paketen nicht ¨ ber die Authentizit¨ machen. F¨ ur erfahrene Anwender bzw. Benutzer einschlägiger Programme ist es u ¨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¨ aß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¨ ufsummen von IPund TCP-Header nat¨ urlich auch vom F¨ alscher 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 diese nicht relevant sind. Trotzdem möchte man sicherlich nicht, dass ein Fremder die eigene 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¨ onnen, so lassen sich doch Mails mit sehr u ¨blen Inhalten 271

272

KAPITEL 18. SICHERES IP

Abbildung 18.1: Snapshot einer Ethereal-Analyse verfassen, die den oder die Accountinhaber/in in Schwierigkeiten bringen können. Oder aber jemand verwendet mitgeh¨ orte Ebay-Daten dazu, Gebote auf eigene Artikel zu platzieren. Das folgende Listing zeigt einen Ausschnitt einer Google-Sitzung; viele Informationen kann man sofort und ohne großen Aufwand direkt entnehmen.

0040 0050 0060 0070 0080 0090 00a0 00b0 00c0 00d0 00e0 00f0 0100 0110 0120 0130 0140 0150 0160 0170

29 77 69 38 3d 2d 35 20 6e 74 2e 78 2c 67 74 69 74 65 75 3d

0d 69 6e 35 20 41 2e 4b 75 74 64 74 20 65 2d 70 79 74 74 30

b5 47 65 2b 39 48 67 30 6f 78 70 65 2f 69 2f 45 2c 0d 3a 66 2e

48 45 2b 6e 2d 54 65 20 6e 29 3a 2f 2a 6d 2a 6e 20 0a 20 2d 35

00 54 68 65 31 54 6e 28 71 0d 2f 0d 2c 61 2c 63 67 41 69 38 0d

00 20 61 74 26 50 74 63 75 0a 2f 0a 20 67 20 6f 7a 63 73 3b 0a

01 2f 63 7a 68 2f 3a 6f 65 52 77 41 69 65 2a 64 69 63 6f 71 41

01 73 6b 26 6c 31 20 6d 72 65 77 63 6d 2f 2f 69 70 65 2d 3d 63

08 65 65 69 3d 2e 4d 70 6f 66 77 63 61 70 2a 6e 2c 70 38 30 63

0a 61 2b 65 64 31 6f 61 72 65 2e 65 67 6e 0d 67 20 74 38 2e 65

11 72 69 3d 65 0d 7a 74 2f 72 67 70 65 67 0a 3a 69 2d 35 35 70

df 63 63 49 26 0a 69 69 33 65 6f 74 2f 2c 41 20 64 43 39 2c 74

06 68 68 53 6d 55 6c 62 3b 72 6f 3a 6a 20 63 78 65 68 2d 20 2d

9c 3f 2b 4f 65 73 6c 6c 20 3a 67 20 70 69 63 2d 6e 61 31 2a 4c

42 71 6d 2d 74 65 61 65 4c 20 6c 74 65 6d 65 67 74 72 2c 3b 61

97 3d 65 38 61 72 2f 3b 69 68 65 65 67 61 70 7a 69 73 20 71 6e

-@5H.... ..._..B. ).GET /search?q= wie+hacke+ich+me in+netz&ie=ISO-8 859-1&hl=de&meta = HTTP/1.1..User -Agent:Mozilla/ 5.0 (compatible; Konqueror/3; Li nux)..Referer: h ttp://www.google .de/..Accept: te xt/*, image/jpeg , image/ png,ima ge/*, */*..Accep t-Encodi ng:x-gz ip, gzip ,identi ty..Accept-Chars et: iso-8859-1, utf-8;q= 0.5,*;q =0.5..Accept-Lan

18.1. SICHERHEITSPROBLEME DES DERZEITIGEN IP-STANDARDS 0180 0190 01a0 01b0 01c0 01d0 01e0 01f0

67 20 43 35 3a 37 37 38

75 77 6f 66 4c 31 30 53

61 77 6f 35 44 37 3a 59

67 77 6b 31 3d 30 53 7a

65 2e 69 34 64 3a 3d 51

3a 67 65 38 65 4c 35 0d

20 6f 3a 31 3a 4d 49 0a

65 6f 20 33 54 3d 4b 0d

6e 67 50 30 4d 31 57 0a

0d 6c 52 35 3d 30 55

0a 65 45 35 31 33 36

48 2e 46 64 30 38 38

6f 64 3d 62 33 38 68

73 65 49 62 38 32 50

74 0d 44 38 38 37 58

3a 0a 3d 32 32 31 73

273

guage: en..Host: www.google.de.. Cookie:PREF=ID= 5f514813055dbb82 :LD=de:TM=103882 7170:LM=10388271 70:S=5IKWU68hPXs

Dar¨ uberhinaus 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¨ unden, wie DoS-Attacken erfolgen. Weiterhin gibt einem die Tatsache, dass bei vielen klassischen Protokollen (wie Telnet, Pop3, Imap4, ftp, http) Passw¨ orter im Klartext u ¨ bertragen werden und damit sehr einfach abzufischen sind, kein gutes Gef¨ uhl. Der Inhalt der Pakete ist auch vor Fälschungen nicht sicher. Zwar bildet der IP-Stack Pr¨ ufsummen u ¨ber den Header und den Paketinhalt1 , jedoch sind die Routinen einfach auf ver¨ anderte Pakete anwendbar. Die Verteilung des IP-Adressraumes liefert vielerlei Anhaltspunkte in Bezug auf die Lage bestimmter Maschinen und Netzwerkstrukturen. Ein genaues Wissen u ¨ ber solche Strukturen erleichtert das Eindringen in Netze. So wird vielleicht das Zielsystem nicht direkt angegriffen, sondern mittelbar u ¨ber weitere Rechner, die ”näher an dieser Maschine liegen”, korrumpiert.

18.1.3

Absicherung - L¨ osungsans¨ atze

Die geschilderten Probleme erzwangen Lösungen, ohne die sichere private und geschäftliche Kommunikation nicht denkbar w¨ are. 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¨ uhren, die anderen erfordern zus¨ atzliche Kernelmodifikationen und Root-Rechte. Netzwerk-Level Pakete, die zwischen Rechnern auf dem Netzwerk transportiert werden, sind verschl¨ usselt. Die Verschl¨ usselung 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. Anderungen oder Zusätze zu den einzlenen Netzwerkapplikationen sind unnötig. In dem Augenblick wo IP-Pakete verschl¨ usselt werden, kann diese Funktion in Router eingebaut werden. Diese werden u ¨ blicherweise sowieso als ”BlackBoxes”betrachtet, da sie den Verkehr zwischen Hosts transparent weiterleiten und selbst nicht f¨ ur den normalen Anwender sichtbar werden. So sieht ein Verschl¨ usselungsrouter f¨ ur den Endanwender wie ein nichtverschl¨ usselnder Router aus. Ein Beispiel hierf¨ ur ist z.B. die SonicWall Pro. Dieser Ansatz lohnt sich besonders dann, wenn eine Verschl¨ usselung auf Applikationsebene nicht möglich oder ¨ außerst aufw¨ andig scheint und sehr viele verschiedene Anwendungen sicher kommunizieren sollen. Beispiele f¨ ur diesen Ansatz sind Microsofts ”Microsoft Point-to-Point 1

IP merkt sich die Paketgesamtl¨ ange und eine Headerpr¨ ufsumme, TCP die Headerl¨ ange und eine Datenpr¨ ufsumme

274


Tunnel Protocol” (PPTP), die Crypto IP Encapsulation (CIPE), OpenVPN und IPsec. Die beiden letzteren Ans¨ atze werden als freie Software im Sinne der GPL entwickelt. F¨ ur das Microsoft-Protokoll existiert ein Linux-Client, um Verbindung mit entsprechenden Microsoftsystemen aufnehmen zu k¨ onnen. 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¨ ohere Protokolle, also nicht nur IP-Pakete dar¨ uber zu tunneln. So können auch IPX und NetBIOSPakete verschickt werden. Der Einrichtungsaufwand f¨ ur dieses Protokoll muss wegen einiger Kernel- und Systemanpassungen als recht hoch eingeschätzt werden. Es gibt verschiedene Versionen und widerspr¨ uchliche 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¨ usselungen den gemeinsamen Nachteil, dass sie keinen Schutz gegen Einbr¨ uche 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 PGPVerschl¨ usselung und Signierung von Emails oder Zertifikate f¨ ur Webinhalte und Programme. Socket-Level F¨ ur 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¨ usselt aber den Inhalt von Paketen. So können die u ¨bertragenen Passwörter und Daten nicht von Dritten mitgehört und modifiziert werden. Mittels SSH lassen sich einfache TCP-Tunnel realisieren. F¨ ur webbasierte Kommunikation wurde der Secure Socket Layer eingef¨ uhrt, der es ermöglicht die HTTP-Kommunikation zwischen Server und Webbrowser zu verschl¨ usseln. Diese Verbindung arbeitet auf der logischen Verbindungsebene der kommunizierenden Programme. In beiden geschilderten F¨ allen wird zwar verhindert, dass die Pakete mitgelesen und modifiziert werden k¨ onnen, jedoch bleibt dem Aussenstehenden die - der Kommunikation zugrundeliegende - Netzstruktur nicht verborgen. Der Aufwand der Konfiguration hält sich sowohl f¨ ur SSH, als auch f¨ ur SSL in Maßen. Es werden keine Kernelmodule benötigt und die Verschl¨ usselung kann vom normalen Benutzer ohne spezielle Rechte durch den Aufruf bzw. die entsprechende Konfiguration der Applikation erfolgen. Applikationsebene In jede Applikation kann eine Verschl¨ usselung eingebaut werden, welche die Daten - bevor sie in die Transportschicht gelangen - geeignet einpackt. Ein Beispiel sind Emailprogramme: Emails werden standardmäßig unverschl¨ usselt u ¨ bertragen. Dabei könnte prinzipiell jeder Administrator eines Servers, der von der Mail durchlaufen wird, die Mail lesen. Nat¨ urlich w¨ are auch ein Geheimdienst oder Wirtschaftsspion in der Lage die Leitungen anzuzapfen und k¨ onnte jede Mail mitlesen. Um dieses zu verhindern wird den Mailprogrammen ein Plugin hinzugef¨ uhrt, bzw. die Fähigkeit Emails vor dem Versenden zu verschl¨ usseln und auf der Empfängerseite zu entschl¨ usseln. Viele Mailprogramme haben Verschl¨ usselungsmöglichkeiten bereits eingebaut. Spezielle Verschl¨ usselungsprogramme wie Pretty Good Privacy (PGP) stehen zum Download bereit. Installations- und Gebrauchsanweisungen sind allenthalben zu finden. Die Installationsrou-

¨ 18.2. VPNS - SICHERE NETZE UBER DAS INTERNET

275

tinen und Bedienoberfl¨ achen sind ausgereift; sie können auch ohne tiefgreifende technische Vorkenntnisse genutzt werden.

18.2

VPNs - Sichere Netze u ¨ ber das Internet

Ein VPN ”Virtual Private Network2 ” verbindet entweder zwei Netzwerke oder einen Computer mit einem Netzwerk oder zwei Computer - und das jeweils auch u ¨ 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¨ urden. Obwohl die Rechner räumlich durch das offentliche Netz getrennt sind, hat man durch das Tunneling-Verfahren eine Situation ge¨ schaffen, welche die Rechner ”virtuell” wie Mitglieder des lokalen Netzwerkes erscheinen läßt.

Öffentliches unsicheres IP-Netzwerk 202.38.21.24 lisa.dyndns.org

Right Subnet 62.137.15.134 rainer.dyndns.org 192.168.4.0/24

192.168.2.0/24

Left Subnet

Internet

192.168.2.254

192.168.4.254

Abbildung 18.2: Eine typische VPN-Situation Folgende Ziele sollen durch VPN’s erreicht werden: • erweitertes Routing - IP-Netze k¨ onnen von dritten unsichtbar u ¨ ber öffentliche Netze getunnelt werden. Dadurch l¨ aßt sich die zugrundeliegende Netzwerkstruktur verdecken und die Identit¨ at der kommunizierenden Rechner verbergen. • Sicherstellung der Absenderauthenzität • Verschl¨ usselung 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¨ ur Verschl¨ usselungstunnel bietet die Crypto IP Encapsulation. Dieses Protokoll ist so angelegt, dass IP-Pakete in verschl¨ usselten UDPPaketen u ¨ bertragen werden. Der Vorteil UDP als Transportprotokoll zu verwenden, liegt 2

zu deutsch: Virtuelles Privates Netzwerk

276


in der leichten Unterscheidbarkeit verschiedener Endpunkte. Bei einer einfachen IP-zu-IPKapselung ist man auf die eigene eingetragene IP-Adresse beschränkt und kann schwer mehrere Tunnel voneinander unterscheiden. Weiterhin wird der Transport u ¨ber dynamische Adressen, Network Address Translation und SOCKS Proxies ermöglicht, die keine spezielle Anpassung f¨ ur CIPE ben¨ otigen. 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¨ ur Linux und Windows. Die Linuximplementation erfordert ein spezielles Kernelmodul, das jedoch bei den meisten Distributionen mit CIPE bereits mitgeliefert wird. Das Kernelmodul regelt das Senden und Empfangen der IP-Pakete. Es definiert ein Netzwerkdevice cipcb*, z.B. ifconfig cipcb0 cipcb0

Link encap:IPIP Tunnel HWaddr inet addr:192.168.2.254 P-t-P:192.168.4.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (70.6 Mb) TX bytes:0 (813.0 Mb)

oder mittels des IP-Route2-Tools ip: ip addr show dev cipcb0 9: cipcb0: 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¨ uber mittels /etc/cipe/ip-up einzutragen oder Firewall-Regeln darauf anzuwenden. Im Namen des Netzwerkinterfaces wird der Verschl¨ usselungsalgorithmus (im ¨ Beispiel ”b” f¨ ur blowfish) kodiert, der zum Zeitpunkt der Ubersetzung von CIPE angegeben werden kann. Im ”user space” l¨ auft 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¨ usselungsrouter auf Basis von CIPE weisen eine herausragende Leistung auf, mit Datentransferraten, die nur zwei bis drei Prozent unter denen des unverschl¨ usselten 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¨ onnen. 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¨ ussen (wenn sich die IP-Daten der Verbindung nicht andern). ¨

18.3. CIPE

18.3.2

277

Aufsetzen von CIPE

Meistens wird CIPE mit der jeweiligen Linuxdistribution mitgeliefert. Dann wird u ¨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¨ ugt werden. F¨ ur jeden CIPE-Tunnel wird eine eigene Konfigurationsdatei angelegt. Bei SuSE wird dem Dateinamen ”option” die Bezeichnung der Verbindung nach einem Punkt angeh¨ angt, so dass alle Verbindungen mit dem Init-Skript gestartet werden, die mit ”option.*” beginnen. F¨ ur das Beispiel-VPN im Bild w¨ urden die Konfiguratinsdateien f¨ ur 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¨ ur 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¨ ur den Privatanwender mit der InternetEinwahl und dynamischer IP-Vergabe kann man eine Seite so konfigurieren, dass sie in Abhängigkeit von der eingehenden Verbindung die Gegenstelle erkennt: # option.example-vpn right side

278


# [ ... ] me 134.34.80.5:10001 peer 127.0.0.1:9 maxerr -1 Hierin besteht der Trick, dass als Gegenstelle einfach die Maschine selbst mit dem DiscardPort angegeben wird, der alle eintreffenden Pakete verwirft. Damit der ciped nicht abbricht, wird die Zahl der erlaubten Fehlversuche mit ”-1” auf unendlich gesetzt. Die Gegenstelle, d.h. der Rechner mit der dynamischen IP-Adresse erhält folgende Einstellungen: # option.example-vpn left side # [ ... ] me 0.0.0.0:10000 peer 134.34.80.5:10001 dynip Nur dieser Rechner kann eine Verbindung initiieren. Wenn zwei Maschinen mit dynamischer IP miteinander kommunizieren, kann auch der DNS-Name statt einer festen IP eingetragen werden. Probleme k¨ onnten jedoch auftreten, wenn sich die IP-Nummer ändert. Mit CIPE 1.5 ist die M¨ oglichkeit hinzugekommen, Schl¨ ussel u ¨ ber ein Public-Key-Verfahren analog zu SSH auszutauschen. Dieser Prozess wird mittels des Zusatzprogrammes pkcipe abgewickelt. Einfacher und weniger fehleranf¨ allig, sowie unter Sicherheitsaspekten meistens ausreichend, ist es in den Konfigurationen einen gemeinsamen Schl¨ ussel 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¨ ussel dient zur Generierung des häufiger gewechselten dynamischen Schl¨ ussels mit dem die Daten tatsächlich gecryptet werden. Die realen routebaren Adressen und die virtuellen Tunneladressen m¨ ussen sich in jedem Fall unterscheiden. Zus¨ atzlich 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¨ ur 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¨ uhrt zur Beschäftigung mit IPsec.

18.4

IPsec-Theorie

IPsec ist ein Versuch, s¨ amtlichen3 Internet-Verkehr automatisch zu verschl¨ usseln. Damit dies ohne Ver¨ anderung der bestehenden Anwendungen geschehen kann, wird die Verschl¨ usselung und Authentifizierung auf IP-Ebene, also unterhalb von TCP, UDP und anderer Protokolle durchgef¨ uhrt. 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¨ angig von der darunterliegenden Infrastruktur kommunizieren können. Im 3

oder zumindest einen großen Teil des

18.4. IPSEC-THEORIE

279

Authentication Header

IP Header

Next Header

Data (variable)

Payload Length

RESERVED

Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) 32 bit

Abbildung 18.3: Aufbau und Einsatz im IP eines Authentication-Header Transportmode - dem einfacheren Verfahren - werden nur die Daten der Transportschicht beachtet. Bei beiden Typen werden die Daten verschl¨ usselt und es wird jeweils gegen¨ uber der anderen Maschine bzw. dem Tunnelendpunkt authentifiziert. Original

IP Header

IP-Datagramm

Data (variable) Getunneltes

Neuer IP Header

IP Header

IP-Datagramm

Data (variable) Datagramm mit Auth-Header im Tunnelmodus

Neuer IP Header

Auth. Header

IP Header

Data (variable)

authentifiziert

Abbildung 18.4: Einf¨ ugen des AH im Tunnelmodus Zur Realisierung der Paketintegrit¨ at sind dem Internet-Protokoll zwei weitere Headertypen (AH und ESP) in der Transportschicht hinzugef¨ ugt worden. Beide Header sind prinzipiell unabhängig von m¨ oglichen kryptographischen Verfahren, um Anpassungen an konkrete Einsatzgebiete und den Stand der Kryptografie zu erlauben. Mittels Authentication Header (AH) wird die Integrit¨ at der u utzt und die Authentizität sicher¨ bertragenen Daten gesch¨ ¨ gestellt. Selbst wenn die Daten nicht versch¨ usselt werden, erlaubt AH die Uberpr¨ ufung der Daten. Dies erfolgt mittels Pr¨ ufsumme u ¨ber den Datenblock durch SHA-1 oder MD5Verfahren. ESP steht f¨ ur Encapsulated Security Payload und sorgt durch Verschl¨ usselung f¨ ur: Die Vertraulichkeit der Daten, deren Integrität und die Authentifizierung der Datenquellen von IP. Der ESP-Header ist selbst nicht verschl¨ usselt, der ESP-Trailer teilweise. Der ESPHeader enthält: Sicherheitsparameterindex (SPI), den Verschl¨ usselungsalgorithmus, die Authentifizierung und den Modus. Im Trailer sind eine Seriennummer, eine Pr¨ ufsumme zur Sicherstellung der Datenintegrit¨ at und weitere SPI.

280

KAPITEL 18. SICHERES IP Security Parameters Index (SPI) Sequence Number Field Payload Data (variable) Padding Pad Length

Padding (0-255 byte)

Next Header

e n c r y p t e d

a u t h e n t i c a t e d

Authentication Data (variable) 32 bit

Abbildung 18.5: Aufbau eines ESP Paketes Original

IP Header

IP-Datagramm

Data (variable)

Getunneltes IP-Datagramm

Neuer IP Header

IP Header

Data (variable) Datagramm mit ESP im Tunnelmodus

Neuer IP Header

ESP Header

IP Header

Data (variable)

ESP Trail

ESP Auth

verschlüsselt authentifiziert

Abbildung 18.6: Einsatz des ESP im IP-Datagramm Ergänzt werden die beiden Header-Typen durch das Internet Security Association and Key Management Protocol (ISAKMP). Dieses wird dazu verwendet, eine Security Association zwischen den beteiligten Kommunikationspartnern zu etablieren und Schl¨ ussel 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¨ usselaustauschverfahren, 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¨ ubergreifend interoperabel werden. Unter Linux erweitert das FreeSWANProjekt den Linux-IP-Stack um die F¨ ahigkeiten von IPsec. Es gibt Lösungen f¨ ur 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¨ ankt. 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¨ oglichkeiten und F¨ ahigkeiten von IPsec u ¨bersteigen die von anderen Sicherheitslösungen erheblich. Das impliziert jedoch eine Modifikation des Kernels. Aufgrund sehr komfortabler Skripte gelingen die notwendigen Anpassungen auch weniger erfahrenen

18.5. IPSEC PRAKTISCH - FREESWAN

281

Kernelbauer. Vielen Linuxdistributionen liegt inzwischen die FreeSWAM IPsec-Suite bei. Die FreeSWAN IPSec Authentifizierung und Verschl¨ usselung kann entweder SSL oder RSA (public/private Schl¨ usselpaare) oder statische PSK (Pre-Shared Keys) verwenden. IPSec Verschl¨ usselungstunnel gibt es in verschiedenen Formen, die drei u ¨ blichsten sind: Netz-Netz, Netz-Host, Host-Host.

18.5.1

Konfigurationsm¨ oglichkeiten von IPsec

Verschl¨ usselter Internet-Verkehr zwischen Rechnern oder ganzen Netzen kann auf vielerlei Arten genutzt werden. Hier sollen einige Beispiele f¨ ur den Einsatz von IPsec im täglichen Leben gezeigt werden. • Point-to-Point Verschl¨ usselung zwischen zwei einzelnen Maschinen - Die einfachste Art eine IPsec Verschl¨ usselung zu nutzen besteht darin, den kompletten IP-Verkehr zwischen zwei Maschinen zu verschl¨ usseln: die Point-to-Point Verschl¨ usselung. 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¨ ur 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. u ¨ 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 u ugt4 , mit dem ¨ ber eine Firewall, die idealerweise u ¨ ber eine IPsec Implementation verf¨ 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) u ¨ bertragen die entsprechenden Pakete u ¨ ber den aufgebauten IPsec Tunnel, was f¨ ur die Benutzer völlig transparent geschieht. • ”Direktes Erscheinen lassen der Maschine im Firmennetz” - damit ist in diesem Zusammenhang gemeint, dass ein weit entfernter Rechner u ¨ ber IPsec sozusagen in das Firmennetzwerk integriert wird. Dabei erhält der Rechner eine IP aus dem Pool der Firma und ist nicht u ¨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¨ oglich - beim Zugriff auf Fileserver, Datenbankserver oder Arbeitsgruppen - den Zugriff auf das interne Netz einzuschränken, also mögliche externe IPs zu ber¨ ucksichtigen. • Road-Warrior - Die ”Road-Warrior” Konfiguration ist das Paradebeispiel f¨ ur 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¨ ur sorgt, dass der Road-Warrior sich u ¨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

282

KAPITEL 18. SICHERES IP Firmenrechner zugreifen muß. Ein angenehmer Nebeneffekt ist dabei nat¨ urlich auch, dass potentiell vertrauliche Daten nicht unverschl¨ usselt durch die Leitungen geschickt werden m¨ ussen.

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 herunter und entpackt diese. Vorher sollten jedoch die Kernelsources zum verwendeten Kernel vorbereitet werden. ¨ Einrichten des Kernels Beispielhaft soll hier die Installation und Ubersetzung der Quellen von FreeSWAN auf einem Rechner mit RedHat Linux 8.0 beschrieben werden, wof¨ ur root-Rechte erforderlich sind. Auf SuSE-Systemem kann man sich die M¨ uhe sparen, da eine fertig u ¨ bersetze FreeSWAN Version in der Distribution enthalten ist. Man hat die M¨ oglichkeit entweder die FreeSWAN-Quellen, oder schon kompilierte RedHat Binaries5 zu benutzen. Das RPM-Paket, das man hier findet, beinhaltet allerdings nur die Userspace Programme - das Kernelmodul muß man trotzdem selber u ¨ bersetzen. Das von uns benutzte Testsystem l¨ auft unter RedHat 8.0, wobei die als ”Server” bezeichnete Installation gew¨ ahlt wurde. Zus¨ atzlich 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¨ oglichkeit er¨ offnet, einen Blick in die Datei ”INSTALL” zu werfen (das sei u ¨ brigens jedem empfohlen !). Hierbei fällt bald auf, dass der Makefile vier Möglichkeiten bereith¨ alt, wobei in jedem Fall zuerst automatisch mit Hilfe des Pakets ”patch” die Ver¨ anderungen im Baum der Kernelquellen vorgenommen werden: • make menugo - Wer diesen Weg w¨ ahlt, 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 u ¨ ber make menugo an. • make xgo - Das gleiche wie ”menugo” nur dieses mal im graphischen Modus unter X11. • make ogo - F¨ ur 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

283

• make oldgo - ”oldgo” entspricht make oldconfig und u ¨ bernimmt die aktuelle Kernelkonfiguration aus “.config” und wählt alle IPsec Optionen aus, wobei IPsec selber als Modul ipsec.o u ¨ bersetzt wird. Befindet sich auf dem System schon ein fertig konfigurierter Kernel oder hat der Administrator keine Lust alles neu zu u ¨ 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¨ urlich 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¨ ugung. Hier sei nur kurz auf deren Bedeutung eingegangen. Weitere Details sind dem entsprechenden RFC2402 zu entnehmen. ¨ Ubersicht nach make mengo im Bereich ”Networking options”: 01 02 03 04 05 06 07 08 09 10

IP Security Protocol (FreeS/WAN IPSEC) --- IPSec options (FreeS/WAN) [*] IPSEC: IP-in-IP encapsulation (tunnel mode) [*] IPSEC: Authenticbation Header [*] HMAC-MD5 authentication algorithm [*] HMAC-SHA1 authentication algorithm [*] IPSEC: Encapsulating Security Payload [*] 3DES encryption algorithm [*] IPSEC: IP Compression [*] IPSEC Debugging Option

In der Zeile ”1” wird IPsec als Kernelmodul f¨ ur den aktuellen Kernel generiert. Es wäre auch m¨ oglich es fest einzubinden f¨ ur 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¨ usselt werden, sondern die Linuxmaschinen an den Tunnelenden als Verschl¨ usselungsgateway f¨ ur 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¨ at von Informationen zu u ufen, die u ¨ berpr¨ ¨ber ein unsicheres Medium u ¨ 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¨ ugt das Transportprotokoll ESP hinzu, welches zum Beginn des Abschnitts erklärt wurden. Die Verschl¨ usselung nach tripple-DES - ebenfalls wichtig f¨ ur die Anbindung an eine SonicWall Pro- wird in Zeile ”8” zur Verf¨ ugung gestellt. Zeile ”9” erlaubt das Einschalten ¨ von Kompression im VPN; was vor allem Geschwindigkeitsvorteile bei der Ubertragung normaler ungepackter Dateien, jedoch auch Overhead bei bereits komprimierten Daten mit 6

in /usr/src/linux/ rufe man make modules install auf

284


sich bringt. Kompression geht aber auf Kosten der CPU und muss bei der Kalkulation der Leistung der Verschl¨ usselungsgateways eingerechnet werden. ”klipsdebug” option: Ohne diesen Schalter gibt es kein Debugging. Es ist n¨ utzlich, wenn alles funktioniert, aber von Nachteil, wenn eine Verbindung aus unbekannten Gr¨ unden 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: echo00 000 >/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¨ ur die einzelnen Verschl¨ usselungstunnel 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¨ ur 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-LOSUNGEN # #

285

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

18.6.1

Cisco-VPN

An vielen Universit¨ aten 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¨ osung handelt es sich um eine zentrale Hardwarekomponente der Cisco VPN3000-Serie. Diese agiert als Verschl¨ usselungs- und Authentifizierungs- Gateway f¨ ur 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¨ ur 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¨ ur 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 u ussen die passenden Kernelsources installiert ¨ bersetzen, m¨ 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¨ ur die erzeugten ausf¨ uhrbaren Dateien (das betrifft die Programme vpnclient, cisco cert mgr, cvpnd und ipseclog) anzugeben und die Autostartoption - f¨ ur das Laden des notwendigen Kernelmoduls - festzulegen. Weiterhin wird das Verzeichnis f¨ ur die Kernelsources ¨ abgefragt. Uberlichweise lassen sich die vorgeschlagenen Einstellungen direkt u ¨bernehmen. Am Ende des Installationsvorganges wird dringend dazu geraten die Zugriffsrechte f¨ ur 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¨ usselungsverbindung wird mittels des interaktiven Kommandozeilen-Tools (vpnclient connect) vpnprofile initiiert. ”vpnprofile” verweist auf eines der unterhalb des Cisco-Konfigurationsverezichnisses

286


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¨ usselungsgateway zugreifen. Mit der Option Username wird der eigene Benutzname eingetragen. Zus¨ atzlich kann man die Option UserPassword einf¨ ugen. Dort wird dann das entsprechende Passwort in Klartext abgelegt. Nach der ersten Verbindung wird dieses Passwort wieder gel¨ oscht und durch ein Versch¨ usseltes ersetzt, das gleiche passiert beim Gruppenpasswort. Wenn der Cisco VPN-Client auf einem Rechner betrieben werden soll, der hinter einer Firewall liegt, muss daf¨ ur gesorgt sein, dass alle f¨ ur 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¨ ur alle Profile gemeinsam verwendete Konfigurationsdatei (vpnclient.ini), welche den Umfang der geschriebenen Log-Informationen und die Lage der ausf¨ uhrbaren 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 u ¨blichen Linux-Tools (ifconfig,

¨ 18.6. KOMMERZIELLE VPN-LOSUNGEN

287

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¨ usselung 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¨ usselte, in die andere Richtung unverschl¨ usselte Datenpakete angezeigt. Das hängt wohl damit zusammen, dass sich das Kernelmodul sehr tief einklinkt, um bei Bedarf den Datenverkehr u ¨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 u ¨berschreiben. Das Verbot eines LAN-Zugriffes und damit implizit das Aufsetzen eines MasqueradingRouters kann zentral vom Verschl¨ usselungsgateway erzwungen werden, in Abhängigkeit davon, wie der zust¨ andige 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¨ usseltungstunnel aktiv ist. Dieses mag zwar f¨ ur spezielle Road-Warrior-Einsätze nicht von Bedeutung sein, kann aber in anderen Szenarien f¨ ur gewaltigen Overhead sorgen, wenn alle Daten ausnahmslos u ¨ 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¨ usselungsverbindung u ur beide Probleme ¨ber diese Interfaces unmöglich. Abhilfe f¨ ¨ schafft ein Blick in den Code. Ob die vorgeschlagenen Anderungen auch mit der CiscoLizenz vereinbar sind, muss der Anwender jeweils f¨ ur sich klären. ¨ Jedoch kann durch einige Anderungen 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

288


*************** 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 u on, dass Cisco diesen Standard einhält). ¨ bliche ”–help” funktioniert; sch¨ 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¨ ochte, sollte nach dem Profil noch seinen Usernamen u ¨bergeben. Man kann auch noch das Passwort u ¨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 Benutzernamen und Passwort in der Profildatei speichen, was aber serverseitig (!) unterbunden werden kann. Wie sinnvoll das ist, bleibt dahingestellt wenn man die oben genannte Sicherheitsl¨ ucke in Betracht zieht. Der Aufruf von vpnclient connect user f¨ uhrt letztendlich zu: Cisco Systems VPN Client Version 3.7 (Rel) Copyright (C) 1998-2002 Cisco Systems, Inc. All Rights Reserved.

¨ 18.6. KOMMERZIELLE VPN-LOSUNGEN

289

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¨ uhrt in diesem Beispiel also DirectNAT durch. In diesem Fall sieht man, dass ”local LAN” ausgeschaltet wurde. Das allerdings nicht anhand der Profildatei sondern von Seiten des Administrators auf dem Cisco3000. Aber was solls, interceptor.c macht einiges möglich ! Wenn man sich nun in einem Netz hinter einer Firewall befindet und das VPN-Gateway den Rechner selber direkt nicht erreicht kann, kommt ”NAT passthrough” ins Spiel. Das Ergebnis sieht dann folgendermaßen aus: IPSec tunnel information. Client address: 134.76.n.n Server address: 134.76.n.n Encryption: 168-bit 3-DES Authentication: HMAC-MD5 IP Compression: None NAT passthrough is active on port UDP 10000 Local LAN Access is enabled disconnect Diese Option ist schnell erklärt: vpnclient disconnect beendet eine bestehende Verbindung. stat Was man im Hause Cisco ”Statistik” zu nennen scheint, hat den Namen eigentlich nicht verdient: IPSec tunnel information. Connection Entry: goemobile Client address: 134.76.n.n Server address: 10.100.n.n Encryption: 168-bit 3-DES Authentication: HMAC-MD5 IP Compression: None NAT passthrough is inactive Local LAN Access is enabled

290

KAPITEL 18. SICHERES IP VPN traffic summary. Time connected: 0 day(s), 00:09.31 Bytes in: 84443 Bytes out: 115760 Packets encrypted: 816 Packets decrypted: 671 Packets bypassed: 19 Packets discarded: 7 Configured Secured * *

routes. Network Destination 10.100.n.n 0.0.0.0

Netmask 255.255.255.255 0.0.0.0

Local

Network Destination 10.100.n.n

Netmask 255.255.0.0

Bytes 0 157753

Neben dem vpnclient Werkzeug existiert ein nettes kleines Programm zum Schreiben von Logfiles. Dessen Verwendung ist zwar etwas ungewöhnlich, aber das Prinzip funktioniert. Bevor man sich entscheidet, einen Logfile schreiben zu lassen (eigentlich unklar, warum nicht gleich an den syslogd u ¨bergeben wird), kann man entscheiden, was und wieviel man mitschreiben lassen m¨ ochte. Die Einstellungen hierzu muss man in der Datei: /etc/CiscoSystemsVPNClient/vpnclient.ini vornehmen. Die Variable ”EnableLog” muss zum erfolgreichen Logging auf 1 gesetzt sein. Die einzelnen Optionen sind relativ gut selbsterklärend. Dabei ist ein hoher ”level” mit ausf¨ uhrlichen 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¨ urftig ist, aber den Zweck erf¨ ullt. 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¨ utzlich 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¨ ussen um einiges besser gegen Mitlesen des Datenverkehrs abgesichert werden, als drahtgebundene Installationen. Die Ausbreitung der Funkwellen läßt sich bei weitem nicht so gut u ¨ 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, u ¨ber das die Teilnehmer nach dynamischer IP-Zuweisung per DHCP einen Verschl¨ usselungstunnel u ¨ ber den Cisco-Router aufbauen und erst so in das ”rich¨ tige” Netz kommen. Die Maschine bildet den einzigen Ubergang und u ¨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¨ ur unterschiedliche Clients, die recht bequem zu benutzen ist. Die Lizenzgeb¨ uhren

18.7. LITERATUR

291

werden u ¨ber die Anschaffung der Hardware7 fällig, die Clients können in beliebiger Zahl benutzt werden. Ein ähnliches Szenario ergibt sich durch die Anbindung von Aussendienstmitarbeitern u ber das unsichere Internet: Sie k¨ onnen 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¨ ur sich selbst festlegen. Stellt man keine besonderen Anforderungen, dann ist der Einsatz der Originalsoftware die einfachere Wahl (besonders da, wo keine Extrakosten f¨ ur 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¨ usseln unabh¨ angig von den auf dem jeweiligen Rechner arbeitenden Usern. Der CiscoClient arbeitet mit userbasierten Credentials, die unabhängig von der darunterliegenden Hardware funktionieren. Im klassischen Road-Warrior-Einsatz spielt dieser Unterschied keine wesentlich Rolle, da Maschine und Benutzer identisch sind. Vom Einsatzszenario eignet sich der vorgestellte Cisco-Client nur f¨ ur den Road-Warrior oder den Rechner im lokalen Netz, die kaum Daten miteinander austauschen, da der gesamte Verkehr jeweils u ¨ber das Cisco-IPsec-Gateway abgewickelt wird. Von der Konzeption her bietet sich deshalb das hier vorgestellte Modell nicht daf¨ ur an, Verschl¨ usselungstunnel f¨ ur ganze Netze einzelner Betriebsteile zu bauen. Hierf¨ ur gibt es entweder spezielle Hardware, die diese Aufgabe besser erf¨ ullen kann oder die GPL-basierten Verschl¨ usselungstunnel CIPE oder FreeSWAN. Am Ende bleibt die Frage nach der Sicherheit der Cisco-VPN-Lösung. Der entscheidende Code liegt im Bin¨ arformat vor und kann nicht von jedermann eingesehen werden. ¨ Ein weiteres Problem zeigt sich mit der ”Offnung” 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 ¨ argerlich, weil die Standardtools nicht in der gewohnten Weise eingesetzt werden k¨ onnen.

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

292


Kapitel 19

Drahtlose Netzwerke 19.1

Funk-Netze

Funknetze sind komplexer im Zugriff als drahtgebundene LANs. Anders als bei geswitchtem Ethernet teilen sich Netzteilnehmer ein gemeinsames Medium. Das macht die Problematik vergleichbar mit dem klassischen 10Base2 oder 10Base5 Ethernet. Anders als im KoaxialKabel, wo jede Station die Datenaussendung jeder anderen mitbekommt, kann die begrenzte Reichweite von einzelnen Teilnehmern und Stationen im Funknetz verhindern, dass ein u oglich ist oder stark erschwert wird. Zusätzlich soll eine ¨ bergreifendes Signalerkennen m¨ Bewegung zwischen verschiedenen Zellen ermöglicht werden. Diese Fähigkeit von Netzen wird als Roaming bezeichnet.

19.2

¨ Uberblick WLAN-Standards

Die große Verbreitung verdanken Funknetze ihrer Standardisierung. Den meisten sind die Standards b, g und und seit einiger Zeit auch a und h ein Begriff. Diese beschreiben ¨ Ubertragungsverfahren und maximal erreichbare Bruttobandbreiten. Daneben existieren eine Reihe weiterer Standards, die sich mit Fragen der Sicherheit des Hand-Overs und ahnlichem befassen. ¨ Drahtlose Netzwerke, engl. Wireless Local Area Networks (WLAN) basieren zumeist auf dem 1997 vom IEEE definierten Standard IEEE 802.11. Um den heutigen Anforderungen zu entsprechen, wurde und wird der Standard ständig erweitert, die einzelnen Protokolle sind in der nachfolgenden Tabelle aufgelistet. Alle Bandbreitenangaben beziehen sich auf ein ”Shared Medium”, d.h. bei steigender Teilnehmerzahl steht dem einzelnen eine niedrigere Datenrate, vergleichbar mit Ethernet u ugung. Die nutzbare ¨ ber Koaxialkabel, zur Verf¨ Bandbreite hängt also von den Teilnehmern pro Funkzelle ab. Es ist jedoch bei geeigneter Frequenzaufteilung m¨ oglich, mehrere Zellen geografisch parallel zu betreiben.

19.2.1

Betriebsmodi

Es gibt grunds¨ atzlich zwei Modi, in denen ein WLAN betrieben werden kann, je nachdem ob eine Basisstation vorhanden ist oder nicht: Ad-hoc-Modus Im sog. Ad-hoc-Modus, auch Peer-to-Peer genannt, kommunizieren zwei oder mehr Ger¨ ate direkt miteinander. Die Topologie eines solchen Ad-hoc-Netzes heisst Independent Basic Service Set (IBSS). Jede Maschine bildet mit ihrer Netzwerkkarte eine Funkzelle. Solange sich die Stationen in einer Zelle befinden oder sich die Zellen u ¨ berschneiden, 293

294

KAPITEL 19. DRAHTLOSE NETZWERKE Standard Beschreibung ¨ 802.11 Protokoll und Ubertragungsverfahren f¨ ur drahtlose Netze, zunächst nur bis 2 MBit/s bei 2,4 GHz definiert. 802.11a WLAN mit bis zu 54 MBit/s im 5 GHz-ISM-Band, zwölf nichtu ale, Modulation: OFDM. ¨ berlappende Kan¨ 802.11b WLAN mit bis zu 11 MBit/s im 2,4 GHz-ISM-Band, 3 nichtu ale. ¨ berlappende Kan¨ 802.11c Wireless Bridging zwischen Access Points. 802.11d World Mode - Anpassungen an regionale Regulierungen: Zuerst f¨ ur den US-Markt entwickelt, wurden mit dieser Erweiterung regionale Besonderheiten (z.B. Frequenzbereich) ber¨ ucksichtigt. 802.11e Quality of Service (QoS) & Streaming: Priorisierung von Datenpaketen beispielsweise f¨ ur Multimedia-Anwendungen und Voice-over-IP. 802.11f Roaming zwischen Access Points verschiedener Hersteller. 802.11g 54 Mbit/s-WLAN im 2,4 GHz-Band, Modulation: OFDM. Dieser Standard spielt derzeit die größte Rolle. 802.11h Erg¨ anzungen zum 802.11a f¨ ur Europa: Dynamic Frequency Selection und Transmit Power Control. 802.11i Authentifizierung & Verschl¨ usselung: AES, 802.1X und EAP (erg¨ anzend/aufbauend auf WEP und WPA). 802.11j Japanische Variante von 802.11a f¨ ur den Bereich 4,9 GHz - 5 GHz. 802.11k Bessere Messung/Auswertung/Verwaltung der Funkparameter (z.B. Signalst¨ arke), soll z.B. ortsbezogene Dienste (Location Based Services) erm¨ oglichen. 802.11m Zusammenfassung fr¨ uherer Ergänzungen, Bereinigung von Fehlern aus vorausgegangenen Spezifikationen (Maintenance). 802.11n Geplante Erweiterung f¨ ur ein schnelleres WLAN mit 108 Mbit/s bis 320 MBit/s. Tabelle 19.1: WLAN-Standards

ist eine Kommunikation zwischen den Stationen möglich. Der Vorteil besteht darin, dass man keine (teure) Basisstation braucht. Diese Art der Vernetzung ist f¨ ur ein WLAN mit IEEE 802.11 aber eher un¨ ublich und mit anderen Techniken, wie Infrarot oder Bluetooth, schneller realisiert. Infrastruktur-Modus In diesem Modus1 erfolgt die Kommunikation der Geräte (Clients) u ucke, den sogenannten Access Point (AP) oder Basisstation. ¨ ber eine zentrale Funkbr¨ ¨ Uber diesen Access-Point erfolgt auch die Verbindung (Bridgeing) in kabelgebundene LANSegmente. Der Access Point erlaubt es sogar, Protokolle, die das WLAN unnötig u ¨ berlasten w¨ urden, herauszufiltern. Die Topologie eines solchen Netzwerkes mit Basisstation nennt man Basic Service Set (BSS). Mittels mehrerer APs lässt sich die Reichweite eines LAN erhöhen, beispielsweise u aude- und Grundst¨ ucksgrenzen hinweg, ohne dass aufwendige Infra¨ber Geb¨ strukturmassnahmen anfallen. Diese Topologie heisst Extended Service Set (ESS). In einem solchen agieren zwei oder mehreren Basic Service Sets. Innerhalb des ESS können die Stationen frei ihren Standort ¨ andern. Ein Roaming-Verfahren hält die Netzwerkverbindung zu den Access Points aufrecht. 1

vielfach auch als Managed-Mode bezeichnet

19.3. PHYSIKALISCHE GRUNDLAGEN

295

Es gibt seit einiger Zeit noch eine andere Möglichkeit, die Verbindung in kabelgebundene LAN-Segmente oder andere drahtlose Netze ohne Kabeleinsatz herzustellen: Wireless Distribution System - Ein WDS funktioniert so ähnlich wie das ESS. Bei WDS-Verbindungen wird mit zus¨ atzlichen Basisstationen die Reichweite der eigenen Funkzelle erhöht. WDS kann man als eine Repeater-Funktion verstehen. WDS kann zwei Modi drahtloser Verbindungen bereitstellen: • Wireless Bridging - Es kommunizieren nur die WDS-APs miteinander, es sind keine Clients zugelassen. • Wireless Repeating - Es kommunizieren die WDS-APs sowohl untereinander als auch mit Clients.

19.3

Physikalische Grundlagen

Der Standard beschreibt im wesentlichen nur die MAC-Teilschicht und die physikalische Schicht des OSI-Referenzmodells. Er wurde f¨ ur den Betrieb mit verschiedenen physikalischen Medien ausgelegt, wobei eines auf Infrarot¨ ubertragung basiert. Die Infrarot¨ ubertragung hat eine begrenzte Reichweite von ca. 10m und ist auf die Anwendung innerhalb von Gebäuden ausgelegt. Es sind bei diesem Verfahren zwei Geschwindigkeiten zulässig, 1 Mbps und 2 Mbps. Sender und Empf¨ anger m¨ ussen dabei nicht aufeinander ausgerichtet sein, sie benötigen keine direkte Sichtverbindung, was sich aber in der erzielbaren Datenrate niederschlägt. Da Infrarotsignale keine W¨ ande durchdringen können, lässt sich hierdurch leicht eine räumliche Trennung von Zellen einrichten. Die MAC-Teilschicht im IEEE 802.11-Standard spezifiziert Merkmale wie das Pr¨ ufsummenverfahren Cyclic Redundancy Code (CRC), Fragmentierung, Auto-Roaming-Verfahren, Authentifizierung und die WEP-Verschl¨ usselung. Logical Link Control (LLC) ist ein Protokoll, das auf allen 802-Protokollen f¨ ur die Sicherungs-Schicht aufsetzt. Es stellt ein universelles Format und eine einzige Schnittstelle zur Vermittlungsschicht f¨ ur alle Arten von 802-Netzwerken zur Verf¨ ugung und sorgt dadurch daf¨ ur, dass die jeweiligen Unterschie¨ de verborgen bleiben. Es ist f¨ ur Ubertragungssteuerung, Fehlersicherung, -erkennung und -korrektur zust¨ andig. Das Physical Layer Convergence Protocol (PLCP) verbirgt die tech¨ nischen Einzelheiten der konkreten Ubertragung vor der dar¨ uberliegenden Schicht (MAC) ¨ und sorgt daf¨ ur, dass Kanalzugriff von den eingesetzten Ubertragungsverfahren unabhängig ¨ sind. Darunter liegen dann die unterschiedlichen Ubertragungsverfahren mit ihren speziellen Eigenschaften. Alle in Deutschland zugelassenen WLAN-Systeme benutzen spezielle Frequenzbänder. Diese sind offiziell f¨ ur industrielle und andere Zwecke reserviert und lizenzfrei f¨ ur jedermann nutzbar. Diese B¨ ander geh¨ oren zu den sogenannten Industrial Scientific Medical-Bands (ISM). Die derzeit am meisten verbreiteten Funktechniken arbeiten zwischen 2,400 GHz und 2,483 GHz. Sie u ugbaren Frequenzen mit ¨bertragen durch Nutzung eines Teils der darin verf¨ Bruttodatenraten von 2 Mbps (802.11), 11 Mbits (802.11b) u ¨ ber 22 Mbits (802.11b+) und 54Mbits (802.11g) bis zu 108 Mbits und mehr. Der Standard 802.11a2 beschreibt Systeme, die im 5 GHz-Band betrieben werden und Datenraten von 54 Mbps aufw¨ arts erm¨ oglichen. Im 5 GHz-Band steht ein grösseres Frequenzband zur Verf¨ ugung - und damit mehr Kanäle. In Deutschland sind in diesem Bereich insgesamt 19 Kan¨ ale in einem Abstand von 20 MHz freigegeben worden. 2

es gibt spezielle Erweiterung f¨ ur Europa: 802.11h und Japan 802.11j

296

KAPITEL 19. DRAHTLOSE NETZWERKE

Durch die hohe Kanalbandbreite von 20 MHz werden direkt benachbarte Kanäle nicht gestört. Anders als die allgemeinen ISM-Bändern ist es ausschliesslich f¨ ur WLANs reserviert. Da Funk-LAN-Produkte speziell f¨ ur den Einsatz in B¨ uros und anderen Arbeitsumgebungen entwickelt wurden, senden sie mit einer entsprechend niedrigen Leistung. Diese Leistung liegt unter einem maximalen Wert von 100 mW und damit beispielsweise deutlich unter der Sendeleistung von gebr¨ auchlichen GSM-Telefonen3 .

19.3.1

Verbesserte Anpassung

Aus den Erfahrungen mit der weiten Verbreitung und der daraus resultierenden Probleme, wie gegenseitiges St¨ oren, ineffiziente Nutzung des Mediums ”Luft” wurden auch speziell f¨ ur die Bestimmungen in Europa und Japan Erweiterungen des a-Standards definiert: Transmit Power Control (TPC) und Dynamic Frequency Selection (DFS). Als Teil dieses Standards sollen TPC und DFS sicherstellen, dass ein WLAN nicht mit anderen kritischen Bereichen im 5 GHz-Band kollidiert. TPC soll daf¨ ur sorgen, dass die Sendeleistung nur so weit reicht, wie es f¨ ur den Betrieb einer jeden Funkzelle jeweils notwendig ist. Dabei wird ständig u uft, ob im aktuellen Frequenzbereich sonstiger Verkehr herrscht und ggf. per DFS ¨ berpr¨ auf einen anderen Kanal gewechselt. In Deutschland wurden von der Regulierungsbehörde REGTP zwei Frequenzbereiche ¨ speziell ausgezeichnet: Im Bereich von 5,15 GHz bis 5,35 GHz sind Ubertragungen mit Sendeleistungen bis maximal 200 mW nur im Inneren von Gebäuden gestattet. Im Bereich von ¨ 5,47 GHz bis 5,725 GHz sind Ubertragungen bis maximal 1000 mW sowohl im Innen- als auch Aussenbereich erlaubt.

19.3.2

Modulationsverfahren

¨ Die Daten- sowie die Steuersignale m¨ ussen den Eigenschaften des Ubertragungsmediums ¨ angepasst werden, um eine Ubertragung erst zu ermöglichen. Dazu dient die Modulation der Daten auf elektromagnetische Wellen. Da auch Wellen anderer Quellen die lizenzfreien Frequenzb¨ ander nutzen, ist mit Konkurrenz zu rechnen und es m¨ ussen entsprechende Vorkehrungen getroffen werden. Bei WLAN-Standards sind verschiedene Modulationsverfahren vorgesehen, die nach dem Bandspreizverfahren (Spread Spectrum (SS)) arbeiten. Dabei wird das Funksignal u ¨ ber ein möglichst breites Frequenzspektrum aufgeteilt. Diese Methode erschwert das Abhören des Funksignals ohne WLAN-Equipment und der Einfluss von Störungen wird verringert. Frequency Hopping Spread Spectrum Beim Frequency Hopping Spread Spectrum (FHSS) nutzen Sender und Empf¨ anger im 2,4 GHz-Band 79 Kanäle mit jeweils 1MHz Bandbreite. Die Datenpakete werden dazu in kleine Päckchen aufgeteilt. Das sogenannte Frequenzsprungverfahren (Frequency Hopping (FH)) moduliert das Signal auf ein ständig die Frequenz wechselndes Tr¨ agersignal. Der Frequenzwechsel ist dabei nicht wirklich zufällig, nach einem durch einen Pseudozufallszahlen-Generator erzeugten Zufallsmuster (HoppingSequenz) werden die Kan¨ ale gewechselt. Die vorgegebene Mindestsprungdistanz beträgt sechs Kanäle, also 6 MHz. Insgesamt l¨ asst sich dieser Frequenzbereich mit 26 Teilnehmern ¨ betreiben, ohne dass sie sich die Ubertragungsrate teilen m¨ ussen. Diese Technik ist sehr anfällig gegen St¨ orungen, vor allem dann, wenn gestörte Frequenzen aus dem Sprungmuster ¨ ausgelassen werden. Sollten auf einem Kanal zwei Ubertragungen miteinander kollidieren, 3

ca. 1 W bei Ger¨ aten, die im Frequenzbereich 880-960 MHz (D-Netze) arbeiten und 2 W in den E-Netzen


297

werden diese Datenpakete einfach nochmal u ¨ bertragen. Da die Kollisionen in einem Funknetz nicht erkannt werden k¨ onnen, kommt ein Verfahren zur Kollisionsvermeidung zum Einsatz4 . FHSS ist relativ kosteng¨ unstig und stromsparend, was bei kleinen mobilen Endgeräten ein grosser Vorteil ist. Der enorme Verwaltungsaufwand bei den Frequenzspr¨ ungen dr¨ uckt jedoch auf die Nutzdatenrate und verkompliziert das Roaming zwischen mehreren Access Points. Ausserdem hat es nur eine begrenzte Reichweite. Frequency Hopping hat noch einen entscheidenden Nachteil. Es lassen sich damit nur maximal 2 Mbits erreichen. Direct Sequence Spread Spectrum Das Direct Sequence Spread Spectrum (DSSS) fasst die 79 schmalbandigen Kan¨ ale in mehrere breitbandige Kanäle zusammen. Die Kanäle von 802.11b und ihre Frequenzen sind in der Grafik aufgef¨ uhrt. Die Abstufung erfolgt in Schritten von 5 MHz (ausgenommen Kanal 14)5 . Demgegen¨ uber arbeitet 802.11a/h in den Frequenzbereichen von 5,15 bis 5,35 GHz und von 5,47 bis 5,725 GHz (Europa und USA). 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 19.1: Kanalaufteilung Diese Kan¨ ale sind allerdings eng aneinander gereiht und u ¨berlappen sich sogar. Bei einer Kanalbandbreite von ca. 22 MHz können jedoch nur maximal drei Kanäle gleichzeitig u ¨ berlappungsfrei genutzt werden. Bei der Konfiguration einer oder mehrerer Basisstationen muss darauf geachtet werden, dass die Kanäle nicht zu dicht beieinander liegen, um eine ¨ ungewollte Uberlappung zu vermeiden. ¨ ¨ Uberlappung f¨ uhrt zu einer geringeren Ubertragungsrate. Es wird empfohlen, mindestens f¨ unf Kan¨ ale als Abstand zueinander einzuhalten. Wird ein Access Point auf einen Kanal eingestellt, so versorgt er damit eine Funkzelle (räumliche Ausbreitung der Funksignale). ¨ Innerhalb der Funkzelle garantiert er eine festgelegte Ubertragungsrate. Alle Teilnehmer in ¨ dieser Zelle, die auf denselben Kanal eingestellt sind, m¨ ussen sich diese Ubertragungsrate teilen. Diese Situation l¨ asst sich gut mit einem klassischen ”Shared Medium” wie dem alten BNC-Ethernet vergleichen. ¨ Rutscht ein Teilnehmer an den Rand der Funkzelle, wo die Ubertragungsrate nicht 4

spezielles CSMA/CA Es gibt regionale Besonderheiten: In den USA sind die Kan¨ ale 1 - 11 verf¨ ugbar, in Europa sind es die Kan¨ ale 1 - 13 und in Japan kann Kanal 14 benutzt werden. 5

298


mehr eingehalten werden kann, oder wird sonstwie gestört, regelt die Basisstation die ¨ ¨ Ubertragungsrate f¨ ur alle Teilnehmer gleichzeitig herunter. Zur Ubertragung des Signals wird es mittels einer Modulo-2-Multiplikation auf die Spreizbandbreite gespreizt. Die Spreizung erfolgt mit einem St¨ orcode, dem Pseudo-Noise-Code, der vor der Signal¨ ubertragung ausgehandelt wird. Dazu werden dem Originalsignal mehrere Bit, die sogenannten Chips, aufmoduliert und anschliessend mit dem Trägersignal multipliziert. Das Signal wird auf die Gesamtbandbreite gespreizt und verschwindet im Rauschen. Der Empfänger kehrt diesen Prozess um. Er multipliziert das empfangene Signal mit den Spreizsignalen (Pseudo-NoiseCode), d.h. er entspreizt das empfangene Signal. Anschliessend werden durch einen Tiefpassfilter die unerw¨ unschten schmalbandigen Störungen herausgefiltert. Das gew¨ unschte Signal bleibt dabei u ¨brig. High Rate Direct Sequence Spread Spectrum Das HR-DSSS-Verfahren unterst¨ utzt ¨ Ubertragungsraten von bis zu 11 Mbits auf dem 2,4 GHz-Band. Diese Technik wird f¨ ur IEEE 802.11b verwendet. Man u uckt damit grössere Distanzen mit einer schnelleren ¨berbr¨ Daten¨ ubertragungsrate als mit FHSS oder DSSS. Die Reichweite ist ca. siebenmal grösser als die von IEEE 802.11a. Orthogonal Frequency Division Multiplexing (OFDM) F¨ ur die schnelleren Standards IEEE 802.11a und 802.11g wurde ein neues Mehrträger-Modulationsverfahren eingef¨ uhrt, das Orthogonal Frequency Division Multiplexing (orthogonales FrequenzmultiplexVerfahren), um bis zu 54 Mbits zu erreichen. Dabei arbeitet IEEE 802.11a im breiteren 5 GHz-ISM-Band, w¨ ahrend IEEE 802.11g als schnellere Variante des 802.11b-Standards auf dem 2,4 GHz-ISM-Band implementiert ist. Bei diesem Verfahren werden 52 verschiedene Frequenzen verwendet, wobei vier f¨ ur die Synchronisation benötigt werden. Die Aufteilung des Signals in viele schmale B¨ ander weist neben der geringeren Anfälligkeit gegen Schmalbandst¨ orungen erhebliche Vorteile auf. Zum Beispiel m¨ ussen nicht direkt benachbarte Bänder verwendet werden. Es werden zwei unterschiedliche Modulationsverfahren eingesetzt: F¨ ur Geschwindigkeiten bis 18Mbps wird auf Basis einer Phasenverschiebungsmodulation, bei höheren Geschwindigkeiten bis 54 Mbps mittels Quadratur-Amplitudenmodulation codiert.

19.3.3

Kollisionsvermeidung

Bei der Funkdaten¨ ubertragung teilen sich die angeschlossenen Stationen ebenso wie beim 10Base2 oder 5 Ethernet dasselbe Medium. Ein WLAN hat aber andere physikalische Eigenschaften als ein konventionelles Koaxialkabel. Daher benötigt es spezielle Protokolle auf der MAC-Teilschicht. Bei Ethernet wartet ein angeschlossener Rechner, falls die Leitung belegt ist, und sendet erst dann, wenn sie frei wird. Im Fall einer Kollision wartet er erneut und sendet die Daten zu gegebener Zeit nochmal. Bei drahtlosen Netzwerken funktioniert dies so nicht. Hier gibt es spezielle Probleme mit der räumlichen Ausdehnung der Funkwellen. Ein Sender kann bei einer drahtlosen Daten¨ ubertragung nicht so einfach eine Signalkollision mit anderen Sendern feststellen. Zum einen werden die Funkwellen von Hindernissen wie Mauern reflektiert bzw. blockiert, so dass man sicherstellen muss, dass die richtigen Daten zum richtigen Zeitpunkt erhalten und decodiert werden. Zum anderen gibt es Probleme, die mit der Reichweite zusammenh¨ angen. Dadurch ergeben sich zwei charakteristische Probleme. 1. Das Hidden-Station-Problem - Da die Reichweite der einzelnen Stationen begrenzt ist, können sie nicht alle im gegenseitigen Sendebereich liegen. So kann eine Station 4 nicht h¨ oren, dass eine Station 2 im Empfangsbereich von 3 bereits Daten von einer


299

Reichweite jeder Station

1

2

3

4

Abbildung 19.2: Sichtbarkeits- oder Hidden-Station-Problem weiteren Station 1 empf¨ angt, die ausserhalb des Bereichs von 4 liegt und daher nicht sichtbar ist. Wenn 4 den Kanal pr¨ uft und auf ihrer Seite keinen Verkehr feststellt, beginnt 4 an 3 zu senden, was zu Kollisionen mit den Daten von 2 f¨ uhrt. (Siehe Abb. 19.3.3 2. 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¨ urde. Auf diese Weise wird Bandbreite verschenkt: ”Exposed Station Problem”. Um die beschriebenen Probleme in den Griff zu bekommen, wird ein MAC-SublayerProtokoll implementiert. Damit wird ein einheitliches Netz u ¨ber verschiedene Sender möglich. Ein naiver Ansatz w¨ are Verwendung des CSMA/CD-Verfahrens, wie es beim drahtgebundenen Ethernet geschieht. Der Standard 802.11 unterst¨ utzt zur Lösung des Hidden-Station-Problems sowie zur Kollisionsvermeidung zwei Modi, die entsprechend der Betriebsmodi eingesetzt werden. Im Ad-Hoc-Modus wird Distributed Coordination Function (DCF) verwendet. Das Verfahren ist dem Ethernet ¨ ahnlich. Bei DCF wird zur Vermeidung von Kollisionen das Protokoll CSMA with Collision Avoidance (CSMA/CA) verwendet, das eine physikalische und eine virtuelle Kanalpr¨ ufung unterst¨ utzt. Bei der physikalischen Pr¨ ufung hört eine Station, die ¨ Daten u stattfindet. ¨ bertragen will, erst den Kanal ab, ob dort eine laufende Ubertragung Ist dies nicht der Fall, sendet die Station die Daten, ohne währenddessen den Kanal zu u ufen. Wenn der Empf¨ anger St¨ orungen signalisiert, sendet die Station die Daten er¨ berpr¨ neut. Im Falle von Kollisionen warten die kollidierenden Stationen eine zufällige Zeit und versuchen es dann wieder. Die virtuelle Kanalpr¨ ufung basiert auf Multiple Access with Collision Avoidance for Wireless (MACAW). Sender und Empf¨ anger tauschen hierbei zuerst Steuer-Daten aus, ¨ bevor die eigentliche Ubertragung beginnt. Station 1 sendet ein Request To Send (RTS), um die Erlaubnis von 2 zu erhalten, Daten zu u ¨ bertragen. 2 antwortet mit einem Clear To Send ¨ (CTS), wenn dies gew¨ unscht ist. Nach Empfang des CTS beginnt 1 mit der Ubertragung und wartet dann auf eine Best¨ atigung. Sollte 2 die Daten korrekt empfangen haben, antwortet 2 mit einem Acknowledgment (ACK). Sollte 2 kein CTS senden, wartet 1 eine zufällige Zeit und versucht es dann nochmals mit einem RTS. Der zweite Modus heisst Point Coordination Function (PCF) und verwendet die Basisstation (Access Point) zur Steuerung der Aktivitäten im Bereich einer Zelle. Diese verwendet einen sog. Polling-Mechanismus, d.h. sie fragt die angemeldeten Stationen reihum ¨ ab, ob sie Daten senden wollen. Da die Ubertragungsreihenfolge vollständig von ihr kon-

300


trolliert wird, k¨ onnen keine Kollisionen auftreten. Die Basisstation sendet hierzu in periodischen Abst¨ anden ein sogenanntes Beacon-Frame in die Runde. Dieser Rahmen enthält verschiedene Parameter wie Frequenzsprungfolge, Verweilzeit, Taktsynchronisation und fordert gleichzeitig neue Stationen auf, sich f¨ ur das Polling anzumelden. Ist eine Station an¨ gemeldet, wird entsprechend der vereinbarten Ubertragungsrate ein bestimmter Teil der Bandbreite zur Verf¨ ugung gestellt, damit wird eine gewisse Dienstg¨ ute gesichert.

19.4

WLAN-Sicherheit

Ein wesentliches Problem haben WLANs gegen¨ uber ihren drahtgebundenen Pendants; sie sind sehr offen. Deshalb muss eine ganz andere Absicherung als bei drahtgebundenen Netzen erfolgen. Zur Sicherung der Verbindung wurde WEP (Wired Equivalent Privacy) eingef¨ uhrt. Es arbeitet mit 64 bzw. 128 Bit Schl¨ usseln. 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¨ ur sich anmeldende Geräte betrieben, die meist so konfiguriert sind, dass jeder Host eine Adresse erh¨ alt. Deshalb gibt es inzwischen eine Art Volkssport: WarDriving (oder WarChalking - Suchen nach offenen WLAN-Netzen).

19.5

WLAN unter Linux

Die Hardware-Auswahl im WLAN-Bereich ist inzwischen ziemlich groß. Neben der klassischen Verwendung in Laptop oder PDA gibt es nun auch eine Reihe Embedded Devices unter Linux, die WLAN-Komponenten verwenden. WLAN-Adapter sind deshalb in vielen verschiedenen Bau- und Anschlussformen erhältlich: • F¨ ur Laptops sind WLAN-Steckkarten f¨ ur die PCMCIA-Schnittstelle immer noch sehr verbreitet. Die Antenne steht meist einige Zentimeter aus dem Schacht heraus. Manche Steckkarten haben einen Anschluss f¨ ur eine externe Antenne. WLAN-CompactFlash sind Mini-Ausgaben f¨ ur den Compact-Flash-Slot. • Mini-PCI • PCI • USB • WLAN-Ethernet-Bridges

19.6

Bluetooth mit Linux

Es gibt verschiedene M¨ oglichkeiten Bluetooth-Devices mit einem Rechner zu verbinden. Die häufigste Variante verwendet USB, f¨ ur Laptops existieren auch PCMCIA-Einsteckkarten. Ein gut unterst¨ utzes Device ist der Blue-Fritz USB2.0, ein externes Dongle. Als SteckkartenGerät findet man die 3COM ”Bluetooth Wireless PC Card” in verschiedenen Versionen. Im folgenden wird die Arbeit mit der Version 2 beschrieben. Der Dongle funktioniert oft auf Anhieb und ohne Probleme, da die benötigte Firmware problemlos im Netz zum Download bereitsteht. Dongles haben jedoch den Nachteil, dass sie vom Laptop immer irgendwo abstehen.

19.6. BLUETOOTH MIT LINUX

301

Ein Vorteil einer PCMCIA-Karte ist oft die versenkbare Antenne. Das erleichtert den Transport mobiler Arbeitspl¨ atze erheblich. Der Aufwand mit der 3COM-Karte war leider deutlich h¨ oher. Da sich die Original-Treiber-CD nicht mehr in lesbarem Zustand befand,musste sich der Autor den Treiber (btpl1 len.exe) von der 3COM-Homepage laden und die Firmware geeignet nach Anleitung extrahieren: unzip -p btp1 1en.exe Drivers.W2k/BT3CPCC.bin > /etc/bluetooth/firmware/BT3CPCC.bin. Das Zielverzeichnis hängt von der eingesetzten Distribution ab. Der Bluetooth-Firmware-Loader muss in der Lage sein die Datei zu finden. Die Linux-Unterst¨ utzung f¨ ur Bluetooth-Devices ist inzwischen recht gut. Hier standen bis zum Einspruch seitens eines BSIG-Mitglieds Mitte März eine Reihe guter Anleitungen f¨ ur einzelne Bluetooth-Adapter. Diese m¨ ussen Sie sich jetzt wieder einzeln ”ergooglen”. Die Einrichtung von Bluetooth unter Linux besteht aus zwei Komponenten, der Unterst¨ utzung des Bluetooth-Stacks im Kernel und den Userspace-Programmen. Die meisten Kernel sind bereits f¨ ur Bluetooth eingerichtet. Ist dieses bei Ihrem nicht der Fall, können Sie es ohne Probleme nachholen. Im Kernel sollte auf jeden Fall Hotplug aktiviert werden: General setup ---> [*] Support for hot-pluggable devices Wenn Sie ein Notebook-Bluetooth-Adapter einsetzen, sollten Sie ebenfalls die PCMCIA/PCCard-Unterst¨ utzung im Kernel aktiviert haben. Je nach verwendeter Karte, sollten Sie die Datei /etc/pcmcia/config anpassen. F¨ ur die 3COM-Karte kamen die folgenden Einträge hinzu: device "bt3c_cs" module "bt3c_cs" card "3Com Bluetooth PC Card" version "3COM", "*", "Bluetooth PC Card" bind "bt3c_cs" Da der Bluetooth-Stack f¨ ur fast alle Adapter Firmware nachlädt, m¨ ussen Sie auch diese Option einschalten: Device Drivers/Generic Driver Options —> Hotplug firmware loading support Es gibt mehrere Implementierungen des Bluetooth-Protokolls. Inzwischen hat sich jedoch BlueZ gegen¨ uber den anderen durchgesetzt. Die Einstellungen finden sich unter Device Drivers/Networking support/Bluetooth subsystem support. Bluetooth darf daf¨ ur bei Devices/USB subsystem nicht aktiviert sein. Hier handelt es sich um einen alten TTY-only Stack. Anschliessend kompilieren und installieren Sie den neuen Kernel wie gewohnt. Die weiteren Bluetooth-Komponenten kommen meistens in mehreren Paketen. Mindestens die Hotplug-Skripten, die Bluetooth-Bibliotheken und die Utilities sollten Sie installieren: mobile linux # emerge -v sys-apps/hotplug mobile linux # emerge -v net-wireless/bluez-libs mobile linux # emerge -v net-wireless/bluez-utils

19.6.1

Bluetooth testen

Nach einem Neustart der Maschine - f¨ ur frisch gebaute Kernels notwendig - können Sie testen, ob Bluetooth funktioniert. Hierzu stecken Sie den Dongle oder die PCMCIA-Karte ein. Je nach Ger¨ at sehen Sie im Logfile eine Reihe von Meldungen: Mar 30 17:47:52 mobile usb 1-1: new full speed USB device using uhci_hcd and \

302


address 2 Mar 30 17:47:52 Mar 30 17:47:52 Mar 30 17:47:52 address 3 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:57 Mar 30 17:47:58 Mar 30 17:47:58 Mar 30 17:47:58 Mar 30 17:47:58 Mar 30 17:47:58 Mar 30 17:47:58

mobile hub 1-1:1.0: USB hub found mobile hub 1-1:1.0: 2 ports detected mobile usb 1-1.2: new full speed USB device using uhci_hcd and mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile mobile

Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.8 usbcore: registered new driver hci_usb hcid[1539]: Bluetooth HCI daemon hcid[1539]: HCI dev 0 up hcid[1539]: Starting security manager 0 Bluetooth: L2CAP ver 2.7 Bluetooth: L2CAP socket layer initialized sdpd[1542]: Bluetooth SDP daemon Bluetooth: RFCOMM ver 1.5 Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized

Wenn Sie nun das Kommando hcitool dev aufrufen, sollten Sie eine Ausgabe der folgenden Form erhalten: dirk@mobile gprs $ hcitool dev Devices: hci0 00:04:16:34:3D:F8 Ist irgendwas beim Initialisieren des Stacks oder beim Laden der Bluetooth-Module schief gegangen steht dort nur ”Devices:” oder die MAC-Adresse besteht lediglich aus Nullen. Nun können Sie Bluetooth auf Ihrem Mobiltelefon aktivieren und ”hcitool scan” ausf¨ uhren: dirk@mobile gprs $ hcitool scan Scanning ... 00:0E:07:47:93:1B BT-Phone Root-Rechte sind jeweils nicht erforderlich. Wenn alles glatt geht meldet sich nach einer gewissen Verz¨ ogerung mindestens ein Gerät. Damit sind die Grundvoraussetzungen f¨ ur die nächsten Schritte erf¨ ullt.

19.6.2

Kontakt aufnehmen

F¨ ur die weiteren Vorg¨ ange m¨ ussen die Bluetooth-Dienste laufen. Sie können diese unterhalb von /etc/bluetooth konfigurieren. Bis auf das gemeinsame Passwort, welches Sie in der Datei pin a¨ndern sollten, brauchen Sie normalerweise nichts anzupassen. F¨ ur das Passwort empfiehlt sich eines, welches Sie gut auf dem Mobiltelefon eingeben können. Die Dienste starten Sie mit ”/etc/init.d/bluetooth start”. Wenn Sie diese beim Start der Maschine automatisch hochfahren m¨ ochten, k¨ onnen Sie es unter Gentoo mit ”rc-update add bluetooth default” aktivieren. Der Autor bevorzugt jedoch den Weg u ¨ber die Hotplug-Agenten. Der passende Agent startet die Dienste beim Einstecken des Notebook-Adapters oder des USBDongles. Hierzu hat der Autor die Datei /etc/hotplug/bluetoot.agent angelegt und f¨ ur ”root” als ausf¨ uhrbar markiert. Wurde das Bluetooth-Device wieder entfernt, stoppt er die Dienste und entl¨ adt nicht mehr ben¨ otigte Kernelmodule.

19.7. AUFGABEN mobile linux # /etc/init.d/bluetooth start * Starting Bluetooth... * Starting hcid... [ ok * Starting sdpd... [ ok * Starting rfcomm... [ ok mobile linux # hciconfig hci0: Type: PCCARD BD Address: 00:04:76:C8:4A:E8 ACL MTU: 128:8 SCO UP RUNNING PSCAN ISCAN AUTH ENCRYPT RX bytes:1046 acl:0 sco:0 events:58 errors:0 TX bytes:850 acl:0 sco:0 commands:35 errors:0 mobile linux # l2ping 0:0E:07:47:93:1B Ping: 00:0E:07:47:93:1B from 00:04:76:C8:4A:E8 (data size 0 bytes from 00:0E:07:47:93:1B id 200 time 63.05ms 0 bytes from 00:0E:07:47:93:1B id 201 time 48.13ms 0 bytes from 00:0E:07:47:93:1B id 202 time 45.13ms 3 sent, 3 received, 0% loss mobile linux # hcitool cc 00:0E:07:47:93:1B mobile linux # hcitool dc 00:0E:07:47:93:1B

303

] ] ]

MTU: 64:8

20) ...

Wurden die Bluetooth-Dienste erfolgreich gestartet, sehen Sie mit ”hciconfig” die Daten Ihrer neuen Schnittstelle. Zum Test k¨ onnen Sie Ihr Mobiltelefon einfach mal mit l2ping u ¨ ber dessen MAC anpingen. Dann wird es Zeit die beiden Geräte zu ”pairen”. Dieses erlaubt anschliessend eine verschl¨ usselte Verbindung, andernfalls ist kein Datenaustausch möglich. Hierzu dient wieder das Kommando ”hcitool”, welches nun aber AdministratorRechte benötigt. Mit dem Parameter ”cc” bauen Sie eine Verbindung zu dem Gerät mit der MAC-Adresse 00:0E:07:47:93:1B auf. Die Adresse Ihres Telefons hatten Sie vorher durch einen ”scan” ermittelt. Kennt Ihr Mobiltelefon die Gegenstelle nicht, so fordert es Sie auf das Passwort einzugeben, welches Sie in /etc/bluetooth/pin gespeichert haben. Der Parameter ”dc” löst die Verbindung wieder. Anschliessend hat Ihr Telefon sich den Partner gemerkt. Dann brauchen Sie zum Verbindungsaufbau auch nur noch das Kommando ”rfcomm”. Wenn Sie den Rechnernamen nicht ¨ andern oder den Dongle austauschen, m¨ ussen Sie das Passwort nicht wieder eingeben. Im letzten Schritt bauen Sie nun eine virtuelle serielle Verbindung u ¨ ber die Bluetooth-Strecke auf: mobile root # rfcomm connect 1 00:0E:07:47:93:1B 1 Connected /dev/rfcomm1 to 00:0E:07:47:93:1B on channel 1 Press CTRL-C for hangup Disconnected mobile root # Das Kommando legt bei erfolgreichem Aufruf eine serielle Schnittstelle, im Beispiel /dev/rfcomm1, an.

19.7

Aufgaben

19.7.1

WLAN-Technik

1. Welche WLAN-Standards exisiteren derzeit? Man nenne mindestens drei Unterscheidungsparameter!

304


2. WLANs arbeiten analog zu Ethernet 10Base2 oder 10Base5 mit einem ”Shared Medium”. Weshalb kommt nicht das von Ethernet bekannte CSMA/CD zum Einsatz? 3. Was versteht man unter ”Hidden Station”? 4. Man beschreibe die Verschl¨ usselungs- und Authentifizierungsverfahren, die f¨ ur WLANs definiert wurden! 5. Welche verschiedenen Betriebsmodi gibt es in Wireless LANs?

19.7.2

WLAN Kommandos

1. Mit welchem Kommando(s) kann man sich allgemeine WLAN-Parameter anzeigen lassen? ¨ 2. Wie lautet das Kommando zum Andern des Kanals bzw. der Sendefrequen? Warum funktioniert dieses im ”Managed Mode” nicht? 3. Mit welchem Kommando ? 4. Was kann man mit den Kommandos iwpriv, iwgetid und iwspy erfahren? 5. Wozu dient das Tool iwlist?

19.7.3

WLAN Hardware

1. Wie bekommt man heraus, ob eine (WLAN-)Netzwerkkarte in der Maschine installiert ist? 2. Traditionell sind viele WLAN-Adapter als PCMCIA oder PC-Card ausgef¨ uhrt. Mit welchen Programmen kann ich den entsprechenden Bus auslesen und steuern?

Kapitel 20

Programmentwicklung 20.1

Intro

Linux ist die ideale Entwicklungsumgebung f¨ ur vielerlei Arten von Softwareprojekten. Es stehen fast alle g¨ angigen Programmiersprachen in einer frei verf¨ ugbaren Implementierung zur Verf¨ ugung und die Auswahl der Entwicklungswerkzeuge hat sich in den letzten Jahren stark vergrößert. Bei größeren Software-Projekten oder Texten, wie diesem hier vorliegenden, kommt man mit einer manuellen Verwaltung durch Absprachen und regelmäßigem versuchten Abgleich der verschiedenen Versionen bald nicht mehr weit, wie auch die Autoren dieses Textes im mutigen Selbstversuch herausfanden! Deshalb widmet sich ein Abschnitt der automatischen Versionsverwaltung. Diese kann durch verschiedene Werkzeuge erfolgen, vorgestellt wird hier das verbreitete und f¨ ur diesen Text verwendete “CVS” (Concurrent Version System)

20.2

CVS zur Projektverwaltung

20.2.1

Die Idee und das Konzept

Programmquellen1 und deren Dokumentationen sowie Texte aller Art in geeigneter Form2 ¨ unterliegen einer hohen Anderungsfrequenz. Gleichzeitig werden häufig viele Dateien in verschiedenen Versionen parallel von mehreren Projektbeteiligten verändert. Das Programm¨ paket CVS hilft, den Uberblick zu behalten. F¨ ur die Verwaltung gr¨ oßerer Projekte, seien es Texte oder Programmcode gibt es eine ¨ Reihe von Anforderungen. So sollen Anderungen, z.B. Löschungen von Textabschnitten, r¨ uckgängig gemacht werden k¨ onnen. Oder es soll eine bestimmte Fassung, die zu einem ¨ bestimmten Datum aktuell war, rekonstruiert werden. Oder es soll der Anderungsverlauf ¨ nachvollziehbar sein: Warum und wann von wem welche Anderungen durchgef¨ uhrt wurden. Es sind also verschiedene Fassungen oder Versionen einer Datei und die Zusammenhänge zwischen ihnen zu ber¨ ucksichtigen. Hierzu können nat¨ urlich laufend Kopien der entsprechenden Dateien erstellt werden. Ein besserer Ansatz ist jedoch der Einsatz eines Versionsverwaltungssystems, welches f¨ ur solche Aufgaben entworfen wurde. Dieses macht sich ¨ die inkrementelle Natur des Vorgangs zunutze, indem es nur die Anderungen zwischen den Versionen archiviert. Versionen werden u ¨ber sogenannte Versionsnummern identifiziert. Die Situation wird versch¨ arft, wenn gleichzeitig mehrere Entwickler an einem Projekt arbeiten, das aus vielen, vielleicht hunderten von Dateien besteht. Einerseits ist daf¨ ur das 1

sogenannte sources (engl.) propriet¨ are und in normalen Editoren unlesbare Texte, wie das MS-Word-Format fallen nicht in diese Kategorie 2

305

306

KAPITEL 20. PROGRAMMENTWICKLUNG

¨ unabhängige Arbeiten zu gew¨ ahrleisten, andererseits d¨ urfen Anderungen nicht verloren gehen. Um zu verstehen, was dies mit der Unterst¨ utzung der Zusammenarbeit zu tun hat, wirft man am besten zun¨ achst einen Blick auf die Mechanismen, mit denen CVS es ermöglicht, dass mehrere Personen zusammen an einem Projekt arbeiten. Zuvor einige Anmerkungen zu einem Mechanismus, der von anderen Versionsverwaltern bekannt sein mag, den jedoch CVS nicht bietet oder zumindest nicht empfielt: das Dateisperren. Vielleicht ist das ¨ Entwicklungsmodell Sperren-Andern-Freigeben bereits bekannt. Hier muss ein Entwickler zuerst den exklusiven Schreibzugriff auf die zu bearbeitende Datei (eine Sperre) erhalten, anschliessend die Ver¨ anderungen vornehmen und dann die Sperre wieder freigeben, damit andere Projektbeteiligte wieder auf diese Datei zugreifen können. Wenn jemand anders bereits eine Sperre f¨ ur diese Datei gesetzt hat, so muss er diese zuerst wieder freigeben, bevor man selbst eine Sperre setzen und Ver¨ anderungen anbringen kann. Dieses System bietet sich an, wenn alle Projektbeteiligte sich kennen und sehr eng zusammenarbeiten und daher wissen, wer was zu einem bestimmten Zeitpunkt machen möchte. Zugriffskonflikte lassen sich bei diesem Verfahren auf einer direkten Ebene klären, die nicht vom Versionsverwaltungssystem realisiert werden muss. Handelt es sich bei einer Projektgruppe um eine gr¨ oßere Anzahl von Entwicklern, die dazu noch geografisch weit verteilt arbeiten, kann das notwendige Sperren und Entsprerren schon wesentliche Teile der zur Verf¨ ugung stehenden Arbeitszeit auffressen. CVS realiseiert einen weitergehenden Ansatz um dieses Problem in den Griff zu bekommen. Die Entwickler haben nun nicht mehr die vorrangige Aufgabe, ihre Arbeit eng zu koordinieren. Dieses u ¨ bernimmt CVS durch die Integration der Veränderungen und den ¨ Uberblick zu vorgenommenen Ver¨ anderungen. Beschrieben werden kann dieses Verfahrung durch das Kopieren-Modifizieren-Zusammenfassen-Modell, das wie folgt funktioniert: • Entwickler 1 fordert eine Arbeitskopie von CVS an (ein Verzeichnisbaum, der alle Dateien eines Projektes enth¨ alt). Dies wird auch “Checking out” einer Arbeitskopie genannt, wie das Ausleihen eines Buches aus einer Bibliothek. • Entwickler 1 arbeitet unbeschwert an seiner lokalen Arbeitskopie. Gleichzeitig können andere Entwickler ebenfalls an ihren eigenen Arbeitskopien werkeln. Da alle Kopien unabhängig voneinander sind, k¨ onnen zu diesem Zeitpunkt keine Konflikte auftreten: Es ist so, als h¨ atten alle Entwickler ihre eigene Kopie des gleichen Buches aus der Bibliothek entliehen und sie alle schreiben, unabhängig voneinander, Kommentare an dessen R¨ ander oder u ¨berarbeiten bestimmte Seiten gänzlich neu. • Entwickler 1 schliesst seine Ver¨ anderungen vorerst ab und sendet diese verkn¨ upft mit einem Kommentar, der beschreibt, was der Zweck der Veränderungen war, an den CVS-Server (“commit”). Dieses l¨ aßt sich damit vergleichen, die Bibliothek dar¨ uber zu informieren, welche Ver¨ anderungen gemacht wurden und aus welchen Gr¨ unden. Die Bibliothek l¨ asst diese wiederum in eine Hauptkopie einfließen, wo sie damit f¨ ur alle Zeit aufgezeichnet werden. • In der Zwischenzeit k¨ onnen andere Entwickler CVS dazu veranlassen, die Bibliothek abzufragen, um festzustellen, ob die Hauptkopie in j¨ ungster Zeit Veränderungen ausgesetzt war. Wenn dieses zutrifft aktualisiert CVS automatisch die jeweils lokale Arbeitskopie. Aus der Sicht von CVS sind alle Entwickler eines Projektes gleich. Zu entscheiden, wann ein “commit” oder eine Aktualisierung durchgef¨ uhrt wird, obliegt einem selbst. Dieses

20.2. CVS ZUR PROJEKTVERWALTUNG

307

ist eher eine Sache der pers¨ onlichen Einschätzung oder der Projektregeln, nie jedoch eine Festlegung seitens CVS. Eine u ¨ bliche Strategie bei Programmierprojekten sieht vor, immer dann eine Aktualisierung vorzunehmen (“up”), bevor die Arbeit an größeren Veränderungen begonnen wird. Ein “commit” sollte erst dann erfolgen, wenn die Veränderungen vollständig und getestet sind, so dass die Hauptkopie sich möglichst zu jedem Zeitpunkt in einem funktionsfähigen Zustand befindet. Es kann hierbei nat¨ urlich vorkommen, dass die Entwickler 1 und 2 in ihren jeweiligen Arbeitskopien unterschiedliche Ver¨ anderungen an der gleichen Datei an identischer Textstelle vornehmen und beide ihre Ver¨ anderungen mittels “commit” aufs Archiv u ¨ bertragen wollen. In diesem Augenblick meldet CVS einen Konflikt, sobald Entwickler 1 oder 2, versucht seine Version abzuschicken. CVS setzt Konfliktmarkierungen, leicht zu erkennende Marken im Text, an die in Konflikt stehenden Stellen im Text seiner Kopie. Diese Stellen beinhalten beide Ver¨ anderungen und sind derart angeordnet, dass sie leicht verglichen werden können. Der jeweilige Entwickler muss sich nun manuell die Geschichte nochmal ansehen. Er muss eine Version bauen, die den Konflikt auflöst. Was ist nun mit der Hauptkopie? In der offiziellen CVS-Terminologie wird diese das Archiv (Repository) eines Projektes genannt. Das Archiv ist schlicht nur ein Datei- bzw. Verzeichnisbaum, der auf einem Server gespeichert ist. Ohne zu stark in die Tiefe der Struktur zu gehen, wird im Folgenden beschrieben, was ein Archiv leisten muss, um den Anforderungen des Checkout-Commit-Aktualisieren-Zyklus gerecht zu werden. Hierzu stelle man sich folgendes Szenario vor: • Zwei Projektbeteiligte, 1 und 2, f¨ uhren gleichzeitig einen “checkout” des gleichen Projektes aus. Das Projekt befindet sich noch am Ausgangspunkt - es wurden noch von niemandem Ver¨ anderungen per Commit an das Archiv geschickt, sodass sich noch alle Dateien in ihrem urspr¨ unglichen Zustand befinden. • Entwickler 1 beginnt anschliessend mit seiner Arbeit und f¨ uhrt schon bald einen ersten ¨ “commit” seiner Anderungen aus. In der Zwischenzeit ist Entwickler 2 immer noch mit anderen Dingen besch¨ aftigt. • Entwickler 1 arbeitet weiter und denkt, dass sich ein lohnender Zwischenstand ergeben hat. Er f¨ uhrt einen zweiten “commit ” aus. Das Archiv enthält nun die Originaldateien, gefolgt vom zweiten Satz der Ver¨ anderungen von Entwickler 1, gefolgt vom letzten Satz an Ver¨ anderungen. Entwickler 2 hat bisher kein Bit an seinem Satz von Dateien geändert. • Zusätzlich st¨ oßt ein weiterer Entwickler 3 zum Projekt und generiert f¨ ur sich eine lokale Arbeitskopie aus dem Archiv. Die Kopie von Entwickler 3 enthält damit bereits zwei Sätze von Ver¨ anderungen von Entwickler 1, weil diese schon im Archiv enthalten waren als 3 sein “checkout” unternahm. • Entwickler 1 ist immer noch am Programmieren und vollendet seinen dritten Satz an Modifikationen. Diese werden wiederum “commited”. • Irgendwann beschliesst Entwickler 3 an die Arbeit zu gehen. Er k¨ ummert sich nicht darum, eine Aktualisierung seiner Arbeitskopie durchzuf¨ uhren, da er vielleicht nicht ¨ davon ausgeht, dass in der Zwischenzeit wesentliche Anderungen erfolgt sind. Er fängt an, Dateien zu bearbeiten, von denen einige dabei sein könnten, an denen 1 bereits Modifikationen vornahm. Kurz darauf f¨ uhrt Entwickler 2 seinen ersten “commit” dieser Ver¨ anderungen aus.

308


An diesem Punkt k¨ onnen nun zwei Dinge passieren. Wenn keine der von Entwickler 2 bearbeiteten Dateien von 1 bearbeitet wurde, dann ist der “commit” erfolgreich. Wenn CVS jedoch merkt, dass einige der Dateien von 2 im Vergleich mit den aktuellen Dateien des Archivs veraltet sind und diese auch von 2 in seiner Arbeitskopie verändert wurden, informiert CVS 2 dar¨ uber, dass er eine Aktualisierung durchf¨ uhren muss, bevor ein Commit durchgef¨ uhrt werden kann. Wenn Entwickler 2 die Aktualisierung durchf¨ uhrt, f¨ ugt die Versionsverwaltung alle Veränderungen von 1 in 2’s lokale Kopien der Dateien ein. Einige von 1’s Veränderungen können mit 2’s noch nicht abgeschickten Veränderungen in Konflikt geraten, manche nicht. Die Teile, welche nicht in Konflikt stehen, werden einfach ohne weitere Komplikationen in 2’s Kopie eingef¨ ugt; die in Konflikt stehenden m¨ ussen zuerst von 2 bereinigt werden, bevor der Commit durchgef¨ uhrt werden kann. Wenn Entwickler 3 nun eine Aktualisierung durchf¨ uhrt, bekommt er mehrere Sätze an Veränderungen aus dem Archiv: den dritten Commit von 1, den ersten von 2 und vielleicht den zweiten von 2 (wenn 2 die Konflikte aufgelöst hatte). Damit die Versionsverwaltung Ver¨ anderungen in der richtigen Reihenfolge an die Entwickler verteilen kann, deren Arbeitskopien unter Umständen unterschiedlich stark veraltet sind, muss das Archiv alle Commits seit Projektbeginn aufzeichnen. In der Praxis speichert das CVS-Archiv diese als aufeinander folgende Diffs. Daher kann CVS auch noch f¨ ur sehr alte Arbeitskopien den Unterschied zwischen den Dateien der Arbeitskopien und dem aktuellen Stand des Archivs bestimmen und dadurch die Arbeitskopie effizient wieder auf den aktuellen Stand bringen. F¨ ur die Entwickler ist es dadurch einfach, die Historie des Projektes einzusehen und zu jedem Zeitpunkt sogar sehr alte Arbeitskopien wieder zum Leben zu erwecken. Obwohl das Archiv genau genommen das gleiche Resultat mit anderen Methoden erreichen könnte, ist das Abspeichern der Differenzdateien eine einfache und intuitive Methode, die notwendige Funktionalit¨ at zu implementieren. Dieser Prozess hat den zusätzlichen Vorteil, dass CVS durch die korrekte Anwendung von patch, jeden vorangegangenen Zustand des Verzeichnisbaumes wiederherstellen und damit jede Arbeitskopie von einem Zustand in einen anderen u uhren kann. Es erlaubt jedem, einen Checkout des Projektes in ¨ berf¨ einem womöglich vergangenen Zustand zu machen. Es kann ebenso die Unterschiede im diff-Format zwischen zwei Zust¨ anden des Projektes aufzeigen, ohne dabei irgendeine Arbeitskopie zu beeinflussen. Daher sind genau diese Funktionen, die den vern¨ unftigen Zugriff auf die Historie eines Projektes zulassen, auch daf¨ ur n¨ utzlich, es einer dezentralen, unkoordinierten Entwicklergruppe zu erm¨ oglichen, an einem Projekt zusammenzuarbeiten.

20.2.2

CVS Begriffswelt und Kommandos

Im Folgenden werden immer wieder Bezeichnungen auftauchen, die einen bestimmten Vorgang bei der Benutzung oder die Aktionen von CVS beschreiben. Die CVS-Sub-Kommandos, soweit mit einzelnen Begriffen assoziiert, sind hinter diesen in Klammern angegeben. Diese Sub-Kommandos werden an das Kommando cvs angehängt. (z.B.: cvs up) • Aktualisierung (up) - Auch “update” genannt; u ¨berträgt die Modifikationen anderer Entwickler vom Archiv in die Arbeitskopie. In diesem Schritt wird gleichzeitig u uft, ob die eigene Arbeitskopie Modifikationen beinhaltet, die noch nicht durch ¨ berpr¨ ein “commit” auf das Archiv u ¨bertragen wurden. • Arbeitskopie - Die Kopie einer Datei, die sich in Benutzung befindet, d.h. auf der aktuell Ver¨ anderungen vorgenommen werden. Dabei ist es erlaubt, dass mehrere


309

Arbeitskopien einer Datei oder eines Projektes existieren. Jeder Entwickler verf¨ ugt u ¨ blicherweise u ¨ber eine eigene Kopie. • Archiv - Dieses bezeichnet die Hauptkopie eines Projektes. Hierin hinterlegt CVS die vollständige Revisionshistorie. Jedes Projekt verf¨ ugt u ¨ber ein dediziertes Archiv. • Checkout (co) - Hierdurch holt sich der Entwickler eine Arbeitskopie vom Archiv ab. Dabei ist die angeforderte Kopie eine Momentaufnahme des gerade aktuellen ¨ Archivstandes eines Projektes. Um die eigenen Weiterentwicklungen und Anderungen anderen zug¨ anglich zu machen m¨ ussen diese mittels “commit” ins Archiv u ¨ bertragen ¨ werden. Damit man die durch andere vorgenommenen Anderungen im Projekt zu sehen bekommt, aktualisiert man seine lokale Kopie durch ein “update”. • Commit (commit)- Wird auch als “Check-In” bezeichnet, d.h. Bekanntgeben, der eigenen Ver¨ anderungen auf das zentrale Archiv. • Importieren (import) - Kommen neue Dateien hinzu, die bisher nicht im Archiv erhalten sind, m¨ ussen diese “importiert” werden. Damit werden sie in die CVS-Archivliste des Projektes aufgenommen. • Konflikt - Nicht alle Ver¨ anderungen lassen sich reibungslos auf das Archiv zur¨ uck¨ ubertragen. Es gibt Situationen, in denen zwei Entwickler versuchen, Veränderungen in der gleichen Datei an gleicher Stelle per “commit” zu u ¨bertragen. CVS stellt ein Problem fest und informiert die Entwickler. Eine Auflösung des Konfliktes muss manuell erfolgen. • Logfile log - Ein Nachrichtenteil welcher beim “commit” an eine Revision angehängt ¨ wird. Anderungen lassen sich auf diese Weise beschreiben, so dass andere Entwickler verfolgen k¨ onnen, was in dem Projekt passiert ist. • Revision - Sie beschreibt alle Ver¨ anderungen an einer Menge von Dateien (die auch aus einer einzigen Datei bestehen kann), die durch einen “commit” abgeschlossen wurde. Eine Revision entspricht damit einer Momentaufnahme eines Projektes. Wie auch bei vielen anderen Unix-Kommandos handelt es sich bei cvs um ein einziges Kommando, welches durch verschiedene Argumente seine Funktionalität ändert3 . Es realisiert so die Aufgaben, wie “import”, “commit”, “diff”, “update” und etliche weitere. Der generelle Aufbau eines CVS-Kommandos sieht so aus: cvs [ cvs options ] command [ command options ] [ command args ] cvs options command

Einige Optionen, die alle Sub-Kommandos beeinflussen Einer der vielen Sub-Befehle (wie “up”, “commit”, ...), die teilweise abgek¨ urzt werden. Nur cvs -H (Hilfe f¨ ur command) und cvs -v (Version) kommen ohne command aus command options Optionen, die sich auf command beziehen command args Argumente f¨ ur command CVS bringt bei seinen Arbeiten auf einzelnen Dateien verschiedene Statusmeldungen: Am Anfang der Zeile vor jeder Datei ein einzelner Buchstabe. Dabei steht U f¨ ur “Update”, M f¨ ur “Modified” und C f¨ ur Conflict. Durch das M wird angezeigt, dass man selbst als ¨ Letzter die Datei angefasst hat und etwaige Anderungen allen anderen noch nicht bekannt sind. N meldet beim Import, dass die entsprechende Datei neu im Archiv neu angelegt wurde. Ein T vor dem Dateinamen zeigt an, dass eine Markierung (ein sogenanntes “Tag”) auf dieser Datei angebracht wurde. 3

Es gibt eine ganze Reihe weiterer Unix-Kommandos, wie ip, tc, ..., die mit Sub-Befehlen arbeiten.

310

20.2.3


Einige Vorbereitungen

Nicht alle Dateitypen lassen sich in CVS gleich effektiv organisieren oder anders ausgedr¨ uckt: Besonders reine Textdateien eignen sich f¨ ur die Verwaltung im CVS. Dazu zählen alle Quelldateien beliebiger Programmiersprachen, Texte in HTML-, XML-, Tex@TEX oder a¨hnlichen Formaten, jedoch keine scheinbar chaotisch aufgebauten binären Formate, wie Microsoft Word oder Excel. Dieses geht nat¨ urlich auch, aber ob die Fähigkeiten von CVS hier Sinn machen, darf bezweifelt werden. Ebenfalls m¨ ussen nicht alle Dateien verwaltet werden, die im Zuge eines Projektes so anfallen: Es macht wenig Sinn mit CVS binäre Zwischenformen, wie Object-Dateien und kompilierte Programme oder bei LATEXDokumenten DVI- und Postscript-Ausgaben zu verwalten. CVS kann sowohl lokal als auch netzwerktransparent arbeiten. Im letzteren Fall ist jedoch eine Anmeldung beim CVS-Server erforderlich. Man meldet sich auf dem Server durch: cvs -d:pserver:[email protected]:/srv/cvs login an. Bei erfolgreicher Anmeldung wird im Homeverzeichnis eine Datei .cvspass angelegt, die eine Kombination aus Server, Pfad und Passwort speichert, so dass f¨ ur alle weiteren CVS-Kommandos keine weitere Authentifizierung notwendig wird. In dieser Kommandozeile bestimmt die Option “-d” das CVS-Repository4 , welches sich aus einer Kombination aus Benutzer- und Rechnername gefolgt von einem absoluten Dateipfad nach dem Doppelpunkt zusammensetzt. Das Argument “login” authentifiziert den angegebenen Benutzer “user” beim CVS-Server (im Beispiel: cvs-server.domain.local). Wenn noch kein CVS-Unterverzeichnis im Projektbaum exisitert, wie das bei der Erstanlage meist der Fall sein wird, ist das CVS-Repository anzugeben. F¨ ur diesen Zweck existiert die Umgebungsvariable “$CVSROOT” oder der Kommandozeilenschalter “-d”: user@linux:~> CVSROOT=":pserver:[email protected]:/srv/cvs" user@linux:~> export $CVSROOT Später wird die Umgebungsvariable nicht mehr benötigt oder kann sogar störend wirken, wenn verschiedene Projekte auf verschiedenen Servern verwaltet werden. Eine parallele Versionverwaltung stellt f¨ ur CVS kein Problem dar, da die Datei .cvspass mehrere Einträge aufnehmen kann und alle notwendigen Basisinformationen im CVS-Unterverzeichnis gespeichert werden.

20.2.4

Anlegen eines neuen Projektes

Nicht jeder wird gleich ein neues Projekt anlegen wollen, trotzdem soll diese Beschreibung schrittweise aufeinander aufbauen. Das Concurrent Version System weiss zu diesem Zeitpunkt noch nichts von seinem Gl¨ uck und muss deshalb zuerst mit dem Satz von Dateien gef¨ ullt werden, der das Projekt ausmacht. Hierbei ist zu u ¨berlegen, welche Dateien dazu zählen und welche davon nur tempor¨ aren Charakter haben und von jedem Programmierer bei Bedarf leicht selbst erzeugt werden können. Ein bestehendes Projekt in der Versionsverwaltung erstmalig anzulegen, geschieht mit dem Kommando cvs import Argumentliste. Dazu lege man zuerst eine Sicherheitskopie des Projektes an, wechsele in das entsprechende Verzeichnis und lösche alle nicht per CVS zu verwaltenden Dateien. Im Beispiel geschieht das f¨ ur das Einchecken dieses Skriptes in CVS. user@linux:~> cp -a ldap-projekt ldap-projekt.bak 4

auch als CVS-Root bezeichnet, das Archivverzeichnis ohne jeweiliges Projektverzeichnis des CVS auf dem Server


311

user@linux:~> cd ldap-projekt user@linux:~> rm *.{aux,dvi,toc,pdf,log,ilg,idx,ind,old,~} user@linux:~> cvs import -m "TeX-Skript in einzelnen Kapiteln" ldap-projekt autor start N ldap-projekt/00kap.tex N ldap-projekt/allestex N ldap-projekt/davedap-new.eps N ldap-projekt/davedap-user.eps N ldap-projekt/dn-rdn.eps N ldap-projekt/einleitung.tex N ldap-projekt/gq-browser.eps N ldap-projekt/header.tex N ldap-projekt/java-ldapbrowser.eps N ldap-projekt/ldap-browser.tex N ldap-projekt/ldap-einf.tex N ldap-projekt/ldap-linux.tex N ldap-projekt/lehrstuhl-logo.eps N ldap-projekt/linux-einf.tex N ldap-projekt/php-html.tex N ldap-projekt/php-ldap.tex N ldap-projekt/prog-entw.tex N ldap-projekt/relat-vs-hier.eps N ldap-projekt/template-system.tex N ldap-projekt/yala-login.eps N ldap-projekt/yala-useradm.eps N ldap-projekt/zentral.tex No conflicts created by this import Wenn die in der letzten Zeile gezeigte Meldung erfolgt, ist das Projekt erfolgreich auf den CVS-Server u ¨ bertragen worden. Man besitzt mit dem soeben transferierten Verzeichnis jedoch noch keine CVS-offizielle lokale Arbeitskopie. Diese muss in einem weiteren Schritt “ausgecheckt” werden. Dazu l¨ osche man am besten das Projektverzeichnis, nachdem man sich der Sicherheitskopie vergewissert hat.

20.2.5

Eine Arbeitskopie erstellen

Nicht jeder Projektbeteiligter wird selbst etwas initial im Concurrent Version System hinterlegen, jedoch jeder Beteiligter ben¨ otigt eine lokale Arbeitskopie, auch derjenige, der im soeben beschriebenen Schritt das CVS-Archiv angelegt hat. Das “check-out”, das Erstellen der lokalen Arbeitskopie, geschieht mittels cvs checkout projectname. Im Beispiel bleibend: user@linux:~> dirk@hermes:~> cvs checkout ldap-projekt cvs server: Updating ldap-projekt U ldap-projekt/00kap.tex U ldap-projekt/allestex U ldap-projekt/davedap-new.eps [ ... ] user@linux:~>

312


Dieser Schritt legt im aktuellen Verzeichnis ein Unterverzeichnis mit dem Projektnamen an und kopiert in dieses alle aktuellen Archivdateien. In diesem Verzeichnis wird ein Unterverzeichnis CVS erzeugt, in dem CVS Informationen zur Versionskontrolle gespeichert werden. Genauer gesagt, existiert nun in jedem Unterverzeichnis des Projektes ein CVSUnterverzeichnis. Dieses impliziert, dass man tunlichst vermeiden sollte, ein Unterverzeichnis mit diesem Namen zu verwenden, was aber nicht allzu schwer fallen sollte! Die Informationen, die sich in diesem Unterverzeichnis befinden, kommen einem inzwischen sicherlich bekannt vor: user@linux:~/ldap-projekt> cd CVS; ls Entries Repository Root user@linux:~/ldap-projekt/CVS> cat Entries /00kap.tex/1.1.1.1/Sat Nov 1 19:21:12 2003// /allestex/1.1.1.1/Sat Nov 1 19:21:12 2003// /davedap-new.eps/1.1.1.1/Sat Nov 1 19:21:32 2003// /davedap-user.eps/1.1.1.1/Sat Nov 1 19:22:02 2003// /dn-rdn.eps/1.1.1.1/Sat Nov 1 19:22:20 2003// /einleitung.tex/1.1.1.1/Sat Nov 1 19:22:20 2003// /gq-browser.eps/1.1.1.1/Sat Nov 1 19:22:44 2003// /header.tex/1.1.1.1/Sat Nov 1 19:22:44 2003// /java-ldapbrowser.eps/1.1.1.1/Sat Nov 1 19:22:58 2003// /ldap-browser.tex/1.1.1.1/Sat Nov 1 19:22:58 2003// /ldap-einf.tex/1.1.1.1/Sat Nov 1 19:23:00 2003// /ldap-linux.tex/1.1.1.1/Sat Nov 1 19:23:02 2003// /lehrstuhl-logo.eps/1.1.1.1/Sat Nov 1 19:23:34 2003// /linux-einf.tex/1.1.1.1/Sat Nov 1 19:23:38 2003// /php-html.tex/1.1.1.1/Sat Nov 1 19:23:38 2003// /php-ldap.tex/1.1.1.1/Sat Nov 1 19:23:38 2003// /prog-entw.tex/1.1.1.1/Sat Nov 1 19:23:38 2003// /relat-vs-hier.eps/1.1.1.1/Sat Nov 1 19:24:32 2003// /template-system.tex/1.1.1.1/Sat Nov 1 19:24:32 2003// /yala-login.eps/1.1.1.1/Sat Nov 1 19:25:00 2003// /yala-useradm.eps/1.1.1.1/Sat Nov 1 19:25:28 2003// /zentral.tex/1.1.1.1/Sat Nov 1 19:25:28 2003// D user@linux:~/ldap-projekte/CVS> cat Repository ldap-projekte user@linux:~/ldap-projekte/CVS> cat Root :pserver:[email protected]:/srv/cvs Die Datei Repository verweist auf ein Projekt innerhalb des Archivs, welches unterhalb des in Root angebenen Verzeichnis gespeichert ist. Entries enthält die Liste aller Archivdateien. Jede Zeile beschreibt hierbei eine Datei. Es finden sich hier nur Einträge f¨ ur die Dateien und Unterverzeichnisse des n¨ achst u ¨ bergeordneten Verzeichnisses. Jeder Eintrag dieser Datei besitzt das Format: “/Dateiname/Revisionsnummer/Zeitstempel//” Mit den Zeitstempeln werden Uhrzeit und Datum der letzten Aktualisierung der Dateien in der Arbeitskopie hinterlegt. Dieses geschieht in universeller Zeit. So kann CVS einfach feststellen, ob eine Datei seit dem letzten “update”, “checkout” oder “commit” angefasst wurde. Wenn sich der Zeitstempel des eigenen Dateisystems von dem in CVS/Entries unterscheidet, kann CVS davon ausgehen, dass die Datei wahrscheinlich geändert wurde. Die


313

Revisionsnummern sind willk¨ urlich und werden nicht ausserhalb von CVS sichtbar. Es gibt einen weiteren, vom genannten unabh¨ angigen, Typ der Kennzeichnung: “Tags”, der in einem weiteren Abschnitt weiter unten behandelt wird.

20.2.6

Laufende Ver¨ anderungen

Nun kann man davon ausgehen, dass ein Projekt nicht statisch vor sich hindämmert, sondern laufenden Ver¨ anderungen unterworfen ist. Sonst wäre der Aufwand zur Versionsverwaltung vielleicht etwas u ubung. Bevor man beginnt ¨ berkandidelt und allenfalls eine Finger¨ ¨ eigene Anderungen in der lokalen Arbeitskopie vorzunehmen, u uft man, ob sich nicht ¨berpr¨ vielleicht von anderer Seite bereits welche ergeben haben. Diese Aufgabe u ¨bernimmt cvs update oder k¨ urzer cvs up: user@linux:~/ldap-projekt> cvs up cvs server: Updating . Wenn sich nichts ge¨ andert hat, sieht es genauso wie im Beispiel aus, sonst wird eine Liste der aktualisierten Dateien angezeigt: user@linux:~/ldap-projekt> cvs up cvs server: Updating . M prog-entw.tex M einleitung.tex M php-ldap.tex Möchte man einen detaillierteren Blick auf die Veränderungen werfen, kann man einen kompletten Report im “diff”-Format anfordern. diff vergleicht die möglicherweise modifizierten Dateien der Arbeitskopie mit den entsprechenden Gegenst¨ ucken im Archiv und zeigt jegliche Unterschiede auf. user@linux:~/ldap-projekt> cvs diff cvs server: Diffing . Index: prog-entw.tex =================================================================== RCS file: /home/src/ldap-projekt/prog-entw.tex,v retrieving revision 1.1.1.1 diff -r1.1.1.1 prog-entw.tex 3c3 < \chapter{Programmentwicklung und Projektverwaltung} --> \chapter{Programmentwicklung} 8c8,18 < Softwareprojekten. --[ ... ] Nun legt man selbst los und nimmt Ver¨ anderungen am Projekt vor. Nachdem man diese abgeschlossen hat oder f¨ ur einen gewissen Zeitraum unterbrechen will, meldet man seine Heldentaten wieder ans CVS zur¨ uck: cvs commit gleicht die Arbeitskopie in umgekehrter Richtung mit dem Archiv ab.

314


user@linux:~/ldap-projekt> cvs commit # (--> editor for log comments invoked) Checking in prog-entw.tex; /home/src/ldap-projekt/prog-entw.tex,v cvs add test.txt cvs server: scheduling file ‘test.txt’ for addition cvs server: use ’cvs commit’ to add this file permanently Hat man also eine neue Datei erstellt, die sich noch nicht auf dem CVS-Server befindet, so wird diese durch cvs add neue.datei hinzugef¨ ugt und anschliessend mittels cvs commit auf dem gewohnten Weg eingecheckt. In jedem steckt ein gewisser Grad an Neugier - beim einen mehr, beim anderen weniger. Hier beschäftigt die Frage, was zwischen verschiedenen Revisionen passiert ist. Was macht den Unterschied zwischen 1.6 und 1.7 aus? F¨ ur diesen Zweck steht der Sub-Befehl “log” zur Verf¨ ugung: user@linux:~/ldap-projekt> cvs log prog-entw.tex RCS file: /home/src/ldap-projekt/prog-entw.tex,v Working file: prog-entw.tex head: 1.2 branch: locks: strict access list: symbolic names:


315

start: 1.1.1.1 dirk: 1.1.1 keyword substitution: kv total revisions: 3; selected revisions: 3 description: ---------------------------revision 1.2 date: 2003/11/01 19:32:34; author: dsuchod; state: Exp; lines: +370 -3 *** empty log message *** ---------------------------revision 1.1 date: 2003/11/01 19:23:39; author: dsuchod; state: Exp; branches: 1.1.1; Initial revision ---------------------------revision 1.1.1.1 date: 2003/11/01 19:23:39; author: dsuchod; state: Exp; lines: +0 -0 Skript fuer das Softwarepraktikum - LDAP-Projekte (PHP, Perl, Java, ...) ============================================================================= Liest man die ausgeworfenen Zeilen von unten nach oben durch, wird einem das Prinzip schnell klar. Der Kommentar aus der letzten Zeile d¨ urfte vom Anlegen des Repository bekannt sein. Vielleicht nur so viel: Bei Revision 1.2 folgt in der nächsten Zeile zunächst der genaue Zeitpunkt der Ver¨ anderung sowie der Autor der Datei. In der folgenden Zeile steht der Log-Kommentar, der beim “commit”-Vorgang im Editor (oder mittels ’-m “Kommentar”’) eingegeben wurde.

20.2.7

L¨ oschen von Dateien und Verzeichnissen

Das Entfernen von Dateien funktioniert ähnlich, wie das Hinzuf¨ ugen. Die Reihenfolge ist identisch: Zuerst wird die Datei lokal in der Arbeitskopie gelöscht, anschliessend durch cvs remove datei aus dem CVS-Archiv. user@linux:~/ldap-projekt> rm for-removal.txt user@linux:~/ldap-projekt> cvs remove for-removal.txt cvs remove: scheduling ’for-removal.txt’ for removal cvs remove: use ’cvs commit’ to remove this file permanently user@linux:~/ldap-projekt> cvs ci -m "removed newfile.c" newfile.c Removing for-removal.txt; /home/src/ldap-projekt/for-removal.txt,v cvs tag "version-0-2" cvs server: Tagging . T 00kap.tex T allestex T davedap-new.eps T ... An strategisch wichtigen Punkten in der Entwicklung eines Projektes macht es sinn, nicht nur einzelne Dateien, sondern wie im Beispiel ein gesamtes Verzeichnis zu markieren. Hier lautet die Kennzeichnung “version-0-2”6 . Ab diesem Augenblick ist es möglich, u ¨ber die Angabe dieses Tags alle obigen Dateien im jetzigen Zustand zu erhalten. Der Befehl “status” mit der Option “-v” zeigt einem ausf¨ uhrlich die entsprechenden Markierungen einer Datei. user@linux:~/ldap-projekt> cvs status -v prog-entw.tex =================================================================== File: prog-entw.tex Status: Up-to-date Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: Existing Tags: version-0-2 start dirk

1.2 1.2 (none) (none) (none)

/home/src/ldap-projekt/prog-entw.tex,v

(revision: 1.2) (revision: 1.1.1.1) (branch: 1.1.1)

Möchte man beispielsweise die Version von prog-entw.tex bearbeiten, die mit “version-0-2” markiert worden ist, kann man folgendes eingeben: 5

siehe die jeweiligen Beschreibungen zu den Sub-Befehlen cvs remove ...; cvs add ... Es bestehen einige Einschr¨ ankungen zur Benennung, so d¨ urfen z.B. “.” und “:” nicht in der Bezeichnung auftauchen, wobei cvs tag ... anmerkt, wenn ung¨ ultige Zeichen verwendet wurden. 6

20.3. BETRIEB EINES CVS-SERVERS

317

user@linux:~/ldap-projekt> cvs update -r version-0-2 prog-entw.tex cvs update: U prog-entw.tex Ebenso gelingt es, den Stand eines Projektes vom Vortag wiederherzustellen: user@linux:~/ldap-projekt> cvs checkout -D yesterday project

20.3

Betrieb eines CVS-Servers

20.3.1

Installation

CVS lässt sich Standalone betreiben. Meistens verwendet man jedoch einen CVS-Server im Netz. Im folgende Abschnitt ist das Aufsetzen eines solchen Dienstes (auf einem DebianSystem) beschrieben. root@debian:# apt-get update root@debian:# apt-get install cvs

20.3.2

Archive anlegen

Sobald die CVS-Programme auf dem Server installiert sind, kann man sie direkt als Client benutzen, um auf entfernte Archive zuzugreifen - was bereits beschrieben wurde. Wenn man jedoch Revisionen auf dieser Maschine anderen zur Verf¨ ugung stellen will, muss ein Archiv angelegt werden. Dieses geschieht wiederum mit dem bereits hinlänglich bekannten “cvs”-Kommando: root@linux:~ # cvs -d /export/cvs/repository init Hierbei ist die Angabe /export/cvs/repository ein Pfad zu der (beliebigen) Stelle, an der das Archiv erzeugt werden soll. Hierf¨ ur sind die notwendigen Schreibrechte vonnöten, die eventuell “root”-Privilegien erfordern. Es mag ein wenig gegen die Intuition sein, dass der Ort des neuen Archivs vor dem “init” Sub-Befehl anstatt danach angegeben wird, doch durch die Verwendung der “-d”-Option wird die Konsistenz mit den anderen CVS-Kommandos gewährleistet. Der Befehl gibt nach seiner Ausf¨ uhrung keine Meldung zur¨ uck.

20.3.3

Netzwerkverbindungen

In den meisten Beispielen wurde davon ausgegangen, dass ein CVS-Archiv u ¨ ber ein Netzwerk auf einer entfernten Server angesprochen wurde. Wenn ein entfernter CVS-Client die “:pserver:”-Methode verwendet, um sich mit einem Archiv zu verbinden, kontaktiert der Client einen festgelegten Port auf dem Server. Default ist hier Port-Nummer 2401. Dieser kann nat¨ urlich ge¨ andert werden, dann ist jedoch beim Client-Aufruf die Angabe des abweichenden Ports erforderlich, ein Verfahren, das von den meisten Netzwerkprogrammen bekannt sein d¨ urfte. Der Versionsserver wartet nicht wirklich auf Verbindungen zu diesem Port. Dieses u ¨ bernimmt der Internet-Super-Daemon (x)inetd, der CVS startet, sobald er eine Verbindungsanfrage eintrifft. Hierzu ist die Konfigurationsdatei des (x)inetd entsprechend anzupassen. Damit sind eingehende Verbindungen sichergestellt. Nun möchte man meistens spezielle CVS-Passw¨ orter - getrennt von den normalen Benutzerpasswörtern - anlegen. So lassen sich Zugriffe ausschliesslich auf das Archiv realisieren.

318

20.3.4


Authentifizierung

Die CVS Passwortdatei befindet sich im Archiv in CVSROOT/passwd. Sie wird nicht standardmäßig beim Aufruf von cvs init erzeugt, da das Versionsverwaltungssystem nicht weiss, in welchem Modus es sp¨ ater betrieben wird. Auch wenn die Passwortdatei erzeugt wurde, kann CVS nicht wissen, welche Benutzernamen und Passwörter angelegt werden sollen. Diese m¨ ussen manuell angelegt werden. Hier ist eine Beispiel-Datei f¨ ur CVSROOT/passwd: user:bKaASD5ezmhOo anonymous:XPiZZe45smnk test:bLa12IOg3JJ:pubcvs Das Format ist einfach und verwendet folgende Syntax: :: Der zusätzliche Doppelpunkt, gefolgt von einem optionalen Systembenutzernamen, sagt CVS, dass Verbindungen, die mit “user” authentisiert sind, unter der abweichenden Systembenutzerkennung “optional system user” laufen sollen - anders gesagt, wäre diese CVSSitzung nur dazu in der Lage, Dinge im Archiv zu tun, die jemand tun könnte, der als “system user” angemeldet w¨ are. Wenn kein Systembenutzername angegeben ist, muss “user” einem tatsächlich existierenden Benutzernamen auf dem System entsprechen. Die Sitzung wird mit den Zugriffsrechten dieses Benutzers gestartet. In beiden Fällen sollte das verschl¨ usselte Passwort nicht gleich dem tats¨ achlichen Login-Passwort des Benutzers sein. Es sollte ein unabhängiges Passwort sein, das nur f¨ ur CVS pserver-Verbindungen verwendet wird. Das Passwort wird dabei mit denselben Algorithmen wie die Standard-Unix-Systempasswörter in /etc/passwd verschl¨ usselt.

Kapitel 21

Virtualisierung mit VMware 21.1

¨ Uberblick

Viele kennen das Problem: Da muss mal eben eine neue Installation getestet werden: Ein neues Betriebssystem ist erschienen oder eine Applikation gibt es einfach nicht f¨ ur Linux, welches standardm¨ aßig auf dem Arbeitsplatzrechner installiert ist. Die klassische Methode in die Kiste mit der alten Hardware zu greifen und daraus fix eine Testmaschine zu basteln ist oft suboptimal - oft wurde die Maschine ausgemustert, weil sie zu langsam, zu instabil war oder einfach zu viel Platz weg nahm. Die Zeit, die vergeht, um ”mal eben” den Zweitrechner wieder sauber in Betrieb zu nehmen, hierf¨ ur Laufwerke und Platz unter dem Schreibtisch zu finden, ist nicht zu unterschätzen. Ebenso m¨ ochte kein Admin f¨ ur jeden kleinen Test ein Betriebssystem neu installieren. F¨ ur das Nachstellen von Kundenproblemen möchte ein Servicemitarbeiter vielleicht auf sehr verschiedene Betriebssysteme m¨ oglichst ohne Zeitverzögerung zugreifen können. Und diese Installationen sollen nach dem Test optimalerweise noch so aussehen wie vorher. Szenarien die mit echter PC-Hardware einen hohen Aufwand erfordern lassen sich mit einer VMware-Workstation vergleichsweise simpel und schnell erledigen. VMware-Workstation bildet einen kompletten 32 bit Intel-PC nach. Es stellt sich dem Benutzer als grafische Applikation dar, die auf einem Linux- oder Windowssystemen läuft. So kann ein Benutzer mal eben zwei komplett verschiedene Betriebssyteme gleichzeitig auf seinem Arbeitsplatz betreiben. VMware (Workstation) ist eine Applikation unter einem Betriebssystem, in der sich wiederum andere Betriebssysteme innerhalb eines Fensters der grafischen Oberfäche des Hostbetriebssystems betreiben lassen. Dazu emuliert VMware einen virtuellen PC, in dem das Gastbetriebssystem l¨ auft. VM meint Virtuelle Maschine, da nicht nur Betriebssystem-APIs, sondern ein kompletter Rechner inklusive Hardware nachgebildet wird. Sie implementiert neben den unverzichtbaren Basiskomponenten, wie CPU, BIOS und Speicher, IDE- und SCSI-Festplatten, CD-Rom, USB, Sound, serielle, parallele sowie Ethernet-Schnittstellen und PS2-Maus. Noch einige Worte zu VMware - es ist kommerzielle Software mit ihren Vor- und Nachteilen. Viele empfinden sicherlich eine arbeitsplatzbezogene Lizenz als deutlich einschränkend und störend. Auf der anderen Seite ist VMware einfach noch deutlich schneller als die Produkte der freien Konkurrenz. Sicherlich werden die alternativen Emulatoren Qemu oder Faumachine eine gr¨ oßere Rolle spielen, wenn die Entwicklung weiterhin so dynamisch erfolgt wie jetzt. Derzeitig sind sie je nach Konfiguration wegen teilweise kompletter Emulation der CPU in Software um Gr¨ oßenordnungen langsamer als VMware. Letzteres läßt je nach CPU und Speicherausstattung durchaus bis zu 70 Prozent der Rechnergeschwindigkeit beim Gast 319

320

KAPITEL 21. VIRTUALISIERUNG MIT VMWARE

ankommen. VMware erlaubt eine Installation f¨ ur jedermann zu Test und Evaluationszwecken. Hierzu lädt sich der interessierte Anwender von der VMware-Downloadseite1 die Software herunter. Die Software gibt es in zwei Packungsformaten: Als komprimiertes TAR-Archiv oder RPM. F¨ ur SuSE oder Redhat bietet sich letztere Option zur bequemen Installation und Registrierung in der Softwaredatenbank an. VMware hat seine Produktpalette um einen kostenlosen Player erweitert. Dieser kann alles, was die Workstation auch kann, jedoch lassen sich keine neuen Maschinen einrichten. Beim Download der Version 5.5 ist der Player automatisch mit dabei.

21.2

Virtuelle Hardware

Die Virtualisierung hat inzwischen viele Kinder: Sie reicht von User Mode Linux (UML), welches schon Eingang in die aktuellen Kernels der 2.6er Serie gefunden hat, u ¨ ber XEN, was gerade sehr viel Beachtung erh¨ alt bis hin zu VMware, welches Gegenstand dieses Kapitels ist. Die Reihenfolge der Auflistung ist bewusst gewählt: Wärend UML es lediglich erlaubt spezielle Linux-Kernels laufen zu lassen, geht XEN schon weiter. Es erlaubt ”xenisierte” Betriebssysteme in virtuellen Domains zu starten. Zur Zeit sind Linux und FreeBSD unterst¨ utzt, aber sogar Microsofts Windows-XP soll zu den Kandidaten zählen. Der Vorteil beider Ansätze: Sie sind frei unter der GPL verf¨ ugbar und verbrauchen sehr wenig Ressourcen f¨ ur die Virtualisierung. Der wesentliche Nachteil soll jedoch nicht verschwiegen werden: Nur speziell ausgesuchte und angepasste Betriebssysteme kommen f¨ ur UML oder XEN in Frage. Hier geht die kommerzielle Software VMware einen deutlichen Schritt weiter. Die VMware (Workstation) emuliert einen virtuellen PC, in dem das sogenannte Gastbetriebssystem läuft. VM meint Virtuelle Maschine, da nicht nur Betriebssystem-APIs oder eine Reihe von Hardware-Schnittstellen, sondern ein kompletter Rechner nachgebildet wird. VMware-Workstation bildet einen kompletten 32 bit Intel-PC nach. Sie implementiert neben den unverzichtbaren Basiskomponenten, wie CPU, BIOS und Speicher, IDE- und SCSIFestplatten, CD-ROM, USB, Audio, serielle, parallele sowie Ethernetschnittstellen und PS2Maus. Wegen der Vollst¨ andigkeit der Emulation bekommt der Gast ”nichts davon mit”, dass er nicht auf einer realen Maschine sondern in einem Host-Betriebssystem läuft. Der Host kann f¨ ur VMware Workstation ein Linux- oder aktuelles Windows-System sein. An dieser Stelle geht es haupts¨ achlich um den Linux-Host, f¨ ur die Gäste in VMware ergibt es keinen Unterschied. Gerade hierin liegt einer der wesentlichen Vorteile von VMware: Die Abstraktion der Hardware ist so vollst¨ andig, dass sich eine Installation eines Gastes in eine virtuelle Festplatte problemlos u ¨ber verschiedene Host-Hardware und -Betriebssysteme transportieren lässt. Hat man beispielsweise ein Windows95 in einer VMware unter einem WindowsXP auf einem P4 mit NVidia-Grafikkarte erstellt, so kann man genau diese Installation ohne Anpassungen unter VMware auf einer Linux-B¨ uchse mit einem Athlon-Prozessor starten. 1 http://www.vmware.com/download - Diese Seite bietet Download-Links zu einer ganzen Reihe von ¨ Produkten an - hier ist der Unterpunkt ”VMware Workstation 5.5” interessant. Uber den Link ”evaluate” bekommt der interessierte Anwender nach Registrierung an eine g¨ ultige Mailadresse einen Freischaltcode mit 30 Tagen G¨ ultigkeit geschickt. Alternativ beschafft man sich die ct 20/05 - hier liegt ein VMware4.5 mitsamt einer Lizenz f¨ ur ein Jahr bei.

21.2. VIRTUELLE HARDWARE

21.2.1

321

Peripherie-Schnittstellen

Die klassischen Peripherieschnittstellen, wie vier serielle und zwei parallele Ports, sind konfigurierbar. Die Ausgaben k¨ onnen jeweils an ihre physikalischen Pendants oder in Dateien des Host-OS erfolgen. Serielle Schnittstellen erlauben zusätzlich Named Pipes. Existieren reale USB-Schnittstellen und werden diese vom Hostbetriebssystem unterst¨ utzt, können sie auch unter VMware sichtbar gemacht werden. Abgebildet werden sie als USB 1.1 Controller mit zwei Ports, an welche Drucker, Festplatten, Scanner, PDAs, Speicherkartenleser und Digitale Kameras angeschlossen werden können. Die Einbindung von USB unter Linux weist einige T¨ ucken auf (Siehe Abschnitt 21.7.2, S. 337). Einen Audiokontroller kennt VMware nat¨ urlich auch: Es handelt sich dabei um den PCI-Klassiker mit ES1371-Chipset. Er ist einigen vielleicht noch von der Soundblaster 64 Karte bekannt. Die Qualit¨ at der Schnittstelle ist jedoch begrenzt und setzt selbstredend eine installierte Soundkarte mit Unterst¨ utzung seitens Hostbetriebssystems voraus. VMware spricht die Audiokomponenten u ¨ber das Kerneldevice /dev/dsp an.

21.2.2

Festplatten, CD/DVD und Floppies

Laufwerke kann VMware auf verschiedene Weisen seinen Gästen zur Verf¨ ugung stellen. Davon hängt auch ab, wieviele G¨ aste gleichzeitig auf welche Weise bedient werden können. Auf dem virtuellen Intel-Mainboard finden sich nat¨ urlich die bekannten PC-Schnittstellen f¨ ur IDE- und Floppy-Laufwerke. Der Nutzer kann u usse CD-Rom, DVD oder Festplat¨ber die insgesamt vier IDE-Anschl¨ ten verteilen. Festplatten k¨ onnen wie am SCSI-Bus auch virtuelle oder reale Festplatten sein. Wichtig ist jedoch die aktivierung der angelegten Devices im VMware-BIOS. Virtuelle Festplatten sind Containerdateien, die im Unterverzeichnis der jeweiligen GastOS-Installation abgelegt werden. Die virtuelle IDE-Schnittstelle bietet folgende Eigenschaften: • Es wird ein Intel 82371 PCI Bus Master IDE-Controller f¨ ur den primären und sekundären IDE-Controller verwendet. • Es können bis zu vier IDE-Ger¨ ate, wie Festplatten oder CD-ROMs angeschlossen sein. • Festplatten k¨ onnen dabei virtuelle oder physische Festplatten sein. Virtuelle Festplatten werden durch Containerdateien abgebildet, die im Dateisystem des Host-OS abgelegt werden. • Virtuelle IDE-Festplatten k¨ onnen bei alten Hostdateisystemen nur bis zu 2 GByte gross sein. Sonst k¨ onnen sie bis auf 128 GByte gebracht werden. • Ein CD-ROM-Laufwerk kann ein physisches Laufwerk oder eine ISO-Image-Datei sein. • DVD-ROM-Laufwerke sind eingeschränkt nutzbar: Sie können nur zum Lesen von Daten und nicht zum Abspielen von Videos verwendet werden. • CD-Brenner k¨ onnen, wie unter Linux auch, nur in der SCSI-Emulation verwendet werden. Als SCSI-Laufwerk bieten sie dann die gewohnte Funktionalität. Wie die großen Br¨ uder ESX und GSX-Server auch, kennt die Workstation einen SCSIBus. Der Anwender kann dabei zwischen zwei Host-Adaptern wählen, dem schon von den Vorgängerversionen bekannten BusLogic BT-958 oder einem LSI Logic. Die Auswahl erhält

322


der Anwender bei einer ”Custom”-Installtion eines neuen Gastsystems. Am Bus sind bis zu sieben SCSI-Ger¨ ate anschliessbar. Er kann mit Festplatten, CD-ROM-, DVD- und Bandlaufwerken umgehen. Die SCSI-Festplatten können als virtuelle oder physische Festplatten sein. Maximal sind bei SCSI bis zu 256 GByte Größe einstellbar. Es können, wie im normalen Rechner auch, bis zu zwei Diskettenlaufwerke bis zu einer Kapazität von 2,88 MByte angeschlossen werden. Beim Laufwerk kann es sich um ein physisch vorhandenes Laufwerk oder eine Imagedatei handeln. Der Zugriff auf das Laufwerk erfolgt exklusiv, eine gleichzeitige Nutzung durch mehrere virtuelle Maschinen oder durch das Hostbetriebssystem sind nicht erlaubt. Die Performance der virtuellen Platten ist etwas schlechter als die der realen, da als weitere Abstraktionsschicht das Dateisystem des Hosts in Kauf genommen werden muss. Das hat aber den wesentlichen Vorteil, dass Dateien viel einfacher u ¨ ber Systemgrenzen hinweg verschiebbar sind als ganze Platten oder Partitionen. Ein weiterer Vorteil liegt im benötigten Platz im Dateisystem. Eine virtuelle Festplatte kann zwar etliche Gigabyte gross sein, braucht aber diesen Platz erst dann, wenn er wirklich in der virtuellen Maschine auch belegt wurde. VMware arbeitet mit Kompressionsverfahren, welche die Container erst vergrößern wenn mehr Speicherplatz benötigt wird. Das funktioniert automatisch ohne Benutzereingriff. Dieser sollte jedoch sicherstellen, dass f¨ ur den Bedarfsfall immer gen¨ ugend Speicherplatz auf dem verwendeten Host-Dateisystem zur Verf¨ ugung steht. Er kann alternativ auch den gesamten virtuellen Plattenplatz bei der Erstellung mit dem Assistenten oder im Konfigurationsmen¨ u alloziieren. Eine automatische Verkleinerung gibt es jedoch nicht: Ben¨ otigte eine Installation beispielsweise einmal 5 GByte und anschliessend wurde aufger¨ aumt und vieles gel¨ oscht, so ist die entsprechende *.vmdk Datei (oder die Gruppe von zusammengeh¨ orenden Dateien) anschliessend nicht kleiner. Die VMware-Tools erlauben jedoch aus dem Gastsystem heraus den Container auf optimale Größe zu bringen. VMware erlaubt den Zugriff auf seine Festplatten in unterschiedlichen Modi. Im Modus ”persistent” verhalten sich Festplatten wie gewohnt, alle Schreib- und Löschzugriffe werden direkt auf dem Medium ausgef¨ uhrt und können nur mit den Mitteln des Betriebssystems r¨ uckg¨ angig gemacht werden. Nonpersistente Festplatten verhalten sich wie ReadOnly-Medien aus Benutzersicht. Das Gastbetriebssystem bekommt davon jedoch nichts mit, da alle Schreibzugriffe in eine spezielle Cache-Datei umgeleitet werden. Bei Lesezugriffen u uft VMware auf eventuell erfolgte Schreibzugriffe und beantwortet solche Anfragen ¨ berpr¨ nicht vom Medium, sondern aus dem Cache. Diese Datei wird als Redo-Protokoll bezeichnet und beliebig auf einem schreibbaren Bereich des Hostdateisystems abgelegt werden. VMware kann von schreibbar eingebundenen Festplatten Snapshots ziehen. Dieses sind Momentaufnahmen eines Maschinenzustandes, der auch nach dem Beenden von VMware zu einem beliebigen sp¨ ateren Zeitpunkt wiederhergestellt werden kann. Ein CD-ROM-Laufwerk kann ein physisches Laufwerk oder eine ISO-Image-Datei sein. ¨ Ahnlich verh¨ alt es mit den Diskettenlaufwerken. Ein Disketten-Image erstellt man beispielsweise ganz einfach mit dem Kommando dd if=/dev/fd0 of=floppy-image.flp. Diese Datei sieht das Gastbetriebssystem dann wie eine reale Diskette. F¨ ur DVD-Laufwerke gilt eingeschränkte Nutzung: Sie lassen sich völlig normal zum Lesen von Daten einsetzen. Wegen der Kopierschutzmechanismen funktioniert das Abspielen von Videos jedoch nicht. Bekommt VMware die realen Laufwerke zu sehen, so ist der Zugriff auf diese immer exklusiv. Entweder kann das Hostbetriebssystem oder genau eine Instanz von VMware beispielsweise das CD-Laufwerk in Beschlag nehmen. Man kann jedoch im laufenden Betrieb von WMware Laufwerke im laufenden Betrieb aus- und einhängen und auf diese Weise verschiedenen Einheiten den Zugriff erlauben.

21.3. VMWARE ALS LINUX-APPLIKATION

21.2.3

323

Grafik-Controller

Eine zentrale Komponente eines klassischen Desktop-Rechners ist die Grafikkarte. Die Karte ist keiner realen Hardware nachgebildet, sondern ein virtueller Standard-PCI-Grafikadapter mit VGA- und SVGA-Unterst¨ utzung. VMware nennt die Grafikkarte einfach ”VMware SVGA II”. Die erzielbare Aufl¨ osung h¨ angt von der Auflösung der Hostmaschine ab und dem, was das installierte Gastbetriebssystem treibermäßig unterst¨ utzt. Hohe Auflösungen sind deshalb mit Windows95 aufw¨ arts kein Problem, jedoch schafft man mit Windows3.11 nur die 640x480 Bildpunkte des VGA. Die aktuellen Grafiktreiber des X.org f¨ ur Linux und andere Unixes bringen das notwendige Treibermodul f¨ ur die Grafikkarte mit. Bei sehr alten Versionen wird man vermutlich Schwierigkeiten haben oder kann zumindest versuchen die VESA-Treiber zu verwenden. Mit den neueren Versionen von VMware kommt eine rudimentäre 3D-Unterst¨ utzung hinzu, so dass zumindest einige Funktionen auch in der virtuellen Maschine bereitgestellt werden.

21.2.4

Virtuelle Netzwerkkarten

Ein wichtiges Feature der virtuellen Maschine bilden die bis zu drei virtuellen Ethernetkarten, der AMD PCNET Family. Mit dieser Hardware gelingt es sogar per eingebautem PXE die virtuelle Maschine diskless zu starten. Zusätzlich sind bis zu neun virtuelle Ethernet Switches enthalten, die durch vmnetN abgebildet werden. Die Ethernet-Interfaces können im Bridged, Host Only oder NAT Modus betrieben werden. Die MAC-Adresse kann durch VMware festgelegt oder vom Administrator im gewissen Umfang frei gewählt werden. Die komplette MAC-Adresse jedes Adapters ist voreinstellbar.

21.3

VMware als Linux-Applikation

21.3.1

Installation und Einrichtung

Die Pakete, RPM oder TGZ in denen VMware angeboten wird, sind inzwischen recht umfangreich. Eine klassische Installation legt fast alle VMware-Dateien unterhalb des Verzeichnisses /usr/lib/vmware ab. Ausf¨ uhrbare Programme und den Wrapper f¨ ur das eigentliche VMware landen in /usr/bin. In /etc/init.d landet schliesslich das Startskript f¨ ur Kernelmodule und Einrichtung der virtuellen Netzwerkkarten ”vmwareN”. In den Versionen seit 4.0 ist vmware-config.pl das zentrale Werkzeug zur Einrichtung der virtuellen Maschine. Es: • kompiliert die notwendigen Kernelmodule vmmon.(k)o und vmnet.(k)o. Das Laden der VMware-spezifischen Kernelmodule u unftigen Start der ¨ bernimmt bei jedem zuk¨ Maschine das Runlevel-Skript (/etc/init.d/vmware). • bevölkert die Datei /etc/vmware/locations mit Einträgen, die von /etc/init.d/vmware ausgewertet werden. Hierzu z¨ ahlt beispielsweise das Anlegen der virtuellen Netzwerkkarten /dev/vmnet0-9. • löscht die Datei /etc/vmware/not configured. Diese Datei wird immer dann angelegt, wenn das Laden der Kernelmodule, das Konfigurieren der virtuellen Interfaces ”vmnetN” fehlschl¨ agt.

324


Der neue 2.6er Kernel wird erst ab VMware 4.5 unterst¨ utzt. Jedoch meldet VMware 4.5 unter Umständen beim Start, dass ihm der installierte Kernel zu neu ist. Ab Version 5.0 trat dieses Problem nicht mehr auf. Die Vorbereitung des Kernels der 2.4er Reihe sieht etwas anders aus: Hier ruft der Administrator innerhalb der installierten Kernelsources make cloneconfig; make dep vor dem Start von vmware-config.pl auf. Wer nicht m¨ ochte, dass VMware temporäre Dateien unterhalb von /tmp anlegt, editiert die /usr/lib/vmware/config und f¨ ugt am Ende die Zeile ”tmpDirectory = neues temp” hinzu. ”neues temp” ist der absolute Pfad des Temporärverzeichnisses. In diesem Pfad legt VMware eine spezielle unsichtbare Pipe-Datei ab, die wärend des Betriebes ungefähr die Größe des anderhalbfachen unter VMware eingestellten Arbeitsspeichers hat. F¨ ur eine automatische, skriptgesteuerte Einrichtung von VMware ist der Inhalt der /etc/vmware/locations interessant: file /etc/vmware/locations answer BINDIR /usr/bin answer LIBDIR /usr/lib/vmware answer DOCDIR /usr/share/doc/vmware answer MANDIR /usr/share/man answer INITDIR /etc/init.d answer INITSCRIPTSDIR /etc/init.d file /etc/init.d/vmware 1065542439 answer EULA_AGREED yes answer BUILDR_vmmon no answer BUILDR_vmnet yes answer NETWORKING yes file /dev/vmnet0 file /dev/vmnet1 file /dev/vmnet2 file /dev/vmnet3 file /dev/vmnet4 file /dev/vmnet5 file /dev/vmnet6 file /dev/vmnet7 file /dev/vmnet8 file /dev/vmnet9 answer VNET_0_INTERFACE eth0 remove_file /dev/vmnet0 file /dev/vmnet0 answer VNET_8_HOSTONLY_HOSTADDR 192.168.3.4 answer VNET_8_HOSTONLY_NETMASK 255.255.255.0 remove_file /dev/vmnet8 file /dev/vmnet8 answer VNET_8_NAT no remove_answer VNET_8_HOSTONLY_HOSTADDR answer VNET_8_HOSTONLY_HOSTADDR 192.168.4.4 remove_answer VNET_8_HOSTONLY_NETMASK answer VNET_8_HOSTONLY_NETMASK 255.255.255.0 directory /etc/vmware/vmnet8 directory /etc/vmware/vmnet8/nat file /etc/vmware/vmnet8/nat/nat.conf 1065542600 answer ISC_COPYRIGHT_SEEN yes answer VNET_1_SAMBA no remove_file /etc/vmware/config

Diese legt beispielsweise die privaten Netze f¨ ur das ”host-only” Networking zwischen Gast-

¨ 21.4. GASTE IN VMWARE

325

und Hostbetriebssystem fest. F¨ ur die Host-Only-Anbindung wird ein eigenes Interface ”vmnetN” als Gegenst¨ uck zum Netzwerkadapter innerhalb der virtuellen Maschine konfiguriert: vmnet8

Link encap:Ethernet HWaddr 00:0C:56:C0:12:0D inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fec0:8/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:2429 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Mit einem Host-Only-Network l¨ aßt sich das Gastbetriebssytem komplett von der Netzwerkaußenwelt abschirmen. M¨ ochte man jedoch, dass das Gast-OS nach f¨ ur andere Maschinen im Netzwerk so auftritt, als w¨ are es ein eigener Rechner, benutzt man BridgedNetworking. Dann k¨ onnen z.B. ein zentraler DHCP-Server oder externe Fileserver problemlos mitbenutzt werden. F¨ ur das Bridged-Networking wird kein eigenes Linux-Interface angelegt, da die Ethernet-Pakete transparent an die Ethernet-Schicht des Linuxkernels durchgereicht werden. Ausf¨ uhrlich werden diese Aspekte in Abschnitt 21.4.1 erörtert. Damit die virtuelle Maschine korrekt zwischen verschiedenen Auflösungen im Vollbildmodus hin- und herschalten kann, darf Linux keine Framebufferkonsolen benutzen. Dieses erreicht der Admin durch den Eintrag ”vga=normal” in dem auf der Maschine verwendeten Boot-Loader. Damit ein Gast u ussen die ¨berhaupt alle Auflösungen ansteuern kann, m¨ VMware-Tools installiert sein. Hierzu dient der ”File-¿Install VMware Tools” Men¨ u-Dialog.

21.4

G¨ aste in VMware

VMware erfolgreich gestartet (siehe Abbildung 21.5.2) ist wie Rechnerteile frisch ausgepackt. Es bietet dem Nutzer einen Splash-Screen mit drei Auswahlmöglichkeiten im Hauptfenster an: Es k¨ onnen eine einzelne neue virtuelle Maschine installiert, mehrere solcher Maschinen in einem virtuellen Netz zu einem sogenannten Team zusammengefasst oder eine bestehende VM-Gastinstallation ge¨ offnet werden. Vor den nächsten Schritten sollte die VMware mittels g¨ ultiger Seriennummer freigeschaltet werden. Nun setzt sich der Anwender seine Traummaschine zusammen und legt eine Hardwarekonfiguration an: 1. ”File->New->New Virtual Machine”. Dieser Men¨ ueintrag startet den Wizard. Er bietet die Auswahl zwischen einer typischen und einer benutzerdefinierten Installation. Ersteres geht einfacher und schneller, erlaubt aber weniger Feinheiten. ”Custom” bietet eine Reihe feinerer Einstellm¨ oglichkeiten, die mit etwas Erfahrung noch den einen oder anderen Aspekt, wie eine spezielle Hardware-Auswahl f¨ ur den SCSI-Controller, tunen helfen. 2. In der einfachen Installation w¨ ahlt der Anwender im nächsten Schritt aus einer Liste möglicher Gast-Betriebssysteme aus. Die Familie legt der Anwender per RadioButton, die jeweilige Version per Schaltleiste fest. Bei der Auswahl von ”Microsoft Windows” gibt es eine lange Liste der verschiedenen Vertreter: Windows 3.1, Windows95, 98, ME, NT und den aktuellen Systemen, wie Windows XP in den beiden Ausgaben. Die Auswahl ist f¨ ur VMware von Bedeutung, damit es sinnvolle Ressourcenvorschl¨ age f¨ ur die Speichermenge machen kann. Nach erfolgreicher Installation des Gasts bindet VMware die passende Datenquelle f¨ ur die VMware-Tools ein.

326


3. Der folgende Schritt w¨ ahlt den Namen der Maschine aus: Diese Information steht später im Fester- oder Reitertitel. Ebenfalls legt man damit ein Verzeichnis f¨ ur die Gastinstallation fest. An dieser Stelle kann man von der Möglichkeit Gebrauch machen den Namen und das Verzeichnis f¨ ur die virtuelle Maschine an die eigenen W¨ unsche anzupassen. Wen beispielsweise die Leerzeichen im Dateinamen stören, hat an dieser Stelle die Chance dieses zu ¨ andern. Im angelegten Verzeichnis landet die Konfigurationsdatei mit der Endung *.vmx, die Festplattenimages mit der Endung *.vmdk und weitere Dateien wie *.nvram mit den BIOS-Einstellungen. Hier wird ebenfalls je nach Einstellung auch ein Logfile der entsprechenden Sitzung vmware.log geschrieben. 4. Im vierten Schritt stehen drei Typen einer Netzwerkverbindung zur Auswahl. Soll die Maschine wie ein autonomer PC agieren, bindet man den virtuellen Rechner per ”bridged networking”, der voreingestellten Auswahl, ein. Weitere Optionen sind ”hostOnly”, ”nat” oder keine Netzwerkverbindung. Dieser Schritt legt die Art und Weise fest, ob und wie das Gastbetriebssystem auf das bestehende Netzwerk zugreifen kann. 5. Im letzten Wizard-Schritt wird die Festplattengröße eingestellt, die in den meisten Fällen vorgeschlagenen 4 GByte sind vielleicht f¨ ur einige Szenarien etwas knapp, mit 8 GByte liegt man oft schon im sicheren Bereich. Die Unterteilung in kleinere Dateien (”Split disk ...”) sollte man vermeiden. Alle aktuellen Dateisysteme von Linux können mit großen Dateien umgehen. Eine einzige Datei ist einfacher zu verschieben als mindestens zwei, die unabh¨ angig von der Größe bei ”Split disk” von VMware erzeugt werden w¨ urden. ”Finnish” schliesst den Vorgang ab und zeigt nun im Hauptfenster die Konfigurationsdaten der neuen Maschine. Anschliessend steht eine Maschine in einfacher aber sinnvoller Grundkonfiguration zur Verf¨ ugung. Sie l¨ asst sich dann mittels des gr¨ unen Knopfes der Werkzeugleiste starten, mit dem roten Knopf ausschalten und dem Recycle-Symbol resetten. Voraussetzung hierf¨ ur ist ein g¨ ultiger Lizenzschl¨ ussel in der Datei /.vmware/license.ws.5.0. Nun ist der Rechner komplett, kann eingeschaltet und mit dem Wunschbetriebssystem bespielt werden. Als Bootlaufwerke stehen u ugung. Die ¨blicherweise CD-Rom oder Diskettenlaufwerk zur Verf¨ Installation verl¨ auft wie gewohnt, der Gast merkt keine Unterschiede zu einer realen Hardware. Unter Umst¨ anden sollte man einen Blick ins virtuelle BIOS werfen, welches u ¨ ber die F2-Taste beim Booten der VM erreicht wird. Das BIOS bietet die bekannten Einstellungen seiner Phoenix-Vorlage. Unter ”Main” sind die verf¨ ugbaren Laufwerke gelistet, ”Boot” erlaubt die Modifikation der Reihenfolge, wo der Rechner nach einem Installationsmedium sucht. Kann man das CD-Laufwerk an die erste Stelle setzen. Im Hauptfenster oder u u (”File->Open Virtual Machine ..:”) ¨ber das Vmware-Men¨ steht hat man jederzeit die M¨ oglichkeit offen, die Konfiguration nachträglich zu ändern. Wenn Windows XP oder ein anderes Betriebssystem erfolgreich installiert wurde, kann man die Container-Datei, die diese Installation enthält zwischen verschiedenen VMwareWorkstations hin- und herkopieren. Dabei spielt es keine Rolle, wie die konkrete Hardware der Host-Maschine aussieht, oder ob VMware unter Linux oder Windows läuft. So können beispielsweise zus¨ atzliche Versionen von Windows, z.B. andere Sprachen bzw. andere Windows-Versionen, installiert werden. Hierzu m¨ ussten wiederum die beschriebenen Installationsschritte f¨ ur das neue, gew¨ unschte Betriebssystem durchlaufen werden. Wenn man mehrere virtuelle Maschinen parallel laufen lassen will, ist auch dieses auf einer einzigen Maschine möglich. Dies erfordert jedoch sehr großz¨ ugig bemessene Hardware-Ressourcen.

21.5. DIE KONFIGURATIONSDATEIEN

21.4.1

327

Netzwerkanbindung

VMware kennt vier Typen von Netzwerkeinstellungen, die beim Setup einer Maschine f¨ ur jedes Gastbetriebssystem eingestellt werden können. Die letzte Version, kein Netzwerk zu installieren, ist trivial. Dann steht einfach in der virtuellen Maschine keine Netzwerkkarte zur Verf¨ ugung. Die anderen drei Varianten sehen wie folgt aus: • Bridged Networking > das Gastbetriebssystem ist mit einer Software-Switch mit der Netzwerkkarte der Hostmaschine direkt verbunden. Deshalb gibt es hierf¨ ur kein sichtbares korrespondierendes vmnet-Interface unter Linux. Unsichtbar wird vmnet0 benutzt. Trotzdem bekommt das Gastsystem selbst im Promiscous-Mode nur die f¨ ur es selbst bestimmten und die Broadcast-Pakete des angeschlossenen Ethernets mit. Eine Stolperfalle gibt es in diesem Setup: Ist kein Netzwerkkabel am Host-Rechner angeschlossen, k¨ onnen Gast- und Gastgeber nicht im Bridged-Mode miteinander kommunizieren. • NAT > Im Modus Network Address Translation wird ein Software-Ethernet zwischen Host und Client aufgesetzt. Hierf¨ ur ist das vmnet8-Interface zuständig. Die Linux-Maschine u ¨ bernimmt das Routing der Pakete in die anderen Netze, an die sie angeschlossen ist. Dieses m¨ ussen keine Ethernets sein. Die Gäste tauchen nur maskiert unter der IP-Adresse der Linux-Maschine in den anderen Netzen auf. Dafaultmäßig startet das Runlevel-Skript /etc/init.d/vmware2 einen DHCP-Server auf vmnet8. Damit bekommt das Gast-OS auf Anfrage automatisch eine IP zugewiesen. Die Festlegung des IP-Raumes f¨ ur das virtuelle Ethernet erfolgt durch vmware-config.pl. • Host Only > In diesem Modus wird lediglich ein virtuelles Ethernet aufgesetzt, welches in keiner Weise mit der Aussenwelt verbunden wird. Dieses Netzwerk endet auf der Seite des Linux-Gastgebers auf vmnet1. Auch hier wird ein DHCP-Server f¨ ur ein vorher durch vmware-config.pl festgelegtes Netzwerk gestartet. Im Gastsystem selbst k¨ onnen bis zu drei Netzwerkkarten präsent sein. Diese können auf die eben genannten Weisen konfiguriert sein. Der Gast selbst merkt keinen Unterschied, welche Art eines konfigurierten Netzwerkes auf der anderen Seite wartet.

21.5

Die Konfigurationsdateien

VMware verwendet f¨ ur verschiedene Konfigurationsaspekte systemweite und benutzerspezifische Konfigurationen. In der Datei /etc/vmware/config werden einige Standardeinstellungen vorgenommen. vmnet1.hostonlyaddress = "192.168.100.1" vmnet1.hostonlynetmask = "255.255.255.0" control.fullpath = "/usr/bin/vmware-cmd" loop.fullpath = "/usr/bin/vmware-loop" dhcpd.fullpath = "/usr/bin/vmnet-dhcpd" libdir = "/usr/lib/vmware" vmware.fullpath = "/usr/bin/vmware"

Eine andere Konfigurationsdatei liegt an einer Stelle ausserhalb des Filesystem Hierachy Standard: /usr/lib/vmware/config. 2

bei SuSE und vergleichbaren Linuxes an dieser Stelle

328


tag.help tag.configurationEditor tag.ideConfig tag.floppyConfig tag.mouseConfig tag.netConfig tag.parallelConfig tag.serialConfig tag.soundConfig tag.memConfig tag.miscConfig tag.usbConfig tag.displayConfig tag.tools

= = = = = = = = = = = = = =

introduction.htm config_editor_newvm.htm devices_virtualdrive.htm devices_floppy.htm devices_mouse.htm devices_netadapter.htm devices_parallel.htm devices_serial.htm devices_sound.htm configvm_memory.htm configvm.htm devices_usb.htm configvm_display-problems.htm vmtools.htm

Dieser legt fest, wo f¨ ur das Speichermanagement der virtuellen Maschine eine Spezialdatei angelegt wird. Diese wird nach Erstellung wieder ”freigegeben” aber nicht geschlossen. So erhält man eine unsichtbare Datei der anderthalbfachen Grösse des f¨ ur den Client konfigurierten Speichers. Diese Datei sollte deshalb besser im Bereich des Festplattenspeichers des Servers (z.B. /tmp/scratch liegen, um den Arbeitsspeicher des Clients nicht zu u ¨berlasten3 .

21.5.1

GUI Konfiguration

F¨ ur jeden Benutzer wird in seinem Home automatisch ein Unterverzeichnis .vmware angelegt. Unterhalb dieses Verzeichnisses findet sich neben der Lizenzdatei mindestens die Konfigurationsdatei .vmware/preferences. Sie bestimmt das Verhalten des grafischen Benutzerinterfaces von VMware. Hierin kann der Anwender besonders das Auftauchen von Fehlermeldungen einschalten oder unterdr¨ ucken: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

hint.xkeymap.notLocal = "FALSE" hint.mks.notLocal = "FALSE" hint.usbgLinux.altuhci = "FALSE" hint.gui.reset = "FALSE" prefvmx.mru.suspended = "" pref.toolbarIcons = "FALSE" hint.disklib.lockerror = "FALSE" hint.gui.poweroff = "FALSE" hint.nfsmounted.persistent = "FALSE" hint.nologging = "FALSE" pref.motionUngrabBarrier = "1" pref.motionScrollBarrier = "100000" prefvmx.mru.config = "~/.vmware/autovm.conf:" hint.mks.fullscreen = "FALSE" pref.autoRaise = "FALSE" pref.motionGrab = "TRUE" pref.exchangeSelections = "TRUE" pref.syncTime = "FALSE" hint.cpuid.unknownfeature = "FALSE" hint.guestos.xp = "FALSE" hint.nfsmounted.undoable = "FALSE" hint.scsi.XP = "FALSE" pref.hotkey.shift = "TRUE" ... 3

Es m¨ usste mindestens ein freier Arbeitsspeicher des zweieinhalbfachen des f¨ ur den VMware-Gast vorgesehenen zur Verf¨ ugung stehen

21.5. DIE KONFIGURATIONSDATEIEN

329

In Zeile 18 wird eingestellt, ob die VMware-interne Zeit mit der Uhr des Hostbetriebssystems synchronisiert werden soll. Zeile 19 sorgt daf¨ ur, dass Meldungen von VMware unterdr¨ uckt werden, wenn bestimmte CPU-Features nicht interpretiert werden können, z.B. das Hyperthreading beim 3 GHz Pentium 4. Die Einträge ab Zeile 20 sind spezifisch f¨ ur die neue VMware-Version 4. Da der SCSI-Treiber, der f¨ ur die Version 4 notwendig ist, nicht bei XP dabei ist, erfolgt ein entsprechender Hinweis 4 . Bei der Einrichtung von VMware ist es sicherlich sinnvoll sich u ¨ ber eine Reihe von möglichen Problemen informieren zu lassen oder Hinweise zur Laufzeit des Programmes zu bekommen. Im Einsatz f¨ ur den Endbenutzer, z.B. in Kursraumumgebungen oder als Erweiterung des Linuxdesktop f¨ ur nur unter Windows verf¨ ugbare Anwendungen, stören oder verwirren diese Meldungen meistens nur.

21.5.2

Die (Hardware-)Konfigurationsdateien

VMware legt f¨ ur jede virtuelle Maschine eine eigene Hardwarekonfiguration an. Der Name wird durch Benutzerwunsch definiert, das Dateiende lautet u ¨ blicherweise auf *.vmx. Der Dateiname kann jedoch vom Benutzer auch frei gewählt werden. Die zuletzt geöffneten Konfigurationsdateien merkt sich VMware in den ”preferences” unter ”prefvmx.mru.config”. Alle Dateien werden mit Doppelpunkt voneinander getrennt in einem String angegeben. Wie auch die preferences handelt es sich um eine reine Textdatei, die sich ausserhalb von VMware mit einem Editor bearbeiten oder durch Skripten oder Programme dynamisch generieren läßt. In der Datei finden alle hardwarespezifischen Einstellungen statt. Die Rei¨ henfolge der Eintr¨ age ist nicht vorgeschrieben, jedoch erhält man einen besseren Uberblick bei geeigneter Gruppierung der Eintr¨ age. Zeile 1 und 2 sind VMware-spezifische Angaben, die f¨ ur die Version 4.X/5.0 der Software zutreffen. In der vierten VMware-Release wird die Konfigurationsdatei in Version 7 geschrieben, welche einige Abweichungen mitbringt. Die virtuelle Hardware kann dann sowohl Version 2 oder Version 3 sein. Eine ganze Reihe von Einstellungen werden u ¨ber Schalter realisiert, die die boolschen Werte ”TRUE” und ”FALSE” annehmen können. Die meisten Einstellungen gelten sowohl f¨ ur die verbreitete Version 4.X als auch die neue Version 5.0 von VMware. Die Option ”displayName” erlaubt das Festlegen eines Namen, der im oben Balken des X11-Fensters nach dem vorgegebenen String ”VMware Workstation:” oder als Titel eines Reiters im Hauptfenster erscheint. So lassen sich mehrere gleichzeitig laufende Instanzen unterscheiden. Die Zeilen 4 bis 6 betreffen das VMware-Fenster: Hier wird eingestellt, dass beim Start von VMware sofort die virtuelle Maschine gebootet wird. Weiterhin wird auto¨ matisch in den Full-Screen-Mode geschaltet und ein Andern der Bildschirmauflösung der virtuellen Maschine erlaubt. Dieser muss vom laufenden Xserver unterst¨ utzt werden und die entsprechende Aufl¨ osung verf¨ ugbar sein. Beim Beenden des Gastbetriebssystems wird VMware automatisch durch die Einstellung von ”gui.exitAtPowerOff” beendet. 01 02 03 04 05 06 07 08 09

config.version = "7" virtualHW.version = "3" displayName = "winXPpro" gui.powerOnAtStartUp = "TRUE" gui.fullScreenAtPowerOn = "TRUE" gui.fullScreenResize = "TRUE" gui.exitAtPowerOff = "TRUE" suspendToDisk = "TRUE" apmSuspend = "FALSE" 4

auf die Quelle bei www.vmware.com zum Download des Treibers

330


Abbildung 21.1: Start einer virtuellen Maschine - VMware BIOS 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

hard-disk.enableIBR = "FALSE" resume.repeatable = "FALSE" disable_acceleration = "FALSE" guestOS = "winXPPro" ide0:0.mode = "nonpersistent" ide0:0.present = "TRUE" ide0:0.fileName = "winXPpro.vmdk" ide0:1.present = "TRUE" ide0:1.deviceType = "atapi-cdrom" ide0:1.fileName = "/dev/cdrom" floppy0.startConnected = "FALSE" floppy1.startConnected = "TRUE" floppy1.present = "TRUE" floppy0.fileType = "device" floppy1.fileType = "file" floppy1.fileName = "fd-image.flo" redoLogDir = "" logging = "FALSE" debug = "FALSE" memsize = "256" ethernet0.present = "TRUE" ethernet0.connectionType = "bridged" ethernet0.address = "00:0C:56:0D:00:00" sound.present = "TRUE"

21.5. DIE KONFIGURATIONSDATEIEN 34 35 36 37 38

331

sound.device = "/dev/dsp" usb.present = "TRUE" usb.generic.autoconnect = "TRUE" usb.generic.devfsPath = "/proc/bus/usb" mouse.fileName = "/dev/mouse"

Die beiden folgenden Zeilen bestimmen Funktionen des Suspend: Ein Suspend wird nicht durch APMEvents eingeleitet, ein Suspend auf Festplatte jedoch möglich. Die Zeilen 10 bis 12 enthalten einige festplattenspezifische Optionen. In der darauffolgenden Zeile wird das Gastbetriebssystem spezifiziert. Ein korrekter Eintrag ist mindestens f¨ ur die Installation der VMware Tools unerl¨ asslich. Möglich sind die Einstellungen: ”dos” (MS-DOS im Konfigurationseditor), ”win31” (Windows3.1), ”win95” (Windows95), ”win98” (Windows98), ”winMe” (WindowsME), ”winNT” (WindowsNT), ”win2000Pro” (Windows2000 Professional), ”win2000Serv” (Windows2000 Server), ”win2000AdvServ” (Windows2000 Advanced Server), ”winXPHome” (WindowsXP Home Edition), ”winXPPro” (WindowsXP Professional), als experimentell gekennzeichnete .NET-Server, ”linux” (Linux), ”freeBSD” (FreeBSD), ”netware6” (Netware 6.0 experimentell) und ”other” f¨ ur nicht aufgef¨ uhrte Betriebssysteme. F¨ ur diese gibt es keine speziellen VMware Tools. Alle genannten Einstellungen lassen sich u ¨ber die ”Misc”-Section des Konfigurationseditors erreichen. Hinzu kommt noch die Möglichkeit Debugging (Zeile 28) einzuschalten, die Lage des Red-Log zu spezifizieren (Zeile 26) und ein wiederholbares Resume auf nonpersistente Platten einzuschalten. In Zeile 29 wird der dem Gastbetriebssystem zur Verf¨ ugung gestellte Arbeitsspeicher eingetragen, dabei berechnet VMware den f¨ ur das Hostsystem benötigten Speicher ab und schlägt in Abh¨ angigkeit des eingestellen Gast-OS untere und obere Speicherlimits vor. Die Erhöhung der Speicherzuteilung kann nur in 4 MByte Schritten erfolgen, dieses muss auch ein Skript beachten, welches den Wert aus dem real zur Verf¨ ugung stehenden Speicher ausrechnet. Die Soundausgabe wird in den Zeilen 33 und 34 konfiguriert: Das Audiodevice ist u ugbarkeit wird in der nachfolgenden Zeile markiert. Nach ¨ blicherweise ”/dev/dsp”. Die Verf¨ dem fast identischen Prinzip erfolgt die Konfiguration des USB in den Zeilen 35 bis 37. Die möglichen Einstellungen sind selbsterkl¨ arend. Noch einfacher kann die Maus normalerweise mit Autodetect konfiguriert werden. Soll ein alternatives Mousedevice verwendet werden, liefert Zeile 38 das entsprechende Beispiel. Einstellungen f¨ ur parallele und serielle Schnittstellen sind hier nicht gezeigt, lassen sich jedoch analog durch den Konfigurationseditor erzeugen und sp¨ ater auf eventuelles Skripting u ¨bertragen. Die Zeilen 31 bis 33 demonstrieren f¨ ur das erste virtuelle Ethernet-Interface die möglichen Einstellungen. Das Ger¨ at kann ein und ausgeschaltet werden und kennt die Modi ”bridged”, ”hostOnly” oder ”nat”. Die erste Option ist f¨ ur den Betrieb vielleicht die interessanteste, weil dann der vorhandene DHCP-Server vom Client transparent u ¨ ber das bestehende Netzwerk mitgenutzt werden kann. Damit sich jeder virtuelle Client eindeutig identifizieren läßt, sollte man ihm eine feste MAC-Adresse zuteilen, wie es in Zeile 33 beispielhaft gezeigt wird. Die neue Version 5.0 des VMware bringt einige zusätzliche Einstellungen in der Konfigurationsdatei mit sich. Augenf¨ allig sind am Anfang der Datei die jeweils um eins höhere Version der Konfiguration und der virtuellen Hardware. Mit der virtuellen Hardware hat auch die Zeile 3 zu tun. config.version = "8" virtualHW.version = "3" ... sound.virtualDev = "es1371" ... # sharedFolder0.enabled = "TRUE"

332


# sharedFolder0.expiration = "never" # sharedFolder0.guestName = "home" # sharedFolder0.hostPath = "/home/username" # sharedFolder0.present = "TRUE" # sharedFolder0.readAccess = "TRUE" # sharedFolder0.writeAccess = "TRUE" # sharedFolder.maxNum = "1" checkpoint.vmState = "" priority.grabbed = "high" tools.syncTime = "TRUE" workingDir = "." # tmpDirectory = "/tmp" tools.remindInstall = "TRUE" uuid.location = "56 4d 88 c7 9d c1 1d 48-3a fa 47 49 91 1b b6 76" uuid.BIOS = "56 4d 88 c7 9d c1 1d 48-3a fa 47 49 91 1b b6 76"

Die Shared Folders gibt es derzeit nur f¨ ur die professionelle Workstation, f¨ ur den Player sollen sie erst in einer sp¨ ateren Version aktiviert werden. Weiterhin kann man der virtuellen Maschine sagen, welche Priorit¨ at die Maschine im angewählten Modus erhält oder in welchem Verzeichnis tempor¨ are Daten landen. Letzteres ist nicht ganz unwesentlich, da hier beispielsweise der Komplettabzug des virtuellen RAMs des Gastsystems landet.

21.5.3

Laufwerkskonfiguration

Eine der entscheidenden Aufgabe von VMware ist es, eine geeignete Zuordnung von realen und virtuellen Disketten-, Festplatten- und CD-Rom-Laufwerken zu treffen. Diese wird zum einen innerhalb der Hardwarekonfigurationsdatei eingestellt und muss zum anderen passend im virtuellen BIOS nachvollzogen werden, damit die Laufwerke f¨ ur das Gastbetriebssystem auch wirklich sichtbar sind. Als erstes werden die Laufwerkseinstellungen, einmal f¨ ur IDE-, einmal f¨ ur SCSI-Geräte erklärt. Mit ”ideX:X.present” kann man definieren, ob dieses Laufwerk verwendet werden soll. Ist dies ein Image5 muss der Name des Images der Variable ”ideX:X.filename” zugeordnet werden. Dieses Image l¨ asst sich dann auf nicht-beschreibbar stellen, indem man folgende Zeile in die Konfiguration aufnimmt: ideX:X.mode = ’’independent-nonpersistent’’. Falls das CD-Rom Laufwerk ein Image ist, muss man zudem ”ideX:X.deviceType” auf ”cdrom-image” stellen. Handelt es sich beim CD-Rom Laufwerk hingegen um ein reales Laufwerk, verschwinden ”ideX:X.filename” und ”ideX:X.deviceType”. An ihre Stelle tritt ide1:0.deviceType = ’’cdrom-raw’’. Das gleiche gilt im Grunde auch f¨ ur SCSI-Geräte. Hier muss aber noch bei Verwendung zusätzlich der ganze BUS, ”scsiX.present”, auf ”TRUE” gesetzt werden. Außerdem muss der zum BUS zugeh¨ orige Treiber mit ”scsiX.virtualDev” definiert werden. Der unten aufgef¨ uhrte ”lsilogic” Treiber sollte beispielsweise bei Windows XP keine Probleme bereiten. Sein Counterpart ”buslogic” ben¨ otigt zusätzliche Treiber. ide0:0.present = "TRUE" ide0:0.filename = "winxp.vmdk" # ide0:0.mode = "independent-nonpersistent" # snapshot.action = "autoRevert" # snapshot.disabled = "TRUE" ide0:0.redo = "" ide1:0.present = "TRUE" # ide1:0.fileName = "dsl-2.0.iso" 5

Eine Datei, die einen Container darstellt, die VMware dem Gast als reale Festplatte pr¨ asentiert

21.6. VMWARE-TOOLS

333

# ide1:0.deviceType = "cdrom-image" ide1:0.deviceType = "cdrom-raw" ide1:0.startConnected = "TRUE" ide1:0.autodetect = "TRUE" floppy0.present = "FALSE" # floppy0.fileName = "/dev/fd0" # # # # # # # # # # # #

scsi0.present = "TRUE" scsi0.virtualDev = "lsilogic" scsi0:0.present = "TRUE" scsi0:0.fileName = "winxp.vmdk" scsi0:0.redo = "" scsi0:0.mode = "independent-nonpersistent" snapshot.action = "autoRevert" snapshot.disabled = "TRUE" scsi0.present = "TRUE" scsi0:0.present = "TRUE" scsi0:0.deviceType = "cdrom-raw" scsi0:0.fileName = "/dev/cdrom"

F¨ ur Festplatten stehen die Modi ”independent-nonpersistent”, wie im Beispiel gezeigt und ”independent-persistent” zur Verf¨ ugung. Diese Modi existieren f¨ ur IDE- und SCSI-Festplatten. Im Modus ”independent-persistent” verhalten sich Festplatten wie gewohnt, alle Schreibund Löschzugriffe werden direkt auf dem Medium ausgef¨ uhrt und können nur mit den Mitteln des Betriebssystems r¨ uckg¨ angig gemacht werden. Nonpersistente Festplatten verhalten sich wie Read-Only-Medien aus Sicht des VMware-Benutzers. Das Gastbetriebssystem bekommt davon jedoch nichts mit, da alle Schreibzugriffe in eine spezielle Cache-Datei umgeleitet werden. Bei Lesezugriffen u uft VMware auf eventuell erfolgte Schreibzugriffe ¨ berpr¨ und beantwortet solche Anfragen nicht vom Medium, sondern aus dem Cache. Diese Datei wird als Redo-Protokoll bezeichnet und u ¨blicherweise im Home-Verzeichnis des Benutzers abgelegt. VMware kann von schreibbar eingebundenen Festplatten Snapshots ziehen. Dieses sind Momentaufnahmen eines Maschinenzustandes, der auch nach dem Beenden von VMware zu einem beliebigen späteren Zeitpunkt wiederhergestellt werden kann. Die Nummerierung der IDE- bzw. SCSI-Busse und Anschl¨ usse erfolgt durch Zahlen, welche mit Doppelpunkt voneinander getrennt werden: ”Bus-Nummer:Device-Nummer”. Die nicht kommentierten IDE-Eintr¨ age bezeichnen das Master-Gerät, in diesem Falle eine virtuelle Festplatte, am ersten IDE-Bus. Die weiteren nichtkommentierten IDE-Zeilen definieren ein CD-Rom, welches als Secondary-Master angeschlossen ist. Ein CD-ROM-Laufwerk kann ein physisches Laufwerk oder eine ISO-Image-Datei sein. Die SCSI-Devices liegen auf dem Bus 0 und können von 0 - 6 durchnummeriert werden. Diskettenlaufwerke werden etwas anders angesprochen und kennen die Modi ”Device” oder ”File”. Dateien m¨ ussen in ihrer Gr¨ oße mit der jeweiligen Nettokapazität des eingestellten Diskettenlaufwerkes im BIOS korrespondieren. Auf Devices wird im ”raw”-Modus zugegriffen, wobei die virtuelle Maschine das Gerät dann exklusiv verwendet. Es ist jedoch möglich u u virtuelle und reale Disketten ein- und auszuschalten. ¨ ber das Men¨

21.6

VMware-Tools

Nach der Installation des Gast-OS sollte man noch die sogenannten VMware-Tools installieren, damit die G¨ aste in einer virtuellen Maschine optimal laufen. Dieses sind Treiber, die

334


beispielsweise daf¨ ur sorgen, dass die Maus transparent u ¨ ber den Desktop und VMware bewegt werden kann ohne dabei von Vmware ”eingefangen” zu werden. Mit den Tools werden Treiber f¨ ur die Grafikaufl¨ osung, den SCSI-Controller und Komponenten zum Reduzieren der virtuellen Festplatte auf optimale Gr¨ oße installiert. Jedoch stellt VMware nicht f¨ ur alle erdenklichen Betriebssysteme diese Tools zur Verf¨ ugung.

21.6.1

Unter Windows

1. Im ersten Schritt schiebt man die Installation der Tools ausserhalb des Gastes u ¨ ber die VMware-Men¨ uleiste an. Beim Aktivieren des Punktes ”VM->Install VM Tools ...” hängt VMware anstelle des CD-Laufwerkes ein ISO-Image mit den f¨ ur den Gast passenden Tools ein. Bei neueren Windows-Systemen startet der Wizard automatisch. 2. Im zweiten Schritt kann man die Art der Installation auswählen. ”Typical” sollte f¨ ur die meisten Anwender die beste Wahl sein. Die Tool-Installation kann jederzeit wiederholt werden, so dass man auch später weitere Komponenten hinzuf¨ ugen oder entfernen kann. 3. Im nächsten Schritt startet die Installation mit einem Klick auf den ”Install” Knopf. Man sieht die u ¨bliche Fortschrittsanzeige. Beim SVGA-Treiber kommt u ¨blicherweise die Meldung, dass dieser nicht automatisch konfiguriert wird. Das ist aber kein Problem, da am Ende des Vorganges eine detaillierte Beschreibung gegeben wird, wie man den Vorgang erfolgreich abschliesst. 4. Irgendwann ist der Wizard fertig und mit ”Finish” schliesst man den Vorgang ab. Dann wird automatisch der Einstellungsdialog f¨ ur den Bildschirm und die Anleitung was nun zu tun ist, eingeblendet. Es erfolgt ebenfalls der Windows-typische Hinweis neu zu booten, um die Prozedur zu vervollständigen. Anschliessend l¨ asst sich die Bildschirmauflösung auf sinnvolle Werte bringen. Das Ein- und Aushängen von Wechsellaufwerken und andere Vorgänge können nun u ¨ ber die VmwareTools in der Systemsteuerung vorgenommen werden.

21.6.2

Unter Linux

Wie f¨ ur Windows gibt es auch f¨ ur Linux Vmware-Tools. Sie k¨ ummern sich in erster Linie um die Hardwarebeschleunigung und stellen ein Kernelmodul f¨ ur die sogenannten Shared Folders bereit. Die Shared Folders erlauben Verzeichnisse des Host-Betriebssystems direkt im Gast einzubinden. Sobald Linux gestartet ist, kann wie f¨ ur Windows auch u upunkt ¨ber den Vmware-Men¨ ”VM->Install Vmware Tools ...” die Installation angestoßen werden. Unter Linux verläuft sie nicht automatisch. VMware tauscht das CD-Laufwerk aus und nach dem Mounten von diesem, beispielsweise durch das Wechseln nach /media/dvd, finden sich dort ein Archiv: vmware-linux-tools.tar.gz. Dieses kopiert man an eine Stelle, wo man es als Systemadministrator entpacken können. Das Einbinden der Tools unterscheidet sich in den ersten Schritten nicht vom Einrichten von Vmware unter Linux. Es m¨ ussen die Kernel-Quellen und der C-Compiler installiert sein. ur das KompilieEbenfalls m¨ ussen die Quellen mit make cloneconfig modules prepare f¨ ren der Module vorbereitet sein. Dann wechselt man in einen Runlevel ohne grafische Konsole, beispielsweise mit init 3. Im entpackten Archiv ruft man das Skript vmwaretoolsinstall.pl auf.

21.6. VMWARE-TOOLS

335

linux:/tmp # tar -xpzf vmware-linux-tools.tar.gz linux:/tmp # cd vmware-tools-distrib/ linux:/tmp/vmware-tools-distrib # ./vmware-install.pl Creating a new installer database using the tar3 format. Installing the content of the package. In which directory do you want to install the binary files? [/usr/bin] What is the directory that contains the init directories (rc0.d/ to rc6.d/)? \ [/etc/init.d] What is the directory that contains the init scripts? [/etc/init.d] In which directory do you want to install the daemon files? [/usr/sbin] In which directory do you want to install the library files? [/usr/lib/vmware-tools] The path "/usr/lib/vmware-tools" does not exist currently. This program is going \ to create it, including needed parent directories. Is this what you want? [yes] In which directory do you want to install the documentation files? \ [/usr/share/doc/vmware-tools] In which directory do you want to install the documentation files? \ [/usr/share/doc/vmware-tools] The path "/usr/share/doc/vmware-tools" does not exist currently. This program is \ going to create it, including needed parent directories. Is this what you want? \ [yes] The installation of VMware Tools 4.5.2 build-8848 for Linux completed successfully. You can decide to remove this software from your system at any time by invoking the following command: "/usr/bin/vmware-uninstall-tools.pl". Before running VMware Tools for the first time, you need to configure it by invoking the following command: "/usr/bin/vmware-config-tools.pl". Do you want this program to invoke the command for you now? [yes] Making sure services for VMware Tools are stopped. Stopping VMware Tools services in the virtual machine: Guest operating system daemon: done cat: /proc/pci: No such file or directory Trying to find a suitable vmhgfs module for your running kernel.None of the pre-built vmhgfs modules for VMware Tools is suitable for your running kernel. Do you want this program to try to build the vmhgfs module for your system (you \ need to have a C compiler installed on your system)? [yes] CC [M] /tmp/vmware-config1/vmhgfs-only/cpName.o CC [M] /tmp/vmware-config1/vmhgfs-only/cpNameLinux.o CC [M] /tmp/vmware-config1/vmhgfs-only/dev.o CC [M] /tmp/vmware-config1/vmhgfs-only/driver.o CC [M] /tmp/vmware-config1/vmhgfs-only/hgfsUtil.o CC [M] /tmp/vmware-config1/vmhgfs-only/main.o CC [M] /tmp/vmware-config1/vmhgfs-only/staticEscape.o LD [M] /tmp/vmware-config1/vmhgfs-only/vmhgfs.o Building modules, stage 2. MODPOST CC /tmp/vmware-config1/vmhgfs-only/vmhgfs.mod.o LD [M] /tmp/vmware-config1/vmhgfs-only/vmhgfs.ko make[1]: Leaving directory /usr/src/linux-2.6.8-24.10’ cp -f vmhgfs.ko ./../vmhgfs.o make: Leaving directory /tmp/vmware-config1/vmhgfs-only’

336


The module loads perfectly in the running kernel. Detected XFree86 version 0.0.0. Problem extracting verion of XFree 4 Execution aborted.

Leider sind die mitgelieferten VMware-Tools f¨ ur die meisten Distributionen zu alt, da sie nicht mit dem X.org klarkommen, welches die Rolle von XFree86 u ¨bernommen hat. Zusätzlich erwarten sie /proc/pci an der falschen Stelle. Es gibt aber inzwischen spezielle Skripten im Netz, die eine saubere Installation ermöglichen. Ohne diese ist auch kein allzu großes Problem, da X.org schon ein passendes X11Grafikmodul mitliefert. Damit zumindest ein Teil der Vmware-Tools aktiviert werden, entfernen man die Datei /etc/vmware-tools/not configured. /etc/init.d/vmware-tools start Starting VMware Tools services in the virtual machine: Switching to guest configuration: Guest filesystem driver: cat: /proc/pci: No such file or directory DMA setup: Guest operating system daemon:

done done done done

Nun muss noch ein mv vmware drv.o.BeforeVMwareToolsInstall vmware drv.o zur Reaktivierung des bereits installierten X11-Treiber sein. Nun kann man mit init 5 wieder in den Runlevel mit grafischer Oberfl¨ ache wechseln.

21.7

Spezielle Probleme

21.7.1

Mausbefreiung und Vollbildmodus

Die VMware-Workstation kennt zwei Darstellungs-Modi: Im Vollbild nimmt der Benutzer gar nicht mehr wahr, dass auf seinem Rechner eigentlich ein ganz anderes Betriebssystem läuft. Der Gast nimmt das komplette Bild ohne irgendwelche Ränder oder andere Zeichen ein. Dabei spielt die Bildschirmaufl¨ osung des Gast-OS solange keine Rolle, wie sie nicht die maximal m¨ ogliche Aufl¨ osung des Hosts u ¨bersteigt. So sieht man das BIOS ebenso im gewohnten Vollbild, wie die Startanzeige von Windows-XP im VGA und die spätere Sitzung in nochmal deutlich hochaufl¨ osender Darstellung. Das Vollbild kann direkt u ¨ ber die Werkzeugleiste getriggert werden. Es ist aber auch denkbar, Gäste so zu konfigurieren, dass sie automatisch beim Start in die volle Auflösung schalten. Das passiert in in den ”Virtual Machine Settings->Options->Power”. Fast alle Tastenkombinationen werden sinnvollerweise 1:1 an den Gast durchgereicht. Trotzdem gibt es M¨ oglichkeiten sich der VM gegen¨ uber bemerkbar zu machen: Die Maus kommt in der Standardeinstellung durch die Tastenkombination [Strg]-[Alt] wieder frei und die Maschine schaltet vom Vollbild- in den Fenstermodus. Alternative Kombinationen, wie beispielsweise [Strg]-[Alt]-[Shift] machen Sinn. Wenn ein Linux-Gast benutzt wird und die Umschaltung von der grafischen Konsole funktionieren soll, darf VMware die Kombination nicht verher abfangen. Die Einstellungen lassen sich u u ”Edit->Preferences¨ ber das Men¨ >Hot Keys” ver¨ andern. In den Preferences lassen sich weitere Anpassungen des Arbeitsplatzes, des Maus- und Display-Verhaltens sowie der Speicherreservierung u ¨ ber alle laufenden virtuellen Maschinen hinweg vornehmen.

21.7. SPEZIELLE PROBLEME

21.7.2

337

Zugriff auf USB

Eine wesentliche Verbessung schaffte VMware mit der USB-Unterst¨ utzung in der Version 5.0. Wurde in fr¨ uheren Versionen dieser Bus ganz ignoriert oder ging das Plug&Play verloren, so klappt es jetzt gut. Wichtig hierf¨ ur ist jedoch, dass nicht das Linux-System schon das Management des frisch angesteckten Gerätes u ¨ bernommen hat oder gerade u ¨bernimmt, wenn VMware l¨ auft. Das bedeutet, dass zwar die grundlegenden Treibermodule f¨ ur den oder die USB-Hostcontroller geladen sein d¨ urfen, aber nicht die Module f¨ ur die jeweilige Geräteklasse. ur USB-Sticks zuständig und holt sich So f¨ uhlt sich das Kernelmodul usb storage.ko f¨ sobald ein solcher Wechselspeicher eingesteckt wird den Zugriff. Das bleibt auch so, solange das Modul geladen ist. Helfen kann das einfache Entladen der Module vor dem Start von VMware, z.B. durch rmmod usb storage. Da das nur der Systemadministrator darf, ist der Weg nicht sonderlich elegant. Komplexer wird die Geschichte durch das neue Hotplug-System. Diese Architektur u ¨bernimmt im Hintergrund das automatische Laden von notwendigen Modulen, um frisch angesteckte Geräte verf¨ ugbar zu machen. Hier kann sich der Admin mit einem Trick behelfen: Unter SuSE u ¨ bernimmt das Skript /etc/hotplug/usb/50-usb.hotplug diese Aufgaben. Der Eintrag ps aux |grep -i vmware| grep -v "grep"&>/dev/null && exit 0 verhindert, dass USB-Hotplug aktiv wird, solange VMware l¨ auft. Leider entl¨ adt Hotplug unn¨ otig gewordene USB-Module nicht automatisch. Dann kann es passieren, dass die Nutzung eines USB-Speichers unter Linux die anschliessende Nutzung unter VMware erschwert. Die USB-Unterst¨ utzung muss bei VMware nicht speziell eingeschaltet werden, das Vorhandensein von USB-Treibern im Hostsystem wird automatisch erkannt. VMware stellt jedoch unabhängig vom Hostcontroller seinen Gästen nur ein USB1.1-Interface zur Verf¨ ugung. Firewire-Devices bleiben unter VMware weiterhin aussen vor.

21.7.3

Datenaustausch zwischen Host und Gast

Aus Sicht der beiden Betriebssysteme, des Gasts und des gastgebenden in dem VMware läuft unterscheidet sich das Szenario nicht von zwei völlig getrennten Rechnern. Die klassischen Wege des Datenauschtausches sind entsprechend Netzwerk und Wechseldatenträger. Die Netzwerkkarte im virtuellen Rechner kennt, wie schon an anderer Stelle erklärt, die Modi ”bridged”, ”hostOnly” oder ”nat”. Sie bestimmt u ¨ber die Art, wie das Gastbetriebssystem auf das Netzwerk zugreifen kann. Die erste Option ist in den meisten Fällen die interessanteste, weil dann eventuell im Netz schon vorhandene DHCP-Server vom ClientOS transparent mitgenutzt werden kann. Nach ”aussen” verhält sich die virtuelle Maschine identisch zur realen. Soll das Gast-Betriebssystem gesch¨ utzt ins Netz gehen oder ist keine IP-Adresse im Netz zusätzlich erh¨ altlich ist ”nat” ein guter Kompromiss. Soll der Gast gar keinen Zugriff auf die Aussenwelt erhalten, ist die ”hostOnly”-Variante vorzuziehen. F¨ ur die beiden letzteren kann VMware einen eigenen DHCP-Server auf den vmnet* Interfaces starten. Die Konfiguration f¨ ur diese Varianten stellt man bereits beim Ablauf von vmware-config.pl ein. Sie findet sich ¨ in der Datei /etc/vmware/locations oder /etc/vmware/config. Uber das konfigurierte Netz lassen sich dann Daten auf dem gewohnten Wege austauschen. Wechseldatentr¨ ager, wie CD-Rom, Disketten oder USB-Stick lassen sich abwechselnd vom Gast und Gastgeber aus nutzen. Dabei m¨ ussen CDs oder Disketten noch nicht einmal reale Hardware sein. Ihre Images gehen auch. So bindet man beispielsweise unter Linux ein Abbild einer DOS-Diskette ein: mount -t msdos -o loop boot-dos6.2.flp /misc/loop

338


F¨ ur geeignete Kombinationen von Gast- und Hostsystemen kennt VMware seit der Version 4 auch eine Abk¨ urzung. Diese heisst SharedFolders und meint die Möglichkeit Verzeichnisse des Host-Dateisystems direkt im Gast, beispielsweise einer WindowsXP-Installation, sichtbar werden zu lassen.

Kapitel 22

Drucken im Netzwerk 22.1

Einleitung

Zum Drucken unter Unix gibt es verschiedene Ansätze: • BSD-System • System V • CUPS Das BSD-System ist historisch gesehen das älteste und war lange bei SUN-Systemen im Einsatz. Das System V Drucksystem sollte mehr den Bed¨ urfnissen 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.

22.1.1

Anforderungen

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önnen. Hier besteht ein wesentlicher Unterschied zu MS-Windows-Systemen. Dort gibt es nur das Programm print im Kommandomodus um Textdateien auszudrucken. Das Kommando lpr unter Linux war urspr¨ unglich auch nur f¨ ur Textdateien ausgelegt, wurde aber durch Erweiterung um Filter ind die Lage versetzt, andere Formate zu verarbeiten. (s. Kap. 22.2.4) 339

340

KAPITEL 22. DRUCKEN IM NETZWERK

22.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 man den gew¨ unschten Drucker beim Aufruf mit angeben: lpr -Pdruckername textdatei Beim Aufruf von lpr werden die angegebenen Optionen interpretiert und angewendet. Anschliessend sorgt lpr daf¨ ur, dass die Datei in das Spoolverzeichnis des angegebenen Druckers geschickt wird. Der Spooler (fr¨ uher 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 mit der Installation des Betriebssystems bzw. Drucksystems zur Verf¨ ugung gestellt. Auch CUPS stellt eine Reihe von PPD-Dateien zur Verf¨ ugung. 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¨ ur die Ausgabe des PostScriptCodes sorgt. Bei PostScript-f¨ ahigen Druckern ist der RIP im Drucker integriert, bei nichtPostScript-kompatiblen Druckern wird ein Post-Script-Interpreter benötigt, der aus den PostScript-Informationen ein Datenformat erzeugt, das vom jeweiligen Drucker verstanden wird. Dieser Interpreter wird durch den druckerspezifischen Treiber zur Verf¨ ugung gestellt. Die Funktionsweise des Treibers geht aber nat¨ urlich u ¨ ber das Erzeugen des richtigen Datenformates weit hinaus. Aufgabe des Treibers ist es, die zu druckende Datei um all die Informationen zu erg¨ anzen, die f¨ ur die optimale Nutzung der Hardware nötig sind. Diese Beschreibung der Funktionsweise des Drucksystems ist nat¨ urlich stark vereinfacht. Bei der genaueren Betrachtung des CUPS (Common Unix Print System) werden die Zusammenhänge detailliert beschrieben. Unter den verschiedenen Systemen zur Konfiguration und Administration des Drucksystems unter Linux wird CUPS am häufigsten verwendet. Es eignet sich sowohl f¨ ur die Konfiguration von Einzelplatz Rechnern/Druckern, als auch f¨ ur komplizierte Systeme im Netzwerk.

22.2

CUPS

Im CUPS (Common Unix Printing System) u ¨ bernimmt der cupsd die Aufgaben des lpd: Annehmen der Druckauftr¨ age, 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¨ ugung: • Authentifizierung von Benutzern ¨ • Verschl¨ usselung der Druckdaten bei der Ubertragung

22.2. CUPS

341

• Bekanntgabe verf¨ ugbarer Drucker im Netz IPP ist ein Protokoll der Anwendungsschicht und kann f¨ ur verteiltes Drucken im Interund Intranet verwendet werden. Das Protokoll definiert die Interaktion zwischen CUPSServer und -Client und erm¨ oglicht dem Client Abfragen von Druckerinformationen.

22.2.1

Client-Server-Architektur

Im CUPS ist jeder Rechner, an dem 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 auch sein eigener Server ist. Jeder Server ist selbst f¨ ur die Aufbereitung der Druckjobs zuständig, d.h. jeder Server muss sowohl die f¨ ur das Druckformat des Druckers nötigen Filter, als auch den entsprechenden Treiber selber zur Verf¨ ugung 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¨ asst sich der CUPS Dämon wie ein Webserver ansprechen. CUPS-Rechner kommunizieren u ¨ber den IPP-Port 631. Der Zugriff auf das Webinterface erfolgt folglich u ¨ ber den Browser durch den Aufruf http://localhost:631/. An diesen Port werden nicht nur die Druckdaten geschickt, sondern auch viele weitere Informationen. Da IPP auf HTTP 1.1 beruht, ist die Konfigurationsdatei /etc/cups/cupsd.conf der httpd.conf sehr ¨ ahnlich. Die wichtigsten Einstellungen werden in Kapitel 22.2.5 erläutert. Eine weitere Besonderheit von CUPS sind die Backends. Sie sorgen f¨ ur den Versand von Druckdaten zu den Ausgabeger¨ aten oder anderen Servern. Die CUPS-Backends ermöglichen die Verbindung u ur jedes ¨ ber verschiedene Schnittstellen und Protokolle mit dem Server. F¨ Protokoll (parallel, seriell, USB oder Neztwerk) ist ein eigenes Backend zuständig. Die CUPS-Backends erlauben so, Druckjobs an alle herkömmlichen Drucker zu schicken.

Abbildung 22.1: Cupsdiagramm

22.2.2

IPP

IPP ist ein Protokoll der Anwendungsschicht und wird in erster Linie f¨ ur verteiltes Drucken im Netz verwendet. Das Protokoll definiert die Interaktion zwischen IPP-Client und IPPServer, d.h. es wird definiert, wie die Daten f¨ ur die Steuerung des Druckvorgangs verwendet werden, wie die Daten kodiert und wie sie transportiert werden. Der Datentransport mit IPP ist generell verschl¨ usselt. Desweiteren definiert IPP das s.g. Verzeichnisschema, u ¨ ber das ein Verzeichnisserver nach verf¨ ugbaren Ausgabegeräten gefragt werden kann. Ausserdem bietet IPP die Möglichkeit, den Zugriff auf Drucker einzuschränken.

342

22.2.3


Funktionsweise

Die Kommunikation zwischen Client und Server erfolgt gemäß dem bekannten RequestResponse-Verfahren. Diese Anfragen und Antworten sind durch ASCII Code definiert und werden mittels des HTTP 1.1 Postmechanismus durchgef¨ uhrt. Ein Request des Clients sieht wie folgt aus: ipp:druck.server/meindrucker/meindruckauftrag und f¨ uhrt dazu, dass der Client eine Verbindung zu Port 631 des Servers druck.server aufbaut und folgende Daten u ¨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” ...

22.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 in welcher Reihenfolge angewendet werden m¨ ussen. Lediglich das Ausgabeformat muss man eintragen, sofern man ein anderes Format als PostScript verwenden möchte. (PostScript ist standardm¨ assig vordefiniert.)

22.2.5

Konfiguration

Die Konfiguration von CUPS kann - wie bereits erwähnt - u ¨ 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¨ ur 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¨ ugung. Hierbei sollte man nicht ausser Acht lassen, dass die Broadcasts (entsprechend der TCP/IP-Spezifikation) nur bis zum nächsten Router oder Gateway weitergegeben werden. Wenn bei einem bestimmten Client nur die BrowsingInformationen eines bestimmten Servers verwendet werden sollen, kann man das in der

22.3. ALTERNATIVEN

343

Konfigurationdatei des Client durch Einträge der folgenden Art erreichen: BrowseAllow 134.76.82.10, BrowseDeny 134.76.82.11. Das Gegenst¨ uck zum Browsing (per Broadcast) ist das Polling. In diesem Fall warten die Clients nicht passsiv auf die Informationen u ugung stehende Drucker, sondern ¨ber zur Verf¨ 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¨ uhrt, dass der genannte Server nach verf¨ ugbaren Druckern gefragt wird, sobald gedruckt werden soll. Beim Polling gilt allerdings dieselbe Einschr¨ ankung 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.

22.3

Alternativen

Zu den heute g¨ angigen Alternativen zu CUPS zählen: • TurboPrint: Ein kommerzielles Drucksystem, mit dem man bestmögliche Druckqualität erreichen kann. N¨ ahere Informationen unter www.turboprint.de • KDEPrint: Ein Modul der KDE-Oberfläche unter Linux. Es ermöglicht einen einfachen und intuitiven Zugriff auf s¨ amliche CUPS-Funktionalitäten. Nähere Informationen unter printing.kde.org

344


Kapitel 23

IPv6 23.1

Einleitung

Vielfach angek¨ undigt aber trotdem noch nicht weitflächig im Einsatz: IPv6, das nächste Generation Internet Protokoll, verharrt weiter in seinen Nischen ohne die Maschinen der inzwischen sehr großen Zahl der Internet-Benutzer wirklich zu erreichen. Seit seiner Definition durch das erste IPv6-RFC 1883 im Jahre 1995 und detailliertere Festlegungen und Konkretisierungen im Dezember 1998 durch RFC 2460, wurde IPv6 immer wieder angek¨ undigt.1 Dabei gab und gibt es gute Gr¨ unde vom sehr erfolgreichen IPv4 langfristig umzusteigen: • Das Internet hat in den letzten Jahren einen enormen Boom erfahren und dabei rasant an Grösse zugenommen. Dadurch haben sich änderungen in seiner Struktur vollzogen. Aus einem reinen Wissenschafts- und Forschungs-Computernetzwerk ist ein gewaltiges Informationsnetz mit Millionen ganz normalen Benutzern geworden. Jederman kann mittlerweile an fast jedem Ort der Welt auf das Internet zugreifen. • Hinzu kommt die Vielfalt multimedialer Datenströme, wie derzeit gerade Voice over IP stark oder auch Video on Demand. Damit einher geht eine Integration der ursrp¨ unglich streng getrennten Telefon- und IP-Datennetze. Betrachtet man die vielen Telefonanschl¨ usse weltweit, die ergänzt werden durch eine stark steigende Zahl von Mobiltelefonen, wird es eng mit einer Abbildung von Telefonnummern in den bestehenden 32 bit IP-Adressraum. Gemessen an der Schnelllebigkeit vieler Software-Produkte und Technologien hält sich das Internet Protokoll IPv4 seit 30 Jahren. Aufgrund seiner soliden Struktur war es in der Lage, die wachsenden Anforderungen zu erf¨ ullen. Doch der Zeitpunkt an dem IPv4 den gewachsenen Anforderungen nicht mehr gerecht werden kann, wird immer wieder prophezeit. Als wichtiger Grund f¨ ur die Ablösung wird der zu knappe Adressraum genannt: ¿Pv4-Adressen nutzen ja noch nichteinmal die theoretisch möglichen 4,5 Milliarden Adressen wirklich aus. Es entfallen spezielle Netze, wie 0.X.Y.Z, 127.X.Y.Z und 224.0.0.0 aufw¨ arts. Adressen, die mit ”0” beginnen sind reserviert f¨ ur den Start von Maschinen vor der dynamischen Adresszuweisung. Das gesamte Netz, welches mit der ”127” beginnt, ist f¨ ur die Loopback-Adresse(n) reserviert. Von ”224” bis ”239” reicht der Bereich f¨ ur Multicast-Adressen. Der Adressraum ab ”240” ist f¨ ur experimentelle Zwecke reserviert und kann nicht genutzt werden. Zusätzlich fallen bestimmte Adressräume f¨ ur sogenannte private Adressen weg: 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255 1

Neuere Artikel verschieben das Ende der IPv4-Adressen inzwischen auf 2022 ([W1]) oder sogar bei 2045 ([W2]).

345

346

KAPITEL 23. IPV6

und 192.168.0.0 - 192.168.255.255. Die Adressen 169.254.0.0 - 169.254.255.255 dienen zur IP-Autokonfiguration, ein Konzept, welches bei IPv6 vorgesehen ist und f¨ ur IPv4 Ende der 90er Jahre ”nachger¨ ustet” wurde. Die Erfolge zur besseren Ausnutzung des derzeitigen Adressraumes schieben die Umstellung vermutlich nur heraus. Selbst mit dem exzessiven Einsatz von Privaten Netzen,2 das Classless Interdomain Routing3 und die Aufteilung der alten Klasse-A Netze ist irgendwann Schluss. Hinzu kommt ein ineffizientes Routing. Da es keine wirkliche geografische Adressaufteilung gibt, werden die Routing Tabellen ziemlich lang. Das wird noch verschärft durch die Auflösung der alten Klasse-A-Netze und deren Verteilung. Viele Haushalte selbst in Europa und Amerika sind noch nicht mit dem Internet verbunden. Dieses ändert sich rapide, besonders wo neue Dienste und Ger¨ ate mit Forderung nach Adressierbarkeit u ¨ber das Internet hinzukommen. Nicht zu vergessen ist ebenfalls der Aufstieg der Kontinente neben den traditionellen Internet-Hochburgen Nordamerika und Europa mit einer bedeutend größeren Bevölkerung als die der ”Neuen Welt” und des ”Alten Europas”. Zusätzliche Argumente sind die fehlende Sicherheit der IPv4 Adressen und die schlechte Unterst¨ utzung mobiler Endger¨ ate. Hier soll IPv6 bessere Antworten finden.

23.1.1

Die Vorgeschichte

IPv6 wird als das ”next generation internet protocol” bezeichnet. Vorversionen wurden damals IP - Next Generation (IPng) benannt. Es gab verschiedene Vorschläge zur Definition des IPng: • TUBA - (TCP und UDP mit gr¨ oßeren Adressen) - Die Idee das OSI verbindungslose Protokoll als Ersatz zu nehmen, erfreute nicht alle Beteiligten. • SIP - Simple Internet Protocol Plus ¿ Vorgänger des IPv64 Der Name IPv5 war bereits f¨ ur das Stream Protocol der Version 2 vergeben, weshalb die nächste freie Nummer genommen wurde und der Name nun IPv6 lautet. Das neue IP sollte ein evolution¨ arer Schritt von IP v4 sein. Es soll sich quasi als ”Software-Update” f¨ ur bestehende Komponenten verhalten.

23.2

IPv6

IPv6 soll nicht alles anders machen als IPv4, aber mindestens vieles besser. Das neue Internet-Protokoll will kein v¨ ollig neues Netzwerk definieren, sondern lediglich IPv4 in seiner Protokollschicht austauschen. Die neuen Ideen schlagen sich in erster Linie im ProtokollHeader nieder. Um der Adressknappheit ein f¨ ur allemal ein Ende zu bereiten, wurde weit ausgeholt: Adressen sind nun 128 bit lang. Das ergibt einen nahezu unerschöpflichen Adressraum. Gerechnet auf eine derzeitige Erdbev¨ olkerung von ca. 6 Milliarden Menschen, erhält man 28 dann ca. 1.6 * 10 Adressen pro Mensch. Das sind wiederum mehr, als die Anzahl der Atome, aus denen ein Mensch besteht. Der Hauptgrund, warum der Adressraum derart gross gewählt wurde, ist eine zusätzliche Funktion. Durch die grossen Reserven entsteht die Möglichkeit der Autokonfiguration. 2 Durch die vielfache Nutzung der privaten Adressbereiche werden selbst f¨ ur große Organisationen oft nur ein paar ”reale IP-Adressen” f¨ ur die Router, NAT und angebotene Dienste ben¨ otigt. 3 die alte statische Aufteilung in Klasse-A,B,C-Netze entf¨ allt. Netze k¨ onnen nun quasi beliebig geschnitten sein. 4 SIP steht heute f¨ ur Session Initiation Protocol - benutzt f¨ ur Voice-over-IP und Internet-Telefonie

23.2. IPV6

347

Abbildung 23.1: Die Migration von IPv4 zu IPv6 aus Sicht des OSI-Modells D.h., es m¨ ussen nicht mehr bestimmte Adressen zugewiesen werden, sondern ein sich einwählender Knoten kann sich seine Adresse unter bestimmten Voraussetzungen selbst wählen, bzw. sie auf seine bestehende Netztwerkinterface-Adresse abstimmen. Aber der neue, grosse Adressraum war nicht das einzige Ziel der Entwickler von IPv6. Eine weitere wichtige Neuerung ist die Vereinfachung des Headers. So wurde der neue Header im Vergleich zu seinem Vorg¨ anger in seiner Struk-tur deutlich schlanker5 , indem man sämtliche Optionen in Erweiterungsheader ausgegliedert hat. So kann die u ¨bertragung von Standardpaketen an den Routern deutlich schneller vollzogen und Optionen flexibler und effektiver eingesetzt werden. Dar¨ uberhinaus lassen sich zuk¨ unftige Optionen einfacher integrieren. Im IPv6-Header direkt erhalten blieben die Protokoll-Version sowie die Quellund Zieladresse. Weiterhin sollten verbesserte u ¨bertragungen von Multimediaddatenströmen und eine bessere Einbindung von mobilen Teilnehmern ermöglicht werden. Zuletzt wurden auch noch spezielle Header f¨ ur Verschl¨ usselung und Authentifizierung entwickelt.

23.2.1

Das neue Headerformat

¨ Mit IPv6 gab es eine Reihe wichtiger Anderungen im Header: In erster Linie soll dadurch eine schnelleren Bearbeitung in Routern möglich werden. Andere Felder wie Header-Länge, Type of Service und Header Pr¨ ufsumme wurden gestrichen. Die Header Pr¨ ufsumme wurde f¨ ur u ussig erachtet. Pr¨ ufsummen bilden schon UDP und TCP oder Layer 2 Protokolle ¨ berfl¨ wie Ethernet. Die Header-Felder im Einzelnen: 5

das bezieht sich nicht auf seine Gesamtl¨ ange. Hier wurde er aufgrund der vierfach l¨ angeren Adressen sogar vergr¨ ossert

348

KAPITEL 23. IPV6

Abbildung 23.2: Die Unterschiede von IPv4 zu IPv6 Headern • Version (4 Bit) - Dieses Feld gibt an, welches Protokoll zugrunde liegt, in diesem Fall eine bin¨ are 6. • Traffic Class (8 Bit) - Das Traffic Class Feld dient dazu, unterschiedliche Klassen von ¨ IPv6 Paketen zu erkennen und zu unterscheiden, um eine Ubertragung mit unterschiedlichen Priorit¨ aten zu erm¨ oglichen. Dieses Modell stammt aus dem Bereich der ATM-Netze. • Flow Label (20 Bit) - Ein Flow ist eine Folge von zusammengehörenden Datagrammen. Um einen Flow zu kennzeichnen wird jedem Datagramm die Nummer des Flows zugeordnet. Geh¨ ort ein Datagramm zu keinem Flow, so enthält das Flow Label Feld ¨ nur Nullen . Somit k¨ onnen bessere Möglich-keiten zur Ubertragung von Real-timeAnwendungen erzeugt werden. • Payload Length (16 Bit) - L¨ ange der Daten, die nach dem Header folgen (in Byte). Darin enthalten sind auch Erweiterungs-Header. Somit ist wie bei IPv4 auch eine Nutzdatengr¨ osse von 65536 Byte m¨ oglich. Noch grössere Datagramme können mit der Jubmo-Payload Option erreicht werden. Hier gibt es jedoch Kompatibilitätsprobleme zum bestehenden TCP. • Next Header (8 Bit) - Legt fest, welcher Headertyp im Anschluss folgt. • Hop Limit (8 Bit) - Wird von jedem Router um eins dekrementiert. Erreicht der Wert ”0”, wird das Datagramm verworfen. • Source Adress (128 Bit) - Die 128 Bit Adresse des Absenders. • Destination Adress (128) Die 128 Bit Zieladresse. Da eine Reihe von Funktionalit¨ at, beispielsweise die Fragmentierung, anders gehandhabt wird und ausgelagert wurde, spielen Erweiterungsheader eine Rolle. So verfolgt beim Umgang mit Optionen IPv6 ein neues Konzept. u ussige Informationen werden aus dem ¨berfl¨ Header entfernt. u ¨brig bleibt nur das, was zum u ¨ bertragen eines Standarddatagramms notwendig ist. Zus¨ atzliche Optionen werden erst in den Erweiterungsheadern festgelegt. Diese stehen in einer vorgegebenen Reihenfolge zwischen dem Haupt-Header und den Nutzdaten. Dieses Konzept hat zwei Vorteile. Erstens können zuk¨ unftige Erweiterungen und Optionen einfach integriert werden, und zweitens werden nur die Informationen beispielsweise von den Routern ausgewertet, die notwendig sind. So stehen zum Beispiel alle Daten, die

23.2. IPV6

349

Abbildung 23.3: Der IPv6 Header nur den Sender und den Empf¨ anger betreffen, nach dem Routingheader. Router hingegen bearbeiten ein Paket gerade bis zu diesem Header. Derzeit gibt es 6 Erweiterungsheader: • Hop-by-Hop Options Header • Destination Options Header (1) • Fragment Header • Destination Options Header (2) • Authentication Header • Encapsulating security Payload Header Bis auf den Destination Options Header darf jeder Header nur einmal oder gar nicht vorkommen. Jeder Header wird durch die Next Header Nummer des vorangegangenen Headers angek¨ undigt. Die folgende Tabelle zeigt eine u ¨bersicht - die Header-Nummern sind kompatibel zum bisherigen Standard gew¨ ahlt. Der letzte Header - gibt es keine Optionsheader, ist das nat¨ urlich der Hauptheader - zeigt auf den Header des u ¨bergeordneten Protokolls, ähnlich wie in der Protokollfunktion in IPv4. Um einen weiteren Zeitgewinn zu erzielen, gibt es innerhalb der Erweiterungsheader ein standardisiertes Optionsfeld, das sogenannte Type-Length-Value (TLV) Optionsfeld. Es besteht aus einem 8 bit Optionsbezeichner, einem 8 bit Längenfeld6 , und den Optionsdaten. Diese können eine variable L¨ ange von bis zu 255 Bytes haben. Ebenso wie die Header, m¨ ussen die Optionen der Reihe nach abgearbeitet werden. Ist eine Option f¨ ur einen Knoten unbekannt, werden die ersten zwei Bit des Optionstyps herangezogen. Sie besagen: • ”00” - Diese Option kann u ¨bersprungen werden 6

muss eine Option u achste Option verwendet ¨bersprungen werden, wird der Eintrag als Pointer auf die n¨

350

KAPITEL 23. IPV6 Header Hop-by-Hop-Options TCP UDP Encapsulated IPv6 Routing Fragment Resource Reservation Encapsulated Security Payload Authentication ICMPv6 No next Destination Option

Dezimalwert 0 6 17 41 43 44 46 50 51 58 59 60

Tabelle 23.1: Die verschiedenen Folge-Header mit Protokoll-ID • ”01” - Das gesamte Paket muss verworfen werden • ”10” - Das gesamte Paket muss verworfen werden und es muss eine ICMP-Fehlermeldunggesendet werden • ”11” - Das gesamte Paket muss verworfen werden und es muss eine ICMP-Fehlermeldung abgesetzt werden, wenn die Zieladresse keine Multicastadresse war Das dritte Bit des Optionstypfeldes gibt an, ob die Optionsdaten verändert werden d¨ urfen oder nicht. Hat ein TLV- Feld nicht das notwendige 32 bit Format, muss es durch eine der zwei Paddingfunktionen (Pad1 und PadN) mit Nullen aufgef¨ ullt werden. Dabei f¨ ullt Pad1 bis zu einem Byte auf, PadN kann mehrere Bytes auff¨ ullen. Hop-by-Hop Options Header In dem Hop-by-Hop Options Header werden zusätzliche Optionen, die von allenKnoten entlang des Kommunikationspfades verarbeitet werden definiert. Ein Hob-by-Hop Options Header wird durch einen Next Header = 0 Eintrag im Hauptheader festgelegt. Derzeit ist lediglich eine Hop-by-Hop Option implementiert, die Jumbo-Payload-Option. Durch sie k¨ onnen sogenannte Jumbogramme, d.h. Datagramme, die ein Nutzdatenfeld zwischen 65.535 und 4.294.967.295 Byte haben, verwendet werden. In der nachstehenden Abbildung ist ein Hop-by-Hop Options Header miteinem JumboPayload-VLT-Option Feld zu sehen. • Option Next Header (8 Bit) - Gibt den Typ des nächsten Header an • Hdr Ext Len (8 Bit) L¨ ange des Hop-byHop Options Headers in 8 Byte-Einheiten ohne die ersten 8 Byte • Option Type (8 Bit) Wert ”C2” Hexadezimal (194 Dezimal), steht f¨ ur dieJ-P-Option Option Data Len (8Bit) Wert 4. Gibt die Länge des J-P-Optionsdatenfeldes in Bytes an • Jumbo Payload Length (32 Bit) Gibt die Länge des Jumbogramms in Bytes an (65.536 - 4.294.967.295).

23.2. IPV6

351

Abbildung 23.4: Hop-by-Hop Option Header mit Jumbo-Payload Der Routing Header Der Routing Header ähnelt von der Funktionsweise den IPv4 Loose Source und Record Route Optionen. Er ist folgendermassen aufgebaut: • Next Header (8 Bit) Gibt den Typ des nächsten Header an • Hdr Ext Len (8 Bit) L¨ ange des Hop-byHop Options Header in 8 Byte Ein-heiten ohne die ersten 8 Byte • Routing Type (8 Bit) Gibt den Typ des Routingheaders an. Derzeit ist nur der Typ 0 implementiert. Trifft ein Router auf einen unbekannten Routing Type, muss er sein weiteres Vorgehen nach dem Segments-Left Eintragrichten. Bei segments-Left = 0 wird der Routing Header ignoriert, bei ”1” muss das Datagramm verworfen werden und eine ICMP-Fehlermeldunggesendet werden. • Segments Left (8Bit) Anzahl von verbleibenden Routsegmenten. z.B. Knoten,die bis zum Ziel angesteuert werden m¨ ussen • type-specific data (variabel) - Abhängig vom Routing Type. Ein Typ 0 Routing Header hat folgendes Format: Next Header, Hdr Ext Len, Routing Type 0, Segments Left, Reseved (32 Bit) - reserviert f¨ ur zuk¨ unftige Verwendung Address[1..n ] Adressvektor mit den Adressen 1 bis n. In einem Routing Header, oder in einem IPv6 Header eines Datagramms mit Routing Header, d¨ urfen keine Multicastadressen stehen. Router verarbeiten IPv6 -Datagramme nur bis zu dem Routing Header. Die folgenden Header werden nur von Start- und Zielknoten bearbeitet. Fragment Header Der Fragment Header dient dazu, Datagramme, die grösser als die Pfad-MTU sind, zu u ¨ bertragen. Dabei zerteilt der Startknoten die Datagramme in, der Pfad-MTU entsprechende, Fragmente, die dann von dem Zielknoten wieder zusammengesetzt werden. Im Gegensatz zu IPv4 ist also ausschliesslich der Ausgangsrechner f¨ ur die Wahl der richtigen Paketgr¨ osse zust¨ andig. Router d¨ urfen keine weitere Fragmentierung vornehmen. Der Header hat folgendes Format:

352

KAPITEL 23. IPV6 • Next Header (8 Bit) - Gibt den Typ des nächsten Header an • Reserved (8 Bit) Reserviert f¨ ur zuk¨ unftige Verwendung. Wird mit Nullen belegt • Fragment Offset (13 Bit) - Gibt die Position des Fragments innerhalb des gesamten Datagramms in 8 Byte Einheiten an. • Res (2Bit) Ein weiteres reserviertes Feld. M flag (1 Bit) 1: Es gibt noch mehr Fragmente, 0: Es handelt sich um dasletzte Fragment • Identification (32 Bit) - In Verbindung mit Sende- und Empfängsadresse ein-deutige Identifizierung eines Datagramms.

Hat ein sendender Host erkannt, dass das Datagramm, welches er verschicken will, grösser als die Pfad-MTU7 ist, muss er es fragmentieren. Dabei bestehen Datagramme aus einem nicht fragmentierbaren (die Daten vor und innerhalb des Fragment Headers) und einem fragmentierbaren Teil (Daten hinter dem Fragment Header). Somit wird nur der fragmentierbare Teil in Pakete geeigneter Grösse zerteilt. Dabei m¨ ussen alle Fragmente, bis auf das letzte, eine L¨ ange haben, die einem Vielfachen von 8 Bytes entspricht. Im nächsten Schritt wird der nichtfragmentierbare Teil, der noch vor dem ersten Fragment steht, kopiert und vor alle anderen Fragmente gesetzt. Jetzt können alle Fragmente als eigenständige Datagramme geeigneter Gr¨ osse mit allen relevanten Daten u ¨ ber Sender, Empfänger und Route verschickt werden. Die Situation wird in der Abbildung dargestellt. Um sicherzustellen, dass jedes Fragment dem richtigen Datagramm zugeordnet werden kann, erhält es eine Idetifikationsnummer. Diese muss in Verbindungmit den Sende- und Empfangsadressen eindeutig sein. Da die IP-Adressen eindeutig sind, muss also noch gewährleistet werden, dass, solange ein Datagrammexistiert, zwischen dem Sender und dem Empfänger dieses Datagramms keinweiteres Datagramm mit der gleichen Identifikationsnummer verschickt wird. Dies geschieht dadurch, dass die Identifikationsnummer durch einen Zähler bestimmt wird. Dieser Z¨ ahler wird jedesmal, wenn ein Datagramm fragmentiert werden muss, um eins erhöht. Bei 32 bit k¨ onnen also ca. 4,3 Milliarden Datagramme fragmentiert werden, bis sich eine Identifikationsnummer wiederholt. Es gibt jedoch kein Datagramm, das eine so lange Lebensdauer hat. Sind nun bei einem Empf¨ anger l¨ uckenlos Fragmente eingegangen (die Reihenfolge spielt dabei keine Rolle), und steht das M-Bit des letzten Fragments auf 0 (es folgen also keine weiteren Fragmente), kann der Empf¨ anger die Pakete wieder in der richtigen Reihenfolge zusammensetzten, indem er sie an die Stelle setzt, die von dem Sender in dem Fragment Offset angegeben wurde. Die Original-Payloadlänge kann aus der Länge des nichtfragmentierbaren Teils des ersten Fragments und der Länge und dem Offset des letzten Fragments berechnet werden.

23.2.2

Destination Options Header

Der Desination Options Header wird f¨ ur zusätzlich Optionen verwendet, die einen Empfänger betreffen. Dabei gibt es zwei Varianten. Bei dem ersten Typ sind die Optionen ausschliesslich f¨ ur einen empfangenden Endknoten bestimmt. Somit ist es nicht notwendig, dass Router Kenntnis von diesem Header nehmen. Er darf auch fragmentiert werden und steht daher hinter dem Fragment Header. 7

Die minimale Path-MTU ist mit 576 oder 1280 Byte(?) festgelegt

23.3. IPV6 ADRESSEN

353

Die zweite Variante betrachtet auch Router als Empfänger. Dadurch können zielorientierte Optionen, die Router betreffen ausgedr¨ uckt werden. Damit Router diese Informationen erhalten k¨ onnen, muss diese Variante vor dem Routingheader stehen. Der Destination Options Header ist der einzige Header, der zweimal vorkommen darf.

23.2.3

Encapsulating Security Payload und Authentication Header

Das IPsec, welches f¨ ur IPv4 definiert wurde, leitet wesentliche Eigenschaften aus der Spezifikation f¨ ur IPv6 ab. Es wurde quasi ”backported”. Damit können die von IPv4 bekannten IPsec-Konzepte f¨ ur Encapsulted Security Payload (ESP) und Authentication Header (AH) direkt auf IPv6 angewandt werden.

23.3

IPv6 Adressen

IPv6 Adressen sind 128 bit lang und werden nicht Hosts, sondern Interfaces zugeordnet. Da kein Interface von zwei Hosts benutzt wrd, ist somit auch eine eindeutige identifizierung der Hosts möglich. Es sind drei unterschiedliche Klassen von IPv6 Adressen definiert. • Unicast Adressen - Dieser Adresstyp wird genau einem Interface zugeordnet. Er entspricht dem von IPv4 bekannten Typ einer normalen IP-Adresse. • Anycast Adressen - Diese Art von Adressen wird mehreren Interfaces zugeordnet. Wird ein Paket an eine Anycast Adresse geschickt, wird es bei nur einem, und zwar ¨ dem nächstm¨ oglichen Interface, abgeliefert. Dieser Adresstyp ist neu. Ahnliches wurde unter IPv4 unter Zurhilfenahme von DNS realisiert. So kann die Antwort auf www.google.com durchaus unterschiedlich ausfallen, da die IP-Adressen im RoundRobin-Verfahren zur¨ uckgeliefert werden. Viele Sites implementieren so eine einfache Form der Lastverteilung und des Clusterings von Diensten. • Multicast Adressen - Die Adresse wird mehreren Interfaces zugeordnet. Multicast Pakete werden an alle Interfaces mit der entsprechenden Adresse abgeliefert. F¨ ur jedes Inteface gilt, dass es mindestens eine link-lokale Unicast Adresse haben muss. Folglich sind mehrere Adressen unterschiedlichen Typs f¨ ur ein Interface möglich.

Abbildung 23.5: IPv6 Aufteilung des Adressraumes Der Typ einer IPv6 Adresse wird durch die ersten Bits identifiziert.

354

KAPITEL 23. IPV6 Adresstyp Unspezifiziert Loopback Multicast Link-local Unicast Site-local Unicast Global Unicast

Präfix 000...0 (128 Bits) 000...1 (128 Bits) 11111111 11111111010 1111111101 Rest

IPv6 Notation ::/128 ::1/128 FF00::/8 FE80::/10 FEC0::/10

Tabelle 23.2: Verschiedene Typen von IPv6 Adressen und ihre Identifikation Auch IPv6-Adressen kennen Strukturierung: Wurden IPv4-Adressen lediglich nach Adressund Host-Teil aufgeteilt, kennt IPv6 weitergehende Hierarchiestufen: • Sogenannte TLAs (Top Level Aggregator) werden f¨ ur ISPs vergeben, die Internet Transit Services anbieten, wie beispielsweise das europäische Forschungsnetz GEANT 2001::. • Die NLAs (Next Level Aggregator) sind f¨ ur ”kleinere” ISPs, Organisationen oder Firmen vorgesehen, welche auf einen TLA zugreifen. So hat das BelWue8 den Prefix 2001:07C0:0100::. NLA k¨ onnen in verschiedene Hierarchielevel aufgeteilt werden. • Der lokationsspezifische Teil besteht aus dem Site Level Aggregator (SLA) und der Interface ID. Er beschreibt die Subnetzstruktur einer Site und die angeschlossenen Hosts. Die Interface ID besteht aus 64 bit und kann die MAC-Adresse der Netzwerkkarte f¨ ur globale Eindeutigkeit enthalten. Unspezifizierte Adresse Die Unspezifizierte Adresse hat die Form 0:0:0:0:0:0:0:0 und darf keinem Interface fest zugeordnet werden. Sie entspricht der IPv4-Adresse 0.0.0.0, die bei der automatischen Interface-Konfiguration, beispielsweise f¨ ur DHCP zum Einsatz kommt. Bis die Maschine eine Lease9 zugewiesen bekommen hat, verwendet sie f¨ ur ihre Anfrage diese Adresse als Absendeadresse. Loopback Adresse Die Loopback-Adresse darf ebenfalls nicht auf ein externes HostInterface zugewiesen werden. Sie kann als Link-lokale Unicast Adresse betrachtet werden, die einem virtuellen Intreface zugeordnet ist, das nirgendwohin f¨ uhrt. Sie u ¨ bernimmt die Funktion der IPv4-Loopback-Adresse 127.0.0.1 im damals reichlich großz¨ ugig bemessenen Subnetz 127.0.0.0/8. Der Vorteil gegen¨ uber der fr¨ uheren Lösung ist, dass die LoopbackAdresse mit ihrer speziellen Funktion nun nicht mehr einfach mitten im IP-Adressraum liegt.

23.3.1

Verschiedene Arten von Unicast Adressen

Es gibt verschiedene Typen von Unicast Adressen: Globale, Site-lokale und Link-lokale. Dazu gibt es noch spezielle Subtypen der Globalen Unicast Adressen, wie die IPv6 Adresse mit integrierter IPv4 Adresse oder NSAP Adressen. 8 9

das Badenw¨ urttembergische Forschungsnetz Adresszuweisung von einem Adress-Server (auf Zeit)

23.3. IPV6 ADRESSEN

355

Globale Unicast Adressen Allgemein sind Global Unicast Adressen unterteilt in einen Global Routing Prefix, eine Subnet ID und ein Interface ID. • Der Globale Routing Pr¨ afix ist ein hierarchisch gegliederter Wert, der eine Site identifiziert. Eine Site ist eine Menge von Subnetzen oder Links. • Die Subnet ID identifiziert ein Subnetz innerhalb einer Site. • Die Interface ID identifiziert eindeutig das Interface. Sie ist 64 bit lang und hat das modifizierte EUI-64 Format - eine Abwandlung der MAC-Adresse. Da ist nat¨ urlich noch ein wenig Platz: Eine MAC-Adresse ist u ¨ blicherweise 48 bit lang. Die Frage ist inzwischen auch, ob ein Host sich im weltweiten Netz durch seine MAC-Adresse eindeutig identifizieren lassen soll.10 Site- und link-lokale Unicast Adressen Es gibt zwei Typen von Lokalen Adressen. Die Link und die Site-lokale Adresse. Beide gelten ausschliesslich in lokalen Netzen und d¨ urfen von Routern nicht u ¨ ber die Site-Grenzen hinaus weitergeleitet werden. Die Linklokale Adresse besteht nur aus dem Pr¨ afix und der Inteface ID. Sie wird f¨ ur die Adressierung innerhalb eines Links f¨ ur die automatisch Adresskonfiguration verwendet, oder wenn kein Router vorhanden ist. Dieses Konzept hat in abgewandelter Form inzwischen auch bei IPv4 Einzug gehalten: Das Adress-Pr¨ afix 169.254.0.0/16 ist f¨ ur die automatische link-lokale IPZuweisung reserviert. Site-lokale Adressen k¨ onnen f¨ ur die Adressierung innerhalb einer Site verwendet werden. Dazu dient eine 54 bit lange Subnet ID. Somit haben die lokalen Adressen das folgende Format: Wenn man auf einer modernen Linux-Maschine einfach ifconfig oder ip addr show aufruft, sieht man auf jedem externen Interface eine link-lokale IPv6-Adresse definiert. Die MAC-Adresse ist dabei Bestandteil der Adresse in den letzten 48 bit. Anycast Adresse Anycast Adressen sind im Grunde Unicast Adressen. Sie werden erst zu einer Anycast Adresse, wenn sie mehreren Interfaces zugewiesen werden. Das kann zum Beispiel von Server genutzt werden, die den gleichen Dienst anbieten. So sind die Server in der Abbildung im gleichen Subnetz und haben die gleiche Adresse. Auf eine Anfrage entscheidet der Router des Netzes, welcher Server am nächstenist und schickt das Paket an diesen Router. Multicast Adresse Das Konzept der Multicast Adressen ist mit IPv6 aus dem experimentellen Stadium heraus. In diesem Zuge wurde auch die ”alte” IPv4-Broadcast-Adresse abgeschafft: Sie ist nun eine spezielle Multicast-Adresse. Mit Multicast-Adressen können ganze Gruppen von Maschinen angesprochen werden, die neben ihrer eindeutigen Unicast auch eine gemeinasme Multicast Adresse haben. Eine Multicast Adresse besteht auseinem 8 bit langen Pr¨ afix, das mit Einsen gef¨ ullt ist, einem 4 bit langen Flag-Feld, das besagt, ob es eine permanente, von der Internet Assigned Number Authority (IANA) zugewiesene oder eine nicht-permanente Adresse ist, einem 4 bit langen Scope Feld und der 112 bit langen Group ID, die eine Gruppe oder einen Dienst identifiziert. Das Scope-Feld definiert die Art der Abdeckung durch die Multicast Adresse: subnet, link, location oder global. 10

Hier sind die Vorstellungen von Datenschutz inzwischen weitreichender

356

KAPITEL 23. IPV6

23.4

IPv6 unter Linux

23.4.1

Adresszuweisung

IPv6 ist seit l¨ angerer Zeit Bestandteil der Vanilla-Kernels. Viele Distributionen kompilieren es nicht direkt in den Kernel, sondern belassen die Funktionalität in einem Modul. Dieses wird dann automatisch geladen, wenn in irgendeiner Form eine IPv6-Adresse auf einem der Interfaces konfiguriert wird. mobile ipv6 # 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 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:10:a4:8d:56:0a brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 scope global eth0 inet6 fe80::210:a4ff:fe8d:560a/64 scope link valid_lft forever preferred_lft forever 3: sit0: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 4: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:2d:09:f6:df brd ff:ff:ff:ff:ff:ff inet 10.100.5.63/16 brd 10.100.255.255 scope global eth1 inet6 fe80::202:2dff:fe09:f6df/64 scope link valid_lft forever preferred_lft forever Im Beispiel sieht man die neue Art der IPv6-Loopback-Adressen ::1/128, eine link-lokale Adresse f¨ ur eth0, fe80::210:a4ff:fe8d:560a/64 und eine f¨ ur eth1, fe80::202:2dff:fe09:f6df/64. Hier sieht man gut den Zusammenhang zwischen MAC-Adresse und ihrer Abbildung auf den Host-Identifier der IPv6-Adresse. Will man sich nur die IPv6-Adressen zeigen lassen, geht das mit der Option ”-f inet6”: mobile ipv6 # ip -f inet6 addr show 1: lo: mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qlen 1000 inet6 fe80::210:a4ff:fe8d:560a/64 scope link valid_lft forever preferred_lft forever 4: eth1: mtu 1500 qlen 1000 inet6 fe80::202:2dff:fe09:f6df/64 scope link valid_lft forever preferred_lft forever

23.4.2

Verbindungen testen

F¨ ur IPv6 gibts eigene Tools: ping6 u ¨bernimmt die Aufgaben von ping, traceroute6 ersetzt entsprechend das Kommando traceroute. Ein Ping auf das Loopback-Interface ist vielleicht nicht f¨ urchterlich aufregend:

23.4. IPV6 UNTER LINUX mobile ipv6 # PING ::1(::1) 64 bytes from 64 bytes from 64 bytes from

357

ping6 ::1 56 data bytes ::1: icmp_seq=1 ttl=64 time=0.083 ms ::1: icmp_seq=2 ttl=64 time=0.078 ms ::1: icmp_seq=3 ttl=64 time=0.075 ms

--- ::1 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.075/0.078/0.083/0.010 ms mobile ipv6 # ping6 -I eth0 fe80::20c:29ff:fe5a:b3d6 PING fe80::20c:29ff:fe5a:b3d6(fe80::20c:29ff:fe5a:b3d6) from fe80::210:a4ff:fe8d:560a eth0: 56 data bytes 64 bytes from fe80::20c:29ff:fe5a:b3d6: icmp_seq=1 ttl=64 time=0.802 ms 64 bytes from fe80::20c:29ff:fe5a:b3d6: icmp_seq=2 ttl=64 time=0.848 ms 64 bytes from fe80::20c:29ff:fe5a:b3d6: icmp_seq=3 ttl=64 time=0.147 ms --- fe80::20c:29ff:fe5a:b3d6 ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.147/0.599/0.848/0.320 ms Spannender ist dann vielleicht schon der Verbindungstest auf einen anderen IPv6-Host mit einer link-lokalen Adresse. Wichtig ist dabei die Angabe des Interfaces, u ¨ber welches das Paket die Maschine verlassen soll.

358

KAPITEL 23. IPV6

Abbildung 23.6: ICMP-Echo-Request unter IPv6

Linux Netzwerk Skript Netzwerk

Linux Netzwerk Skript Netzwerk

Hauptüberschrift

Our 2048kBit link to the rest of the internet

Suggest Documents

Linux im Netzwerk - KnowWare

Netzwerk für Kaderleute - Schreiner - Netzwerk - Zentralschweiz

Umfangreiches PDF-Skript mit Beschreibung und ... - DaF Netzwerk

Beijing - WIDE-Netzwerk

H.264 Netzwerk DVR

Megapixel PIR Netzwerk Kamera

Beijing - WIDE-Netzwerk

Getrennte Welten? - Netzwerk Recherche

Download - Netzwerk-Lernen

Getrennte Welten? - Netzwerk Recherche

Untitled - Netzwerk EBD

Stationentraining Adjektive - Netzwerk Lernen

Inhalt - Netzwerk-Lernen

ansehen - Netzwerk Lernen

ansehen - Netzwerk Lernen

Juli 2013 - Psychosoziales Netzwerk

Wireshark ohne Netzwerk - Kaiser.cx

Getrennte Welten? - Netzwerk Recherche

SuSE Linux / Installation - Netzwerk - Informatik - FB3 - Uni Bremen

LINUX/NETZWERK ADMINISTRATOR (m/w) - CIB software GmbH

Die drei Spatzen - Netzwerk Sims

Netzwerk – Arbeitsbuch A1.1 Lösungsschlüssel - deutschweb

Statusseminar NUTRIGENOMIK - Netzwerk Nutrigenomik Berlin ...

Harald Hoß: Linux-Server im Windows-Netzwerk - Terrashop.de