Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix

Transkript

1 Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix Internet WLAN printer WAN /24 LAN Kursunterlagen -Universitäten Göttingen und Freiburghera.dom.test zeus.dom.test aphrodite.dom.test Dirk von Suchodoletz mit Beiträgen von: Frank Schwichtenberg Daniel van Ross Tim Oliver Kaiser Steffen Wagner Stefan Koospal Korrekturgelesen und zusammengestellt von: Antonia Blanke 3. Auflage 22. Mai 2006

2 Alle in diesem Dokument erscheinenden Produktnamen dienen nur zu Identifikationszwecken und sind Eigentum ihrer jeweiligen Besitzer.

3 Inhaltsverzeichnis 1 Einleitung Netzwerk Zu diesen Unterlagen Bezeichnung von Dateien und Verzeichnissen Begriffserklärungen - Bereich Netzwerk Begriffserklärungen - Telefonie OSI-Schichtenmodell Kategorisierungen Protokollhierarchien Hierarchie Motivation Die einzelnen Schichten Bitübertragungsschicht Sicherungsschicht Vermittlungsschicht Transportschicht Sitzungsschicht Darstellungsschicht Verarbeitungsschicht Konzepte Protokolle Einordnungen Aufgaben OSI Netzwerke LAN Hardware Ethernet Ethernet-Adapter Koaxialkabelbasierte Netze für 10 MBit Twisted-Pair-basierte Verkabelungen 10/100 Mbit Mbit Ethernet unter Linux Funk-Netze TokenRing Netzwerk-Interfaces von Linux Aufgaben Ethernet

4 4 INHALTSVERZEICHNIS 4 WAN Hardware Einleitung Leistung und Kosten der einzelnen Technologien Leistung / Datendurchsatz Kosten Telefonnetze Das klassische Telefonnetz Digitale Telefonnetze - ISDN Mobilfunknetze nach dem GSM-Standard GPRS HSCSD Mobilfunknetze der dritten Generation - UMTS ISDN Modem ADSL Designüberlegungen Übertragungsmethoden Vorteile der neuen Technik Benutzung unter Linux ATM Die ATM-Zelle FDDI Mobilfunknetze GSM, HSCSD, GPRS und UMTS Netzwerkadapter für Mobilfunknetze TCP-IP Schaffung von Inter-Nets Überblick über TCP/IP Design Internet Protocol (IP) Spezifikation IPv4-Standard Notation Adressbereiche Spezielle IP-Adressen Private IP-Adressen Der IP-Header Fragmentierung IP-Routing Prinzip der IP-Netze Routing (Die Wege im Netz) Einfaches Hostrouting Routingentscheidung Subnetting und Supernetting QoS-Routing Address Resolution Protocol ARP - Hilfsprotokoll des IP Funktionsweise

5 INHALTSVERZEICHNIS ARP unter Linux Eingebaute Sicherheitslücken Gefahrenabwehr ARP und doppelte IP-Adressen Proxy-ARP Probleme durch Proxy-ARP ICMP - Internet Control Message Protocol Domain-Name-Service (DNS) Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Ports Aufgaben Internets Internet Protokoll / Header IP-Netze Fragmentierung IP-Routing ARP Linux im Netzwerk IP-Konfiguration unter Linux Die traditionellen Tools Routing Next Generation IP-Config Das Kommando ip Erste Schritte mit ip Weitergehende Anwendungen von IProute Weitere Tools Routing Policy Database Generelle 2-Wege-Routen Dienste-basiertes Routing Überprüfung der Konfiguration Aufgaben IP-Konfiguration und Erreichbarkeit Datenverkehr zählen DHCP Automatische IP-Zuweisung Implementation DHCP-Server DHCP-Standardoptionen DHCP-DNS-Verbindung Benutzerdefinierte Optionen Die Verwendung von Vendor-Code-Identifiern DHCP-Client DHCP mit LDAP-Backend Aufgaben DHCP

6 6 INHALTSVERZEICHNIS 8 DNS Einstieg Enstehungsgeschichte DNS - Das virtuelle IP-Telefonbuch Regeln für die Namensgebung Registrieren und Verwalten von Domains Implementation Nameserver und Zuständigkeiten Caching Primärer und sekundäre Nameserver DNS-Server mit Linux Der Dämon Die DNS-Datenbank Starten und Anhalten des Nameservers Slave-Server Delegation einer Subdomain Dynamische Updates der Zonendateien Sicherheit DNS bekommt neue Aufgaben ENUM IPv DNS als Bannerfilter Aufgaben Rechnernamen im Internet Domain Name Service (DNS) DNS Server Webserver Überblick HTTP-Kommunikation Was ist ein Webserver? Apache Erweiterte Funktionalität Konfiguration Optionen Module User Webserver Erweiterungen Die Benutzer-Homepage - mod userdir URL-Umschreiber mod rewrite Zugriffskontrollen Kompression Das Web-DAV Modul Vrituelle Webserver SSL (Secure Socket Layer) Funktionsweise Zertifikate Zertifikate erzeugen Integration

7 INHALTSVERZEICHNIS CGI (-Modul) PHP Das Apache-PHP-Modul SSI (Server Side Includes) Überblick HTTP-Kommunikation Überblick HTTP-Kommunikation Überblick HTTP-Kommunikation Dokumentation Mail SMTP Adresse Versenden einer Mail-Body Header Open-Relay Sicherheit sendmail exim POP IMAP Aufgaben Dienste Fileserver Unix-Netzwerkdateisystem - NFS NFS im Einsatz NFS und Portmapper NFS-Clients NFS-Server NFS und (Un)Sicherheit Andrew Filesystem (AFS) Die Clientseite File Transfer Protocol Dateiarchiv - FTP-Server FTP-Clients Das Minimal-FTP (TFTP) Weitere Fileserver-Konzepte Network Block Devices NBDs im Einsatz Erste Versuche mit NBD NBD und Filesysteme DNBD - eine spezialisierte Alternative Spezielle Blockdevice-Erweiterungen

8 8 INHALTSVERZEICHNIS 12 Samba Samba - Brücke zwischen Microsoft- und Unix-Welt Einsatzgebiete von Samba Erste Versuche Windows-Server - Linux-Client Linux-Server - Windows-Client Weitergehende Konfiguration Homeverzeichnisse für Windows und Linux Druckerfreigaben Nachrichtendienst auf Linux-Clients Die zentrale Samba-Konfigurationsdatei Struktur Wichtige Optionen in der Sektion [global] Wichtige Optionen der anderen Abschnitte Virtuelle Samba-Server Controller-Funktionalität Der Windows Namensdienst NetBIOS Namen Der Nameserver (WINS) Samba als PDC Benutzerprofile und Logon-Skripten Samba und LDAP Konfiguration des LDAP-Servers Die neue Samba-Konfiguration Die IDEALX-Skripten Fazit von Samba-LDAP-Aktionen Ressourcenverwaltung Einleitung NIS Zielsetzung NIS-Datenbanken NIS-Server NIS-Client Hierarchische Datenbank: LDAP Intro Was kann mit LDAP abgebildet werden Das Datenmodell Das Protokoll LDAP praktisch Server- und Clientprogramme unter Linux Eine einfache Beispielkonfiguration Absicherung durch SSL Drucken im Netz Einleitung Anforderungen Grundlagen CUPS

9 INHALTSVERZEICHNIS Client-Server-Architektur IPP Funktionsweise Filter Konfiguration Alternativen Wichtige Netzwerkkommandos Offene Dateien und Netzwerkverbindungen netstat Systemprogramme Dämonen Netzwerkkonfiguration Netzwerktests Netzwerküberwachung Netzwerküberwachung Überblick SNMP - Das Simple Network Mangement Protocol Überblick Die Datendefinition Der SNMP-Namensraum und die Management Information Bases Die SNMP-Agenten Der Kommunikations-Code der Agenten SNMP-Implementierungen unter Linux Kommandos zur Datenbeschaffung Konfiguration des UCD-SNMP Der Kopf definiert die Zugriffs-Policies Parameter der Enterprise -Erweiterungen Erweiterung durch externe Skripten und Programme Überwachung weiterer Parameter Weitergehende Ergänzungen Parameter der Host-Ressource-Erweiterungen MRTG als Frontend zur Anzeige von Zeitreihen Einige abschließende Worte zu SNMP Weiterführende Literatur Systemsicherheit Generelle Überlegungen Sicherheit auf dem Rechner Einleitung Passwörter Der Admin-Account /etc/passwd und /etc/shadow Locken oder ausloggen Setuid und Verzeichnisse Setuid und Mounting Browser, CGI / Java-Applet und Binaries, per Mail Physikalischer Zugriff Literatur

10 10 INHALTSVERZEICHNIS 17.4 Sicherheit im Netzwerk Einleitung Gesicherte Verbindungen ssh und scp Der Intenet- Super -Daemon (x)inetd xhost + und das unsichtbare Fenster rhosts Überprüfung der Netzwerksicherheit eigener und anderer Rechner Firewall Aufgaben Secure Shell Sicheres IP Sicherheitsprobleme des derzeitigen IP-Standards Intro Offener Datentransport Absicherung - Lösungsansätze VPNs - Sichere Netze über das Internet CIPE Idee Aufsetzen von CIPE IPsec-Theorie IPsec praktisch - FreeSWAN Konfigurationsmöglichkeiten von IPsec Einrichtung von IPsec unter Linux Einschaltbare Optionen Konfiguration von IPsec-Verbindungen Kommerzielle VPN-Lösungen Cisco-VPN Verwendung der Cisco-Tools Einsatzszenarien Fazit Literatur Firewall Aufbau Ein- und Austragen von chains und Filter-Regeln Pakete genauer spezifizieren Match Extensions und Erweiterbarkeit von masquerading und packet mangling Network Address Translation packet mangling connection tracking Referenzen

11 Kapitel 1 Einleitung Netzwerk 1.1 Zu diesen Unterlagen Der Kurs Linux und Netzwerke soll in die Begriffswelt vernetzter Rechner einführen. Vorgestellt werden die Grundlagen von Netzwerken und darauf aufbauende Applikationen. Zur besseren Einordnung der unterschiedlichen Netzwerk-Layer ist das OSI-Schichtenmodell vorangestellt. Gefolgt wird dieses von Ausführungen zu derzeitig verfügbarer Netzwerkhardware, wie Ethernet oder Funk-Lan und verfügbaren Netzwerkanschlüssen, wie Modem, ISDN, ATM und ADSL. Alle Erläuterungen erfolgen am Beispiel des Betriebssystems Linux. Im Zuge des Skriptes werden etliche Programme vorgestellt, welche zu Konfiguration, Tests, Fehlersuche, Betrieb bestimmter Dienste und Abfragen dieser benötigt werden. Diese Unterlagen wurden aus Anlass mehrerer Vorlesungen, Seminare und einiger Fortbildungskurse zum Thema Linux und Administration in Netzwerken, Linux als Beispiel eines Netzwerkbetriebssystems oder Einführung in IP-Netzwerke zusammengestellt. Sie sind inzwischen ein gemeinsames Projekt des Rechenzentrums der Universität Freiburg und der mathematischen Fakultät Göttingen. Die Unterlagen werden permanent aktualisiert, jedoch können einige Teile durchaus älteren Datums sein. Sollte es Fehler in den Texten oder Probleme geben, bitte ich Sie, mich einfach zu benachrichtigen. 1 Viele Teile stammen von Artikeln ab, die ich irgendwann mal in der einen oder anderen Publikumszeitschrift veröffentlicht hatte. Ich habe daher nichts dagegen, wenn diese Unterlagen ganz oder zum Teil für andere Projekte Verwendung finden. Ich möchte dann nur auf den Haftungsausschluss hinweisen und bitten, die Quellen zu überprüfen und gegebenenfalls zu kennzeichnen. Deshalb möchte ich die GPL möchte auf diese Unterlagen angewandt sehen. Das Skript erhebt keinen Anspruch auf Vollständigkeit oder Originalität. Vieles findet man im Internet oder in Lehrbüchern ebenso gut oder besser. Dort nachzuschlagen und zu vergleichen, sei den Lesern nachdrücklich ans Herz gelegt. Dennoch wird immer wieder ein eigener Weg der Darstellung begangen, wobei manches über den normalen Umfang einer Einführung hinausgehen kann. Dafür kommen manche traditionell breits abgehandelten Gebiete hier recht kurz weg. Manches fehlt auch ganz, weil man es woanders leicht finden kann. Dieses Skript will und kann kein Lehrbuch ersetzen (das brauchen Sie außerdem), sondern ergänzen. Das Self-Linux -Projekt 2 bietet eine vernünftige Ergänzung zu den vorliegenden Unterlagen. Einiges wird anders als gewohnt präsentiert. Es werden Beispiele und auch zusätzliche Informationen angeboten, die nicht unbedingt zum Prüfungsstoff gehören, aber gut zu wis- 1 beispielsweise per Mail an dirk@goe.net 2 1

12 2 KAPITEL 1. EINLEITUNG NETZWERK sen sind (oder die man hier bequemer findet). Dafür entfallen viele Aspekte, die in den Standard-Lehrbüchern gut dargestellt oder weitgehend bekannt sind. Die weiterführende Literatur findet sich am Ende eines Abschnitts. Ich hoffe, dass diese Kursunterlagen den Einstieg in Netzwerke und Linux in diesen erleichtern. Die Beispiele habe ich in den meisten Fällen selbst ausprobiert und Angaben aus Konfigurationsdateien stammen aus meiner eigenen Praxis. Trotzdem können Fehler enthalten sein, die ich dann zu entschuldigen bitte Bezeichnung von Dateien und Verzeichnissen Zur Erhöhung der Lesbarkeit werden alle auführbaren Dateien/Systembefehle durch Fettdruck, z.b. dhcpd hervorgehoben. Alle Konfigurationsdateien, IP- und MAC-Adressen, Hostnamen werden italic gesetzt, um sie vom Druckbild hervorzuheben. Um den Lesefluss nicht stark zu stören, werden viele Erläuterungen als Fussnoten angefügt. Auch alle Links zu den entsprechenden Webseiten sind hier zu finden. 1.3 Begriffserklärungen - Bereich Netzwerk Im folgenden werden einige Begriffe und Abkürzungen erläutert, die im Bereich Linux im Netzwerk und Internet häufig vorkommen. Bandbreite wird in mehreren Bedeutungen benutzt: Zum einen ist die Bandbreite ein Mass für die Breite eines Frequenzbands. Die Differenz zwischen einer oberen und einer unteren Grenzfrequenz, die nie über- oder unterschritten wird. So hat beispielsweise hat ein analoges Telefonsignal, das in einem Frequenzbandbereich von 300 Hz bis 3400 Hz übertragen wird, eine Bandbreite von 3100 Hz. Andererseits ist die Bandbreite ein Mass für die Anzahl Bits pro Sekunde, die gleichzeitig über eine Kommunikationsleitung transferiert werden können. So hat das klassische Ethernet eine Bandbreite von 10 Mbit/s. CSMA Carrier Sense Multiple Access beschreibt das Zugriffsverfahren für bestimmte Broadcast-Netze, wie Ethernet oder TokenRing. Dabei gibt es zwei wichtige Ausprägungen: CD steht für Collision Detection, das Erkennen und CA für Collision Avoidance - das Vermeiden von Paketzusammenstößen. Ersteres ist charakteristisch für Ethernet, das Zweite für TokenRing oder FDDI. Datenübertragungsrate Die maximale Datenübertragungsrate R lässt sich gemäss dem Nyquist-Theorem folgendermassen berechnen: Wenn das Signal aus V diskreten Stufen besteht: R = 2Hlog2V Bit/s. Nach Shannon beträgt die maximale Datenübertragungsrate R eines rauschenden Kanals mit einer Bandbreite von H Hz und einem Rauschabstand von S/N gleich Hlog2(1 + S/N), die maximale Anzahl von Bit pro Sekunde. Dezibel (db) ist ein einheitenloses Maß. Bel ist nach dem Physiker Alexander Graham Bell benannt. In der Nachrichtentechnik verwendet kommt üblicherweise die Masseinheit Dezibel (db) zum Einsatz. Das Dezibel ist ein logarithmisches Maß. Es vereinfacht die Berechnung der Dämpfung oder Verstärkung. Damit müssen für die Ermittlung der Verstärkung eines Gesamtsystems nur die einzelnen db-werte addiert werden. Eine Rechnung der Sendeleistung (beispielsweise eines WLAN-Access-Points) addiert die Leistung

13 1.3. BEGRIFFSERKLÄRUNGEN - BEREICH NETZWERK 3 des Senders/Empfängers zur Leistung eines eventuell verwendeten Verstärkers und der Antennenleistung. Von diesem Wert zieht man den Leistungsverlust durch Kabel, Stecker und eventuellem Blitzschutz ab. Eine Veränderung um 3 db entspricht immer einer Leistungsverdoppelung oder Halbierung. Die Einheit Dezibel Milliwatt (dbm) beschreibt den Leistungspegel bezogen auf ein Milliwatt. Die Einheit ist eine absolute Angabe. 20 dbm entsprechen einer Leistung von 100 mw, 0 dbm entsprechen 1 mw. Der Antennengewinn in dbi beschreibt die Leistungsverbesserung gegenüber einem isotrophen Kugelstrahler. Sobald die Leistung nicht mehr in alle Richtungen gleichmäßig, sondern bezogen auf ein bestimmtes Raumsegment abgegeben wird, erhält man einen Gewinn. Diskless X-Station Diskless X-Station meint Workstations auf PC-Basis. Diese Geräte mounten ihr Dateisystem von einem Fileserver und gestatten dem Benutzer das lokale Ausführen von Applikationen, sowie den Zugriff auf alle Laufwerke, installierte Erweiterungshardware (Audio, Video, SCSI, USB...) und angeschlossene Perepheriegeräte. DHCP Dynamic Host Control Protocol. DHCP basiert auf UDP und benutzt für den Server-Kanal Port 67 und den Client-Kanal Port 68. Durchsatz oder Datendurchsatz bezeichnet die gemessene Leistung eines Kanals und wird in Bit pro Sekunde (bps) angegeben. ERP und EIRP machen Angaben zur abgestrahlten Leistung von Antennen. ERP (Effective Radiated Power) gibt die effektiv abgestrahlte Leistung in der Hauptstrahlungsrichtung der Antenne an. EIRP (Effective Isotropic Radiated Power) wird benutzt um Richtantennen zu charakterisieren. EIRP gibt an, wie stark eine ungerichtete Antenne (isotrop) senden müsste, um die gleiche Wirkung zu erzielen wie die Richtantenne in ihrer Hauptsenderichtung. FTP Das File Transfer Protocal ist eine der ältesten Möglichkeiten über TCP/IP Dateien zwischen Rechnern zu kopieren. Es verwendet das verbindungsorientierte TCP und verwendet Port 23. LAN Local Area Network. Meint Netzwerke einer geringen bis mittleren Ausbreitung, die sich üblicherweise der Ethernet-, ATM-, TokenRing- oder FDDI-Technologie bedienen. Latenz ist die Dauer, die eine Nachricht von einem Ende eines Netzwerks zum anderen braucht. Die Zeitspanne, eine Nachricht von einem Ende eines Netzwerks zum anderen und wieder zurück zu senden, wird als Round Trip Time (RTT) des Netzwerks bezeichnet, sie bewegt sich (in den meisten Netzen) meist im Millisekundenbereich. MIME Multipurpose Internet Mail Extension ist ein Kodierstandard, der die Struktur und den Aufbau von s und anderen Internetnachrichten festlegt. Modulation Unter Modulation versteht man die Veränderung von Merkmalen eines Signals, z.b. der Frequenz, Amplitude oder Phase, um Informationen zu kodieren. NFS Network File System. NFS ist ein UDP-basiertes Protokoll, das Dateisysteme über ein TCP/IP-Netzwerk zur Verfügung stellen kann.

14 4 KAPITEL 1. EINLEITUNG NETZWERK Nyquist-Theorem besagt, dass ein Signal mit der Bandbreite H durch 2H Abtastwerte pro Sekunde vollständig rekonstruiert werden kann. Anders ausgedrückt kann ein Signal der Frequenz f mit 2f Abtastwerten vollständig rekonstruiert werden. OSI-Schichtenmodell Dieses Modell der International Organization for Standardization (ISO) betrifft die Organisation von Datenfernübertragungen und veranschaulicht die ebenenorientierte Denkweise in der Informatik. Port Neben der IP-Adresse verfügt ein Rechner über jeweils TCP bzw. UDP- Ports. Damit wird es möglich viele verschiedene Dienste auf einem Rechner gleichzeitig anzubieten, bzw. viele gleichzeitige Verbindunge aufzubauen. Server Der Server ist ein Diensteanbieter im klassichen TCP/IP-Client-Server-Modell, d.h. er stellt, meistens zentral, bestimmte Funktionalitäten, wie Mail-, File- und Webdienste oder Applikationen zur Verfügung. Benutzer können sich an einem Server anmelden, werden aber nur in den seltensten Fällen physisch vor dem Gerät sitzen. Signal-Rausch-Abstand (englisch: Signal Noise Ratio (SNR) beschreibt das Verhältnis der Signalstärke S zur Rauschstärke N, also die Intensität des thermischen Rauschens in einem Übertragungskanal: S/N, und wird in Dezibel (db) gemessen. Es ist ein Mass für die Reinheit eines Signals. SSH Secure Shell Verbindung. Diese ist dem Telnet auf jeden Fall vorzuziehen, da sie verschlüsselt erfolgt. Das Programm auf der Serverseite heisst üblicherweise sshd, die Clientapplikation ssh. Telnet Eines der ersten Protokolle der TCP/IP-Suite, um sich an entfernten Rechnern anmelden zu können. Telnet verwendet als Transportprotokoll TCP und arbeitet auf Port 21. Der Daemon, d.h. der Hintergrundprozess, der den Telnet-Dienst auf einem Rechner anbietet, heisst üblicherweise (in.)telnetd und wird meistens über den Internet-Super- Daemon (x)inetd gestartet. Die Clientapplikation heisst einfach telnet. Heutzutage aus Sicherheitsgründen kaum noch Telnet-Server, jedoch lassen sich mit Telnet einfache Tests auf TCP-basierte Dienste loslassen. TFTP Trivial File Transfer Protocol. TFTP stellt eine stark vereinfachte Version des FTP dar und arbeitet auf Basis von UDP Port 69. UDP User Datagram Protocol. UDP ist Teil von TCP/IP und stellt eine Implementation der Transportschicht dar. UDP arbeitet verbindungslos. User Agent oder Benutzeragent, -programm ist ein Client Programm in Netzwerkverbindungen. Es initiiert Anfragen, beispiel ein Browser an einen Web-Server. WAN Wide Area Network. Meint Netzwerke mit großer räumlicher Ausdehnung, die sich üblicherweise der ISDN oder ATM Technologie bedienen. (Lichtwellenleiter, Kupferkabel)

15 1.4. BEGRIFFSERKLÄRUNGEN - TELEFONIE 5 XDMCP Das X display message control protocol steuert die Grafikschnittstelle auf Unix- Systemen. Diese Schnittstelle ist netzwerktransparent. Dabei erfolgt die Ausgabe des Grafikoberfläche des Servers lokal auf der Maschine. Die Bentutzereingaben durch Tastatur und Maus werden über XDMCP an den Server weitergereicht. 1.4 Begriffserklärungen - Telefonie Im folgenden werden einige Begriffe und Abkürzungen erläutert, die im Bereich digitaler Telefonnetze, Mobiltelefonie, Voice-over-IP, ISDN häufig verwendet werden. ACM Die Address Complete Message signalisiert im PSTN, dass das Routing eines Telefonanrufes erfolgt ist. Üblicherweise erhält der Anrufer in der Zwischenzeit das Rufzeichen, Ansagen wie The person you have called is temporarily not available, This number is no longer in service... Ein PSTN-2-SIP Gateway muss eine solche Meldung geeignet weitergeben - durch early media (definiert in RFC2543) und/oder durch 183 Session Progress. AIN Advanced Intelligent Network, siehe auch IN. ANM steht für Answer Message im PSTN. BSC Base Station Controller. BSS bezeichnet das Base Station System. Dieses besteht aus einem oder mehreren BSC. BTS Base Transceiver Station. CCI Der Call Charge Indicator ist ein ISUP Parameterfeld. CdPN Called Party Number ist ein Teil der ISUP Message. Dieses Feld enthält den NPI (Numbering Plan Indicator), beispielsweise E.164 und NOA (Nature of Address, z.b. national ). CgPN Calling Party Number ist ein weiterer Teil der ISUP Message. CPC Die Calling Party Category ist ein ISUP Parameterfeld. CSD Circuit Switched Data ist ein Begriff aus dem Bereich der GSM-Telefonnetze und bezeichnet den Standard zum Datenaustausch. Die Nutzdatenrate beschränkte sich auf maximal 9,6 kbit/s. In der GSM-Phase-2 wurde die Geschwindigkeit der Datenübertragung auf 14,4 kbit/s erhöht, in der GSM-Phase-2+ die Bündelung mehrerer Kanäle ermöglicht. DTAP Der Direct Transfer Application Part ist das Call Control Protocol zwischen MS und MSC. FCI Der Forward Call Indicator ist ein ISUP Parameterfeld.

16 6 KAPITEL 1. EINLEITUNG NETZWERK GPRS Der General Packet Radio Service benötigt keine eigene Infrastruktur, sondern ist lediglich eine Erweiterung der bestehenden GSM-Netze. GPRS-Mobiltelefone stellen für den schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt (APN = Acces Point Name) ins Netz her. Für die Datenkommunikation wird es Endgeräten erlaubt mehrere GSM-Kanäle zusammenzufassen und für die Kommunikation zu reservieren. Bandbreiten in Funknetzen haben immer ein Problem: Alle Nutzer einer Zelle teilen sich ein gemeinsames Medium. Wollen alle gemeinsam zugreifen, sinkt für jeden einzelnen die erreichbare Datenrate. n der Einführungsphase von GPRS wurde netzseitig eine Bandbreite von 53,6 kbit/s (4 Kanäle à 13,4 kbit/s) pro Funkzelle vorgesehen. Stehen alle acht Kanäle für GPRS zur Verfügung, würde die Bandbreite auf 107,2 kbit/s steigen. Weitere Steigerungen durch bessere Fehlerprotokoll erlaubten theoretische 171,2 kbit/s (acht Kanäle a 21,4 kbit/s). Mobiltelefone arbeiten momentan mit 13,4 kbit/s pro Kanal. Sie können je nach Gerät zwei bis drei Kanäle zusammenfassen. GMSC Gateway Mobile Switching Centre. GSM Global System of Mobile Telecommunication bezeichnet allgemein den weltweiten Generation 2 Standard digitalen Mobilfunks. HLR Home Location Register HSCSD High Speed Circuit Switched Data, der Nachfolger von CSD, erreicht eine maximale Datentransferrate von 57,6 kbit/s. Der Unterschied zwischen den beiden Systemen liegt in den verwendeten Protokollen und der Übertragungstechnik. Wie bei einer Telefonleitung steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verfügung. Die Zahl der gleichzeitig aktiven Teilnehmern ist für die verfügbare Bandbreite nicht relevant und nur durch die maximale Zellkapazität (bezogen auf aktive Teilnehmer) beschränkt. IAM steht für Initial Address Message im PSTN und ist Bestandteil des ISUP. IAM entspricht der ISDN Message Setup und der SIP Message INVITE. IMSI Die International Mobile Subscriber Identity ist auf der SIM-Karte hinterlegt. Sie besteht aus maximal 15 Ziffern, wobei die ersten drei Ziffern für die MCC und die folgenden zwei oder drei Ziffern für die MNC vorgesehen sind. Dabei bezeichnet MCC den Mobile Country Code und MNC (Mobile Network Code) den Betreiber des Mobilfunknetzes innerhalb eines Landes. Unterhalb des MCC ist der MNC immer einheitlich zwei oder drei Ziffern lang. Der Rest ist die MSIN, Mobile Subscriber Identification Number. Sie dient zur Identifikation eines Benutzers im PLMN. IN Intelligent Network meint in der Telco-Szene moderne digitale circuit-switched Telefonnetze, die noch großartigere Form wird mit AIN bezeichnet. Interface Anders als in paketorientierten IP-Netzwerken, wo die Einhaltung von (offenen) Protokollen und Standards eine wesentliche Voraussetzung ist, spielen im Bereich klassische Telefonie Interfaces eine große Rolle für die Signalisierung zwischen Komponenten des Netzwerks. So bezeichnet das A Interface die Verbindung zwischen MSC und BSC, Abis liegt zwischen BSC und BTS, D zwischen MSC und HLR und U m für die Funkverbindung zwischen MS und BTS. Im Bereich des ISDN bezeichnet S 0 die Schnittstelle zwischen

17 1.4. BEGRIFFSERKLÄRUNGEN - TELEFONIE 7 NTBA und den Endgeräten, wie ISDN-Telefon oder AB-Wandler. U k0 ist die Zweidraht- Kupferschnittstelle zwischen NTBA und Vermittlungsstelle. ISDN Integrated Services Digital Network ist ein weltweiter Standard der leitungsvermittelten (circuit-switched) Telefonie. Endbenutzer haben mit dem sogenannten Basic Rate Interface (BRI) zu tun. Grosse Nebenstellenanlagen sind mittels Primary Rate Interfaces (PRI) mit dem öffentlichen Telefonnetz verbunden. ISUP Der ISDN User Part regelt die Inter-Circuit-Signalisierung von Anrufen und ist für deren Auf- und Abbau zuständig. Diese kann mittels SS7 oder alternativ mittels D-Kanal (Q.931) erfolgen. ISUP beinhaltet folgende Felder: IAM, CgPN, CdPN, USI, FCI, CPC, CCI. MSC Das Mobile Service Switching Centre ist die zentrale Schaltstelle im Telefonie- Netzwerk. Es ist verbunden mit dem Radio Access Network (RAN), welches von den BTS und BSCs gebildet wird, welche wiederum das Public Land Mobile Network (PLMN) bilden. MISDN Die Mobile Station ISDN Number wird dazu verwendet Benutzer zu identifizieren, wenn Verbindungen aufgebaut werden. Sie besteht aus maximal 15 Ziffern, 3 wobei die ersten eins, zwei oder drei Ziffern für den Country Code (CC) und anschliessende Ziffern für den National Destination Code (NDC) stehen. Letzterer bezeichnet üblicherweise die Vorwahlen der diversen Mobilfunkanbieter. Der Rest ist dann die Subscriber Number (SN), welche den Benutzer innerhalb eines PLMN Nummernplans einsortiert. Die MISDN ist dabei nicht(!) auf der SIM gespeichert und ist nicht auf der MS feststellbar. Unabhängig davon kann sich jeder die Nummer natürlich irgendwo hin speichern, was aber für das Netz keine Auswirkungen hat. MS Die Mobile Station ist das Benutzerendgerät in Mobilfunknetzen, welches man in der Hand hält. Dieses besteht aus dem Mobiltelefon, dem Mobile Equipment (ME) und der SIM-Card. Jedes Mobiltelefon hat eine eindeutige Kennung (IMEI - International Mobile Equipment Identifier), die hardcodiert im Gerät hinterlegt ist. MSRN Die Mobile Station Roaming Number ist eine temporäre Nummer, die einer MS zugeordnet wird, wenn eine Verbindung aufgebaut wird. Dieses ist notwendig, da zwar die MISDN einen Benutzer identifiziert, aber nichts darüber aussagt, wo er sich gerade befindet. PBX Private Branch exchange meint die Endbenutzer Vermittlungsstelle. PLMN Public Land Mobile Network. So sind GSM und UMTS Beispiele für PLMNs. GSM unterscheidet hier noch in Home PLMN (HPLMN), Visited PLMN (VPLMN) und Interrogating PLMN (IPLMN) 3 Im Gegensatz zu den bekannten IP-Adressen handelt es sich hier um aufeinanderfolgende Dezimalziffern. Das liegt an der langen Historie von Telefonnetzen, die traditionell Teilnehmern Ziffernfolgen des Dezimalsystems zuordnen.

18 8 KAPITEL 1. EINLEITUNG NETZWERK POTS Plain Old Telephony System bezeichnet oft die klassische Analog -Teleonie über die 2-Draht-Kupferleitung. PSTN Das Public Switched Telephone Network meint das klassische System der (digitalen) Telefonie. Üblicherweise wird hierfür ISDN eingesetzt. REL ist eine ISUP Message (Release) und entspricht dem Release des ISDN. RLC ist eine ISUP Message (Release complete) und entspricht dem Release Complete des ISDN. SIM Subscriber Identification Module ist ein Chip (auf einem genormten Stück Plastik, das in das ME gesteckt wird), welcher den sogenannten Subscriber (Mobilfunkbenutzer) gegenüber dem GSM-Netz identifiziert. SIP Session Initiation Protocol ist ein Application Layer Protocol welches auf Basis von TCP oder UDP Session-Setup, In-Session-Info und Session-Close-Services für interaktive Dienste wie Telefonie, Video-Conferencing oder Multi-User-Games zur Verfügung stellen kann. SS7 Das Signalisierungs System (Signaling System) 7 ist ein Standard der Out-of-Band- Signalisierung in digitalen Telefonnetzen. UTMS Hinter der Abkürzung Universal Mobile Telecommunications System steckt der 1998 von der ETSI (Abkürzung für European Telecommunications Standard Institute) vorgestellte Breitband-Mobilfunkstandard der 3. Generation (G3). Die Weiterentwicklung und Pflege des Standards unterliegt inzwischen dem 3GPP (3rd Generation Partnership Project). Zu den wesentlichen Leistungsmerkmale von UMTS zählt die Übertragung von Sprache und Audiodaten, die Übermittlung von multimedialen Inhalten sowie der schnelle Zugriff auf das Internet. UMTS ermöglicht Datenübertragungsraten von 364 kbit/s bis zu 2 Mbit/s, womit Streaming Video und Audio Übertragung, sowie Bildtelefonie ermöglicht werden sollen. Diese Übertragungsraten erreicht UMTS durch den asynchronen Transfermodus kurz ATM-Verfahren im sogenannten Codemultiplexverfahren. Als Funk-Technologie kommt Wideband CDMA (WCDMA) im Frequenzbereich um die 2 GHz zum Einsatz. VLR Visitor Location Register ist ein Begriff auf dem Bereich digitaler Mobilfunknetze der zweiten (GSM) und dritten Generation (UMTS).

19 Kapitel 2 OSI-Schichtenmodell 2.1 Kategorisierungen Computernetze sind durchaus komplex aufgebaut. Nicht jede Applikation soll diese Komplexität jeweils nachvollziehen müssen. An dieser Stelle wird wiederum Abstraktion verlangt. Dies ist durchaus vergleichbar mit den Aufgaben von Betriebssystemen, welche die Hardware virtualisieren. Eine saubere Trennung der Aufgaben (im Sinne der Programmierung von Schnittstellen) ist erforderlich. Sonst wären Applikationen schwer zu warten, schlecht erweiterbar und im Laufe ihrer Weiterentwicklung kaum überschaubar. Deshalb ist ein strukturierter Aufbau notwendig. Hierfür erfolgt die Vereinbarung von Protokollen und die Definition von Schnittstellen. Für die Modellierung von Netzwerken bietet das OSI-Schichtenmodell eine Orientierung. Dieses schafft eine hierarchische Aufteilung der Hardware und Programme in Module, die jedoch durchaus von sehr verschiedenen Lieferanten stammen können. 2.2 Protokollhierarchien Protokolle sind Regeln, die den Austausch von Nachrichten - oder allgemeiner das Verhalten - zwischen (Kommunikations-) Partnern regeln ( Protocols are formal rules of behaviour ). Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar gänzlich unmöglich. Ein Beispiel für ein Protokoll aus dem täglichen Leben ist z.b. der Sprechfunkverkehr: Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit Roger und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung schließlich mit Over and out. Ähnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern benötigt - auch wenn hier die Komplexität der Anforderungen etwas höher ist. Aufgrund dieser höheren Komplexität werden viele Aufgabe nicht von einem einzigen Protokoll abgewickelt. In der Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen Teilaufgaben, zum Einsatz. Diese Protokolle sind dann in Form von Protokollschichten mit jeweils unterschiedlichen Funktionen angeordnet Hierarchie Jede Schicht n enthält Instanzen für den Datenaustausch mit der Partnerinstanz der gleichen Schicht n in anderen Computern. Die Vereinbarungen, nach denen diese Kommunikation abgewickelt wird, nennt man das Protokoll der Schicht n. Praktisch kommunizieren die 9

20 10 KAPITEL 2. OSI-SCHICHTENMODELL Schichten nicht direkt miteinander, sondern jede Schicht gibt der darunterliegenden Schicht die Daten und Steuerinformationen. Man kann sich vorstellen, dass jede Schicht (bis auf die unterste Schicht, die nur für das Senden und Empfangen eines nicht formatierten Bitstroms zuständig ist) die erhaltenen Daten in einen Umschlag steckt, in dem zusätzlich Informationen für die korrespondierende Schicht auf der anderen Maschine stecken, die für die korrekte Wiederherstellung der Daten nötig sind. Auf der untersten Schicht (Schicht 1) findet die tatsächliche Kommunikation auf dem darunterliegenden Medium statt. Auf der anderen Maschine werden nun die Daten von der untersten Schicht in Empfang genommen und an die Schicht 2 übergeben. Diese öffnet den Umschlag und stellt mit den darin enthaltenen Informationen die korrekte Nachricht für Schicht 3 wieder her. Dies geschieht solange, bis die oberste Schicht erreicht ist. Diesen Satz von Schichten und Protokollen nennt man Protokollarchitektur. Das Schichtenmodell und die Protokollarchitektur, sowie die standardisierten Kommunikationsprotokolle bilden das OSI-Referenzmodell. 2.3 Motivation Der Name des Modells lautet Open Systems Interconnection. Dieses Referenzmodell ist als Vorschlag für die Standardisierung von Netzwerkprotokollen durch die ISO entstanden. Es wurde etwas später bzw. in gewissem Maße zeitgleich zu TCP/IP vorgeschlagen. Es sollte deshalb eher als theoretisches Konzept denn als technische Leitlinie der Entwicklung von Netzwerkschichten verstanden werden. Layer Name of Unit 7 Application Application ftp,http,smtp,pop3 6 Presentation Presentation A 5 Session Session 4 Transport TCP, UDP, SPX, Appleshare Transport 3 2 Network Data link IP, IPX, Appletalk N Ethernet-, ATM-Switch Network Data link Packet Frame 1 Physical Ethernet, TokenRing, ISDN Physical Bit Host A Real Connection Virtual Connection Flow of Data from A to B Host B A User-Application N Network-Protocol Abbildung 2.1: OSI-Schichtenmodell Kaum ein Protokoll für Internets setzt alle Vorschläge des Schichtenmodells um. Trotzdem ist es hilfreich für die Strukturierung und Abgrenzung von Netzwerkprotokollen und zum Verständnis für die Funktion von Netzwerken.

21 2.3. MOTIVATION 11 Hardware (-nahe) Protokolle für LANs und WANs lassen sich mit OSI erklären und einordnen. Auch die Abbildung der Dienste der TCP/IP-Suite kann innerhalb des OSI- Modells erfolgen. Die Kommunikation zwischen verschiedenen Hosts läßt sich anhand von OSI gut veranschaulichen. Deshalb wird dieses durchaus immer noch erwähnt bzw. gelehrt. Die sieben Schichten entstammen folgenden Designprinzipen: Eine Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird Jede Schicht soll genau definierte Funktionen erfüllen Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden Grenzen zwischen Schnittstellen so wählen, dass möglichst wenig Informationsfluß über Schnittstellen notwendig wird Es sind so viele Schichten vorzusehen, dass keine Notwendigkeit besteht mehrere verschiedene Funktionen in einer Schicht zu implementieren Schichten von unten nach oben (d.h. ausgehend von der Hardware hoch zur Applikation) sind in der Tabelle dargestellt. # Schicht Layer Orientiert Aufgabe Prot. (engl.) 7 Anwendungs- application Anwen-dungs- Verbindung zwischen - Benutzern und deren Tätigkeiten 6 Darstellungs- presentation Anwendungs- Datenformat des FTP - Informationsaustausches 5 Kommunikasession - Anwendungs- Verbindung zwischen TCP tionssteuer- Prozessen auf verschiedenen Rechnern 4 Transport- transport - Transport- Zusammensetzung TCP der Nachrichten 3 Vermittlungs- network - Transport- Adressierung IP der Nachrichten zwischen Rechnern 2 Sicherungs- data link - Transport- Beseitigung von Übertragunsfehlern durch Störungen 1 Bitübertragungsphysical - Transport- Betrieb der Netzkarten Tabelle 2.1: Das OSI-Modell mit Beispiel FTP als TCP/IP-Protokoll

22 12 KAPITEL 2. OSI-SCHICHTENMODELL 2.4 Die einzelnen Schichten Im OSI-Modell sind die Schichten 1-4 transportorientiert; sie entsprechen den verschiedenen Netzwerkprotokollen, welche in der Netzwerkhardware oder im Betriebssystem implementiert sind. Die Schichten 5-7 arbeiten anwendungsorientiert; sie finden üblicherweise innerhalb einer Anwendung statt. Jede Schicht soll sich dabei nur der Dienste der darunterliegenden Schicht bedienen. Die Implementation ist dabei beliebig, d.h. liegt im Ermessen des Anwenders oder Netzwerkdesigners. Der Austausch von Schichten soll dabei möglich sein, wenn die neue Schicht die Funktionen der alten zur Verfügung stellt. Die Aufgaben der einzelnen Schichten lassen sich wie folgt beschreiben: Bitübertragungsschicht regelt die Übertragung von rohen Bits über den Kommunikationskanal. Dabei handelt es sich um einen unstrukturierten Bitstrom. Die Bitübertragungsschicht enthält die Definition, welcher elektrischer, physikalischer Zustand einer binären Null bzw. einer Eins entspricht. Dazu zählt beispielsweise, welche Länge ein bestimmter Zustand andauern muss oder mit wieviel Volt signalisiert wird. Weiterhin erfolgt die Festlegung, wie gross bestimmte Toleranzen sein dürfen, damit ein Signal noch interpretiert werden kann und welche Abstände zwischen verschiedenen Zuständen liegen, damit diese sauber interpretiert werden können. Weiterhin zählt dazu die Festlegung von Kabeltypen und -qualitäten (optisch bzw. elektrisch) oder die Definition von Funkstandards für drahtlose Übermittlung. Bestandteil ist weiterhin die Definition von Steckern und Buchsen, die Anzahl benötigter Adern und die full- oder halfduplex Datenkommunikation Sicherungsschicht übernimmt die Umwandlung des rohen Datenkanals der Bitübertragungsschicht in eine Leitung, welche virtuell frei von unerkannten Übertragungsfehlern ist. Dies geschieht durch die Aufteilung des Datenstroms in Frames 1. Dabei erfolgt das Setzen von Rahmengrenzen durch spezielle Kontrollbits. Weiterhin werden einfache Prüfmechanismen geschaffen z.b. durch die Einführung von CRC-Prüfsummen. Die Sicherungsschicht erlaubt weiterhin eine Datenverkehrskontrolle. Sie kann Meldungen von Überschwemmungen eines Empfängers generieren. Darüberhinaus regelt sie die Zugriffssteuerung in Broadcastnetzen Vermittlungsschicht sichert die Steuerung des Teilnetzbetriebes. Sie ist sozusagen verantwortlich für die Auswahl der Paketrouten auf dem Weg vom Ursprungs- zum Bestimmungsort. Die auftretenden Routen können statisch, d.h. fest verdrahtet sein oder dynamisch für jede Sitzung festgelegt werden. Es geht auch noch dynamischer: Für jedes Paket einer Sitzung wird eine Route generiert. Bei Überlastungen der Teilnetze mit zuvielen Paketen muss eine Engpass- bzw. Stausteuerung erfolgen. Darüberhinaus können Abrechnungsfunktionen 2 in dieser Schicht implementiert sein. Die Vermittlungsschicht überwindet verschiedene Hardwareprotokolle. Sie kann Pakete in die angepaßte Größe für jedes Teilnetz umbauen. 1 anderer Name für Paket, um die Daten häppchen der verschiedenen Schichten unterscheiden zu können 2 z.b. für die Paketdurchleitung; da kaum ein Anbieter jede End-zu-Endverbindung im eigenen Netz realisieren kann

23 2.5. KONZEPTE Transportschicht ist für die Entgegennahme der Daten aus der Sitzungsschicht verantwortlich. Die Transportschicht regelt gegebenenfalls die geeignete Zerstückelung des eintreffenden Datenstromes. Diese Daten werden an die Vermittlungsschicht weitergegeben. Die Transportschicht bietet eine End-zu-End-Kontrolle der Korrektheit der Pakete und deren Reihenfolge. Dadurch erhält der Anwender einen fehlerfreien Punkt-zu-Punkt-Datenkanal. Die Transportschicht ist echte End-zu-End-Schicht, d.h. sie stellt die Ebene dar, auf der Programme Informationen miteinander austauschen können. Weiterhin erlaubt sie das Multiplexen mehrerer Datenströme, da ein Host durchaus mehrere Verbindungen unterhalten kann Sitzungsschicht soll den Benutzern an verschiedenen Maschinen erlauben, Sitzungen miteinander aufzubauen, d.h. einerseits einen gewöhnlichen Datentransport zu realisieren, aber auch zusätzliche Dienste anzubieten. Dialogsteuerungen und Tokenmanagement einiger Anwendungen könnten in der Sitzungsschicht verortet werden. Weitere mögliche Aufgaben wären die Synchronisation z.b. Recovery eines Datenstransfers nach einem längerem Ausfall. Die genannten Beschreibungen deuten bereits an, dass diese Schicht sich schwer abgrenzen läßt Darstellungsschicht realisiert Funktionen, die sich mit Syntax und Semantik der übertragenen Informationen beschäftigen. Hierzu zählt die Kodierung der Daten auf vereinbarte Weise 3. In der Darstellungsschicht erfolgt die Umwandlung spezieller Daten- und Objektstrukturen eines Rechners in die für die Netzübertragung geeignete Form Verarbeitungsschicht wird in einigen Darstellungen auch Anwendungsschicht genannt. Sie bezieht sich auf die letztendlich auf einem Host ablaufenden Netzwerk-Applikationen. Diese können z.b. eine einheitliche Terminalemulation 4 umfassen, die eine Vielzahl sehr unterschiedlicher Terminaltypen darstellen kann. Damit wird anderen Programmen (und deren Programmierern) die Ausgaben von Text und die Entgegennahme von Tastatureingaben erleichtert. Weiterhin könnte die Verarbeitungsschicht den Dateitransfer über verschiedene Standards von Dateisystemen und Namenskonventionen hinweg organisieren. Diese Erörterungen lassen sich ebenso auf -, Webdienste etc. anwenden. 2.5 Konzepte Für den Zusammenschluss verschiedener Netze sind spezielle Hardwarekomponenten notwendig. Diese regeln die Übergänge zwischen verschiedenen Teilnetzen und Netzwerktechnologien, die sich sowohl im Medientyp, den Adressierungsschemata und den Frameformaten unterscheiden können. 3 little- oder bigendian, ASCII oder Unicode, Kodierung negativer Ganzzahlen als Einer- oder Zweierkomplement,... 4 Mit Terminals sind im heutigen Sprachgebrauch die virtuellen Nachbildungen der meist seriellen Datensichtgeräte an Workstations oder Mainframes gemeint.

24 14 KAPITEL 2. OSI-SCHICHTENMODELL Diese Hardwarekomponenten können wie Hosts mit mindestens zwei Interfaces aufgefaßt werden. Sie sollen sich wie ein Host 5 im jeweiligen Teil-Netz verhalten, wobei die Zahl von Übergängen zwischen verschiedenen Netzwerken möglichst nicht begrenzt sein sollte. Hierfür dient der Einsatz sogenannter Router. Weiterhin: Schaffung eines Adressierungsschemas, welches hardwareunabhängig (z.b. von der Ethernetadressierung) ist Schaffung eines virtuellen Netzes; die Netzstuktur dieses Super -Netzes muss von Topologie und Ausdehnung der darunterliegenden Netze unabhängig sein abstraktes Kommunikationssystem,.h. Soft- und Hardwarelösungen bilden eine Illusion eines gemeinsamen übergreifenden Netzes Protokolle Protokoll dient als gemeinsame Vereinbarung (Standard) über die Kommunikationsparameter. Es wurden verschiedene Protokolle für den genannten Aufgabenbereich geschaffen: TCP/IP als bekanntester Vertreter dieser Gruppe, da das weltweite Internet dieses verwendet IPX/SPX als Netzwerkprotokoll von Novell Appletalk: Netzwerkdienst der Apple-Macintosh-Architektur DECnet: Vernetzung von Unix-Workstations X25: ITU-Standard für WAN-Technologien, Angebot von Telefongesellschaften Diese Protokolle besitzen Routingfähigkeit, d.h. verschiedene Netze können über spezielle Rechner (Router) miteinander gekoppelt werden. Sie bieten einen einheitlichen bzw. globalen Adressraum und sind für verschiedene Netzwerkhardware verfügbar. Andere Protokolle, z.b. NetBIOS von Microsoft, sind nur im LAN einsetzbar, weil sie über kein globales Adressschema verfügen, nicht routingfähig sind und nur auf bestimmte Netzwerkhardware anwendbar sind. Mit der Ausdehnung der Firmennetze, dem Ausbruch des Rechners aus dem Rechenzentrum, der Popularisierung von Computern spielen Netzwerke eine immer größere Rolle. Deshalb wurde ein allgemein standardisiertes, nichtproprietäres Netzwerkprotokoll gesucht, welches gleichzeitig die Unabhängigkeit von bestimmten Herstellern besitzt. Betriebserfahrungen und Robustheit im Einsatz waren weitere Argumente. Die TCP/IP-Suite hat sich umfassend durchgesetzt; andere Protokolle sind nur mehr Randerscheinungen. 2.6 Einordnungen Nach dem Aufbau eines Theoriegerüstes in Form des OSI-Modells, läßt sich nun eine Einordnung der im Folgenden vorgestellten Netzwerkprotokolle in einem kurzen Ausblick vornehmen. Dabei wird sichtbar, welche Protokolle jeweils für die Umsetzung bestimmter Aufgaben benötigt werden. 5 einfaches Mitglied in einem Netzwerk

25 2.7. AUFGABEN 15 Ethernet, TokenRing, ADSL, ISDN oder Modem definieren in erster Linie verschiedene Typen von Bitübertragungsschichten. Sie stellen die Übertragungsstandards, was Kabel und elektrische bzw. optische Signalisierung, Verbindungslängen etc. betrifft, sicher. Sie bestimmen außerdem die Datenraten und Half- oder Fullduplex-Betrieb, sowie die Kodierung der Daten für beste Erkennung und höchste Datenraten. Weiterhin implementieren Ethernet- und TokenRing jeweils die Medienzugriffsverfahren, wie CSMA/CD oder CA 6, die der Sicherungsschicht zuzuordnen sind. MAC-Adressierung ist ebenfalls ein Konzept der Sicherungsschicht. Ethernetswitches arbeiten auf dieser und schalten virtuelle Punkt-zu-Punkt-Verbindungen auf dieser Ebene. Ethernet implementiert weiterhin Verfahren zur Congestioncontrol. Auch Korrekturverfahren, wie sie bei Modemkommunikation definiert werden, sind der Sicherungsschicht zuzuordnen. Das Internet-Protokoll läßt sich der Vermittlungsschicht zuordnen. Es übernimmt die Paketadressierung der End-zu-End-Zustellung und implementiert die Routingfunktionalitäten. IP kann dabei auf austauschbare Bitübertragungs- bzw. Sicherungsschichten zurückgreifen. Es kann über Ethernet, GPRS, ADSL, ISDN oder Modem ohne Änderungen im Protokoll arbeiten. Dabei nimmt es evtl. Paketgrößenanpassungen vor. Dies geschieht durch die Steuerung der Paketfragmentierung auf dem Weg und durch den Zusammenbau im Zielhost. Der Weg eines Paketes von Rechner A zu Rechner B durch ein Netzwerk liesse sich im OSI-Modell wie folgt veranschaulichen. Weg eines Datenpaketes von Host A zu B über einen Router Schicht Host A Eth-HUB Router Switch Host B Abbildung 2.2: Weg eines Paketes durch OSI-Schichten 2.7 Aufgaben OSI 1. Worin unterscheiden sich das OSI- und TCP-Schichtenmodell? 6 Carrier Sense Multiple Access with Collision Detection bzw. Collision Avoidance

26 16 KAPITEL 2. OSI-SCHICHTENMODELL 2. Warum kann es passieren, dass einzelne Schichten vielfach nochmal unterteilt wurden? 3. Was sind Gründe um geschichtete Protokolle zu verwenden? 4. Ein System verwendet eine n-layer Protokollhierarchie. Eine Applikation generiert eine Nachricht von der Länge N Bytes. Auf jeder Schicht wird ein H Byte langer Header angefügt. Welcher Anteil der Netzwerkbandbreite wird allein durch die Headerinformation belegt? 5. Welche OSI-Schicht handelt die folgenden Aufgaben ab: a) Aufteilung des zu übertragenden Datenstroms in Frames und b) festzustellen, welche Route durch das Netzwerk benutzt werden soll? Netzwerke 1. Was sind die wesentlichen Unterschiedungen von packet-switching und circuit-switched Networks? 2. Wodurch kommen Ende-zu-Ende-Verzögerungen zustande? Woraus setzt sich die Gesamtverzögerung zusammen? Annahme: Pakete bewegen sich entlang einer festgelegten Route.

27 Kapitel 3 LAN Hardware 3.1 Ethernet Die in LANs am weitesten verbreitete Hardware ist im allgemeinen unter dem Namen Ethernet bekannt. Es umfaßt die Schichten 1 und 2 des ISO/OSI-Modells. Ethernets sind in der Installation relativ günstig, was, zusammen mit Übertragungsraten von bis zu 1000 Megabit pro Sekunde, zu seiner starken Popularität gesorgt hat. ISO/OSI Application Presentation Session IEEE reference model Upper-layer protocols Transport Network Data Link Physical MAC-Client Media Access (MAC) Physical (PHY) IEEE 802-spcific IEEE spcific Media-specific Abbildung 3.1: Ethernet im OSI-Schichtenmodell Ein Nachteil der Ethernet-Technologie ist die begrenzte Länge der Kabel, was die Verwendung auf LAN s (Local Area Network) beschränkt. Allerdings kann man aber mehrere Ethernet-Segmente miteinander verbinden, indem man sogenannte Repeater, Bridges oder Router verwendet. Repeater kopieren einfach die Signale zwischen zwei oder mehreren Segmenten, was bedeutet, dass alle Segmente zusammenarbeiten, als wäre es ein einzelnes Ethernet. Aufgrund der Timing-Anforderungen dürfen zwischen zwei Hosts im Netzwerk nicht mehr als vier Repeater verwendet werden. Bridges und Router sind da schon etwas aufwendiger. Sie analysieren die eingehenden Daten und leiten sie nur dann weiter, wenn sich der empfangende Host nicht im lokalen Ethernet befindet. Ethernet arbeitet wie ein Bus-System, bei dem ein Host die Pakete (oder Frames) mit einer Größe von bis zu 1500 Byte an einen anderen Host in demselben Ethernet übertragen kann. Ein Host wird dabei über eine sechs Byte lange Adresse (MAC) angesprochen, die in die Firmware der Ethernet-Karte fest eingetragen ist. Diese Adressen werden von der FCC in den USA zugeteilt. Die Sequenz von zweistelligen Hexadezimalzahlen, die jeweils durch Doppelpunkte voneinander getrennt werden, kennt inzwischen fast jeder, der mit 17

28 18 KAPITEL 3. LAN HARDWARE Transmission order: left-to-right, bit serial FCS error detection coverage FCS generation span PRE SFD DA SA Length/Type Data Pad FCS Field length in bytes Abbildung 3.2: Aufbau des Ethernet-Headers Netzwerken zu tun hat. Ein Ethernet-Header beginnt mit einer 64 bit (8 octets) langen Sequenz aus Nullen und Einsen um ein Paket einzuleiten. Dieses ist zur Synchronisation der angeschlossenen Geräte und zur Collision Detection erforderlich. Die ersten sieben Bytes besitzen jeweils einen Wert von während das letzte Byte mit dem Wert das Ende der Präambel ankündigt. Es folgen die Ziel und Quelladresse (jeweils 6 octets lang) und die Art des darüberliegenden Protokolls (kodiert in 2 octets). Nach den minimal 46 und maximal 1500 Byte Daten schliesst sich eine Prüfsumme (4 octets lang). Unterschreitet eine Datagrammgröße 46 Bytes, so muss mit Zusatz-Bits erweitert werden. Die Vermittlungsschicht verwendet das Längen-Feld im Header, um die Füllbits zu erkennen. Durch das CRC-Feld wird überprüft, ob irgendwelche Bits im Rahmen durch äußere Einflüsse (z.b. Dämpfung der Signalstärke, elektromagnetische Umgebungsstörungen, usw.) gekippt (komplementiert) wurden. Der Client berechnet den Wert des CRC-Feldes aus den übrigen Bits im Rahmen einschließlich der Präambelbits. Der Server wendet auf die empfangenden Bits im Rahmen dieselbe Berechnung an (CRC-Prüfung) und überprüft damit den vom Client eingetragenen Wert. Ethernet arbeitet nach dem CSMA/CD-Verfahren, was Carrier Sense Multiple Access/Collision Detection bedeutet. Bevor eine Datenübertragung beginnt, wird der Zustand des Netzes von der sendewilligen Station überprüft. Jede Station darf immer dann senden, wenn in diesem Moment keine andere Station Daten überträgt. Deshalb kann jede Station simultan horchen und senden. Ein von einem Rechner ausgesandter Frame wird von allen vorhandenen Rechnern registriert, aber nur der Ziel-Host liest das Paket und verarbeitet es. Hierin liegt ein Sicherheitsproblem von Ethernet, weil ein Rechner einfach alle im Netz kursierenden Frames untersuchen kann. Eine sendende Station überprüft - zur Sicherstellung, dass sie alleine sendete - ob das gesendete Signal gleich dem empfangenden ist. Sollte dies nicht der Fall sein, so verschickt die Station ein Störsignal (Jam-Sequence), um allen anderen Stationen zu signalisieren, dass eine Kollision stattfand. Anschliessend stellt sie das Senden ein. Die andere gleichzeitig sendende Station registriert dieses Signal und stellt ebenfalls das Senden ein. Der nächste Sendeversuch erfolgt zeitversetzt um einen Zufallsfaktor, damit ein weiteres Zusammentreffen von Paketen vermieden wird. Befindet sich jedoch eine sehr hohe Last auf dem Netzwerk, so wird - aufgrund dieses Verfahrens zu Kollisionsbehebung - der Datendurchsatz dieser Netzwerktechnologie stark eingeschränkt. Moderne Netzwerkkomponenten wie Switches reduzieren das Sicherheitsund Kollisionsproblem, in dem sie zum einen die Datenpakete nur noch an dem Port zur Verfügung stellen, an dem eine bestimmte MAC anliegt (hierzu haben diese Geräte übli-

29 3.1. ETHERNET 19 cherweise einen Speicher von MAC-Adressen) und zum anderen wird per Store&Forward das Zusammentreffen von Paketen vermeiden Ethernet-Adapter Die Protokolle sind in einen sogenannten Adapter, welcher auch als Netzwerkschnittstellenkarte bekannt ist und der mit einem ROM sowie mit einem DSP-Chip versehen ist, implementiert. Ein Adapter ist eine halbautonome Einheit. Er besitzt eine eigene feste Adresse, MAC-Adresse (Media Access Controll), welche bei der Herstellung in das ROM des Adapters fest eingebrannt wird. Diese Adresse ist sechs Bytes lang und wird normalerweise in hexa-dezimaler Notation ausgedrückt. Somit leitet die Vermittlungsschicht des sendenden Clients Datagramme an den Adapter der Sicherungsschicht weiter, während dieser dann die Erweiterung des Ethernet-Headers übernimmt und den so entstandenen Rahmen auf der Kommunikationsleitung überträgt. Der Adapter des empfangenden Servers extrahiert dann die Datagramme aus den Rahmen und leitet sie nach der Überprüfung auf Fehler gegebenenfalls an die Vermittlungsschicht weiter. Der Adapter besitzt die Freiheit einen Rahmen zu verwerfen, falls er feststellt, dass dieser fehlerhaft ist, ohne die oberen Schichten informieren zu müssen. Ein wesentlicher Grund dafür, warum man auf der Sicherungsschicht MAC-Adressen und keine gewöhnliche IP-Adressen verwendet, ist, dass dann die Adapter kaum andere Protokolle der Vermittlungsschicht (z.b. IPX, DECNet) unterstützten könnten und somit ihre Flexibilität verlieren würden. Adressauflösungsprotokolle wie ARP, dienen den Sende-Adaptern, aus den Ziel-IP- Adressen die MAC-Adressen der entsprechenden Empfangs-Adapter zu ermitteln. Es ist zu erwähnen, dass ARP nur die IP-Adressen in MAC-Adressen auflöst, deren Hosts sich im gleichen LAN befinden Koaxialkabelbasierte Netze für 10 MBit max. 30 Stationen pro Segment max. 100 Stationen pro Segment TERM 50Ohm 10Base2 TERM 50Ohm TERM 50Ohm PC 1 PC 2 WS 1 WS 2 WS 3 CHEAPER-NET T-Connector 2,5m 185m max. 4 Repeater Repeater MAUI 500m YELLOW-CABLE TERM 50Ohm 10Base5 Abbildung 3.3: Regeln in BNC-Netzen Thin Ethernet, Cheaper Net oder auch BNC bezeichnet die inzwischen veraltetete Vernetzung mittels 50 Ohm abgeschirmten Koaxialkabel (wie beim Rundfunk; Verbindungsstücke und -kupplungen sind in BNC-Technik ausgeführt. Die Enden müssen mit Endwiderständen terminiert, d.h. abgeschlossen werden.). Diese Topologie ist preiswert und recht einfach; neue Knoten sind mit geringem Aufwand einzufügen. Die Nachteile liegen jedoch in der primitiven Technik und seiner Empfindlichkeit. Die Unterbrechung des Kabels an einer Stelle führt zum Ausfall des ganzen Netzwerk(-segment)es. Bezeichnet wird dieser Standard mit 10Base2. Mittels Cheapernet können bis zu 185 m überbrückt werden. Der ursrpüngliche Standard 10Base5 basiert auf dickerem Koaxialkabel, wobei die Anschlüsse

30 20 KAPITEL 3. LAN HARDWARE der Endgeräte mittels Transceiver erfolgte. Hiermit sind bis zu 500 m Gesamtlänge erreichbar Twisted-Pair-basierte Verkabelungen 10/100 Mbit Twisted Pair Kabel mit 10/100 Mbit verwendet vier Kupferadern, die paarweise verdrillt sind. Die maximale Segmentlänge liegt hier bei 100 m. Bei mehr als zwei Rechnern ist nun üblicherweise zusätzliche Hardware notwendig, die als Hub bezeichnet ist. Die Verkabelung erfolgt sternförmig zum HUB und erlaubt die einzelne Segmentierung (Abschaltung) eines Rechners, falls es zu Fehlern auf dem Kabel kommt. Im 8-adrigen Kabel bzw. auf der 8-poligen Anschlussdose werden üblicherweise die Kabelpaare 1,2 und 3,6 verwendet. Möchte man zwei Rechner direkt mittels TP-Kabel verbinden, muss dieses gekreuzt sein, damit Empfangs- und Sendeanschlüsse entsprechend miteinander verbunden werden. Diese Aufgabe wird üblicherweise von einem Hub bzw. Switch übernommen. Eine andere Möglichkeit ist die beiden Rechner mit einem Cross- Connenct-Kabel zu verbinden. Damit Endgeräte und Netzwerkkomponenten mit unterschiedlichen Übertragungsraten in einem Netz betrieben werden können, sind Komponenten, die 100 Mbit transferieren können, mit einem Media Independent Interface (MII) ausgestattet. Dieses handelt beim Aufbau der Verbindung die Übertragungsrate, sowie den Verbindungsmodus (Voll- oder Halbduplexbetrieb) aus Mbit Für Ethernetverbindungen mit 1000 Mbit (Gigabit) benötigt man vier verdrillte Kupferadernpaare. Das hat zur Folge, dass ältere Kabel aufgrund ihrer Beschaltung und elektrischen Eigenschaften nicht mehr genutzt werden können. Gigabitnetzwerkkomponenten verfügen analog zu 100 Mbit Geräten über ein Gigabit Media Independent Interface (GMII), welches die Aushandlung der Verbindungsart vornimmt. Auf diese Weise können ältere Geräte weiterhin in einem solchen Netz betrieben werden. Das GMII ist in der Lage automatisch zwischen gekreuzten und ungekreuzten Kabelverbindungen zu unterscheiden und die Verbindung entsprechend zu schalten. 416 byte for 1000Base-X 520 byte for 1000Base-T PRE SFD DA SA Length/Type Data Pad FCS Extension Field length in bytes Abbildung 3.4: Erweiterungen des Ethernet-Standards für Gigabit Ethernet unter Linux Die durchschnittliche vernetzte Linux-Maschine hängt an einem Ethernet. Für mobile Endgeräte wie Laptops oder Tablet-PC gilt, dass dieses noch nicht einmal die ganze Zeit der Fall sein muss. Wenn auch Ethernets zu den fehlerfreiesten Netzwerken zählen, so müssen trotzdem nicht immer alle Komponenten problemlos miteinander kooperieren. Klappt die Aushandlung der Verbindungsgeschwindigkeit beispielsweise zwischen älterer Switch und billigem Netzwerkadapter nicht, kommt kein Datenaustausch zustande.

31 3.1. ETHERNET 21 Weniger dramatisch ist eine Netzwerkkarte im Fullduplex-Mode an einem Hub. Hier leidet die Verbindungsqualität unter Umständen heftig, wegen der ausgeschalteten Kollisionserkennung der Netzwerkkarte. Als Ergebnis beobachtet man Datenraten durchaus weit unter der nominellen Schnittstellengeschwindigkeit. An dieser Stelle setzen Programme wie ethtool, mii-diag oder die Toolsuite nictools an. Man als Systemadministrator ethtool eth0 aufruft, erhält man einen umfassenden Überblick zum Ethernet-Interface eth0. Hierzu gehören die unterstützten Interface- Geschwindigkeiten, die aktuell benutzte Geschwindigkeit, der Duplex-Status, welche Art des Mediums angeschlossen ist, ob ein Link besteht und weiteres. Wenn es Probleme mit der automatischen Aushandlung der Parameter gibt, lässt sich diese ausschalten: s02:~ # ethtool -s eth0 autoneg off s02:~ # ethtool -s eth0 speed 10 s02:~ # ethtool -s eth0 duplex half Anschliessend kann die Geschwindkeit und die Art des Links manuell eingestellt werden. Das Ergebnis der letzten beiden Kommandos sorgt für eine Netzwerkverbindung in der Qualität des alten BNC-Ethernets - 10 Mbits half duplex. Unterstützt die Netzwerkkomponente Hub oder Switch die Anzeige der Geschwindigkeit, kann man die Änderung der Parameter dort nachvollziehen. Nach der Wiedereinschaltung der Autonegotiation reicht ein kurzes Ziehen und Wiedereinstecken des Kabels, um wieder die alten Parameter vor dem Experiment zu erhalten. Die Einstellungen kann ein Admin natürlich auch Schritt-für-Schritt in der Kommandozeile vornehmen, indem er die eben gezeigten Befehle umkehrt. Ein gezogenes Kabel quittiert ethtool mit der Meldung Link detected: no. Ähnliche Informationen liefert auch mii-diag. hermes:~ # mii-diag eth0 Basic registers of MII PHY #1: d e1 41e The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT. End of basic transceiver information. ethtool kann bei einer Reihe von Netzwerkkarten, beispielsweise einigen Onboard Via- Rhine, dazu verwendet werden, Wake-on-LAN einzuschalten. Dieses erreicht man durch ethtool -s eth0 wol g. Der Parameter g steht für Wake on MagicPacket. Einen solchen Weckruf kann das Programm ether-wake erschallen lassen. ether-wake 00:10:20:30:40:50 schickt ein geeignet formatiertes Ethernet-Frame an die angegebene MAC-Adresse. Es gibt eine ganze Reihe weiterer Programme, die solche Pakete schicken können, auch über Router hinweg. Möchte man permanent den Link-Status überwachen, weil man beispielsweise nicht zum Ablesen der LEDs an der Karte auf die Rechnerrückseite krabbeln will, können hier die Nic-Tools weiterhelfen. So überwacht beispielsweise für eine SMC Epic100-Karte (83c170) epic-diag -mm permanent ob ein Kabel angeschlossen ist oder ein Link zu einer anderen Netzwerkkomponente besteht. Die Diag-Tools - der Name beginnt immer mit der Netzwerkkarte oder dem Chip - können weitere Informationen, beispielsweise über den Inhalt des Konfigurations-EEPROMs oder Device-Register ausgeben: via-diag -e oder rtl8139-diag -a.

32 22 KAPITEL 3. LAN HARDWARE 3.2 Funk-Netze Drahtlose lokale Kommunikationssysteme, sogenannte Wireless LANs, finden bei zunehmender Produktvielfalt eine immer grössere Verbreitung. Sie basieren üblicherweise auf Funk als Übertragungsweg. Lokale Funknetze können eine effiziente Alternative zu aufwendigem Verlegen von Kabeln darstellen. Eine Ad-hoc-Vernetzung per Funk erlaubt den spontanen und mobilen Datenaustausch. Kabellose Eingabegeräte erhöhen den Bedienkomfort von Computern. Mit heute verfügbarer drahtloser Technik sind eine ganze Reihe von Mobilitätsansprüche der Nutzer von IT-Technik realisierbar. Die wichtigsten technischen Systeme hierzu sind z.z. WLAN (IEEE ) und Bluetooth-Module (IEEE ). Funknetze sind komplexer im Zugriff als drahtgebundene LANs. Die begrenzte Reichweite der einzelnen Teilnehmer und Stationen verhindern, dass ein übergreifendes Signalerkennen möglich ist oder stark erschwert wird. Zusätzlich soll eine Bewegung zwischen verschiedenen Zellen ermöglicht werden. Diese Fähigkeit von Netzen wird als Roaming bezeichnet. Um die beschriebenen Probleme in den Griff zu bekommen, wird ein MAC-Sublayer- Protokoll implementiert. Damit wird ein einheitliches Netz über verschiedene Sender möglich. Ein naiver Ansatz wäre Verwendung des CSMA/CD-Verfahrens, wie es beim drahtgebundenen Ethernet geschieht. Jedoch hört 3 nichts bei einem Transfer zwischen 1 & 2 und könnte zu 2 übertragen wollen. Die Leitung scheint frei zu sein, obwohl gesendet wird. Diese Situation wird als Hidden Station Problem bezeichnet. Es tritt weiterhin folgende Schwierigkeit auf: Bei einem Datentransfer von 2 zu 1 denkt 3, dass Zelle blockiert ist und unterläßt einen gleichzeitigen Transferversuch zu 4, obwohl dadurch keine gegenseitige Störung auftreten würde. Auf diese Weise wird Bandbreite verschenkt: Exposed Station Problem. Deshalb wird ein neues Zugriffsverfahren eingeführt. MACA(W) bezeichnet Multiple Access with Collision Avoidance. Bei diesem Verfahren wird vor dem eigentlichen Datentransfer ein kurzes Testsignal mit der Bezeichnung RTS (Ready To Send) gesendet. Mit diesem Signal erfolgt die Ankündigung des großen Datenblocks. Die Zielstation antwortet mit einem CTS (Clear To Send). Reichweite von RTS CTS Reichweite von 2 5 MACA (W) Zugriffsverfahren für WLAN Abbildung 3.5: Sichtbarkeitsproblem Alle Stationen, die ein RTS-Signal hören, müssen in der Zwischenzeit schweigen. Es gibt eine Optimierung des Protokolls, die mit MACAW bezeichnet wird. Folgende wichtige Standards regeln die Implementierung drahtloser Netzwerke: a bis 54 Mbit/s im 5 GHz Band b derzeitige Implementation bis 11 Mbit/s

33 3.2. FUNK-NETZE g bis 54M bit/s jedoch im 2,4 GHz Band Mit dem derzeitig verfügbaren Standard sind bei 11 Mbit/s nominaler Übertragungsrate aufgrund von Protokolloverheads real ca. 6 Mbit/s erreichbar. Verwendet wird das für Forschung, Medizin und private Zwecke freigegebene Frequenzband bei 2,4 GHz. Die Leistung der verwendeten Geräte, Access-Points, Netzwerkkarten oder Repeater darf maximal 100 mw betragen. Die Reichweiten liegen indoor je nach Gebäudebeschaffenheit bei 30 bis 100 m. Im Freien sind bei Sichtkontakt 300 bis 500 m und mit Antenne verstärkt bis zu mehreren Kilometern überbrückbar. Ein Funknetz kann in verschiedenen Modi aufgebaut werden: AdHoc, Managed, Master, AccessPoint. Hiervon hängt ab, ob die Netzwerkkarten auf eine feste Frequenz eingestellt werden müssen oder sie nach einem gemeinsamen Kanal suchen. Beim AccessPoint-Modus übernimmt der AccessPoint die Steuerung der Verbindung. Der g Standard versucht bis zu 54 Mbit/s noch im 2,4 GHz Band zu realisieren, weiterhin gibt es herstellereigene Zwischenstandards bis 22 Mbits/s, die derzeitig auf dem Markt auftauchen und meistens nicht untereinander kompatibel sind. Die WiFi-Zertifizierung kennzeichnet Geräte, die nach den gegebenen Standards interoperabel sind. Erreicht werden die höheren Bandbreiten durch Kanalbündelung, womit insgesamt weniger Kanäle für verschiedene Netze zur Auswahl stehen. Die Aufteilung des zur Verfügung stehenden Frequenzspektrums erfolgt auf bis zu 13 Kanäle 1 Bei einem engmaschigem Netz von AccessPoints ist eine geschickte Kanalaufteilung notwendig, um Signalstörung oder Auslöschung zu vermeiden. Mehrere AccessPoints können in einem Bereich betrieben werden, wenn ihre Kanäle weit genug auseinanderliegen. Alle Bandbreitenangaben beziehen sich auf ein Shared Medium, d.h. bei steigender Teilnehmerzahl steht dem einzelnen eine niedrigere Datenrate, vergleichbar mit Ethernet über Koaxialkabel, zur Verfügung. Die nutzbare Bandbreite hängt also von den Teilnehmern pro Funkzelle ab. Es ist jedoch möglich mehrere Zellen parallel zu betreiben. Die Kennung erfolgt über die sechsstellige MAC, mit dieser erfolgt auch die Anmeldung an den AccessPoints. 2,4000GHz 2,4835GHz Kanalbelegung und evtl. Überschneidung beim WLAN (802.11b) Abbildung 3.6: Kanalaufteilung 1 Die Verteilung ist in verschiedenen Ländern unterschiedlich, so dass nicht immer alle Kanäle genutzt werden dürfen.

34 24 KAPITEL 3. LAN HARDWARE Ein wesentliches Problem haben WLANs gegenüber ihren drahtgebundenen Pendents; sie sind sehr offen. Deshalb muss eine ganz andere Absicherung als bei drahtgebundenen Netzen erfolgen. Zur Sicherung der Verbindung wurde WEP (WiredEquivalentPrivacy) eingeführt. Es arbeitet mit 64 bzw. 128 Bit Schlüsseln. Diese sind jedoch nicht unproblematisch: Sie besitzen einen Klartext-Initialisierungsvektor (24 bit), der jeder Nachricht voransteht. Damit ist der WEP-Key nur noch 40 bzw. 104 Bit lang. Die Einfachheit der Konfiguration von WLANs bringt weitere Probleme mit sich: Die AccessPoints arbeiten meistens sofort und ohne voreingestellte Absicherung. Zusätzlich werden meistens DHCP-Server für sich anmeldende Geräte betrieben, die meist so konfiguriert sind, dass jeder Host eine Adresse erhält. Deshalb gibt es inzwischen eine Art Volkssport: WarDriving (oder WarChalking - Suchen nach offenen WLAN-Netzen). 3.3 TokenRing TokenRing wurde von IBM entwickelt und ist heutzutage nur noch in alten Netzen im Einsatz. Im Gegensatz zu Ethernet kreist zur Zuteilung der Sendeerlaubnis ein Token, welches dem Netzadapter - der im Besitz dieses Tokens ist - erlaubt Pakete zu verschicken. So kommt es nicht zu Kollisionen und die Bandbreite des Netzes (üblicherweise 4 oder 16 Mbit) kann auch mit einer grösseren Zahl von Maschinen besser ausgenutzt werden, als im ungeswitchten Ethernet. Die Verzögerungszeiten in einem TokenRing liegen üblicherweise unter 250 ms. In der Regel berechtigt der Besitz des Tokens nur zur Sendung eines Blocks (non exhaustive). Im anderen Extremfall könnte auch definiert werden, dass die Station soviele Datenblöcke senden kann, wie sie möchte (exhaustive). Damit könnte aber eine Station, die den Token besitzt, alle anderen dominieren. Normalerweise wird deshalb nur ein Block gesendet. Außerdem wird die Dauer der Sendeberechtigung befristet (Token Holding Time, z.b. 10 ms). Solange das Netz fehlerfrei funktioniert, stellt Token-Ring ein sehr einfach zu bedienendes Verfahren dar. Komplexer sind die Aufgaben beim Initieren des Netzes und bein Ein- oder Auskoppeln von Stationen. TokenRing ist das einzige Netz mit aktiven Stationen, die aus Eingabe- und Ausgabeeinheit bestehen. Grundsätzlich sind alle Stationen gleichberechtigt, jedoch übernimmt eine von ihnen als aktiver Monitor besondere Überwachungsaufgaben im Netz. Eine andere Station überwacht als passiver Monitor den aktiven Monitor und kann gegebenenfalls dessen Aufgaben übernehmen. Die Aufgaben des aktiven Monitors sind: Erzeugen des Ringtaktes Überwachen des Tokens (Neuen Token erzeugen, falls er verloren geht; Verhindern mehrerer Tokens) Unterbinden permanent kreisender Blöcke oder Tokens erhöhter Priorität. (Generell: Ring säubern durch Senden eines Purge Ring Frame an alle Stationen und Erzeugen eines neuen Frei-Tokens). Verhindern, dass mehrere Monitore aktiv sind. Verzögerung des Token-Rahmens um 24 Bit-Zeiten (die Länge des Token-Rahmens beträgt 24 Bit). Auch bei extrem kleinem Ring wird so sichergestellt, dass eine Station den Token-Rahmen vollständig senden kann, bevor sie ihn wieder empfängt. In regelmäßigen Abständen sendet der aktive Monitor einen Active Monitor Present Frame an alle Stationen im Ring. Gleichzeitig wird dadurch eine Prozedur in Gang gesetzt,

35 3.3. TOKENRING 25 die allen Stationen die Adresse des jeweiligen Vorgängers im Ring liefert (NAUN = Nearest Active Upstream Neighbour) - eine Information, die nur im Fehlerfall wichtig ist. Ein Fehler auf Empfangsseite bedeutet, dass der eigene Empfänger oder der Sender des NAUN defekt ist. Die Auswahl des aktiven Monitors geschieht per Claim-Token Process durch: den derzeit aktiven Monitor, wenn dieser Probleme bei der Durchführung seiner Aufgaben hat, einen passiven Monitor, wenn der aktive Monitor nicht korrekt arbeitet (z.b. Timeout auftritt). eine neu eingegliederte Station, wenn diese das Fehlen des aktiven Monitors feststellt. Token-Ring-Netze werden normalerweise als Stern-Ring-Verbindungen mit passiven Ringleitungsverteilern aufgebaut. In den Ringleitungsverteilern befinden sich Relais (die von den Stationen gesteuert werden); sie dienen der Eingliederung von Stationen und der Schaltung von Ersatzringen bei Defekten. Die Eingliederung einer Station erfolgt in fünf Schritten: 1. Ist ein Adapter vom Ring getrennt, sind gleichzeitig Eingangs- und Ausgangsleitung kurzgeschlossen. Es erfolgt zunächst ein Adaptertest. Nach dem Test versorgt der Adapter die Relais mit Strom und wird in den Ring eingegliedert. 2. Die Station hört nun den Ring ab. Wenn sie innerhalb einer festgelegten Zeit keine Aktivität des aktiven Monitors wahrnimmt, startet sie den Prozeß zur Auswahl des aktiven Monitors. 3. Durch Aussenden eines Duplicate Address Test Frame prüft die Station die Eindeutigkeit ihrer Adresse. Ist sie nicht eindeutig, koppelt sich die Station wieder ab. 4. Durch den NAUN-Prozeß erfährt die Station die Adresse ihres Vorgängers und ist nun ins Netz eingegliedert. 5. Von den Voreinstellungen abweichende Parameter können nun bei einer Server-Station abgefragt werden, sofern dies nötig ist. Die Funktionen von Monitor und von den eingegliederten Stationen müssen nicht nur einmalig initiiert, sondern auch ständig überwacht werden. In vielen Fällen sind dies zahlreiche Aktionen, die auch viele Blöcke auf dem Netz zur Folge haben und in deren Verlauf auch Fehler- und Ausnahmebedingungen auftreten können. Der Nachteil von Token-Ring liegt darin, dass beim Ausfall einer Station oder bei Kabeldefekten das Netz unterbrochen wird. Wird die defekte Station hingegen abgeschaltet, so schalten die Relais im Ringleitungsverteiler die Leitung durch. Token Ring ist genormt nach IEEE Jede Station empfängt, liest und sendet die auf dem Ring zirkulierenden Daten. Dabei gibt sie im allgemeinen nach dem Lesen die jeweilige Nachricht an die Nachbarstation weiter. Jedes Paket enthält die Adresse des Senders (SA) und die Zieladresse (DA). Wenn die Zieladresse mit der eigenen Adresse übereinstimmt, wird die Nachricht in den lokalen Speicher kopiert. Dies wird der lokalen LLC-Komponenete (Logical Link Control) gemeldet, und es wird ein Quittierungsfeld- oder Fehlerfeld entsprechend verändert. Anschließend wird diese Nachricht an die Nachbarstation weiter gesendet. Die sendende Station entfernt die von ihr gesendete Nachricht und interpretiert die Quittierungsfelder. Um Senderecht zu erhalten, muß jede Station das Token erhalten. Dies kann von jeder Station mit einer entsprechenden Priorität vorab reserviert werden:

36 26 KAPITEL 3. LAN HARDWARE Priorität Anwendung 0 frei verfügbar, von den meisten Anwendungen verwendet 1-3 frei verfügbar 4 von Bridges verwendet 5,6 reserviert, jedoch nicht verwendet 7 für die Administration des Ringes verwendet Tabelle 3.1: Prioritätslevel bei TokenRing Nur die Station mit der höchsten reservierten Priorität erhält somit das Senderecht. Diese Prioritäten, zusammen mit der festgelegten maximalen Umlaufzeit eines Paketes, ermöglichen eine garantierte Datenübertragung kontinuierlicher Medientypen. 3.4 Netzwerk-Interfaces von Linux Auf irgendeine Weise müssen Netzwerkdatenpakete in eine Linuxmaschine hineinkommen oder diese verlassen können. Dies geschieht über sogenannte Netzwerk-Interfaces. Durch den Namen des Interfaces wird meistens die Art der Verbindung oder der verwendeten Netzwerkhardware spezifiziert. Anders als bei anderen Unixes verwendet Linux für alle Ethernet-Interfaces die Bezeichnung ethn. Das N ist eine natürliche Zahl zwischen 0 für das erste Interface und n-1 für die letzte Netzwerkkarte, die in eine Maschine eingebaut ist. Ein Rechner kann durchaus über etliche Interfaces auch von verschiedenen Typen verfügen. Die Verfügbarkeit eines bestimmten Interfaces hängt meistens von einem Kerneltreiber ab. Mit dem Laden des entsprechenden Moduls für einen TokenRing, Ethernet oder ähnliche Adapter steht sodann das entsprechende Interface zur Verfügung. Dabei hängt die Reihenfolge der Nummerierung von der Reihenfolge des Modul-Ladens oder der automatischen Erkennung des Linux-Kernels ab. TokenRing-Adapter stellen nach dem Laden der entsprechenden Kernelmodule ein Netzwerkinterface vom Typ tr0 und folgende für weitere Adapter dieser Art bereit. Ähnliches geschieht bei den entsprechenden Modulen für ATM, FDDI und andere Netzwerkhardware. Eine Besonderheit ist das Loopback-Interface, welches mit dem Einschalten der TCP/IP Unterstützung, im Kernel automatisch zur Verfügung steht. Es wird mit lo bezeichnet und existiert nur in einfacher Ausführung. Weiterhin gibt es eine Reihe von Software-Interfaces, wie ppp0 für PPP-Verbindungen verschiedener Art, slip0 für Serial-Line-IP, dummy0 für Testzwecke, ipsec0 für IPsec-Verbindungen und weitere. dirk@linux:~/kurs> /sbin/ifconfig cipcb0 Link encap:ipip Tunnel HWaddr inet addr: P-t-P: Mask: 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: Bcast: Mask: inet6 addr: fe80::202:b3ff:fe87:5343/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100

37 3.5. AUFGABEN 27 RX bytes: (758.6 Mb) TX bytes: ( Mb) Interrupt:10 Base address:0xec00 Memory:dffff000-dffff038 lo vmnet8 Link encap:local Loopback inet addr: Mask: inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes: (765.6 Mb) TX bytes: (765.6 Mb) Link encap:ethernet HWaddr 00:50:56:C0:00:08 inet addr: Bcast: Mask: inet6 addr: fe80::250:56ff:fec0:8/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:4297 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Mit dem Kommando ifconfig erhält man z.b. obige Ausgabe, welche ein Interface für CIPE (cipcb0), ein klassisches Ethernet-Interface (eth0), das Loopback-Interface (lo) und ein virtuelles Ethernet-Interface für die Software VMware (vmnet8) als konfiguriert anzeigt. Die angezeigten Zusatzinformationen variieren in Abhängigkeit vom Interface-Typ. Die Maximum Transfer Unit (MTU) hängt von der darunterliegenden Netzwerkhardware ab und liegt, z.b. im Ethernet bei 1500 Byte. Das Loopback-Interface, welches nur in Software auf der Maschine selbst stattfindet, kann in einer Einheit bis zu 16 kbyte übertragen. Hardwaredaten, wie verwendeter Interrupt und Speicherbereiche findet man natürlich nur bei Interfaces, die direkt mit einer Hardware zu identifizieren sind. 3.5 Aufgaben 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?

38 28 KAPITEL 3. LAN HARDWARE

39 Kapitel 4 WAN Hardware 4.1 Einleitung Der Begriff Internet hat heute einen festen Platz in fast jedermanns Wortschatz. Die Entdeckung des Internets beeinflusst das Leben aller Generationen. Kommunikation (Chatt, , ), Einkaufen, Überweisungen (Online-Banking), Recherchieren - um nur einige zu nennen - sind Bereiche, in die das Internet auf selbstverständliche Art und Weise Einzug gehalten hat. Das Internet ist heutzutage aus fast keinem Lebensbereich mehr wegzudenken. Das Internet Protokoll selbst definiert jedoch keine Hardware, die zur Bitübertragung eingesetzt werden kann. Die folgenden Abschnitte wollen deshalb versuchen, dem Leser einem Blick hinter die Kulissen der physikalischen Datenübertragung zu verschaffen. Dabei wird insbesondere auf die eingesetzten Technologien und Methoden der Datenübertragung eingegangen. Wie aus dem Namen bereits ersichtlich, bilden Computernetzwerke einen Verbund von mehreren Computern. Dabei können diese Computer sich alle in einem Raum befinden und über sogenannte Netzwerkkabel direkt miteinander verbunden sein oder sich in unterschiedlichen Teilen der Welt aufgestellt sein und über Netzwerkkabel und Funknetze miteinander kommunizieren. Sobald in irgendeiner Form mindestens zwei physikalisch getrennte Computer miteinander verbunden sind, spricht man von einem Computernetzwerk. Im Fachjargon bezeichnet man alle Computer, die im Netzwerk registriert sind, als Hosts oder Endsysteme. In diesen Unterlagen werden zumeist die Begriffe Host oder Netzwerkrechner verwendet werden. In der heutigen Zeit existieren unzählige Computernetzwerke (kurz: Netzwerke). Ein Netzwerk liegt bereits vor, wenn in einem kleinen Haushalt die Computer aller Familienmitglieder über ein lokales Netz (LAN) miteinander verbunden sind. Umfangreichre Netzwerke sind beispielsweise Unternehmensnetzwerke, Firmennetzwerke oder Universitätsnetzwerke. Das berühmteste Netzwerk ist aber sicherlich das öffentliche Internet, welches Millionen von Computern miteinander verbindet und so als ein Zusammenschluss von verschiedenen Netzwerken interpretiert werden kann. Da - wie oben bereits erwähnt - die Hosts sich in den verschiedensten Teilen der Welt befinden können und in jedem Land unter Umständen andere Standards bezüglich der eingesetzten Computertechnologien existieren, beschäftigte man sich schon in den früheren Jahren der Netzwerkeinführung mit der Frage des reibungslosen Ablaufes der Kommunikationen zwischen den verschiedenen Hosts. 29

40 30 KAPITEL 4. WAN HARDWARE 4.2 Leistung und Kosten der einzelnen Technologien Leistung / Datendurchsatz In Tabelle 3.1. sind die häufig verwendeten Verbindungsprotokolle aufgeführt. ATM, ISDN und Modem werden eher dem WAN-Bereich, der Rest dem LAN zugeordnet. Aus der Tabelle geht die max. Reichweite, die Anzahl der Knoten und der Datendurchsatz hervor Kosten Die Kosten für die verschiedenen Netzwerktypen sind in Tabelle 3.2. aufgelistet. Sie lassen sich hier natürlich nur grob angeben. Bei Festinstallationen wird man noch die Aufwendungen für Anschlussdosen (10-20 EUR/Stück), die Unterverteiler (Patchpanel ( EUR), Datenschränke ( EUR), Patchkabel (TP 2.5 EUR/m, LWL 12 EUR/m...) mit einplanen müssen. Wenn Lichtwellenleiter zum Einsatz kommt, sind die Aufwendungen noch etwas höher anzusetzen, da für den Anschluss (das Spleissen) in den meisten Fällen eine Firma beauftragt werden muss. Bei einer Funkvernetzung entfallen die Kosten für eine Festinstallation, jedoch sind die weitaus höheren Aufwendungen für die Netzwerkkarten und die Access-Points zu berücksichtigen. Medium Reichweite Knoten Durchsatz Funk-LAN einige 100m ca Mbits ADSL mehrere km Mbit ATM mehrere km???? Mbits Ethernet (TP) 100 m Mbits Ethernet (BNC) 185 m ca Mbits ISDN Kbits loopback Mbits Modem Kbits GPRS/HSCSD mehrere km KBit UMTS mehrere km KBit Serieller Port 30 m Bits Tokenring 100 m 8 4, 16 Mbits Tabelle 4.1: Leistung und Datendurchsatz einiger Netzwerke Einige Netzwerk-Technologien wird man nur noch in bestehenden Installationen oder Computer-Flohmärkten antreffen. Hierzu gehören sicherlich BNC-Ethernet, TokenRing oder auch Parallelport-Verbinder. 4.3 Telefonnetze Telefonnetze gehören zu den ältesten Weitverkehrsnetzen überhaupt. Die ersten Zweidraht- Kupfer-Telefonnetze wurden bereits Ende des 19. Jahrhunderts eingerichtet. Die Versorgung mit Telefonanschlüssen liegt in Deutschland inzwischen bei nahe 100 Prozent. Datennetze kamen deutlich später. Deshalb wurden die ersten Datenleitungen über Telefonnetze geschaltet. Die meisten Internet-Benutzer verwenden in irgendeiner Form Telefonleitungen für die Verbindung. Dabei geht der Trend jedoch eindeutig weg von den alten analogen Telefonanschlüssen über ISDN hin zu DSL. Jedoch bleibt der Anbieter der Zweidraht-Leitung

41 4.3. TELEFONNETZE 31 Medium Adapter Kabel Gebühren (ca. EUR) ATM EUR 4/m (LWL) Grosskunde Parallelport Ethernet (TP 1000) EUR 0.70/m - Ethernet (TP 100) 4-40 EUR 0.70/m - Ethernet (TP 10) 0.70/m - Ethernet (BNC 10) 0.20/m - Funk-LAN (2/11 Mbit) EUR 500/AccessPoint - ISDN Telefongebühren Modem Telefongebühren GPRS EUR - saftige Volumengebühr HSCSD EUR - saftige Zeitgebühr UMTS EUR - saftige Volumengebühr Serieller Port 5 0 TokenRing 0.70/m - Tabelle 4.2: Kosten einiger Netzwerke in den meisten Fällen identisch. Die Zeit der analogen Telefonnetze in Deutschland ist Mitte der 90er Jahre abgelaufen. Wenn auch die meisten Endgeräte in den Haushalten nach den Prinzipien der Telefone von vor 70 Jahren arbeiten, so findet die Gesprächsvermittlung und Übertragung im Hintergrund meistens nur noch digital statt Das klassische Telefonnetz Das klassische Telefonnetz nutzt eine Kupfer-Zweidraht-Leitung von der Vermittlungsstelle bis in die Haushalte. Diese Art Telefonsystem wird von Netzwerkern oft als plain old telephone system - POTS bezeichnet. Übertragungs- Datenrate Datenrate Reichweite Verfügbarkeit methoden Upstream Downstream in Meter in Deutschland Analoge Modems 33.6 kbps 56 kbps etliche km verfügbar IDSN 128 kbps 128 kbps etliche km verfügbar Symmetrisches DSL 2048 kbps 2048 kbps 4000 verfügbar ADSL (DMT) 768 kbps 8 Mbps 6000 verfügbar ADSL (CAP) 64 kbps 1,54 Mbps 6000 verfügbar 640 kbps 6,14 Mbps 4000 Testphase VDSL 640 kbps 13 Mbps 1500 Testphase 1,6 bis 2,3 Mbps 52 Mbps 300 Testphase Kabelmodems 768 kbps 30 Mbps je nach Kabel Testphase Tabelle 4.3: Protokolle auf 2-draht Kupferleitungen im Überblick Digitale Telefonnetze - ISDN Meistens wird ISDN für einen Zugang zum Internet verwendet; es ist für interne Vernetzungen fast nur im Bereich der WAN s (Wide Area Networks) anzutreffen. ISDN wird üblicherweise von Telefongesellschaften zur Sprachkommunikation angeboten und findet sich auch

42 32 KAPITEL 4. WAN HARDWARE im Umfeld grösserer Firmentelefonanlagen. Die Primärbandbreite beträgt 64 kbit, welches von der digitalen Sprachvermittlung herrührt. Verwendet wird PCM (Pulse Code Modulation), welche 8000 Samples von 8 bit Grösse pro Sekunde erzeugt. Oft findet man passive ISDN-Karten im Computer, die nur einen einfachen Wandler des digitalen Datenstroms der ISDN-Verbindung zum Rechnerbus vornehmen. Für den jeweiligen Adapter muss eine Treiberunterstützung im Linux-Kernel vorhanden sein, damit er benutzt werden kann. Zur Ansprache als Netzwerk-Interface stehen bei erfolgreicher Konfiguration die Point-to-Point (PPP) Interfaces ippp0 und folgende zur Verfügung. Diese können sodann mit den klassischen Netzwerktools eingerichtet und gesteuert werden Mobilfunknetze nach dem GSM-Standard GSM - der Global Standard for Mobile Communication definiert ein digitales Mobilfunknetz, was in der überwiegenden Zahl der Länder weltweit eingesetzt wird. Über dieses Telefonnetz ist es ebenfalls möglich Daten zu übertragen. Dabei gibt es zwei Ausprägungen: CSD benutzt direkt GSM-Technik und benötigt keine zusätzliche Infrastruktur. GPRS ist eine Erweiterung des GSM Standards und benötigt zusätzliche Komponenten. Inzwischen sind jedoch die meisten GSM-Netze auch GPRS-fähig GPRS Der General Packet Radio Service (GPRS) benötigt keine eigene Infrastruktur, sondern ist lediglich eine Erweiterung der bestehenden GSM-Netze. GPRS-Handys stellen für den schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt 1 ins Netz her. Für die Datenkommunikation wird es Endgeräten erlaubt mehrere GSM- Kanäle zusammenzufassen und für die Kommunikation zu reservieren. Bandbreiten in Funknetzen haben immer ein Problem: Alle Nutzer einer Zelle teilen sich ein gemeinsames Medium. Wollen alle gemeinsam zugreifen, sinkt für jeden einzelnen die erreichbare Datenrate. Üblicherweise haben Sprachverbindungen Vorrang, so dass die verfügbare Bandbreite je nach Auslastung einer GSM-Zelle unterschiedlich ausfällt. Auch können verschiedene GPRS-Geräte, wie PCMCIA, Cardbus-Adapter oder Mobiltelefone mit entsprechender Erweiterung unterschiedlich viele Kanäle gleichzeitig nutzen. In der Einführungsphase von GPRS wurde netzseitig eine Bandbreite von 53,6 kbit/s (4 Kanäle à 13,4 kbit/s) pro Funkzelle vorgesehen. Stehen alle acht Kanäle für GPRS zur Verfügung, würde die Bandbreite auf 107,2 kbit/s steigen. Weitere Steigerungen durch bessere Fehlerprotokolle erlaubten theoretische 171,2 kbit/s (8 Kanäle a 21,4 kbit/s). Handys arbeiten momentan mit 13,4 kbit/s pro Kanal. Sie können je nach Gerät zwei bis drei Kanäle zusammenfassen. Aktuelle Geräte unterstützen auch vier Kanäle und können damit auf eine Bandbreite von 53,6 kbit/s kommen. Die Angaben beziehen sich jedoch meistens nur auf den Download- Kanal. Im Upload können Mobiltelefone oft nur einen oder zwei Kanäle benutzen. Oft findet man eine Klassifizierung: So bedeutet Class 10, dass das Gerät vier Down- und zwei Upstreamkanäle nutzen kann. Class 8 deutet auf vier Down- aber nur einen Upstream hin. GPRS selbst arbeitet schon mit starker Datenkompression. Deshalb kann der Endanwender auf eine Kompression auf höheren Protokollschichten verzichten. GPRS verwendet zur Paketvermittlung gleich das Internet-Protokoll. Üblicherweise stellen die Mobilfunkanbieter ihren Datenkunden dabei eine private Netzwerkadresse zur Verfügung. Die Aushandlung der IP-Parameter übernimmt das von anderen Diensten wohlbekannte Point-to-Point-Protokoll 1 APN = Acces Point Name

43 4.3. TELEFONNETZE 33 (PPP). Jedes Datenpaket besitzt somit eine eindeutige Empfängeradresse im Funknetz, um zu dem Endgerät zu gelangen. Hierfür ist es unerheblich, über welchen der Funkkanäle es übertragen wird. Wie beim GSM auch halten alle eingebuchten GPRS-Teilnehmer permanent über Signalisierungskanäle Kontakt mit dem Netz. Der Teilnehmer ist über den Zeitraum der Einbuchung immer online. Hierfür müssen die Kanäle nicht aufgebaut sein. Die notwendigen Kanäle werden erst zugeschaltet, wenn tatsächlich Daten abgerufen werden. Die Einführung von GPRS erfolgte in Deutschland schrittweise ab dem Jahr GPRS wurde dabei technisch gesehen über das bestehende GSM-Netz gelegt. Wesentliche Teile der GSM-Infrastruktur kommen auch für das GPRS-Netz zum Einsatz HSCSD CSD (Circuit Switched Data) existiert seit Beginn der GSM-Netze. Die Nutzdatenrate beschränkte sich auf maximal 9,6 kbit/s. In der GSM-Phase-2 wurde die Geschwindigkeit der Datenübertragung auf 14,4 kbit/s erhöht, in der GSM-Phase-2+ die Bündelung mehrerer Kanäle ermöglicht. GPRS war nicht der einzige Ansatz zur Erhöhung der möglichen Datenrate. HSCSD (High Speed Circuit Switched Data), der Nachfolger von CSD, erreicht eine maximale Datentransferrate von 57,6 kbit/s. Der Unterschied zwischen den beiden Systemen liegt in den verwendeten Protokollen und der Übertragungstechnik. Wie bei einer Telefonleitung steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verfügung. Das macht sich im Abrechnungsmodell bemerkbar: HSCSD-Anbieter offerieren dem Teilnehmer einen zeitabhängigen Tarif, der unabhängig vom Datenvolumen ist. Die Zahl der gleichzeitig aktiven Teilnehmern ist nicht relevant und durch die maximale Zellkapazität beschränkt. E-Plus und Vodafone bieten in Deutschland HSCSD an. Die Preisgestaltung legt jedoch die Nutzung von GPRS für die gewohnte Internet-Nutzung nahe. HSCSD lohnt sich nur bei permanenten gleichmäßig hohen Datenraten Mobilfunknetze der dritten Generation - UMTS Hinter der Abkürzung UTMS (Universal Mobile Telecommunications System) steckt der 1998 von der ETSI (Abkürzung für European Telecommunications Standard Institute) vorgestellte Breitband-Mobilfunkstandard der dritten Generation (G3). Die Weiterentwicklung und Pflege des Standards unterliegt inzwischen dem 3GPP (3rd Generation Partnership Project). Zu den wesentlichen Leistungsmerkmale von UMTS zählt die Übertragung von Sprache und Audiodaten, die Übermittlung von multimedialen Inhalten sowie der schnelle Zugriff auf das Internet. UMTS ermöglicht Datenübertragungsraten von 364 kbit/s bis zu 2 Mbit/s, womit Streaming Video und Audio Übertragung, sowie Bildtelefonie ermöglicht werden sollen. Diese Übertragungsraten erreicht UMTS durch den asynchronen Transfermodus kurz ATM-Verfahren im sogenannten Codemultiplexverfahren. Als Funk-Technologie kommt Wideband CDMA (WCDMA) im Frequenzbereich um die 2 GHz zum Einsatz. UMTS-Hotspots existieren bereits in Ballungszentren und Großstädten. Ob eine flächendeckende Einführung stattfindet, muss abgewartet werden. Nicht mehr alle Bieter um die Lizenzen im Jahr 2000 sind am Start und die Aktivitäten der verbliebenen sind von Zurückhaltung gekennzeichnet.

44 34 KAPITEL 4. WAN HARDWARE 4.4 ISDN Meistens wird ISDN für einen Zugang zum Internet verwendet; es ist für interne Vernetzungen fast nur im Bereich der WAN s (Wide Area Networks) anzutreffen. ISDN wird üblicherweise von Telefongesellschaften zur Sprachkommunikation angeboten und findet sich auch im Umfeld grösserer Firmentelefonanlagen. Die Primärbandbreite beträgt 64 kbit, welches von der digitalen Sprachvermittlung herrührt. Verwendet wird PCM (Pulse Code Modulation), welche 8000 Samples von 8 bit Grösse pro Sekunde erzeugt. Oft findet man passive ISDN-Karten im Computer, die nur einen einfachen Wandler des digitalen Datenstroms der ISDN-Verbindung zum Rechnerbus vornehmen. Für den jeweiligen Adapter muss eine Treiberunterstützung im Linux-Kernel vorhanden sein, damit er benutzt werden kann. Zur Ansprache als Netzwerk-Interface stehen bei erfolgreicher Konfiguration die Point-to-Point (PPP) Interfaces ippp0 und folgende zur Verfügung. Diese können sodann mit den klassischen Netzwerktools eingerichtet und gesteuert werden. 4.5 Modem Ein Modem empfängt Daten von der seriellen Schnittstelle und verschickt sie über die Telefonleitung oder Zweidraht-Standleitung. Externe Modems werden zwischen serielleroder USB-Schnittstelle und Telefon geschaltet. Interne Modems (PC-Einschubkarte) besitzen eigene serielle Schnittstellen. Die Datenrate ist durch die Eigenschaften der analogen Telefonleitung beschränkt und liegt zur Zeit höchstens bei 56 kbit. Modems waren sehr lange Zeit traditionell über die serielle Schnittstelle an Computer oder entsprechende Geräte angeschlossen. Unter Linux erfolgt der Zugriff auf diese Schnittstellen über Device-Dateien vom Type Character-Device im Verzeichnis /dev. Die Schnittstellen werden dabei durchnummeriert mit ttys0 bis ttysn. Das Netzwerkinterface ist dabei nicht mit der Device-Datei gleichzusetzen, sondern hängt von der Art der Verbindung ab: Bei PPP-Verbindungen handelt es sich dann um ein Interface mit der Bezeichnung ppp0 oder folgende, welches mit den Standardwerkzeugen für Netzwerkinterfaces aufgesetzt und ausgelesen werden kann. Handelt es sich um ein USB-Modem, wird es nicht mehr über eine Device-Datei vom Typ ttysn, sondern über eine entsprechende USB-Device-Datei angesprochen. Auch hier sieht man den typischen schichtenweisen Aufbau von Protokollen: Die Geräte auf unterster Ebene können sich unterscheiden, das Netzwerk-Interface bleibt weiterhin identisch: ppp0 und entsprechende. 4.6 ADSL Die Grenzen der Übertragungskapazität der analogen Telefonleitungen sind durch das Nyquistund das Shannon-Theorem beschrieben. Das Nyquist-Theorem besagt, dass die Schrittgeschwindigkeit bei der verzerrungsfreien Übertragung von Impulsen maximal doppelt so groß sein darf wie die Bandbreite des benutzten Übertragungskanals. Das Shannon-Theorem zeigt Zusammenhänge zwischen der verfügbaren Bandbreite - dem Verhältnis zwischen Signal- und Rauschpegel - und der maximal möglichen Anzahl übertragbarer Bits pro Sekunde. Beim derzeitigen analogen Telefonnetz ist die Bandbreite auf 4 khz beschränkt und das Signal-/Rauschverhältnis liegt bei 30 bis 35 db. Daraus resultiert eine Übertragungsrate von maximal 35 kbit/s (für Modems!)

45 4.6. ADSL Designüberlegungen Allerdings ist das Erreichen der maximalen Übertragungsgeschwindigkeit von verschiedenen Faktoren abhängig: Insbesondere die Länge und der Querschnitt des Kupferkabels, sowie die Dämpfung begrenzen die theoretisch möglichen Transferraten. In der Praxis bedeutet das für Anwender, deren Hausanschluß weit von der nächsten Vermittlungsstelle entfernt liegt, Tranferraten im unteren Bereich. ADSL basiert technisch auf der Trennung des nutzbaren Frequenzspektrums in drei Kanäle. Hierbei finden zwei unterschiedliche Verfahren Verwendung: Frequency Division Multiplexing oder Echo Cancellation (EC). EC spielt jedoch eine eher untergeordnete Rolle. Grund dafür ist, dass im Gegensatz zu FDM die Kanäle für Up- und Downstream nicht komplett getrennt, sondern überlagert werden. Dies erhöht den technischen Aufwand zur Signaltrennung wesentlich und verteuert die Endgeräte. FDM hingegen erzeugt einen schmalbandigen Frequenzbereich, der direkt oberhalb der Sprachfrequenzen angesiedelt ist. Der breitbandige Downstream-Bereich schließt direkt an den Upstream-Bereich an. Frequency Division Multiplexing beziehungsweise Echo Cancellation sorgen lediglich für die Trennung des Frequenzspektrums in entsprechende Kanäle, schaffen also nur die Grundlage für den eigentlichen Datentransfer. Dieser kann wiederum durch verschiedene Übertragungsmethoden realisiert werden. Auch hier läßt die ADSL- Spezifikation - die in Händen von ANSI (American National Standards Institute) und ETSI (European Telecommunications Standards Institute) liegt - verschiedene Methoden zu. Daher kommen derzeit in der Praxis drei Modulationsverfahren zum Einsatz, die zueinander inkompatibel sind. Ähnlich wie anfangs bei der 56 k-technik kann es also dem Anwender passieren, dass eine Kommunikation trotz gleicher Basistechnologie scheitert. Im folgeden Kapitel werden verschiedene Übertragungsverfahren beschrieben Übertragungsmethoden QAM Quadrature Amplitude Modulation versetzt die Signale einfach in einen höheren Frequenzbereich versetzt. Dies wird durch Modulation eines Basisbandsignals mit einem Trägersignal erreicht, wobei die Amplitude moduliert wird. QAM ist ein sogenanntes Einträger-Bandpaßübertragungsverfahren, das ein Trägersignal mit einem Symbolstrom moduliert. Bei diesem Verfahren wird der Datenstrom in zwei einzelne Ströme mit halber Übertragungsrate aufgespaltet und anschließend mit einem Trägerpaar aufmoduliert. Bei den orthogonalen Trägern handelt es sich um eine Sinusund eine Kosinusfunktion. Der Sender beinhaltet einen Scrambler (Chiffrierer), einen Leitungskodierer, einen Sendefilter, einen Modulator und einen D/A- Wandler. Das Signal wird in einem Demultiplexer in zwei Teilsignale aufgeteilt. Diese Teilsignale durchlaufen anschließend die Leitungscodierer, die eine Bit-nach-Symbol-Kodierung ähnlich wie bei der 56 kbit-technologie vornehmen. Anschließend werden die kodierten Signale im Modulator mit einer definierten Frequenz (f0) multipliziert. Das eine Signal wird mit einem Kosinus, das andere mit einem Sinus moduliert. Anschließend erfolgt die Addition sowie eine D/A-Wandlung. Ein Sendefilter schließlich bringt das Signal auf die Leitung. Auf der Empfängerseite passiert ähnliches: Das Signal wird zunächst in einem Empfangsfilter bandbegrenzt und nach einer A/D-Wandlung mit einem Kosinus- beziehungsweise Sinusträger gleicher Frequenz wie beim Sender multipliziert. Ein nachfolgender Entzerrer macht eventuell bei der Übertragung aufgetretene Verzerrungen des Leiterpaares

46 36 KAPITEL 4. WAN HARDWARE rückgängig und filtert die Frequenzanteile (f0) heraus. Danach liegt wieder das ursprüngliche Basisbandsignal vor. Dieses wird für das jeweilige Signal getrennt dekodiert, um die Teilsignale schließlich in einem Multiplexer (zur Serialisierung der Signale) zusammenzufassen CAP (Carrierless Amplitude/Phase Modulation) Grundlage von CAP ist eine trägerlose Amplituden/ Phasenmodulation. Ein einziges Trägersignal dient als Transportmittel, das selbst weder übertragen wird, noch eigene Informationen beinhaltet. Auch CAP zählt zu den Einträger-Bandpaßübertragungsverfahren. Schon die Bezeichnung des Modulationsverfahren deutet seine Besonderheit an: Es wird eine trägerlose Amplituden/ Phasenmodulation durchgeführt, wobei ein technischer Kniff die Übertragung der Trägerfrequenz verhindert. Zusätzlicher Unterschied zu QAM: Modulation und Demodulation erfolgen beim Sender und Empfänger über digitale Filter. Die Grafik verdeutlicht die Arbeitsweise der CAP. An die Stelle der orthogonalen Trägerfunktionen von QAM treten digitale Filter, um die Teilströme zu modulieren. Das zu übertragende Signal wird einfach durch Addition der beiden Filterausgaben gebildet. Nachdem das Signal eine D/A-Wandlung erfahren hat und den Sendefilter passiert hat, wird es auf die Leitung gelegt DTM (Discrete Multi-Tone Modulation) beschreibt ein Verfahren, bei dem mehrere Trägersignale für die Übermittlung eingesetzt werden. Die übermittelten Daten verteilen sich also auf eine Vielzahl von Trägern, die alle eine Form der Quadrature Amplitude Modulation (QAM) einsetzen. DMT basiert auf der Discrete-Fast-Fourier-Transformation, die aus der digitalen Technik stammt. Im Unterschied zu CAP und QAM zählt Discrete-Multi-Tone-Modulation zu den sogenannten Mehrträger-Bandpaßübertragungsverfahren. Dieses Verfahren findet bei den Herstellern derzeit breite Unterstützung. Zur Umsetzung wird der gesamte Übertragungskanal in mehrere Teilkanäle unterteilt, die - theoretisch - die gleiche Bandbreite aufweisen. Im einfachsten Fall findet bei jedem dieser Teilkanäle das gleiche Modulationsschema Verwendung. Die Übertragungsrate ist daher identisch. Allerdings hat dies einen entscheidenden Nachteil gegenüber den zuvor beschriebenen Modulationsmethoden: Wenn Teilkanäle in hohen Frequenzbereichen liegen, so schlagen sich die schlechten Übertragungseigenschaften von Kupfer auf den Datentransfer nieder. Daher legen die Hersteller die Bitrate des jeweiligen Teilkanals entsprechend seiner Störanfälligkeit fest. Nur so ist eine optimale Nutzung des Übertragungsmediums Kupfer möglich. DMT läßt sich im Prinzip als eine Reihe von parallel arbeitenden QAM-Systemen verstehen. Dabei verwendet jedes QAM-System die zu einem DMT-Teilkanal korrespondierende Trägerfrequenz. Der Transmitter moduliert Daten, indem er Töne bestimmter Frequenzen erzeugt, diese zusammenfaßt und schließlich über die Leitung schickt Vorteile der neuen Technik Bei hinreichend kleiner Teilkanalbandbreite ist die Dämpfung für jeden einzelnen Teilkanal nahezu konstant. Ein weiterer Vorzug dieser Technik: Beim Empfänger entfällt der Entzerrer. Es reicht ein einfacher Kanalverstärker, da der Einfluß der nichtlinearen Phase des

47 4.7. ATM 37 Kabels auf das übertragene Signal in einem Teilkanal vernachlässigbar ist. Damit ist die Herstellung derartiger ADSL-Modems relativ preiswert. Allerdings setzt ein Mehrträger-Modulationsverfahren Orthogonalität zwischen den verschiedenen Teilkanälen voraus. Dies kann man beispielsweise durch die Verwendung von Fast-Fourier-Transformation-Methoden erreichen. Der Aufbau eines DMT-ADSL-Transceivers entspricht im wesentlichen dem eines CAP-ADSL-Gerätes. Wie bereits erwähnt, kann die Anzahl der Bits, die über einen Teilkanal gesendet werden, bei DMT variieren. Daraus ergibt sich eine verbesserte Performance, da störanfällige Frequenzen außen vor bleiben. Die mögliche Übertragungsrate beim Upstream-Kanal erhöht sich dabei auf 256 kbit/s Benutzung unter Linux Klassischerweise verfügen ADSL-Geräte beim Endnutzer über Ethernet- oder ATM-Schnittstellen, wobei üblicherweise nur erstere benutzt werden (können). ADSL stellt die Grundlage für das Tunneln von Ethernetframes bereit. Damit eine benutzerbasierte Authentifizierung erfolgen kann - die Ethernet selbst nicht bereitstellt - wird ein spezielles Protokoll, das PPPoE 2, eingesetzt. Linux kommuniziert auf dem unteren, dem Ethernet-Layer, klassischerweise über die eingebaute Ethernet-Netzwerkkarte. Diese sollte vom Kernel treiberseitig unterstützt sein, womit ein Netzwerk-Interface vom Typ eth0 und folgende (für weitere Netzwerkkarten) zur Verfügung steht. Darüberhinaus wird ein Software-Treiber benötigt, der das PPPoE- Protokoll zur Verfügung stellt. Als Netzwerk-Interface steht anschließend eines vom Typ ppp0 (und weitere) zur Verfügung. Damit wird über das broadcastfähige Medium Ethernet eine Punkt-zu-Punkt-Verbindung zwischen zwei Rechnern aufgebaut. 4.7 ATM Unter der Zielsetzung, die Grundlagen für eine weltweit einheitliche Netz-Architektur zu schaffen, veröffentlichte die ITU 1984 die erste Empfehlung zum Schmalband-ISDN, kurz ISDN. Nachdem als Implementierungsversuch des Breitband-ISDN (B-ISDN) zu dieser Zeit auch STM in Erwägung gezogen wurde, entschied sich die ITU 1987 für den Asynchronous Transfer Mode (ATM). Die ersten Empfehlungen hierzu wurden in den Jahren 1990/91 veröffentlicht. Neben der ITU kam es im September 1991 zur Gründung eines weiteren Gremiums, welches sich ausschließlich mit der Standardisierung von ATM befaßt, dem ATM-Forum. Gegründet von CISCO-Systems, NET/adaptive, Northern Telekom und US-Sprint, gehören dem ATM-Forum inzwischen mehrere hundert Mitglieder an. Ziel des ATM-Forums ist ein zügiges Voranbringen des Standards ATM in enger Zusammenarbeit mit der ITU und der Industrie. Bei der Normierung früherer Standards war es aufgrund des langwierigen Normierungsprozesses oft zu einem Auseinanderdriften von ITU-Norm und von der Industrie entwickelten Quasistandards gekommen. Wie auch andere Übertragungsverfahren basiert ATM grundsätzlich auf einer Paketübertragungstechnik. Hierbei sind jedoch folgende wesentliche Änderungen bzw. Ergänzungen zu bisherigen Paketvermittlungsverfahren festzuhalten: 2 PPP über Ethernet: PPP-Pakete werden als Ethernetframes geschickt, welche selbst wiederum über den ADSL-Layer laufen. Damit erfolgt in den beiden unteren Schichten des OSI-Modells nochmals eine Untergliederung.

48 38 KAPITEL 4. WAN HARDWARE Feste Paketlänge: ATM nutzt zur Übertragung ausschließlich Pakete mit einer festen Länge von 53 Bytes. Diese kleinste unteilbare Übertragungseinheit wird daher ATM- Zelle genannt. Qualitätsparameter der Verbindung: ATM unterstützt QoS. Die hierzu notwendigen Parameter und Betriebsmittel werden beim Aufbau einer Verbindung festgelegt bzw. zugewiesen. Verbindungsorientierte Betriebsweise: ATM agiert grundsätzlich verbindungsorientiert. Die Umsetzung verbindungsloser Dienste höherer Schichten ist vorgesehen. Verzicht auf eine abschnittsweise Fehlersicherung: Die sehr geringen Bitfehlerwahrscheinlichkeiten heutiger Lichtwellenleiter ermöglichen den Verzicht auf eine abschnittsweise Fehlersicherung zugunsten einer höheren Übertragungsrate. Verzicht auf eine abschnittsweise Flußsteuerung: Aufgrund der hohen Übertragungsund Verarbeitungsgeschwindigkeiten ist eine abschnittsweise Flußsteuerung nicht möglich. Außenband-Signalisierung: Wie im Schmalband-ISDN wird die Signalisierung durch Nutzung separater Signalisierungskanäle vom Nutzdatenstrom entkoppelt Die ATM-Zelle Die ATM-Zelle ist eine starre Einheit von 53 Bytes. Sie besteht aus einen 5Bytes langen Header sowie 48 Bytes Nutzinformation (Payload). Es wird zwischen zwei Arten von ATM-Zellen unterschieden, die sich in der Belegung der Bits 5-8 des ersten Headerbytes unterscheiden: Bit Flow Control (GFC) Channel Identifier Channel Identifier (VCI) Path Identifier (VPI) Path Identifier PT CLP HEADER CHECKSUM (CRC) Header einer User Network Interface Zelle Abbildung 4.1: User-Network-Interface Zelle UNI-Zellen Die User-Network-Interface-Zellen dienen zur Kommunikation zwischen Nutzer- und Benutzer-Netzwerk-Schnittstelle (User-Network-Interface, UNI). Der Header der UNI-Zelle unterteilt sich in sechs Elemente, die in der Abbildung dargestellt sind. Das Feld GFC (Generic Flow Control) dient der direkten Zugriffssteuerung auf ein Übertragungsmedium. Es ist daher nur im Bereich lokaler ATM-Netze von Relevanz und wird von ATM- Vermittlungsstellen und Cross-Connects am NNI-Interface überschrieben. Eine Standardisierung zur Nutzung des GFC Feldes steht bislang aus.

49 4.7. ATM 39 Zur Adressierung stehen die Felder VPI (Virtual Path Identifier) und VCI (Virtual Channel Identifier) zur Verfügung. Sie werden im Abschnitt weiter betrachtet. Anhand des Feldes PT (Payload Type) wird zwischen Benutzerzellen und OAM-Zellen (Operation and Maintenance) unterschieden. Der Standardwert ist 000. Die Funktion der OAM-Zellen liegt in der Überwachung des Systems. Sie ermöglichen die Aufdeckung und Behebung von Fehlfunktionen auf allen ATM-Ebenen. PT-Feld Bedeutung 000 Benutzerzelle, keine Überlast festgestellt, SDU-Type=0 001 Benutzerzelle, keine Überlast festgestellt, SDU-Type=1 010 Benutzerzelle, Überlast festgestellt, SDU-Type=0 011 Benutzerzelle, Überlast festgestellt, SDU-Type=1 100 Segment-OAM-F5-Zelle 101 End-to-End-OAM-F5-Zelle 110 Reserviert für zukünftiges Lastmanagement 111 Reserviert für zukünftigen Gebrauch Tabelle 4.4: Mögliche Nutzlasttypen von ATM Das Feld CLP (Cell Loss Priority) definiert die Priorität einer Zelle. Bei auftretender Überlast an Netzwerkschnittstellen werden Zellen mit niedriger Priorität (CLP=1) zuerst verworfen. Eine Priorisierung bzw. Markierung von Zellen erfolgt, wenn die sie erzeugende Anwendung Resourcen in höherem Maße belegt, als ihr zugeordnet wurde. Verworfen werden also erst die Zellen, die außerhalb ihrer QoS-Parameter generiert wurden, bzw. Zellen deren Priorität bereits bei ihrer Generierung auf 1 gesetzt wurde. Die letzten 8 Bits werden durch das Feld CRC (Cyclic Redundancy Checksum) belegt. Bei der Bildung der Prüfsumme werden dabei nur die 32 Bits des Zellheaders (ohne CRC- Feld) berücksichtigt. Die Bildung einer Headerprüfsumme ist sinnvoll, da sich die Informationen des Headers an jedem NNI, den die Zelle passiert, ändern kann, die Nutzinformation jedoch erhalten bleibt. NNI-Zellen Die Network-Node-Interface-Zellen werden entsprechend zur Kommunikation zwischen den einzelnen Knoten des ATM-Netzwerks genutzt (Network-Node-Interface, NNI) Bit Channel Identifier (VCI) Channel Identifier Path Identifier Path Identifier (VPI) Path Identifier PT CLP HEADER CHECKSUM (CRC) Header einer Network Node Interface Zelle Abbildung 4.2: Network-Node-Interface Zelle

50 40 KAPITEL 4. WAN HARDWARE Im Vergleich mit dem UNI-Header ist das VPI-Feld des NNI-Headers um 4 Bit verlängert. Dies trägt der pfadorientierten Wegelenkung (Routing) in ATM-Weitverkehrsnetzen Rechnung, sowie der Tatsache, daß hier eine direkte Zugriffskontrolle auf das Übertragungsmedium nicht benötigt wird. 4.8 FDDI Für Backboneverbindungen in grossen LAN s kam bis zum Ende der 90er Jahre üblicherweise FDDI (Fiber Distributed Data Interface) zum Einsatz. FDDI erlaubt maximale Kabellängen von bis zu 200km, die maximale Geschwindigkeit von 100 Mbit ist jedoch der Grund, weshalb FDDI nicht mehr eingesetzt wird. FDDI verwendet einen anderen Ansatz bei der Datenübertragung, bei dem eine Reihe sogenannter Tokens ausgesandt werden. Eine Station darf nur dann ein Paket übertragen, wenn sie eines dieser Tokens auffangen konnte. Somit entfällt wie bei TokenRing das Problem der Paketkollisionen. 4.9 Mobilfunknetze Das Interesse an Internet überall hat mit der Vielzahl mobiler Endgeräte deutlich zugenommen. Laptops und PDAs sind keine Seltenheit mehr, sondern inzwischen die Grundausstattung der verschiedenen Datennomaden. Die Nahfunktechniken nach dem Standard beherrschen dabei das Feld. Daher sind die meisten Geräte dafür schon werksseitig mit einem entsprechenden Netzwerkadapter ausgestattet. Diese schöne neue Welt dieser Netze weist jedoch noch gravierende Löcher in der Abdeckung auf, so dass schnell nicht mehr von einem wirklich mobilen Internetzugang gesprochen werden kann. Es gibt zwar eine wachsende Zahl von Hotspots, leider jedoch auch eine wachsende Anzahl durchaus unterschiedlicher Zugangsprocederes. Wenn auch an vielen Stellen noch offene WLANs zu finden sind, so ist die Benutzung eines solchen Zugangs ohne Einverständnis des Betreibers nicht unbedingt legal. Obwohl schon seit einigen Jahren am Start erhielten die Datendienste über die Mobilfunknetze erst mit der Einführung von UMTS wieder größere Aufmerksamkeit. Mobilfunknetze decken zu fast 100% das Land ab und erlauben damit fast überall und jederzeit online zu gehen GSM, HSCSD, GPRS und UMTS Es gibt inzwischen eine ganze Reihe von Methoden Daten in Mobilfunknetzen zu transportieren. GPRS (General Packet Radio Service ist sicherlich das inzwischen verbreiteste Verfahren und wird von allen Mobilfunkbetreibern fast überall angeboten. Es arbeitet mit zeitunabhängigen Volumentarifen. GPRS kommt nicht nur beim Internet-Zugriff via PC zum Einsatz, sondern versendet auch MMS (Multimedia Message und wird zum Transport von WAP-Inhalten eingesetzt. Darüberhinaus gibt es HSCSD. Dieses belegt für die Online-Zeit einen GSM-Mobilfunkkanal und wird daher zeitbezogen abgerechnet. HSCSD ist bei weitem nicht so verbreitet wie inzwischen GPRS. Die Zukunft liegt sicherlich erstmal in UMTS. Wenn auch die Anbieter immer noch nach einer Killerapplikation suchen, um von den Kunden das Geld für die Lizenz wieder einzusammeln, so ist jetzt schon für den Internet-Zugriff eine ernstzunehmende Alternative. Die erreichbaren Geschwindigkeiten, so eine Zelle verfügbar und

51 4.10. NETZWERKADAPTER FÜR MOBILFUNKNETZE 41 nicht ausgelastet ist, liegen bei 384 kbit/s. Das ist deutlich mehr als die ca. 55 kbit/s mittels GPRS oder HSCSD. Da UMTS bei weitem nicht die Abdeckung von GSM erreicht, ist ein Fallback auf GPRS vorgesehen. Daraus resultieren oft identische Volumentarife für GPRS und UMTS. Die entsprechenden Netzwerkadapter für UMTS beherrschen daher beide Übertragungsverfahren Netzwerkadapter für Mobilfunknetze Wie für jedes andere Netzwerk auch, benötigt man einen passenden Netzwerkadapter. Der Adapter für Mobilfunknetze kommt üblicherweise als PCMCIA- oder Cardbus-Karte daher. Alle neueren Mobiltelefone bringen GPRS-Unterstützung mit und kommen ebenfalls als Zugangshardware in Frage. Vielfach wird dieser Adapter auch als Modem bezeichnet, da es sich um einen Netzwerkzugang per Telefonnetz handelt. Das Mobilfunknetz arbeitet jedoch von sich aus schon digital. Deshalb ist eine (De)Modulation gar nicht mehr nötig. Trotzdem findet man einige Anleihen aus der Modem-Welt wieder. Die meisten Mobiltelefone unterstützen GPRS. Eine gewisse Schwierigkeit stellt die Verbindung zwischen Rechner und Handy dar. Hier gibt es je nach Ausstattung der Geräte drei Möglichkeiten. Die Verbindung mittels Bluetooth ist sicherlich die modernste Variante. Hierzu müssen selbstredend beide Seiten mit dieser Art des Drahtlosfunks ausgestattet sein. Das Fehlen an Laptop oder PC ist kein Problem, da man Bluetooth per USB-Dongle oder PCMCIA-Steckkarte nachrüsten kann. Die drahtlose Verbindung zwischen den Geräten hat den Vorteil, dass sich das Telefon für optimalen Empfang leicht positionieren lässt. Jedoch sorgt Bluetooth gerade auf der Seite des Mobiltelefons dafür, dass sich dessen Akkulaufzeit oft deutlich reduziert. Ebenfalls sollte man die Datensicherheit im Blick. Unter Umständen ist ein Mobiltelefon in einem weiten Umkreis sichtbar. Wenn dann auch noch die Firmware einige gravierende Sicherheitslücken aufweist, eröffnet man anderen vielleicht tiefere Einblicke in das Telefon als einem lieb ist. Unter Sicherheitsaspekten deutlich unproblematischer ist eine Verbindung mit optischem Drahtlos-Funk. Viele Mobiltelefone, eine große Zahl von tragbaren Computern und PDAs haben Infrarot eingebaut. Die Reichweite von IrDA ist mit üblicherweise einem halben Meter beschränkt. Ein weiterer Vorteil: Steckt das Mobiltelefon irgendwo in der Tasche, ist es für andere per IrDA nicht mehr sichtbar. Die Ausrichtung der beiden kommunizierenden Geräte zueinander ist nun entscheidend: Viel mehr als 30 Grad von der Hauptstrahlrichtung sollte der Winkel nicht betragen. Unter Energie- und Sicherheitsgesichtspunkten schneidet sicherlich die drahtgebundene Verbindung zwischen Mobiltelefon und Rechner ab. Ältere Mobiltelefone beherrschen nur die serielle, neuere Geräte auch USB-Verbindungen. Die entsprechenden PC-Gegenstücke sind eigentlich immer vorhanden. Leider gibt es jedoch kaum Telefone bei denen das Kabel schon beiliegt.

52 42 KAPITEL 4. WAN HARDWARE

53 Kapitel 5 TCP-IP 5.1 Schaffung von Inter-Nets In den bisherigen Abschnitten erfolgte die Einführung in das Thema Netzwerke, in die Konzepte der paketorientierten Datenübertragung, der Signalisierung und der Kodierung. Als Protokolle der Hardwareebene wurden Ethernet und sehr kurz aus historischen Gründen TokenRing besprochen. Diese Netzwerkhardware wird überlicherweise für Local Area Networks verwendet, da die überbrückbaren Entfernungen nur wenige einhundert Meter und mit optischen Medien nur wenige Kilometer betragen. ATM over ADSL Internet Ethernet 1000Base-X ATM over ADSL # /22 #3 Ethernet a 10Base-T #2 #1 Router 2 Ethernet 100Base-T /24 #2 Router n TokenRing / /24 Router 1 #2 #1 FDDI Router /24 Abbildung 5.1: IP als Universalservice Für Weitverkehrsnetze greift man auf überall verbreitete Telefonnetze in ihrer analogen oder digitalen Ausprägung zurück. Dann kommt entweder ein Modem oder ein ISDN- Adapter als Netzwerkanschluss zum Einsatz. Auf diese Weise lassen sich verschiedene Hardwareausprägungen für die Paketübertragung nutzen. Jedoch besteht dadurch auch ein Problem: Ethernet ist zwar für fast alle Medientypen implementiert 1 aber z.b. nicht für Zwei- Draht-Verbindungen für weite Entfernungen. Die WAN-Techniken, wie z.b. ISDN und analoges Modem eignen sich kaum für die Vernetzung vieler Maschinen bzw. Komponenten. ISDN und Modem können weite Entfernungen realisieren, bieten aber nur Punkt-zu- Punkt-Verbindungen zwischen jeweils zwei dedizierten Interfaces 2. Verschiedene physikali- 1 Es existieren jeweils Standards für Koaxialkabel (10Base5 ThickEthernet/Yellow-Cable bzw. 10Base2 für Cheapternet), TwistedPair-Kabel (4bzw. 8adrig), Lichtwellenleiter, Funkwellen im 2.4 GHz-Bereich 2 In den typischen Einwahlsituationen von Internet-Providern handelt es sich dabei um spezielle Hardware, welche eine große Anzahl von Netzwerkinterfaces in einer Maschine vereint. 43

54 44 KAPITEL 5. TCP-IP sche Netze sind unumgänglich, da keine Technologie sich für alle Einsatzszenarios eignet. Weiterhin sind Trennungen an bestimmten Grenzen, wie abgeschlossene Firmen- oder Abteilungsnetze durchaus gewünscht und aus Sicherheitsgründen notwendig. Deshalb wird ein Universaldienst geschaffen, welcher Verbindungen zwischen beliebigen Rechnern erlaubt. Dabei soll die Kommunikation über unterschiedliche Entfernungen, durch unterschiedliche Netze (LAN oder WAN) und über verschiedene Medien realisierbar sein. Virtuell soll jede Verbindung für die kommunizierenden Maschinen gleich aussehen, d.h. es sollen keine anderen Applikationen oder Protokolle in Abhängigkeit davon verwendet werden müssen, ob sich die Maschinen im gleichen LAN befinden oder über Kontinente hinweg Daten austauschen. Dabei soll keine Entscheidung für eine bestimmte Technologie 3 getroffen werden, sondern ein Universalnetz über mehrere heterogene Netze hinweg geschaffen werden. Ein solcher Universaldienst wird als Inter-Net bezeichnet. 5.2 Überblick über TCP/IP Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In den nun folgenden Abschnitten soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen TCP und IP der Netzarchitektur beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI- Referenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI-Standardisierung eingeflossen. Als Ziele der Architektur wurden bei der Entwicklung definiert: Unabhängigkeit von der Architektur der Hostrechner. Universelle Verbindungsmöglichkeiten im gesamten Netzwerk. Ende-zu-Ende-Quittungen. Standardisierte Anwendungsprotokolle. Unabhängigkeit von der verwendeten Netzwerk-Technologie. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nur vier Schichten: Application Layer, Transport Layer, Internet Layer, Network Layer. Applikationssschicht (application layer): Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfaßt alle höherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen SSH (für virtuelle Terminals), FTP (Dateitransfer), SMTP (zur Übertragung von ), DNS (Domain Name Service), HTTP (Hypertext Transfer Protocol) etc. Transportschicht (transport layer): Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll, durch das ein Bytestrom fehlerfrei zu einem anderen Rechner im 3 Netzwerkhardware mit bestimmten darauf laufenden hardwarenahen Protokollen

55 5.2. ÜBERBLICK ÜBER TCP/IP 45 Internet übermittelt werden kann. UDP ist ein unzuverlässiges verbindungsloses Protokoll, das vorwiegend für Abfragen und Anwendungen in Client/Server- Umgebungen verwendet wird, in denen es in erster Linie nicht um eine sehr genaue, sondern schnelle Datenübermittlung geht (z.b. Übertragung von Sprache und Bildsignalen). Diese Protokolle werden gleich noch ausführlicher behandelt. Internetschicht (internet layer): Die Internetschicht im TCP/IP-Modell definiert nur ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das Internet Protocol. Netzwerkschicht (network layer): Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt auf dieser Ebene nicht viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, daß zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muß. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.b. Ethernet (IEEE 802.3), PPP, etc. SSH FTP HTTP DNS DHCP Application Layer Transmission Control P. (TCP) User Datagram Protocol (UDP) Transport Layer Internet Protocol (IP) ICMP / ARP Internet Layer Ethernet ATM FDDI Modem ISDN Network Layer Abbildung 5.2: Der TCP/IP-Protokoll-Stapel Um Datenpakete im großen Umfang und möglichst schnell an verschiedenste Empfänger schicken zu können, muß das Format der Adressen besonders gut von Computern oder speziellen elektronischen Schaltkreisen zu verarbeiten sein. Daher steckt das Konzept zur Verarbeitung der IP-Adressen im Binärformat (denn Host- und Domänennamen zu analysieren kostete zuviel Zeit!) Maschinen-intern entsprechen dem üblichen, dezimalen Format der IP- Adressen (a.b.c.d) pro Zahl 8-bits. IP-Adressen sind also insgesamt 32-bit lang, wobei die Unterteilung in 8 bit Blöcke nur der Lesbarkeit halber eingeführt wurde. Dieses Format wird auch Dotted Quad Notation genannt: entspricht In dieser simplen Form kann die Adresse von sehr primitiven und enorm schnellen Logik- Bausteinen analysiert werden und sehr schnell mit Netzmasken und Broadcastadressen zum Routing berechnet werden.

56 46 KAPITEL 5. TCP-IP 5.3 Design Für das Verständnis und die Behandlung des Internet-Protokolls sind einige Vereinbarungen sinnvoll: Ein Host(-rechner): Meint ein beliebiges Computersystem, das an ein Internet angeschlossen ist und auf dem Anwendungen laufen. Dabei spielt die Rechnerhardware, Typ und Geschwindigkeit des Netzwerkes keine Rolle. Alle Hosts können ungeachtet der Hardwareunterschiede (und Betriebssysteme) miteinander kommunizieren. Ein Router ist ein Host mit mehrern Interfaces. Eine (global) einheitliche Adressierung eines Hosts muss sichergestellt sein, damit ein übergreifendes Inter-Net sinnvoll funktionieren kann. Das Internet-Protokoll (IP) ist Abstraktion der Konzepte seiner Entwickler. Es ist unabhängig von einer speziellen physikalischen Hardware angelegt. Die Implementierung findet ausschliesslich in Software statt. Damit kann es Bestandteil des Betriebssystems eines Rechners werden oder als eigenständige Applikation, die unter einem Betriebssystem ausgeführt wird, laufen. Das Adressierungsschema bildet dabei die zentrale Komponente der Abstraktion. Zum einen können die physikalischen Adressen nicht ausreichen, 4 zum anderen können sie sehr unterschiedliche Schemata 5 verwenden. Die Zustellung von IP-Paketen erfolgt analog zur Zustellung von Frames auf Hardwareebene. Die Adressierung der virtuellen Ebene läßt sich gut mit der physikalischen Adressierung vergleichen. Der Host trägt die Zieladresse in den Header 6 des zu verschickenden Datenpaketes ein und vermerkt seine eigene Adresse als Absenderkennung. Das Zielsystem, welches durchaus ein Zwischenziel in Form eines Routers auf dem Weg eines Datenpaketes sein kann, überprüft die Adresse auf Übereinstimmung mit der eigenen. Anhand dieser wird das Paket behandelt: Im Falle eines Routers erfolgt die Weiterleitung in ein angeschlossenes Netz, soweit ein geeignetes vorhanden ist. Erreicht das Paket den adressierten Host, kann dieser die Absendeadresse als Ziel für das Verschicken einer Antwort verwenden. An jeder Stelle auf dem Weg eines Paketes ist die entsprechende Protokollsoftware mit der Zustellung beschäftigt. 5.4 Internet Protocol (IP) Netzwerke sollen unabhängig von der verwendeten Hardware ein einheitliches Adressschema verwenden. Die Beschränkung auf Ethernet verbietet sich allein schon wegen der begrenzten Kabellängen im LAN. Der Hauptvorteil von IP besteht also darin, daß es physikalisch verschiedene Netzwerke zu einem scheinbar homogenen Netzwerk zusammenfaßt. Die Zusammenarbeit verschiedener Netze wird als Internetworking bezeichnet, die Kommunikation verläuft über das Internet-Protokoll (IP). Es gibt nicht DAS Internet, sondern das Internet ist eine Sammlung von Teilnetzen, die miteinander verbunden sind. Es gibt keine echte Struktur des Netzes, sondern mehrere größere Backbones, die quasi das Rückgrat (wie der Name Backbone ja schon sagt) des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher Bandbreite und schnellen Routern gebildet. An die Backbones sind wiederum größere regionale Netze an- 4 Obwohl das MAC-Adressierungsschema des Ethernets z.b. mit 2 48 mehr Adressen umfaßt als das Internet-Protokoll der Version 4. Hier besteht jedoch die Schwierigkeit, dass die Adressen fest mit einem Netzwerkadapter verknüpft sind, d.h. eine beliebige Abstraktion nicht möglich ist. 5 Die Zuordnung von Modem- oder ISDN-Leitungen könnte z.b. anhand der Telefonnummer erfolgen, TokenRing und Ethernet verwenden MAC-Adressen. 6 speziell gekennzeichneter Kopf eines Datenpaketes, welcher keine Nutzdaten enhält, sondern Zustellvermerke speichert

57 5.4. INTERNET PROTOCOL (IP) 47 geschlossen, die LANs von Universitäten, Behörden, Unternehmen und Service-Providern verbinden. IP stellt die Basisdienste für die Übermittlung von Daten in TCP/IP-Netzen bereit. Hauptaufgaben des Internet Protokolls sind die Adressierung von Hosts und das Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemühen ( best effort ) von der Quelle zum Ziel befördert, unabhängig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enthält keine Funktionen für die Ende-zu-Ende-Sicherung oder für die Flußkontrolle. Das Internet-Protokoll muss eine Reihe von Aufgaben erfüllen, um eine End-zu-End- Zustellung von Datenpaketen zu gewährleisten. Dazu zählt die Definition von Datagrammen, welche die Basiseinheiten zur Datenübermittlung in Internets bilden. Weiterhin wird das bereits angesprochene Adressierungsschema benötigt. Eine weitere Aufgabe besteht in der Übermittlung der Daten von der Transportschicht zur Netzwerkschicht. 7 Die Datagramme müssen geeignet durch das Netz geschleust werden, dieser Vorgang wird als Routing bezeichnet. Da auf diesem Wege durchaus unterschiedliche Arten von Netzwerkhardware passiert werden kann, muss die optimale Framegröße nicht unbedingt auf allen Teilstrecken identisch sein. Da die Framegröße nur anhand der Daten des ersten Teilnetzes, in dem der sendende Host Mitglied ist, bestimmt wird, müssen Mechanismen zur Verfügung stehen, mit eventuell kleiner werdenden Frame-Größen umzugehen. Daher erlaubt das IP die Fragmentierung der Datagramme auf ihrem Weg durch das Netz und das Zusammensetzen von diesen auf der Zielmaschine. Die Funktionen von IP umfassen: Die Definition von Datagrammen, welche die Basiseinheiten für die Übermittlung von Daten im Internet bilden. Definition des Adressierungsschemas. Übermittlung der Daten von der Transportebene zur Netzwerkschicht. Routing von Datagrammen durch das Netz. Fagmentierung und Zusammensetzen von Datagrammen. IP benötigt deshalb ein hardwareunabhängiges Adressierungsschema; jedem Host (teilnehmender Rechner im Internet wird eine eindeutige 32-Bit-Zahl zugewiesen, die sogenannte IP-Adresse. Die Dargestellung von IP-Adressen erfolgt üblicherweise durch vier Dezimalzahlen, eine für jeden 8-Bit-Anteil, die durch Punkte voneinander getrennt sind. IP ist ein verbindungsloses Protokoll, d.h. zur Datenübertragung wird keine Ende-zu- Ende-Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein unzuverlässiges Protokoll, da es über keine Mechanismen zur Fehlererkennung und -behebung verfügt. Unzuverlässig bedeutet aber keinesfalls, daß man sich auf das IP Protokoll nicht verlassen kann. Unzuverlässig bedeutet in diesem Zusammenhang lediglich, daß IP die Zustellung der Daten nicht garantieren kann. Sind die Daten aber beim Zielhost angelangt, sind diese Daten auch korrekt. 7 Das zugehörige OSI-Schichtenmodell ist Thema eines eigenen Kapitels

58 48 KAPITEL 5. TCP-IP 5.5 Spezifikation IPv4-Standard Mit den erfolgten Designüberlegungen und definierten Aufgaben des Internet-Protokolls sind die wesentlichen Grundlagen gelegt. Nun kann die Spezifikation, d.h. die Festlegung einzuhaltender Standards, des Protokolls erfolgen. Wie schon mehrfach implizit erwähnt wurde, ist IP ein paketorientiertes Protokoll. Die IP-Adresse ist eine 32 bit große Binärzahl, die jedem Host in einem Internet zugewiesen wird und für die gesamte Kommunikation mit jedem anderen Host in diesem Internet verwendet wird. Dabei wird die Adresse virtuell in zwei Teile aufgespalten in ein Präfix und ein Suffix, wobei die Aufteilung nicht statisch ist. Das Präfix einer IP-Adresse identifiziert das Netz, in welchem sich der jeweilige Host mit seiner Adresse befindet. Das Adress-Suffix identifiziert den Host in dem durch das Präfix bestimmten Netz. Jedes Netz verfügt damit über eine eindeutige Kennung, die Netznummer. Jede Netznummer bzw. Network Number tritt nur einmal auf. Suffixes können in jedem Netz, dh. mehrfach, verwendet werden. Durch diese Festlegung soll das Routing effizient gestaltet werden können. Durch diese Festlegungen wird das wesentliches Designprinzip beschrieben: Jeder Host erhält eine einheitliche Adresse, diese Adresse kann jeweils nur von einer Maschine verwendet werden. Es erfolgt eine globale Koordination bei der Zuteilung von Netznummern, jedoch eine lokale Verteilung der Suffixes in den jeweiligen Teilnetzen. Es wird eine Delegationshierarchie geschaffen, die eine leichte Einordnung von Computern ermöglicht: Verschiedene Präfixes bedeutet verschiedene Netze; Gleiches Präfix heisst gleiches Netz. Das erzwingt dann verschiedene Suffixes. Das Internet Control Message Protocol (ICMP) ist eine Erweiterung des IP und wird dazu verwendet, um Fehlermeldungen und ähnliches an andere Hosts weiterzugeben bzw. die Erreichbarkeit von Hosts zu überprüfen. Neben der Erreichbarkeit von Rechnern gibt es eine weitere Funktion für die Weitergabe bestimmter Routinginformationen, die Redirect Messages. Diese wird vom Routing-Modul erzeugt, wenn es erkennt, daß es von einem anderen Host als Gateway verwendet wird, obwohl es einen wesentlich kürzeren Weg gibt. Weil dieses aber stark in die Funktionen des Hosts eingreift, ist das Ganze mit Vorsicht zu geniessen. In einigen Fällen wird ICMP komplett abgeschaltet. Ein weiteres Hilfprotokoll stellt das Address Resolution Protocol dar. Es dient der Zuordnung von Hardwareadressen zu IP-Nummern. Beide Protokolle werden später in eigenen Abschnitten behandelt Notation Für die Protokollsoftware ist die Binärdarstellung entscheidend, nur in dieser kann eine effiziente Analyse der Adressen erfolgen. Jedoch besitzt diese auch Nachteile: Für Menschen, die diese Adressen in ihren Applikationen verwenden, ist die Binärnotation schwer lesbar und Verwechselungen leicht möglich. Deshalb führt man die sogenannte Dotted-Quad-Notation ein. Die IP-Adresse wird in vier Byte-Blöcke aufgeteilt, z.b Die Punkt- Dezimal-Notierung liefert dann eine für das menschliche Auge leicht erfassbare, Darstellung. Im Beispiel bleibend schreibt sich die genannte IP-Adresse nun: Jeder Block besteht dabei aus einem vorzeichenlosen Ganzzahlwert im Bereich

59 5.5. SPEZIFIKATION Adressbereiche Der gesamte IP-Adressbereich erstreckt sich damit von Adresse bis In der Binärdarstellung bedeutet dieses die Spannbreite von allen 32 Stellen Null gesetzt bis zu allen Stellen Eins gesetzt. Die zuteilende Stelle für IP-Adressen bzw. -Bereiche muss für jeden Adressanteil die Zahl der Bits festlegen, welche für das Präfix bzw. das Suffix reserviert werden. 8 bits 8 bits 8 bits 8 bits Class A 0 network host host host B 1 0 net work network host host C net work network network host D multicast multicast multicast E experi mental experi mental experi mental Abbildung 5.3: Adressbereiche des IPv4 Die Zuordnung von einer größeren Zahl von Bits in einem Bereich bedeutet automatisch die Verfügbarkeit von weniger Bits im anderen Teil. D.h. die Verlängerung des Präfixes liefert mehr definierbare Netznummern, aber weniger Hosts im jeweiligen Netz. Die Vergrößerung der Zahl der Hosts pro Netz geht zulasten der definierbaren Anzahl von Netzen. Eine übergreifend einheitliche Festlegung ist jedoch kaum sinnvoll, da sehr unterschiedliche Netze und Anforderungen existieren. Das Internet-Protokoll ist aus Sicht der Computer- und Netzwerkevolution ein recht altes Protokoll, d.h. nicht alle Entwicklungen konnten vorausgesehen werden. Der ursprünglich festgelegte Adressraum erschien gross genug um alle damaligen Anforderungen abdecken zu können 8. Weiterhin sollten IP-Adressen selbstbezeichnend sein, d.h. ohne weitere Angaben sollte die Netzgröße, d.h. die Anzahl maximal enthaltener Hosts als Information bereits beinhaltet sein. Die frühe IP-Software interpretierte zur Ermittlung einer Adressklasse, die Einteilungsvorschrift des IP-Adressraumes, die ersten vier Bits. Diese wurden in einer Tabelle zur schnelleren Bearbeitung verwaltet. Mit dieser Festlegung wurde eine Aufteilung des gesamten Adressraumes getroffen: Die Aufteilung geschieht über die Internet Assigned Number Authority (IANA). 8 Es gab bei der Entwicklung von IP nur eine winzige Anzahl zu vernetzender Rechner und man schätzte die Weiterentwicklung bei weitem nicht so stürmisch ein, wie sie später erfolgen sollte.

60 50 KAPITEL 5. TCP-IP Bezeichnung Präfix Suffix Netze Hosts pro Netz Class A 7 bit 24 bit Class B 14 bit 16 bit Class C 21 bit 8 bit Tabelle 5.1: Aufteilung der IP-Adressklassen Spezielle IP-Adressen Besondere Adressierungen sollen im gemeinsamen Adressraum abgebildet werden. Deshalb wurde eine Reihe von Spezialadressen definiert. Dazu zählen die Netzwerkadressen: Um den Netzen einen Namen zu geben, d.h. um sie direkt ansprechen zu können, erhalten diese Adressen im Prefix die Netzwerk-Nummer und im Suffix Nullen. Für den direkter Broadcast, d.h. um alle Rechner in einem gemeinsamen physikalischen Netz eine Nachricht schicken zu können, wird das Netzwerkprefix verwendet und im Suffix binäre Einsen eingetragen. Der limitierte Broadcast erlaubt es, allen Rechnern im physikalischen Netz (in dem sich die Maschine gerade befindet) eine Nachricht zu schicken. Im Netzwerkprefix und im Suffix werden ausschließlich Einsen eingetragen. This Computer stellt auch eine spezielle Anforderung dar: Wenn ein Rechner bootet und dynamisch eine IP-Adresse erhalten soll, benötigt er eine Adresse zur IP-Kommunikation: Im Präfix und Suffix ausschließlich Nullen. Diese Situation tritt z.b. bei festplattenlosen Maschinen auf, die keine Möglichkeit haben, die Adresse irgendwo abzulegen. Dieses gilt auch für mobile Maschinen, die zwischen verschiedenen Netzen wechseln. Die Loopback Address bietet eine auf jeder Maschine einheitliche Adresse. Viele Programme verwenden zur Kommunikation TCP/IP, selbst wenn die Maschine nicht an ein Netzwerk angeschlossen ist. Zur schnellen IP-Kommunikation innerhalb der Maschine ist als höchstes das Class-A Netzwerk 9 definiert. Dieses erscheint aus heutiger Sicht durchaus als Verschwendung, da in einem solchen Netz mehrere Millionen Rechner Platz finden. Router erhalten auch IP-Adressen obwohl sie selten Applikationen zur Host-zu-Host- Kommunikation ausführen. Sie haben Verbindung in verschiedene physikalische Netze und müssen in jedem dieser Netze adressierbar sein. Jede dieser IP-Adressen eines Routers bezeichnet mit ihrem Prefix das physikalische Netz. Dabei wird folgendes Prinzip angewandt: IP-Adressen bezeichnen nicht direkt den Host, sondern die Verbindung eines Rechners zu einem Netzwerk. Zur Abgrenzung von Routern bezeichnet man Rechner mit mehreren IP-Adressen ohne Routingfunktionalität als Multi-Homed-Hosts. Beim Routing spielen einige IP-Adressen mit besonderer Bedeutung eine Rolle, die im folgenden kurz vorgestellt: Netzwerkadresse ist definiert durch ein Präfix. Der Teil, welcher den einzelnen Host bezeichnet, wird mit Nullen am Ende aufgefüllt. So beschreibt die spezielle IP-Nummer, z.b ein Klasse-C-Netzwerk mit max. 254 Teilnehmern. Broadcastadresse für einen direkten Broadcast, d.h. ein Datenpaket an alle Teilnehmer eines Teilnetzes, besteht aus dem Präfix mit Einsen am Ende, die den Hostteil auffüllen. Im o.g. Beispiel wäre dieses die spezielle IP-Nummer

61 5.5. SPEZIFIKATION 51 Defaultrouter heißt der Standardübergang zu anderen Netzen. Dieses ist eine Maschine, die den Weg zum restlichen Internet kennt. Der Defaultrouter ist eine Konvention, damit nicht jeder Router im Netz alle Routen zu allen existierenden Netzwerken listen und verarbeiten muss. Diese Maschine muss aber zwingend Mitglied im jeweilgen Teilnetz sein. Im Beispielnetz könnte dieses z.b. die IP-Adresse sein. Dieses ist im Gegensatz zu Netzwerkadresse und Broadcastadresse nicht standardisiert. Netzwerkmaske wird durch die spezielle IP-Adresse beschrieben, welche mit binären Einsen beginnt und mit binären Nullen endet. Der Übergang bezeichnet die Grenze zwischen Prä- und Suffix und sollte eindeutig sein. Für das Beispielnetz lautet diese und ist damit Netzmaske eines Klasse C-Netzes. Binär lautet sie: Eine Netzwerkmaske für Netze mit nur einem Rechner besteht ausschliesslich aus Einsen, die Netzwerkmaske für das gesamte Internet nur aus Nullen bezeichnet deshalb die Defaultroute. Weiterhin lautet die Netzwerkmaske z.b. für ein Klasse B Netz und in der Binärschreibweise Häufig wird jedoch die sehr lange und umständliche Darstellung mit der Angabe der Anzahl der Einsen in ihrer jeweiligen Darstellung abgekürzt. Klasse Beispiel Anzahl der Einsen Class A Class B Class C Tabelle 5.2: Kurzdarstellung für Netze Wenn man classless Routing einführt, dann haben Netze wieder Netzmasken von 0 bis 32. Deshalb sollten als Endungen von Netzmasken nur die dezimalen Zahlen 255, 254, 252, 248, 240, 224, 192, 128, 0 auftreten. Man könnte natürlich versucht sein, kompliziertere Muster von Netzmasken zu bauen und statt ein Klasse C-Netz in der Mitte zu teilen, entlang der geraden und ungeraden IP-Nummern spalten. Dieses trägt jedoch extrem dazu bei, Routingtabellen nicht mehr durchschauen zu können und sei daher nur dem erfahrenen Netzwerkadministrator als Option genannt. Weiterhin wird man sich nicht immer darauf verlassen können, dass jede TCP/IP-Implementation sauber mit dieser Art von Netzmasken umgehen kann Private IP-Adressen Der gesamte Adressbereich 127.b.c.d ist dem Loopback-Netz 10 zugeordnet, dabei handelt es sich um ein per Software simuliertes Netz. Einzige Maschine auf diesem loopback-netz ist die eigene; evtl. mit verschiedenen Namen. Die Adresse bezieht sich stets auf die eigene Maschine; sie kann zu keinen anderen Zwecken gebracht werden, als zur Definition des das sind wir selbst. Die Adresse a.b.c.0 ist für das lokale Netz (Netz name ) reserviert. Die Adresse a.b.c.255 ist für Nachrichten an alle (Broadcast) reserviert 11. Folgende Adreßbereiche sind zum Aufbau privater, nicht mit dem Internet verbundener Netzwerke freigegeben: siehe hierzu die Anmerkungen im vorherigen Abschnitt 11 Das Beispiel bezieht sich auf ein Class-C Netzwerk, bei einem Class-B sähe die der Netzname wie a.b.0.0 und die Broadcastadresse wie a.b aus.

62 52 KAPITEL 5. TCP-IP Diese Adressen werden im Internet nicht geroutet (d.h. die Pakete werden spätestens am Router des eigenen LAN zum Internet wegegeworfen). 5.6 Der IP-Header IP hat mehrere Aufgaben, dafür werden einige Informationen benötigt: Die Quell- und Zieladresse; Informationen zum Weiterreichen an die höhere Netzwerkschicht; Fragmentierung 12 ; Verfallsdatum 13 ; Länge des Pakets und die Prüfsumme. 32 bit VERS. IPHL IDENTIFICATION TYPE OF SERV. D F M F SOURCE ADDRESS DESTINATION ADDRESS TOTAL LENGTH FRAGMENT OFFSET TIME TO LIVE PROTOCOL HEADER CHECKSUM OPTIONS (ZERO OR MORE WORDS) Die einzelnen Header-Bestandteile: Abbildung 5.4: IP Paket-Header Version (4 bit) - Die Versionsnummer steht für die zu verwendende IP-Protokollversion. Derzeit üblicherweise verwendet wird IPv4. H-Länge (4 bit): Die Header-Länge gibt an, wie viele 32 bit-zeilen der gesamte IP- Header besitzt. Dadurch, dass das Optionen-Feld unterschiedlich lang werden kann, ist es sinnvoll zu wissen, ab wo das Protokoll der nächst höheren Schicht beginnt. Service-Type (8 bit): Das TOS-Feld (Type of Service) bestimmt, um welche Art von Daten es sich bei diesem Datagramm handelt. Diese Information ist hauptsächlich zu Zeiten von überlastetem Netzwerkverkehr nützlich. Hier macht es Sinn die Anwendungsart (HTTP-Typ, FTP-Typ,...) der Daten zu wissen, um entsprechende Prioritäten beim Transport der Datagramme über eine Verbindungsleitung zu setzen. Wirklich verwendet wird dieses Feld jedoch nicht. Länge (16 bit): Dieses Feld gibt an, wie viele Bytes das gesamte Datagramm überhaupt enthält. Fragment-ID (16 bit): Gibt an um welches Paket es sich handelt. Das spielt eigentlich nur eine Rolle, wenn fragmentiert werden muss. Da jeder Sender eine ID in dieses Feld einträgt, ist es Dritten durchaus möglich verschiedene Maschinen hinter einem Masquerading-Router zu identifizieren. 12 nicht alle darunterliegenden physikalischen oder logischen Netze haben die gleichen Eigenschaften 13 Unzustellbare Pakete müssen irgendwann das Netz wieder verlassen - also entsorgt werden

63 5.7. IP-ROUTING 53 Flags (3 bit): Flags werden für die Fragmentierung benutzt, auf die im nächsten Abschnitt genauer eingegangen werden soll. Fragment-Offset (13 bit): Gibt an, an welcher Stelle das Fragment eingefügt werden muss. TTL (8-Bits): Das Time-To-Live gibt an, wie viele verschiedene Netze (Hops) das Datagramm auf seiner Reise noch benutzen darf. Somit wird verhindert, dass Datagramme endlos im Netzwerk herumirren. Höheres Protokoll (8 bit): Hiermit wir angegeben, um welches Protokoll es sich in der nächsthöheren Schicht, also der Transportschicht, handelt. Ein Wert von 6 bedeutet, dass das TCP-Segment über den entsprechenden Port an das TCP weiter verabreicht werden soll. Ein Wert von 5 deutet hingegen auf das UDP in der Transportschicht hin. Die Protokollnummer wird im IP-Jargon als der Klebstoff bezeichnet, welcher die Netzwerkschicht mit der Transportschicht verbindet. Die Zuordnungen von Protokollen und Nummern findet man in der Datei /etc/protocols. Prüfsumme (16 bit): Dieses Feld besitzt dieselbe Funktion wie das Prüfsummen-Feld im TCP/UDP. Sie dient der Detektion von Bit-Fehlern in einem empfangenen Datagramm. Es stellt sich an dieser Stelle nun die Frage, warum sowohl auf der Transportschicht als auch auf der Vermittlungsschicht eine Prüfsumme berechnet wird. Ein offensichtlicher Grund dafür ist, dass sowohl auf der Vermittlungsschicht als auch auf der Transportschicht andere, wenn auch nicht häufig verwendete Protokolle existieren, die keine Prüfsummenberechnung durchführen, so dass es sinnvoll sein kann, die Überprüfung der Korrektheit mittels der Prüfsummenberechnung auf beiden Schichten durchzuführen. Quell-IP-Adresse (32 bit): Gibt an, von welcher IP-Adresse das Datagramm ursprünglich kommt. Ziel-IP-Adress (32 bit): Gibt an, zu welcher IP-Adresse das Datagramm verschickt werden soll. Optionen (je 32 bit): Diese Felder dienen der Erweiterung des IP-Headers Fragmentierung Manche Teilstrecken im Netzwerk können nicht mit beliebigen Datagrammgrößen hantieren. Jedes Netzwerkteilstück besitzt deshalb eine maximale Datagrammgröße MTU (Maximal Transmission Unit). Die Router, die Datagramme zu diesen Routern senden, müssen also stets überprüfen, ob die Größe der zu sendenden Datagramme die MTU der empfangenden Router nicht übertreffen. Sollte dies der Fall sein, so werden die jeweiligen Datagramme fragmentiert. Wenn ein Datagramm fragmentiert wird, so werden mehrere kleinere Datagramme erstellt, die dieselbe ID haben, jedoch ein gesetztes Fragment-Flag enthalten. Durch das Fragment-Offset wird zudem angegeben, an welcher Stelle das Fragment in das Datagramm eingefügt werden muss. Beim letzten Fragment ist das Fragment-Flag gelöscht, um anzuzeigen, dass keine weiteren Fragmente mehr folgen. 5.7 IP-Routing Eine entscheidende Aufgabe des Internet-Protkolls ist die Verbindung verschiedener Teilnetze untereineinder. Hierzu muss es eine geeignete Paketweiterleitung implementieren. Diese

64 54 KAPITEL 5. TCP-IP wird als Routing bezeichnet. Zur Einordnung sei wiederholt, dass IP ein verbindungsloses paketorientiertes Protokoll ist, welches definiert wurde, um die exklusive Belegung eines Datenkanals zu verhindern. Erst auf darüberligenden Schichten kann der Nutzer entscheiden, ob er verbindungsorientierte oder -lose Kommunikation wünscht. TCP arbeitet verbindungsorientiert, UDP schafft einen einfachen Datagrammrahmen, der direkt auf IP aufsetzt. Die Weiterleitungsentscheidung erfolgt beim Internet-Protokoll für jedes einzelne Paket neu. Damit das Routing möglichst effizient erfolgen konnte, sollten IP-Adressen selbsterklärend sein, d.h. sie besitzen ein Präfix zur Netzwerkkennung. Mit dem Suffix wird der Host im Teilnetz identifiziert. Deshalb erfolgte ursprünglich eine Klasseneinteilung des gesamten IP-Adressraumes in Klassen. Die Klassen A bis C definierten dabei gültige Adressen mit fest vorgegebenen Prä- und Suffixlängen. Spezielle Adressen werden für die Netzwerkkennung eingeführt. So sind Netzwerke neben anderen IP-Spezialadressen innerhalb des Namesraumes zu kennzeichnen. Mit dieser Festlegung ist eine gewisse Hierarchisierung der Verteilung von IP-Adressen möglich Prinzip der IP-Netze Bei der Planung eines lokalen Netzes gibt es zwei Zielsetzungen: Direkter Datenverkehr zwischen allen lokalen Maschinen ohne Umweg über den Router (sonst unnötige Belastung und Verzögerung) Begrenzung der Reichweite der Datenpakete auf das kleinst-mögliche Teil-Netz (aus Sicherheitsgründen und zum Schutz anderer Teil-Netze vor unnötiger Belastung) Die Einstellungen zum Umsetzen dieser Ziele sind: Bezeichnung networkaddress subnet-mask ip-address Beschreibung Adresse des eigenen Teil-Netzes, Vergleich mit IP- Adresse gibt an, ob ein Datenpaket zum lokalen Netz gehört oder nicht Bitmaske zum Herausstanzen der Netzwerk- Adresse aus der IP-Adresse einer Maschine Eigene Adresse der Maschine Tabelle 5.3: Abgrenzung der Reichweite des lokalen Netzes address netmask network In diesem Beispiel bilden alle 254 Maschinen mit der Adresse N ein gemeinsames Netzwerk. Darüberhinaus gibt es noch die broadcast-address, die eine Adresse für Nachrichten an alle in diesem Teil-Netz ist. Rechnet man die Netzadresse 14 und die Broadcast-Adresse 15 hinzu, kommt man für ein Class-C-Netz, wie hier dargestellt, auf 256 IP-Adressen (= 2 8 ). 14 die kleinste Adresse im Teilnetz, dieses ist eine nicht vergebbare IP! 15 die grösste Adresse im Teilnetz, auch diese IP sollte nicht für Rechner vergeben werden!

65 5.7. IP-ROUTING Routing (Die Wege im Netz) Der Datenverkehr findet zwischen den Netzwerkschnittstellen der Internet-Rechner statt. Ein Linux-PC kann mehrere Netzwerkschnittstellen besitzen und als Vermittlungsstelle zwischen verschiedenen Netzen (Router) dienen. Dann kann es jedoch notwendig sein, die Routing-(d.h. Paketforwarding-)Fähigkeit des Kernels einzuschalten. Dieses kann für jedes Interface einzeln definiert werden. Der Name einer Netzwerkschnittstelle hängt von der verwendeten Netzwerktechnik ab (nicht etwa vom Hersteller der Einsteckkarte, wie bei anderen Systemen). Der Befehl route zeigt an, wie der Betriebssystemkern Datenpakete an die verschiedenen Empfänger verschickt: shuttle:~/ > /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UGH wlan U eth U wlan UG lo U tun0 Alle gerade aktuellen Routen im Einzelnen kann man sich mit route -C anzeigen lassen. Diese Liste wird aber in grösseren Netzen bzw. auf Gatewayrechnern sehr schnell sehr lang werden. Informationen zum Routing können auch mit den Kommandos ip route oder netstat -r erhalten werden. Jedes dieser Programme greift dabei auf das Kernel-Proc- Interface zu. Eine klassische Konfiguration sieht wie angezeigt aus: Es ist das lokale Ethernet definiert, in dem alle teilnehmenden Systeme ohne Router/Gateway erreicht werden können. Alles was in diesem Bereich nicht zugestellt werden kann, wird dem Defaultrouter zur weiteren Zustellung überlassen. default hat die IP und meint das ganze Internet, also den verbleibenden Rest, wenn die erste Route nicht angewendet werden konnte. Der Defaultrouter (bzw. Defautlgateway) muss bereits in einem darüber definierten Routingeintrag bekannt gemacht worden sein (Mitglied im entsprechenden Subnetz sein), da es sonst nicht erreicht werden kann! So genügt es zum Transport von IP-Paketen, dass jeder Rechner im Internet entsprechend seines Horizontes Systeme kennt, die wieder die weiteren Wege im Netz kennen. Bei den Flags deutet G an, dass es sich um eine Gatewayroute handelt, also die Pakete nicht im lokalen Subnetz zugestellt werden. H deutet eine Hostroute an, dieses ist eine spezielle Form eines Sub-Netzes, da hier Point-to-Point- Verbindungen definiert werden. traceroute dient zur Verfolgung des kompletten Weges, den Datenpakete zu einem bestimmten Empfänger einschlagen, z.b. zu traceroute shuttle:~ # traceroute traceroute to ( ), 30 hops max, 40 byte packets ms ms ms ms ms * 3 nsc-rz-gwn.fun.uni-freiburg.de ( ) ms ms \ ms 4 Freiburg1.Belwue.DE ( ) ms ms ms 5 Stuttgart1.BelWue.DE ( ) ms ms ms 6 Frankfurt1.belwue.de ( ) ms ms ms 7 de-cix.ffm.plusline.net ( ) ms ms \ ms 8 heise2.f.de.plusline.net ( ) ms * ms

66 56 KAPITEL 5. TCP-IP 9 * heise2.f.de.plusline.net ( ) ms ms 10 * * heise2.f.de.plusline.net ( )(N!) ms Ein weiteres Tool, auch zur grafischen Visualisierung, ist mtr, My Traceroute. Router leiten Datenpakete an entfernte Maschinen und sorgen für den Datenaustausch zwischen Teilnetzen. U.U. müssen die Pakete bis zum Ziel über mehrere Router geleitet werden; darauf hat man aber keinen Einfluß. Router oder Gateway wird meist synonym verwendet, wobei ein Gateway eigentlich grundverschiedene Netze (Protokolle) miteinander verbindet. Der Routingeintrag, der zu einem bestimmten Interface gehört (im obigen Beispiel der erste Eintrag) erfolgt ab dem Kernel Version 2.2 automatisch, wenn der Systemadministrator das Interface konfiguriert. Alle weiteren Routingeinträge müssen manuell über das Kommando route erfolgen, was für den obigen Fall (ungekürzt) so aussehen würde: shuttle:~/ # route add -net netmask gw Da man diesen Vorgang nicht jedesmal beim Neustart des Netzwerkes oder des ganzen Rechners wiederholen möchte, können die weiteren Routingeinträge ublicherweise in der Netzwerkkonfiguration hinterlegt werden Einfaches Hostrouting Wie werden Pakete bei einfachen Hosts, d.h. Maschinen mit einer einzigen Netzwerkverbindung zugestellt? Jede Maschine benötigt eine eigene IP-Nummer, z.b Dieses ist eine gültige Adresse aus dem Bereich des genannten Beispielnetzes von Insgesamt können also 254 IP-Nummern vergeben werden, da von den 256 Möglichkeiten die Netzwerknummer und die Broadcastadresse abzuziehen sind. Die Verwaltung des Netzwerkes erfolgt auf den Routern und durch geeignete IP-Vergabe an die Hosts. Alle Eintragungen erfolgen manuell. Jedoch sollte man beachten, dass IP nicht überprüft, ob bestimmte Adressen bereits vergeben wurden. Für die dynamische Zuweisung von IP-Adressen an Hosts hat sich das Dynamic Host Configuration Protocol als Standard herausgebildet. Dieses wird in einem weiteren Abschnitt näher beleuchtet. Jeder Host des Beispielnetzes enthält Routingtabelle. Diese fällt je nach Zahl der Interfaces und angeschlossenen Netzwerke unterschiedlich komplex aus. Netzwerk Netzmaske Router-IP Interface Ethernet, TokenRing, Loopback-Interface Defaultroute Tabelle 5.4: Routingtabelle eines Hosts Die Defaultroute dient für alle anderen Adressen, die im eigenen Netz nicht zustellbar sind. Deshalb wurde die Bezeichnung Defaultroute gewählt. Damit Pakete weitergeleitet werden können, muss jedoch mindestens ein Router Mitglied des jeweiligen Teilnetzes sein 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.

67 5.7. IP-ROUTING 57 aus Ziel-IP und Netzmaske wird durch den Vergleich mit den Netzadressen ermittelt, ob eine Route verwendet wird oder nicht. Z.B. für das Ziel: & ergibt Dieses wird mit der Netzadresse verglichen. Wenn es passt, schicke auf diese. Andernfalls probiere nächste, z.b. bei & ergibt ungleich, also nächster Versuch & errechnet sich zu passt immer auf die Defaultroute. Dabei startet man bei der kleinsten Netzmaske, also dem Netz mit den wenigsten Hosts. Dann arbeitet man sich sukzessive bis zur größten Netzmaske 17 alle eingetragenen Routen ab. Die Defaultroute ist dabei eine Konvention zur Vereinfachung der Routingtabellen. Kein Router kennt alle die Wege zu allen Internet-Adressen direkt, da fast jeder Router nur einen Bruchteil des Adressbereiches verwaltet. Jeder dieser Router hat eine Route für alle restlichen Bereiche. Auch ein einfacher Host kann mehrere Routen für verschiedene Netze kennen, falls mehrere Router in seinem Teilnetz vorhanden sind. Eine Entscheidungstabelle eines Routers könnte wie im nachstehend gezeigten Beispiel aussehen. Die Netzmaske entscheidet über Reihenfolge der Einträge in der Routingtabelle. Im Extremfall kann es also passieren, dass ein Paket gegen jede Regel geprüft wird. Netz Netzmaske Gateway/Router Interface # # # # # # #3 Tabelle 5.5: Beispiel einer möglichen Routingtabelle Eine Verwaltung von Routinginformationen in größeren Netzwerken wird sehr schnell recht aufwändig. Deshalb wurden Protkolle entwickelt, um einige Aspekte automatisieren zu können. Dynamisches Routing soll Ausfälle erkennen und Alternativrouten finden und eintragen. Hierzu sind verschiedene Strategien möglich: Hop-Count: Wieviele Router liegen auf dem Weg von A nach B (was ist jedoch, wenn der Weg über eine langsame ISDN-Leitung viel kürzer ist, als der Umweg über ein viel schnelleres LAN) Open Shortest Path First: Routingmetrik nimmt weitere Kennzahlen einer Route auf BGP: Border-Gateway-Protokolle für Router an den Grenzen großer Netzwerke Obwohl Adressen zentral vergeben werden, erreicht man kaum eine nähere geografische Zuordnung 18 als auf Länder oder Kontinentebene. Lokal nahe beieinander liegende Firmen oder Organisationen können durchaus netzwerktopologisch gewaltige Entfernungen besitzen, wenn sie über verschiedene Provider angeschlossen sind. IP-Netze sind eher daher eher als provider-based zu bezeichnen das gesamte Internet 18 Auch wenn es Firmen gibt, die zu jeder IP-Adresse eine ungefähre bis genaue geografische Koordinate liefern können.

68 58 KAPITEL 5. TCP-IP Subnetting und Supernetting Frühe Router interpretierten zur Ermittlung der Adressklasse die ersten vier Bits und verwalteten diese in einer Tabelle zur schnelleren Bearbeitung. Dieses Konzept ist nicht mehr wirklich praktikabel, denn z.b. Uni-Freiburg hat mit Netzadresse und Netzmaske ein Klasse-B-Netz. Aber: Nicht alle Rechner können in einem Ethernet o.ä. zusammengefaßt werden, damit ist ein Routing wie im Beispiel kaum sinnvoll. Noch extremer: Besitzer von Klasse-A-Netzen können nicht mehrere Millionen Rechner direkt verwalten. In diesen Netzen wird üblicherweise ein Subnetting zur besseren Abtrennung verschiedener Netze untereinander betrieben. Damit reduziert sich die Broadcast-Domain und es wird eine Strukturierung des Netzes erreicht. Mit der Knappheit der IP-Adressen im Netzmaske Bitmuster der Netzmaske Teilnetze Anzahl IP s Tabelle 5.6: Subnetting in Klasse-B-Netzwerken derzeitigen IPv4-Adressraum von 2 32 (weniger etlicher Spezialadressen, siehe dazu bisherige Ausführungen) gab es eine Reihe von Ansätzen das Ende von IPv4 herauszuzögern. Ein Ansatz ist das classless routing und das subnetting. Netze können nun im Bereich der Adressen beliebig zusammengefasst und geteilt werden. Für die Routinginformationen wird nun jedoch immer die Subnetzmaske mit zu übermitteln sein, da sich diese nicht mehr aus der ersten Bitfolge der IP ergibt. Damit: Ein flexibleres Schema ist notwendig. Klassen dürfen beliebig in Subklassen aufgeteilt werden, z.b. kann das RZ der Uni-Freiburg einzelnen Bereichen sog. Subnetze zuweisen. Aus der Aufteilung der höheren Klassen entstehen aus einem Klasse B Netz mit Rechnern werden dann 256 Klasse C Netze mit 254 Rechnern pro Netz. Trotzdem müssen sich Router weltweit weiterhin nur als Netzadresse merken, da Netze mittels Supernetting zusammengefaßt werden können. Supernetting kann z.b. zwei Klasse C Netze, wie und , zu einem Netz zusammenfassen und für dieses dann die Maske verwenden. Supernetting kann damit Adressverschwendung verhindern: Ausgabe eines Klasse B Netzes für eine Organisation mit 500 Rechnern. Dann: IP-Adresse ist nicht mehr wie ursprünglich selbsterklärend deklariert, denn nun muss die Netzmaske zwingend mit übermittelt werden. Die Netzmaske liefert aus ihrer Folge von 1 und 0 die Aufteilung zwischen Netzwerkteil der IP-Adresse und dem Hostteil. Diese Unterteilung bestimmt, welche Adressen in einem lokalen Netz vergeben werden können. Diese können in diesem Netz ohne Router miteinander direkt über ARP kommunizieren. Dabei sollten in der Folge nur 1 gefolgt von nur 0 stehen 19, z.b.: 19 Daraus folgt, dass nur die Zahlen 0, 128, 192, 224, 240, 248, 252, 254, 255 in der Netzmaske vorkommen können. Andere Muster wären möglich aber eventuell ordentlich verwirrend. Siehe Anmerkungen dazu weiter

69 5.7. IP-ROUTING 59 netmask netmask netmask Die erste Beispielmaske ist eine Class-C-Maske und die letzte, die eines Class-B-Netzes. Es spielt nun aber keine Rolle mehr, wie das erste Bitmuster der IP-Adresse aussieht. Geht man z.b. davon aus, dass ein Class-B-Netz aufgeteilt werden soll, dann geschieht das wie folgt: Das gezeigte Muster kann natürlich auch ausgehend von einem Class-A-Netz durchgeführt werden, wobei dann der letzte Tabellenwert mit 256 zu multiplizieren ist. Geht man von einem Class-C-Netz aus, muss der letzte Wert hingegen durch 256 geteilt werden. Wendet man dieses Beispiel nun auf ein konkretes Teilnetz an, z.b. auf das Class-B- Netz , dann ergibt sich das Bild (Tabelle 5.7.5) bei gleichmässiger Aufteilung. Die Tabellen könnten natürlich noch weiter fortgesetzt werden, aber das Prinzip sollte klar Teilnetze Netzadresse(n) Netzmaske Broadcastadresse(n) Zahl der IP s Tabelle 5.7: Beispiele einer Aufteilung in bis zu acht Teilnetze geworden sein. Es ist jedoch nicht erforderlich ein Netz in gleiche Teile zu untergliedern, sondern es können auch unterschiedlich grosse Teilbereiche definiert werden, wobei sich jedoch jeder Teilbereich in die seinem Bitmuster passenden Blöcke einfügen muss 20. Das angegebene Beispiel könnte also auch so aussehen, wie in Tabelle?? gezeigt. Subnetting und Supernetting haben wesentlich dazu beigetragen, dass IPv4 immer noch reicht. Dadurch wird Routing aufwändiger, da Router nicht mehr anhand der ersten vier Stellen der Adresse über deren Maske entscheiden können. Router benötigen mehr Speicher für die Kombination aus Netznamen und Netzmaske. Adressklassen sind nun von eher historischer Bedeutung. Problem: Wie werden ehemals reservierte Adressen, wie Broadcast und Netznamen behandelt, die nun evtl. reguläre Adressen in zusammengefaßten Netzen sind? oben 20 Das bedeutet z.b. im Beispiel, dass eine Netzadresse wie bei einer Netzmaske von ungültig ist. Die Startadresse kann [0,7,15,23,...].0 sein.

70 60 KAPITEL 5. TCP-IP Teilnetze Netzadresse(n) Netzmaske Broadcastadresse(n) Zahl der IP s Tabelle 5.8: Beispiele einer Netzaufteilung mit verschiedenen Subnetzmasken QoS-Routing IP selbst und die meisten Netzwerktechnologien kennen kein oder nur sehr beschränktes Quality of Service (QoS). Paketorientierte Netzwerke sind zuallererst für gleichberechtigten Zugriff ohne Ressourcen-Monopolisierung ausgelegt. ATM unterstützt zwar QoS, jedoch keine einfache Verknüpfung mit IP über Schichtgrenzen hinweg. IP ist verbindungslos, mit dem Verlassen des Paketes der Maschine ist kein Einfluss mehr möglich. IP-Header enthält ein Optionenfeld für QoS-Flags (dieses wird jedoch nur selten ausgelesen): Minimum Delay Maximum Throughput Maximum Reliability Minimize Costs Kombinationen aus diesen Feldern sind möglich. Verschiedene Dienste können so unterschiedliche Merkmale realisieren (Sprache, FTP, SSH,...). Probleme: Verletzung des Schichtenmodells, da Applikation den IP-Header mitbestimmen muss; alle Router müssen Felder auswerten; Prioritäten können sich auf dem Weg ändern (z.b. Einschätzung des Kostenfaktors von Leitungen); Pakete können auf ihrem Weg umgeschrieben werden. Trotzdem kann QoS-Routing beim Anschluss von LANs an das Internet über schmale Uplinks (Bsp. WG-oder Firmen-Router an DSL) sinnvoll sein. Router sind bereits mit normalem Routing stark belastet - zusätzliche Regeln können die Belastung nur erhöhen. Deshalb: Meistens ist es wieder einfacher die Bandbreite zu erhöhen, als aufwändiges QoS-Routing einzusetzen. Im LAN-Bereich gibt es Überlegungen zu QoS bei Ethernet - IPv6 soll einiges mehr an QoS implementieren.

71 5.8. ADDRESS RESOLUTION PROTOCOL Address Resolution Protocol Jede Ethernet-, Funk- TokenRing-Karte besitzt eine eindeutige Hardware-Adresse, die auch als MAC-Adresse bezeichnet wird. LAN-Karten bedienen sich dieser MAC-Adresse, die für die Aussendung und den Empfang von Datagrammen über das Netzwerk unerlässlich ist. Sie können nur auf Datagramme antworten, die im Empfänger-Feld eine Rundsende-Adresse, eine bekannte Verteilsende-Adresse oder eine auf die betreffende LAN-Karte hinweisende Individual-Adresse aufweisen. Die MAC-Adresse steht bereits beim Erwerb des Netzwerkgeräs fest. Sie ist fest einkodiert z.b. in einer Netzwerk-Karte. Sie ändert sich nicht und ist weltweit theoretisch 100 % eindeutig. Der flache Adressraum umfasst 48 bit und die Adressen werden traditionell hexadezimal dargestellt. Man werfe einfach mal einen Blick auf die Unterseite des eigenen Laptops oder den Aufdruck auf einer Netzwerkkarte und wird dort eine typische Darstellung der Form: 00:0a:e4:35:34:6a finden. Ethernet verwendet ein ganz eigenes Adressierungsschema, das nach komplett anderen Kriterien funktioniert, als beispielsweise vom Internet Protokoll gewohnt. Es gibt lediglich eine Aufteilung der Adresse in ein Hersteller-Prefix und ein eindeutiges Suffix für jede Karte eines Herstellers ARP - Hilfsprotokoll des IP Das Address Resolution Protocol wird als Bindeglied zwischen der eigentlichen Netzwerk- Hardware einerseits und dem Internet Protokoll (IP) anderseits benötigt. Anders als bei Punkt-zu-Punkt-Verbindungen, wie beispielsweise ISDN agieren in einem Ethernet viele Maschinen gleichberechtigt. Damit reicht es nicht, einfach das Paket an einem Ende der Leitung abzuliefern und nach kurzer Verzögerung am anderen Ende zu erwarten. IP-Adressen kann man nicht einfach nehmen, da man ja beim Kauf einer Ethernet-Karte noch gar nicht wissen kann, in welchem Netz eine Maschine betrieben wird. Ebenso wollte sicherlich keiner einsehen, dass ein Laptop entweder nur zu Hause oder im Firmennetz an einer bestimmten Stelle angeklemmt werden kann,oder dass man sich einen neuen Netzwerkadapter kaufen muss, wenn sich die IP ändert. Deshalb verwendet man beim Ethernet einen eigenen Adressraum mit Eigenschaften, die sich zum IP-Adressraum stark unterscheiden. Die IP-Adresse ist, wie bereits oben erläutert, im OSI-Schichtenmodell der Vermittlungsschicht zugeordnet und von der individuellen MAC-Adresse unabhängig. Jede Kommunikation mittels TCP/ IP wird durch die IP-Adresse eingeleitet, wodurch für den Aufbau des Dialogs die MAC-Adresse als sekundär zurückgestuft wird. End-zu-End-Kommunikationen bedienen sich also der IP-Adresse, wohingegen bei den dazwischen liegenden Knotenpunkten (Hops) in den genannten Netzwerktypen die MAC-Adresse genutzt wird. Jedem Host im Netz wurde aber nun auch noch eine IP-Adresse zugeordnet und damit hat das darunterliegende broadcastfähige LAN ein Problem: Mit der IP-Adresse weiß es nichts anzufangen, mit der MAC-Adresse 00:08:74:46:DC:9C allerdings schon. Ein Vermittlungsdienst muss her: Das Adress Resolution Protocol (ARP) übersetzt die IP- Adressen in Ethernet-Adressen. So gesehen gehört es eigentlich auch nicht vollständig in den Link Layer, sondern ist irgendwo zwischen Link und Network Layer einzuordnen. In den ersten beiden 16 bit Feldern des ARP-Paketes stehen der Hardwaretyp und die benutzten Protokolladressen. Im Falle von IP auf der Basis von Ethernet steht im ersten Feld eine 1 für Ethernet und im zweiten Feld 0x0800 für das IP-Protokoll, wie es auch im Ethernet- Rahmen markiert wird. Die beiden 8 bit Felder zu Beginn der nächsten Zeile bestimmen die Anzahl der Bytes für die Hardware- und Protokolladressen, in diesem Fall 6 Byte für die Ethernetadresse und 4 Byte für die IP-Nummer. Das sich anschließende Operation -Feld

72 62 KAPITEL 5. TCP-IP 32 bit HARDWARE ADDRESS TYPE PROTOCOL ADDRESS TYPE HADDR LENGHT PADDR LENGHT OPERATION SENDER HARDWARE ADDRESS (first 4 Byte) SENDER HADDR (last 2 Byte) SENDER PROTOCOL ADDRESS (first 2 Byte) SENDER PROTOCOL ADDRESS (last 2 Byte) TARGET HADDR (first 2 Byte) TARGET HARDWARE ADDRESS (last 4 Byte) TARGET PROTOCOL ADDRESS (all 4 Byte) Abbildung 5.5: Aufbau eines ARP Pakets bestimmt, ob es sich um eine Anfrage (Wert 1) oder eine Antwort (Wert 2) handelt. ARP beinhaltet Felder für zwei Adressbindungen, wobei eine dem Sender und die andere dem Empfänger entspricht, die in den Target -Feldern genannt wird. In den ersten TCP/IP-fähigen Rechnern wurde eine manuell erstellte Tabelle verwendet 21, die die Zuordnung zwischen MAC- und IP-Adresse indirekt automatisieren sollte. In den meisten broadcast-fähigen Netzen werden davon losgelöst zusätzlich oder ersetzend Routing-Informationen komplett automatisch mittels dem Adress Resolution Protocol ausgetauscht, welches in RFC 826 (An Ethernet Address Resolution Protocol) definiert wird. Jeder Host verwaltet dabei dynamisch den sogenannten ARP-Cache mit den relationalen IP-/MAC-Einträgen Funktionsweise ARP arbeitet dabei ziemlich geräuschlos im Hintergrund. Man muss nichts extra installieren, da diese Fähigkeit eigentlich in jeden Linuxkernel schon hineinkompiliert ist. Die Programme zur Konfiguration und Abfrage des ARP-Caches sind auf fast jedem Linux- Rechner installiert: mobile:~ # ip neighbor show dev eth0 lladdr 00:0a:e4:35:33:7a REACHABLE dev eth0 lladdr 00:0c:6f:45:03:0d REACHABLE dev eth0 lladdr 00:09:37:31:3a:13 REACHABLE In einem gegebenen Subnetz, hier / , werden alle Pakete, die eine Maschine verlassen sollen über das lokale Ethernet ausgetauscht. Dieses trifft auf fast alle Maschinen mit Internet-Verbindung zu, welche nicht ausschliesslich an einer Modem- oder ISDN-Verbindung hängen. Maschinen in diesem Subnetz verfügen meist über genau eine Netzwerkkarte, ausser sie stellen Gateway-Funktionen in andere Netze bereit. Dann bezeichnet man sie üblicherweise als Router. So gibt es zwei Szenarien: 1. Die Maschine A will mit einer Maschine B im selben Subnetz kommunizieren. Die Pakete können ohne die Beteiligung weiterer Maschinen direkt über das Ethernet hin- und hergeschickt werden. 21 Diese Fähigkeit ist heute noch vorhanden: Mit dem Kommando arp können der Kernel-ARP-Tabelle statische Einträge hinzugefügt oder welche gelöscht werden.

73 5.8. ADDRESS RESOLUTION PROTOCOL Die Maschine A will ein Paket an irgendeine Maschine ausserhalb des Subnetzes schicken. Da nur der Router R, der deshalb auch als Default-Gateway bezeichnet wird, den Weg in die weite Welt kennt, liefert A die Daten an R. R kümmert sich dann um die Weitersendung und leitet A eventuell zurückommende Antwortpakete oder Fehlermeldungen zu. Die Art der Daten, die ausgetauscht werden, spielt auf den unteren Netzwerkschichten unterhalb von IP keine Rolle. Jedes IP-Paket wird an den Data-Link Layer weitergereicht, um dort versendet zu werden. Mit der IP-Adresse von B, die als bekannt vorausgesetzt wird, kommt A hier nicht weiter und muss deshalb die MAC-Adresse von B in Erfahrung bringen. Der Ablauf einer ARP-Sitzung folgt normalerweise einem strikten Protokoll: A B 00:01:AA 00:01:BB ARP-Reply: " is at 00:01:BB..." Abbildung 5.6: Die Station mit der passenden IP-Adresse schickt ein ARP-Reply 1. Zu allererst schaut A in seinem ARP-Cache nach, ob es nicht vielleicht bereits dasgesuchte Adress-Paar bzw. die gesuchte MAC-Adressen kennt. In diesem Cache werden festgestellte Paarungen aus früheren Sitzungen für eine Weile vorgehalten, um nicht ständig wieder neu fragen zu müssen. Dieses würde unnötigen Netzwerk-Verkehr produzieren. 2. Falls kein Eintrag vorhanden ist, wird vom Initiator mit Hilfe von ARP die MAC- Adresse der fraglichen IP-Adresse zu ermitteln versucht. In der Hoffnung diese Frage wenigstens temporär aus der Welt zu schaffen, sendet A ein ARP-Datagramm inklusive der zu erfragenden IP-Adresse und einer sogenannte ARP-Anforderung an alle LAN-Karten mittels der bekannten MAC-Broadcast-Adresse (0xFFFF FFFF FFFF). ARP setzt in dieser verhältnismässig globalen Anforderung seinen eigenen Ethernet- Typ 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten wahrgenommen wird. Dieses Rundschreiben Ich kenne die MAC-Adresse X, die IP- Adresse A und ich suche die MAC-Adresse desjenigen, der die IP-Adresse B hat. wird von allen aktiven Maschinen im Netzwerk bemerkt. Falls innerhalb eines definierten Timeouts im Sekundenbereich keine Antwort auf die Broadcast-Anfrage eingeht, so wird die Anforderung erneut gestellt. 3. Der Rechner B, und nur dieser, wird auf dieses Broadcast-Request antworten: Die IP-Adresse von B ist unter der MAC-Adresse Y zu erreichen. In der ARP-Antwort sind dann alle Felder entsprechend gesetzt. 4. Für eine gewisse Zeit notiert sich A dieses Paar in seinem Cache. Da es den anderen Teilnehmern den Aufwand spart, später ebenfalls nach dieser Paarung fragen zu müssen, merkt sich die befragte Maschinen ebenfalls diese Paarung, solange der Cache nicht aufgrund potentieller Überfüllung überschrieben wird. Sie tut es auf Vorrat für den Fall, dass sie später ebenfalls Pakete an B schicken will. Bei einer eventuell nachfolgenden Anforderung ist es daher auch nicht mehr nötig den ARP-Dialog

74 64 KAPITEL 5. TCP-IP in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem bereits bekannt sind A B 00:01:AA 00:01:BB Ethernet-Kommunikation 00:01:AA <-> 00:01:BB IP-Kommunikation <-> Abbildung 5.7: Nach dem Austausch der MACs erfolgt die IP-Kommunikation ARP-Datagramme werden von Routern nicht weitergeleitet, da sie in der IP-Schicht operieren und auf MAC-Broadcasts grundsätzlich nicht reagieren können und dürfen. Router stellen daher verwertbare Puffer zwischen einzelnen Rundsende-Subnetzen dar. Mit ihrer Hilfe kann überflüssiger Traffic im gesamten Netzwerk eingedämmt und auf effektiv betroffene Subnetze minimiert werden ARP unter Linux Unter Linux erfährt man die MAC-Adresse mit: linux02:~ # ip link show 1: lo: <LOOPBACK,UP> mtu qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:81:55:06:01 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:e0:81:55:06:00 brd ff:ff:ff:ff:ff:ff 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit brd Die beiden Ethernet-Interfaces haben eine gültige Adresse, Loopback (lo) und das Tunnel- Interface (sit0) benötigen keine. Zum Netzwerkgerät zugeordnete IP-Adressen haben das bekannte Format bestehend aus vier durch drei Punkte getrennte Blöcke von Dezimalzahlen Zwar arbeiten die Rechner intern mit der Binärdarstellung, trotzdem sind die Unterschiede zwischen MAC- und IP-Adresse groß. ARP arbeitet beim Dolmetschen geräuschlos im Hintergrund. Man muss nichts extra installieren, da diese Fähigkeit im Linux-Kernel vorhanden ist. Die Programme arp und ip zur Konfiguration und Abfrage des ARP-Caches sind auf fast jedem Linux-Rechner installiert. mobile root # arp -n Address HWtype HWaddress Flags Mask Iface ether 00:03:47:B9:DE:36 C eth ether 00:02:B3:C2:55:91 C eth ether 00:0C:6E:15:03:0E C eth0 mobile root # arp -d mobile root # arp -n Address HWtype HWaddress Flags Mask Iface ether 00:03:47:B9:DE:36 C eth (incomplete) eth ether 00:0C:6E:15:03:0E C eth0

75 5.8. ADDRESS RESOLUTION PROTOCOL 65 mobile root # arp -n Address HWtype HWaddress Flags Mask Iface ether 00:03:47:B9:DE:36 C eth ether 00:02:B3:C2:55:91 C eth ether 00:0C:6E:15:03:0E C eth0 mobile root # arp -s :11:22:33:44:55 mobile root # arp -n Address HWtype HWaddress Flags Mask Iface ether 00:03:47:B9:DE:36 C eth ether 00:11:22:33:44:55 CM eth ether 00:0C:6E:15:03:0E C eth0 mobile root # ping PING ( ) 56(84) bytes of data ping statistics packets transmitted, 0 received, 100% packet loss, time 0ms mobile root # arp -s :02:B3:C2:55:91 mobile root # ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.164 ms ping statistics packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.164/0.164/0.164/0.000 ms ARP verlässt sich auf die MAC-Adresse des Ethernet-Adapters, so wie sie vom Betriebssystem mitgeteilt wird. Wenn man die MAC-Adresse eines Interfaces ändern will, kann man als Administrator dazu das Kommando ip link set verwenden: linux:~ # ip link set eth0 down linux:~ # ip link set eth0 address 00:20:AA:20:AA:20 linux:~ # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:20:AA:20:AA:20 brd ff:ff:ff:ff:ff:ff Das Ganze geht auch mit ifconfig: linux:~ # ifconfig eth1 eth1 Protokoll:Ethernet Hardware Adresse 00:00:0E:7D:71:DF BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) linux:~ # ifconfig eth1 down linux:~ # ifconfig eth1hw ether 00:4F:0E:7D:71:DF linux:~ # ifconfig eth1 eth1 Protokoll:Ethernet Hardware Adresse 00:4F:0E:7D:71:DF inet6 Adresse: fe80::24f:eff:fe7d:71df/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:0 (0.0 b) TX bytes:70 (70.0 b) Das bedeutet schlicht und einfach, dass man sich nicht darauf verlassen kann, dass die im Netz sichtbare MAC-Adresse wirklich die auf dem Netzwerkadapter programmierte ist. Im

76 66 KAPITEL 5. TCP-IP WLAN lässt sich die MAC-Adresse scheinbar auch auf diese Weise ändern. Da sie jedoch von der Firmware der Karte noch in anderen Schichten benutzt wird, kommt nach dieser Art der Änderung keine Funkverbindung mehr zustande. Es gibt jedoch Programme, mit denen sich per Firmware die MAC-Adresse von WLAN-Karten ändern lässt Eingebaute Sicherheitslücken Normalerweise sind keine Kontrollmechanismen vorhanden, die eine MAC-Adresse im Namen mehrerer IP-Adressen kompetent verifizieren kann. Angreifer können sich diese Eigenheit von ARP zunutze machen. Die Schwäche von ARP liegt in seiner Vertrauensseligkeit. ARP stammt aus den frühen Zeiten der IP-Kommunikation, wo ein es geht und möglichst schonender Umgang mit Netzwerkresourcen wichtiger waren, als eine sauber implementierte und unter umständen sehr aufwändige Authentifikation. Wenn ein Endsystem ein ARP-Reply aufschnappt, dann wird dieser im Cache abgelegtt, unabhängig davon, ob zuvor nach dieser Adresse gefragt wurde. Hierin verbirgt sich die grundlegende Sicherheitslücke. Aber auch ein scheinbar folgerichtiger Ansatz, eine Adresse nur dann zu speichern, wenn vorher genau nach dieser Adresse gefragt wurde, lässt sich leicht austricksen, indem ein potenzieller Angreifer einfach schneller antwortet, als der Inhaber der Adresse. So kann der Angreifer natürlich eine beliebige Antwort geben, wie beispielsweise seine eigene Adresse. Ausgangssituation für das 00:b0:11:11:11:11 00:b0:11:22:22: A B ARP-Reply: " is at 00:b0:11:33..." P 00:b0:11:33:33:33 ARP-Reply: " is at 00:b0:11: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 und die MAC 00:b0:11:11:11:11, B und MAC 00:b0:11:22:22:22. Der angreifende Host P hat die IP und dazugehörige MAC 00:b0:11:33:33:33. Er möchte ablauschen, was A und B miteinander zu schnacken haben. Host P startet seinen Angriff, indem er die ARP-Caches der Opfer A und B vergiftet 22, d.h. er injiziert gefälschte ARP-Antworten in das lokale Subnetz. P schickt an A ein ARP- Reply, dass die Information enthält, dass der Rechner B mit der IP-Adresse 2 unter der MAC-Adresse 00:b0:11:33:33:33 zu erreichen ist. In Wirklichkeit bekomm nun aber P die Pakete von A für B zugeschickt. Ebenso erhält B gefälschte Pakete von P, dass beinhalten, dass A mit der IP-Adresse 1 unter der MAC-Adresse 00:b0:11:33:33:33 angesprochen wird. In Zukunft schickt also A seinen Verkehr für B statt direkt zu B in Wirklichkeit zu P. Bei B gestaltet es sich genauso, er schickt seinen Verkehr für A zu P. Der Angreifer P muss nun einfach die Pakete korrekt weiterreichen, indem im Kernel IP-Forwarding eingeschltet wird. Die korrekten IP-Adressen stehen ja in den Paket-Headern, P kennt auch die korrekten MAC-Adressen. Wenn P noch ein wenig cleverer ist, dann passt er noch den HOP-Count im IP-Header an, bevor das Paket sein Interface verlässt. Da jeder Router im IP-Header den Hop-Counter um eins reduziert, muss dieser wieder erhöht werden. Andernfalls würde auffallen, dass der Weg von A nach B plötzlich um 22 hiervon stammt der Ausdruck Poisioning

77 5.8. ADDRESS RESOLUTION PROTOCOL 67 00:b0:11:11:11:11 00:b0:11:22:22: A B IP-Kommunikation <-> Ethernet-Kommunikation 00:b0:11:11... <-> 00:b0:11: P 00:b0:11:33:33:33 Ethernet-Kommunikation 00:b0:11:33:33:33 <-> 00:b0:11:22:22:22 Abbildung 5.9: mindestens einen Router länger geworden ist. Im Zuge der Weiterleitung der Pakete können diese bequem mitgelesen werden. Dabei kann der Angreifer möglicherweise Passwörter und andere geheime Daten auslesen. Zudem können Pakete auch problemlos manipuliert werden, was die Attacke noch mächtiger macht. Da der Angreifer sozusagen direkt auf dem logischen Verbindungspfad zwischen den Opfern sitzt, wird diese Art eines Angriffs auch als Man- In-The-Middle bezeichnet. 00:b0:11:11:11:11 00:b0:11:22:22: A B IP-Kommunikation <-> Paketlaufzeit1 Hop-Count: TTL P 00:b0:11:33:33:33 Paketlaufzeit2 Abbildung 5.10: Wenn der Angriff wieder beendet wird, muss der ARP-Cache der Opfer wieder aufgeräumt werden, d.h. es müssen erneut gefälschte ARP-Replies an A und B geschickt werden, zur Abwechslung nun mit den korrekten Paarungen von MAC- und IP-Adressen. Passiert dies nicht und P entfernt sich aus dem Netz oder deaktiviert sein IP-Forwarding, dann schicken A und B weiterhin ihren Verkehr an P. Dieser leitet ihn aber nicht mehr weiter: Die ganze Sache fällt wegen der Netzwerkunterbrechung unter Umständen auf. Insgesamt kann man festhalten, dass man nur an der ARP-Reply allein keine Auffälligkeit feststellen kann. Die Sender MAC Address stimmt überein mit der Absender-Adresse des umgebenden Ethernet-Frames, so dass es sich bei diesem Paket auch durchaus um ein echtes ARP-Reply handeln könnte. Tatsächlich ist dieses Paket aber gefälscht und Teil einer ARP-Poison-Attacke. Beim Beenden der Attacke verrät sich der Angreifer. Denn er schickt von seiner MAC-Adresse aus eine ARP-Reply, die angibt, dass seine IP-Adresse jetzt unter einer anderen MAC-Adresse zu erreichen ist. D.h. die Sender MAC Address stimmt in diesem Fall nicht überein mit der Absender-Adresse des umschließenden Ethernet-Frames. Hier kann man den Angreifer entdecken und seine MAC-Adresse ablesen. Das Standardwerkzeug für ein ARP-Angriff ist das Programm ettercap. Das kann inzwischen eine ganze Reihe von Man-in-the-Middle Angriffe durchführen. Hier interessieren jedoch nur die ARP-Angriffe. Ettercap ist ein Projekt, welches auf Sourceforge gehostet ist. Ettercap kennt drei verschiedene Benutzerinterfaces, eine Kommandozeilenversion, die mit -T aktiviert wird, eine ncurses-basierte Textoberfläche ( -C ) und eine grafische GTK-Version. Möchte man nun den Verkehr zwischen den beiden Maschinen und mitschneiden, dann erreicht man das über den Aufruf: ettercap -C -M arp

78 68 KAPITEL 5. TCP-IP Abbildung 5.11: Ettercap in der Ncurses-Ausführung / / / /. Mit ettercap -T -M arp:remote / / / / kann man das ARP Poisoning für das Gateway und die Rechner im Ethernet zwischen 2 und 10 laufen lassen. Die Remote-Option wird benötigt, damit man den Traffic mitbekommt, der über das Gateway geroutet wird. Ettercap dient nicht nur als Cracker-Werkzeug, es kann ebenso Administratoren eingesetzt werden, um Schwachstellen im eigenen Netz aufzuspüren. Die Illusion, dass sich Programme wie ettercap oder dsniff fernhalten lassen, kann man getrost vergessen, wo sie schon im Standardumfang vieler Von-CD-Distributionen enthalten sind Gefahrenabwehr Wie man sieht, bemerkt man einen solchen ARP-Angriff, wenn er geschickt ausgeführt wird, also wenn der HOP-Count manipuliert wird, kaum bzw. höchstens, wenn er beendet wird. Es gibt Möglichkeiten, ARP-Angriffe zu entdecken, aber es gibt kein wirksames Mittel gegen einen solchen Angriff außer einer Verschlüsselung. Das ändert natürlich auch nichts an der Tatsache, dass P immer noch die IP-Pakete abfangen und mitlesen kann, die zwischen A und B hin- und hergeschickt werden, aber wenn sie gut verschlüsselt sind, kann P nicht mehr viel damit anfangen. Für den Fall, dass P den Inhalt manipulieren will, insofern das überhaupt Sinn macht, wenn er den Inhalt nicht lesen kann, wird das auch auffallen. Verschlüsselung ist die einzige wirksame Möglichkeit. In kleinen Netzwerken, mit seltenen Änderungen der angeschlossenen Maschine ist es sogar mit vertretbaren Aufwand möglich, ARP-Angriffe komplett auszuschliessen, indem man ARP gar nicht erst verwendet. Die einfachste Variante ist die manuelle und statische Zuweisung von IP-Adressen zu MAC-Adressen. Der Admin trägt in einer Tabelle die Paarungen ein und vergibt entsprechend dieser Tabelle freie IP-Adressen. Diese Informationen stehen allen Endsystemen zum Routing zur Verfügung und sie können, außer durch den Admin, durch niemanden geändert

79 5.8. ADDRESS RESOLUTION PROTOCOL 69 werden. Die Verwendung von ARP wird schlichtweg überflüssig und damit fällt auch die Sicherheitslücke komplett weg. Der große Nachteil dieser Methode ist allerdings, dass sie nur sehr schlecht skalierbar ist, d.h. sobald das Netzwerk eine gewisse Größe erreicht hat, ist es einfach nicht mehr praktikabel. Dann gibt es häufige Änderungen, die zum einen kommuniziert werden müssen, aber zum anderen vor allem überhaupt erstmal vorgenommen werden müssen. Angenommen der Admin ist gerade nicht da, dann kann man z.b. keine Netzwerk-Karte auswechseln, weil man für die neue Karte keine IP-Adresse hat. Deshalb wurde ARP ja erfunden. In großen Netzwerken fällt diese Ausweichmöglichkeit also weg, weil es zu umständlich und schlecht wartbar ist. Verwendet man dann doch wieder ARP, kann man aber wenigstens die Paarungen von MAC- und IP-Adressen im Auge behalten. Zum einen fällt es natürlich auf, wenn ständig ARP-Replies geschickt werden, zumal es für diese Replies nie ein Request gab. Die gefälschten Replies müssen ja auch ständig neu geschickt werden, denn der ARP- Cache wird nicht ewig vorgehalten, irgendwann fällt der Eintrag von alleine wieder heraus. Eine zur statische Festlegung der der ARP-Tabelle mindestens gleichwertige Alternative stellt der Einsatz von arpwatch von Craig Leres dar, welches nach Veränderungen der IP- /Ethernet-Mappings Ausschau hält. Werden Änderungen bemerkt, findet eine Alarmierung per statt. Zudem werden die Manipulationen für eine spätere Analyse protokolliert ARP und doppelte IP-Adressen Wird einem Client-Rechner aus Versehen die gleiche IP-Adresse wie dem zur Verbindung aufgeforderten Host-System zugeteilt, können diverse Benutzer für kurze Zeit nicht auf die Dienste des Hosts zugreifen. Die verschiedenen Komponente und Eigenheiten des spezifischen Netzwerks lassen dieses Problem polymorph erscheinen, denn die Architektur des Netzes, der Einsatz von Routern, Hubs oder Bridges und die verwendete Hard- und Software haben einen entscheidenden Einfluss auf die Reaktionszeiten von ARP und dadurch auf das ganze Szenario. In deiner zur letzten Darstellung ähnlichen Situation haben der Host B und der Rechner P die gleiche IP-Adresse. Versucht nun Host A eine Verbindung zu P herzustellen, welche eine ARP-Anforderung zur Folge hat, erhält er durch das Adress Resolution Protokoll die IP-Adresse von Host B, da sowohl der Host als auch Host B antworten. Host A kann die Verbindung kaum erfolgreich herstellen, da Host B kaum in der Lage ist, mit der korrekten Dienst-Software aufzutrumpfen. Beim zweiten Versuch erhält Host A vielleicht die korrekte Antwort des Hosts, kann jedoch noch immer keine Verbindung herstellen. Handelt es sich beim Host B um einen normalen Arbeitsplatzrechner, wird dieser sehr wahrscheinlich bei längerem Nichtgebrauch ausgeschaltet. In diesem Fall taucht das Problem nur gelegentlich, zum Beispiel während den Arbeitszeiten des Benutzers am Host B, auf. Dies kann für genervte Benutzer zwischenzeitlich zum Vorteil werden, behindert jedoch die Fehlersuche des Netzwerkadministrators erheblich. Das letzte Szenario beschreibt sich einfacherweise wie folgt: Zwei Host-Rechner bedienen sich einer identischen IP-Adresse. In diesem Fall werden die Client-Maschinen gelegentlich eine Verbindung zum falschen Host herstellen, was ein korrekter Ablauf der Kommunikation unterbindet. Dieser Machtkampf ist selten anzutreffen, da es zu den Hauptaufgaben eines kompetenten Administrators zählt, bei jeder Phase des Netzwerkdesigns auf individuelle IP-Adressen zu achten. Hierbei hilft beispielsweise die Verwendung von DHCP.

80 70 KAPITEL 5. TCP-IP Proxy-ARP Mit Proxy ARP wird eine von IP-Routern genutzte Technik betitelt, die mit der Entwicklung von TCP/IP spezifiziert wurde. Der Sinn der Methode liegt in der Beseitigung einiger Probleme des begrenzten IP-Adressraums von IPv4. Durch dieses Verfahren können Router unsichtbar gemacht werden und Teilnetze bequem auf andere Interfaces geroutet werden. Der Linuxkernel unterstützt Proxy-ARP, womit sich recht komplexe Router aufbauen lassen. Nicht nur aufgrund des Wachstums eines Netzwerkes kann relativ schnell und verhältnismässig unerwartet der Punkt der physikalischen Beschränkung einer Einführung zusätzlicher Host in das System erreicht werden. In diesem Falle kann das Netz nur durch ein zweites unabhängiges physikalisches Kabelsystem erweitert werden. In den Kinderjahren von TCP/IP, vor dem Erfinden von Netzmasken und Brücken, konnten zwei Kabelsysteme nur mit einem für zwei verschiedene IP-Ranges konfigurierten Router verbunden werden. Repeater waren aufgrund des Fehlens der Notwendigkeit von Filterungsfunktionen für diese Arbeit nicht geeignet. IP-Adressen wurden damals rigoros und verschwenderisch vergeben - man konnte es sich ja damals auch noch leisten. Wenden wir uns einem illustren Beispiel zu: Ein Unternehmen ergatterte sich die registrierte IP-Adresse der Klasse B Die Firma benutzt die Ethernet-Technologie und möchte Host-Rechner mit der Hilfe von TCP/IP untereinander agieren lassen. Mit der Adresse der Klasse B stehen dem Unternehmen mögliche Hostadressen zur freien Verfügung. Da man jedoch Ethernet einsetzt, können maximal 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 Adressen der Klasse B nur gebraucht wurden, können die restlichen Adressen nicht verwendet werden; also offenbahrt sich eine Vergeudung in höchstem Maße. Damit der Router einwandfrei arbeiten kann, muss ihm eine zweite IP- Adresse der Klasse B zugeteilt werden, und damit sind erneut ganze IP-Adressen verschwendet. Dieses Vorgehen ist aus technischer Sicht in keinster Weise akzeptabel; abgesehen von privaten autonomen Netzwerksystemen ohne registrierte IP-Adressen. Das Internet Protokoll bedient sich ARP, um die MAC-Adresse einer Einheit zu ermitteln, sofern die Netznummer in der eigenen IP-Adresse der des Empfängerknotens entspricht. Andernfalls kommt ein routendes Element (Router oder Gateway) zum Einsatz. Damit möglichst wenige IP-Adressen verschleudert werden, ist es aus technischer Sicht wünschenswert den beiden Interfaces des routenden Systems die gleiche Netznummer zuzuteilen. Wird jedoch dieselbe Netznummer verwendet, muss man ein Verfahren finden, mit dem man die Richtung der Weiterleitung von Datagrammen eindeutig erkennen kann. Proxy ARP ist in diesem Fall einer der Schlüssel. Proxy ARP kann auf verschiedenste Weisen implementiert werden. Als die effizienteste Methode ist die Zuordnung von Bits in der IP-Adresse, anhand derer unterschiedliche Subnetze identifiziert werden können, anzusehen. Das Relais kann als eine Art Puffer die unnötigen ARP-Rundsende-nachrichten abblocken, da nur die an andere Subnetze adressierten Broadcasts weitergeroutet werden müssen. Damit kann der überschüssige Netzwerkverkehr eingedämmt und die Performance gewahrt werden. Die einzigen Hops, die die elementaren Bits zur Kennzeichnung der verschiedenen Subnetze erkennen können müssen, sind die Proxy ARP-Geräte. Natürlich erfordert das erreichen dieses Ziels eine durchdachte Zuweisung des richtigen Adressbereichs von seiten des Netzwerkadministrators. Beispiels-

81 5.8. ADDRESS RESOLUTION PROTOCOL 71 weise könnten die ersten vier Bits des Host-Anteils der IP-Adresse zur Identifizierung der verschiedenen Subnetze eingesetzt werden. Dabei wird jedoch nicht, wie von vielen vielleicht vermutet, mit Subnetz-Masken gearbeitet oder die Adressenstruktur des Endknotens bekannt. Es können nun also 14 Subnetze dadurch definiert werden (Die Subnetze 0 und 15 finden in diesem Beispiel aus Gründen der Einfachheit keine Verwendung!). Empfängt nun die Schnittstelle 1 eine ARP-Anforderung, überprüft die Proxy ARP-Vermittlungseinheit die Bits in der Hostadresse darauf, ob die Nachricht ein anderes Subnetz kennzeichnet. Wird der Gutfall erkannt, findet eine Weiterleitung an die Schnittstelle 2 statt. Dort wird dann die Absenderadresse durch jene der Proxy ARP-Schnittstelle 2 ersetzt und als üblicher ARP-Broadcast ins Neuland geblasen. Die jüngst von der ganzen Aktion betroffene Proxy ARP-Einheit speichert die in der ARP-Antwort vermerkte MAC-Adresse des Absenders-, sowie des Empfängerknotens und vermerkt an welcher Schnittstelle sich diese befinden. Wird vom Absender nun nocheinmal ein Datagramm an die Schnittstelle 1 des Routers gesandt, enthält dieser bereits die Empfängeradresse der Proxy ARP-Einheit. Das Datagramm wird daher direkt von der Proxy ARP-Einheit angenommen. Die Proxy ARP-Einheit ersetzt nun wiederum die tatsächliche MAC-Adresse des Empfängerknotens und sendet das modifizierte Datagramm an die Schnittstelle 2. Diese Methode funktioniert nur, wenn die beiden Endknoten die Gültigkeit der MAC-Adressen in den jeweiligen ARP-Antworten nicht überprüfen. Es ist durch dieses ganze Prozedere möglich, mit einer beliebigen MAC- Adresse zu antworten, die als Ersatz eines anderen Hosts fungiert. Der ARP-Cache eines Endknotens, der sich in einem Proxy ARP-System befindet, enthält die MAC-Adresse der Proxy ARP-Einheit, die vielen IP-Adressen zugeordnet ist. Diverse Firewall-Systeme erlauben das Verwerfen von durch Proxy ARP modifizierten Datagrammen, um so entfernte Manipulationen am ARP-Cache zu unterbinden Probleme durch Proxy-ARP Viele Router verwenden per Default-Einstellung Proxy ARP, auch wenn keine Subnetz- Adressierungs-schema zum Einsatz kommen. Das Router-Element greift insofern beim Empfang einer ARP-Anfor-derung für ein anderes Netz oder Subnetz manipulativ in das Geschehen ein, indem es seine eigene MAC-Adresse in der ARP-Antwort zurückschickt. Zur Übermittlung des Datagramms an den Empfänger werden die herkömmlichen Routenwahl- Mechanismen eingsetzt. Dieser Fall kann jedoch nur eintreten, wenn ein verwirrter oder falsch konfigurierter Rechner das Gefühl des Sich-in-einem-anderen-Netz-Befinden hat und der Router sich an ein anderes Bild der Adressenstruktur klammert. Es läge also ein klassischer Adressierungs-Fehler vor, da zwei Geräteeinheiten die IP-Adresserungsschematas komplett anders interpretieren. Grund dafür kann die Wahl unterschiedlicher Subnetz- Masken sein. Die beiden Geräte würden so mit einer Netzstruktur arbeiten, die für die Opposition nicht erkennbar und verständlich ist. Denial of Service durch ARP-Stürme Der Denial of Service-Angriff mittels ARP- Sturm hat die Überlastung einer Netzwerkkomponente oder eines Netz(abschnitt)es zur Folge, was unter Umständen einen weiteren weniger destruktiven Angriff erst ermöglicht (z.b. IP-Spoofing). Die Extremsituation tritt ein, wenn ARP-Broadcasts eine non-existente IP-Adresse in Erfahrung bringen versuchen. Alle an das Netzwerk angeschlossenen Gateways beginnen alsdann mit dem Weiterleiten der Anfrage an die Nachbarnetze. Ganz extrem wird dieser Angriff, wenn nach dem ersten Briadcast-Sturm synthetische ARP-Rückantworten der nicht existierenden Adresse versendet werden, die wiederum von den Gateways per Broadcast zur finalen Verstopfung des Netzes weiterverbreitet werden. Solche Broadcast-

82 72 KAPITEL 5. TCP-IP Stürme belegen rasch einen Grossteil der Netzwerkkapazität und lassen die Performance in den Keller sinken. Wichtig ist in sensiblen Umgebungen im Vorfeld das sogenannte Media- Speed-Verhalten durch experimentell simulierte Extremsituationen in Erfahrung zu bringen. HAVOC für UNIX/Linux ist ein beliebtes Tool zum Erzwingen von ARP-Stürmen. Denial of Service durch ARP-Fehlimplenetierungen Auch auf Fehlimplementierungen der ARP-Funktionalität können Denial of Service-Attacken abzielen, wie im NetBSD Security Advisory (ARP table vulnerability) berichtet wird: obsd fun.c schickt übergrosse ARP-Pakete an eine OpenBSD 2.6-Maschine, und zwing sie so zur Kernel-Panik. Aber nicht nur UNIX-Derivate sind von solchen Schlampereien betroffen. Auch Microsot Windows, welches eine Menge Code von BSD direkt übernommen haben muss, kann mit den C-Scripts winarp.c und poink.c auf die Pelle gerückt werden. Diese Angriffs-Form wird im Thread von Joel Jacobson in Bugtraq erstmals vorgestellt. Ähnliche Diskussionen finden sich in den beiden Threads von Andrew Lancashire und Lisa Napier über DoS-Attacken auf Cisco-Systeme, und von Scott Blake über Cabletron-Router, durch das Überfluten der ARP-Tabelle. 5.9 ICMP - Internet Control Message Protocol Das ICMP dient zur Übermittlung von Fehler- und Statusinformationen. ICMP wird auch von IP selbst verwendet, um beispielsweise Fehler zu melden. ICMP ist daher zwingend in IP vorhanden; funktional gesehen ist es Teil von IP, technisch setzt es jedoch auf IP auf. ICMP kann aber auch direkt von Applikationen verwendet werden. ICMP Pakete werden verwendet, wenn beispielsweise der Zielrechner oder das Zielnetzwerk nicht erreichbar ist. In diesem Fall gibt ein TCP/IP Router beispielsweise ein host unreachable bzw. network unreachable Paket zurück. ICMP ist im Network Layer angesiedelt, ist aber eigentlich kein wirklich eigenständiges Protokoll, da die Übermittlung von ICMP-Nachrichten durch IP-Pakete erfolgt und dazu dient, die Übertragung von den eigentlichen Daten zu steuert. ICMP ist damit kein Datenfluss sondern ein Kontrollfluss, der den Datenfluss steuert. Durch seine Vielseitigkeit bietet ICMP aber auch leider die Möglichkeit versteckte Nachrichten zu übermitteln. Ein Stichwort ist hier das sogenannte ICMP-Tunneling. Beim ICMP-Tunneling wird das Datenfeld eines ICMP-Paketes genutzt, um Informationen zwischen Rechnern auszutauschen. ICMP-Tunneling ist aber keine Technik, die es eventuellen Datenspionen ermöglicht, in einen Rechner oder ein Netz einzubrechen. Dennoch stellt das Tunneling eine Bedrohung für das Sicherheitskonzept eines Netzes dar. Eine recht bekannte Anwendung von ICMP ist das Programm ping, mit dem man die Erreichbarkeit eines anderen Rechners prüfen kann. Dazu wird ein ICMP echo request an den Zielrechner geschickt, dieser sendet ein ICMP echo reply zurück, wenn er denn verfügbar ist. Ping ist ein einfaches Shell-Kommando und wird mittels ping Zieladresse aufgerufen. dirk@linux:~/nwak> ping PING ( ) from : 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=47 time=21.1 ms 64 bytes from : icmp_seq=2 ttl=47 time=23.2 ms 64 bytes from : icmp_seq=4 ttl=47 time=20.9 ms ping statistics packets transmitted, 3 received, 25% loss, time 3019ms rtt min/avg/max/mdev = /21.774/23.243/1.041 ms

83 5.10. DOMAIN-NAME-SERVICE (DNS) 73 ICMP wird meistens von IP für den Benutzer unsichtbar verwendet, zum Beispiel um herauszubekommen, wie groß ein Paket sein kann, das von Link Protokoll übertragen werden kann, oder um Fehler zu melden. ICMP hat sehr unterschiedliche Informationen zu transportieren. Deshalb ist nur der Grundaufbau des ICMP-Headers immer gleich, die Bedeutung der einzelnen Felder im Protokollkopf wechselt jedoch. Jeder ICMP-Nachrichtentyp wird in einem IP-Datengramm eingekapselt. Die derzeit wichtigsten ICMP-Nachrichtentypen sind: Destination Unreachable (Ziel nicht erreichbar) - Diese Nachricht wird verwendet, wenn ein Netzwerk, Host, Protokoll oder Port nicht erreichbar ist, ein Paket nicht fragmentiert werden kann, weil das DontFragment-Bit gesetzt ist oder die Source Route Option nicht erfolgreich verwendet werden konnte. Parameter Problem - Verständigt den Absender eines Datengramms darüber, dass das Paket aufgrund einer fehlerhaften Angabe im IP-Header verworfen werden mußte. Redirect - Wird ausgesendet, wenn ein Router feststellt, dass ein Paket falsch weitergeleitet wurde. Der sendende Host wird damit aufgefordert, die angegebene Route zu ändern. Time Exceeded (Zeit verstrichen) - Diese Nachricht wird an den Absender eines Datengramms gesendet, dessen Lebensdauer den Wert 0 erreicht hat. Diese Nachricht ist ein Zeichen dafür, dass Pakete in einem Zyklus wandern, dass Netz überlastet ist oder die Lebensdauer für das Paket zu gering eingestellt wurde. Echo Request und Reply - Mit diesen Nachrichten kann festgestellt werden, ob ein bestimmtes Ziel erreichbar ist. Ein Echo Request wird an einen Host gesendet und hat einen Echo Reply zur Folge (falls der Host erreicht wird). Das Ping-Kommando nutzt diese Eigenschaft des ICMP. Timestamp Request und Reply - Diese beiden Nachrichten sind ähnlich den zuvor beschriebenen Nachrichten, außer dass die Ankunftszeit der Nachricht und die Sendezeit der Antwort mit erfaßt werden. Mit diesen Nachrichtentypen kann die Netzleistung gemessen werden. Eine ICMP-Nachricht wird immer als Antwort auf ein Datengramm verschickt. Entweder ist ein Datengramm auf ein Problem gestoßen, oder das Datengramm enthält eine ICMP-Anfrage, auf die eine Antwort versendet werden muss. In beiden Fällen sendet ein Host oder Router eine ICMP-Nachricht an die Quelle des Datengramms zurück Domain-Name-Service (DNS) Der Domain-Name-Service ist ein auf TCP/IP basierender Dienst und kein Bestandteil der Vermit-tlungs- bzw. Transportschicht. Jedoch werden vielfach Maschinen nicht primär über ihre Netzwerkadresse, sondern ihren Hostnamen und evtl. Domainnamen, die zusammen den Full Qualified Domain Name ergeben, angesprochen. Deshalb wird dieser Dienst an dieser Stelle bereits kurz vorgestellt. In der Benutzung hat man meistens clientseitig mit DNS zu tun, die Serverseite wird in einem eigenen Abschnitt gesondert vorgestellt. Fast jede Maschine im Internet besitzt neben der numerischen Adresse (IP-Nummer) mind. einen sybolischen Namen (Hostname). Nameserver kennen die zu den symbolischen Namen gehörenden IP-Adressen und umgekehrt. Wenn man Nameserver direkt abfragen will, kann

84 74 KAPITEL 5. TCP-IP Kürzel Bedeutung Kürzel Bedeutung gov governemental com Unternehmen ( commercial ) de Deutschland edu Ausbildungseinrichtung net Netzwerk org Organisation Tabelle 5.9: Die traditionellen Domänenendungen Kürzel Bedeutung Kürzel Bedeutung name Privatpersonen biz Unternehmungen eu Europa info Informational ws WebSite int Internationale Organisationen Tabelle 5.10: Die von der IANA beschlossenen/vorgesehenen neuen Domänenendungen man das mit den Kommandos host oder nslookup machen. Mittels DNS (Domain-Name- Service) werden die Hostnamen in einen hierarchischen Namensraum eingegliedert, wobei geografische Gesichtspunkte (Länderdomains, wie de ) oder organisatorische Gründe (Firmen) Ausrichtungskriterien abgeben können. Die Organisation von Namen in einer Hierarchie von Domains schafft gleichzeitig die Schwierigkeit der Eindeutigkeit von Namen aus der Welt. Bei DNS muß ein Hostname nur innerhalb einer (Sub-)Domain eindeutig sein, und schon ist sichergestellt, dass er sich von allen anderen Hosts weltweit unterscheidet (Sonst wäre der beliebte Aliasname www nicht möglich!). Mehr noch, voll qualifizierte Namen sind einfacher zu merken. Der FQDN (Full Qualified Domain Name), die Kombination aus Hostnamen und der Domain (incl. evtl. Subdmomainnamen) wird durch Punkte in Bestandteile gegliedert, die über den Namen und die Zugehörigkeit des Rechners Auskunft geben. Das erste Wort des FQDN ist der sogenannte hostname, der hintere Teil des FQDN ist der domainname. Während der domainname vorgegeben ist, hat man bei der Taufe des Rechners freie Wahl. Neben Namen, die in Zusammenhang mit der domain stehen (s.o.) sind außerdem Comic-Helden, Romanfiguren, berühmte Personen, antike Götter usw. sehr beliebt. Dem Rechner kann man auch weitere Namen verpassen, sogenannte Aliase, die meistens die Funktion der Maschine ausdrücken, z.b. 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 nameserver Die search Order definiert, welche Domainnamen an Hostnamen angehangen wurden, die ohne Domainkürzel angesprochen wurden: ping test würde versuchen zuerst test.kolosseum.local, dann test.goe.net und zum Schluss test.gwdg.de zu ergänzen und aufzulösen. So kann man sich beim Bewegen in der eigenen Domain viel Tipparbeit sparen. Es können maximal zehn Ergänzungen der Suchreihenfolge und maximal drei Nameserver angegeben werden. Der zweite und dritte DNS werden nur befragt, wenn der erste nicht reagierte, nicht jedoch, wenn die Anfrage auf dem ersten keinen Erfolg brachte.

85 5.11. TRANSMISSION CONTROL PROTOCOL (TCP) Transmission Control Protocol (TCP) Mit der Übertragung von Datagrammen (IP-Paketen) von einem Netzwerkknoten zum anderen ist es nicht getan. Wenn man sich remote einloggen möchte, z.b. mit dem Kommando ssh oder Daten von einem Webserver bezieht, ist hierfür eine zuverlässige Verbindung die Voraussetzung. Der Datenstrom wird zum Transport in Pakete aufgeteilt, da grosse Dateien 32bit SOURCE PORT DESTINATION PORT TCP-H Length unused CHECKSUM SEQUENCE NUMBER ACKNOWLEDGEMENT NUMBER U R G A C K P S H R S T S Y N F I N WINDOW SIZE URGENT POINTER OPTIONS (0 or more 32bit words) BEGINNING OF DATA (optional) Transmission Control Protocol (TCP) Abbildung 5.12: TCP Paket-Header nicht in einem Stück transferiert werden können und interaktive Verbindungen zeitnah laufen sollen, d.h. nicht ewig gewartet werden kann, bis ein grosses Paket voll ist. IP ist (absichtlich) nicht zuverlässig. Überlastungen im Netzwerk werden durch das Vergessen von Paketen gelöst. Die Verantwortung für die Integritätsprüfung und die Vollständigkeit der Daten übernehmen die beiden kommunizierenden Rechner, die fehlerhafte Daten erkennen sollen und diese im Fehlerfall erneut anfordern. Diesen Part übernimmt ein weiteres Protokoll, das Transmission Control Protocol (TCP). Dieses stellt einen zuverlässigen Dienst über IP-Verbindungen her. Da es auf IP aufsetzt, muss sich TCP um den Weg, das Routing durchs Netz, keine Gedanken machen. TCP bringt seine Informationen wiederum in einem Header unter: Dieser ist 20 Bytes lang. Eine TCP-Verbindung kann man sich am besten wie ein Telefonat vorstellen. TCP identifiziert die Endpunkte einer solchen Verbindung anhand der IP-Adressen der beiden Rechner und der Nummer eines sogenannten Ports auf jedem Host. Ports können Sie sich als eine Art Ein- und Ausgang für Netzwerkverbindungen vorstellen. Diese Adressierung kann man mit einem Haus (IP-Nummer) und den verschiedenen Türklingeln (Port- Nummern) vergleichen. Auf einer Unix-Maschine kann man sich die Zuordnung von Diensten zu Ports in der Datei /etc/services ansehen. In TCP/IP-Suite übernimmt das Transmission Control Protocol die Aufgaben der Transportschicht. Es etabliert ein verbindungsorientiertes Protokoll, welches auf dem verbindungslosen Internet-Protokoll aufsetzt. Dadurch gelingt es, einen zuverlässigen Bytestromes in einer End-zu-End-Ver-bindung auf einem unzuverlässigen Netzverbund aufzubauen. TCP nimmt Datenströme von Benutzerapplikationen entgegen und teilt diese in maximal 64 kbyte grosse Blöcke auf. Diese Datenblöcke, Datagramme 23 genannt, werden wiederum mit einem Header versehen. Das so gebildete Datagramm wird dann an die IP-Schicht 23 zur Unterscheidung von den Datenblöcken der Hardwareschicht Frames und den Datenblöcken der Vermittlungsschicht Packet

86 76 KAPITEL 5. TCP-IP weitergeleitet. Da IP selbst keine Zustellbestätigung kennt muss TCP diese implementieren und bei Bedarf ein Neuverschicken verlorengegangener oder beschädigter Pakete veranlassen. Weiterhin muss die Reihenfolge der Pakete kontrolliert und evtl. korrigiert werden. Da auf einem Host mehrere Datenströme möglich sein sollen und nur eine IP-Adresse vergeben wird, erfolgt die Definition von speziellen Endpunkten. Diese Endpunkte werden als Sockets bezeichnet. Jedes Socket hat eine Socketnummer. Diese besteht aus der IP-Adresse des Hosts und einer 16 bittigen Portnummer. Ein Socket kann mehrere Verbindungen verwalten, wobei jedoch jedes Quadrupel aus Quelladresse und -port und Zieladresse und -port eindeutig sein muss. Portnummern unterhalb von 256 bzw sind für sogenannte well-known services reserviert. Hier findet man die Standarddienste Weitere sechs Ein-Bit-Felder des Hea- Service Port-Nummer Service Portnummer ftp 21 pop3 110 ssh 22 ntp 123 telnet 23 rsync 873 smtp 25 imaps 993 http 80 pop3s 995 ldap 389 ldaps 636 Tabelle 5.11: TCP-basierte Standardservices ders sind für diverse Flags vorgesehen. Sie steuern das Verbindungsverhalten eines TCP- Datenkanals. Das Flag Push signalisiert, dass keine Datenpufferung stattfinden soll, d.h. dass die Datagramme nicht vollständig aufgefüllt werden sollen. Dieses ist bei interaktiven Verbindungen, wie ssh, telnet und dem Steuerkanal von ftp sinnvoll. Sonst müßte man warten bis z.b. der User an die eintausend Zeichen getippt hat, um ein Paket zu verschicken. Synchronize, Acknowledge, Reset und Finish dienen der Verbindungssteuerung. Mit Urgend kann das Dringlichkeitsflag gesetzt werden. Dann zeigt der Urgendpointer, der in einem weiteren Datenfeld des Headers untergebracht ist, auf das Paket welches sofort behandelt werden soll. Damit kann eine Out-of-Band Signalisierung erfolgen. Das Feld für die Header-Länge gibt die Zahl der verwendeten 32 bit-worte an. Damit ist das Startfeld der Daten bekannt. Ein Analogon findet man im Fragment Offset des Internet-Protokolls. Sequence- und Acknowledgenummern dienen der Kontrolle der Paketreihenfolge und sollen die Sicherheit einer Verbindung erhöhen. Letzteres darf jedoch nicht dazu verführen, anzunehmen, dass eine TCP-Sitzung sicher vor bewußter Manipulation oder Mitlauschen ist. Da alle Daten offen, d.h. unverschlüsselt, übertragen werden, können Angreifer versuchen die Acknowledge- und Sequencenummern zu raten und damit einen Datenstrom übernehmen. Diese Nummern werden quasizufällig beim Verbindungsaufbau gesetzt 24 und dann jeweils um eins (bzw. in späteren Implementationen auch andere zufällige Integer-Beträge) erhöht. Die Window-Size, ein weiteres Feld des TCP-Headers, erlaubt Flusskontrolle. Damit kann die Geschwindigkeit einer Verbindung gesteuert werden, in dem die Datenmenge bestimmt wird, nach der Paketbestätigungen verschickt werden. Hierbei findet das Sliding- 24 Da das Verfahren möglichst schnell und effizient arbeiten soll, wurde bei früheren TCP- Implementationen die Zahl einfach erhöht, aus dem Zeittakt abgeleitet etc.

87 5.12. USER DATAGRAM PROTOCOL (UDP) 77 Window-Verfahren Anwendung. Damit wird ein Zeitfenster eröffnet, in dem eine Paketbestätigung eingegangen sein muss. TCP benutzt eine aufwendige State-Machine für die eindeutige Charakterisierung des jeweiligen Verbindungszustandes. Der Verbindungsaufbau erfolgt mittels des sogenannten Three-Way-Handshakes. Erst nach einem erfolgreichen Verbindungsaufbau kann ein Datentransfer stattfinden. Für Verbindungsabbau erfolgt ein geordneter Abschluss analog zum Aufbau User Datagram Protocol (UDP) In vielen Fällen der Netzwerkkommunikation genügt die Übertragung eines einzigen Paketes zur Informationsübermittlung in jede Richtung. Der Aufwand würde durch das vorgeschaltete 3-Wege-Handshake, welches TCP implementiert, und den geordneten Abbau der Verbindung gewaltig angehoben. Dadruch entstünde eine unnötige Belastung des Netzwerkes. Ein weiteres in IP-Netzwerken verwendetes Protokoll ist das im Gegensatz zu TCP ungesicherte User Datagram Protocol (UDP). Mit UDP werden einzelne Pakete an den entsprechenden Dienst gesandt, ohne dafür eine Verbindung aufzubauen. Klassischerweise verwenden NFS, SNMP und RWHO UDP. Die Grösse des Paketheaders beträgt bei UDP 8 Byte und ist damit gegenüber TCP erheblich geringer. Beispiele für die Anwendung eines solchen sparsamen Protokolls sind das DHCP (Dynamic Host Configuration Protocol) oder DNS (Domain Name System). Die genannten Protokolle finden nur (DNS sehr viel) im LAN statt - dieses zeichnet sich üblicherweise durch sehr geringe Fehlerraten aus. Mit UDP wurde das Design eines sehr einfachen Protokolls der Transportschicht geschaffen, welches IP mit Transportfunktionalität ausstattet. Das User Datagramm Protocol ist verbindungslos und implementiert nur einen einfachen Header. 32 bit Source Port UDP Length Destination Port UDP Checksum User Datagram Protocol Abbildung 5.13: UDP Paket-Header UDP verwendet wie TCP 16 bittige Portnummern, womit UDP-Ports auf einer Maschine verfügbar sind. Diese können komplett parallel zu den TCP-Ports verwendet werden. Weiterhin wird die Paketlänge und eine Prüfsumme vermerkt. UDP kennt keine Bestätigungsmeldungen und keine Prüfung auf Reihenfolge. Der UDP-Header ist immer 8 Byte lang 25. Deshalb erhält man sehr geringe Latenzzeiten. Es eignet sich gut für Broadcasts. Alle weiteren Aufgaben, die TCP zusätzlich implementiert, müssen bei der Verwendung von UDP von der Applikation übernommen werden. UDP-Pakete können auch per Broadcast an alle Hosts des lokalen Netzes versandt werden, die IP-Adresse des Empfängers ist dann 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

88 78 KAPITEL 5. TCP-IP entsprechenden Paket; alle anderen bekommen das Paket erst gar nicht oder müssen sich einfach an alle wenden. Broadcast-Pakete gehen nur einmal über die Netzwerk-Leitung. Es wird also nicht für jeden Teilnehmer ein getrenntes Paket verschickt. Die Leitungs- Belastung ist also gleich der beim Versenden eines Pakets an nur einen Peer Ports Ports wurden im Zusammenhang der Transportprotokolle UDP und TCP bereits kurz erwähnt, aber kaum erklärt. Dies soll an dieser Stelle nachgeholt werden. Über das TCP und UDP Protokoll können Daten zu einem anderen Rechner übertragen werden. Nun hat man aber häufig mehrere Dienste auf einem Rechner, und möchte gleichzeitig mit mehreren Diensten kommunizieren können. Da also ein Rechner in der Regel mehr als einen Dienst anbietet (z.b. FTP, Telnet, POP,...), muß man neben der IP-Adresse ein weiteres Adressierungsmerkmal finden. Dies sind die sogenannten Ports. So erreicht man z.b. den Dienst FTP auf einem Rechner in der Regel über TCP Port 21, Telnet läuft über TCP Port 23, DNS auf UDP Port 53. Hinter jedem Port steht auf dem Rechner ein Prozeß, der auf Anfragen wartet, hinter Port 21 entsprechend der FTP-Daemon. Solche üblichen und allgemein bekannten Ports nennt man well-known ports. Man sollte die Informationen nicht verwechseln. Adressen sind Teile von IP. Ports sind Teile von UDP und TCP. Es gibt damit also keine IP-Ports, sondern nur UDP Ports und TCP Ports. In der Datei /etc/services sind etliche well-known ports aufgeführt Aufgaben 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? Internet Protokoll / Header 1. Wozu dient das TTL-Feld im IP-Header? 2. Man ergänze mindestens vier IP-Header-Felder! 3. Anhand welchen IP-Header-Felds kann man unter Umständen erkennen, wieviele Maschinen hinter einer maskierenden Firewall (NAT) laufen? 4. Ein Rechner hat ein IP-Datagramm empfangen und erfolgreich ausgewertet. Woher weiss die Maschine, an welche höhere Netzwerkschicht der Inhalt dieses Pakets (die sog. Payload) weitergereicht werden soll?

89 5.14. AUFGABEN 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? IP-Netze 1. Was unterscheidet die folgenden IP-Nummern im Netz /24: , , , , voneinander? 2. Wie konnte ein Router früher schon an der IP-Adresse erkennen, um was für ein Netz (Netzmaske) es sich handelt? Weshalb hat man dieses Konzept aufgegeben? 3. Wenn man ein Class-C-Netzwerk (Netzmaske in vier Subnetze aufspaltet, wieviele Maschinen können dann in jedem Netz adressiert werden? Erkläre die Entscheidung! 4. Einem ISP wurde der Nummernblock /17 zugeteilt. Nun soll dieser Bereich in vier gleiche Subnetze aufgeteilt werden. Wie lauten diese? 5. Ein Netzwerk habe die Subnetzmaske Wievele Maschinen können maximal in diesem Netz adressiert werden? 6. Ist eine Subnetzmaske der Form a) oder b) zulässig? Man begründe die Entscheidung! 7. Was versteht man unter IP-Spoofing? Läßt es sich verhindern; warum oder warum nicht? 8. Man bastele eine (hypothetische) Netzmaske, die Rechner mit geraden IP-Adressen in ein und mit ungeraden Adressen in ein anderes Subnetz legt! Fragmentierung 1. Warum bietet IP die Möglichkeit Pakete zu fragmentieren? 2. Was versteht man unter Path MTU Discovery (PTMUD)? Die MTU (Maximum Transfer Unit) gibt die maximale Paketgröße auf dem Data Link/physikalischen Layer an. 3. Wodurch kann PMTUD von Routern (ungewollt) verhindert werden?

90 80 KAPITEL 5. TCP-IP 4. Warum arbeitet man bei der Fragmentierung mit Offsets und schreibt nicht einfach die Größe des Fragments in das Feld? 5. Man betrachte die Verschickung eines 4000 Byte Datagramms über ein Netzwerk mit einer MTU von 900 Byte. Dabei sei das Original mit der Identifikationssnummer 345 bezeichnet worden. Wieviele Fragmente werden generiert? Für jedes Fragment gebe man die Identifikation, die Payload ohne IP-Header, Offset und den Inhalt des More Fragments Flags an! IP-Routing 1. Ein Router hat die folgenden Einträge in seiner (statischen) Routing-Tabelle: Address/Netmask Next Hop /22 Interface 0 (direkt) /22 Interface 1 (direkt) /23 Router /20 Router /0 Router 3 Wo schickt der Router Pakete mit folgenden Zieladressen lang: , , , , , ? ARP 1. Warum wird eine ARP-Anfrage in einem Broadcast-Frame (Ethernet, TokenRing,...) geschickt? Wie sieht so ein spezielles Frame aus? 2. Warum kommt die ARP-Antwort in einem Frame mit einer spezifischen Zieladresse zurück? 3. Braucht man ARP bei der Modem/ISDN-Einwahl?

91 Kapitel 6 Linux im Netzwerk Linux hat sich im Laufe der Zeit zu einem der führenden Betriebssysteme entwickelt, welches auch und gerade wegen seiner vielfältigen Eigenschaften auch auf Routern 1 eingesetzt wird. Router sind die zentralen Vermittlungs- und Weiterleitungsstellen im verbindungslosen, paketorientierten Internet. Linux kann neben TCP/IP auch in AppleTalk, IPX/SPX, Decnet und weiteren Netzwerken betrieben werden. Die folgenden Ausführungen werden sich jedoch nur am Rande mit anderen Netzen als dem Internet-Protokoll (IP) auseinandersetzen. Die folgenden Ausführungen zum OSI-Modell und TCP/IP haben natürlich nicht nur mit Linux zu tun, sondern betreffen alle Rechner, die über Netzwerke miteinander (mittels TCP/IP) kommunizieren können. IP-Netzwerke sind inzwischen die dominierende Form der Rechnervernetzung. Der Komplexitätsgrad und die Anforderungen an diese Netze haben stark zugenommen. Während lange Zeit die einfache Einbindung einer Linux-Maschine in bestehende Netzwerke durch Ethernet oder Modem/ISDN im Vordergrund stand, geht mit den aktuellen Kernels bedeutend mehr. 6.1 IP-Konfiguration unter Linux Die Einbindung von Linux in ein IP-Netzwerk geschieht durch die Zuweisung einer eindeutigen Adresse. Diese ist entweder weltweit erreichbar oder zumindest im lokalen Netzwerk nur einmal vorhanden 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: Bcast: Mask: 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: (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

92 82 KAPITEL 6. LINUX IM NETZWERK lo Link encap:local Loopback inet addr: Mask: 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: (12.8 Mb) TX bytes: (12.8 Mb) In der Ausgabe sieht man je nach Interface die Angaben zur definierten IP, die Hardwareadresse, wenn es sich um ein Ethernetinterface handelt, sonst den Point-to-Pointpartner (z.b. bei Modem und ISDN). Weiterhin wird angezeigt, welche Protokolle auf dem Interface registriert sind (z.b. Appletalk und IPv6 sind neben dem klassischen IPv4 denkbar), wieviel Byte die maximale Paketgrösse transportiert und die Kosten (Metrik) des Interfaces. In den folgenden Zeilen gibt es Angaben zu den empfangenen und gesendeten Paketen, sowie den evtl. aufgetretenen Fehlern. Handelt es sich um ein Ethernetanschluss wird in einer weiteren Zeile die Zahl der Kollisionen vermerkt und die Länge der Queue für ausgehende Pakete. Mit dem Befehl: ifconfig eth netmask broadcast wird z.b. die erste Netzwerkkarte mit der IP-Nummer versehen. Ist eine weitere Netzwerkkarte im Rechner enthalten und soll diese auch eingerichtet werden, dann spricht man sie mit ifconfig eth1... an. Möchte man auf einer Netzwerkkarte mehrere Netze bzw. IP-Nummern konfigurieren, kann dafür ein IP-Alias definiert werden, wenn in der Kernelkonfiguration IP-Aliasing aktiviert wurde: ifconfig eth0:0... erlaubt es nun eine weitere IP auf der ersten Netzwerkkarte einzutragen. Dieses Interface wird vom Kernel getrennt von eth0 verwaltet, d.h. wenn ich Pakete zwischen den beiden Interfaces routen möchte, muss ich dieses im Kernel einschalten (echo "1" >/proc/sys/net/ipv4/conf/ ip forward). Ein Alias auf einer Netzwerkkarte kann man jedoch nur konfigurieren, wenn diese Netzwerkkarte bereits eingerichtet wurde Routing Im Internet geht es an jeder Stelle um die Weiterleitung von Paketen von einer Quellzur Zieladresse. Jedem Netzknoten, die Internet-Router, müssen für jedes IP-Paket neu entscheiden, wo sie es langschicken. Routingentscheidungen müssen jedoch schon auf dem Quellrechner eines Paketes getroffen werden. Dieses gilt für jede Linux-Maschine mit installiertem TCP/IP-Stack. Ist das Paket für das Loopback-Interface bestimmt soll es im lokalen Ethernet zugestellt werden soll es über ein Interface laufen, an dem ein Modem hängt soll es an das Default-Gateway im Netz weitergeleitet werden. Der Linux-Kernel muss also für alle ausgehenden Pakete entscheiden, in welches Netzwerk er die Pakete schicken soll. Hierzu verwaltet der Kernel eine eigene Routing Tabelle. Diese enthält Informationen über Routen zu anderen Netzwerkknoten speichert. Jeder Eintrag einer Route besitzt dabei einen eindeutigen Schlüssel bestehend aus der Netzwerkadresse und der Netzmaske des verbundenen Netzwerks. Der nächste Hop für ein Paket welches nicht lokal zugestellt wird, ist das Default-Gateway. Dieses Gateway muss in einem der angeschlossenen Subnetze liegen, da es sonst nicht erreicht werden kann. Üblicherweise läßt sich der Admin diese Tabelle durch route -n oder netstat -rn:

93 6.1. IP-KONFIGURATION UNTER LINUX 83 linux:~ # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface U eth U eth U eth U lo UG eth1 ausgeben. In den SuSE-Linux-Distributionen werden die IP-Einträge unterhalb des Konfigurationsverzeichnisses /etc/sysconfig/network gespeichert und über das Runlevel-Skript /etc/init.d/ network start 2 mittels ip aktiviert. Bezieht der Rechner seine IP dynamisch per DHCP, so wird statt ip ein DHCP-Client-Tool, wie dhclient, pump oder dhcpcd ausgeführt. Diese Dienste beziehen die IP-Konfiguration über das lokale Ethernet und tragen die Ergebnisse direkt oder per Skript dhclient-script in die Netzwerkkonfiguration ein Next Generation IP-Config Die meisten Administratoren kennen und arbeiten immer noch ausschliesslich mit den traditionellen Werkzeugen ifconfig und route. Das IProute2-Paket erlaubt jedoch eine weit höhere Flexibilität. IProute2 ist seit Kernel-Version 2.2 standardmässig für das Routing von IP-Paketen zuständig. Es beherrscht eine ganze Reihe neuer Fähigkeiten: des Weiterleitens des Filterns der Klassifikation von IP-Paketen. Hierzu zählen beispielsweise das Einrichten von Backup-Gateways und das Verwenden von mehreren Default-Gateways. Wo früher nur die Zieladresse eines Paketes bei der Routing-Entscheidung eine Rolle spielte, können nun auch die Absendeadressen hierfür in Betracht gezogen werden. Ebenfalls lassen sich verschiedene Wege und Prioritäten anhand von eingesetzten höher liegenden Protokollen (TCP und UDP) und deren Ports festlegen. Auf diese Weise erhält der best-effort Service IP eine Quality of Service (QoS) Komponenten verpasst. Diese ist deutlich mächtiger als die meist sporadische Verwendung der Type of Service (ToS) Flags des IP-Headers. IProute2 führt neue Kommandos ein: ip und tc sind die beiden wichtigsten. Das erste Kommando dient zur Bearbeitung der Kernel-Routing-Tabelle. Das zweite zur Manipulation verschiedener Verkehrsklassen. Letzteres ist Thema an anderer Stelle im Skript. Die Tool-Suite enthält weitere Kommandos, wie nstat, ifstat, routel, rtstat. Sie generieren Statistiken und Überblicke Das Kommando ip IProute2 stammt von Alexey Kuznetsov entwickelt. Das Projekt besteht seit 1999 und wird seit Kernel 2.2 für das lokale Routing von IP-Paketen benutzt. Folgende Aktionen kann ein Sysadmin mit IProute2 vornehmen: Management von IP-Adressen (IPv4, IPv6) 2 Die Runlevel-Skripten sind auch direkt mit rcnetwork aufrufbar, da dieses Links aus dem Verzeichnis /usr/sbin auf die entsprechenden Runlevelskripten sind.

94 84 KAPITEL 6. LINUX IM NETZWERK ARP Tabellen Management Routing Tabellen Management Routing Policy Database Management IP Tunnel Konfiguration Paket und Routen Monitor Traffic Shaping (QoS) ip ist ein zusammengesetztes Kommando. Seine Funktion wird durch das zu bearbeitende Objekt bestimmt. Allgemein setzt sich der Aufruf von ip wie folgt zusammen: ip [OPTIONS] OBJECT [COMMAND[ARGUMENTS] help] Die OPTIONS beeinflussen wie bei gewohnten Kommandos auch das generelle Verhalten und die Ausgabe die ip Befehls. Optionen folgen direkt nach dem Kommando und sind mit dem - Zeichen eingeleitet. Sie können nicht hinter dem Objekt stehen. -V[ersion] - gibt die aktuelle ip-version aus. -s[tatistics] zeigt passend zum Objekt ausführlichere Informationen an. -f[amily] inet, inet6, link legt die die Protokollfamilie fest. -o[neline] sorgt für die Ausgabe aller Informationen in einer Zeile. So läßt sich die Ausgabe in Skripten oft besser bearbeiten. -r[esolve] schaltet die Namensauflösung von IP-Adressen und Netzen ein. OBJECT bezeichnet den Objekttyp. Zu diesem lassen sich Informationen ausgeben. Oder es wird eine Operation auf ihn angewendet. Das Objekt link bezeichnet ein physikalisches oder logisches Interface bzw. Netzwerkadapter. address ist die IPv4 oder IPv6 Adresse eines Adapters. neighbour greift auf den Kernel ARP Cache zu. route gibt Routing Tabellen aus und erlaubt deren Bearbeitung rule bezeichnet eine Regel in der Routing Policy Database. maddress dient zur Bearbeitung von Multicast Adressen. mroute ist für Multicast Routing Cache Einträge tunnel definiert IP-in-IP Tunnel. COMMAND spezifiziert die Aktion, die mit dem OBJECT veranstaltet werden soll. Die Art und Menge der möglichen Aktionen hängt dabei vom Objekttyp ab. Üblicherweise lassen sich Objekte hinzuzufügen (add), entfernen (delete) oder anzeigen (show). Einige Objekte kennen weniger andere weitere Aktionen. ARGUMENTS sind Kommando-Optionen. Sie hängen von der Art des Kommandos und vom Objekttyp ab. Es existieren zwei Typen von Argumenten: flags - können durch einzelnes Schlüsselwort abgekürzt werden. parameters - bestehen aus einem Schlüsselwort gefolgt von einem Wert. help liefert immer eine Kurzhilfe für das Kommando generell oder die Anwendung des Kommandos auf einzelne Objekte, z.b. ip help oder ip route help.

95 6.1. IP-KONFIGURATION UNTER LINUX Erste Schritte mit ip Die folgenden Beispiele sollen demonstrieren, wie ip die Standardaufgaben von route, arp und ifconfig übernimmt, die ein Sysadmin üblicherweise damit ausführt. Dazu sollte man sagen, dass bereits seit einiger Zeit die beiden traditionellen Kommandos ifconfig und route im Hinterground ip verwenden. Das Anzeigen aller Interfaces mit darauf definierten IP-Adressen erfolgt durch: linux02:~ # ip addr show 1: lo: <LOOPBACK,UP> mtu qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet /8 brd scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff inet /24 brd scope global eth0 inet /32 scope global eth0 inet6 fe80::2e0:29ff:fe0b:f938/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:0c:6e:15:03:0e brd ff:ff:ff:ff:ff:ff 4: sit0: <NOARP> mtu 1480 qdisc noqueue link/sit brd : tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1412 qdisc pfifo_fast qlen 10 link/[65534] inet /32 scope global tun0 Die Informationen zur Routing Tabelle liefert das Kommando ip wie folgt: linux02:~ # ip route show via dev eth0 src mtu 1500 advmss 1460 \ fragtimeout /24 dev eth0 proto kernel scope link src /16 dev eth0 scope link /14 via dev eth0 src /8 dev lo scope link default dev tun0 scope link Das Bild sieht etwas anders als von route gewohnt aus. Administratoren mit langer IP- Erfahrung werden sich schnell zurecht finden und die Vorteile von ip schätzen lernen. Das Setzen einer IP-Adresse auf ein Interface oder das Hinzufügen einer weiteren, durchaus auf dasselbe, geschieht mit: linux02:~ # ip addr add /24 broadcast dev eth0 linux02:~ # ip addr add /24 broadcast dev eth0 linux02:~ # ip addr show eth0 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff inet /24 brd scope global eth0 inet /24 brd scope global eth0

96 86 KAPITEL 6. LINUX IM NETZWERK Die Angabe der Netzwerkmaske ist einigen vielleicht etwas ungewohnt. Statt in der klassischen Form einer IP-Adresse (hier wäre es die ) erfolgt die Beschreibung durch die Zahl der Einsen im Präfix (hier 24). Die (Hardware-)Daten zu einem einzelnen Interface zeigt: linux02:~ # ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff linux02:~ # ip link set eth0 down linux02:~ # ip link set eth0 address 00:20:AA:20:AA:20 linux02:~ # ip link set eth0 mtu 1400 linux02:~ # ip link set eth0 name dsl0 linux03:~ # ip link show dsl0 2: dsl0: <BROADCAST,MULTICAST> mtu 1400 qdisc pfifo_fast qlen 1000 link/ether 00:20:aa:20:aa:20 brd ff:ff:ff:ff:ff:ff Abschalten läßt es sich mit dem darauf folgenden Befehl. Wenn der Admin die MAC-Adresse des Interfaces ändern will, kann er dazu ebenfalls das Subkommando set verwenden. Nur diesmal ist es nicht ein einfaches Flag (down) sondern ein Parameter gefolgt durch einen Wert (die neue Hardwareadresse). Eben dieses gilt für die Reduktion der MTU um 100 Byte oder für das Setzen eines anderen Interface-Namens. Das macht dann Sinn, wenn der Admin Interfaces beispielsweise nach ihrer Funktion kennzeichnen möchte. Anschliessend erfolgt die Anzeige der Konfiguration mit dem neuen Interface-Namen (hier dsl0). Das Interface ist abgeschaltet - zu sehen daran, dass in der Anzeige bei den Flags UP fehlt. In jedem der gezeigten Aufrufe wurde das Interface direkt hinter dem Kommando (set oder show) angegeben. Mit der gesetzten Option -s gibts etwas mehr zu sehen: linux02:~ # ip -s link show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast TX: bytes packets errors dropped carrier collsns Die Statistiken zum Interface kennt man schon von ifconfig. ip zeigt sie in einer Tabelle, was die skriptbasierte Auswertung erleichtert. Mehr Informationen gibt es bei Wiederholung der Option ( -s -s ). Dann schlüsselt ip noch die Art der aufgetretenen Fehler auf. Der ARP-Cache kann mit: linux02:~ # ip neighbor show dev eth0 lladdr 00:10:a4:8d:56:0a nud delay dev eth0 lladdr 00:0f:66:c7:73:e8 nud stale 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.

97 6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE Weitere Tools Das IProute2-Paket enthält einige weitere nützliche Programme. So liefert das Kommando nstat Statistiken des Kernels zum IP-Verkehr. linux02:~ # nstat #kernel IpInReceives IpForwDatagrams IpInUnknownProtos IpInDelivers IpOutRequests IpReasmReqds IpReasmOKs IpFragOKs IcmpInErrors IcmpInDestUnreachs IcmpInTimeExcds IcmpInParmProbs IcmpInEchoReps IcmpInTimestamps IcmpOutErrors IcmpOutTimeExcds IcmpOutTimestamps TcpActiveOpens TcpPassiveOpens [... ] Diese Informationen kennen einige vielleicht schon von der SNMP-Standard-MIB. Letztendlich macht beispielsweise NetSNMP unter Linux nichts anderes, als diese Kernel-Informationen auszulesen. So erhält der Admin Informationen zu empfangenen und gesendetet IP-Paketen (IpInReceives, IpOutRequests), wieviele davon geroutet wurden (IpForwDatagrams), unroutebare Pakete (IpOutNoRoutes). Ebenfalls gibt es Statistiken zum Internet Control Message Protocol (ICMP). ICMP liefert IP-Fehlermeldungen, wenn Netzwerke, Maschinen, höherschichtige Protokolle oder Ports nicht erreichbar sind (IcmpInDestUnreachs). Ping benutzt mit Echo und Reply diesen Dienst für Tests auf Erreichbarkeit von IP-Adressen (IcmpInEchoReps). Weiterhin gibt es Statistiken zu IPv6, UDP und TCP. routel ist ein Shell-Skript und gibt eine ausführliche Kernel-Routing-Table aus. ifstat fasst die Statistiken zu Datenraten der einzelnen Netzwerkinterfaces zu einer Tabelle zusammen: linux02:~ # ifstat ifstat: history is aged out, resetting #kernel Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate lo eth K K K tun K K Der Befehl ss zeigt die aktuell bestehenden TCP-Verbindungen an: linux02:~ # ss State Recv-Q Send-Q Local Address:Port Peer Address:Port

98 88 KAPITEL 6. LINUX IM NETZWERK ESTAB : :ssh ESTAB : :microsoft-ds ESTAB : :ssh Zu weiteren Kommandos und ausführlicheren Beschreibungen sei auf die mitgelieferte Dokumentation oder weiterführende Literatur verwiesen Routing Policy Database Klassisches TCP/IP Routing wertet auf dem Weg eines Paketes nur dessen Zieladresse aus. Erst am Ziel wird im Falle einer Antwort die Quelladresse benutzt. Oftmals ist jedoch Routing auf der Basis von anderen IP-Header Daten wie beispielsweise der Quelladresse, des höherschichtigen Protokolls oder ToS erwünscht. Da sich einzelne Dienste gut an ihren Portnummern untscheiden lassen, soll vielfach auch der nächste Header in Betracht gezogen werden. Der Port steht im TCP oder UDP-Kopf. Diese Art des Routings bezeichnet man als Policy Routing. Viele Admins kennen dieses Konzept bereits von der Einrichtung einer Firewall. In IProute2 wird das Policy Routing durch eine Routing Policy Database (RPDB) und einem Set von Regeln implementiert. Die RPDB besteht aus 255 Tabellen, mit denen IP- Pakete die bestimmten Mustern folgen, geroutet werden können. Die Muster lassen sich mit dem Befehl ip rule und die Routing Tabellen mit ip route manipulieren. Immer eingerichtet sind drei vorkonfigurierte Tabellen local, main und default. Dazu gehören drei Regeln, die bestimmen wann diese Tabellen für das Routing aufgerufen werden sollen. Die Regeln werden in der Reihenfolge ihrer Priorität abgearbeitet. Die Priorität ist der Wert vor dem Doppelpunkt. linux02:~ # ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default In der vorkonfigurierten Einstellung wird für jedes ankommende Paket die Route zuerst in der Tabelle local nachgeschlagen. Falls sie dort nicht steht, werden die Tabellen main und danach default befragt. Mit Hilfe der RPDB lassen sich nun Fragestellungen, wie das Routing in Abhängigkeit von der Absendeadresse oder das Routing mit mehreren Gateways einfach realisieren. Das Routing nach Quelladresse demonstriert das erste Beispiel. Sei ein kleines Firmennetz über zwei Provider an das Internet angeschlossen. Ein Provider bietete eine schnelle Leitung, die jedoch relativ teuer sei. Der andere Provider sei billig, hat aber eine deutliche Verzögerung. Es sollen daher nur Pakete vom Voice-over-IP-Gateway der Beispielfirma (IP-Adresse ) über den schnellen Provider geleitet werden. Alle anderen Pakete nehmen den verzögerten Weg über das Gateway : Alle Maschinen im privaten Subnetz benutzen ein gemeinsames Linux Default-Gateway. Auf diesem Gateway soll anhand der Quelladresse entschieden werden, über welchen Router (das können beispielsweise kleine integrierte DSL/ISDN-Router sein) ein Paket seinen weiteren Weg nimmt. Für dieses Regelset wird zuerst eine neue Tabelle SourceRouting in der Datei /etc/ iproute2/rt tables eingetragen. Hierfür muss eine Regel erstellt werden, die für alle Pakete mit der Quelladresse die Routing Tabelle SourceRouting befragt. linux02:~# echo 100 SourceRouting >> /etc/iproute2/rt_tables linux02:~# ip rule add from table SourceRouting linux02:~# ip rule show

99 6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE2 89 Abbildung 6.1: Default-Gateway mit zwei Wegen zu verschiedenen Routern 0: from all lookup local 32765: from lookup SrcRouting 32766: from all lookup main 32767: from all lookup default Zum Schluss wird noch das schnelle Gateway als Standard Route in die Tabelle Source- Routing eingetragen. Ab dann werden alle Pakete von der IP-Adresse über den schnellen Weg geschickt. linux:~# ip route add default via dev eth0 table SourceRouting Generelle 2-Wege-Routen Das folgende Beispiel befaßt sich wieder mit dem Routing über zwei Gateways. Es können auch mehrere sein, das spielt hier aber keine Rolle. Die Fragestellung ist etwas modifiziert: Wie kann man ausgehenden Verkehr gleichmässig auf beide Strecken verteilen (Load Balancing)? Wie lassen sich Pakete, die über eine Leitung kommen wieder über dieselbe verschickt werden (Split Access)? Wie kann eine Backup-Default-Route definiert werden, die nur bei Ausfall der Default- Route benutzt wird? In einem ersten Schritt legt man zwei neue Routing Tabellen Route1 und Route2 in /etc/iproute2/rt tables an, identisch zum eben beschriebenen Verfahren. Route1 sei dabei die Tabelle für Provider 1 und entsprechend Route2 die für Provider 2. linux02:~# ip route add /28 dev eth0 src table Route1 linux02:~# ip route add default via table Route1 linux02:~# ip route add /25 dev eth1 src table Route2 linux02:~# ip route add default via table Route2 Die Routing Rules legen fest, welche Tabelle für welche IP herangezogen wird.

100 90 KAPITEL 6. LINUX IM NETZWERK Abbildung 6.2: Szenario mit zwei Routen über Provider 1 und 2 linux02:~# ip rule add from table Route1 linux02:~# ip rule add from table Route2 Im folgenden Schritt wird die Main Routing Tabelle für das lokale Routing in beide Netzwerke konfiguriert. linux02:~# ip route add /28 dev eth1 src linux02:~# ip route add /25 dev eth2 src Zum Abschluss wird die Default-Route für die main Routing Table gesetzt. Da der Verkehr gleichmäßig auf beide Anschlüsse verteilt werden soll, muss die Route jetzt als Multipath-Route angelegt sein. Der weight Parameter dient dazu die Verteilung über die einzelnen Verbindungen zu gewichten. Man kann bei Bedarf auch einen Provider stärker als den anderen belasten. linux02:~# ip route add default scope global nexthop via dev eth1 \ weight 1 nexthop via dev eth2 weight 1 Im letzten Beispiel wurden die beiden Default-Routen gleichmäßig oder gewichtet benutzt. Wenn eine immer verwendet werden soll und die andere nur beim Ausfall der ersten den Datenverkehr komplett übernimmt, kann man das über die Angabe einer Metrik 3 regeln. Der Kernel benutzt Gateway immer die Route mit der kleinsten Metrik, solange er sie erreichen kann. Falls diese nicht mehr verfügbar ist, greift er automatisch auf die Route mit der nächstkleineren Priorität zurück. Für das Beispiel soll Gateway als Gateway für eventuelle Ausfälle von Gateway dienen. Für diese Aufgabenstellung genügt es, die Route zum Router 1 mit einer Metrik 1 zu definieren. Die Route zum Backup-Gateway erhält eine höhere Metrik von beispielsweise 5. Die reinen Zahlenwerte sind dabei nicht so interessant. Alle vorherigen Routingeinstellungen sind vorher zu löschen. Das Beispiel nutzt dazu das Kommando flush. Mit der Option -4 legt man fest, dass flush nur auf IPv4-Adressen wirkt. Damit bleiben eventuell vorhandene IPv6-Einträge unberührt. linux02:~# ip -4 addr flush label "eth0" linux02:~# ip route add default via dev eth0 metric 1 linux02:~# ip route add default via dev eth0 metric 5 3 Kosten oder Präferenz einer Route - je kleiner der Wert desto besser

101 6.3. ÜBERPRÜFUNG DER KONFIGURATION Dienste-basiertes Routing Wenn sich Dienste und deren Administratoren an Standards halten, kann man sie anhand ihrer verwendeten Portnummern identifizieren. Die Datei /etc/services listet die Zuordnung von Portnummern zu Diensten auf. ip hat selbst keine Möglichkeit direkt in folgende Header, TCP oder UDP eines Datenpaketes zu schauen. Das können entweder tc oder besser das Netfilter Paket übernehmen. Letzteres ist oft sowieso schon als Firewall im Einsatz. So lassen sich IP-Pakete klassifizieren und ihre Header manipulieren. Man markiert Pakete, die an einen bestimmten Port geschickt werden, mit einer Nummer. Auf Basis dieser werden dann wieder Routing Tabellen erstellt. Das Beispiel sei wie das eingangs beschriebene. Diesmal sollen nur SSH Pakete die schnelle Verbindung passieren und alle anderen den kostengünstigeren Weg nehmen. Als erstes, werden alle ausgehenden SSH-Pakete mit dem Netfilter-Tool iptables durch eine 1 gekennzeichnet. Das Label kann eine beliebige Zahl sein. linux02:~# iptables -A OUTPUT -i eth0 -t mangle -p tcp --dport 22 -j MARK \ --set-mark 1 linux02:~# echo 200 ssh >> /etc/iproute2/rt_tables linux02:~# ip rule add fwmark 1 table ssh linux02:~# ip route add default via dev eth0 table ssh Dann wird wieder eine Regel in der RPDB erstellt, die besagt, dass für alle Pakete, die mit einer 1 markiert sind, die Tabelle ssh befragt wird. Zuletzt muss eine Default Route zur schnellen Verbindung in der Routing Tabelle ssh erzeugt werden. Ab dann gehen alle SSH-Pakete über den schnellen Router Überprüfung der Konfiguration Den Erfolg einer IP-Konfiguration kann man am besten im Netz mit dem Befehl ping testen (das setzt einen weiteren Rechner mit garantiert funktionierender Netzwerkkonfiguration voraus!). ping IP-Adresse/Hostname sendet Datenpakte im Sekundenabstand an die angegebene IP-Adresse oder Rechnernamen 4. Ping 5 kennt einige interessante Kommandoparameter, die sich auch zum Testen der Leistungsfähigkeit eines LAN s eigenen. So lässt sich mit -c Zahl die Anzahl der verschickten Pakete festlegen, -f lässt den Systemadministrator so viele Pakete versenden, wie nur irgendwie geht und mit -s Zahl lässt sich die Paketgrösse, die zum Test verschickt wird, variieren. Meldet ping keinen Erfolg 6, kann man mit dem Kommando tcpdump überprüfen, ob überhaupt Datenpakete auf dem Netzwerkinterface eintreffen und vom Kernel registriert werden. 6.4 Aufgaben IP-Konfiguration und Erreichbarkeit 1. Wie bekommt man folgende Informationen heraus: IP Adresse, Routing Tabelle, eigene MAC-Adresse(n)? 2. Wie lautet die Netzwerkmaske des eigenen Subnetzes und wie kann diese verändert werden? 4 Dieses setzt jedoch einen funktionierenden Nameservice voraus! 5 weitere Informationen kann man sich über den Aufruf der Manualseiten mit man ping anzeigen lassen. 6 das meint eine Meldung wie 100 packet loss

102 92 KAPITEL 6. LINUX IM NETZWERK 3. Warum muss die eigene Netzwerkmaske zu den Einstellungen des Subnetzes passen, in dem man sich befindet? Was passiert, wenn die Maske des Subnetzes kleiner oder größer als die auf der eigenen Maschine eingestellte ist? 4. Man organisiere sich die IP vom Nachbarn und versuche diesen per Ping zu erreichen. Wie erfährt man seine eigene Default-Gateway-Adresse? 5. Wie erfahre ich die MAC-Adressen meiner Kommunikationspartner? Wie lauten die MAC-Adressen für goe.net oder Datenverkehr zählen 1. Welche ganz einfachen Möglichkeiten hat man, um festzustellen, wieviel Datenverkehr von einer Maschine ins Netz geschickt oder empfangen wurde?

103 Kapitel 7 DHCP 7.1 Automatische IP-Zuweisung Administratoren sind für ihren zugewiesenen IP-Bereich selbst zuständig RZ teilt z.b. das Uni Class-B-Netz von / mittels Subnetting in 256 Class-C Netze auf. In diesen Netzen sind bis zu 254 Rechner zu verwalten. Ziel ist die Rezentralisierung der netzwerkseitigen Konfiguration - der Einsatz des DHCP (Dynamic Host Control Protocol) als Netzwerkprotokoll der Anwendungsschicht, mittels dessen grundlegende Daten zur Konfiguration eines Clientsystems übertragen werden können. Dynamic Host Configuration Protocol kann zur automatischen und dynamischen IP- Zuweisung verwendet werden. Damit kann die Konfiguration auf einem zentralen Rechner des Teilnetzes erfolgen (bzw. weitere lassen sich aus Redundanzgründen einfügen). Die Rechner lassen sich fest konfigurieren, aber es kann auch ein Pool von Adressen für wechselnde Hosts verwaltet werden. Damit kann eine weit höhere Anzahl von Maschinen als vorhandene IP-Nummern bedient werden. DHCP verwendet spezielle IP-Nummern (Host ohne IP-Information) und Lokaler Broadcast an alle Teilnetze sind durch Router voneinander abgegrenzt, damit werden Broadcastpakete nur im eigenen Subnetz sichtbar wird nach IP-Bezug sofort wieder frei. 7.2 Implementation DHCP 1, das Dynamic Host Control Protocol stellt eine Erweiterung und Ergänzung des BOOTP dar. Die Einschränkungen im BOOTP einerseits und seine anerkannten Vorteile zur Konfiguration großer Rechnerzahlen andererseits mündeten in der Entwicklung von DHCP. Weiterentwicklungen, wie z.b. dynamisches DNS, finden in erster Linie beim dhcpd statt, die verwendeten bootpd Implementierungen stammen aus den Anfängen der 90er Jahre und werden nur noch im Fall grober Sicherheitsverletzungen gepatcht. Das Internet- Software-Consortium 2 entwickelte eine Beispielimplementation des DHCP und einiger anderer Internetprotokolle. Der Sourcecode liegt in den meisten Fällen auch in einer Linuxanpassung vor, so dass eine einfache Übersetzung für die Zielplattform erfolgen kann. Im 1 Die grundlegenden RFCs für DHCP sind: RFC1541 : Dynamic Host Configuration Protocol, Oktober 1993 RFC2131 : Dynamic Host Configuration Protocol, März 1997 RFC2132 : DHCP Options and BOOTP Vendor Extensions, März siehe dazu [W6], wobei das ISC neben der DHCP-Implementierung weitere Internet-Standards betreut. 93

104 94 KAPITEL 7. DHCP Weiteren bezieht sich daher die Beschreibung auf die DHCP-Implementierung des ISC. Diese liegt inzwischen in der dritten Version vor und unterstützt eine ganze Reihe neuer Eigenschaften, wie die Unterstützung von Dynamischen DNS oder Vendor Code Identifier. 32 bit OP HTYPE HLEN HOPS TRANSACTION IDENTIFIER SECONDS ELAPSED FLAGS CLIENT IP ADDRESS YOUR IP ADDRESS SERVER IP ADDRESS ROUTER IP ADDRESS CLIENT HARDWARE ADDRESS (16 OCTETS).. SERVER HOSTNAME (64 OCTETS).. OPTIONS (VARIABLE).. DHCP Message Format Abbildung 7.1: Aufbau eines DHCP-Paketes DHCP arbeitet auf Port 67 zur Anfrage an den Server und auf Port 68 zur Rückantwort an den Client. Solche Informationen findet man in der /etc/services. Das vorgestellte Protokoll läßt sich nur sinnvoll in broadcastfähigen Netzen 3 einsetzen. Es ist nicht (bzw. nur über den Umweg eines DHCP-Gateway-Servers) routebar. DHCP verwendet als Transportprotokoll UDP, da 3-Wege-Handshake mit den IP-Spezialadressen 4 kaum sinnvoll realisiert werden kann. In den meisten Fällen genügt ein Datenpaket pro Konfigurationsschritt in jede Richtung. DHCP ist eine Erweiterung des Bootp, welches weniger komplex im Leasehandling ist. Es kennt nur statische Adresszuweisungen und weniger vordefinierte Konfigurationsoptionen. DHCP arbeitet im vierstufigen Verfahren bei der Adresszuweisung: Client schickt DHCPDISCOVER an Port 67 um Server zu ermitteln Server schickt einen Vorschlag mit Parametern als DHCPOFFER an Port 68 Client sucht sich aus evtl. mehreren Offers nach bestimmten Kriterien eine passende aus (z.b. nach der Länge der Lease ) und schickt DHCPREQUEST gerichtet an den passenden Server Server bestätigt mit DHCPACK gerichtet an Client 3 Ethernet bzw. TokenRing für den lokalen Broadcast im Netz als Anfrage mit der eigenen IP

105 7.2. IMPLEMENTATION 95 1 Konfiguration festlegen 2 3 Konfiguration annehmen 4 Server DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK Client Beginn der Initialisierung Konfiguration wã hlen Initialisierung abgeschlossen 5 Lease entfernen DHCPRELEASE Sauberes Beenden Abbildung 7.2: Ablauf einer DHCP-Anfrage Server kann ein Request eines Clients ablehnen und ein NAK schicken Wenn der Client ein Problem mit der zugewiesenen Adresse hat, sendet er ein DE- CLINE Der Client kann die erhaltene Adresse vor Ablauf zurückgeben und hierfür ein RE- LEASE senden Der Client kann die erhaltene Adresse vor Ablauf verlängern und hierfür ein RENEW schicken Der DHCP-Server verwaltet den Adresspool und versieht jede Adresse mit der Verleih - Zeit. Er kennt eine Reihe fest definierter Optionen und bei Bedarf können weitere eigene Optionen definiert werden. 5 Im Ethereal-Mitschnitt kann man gut den Aufbau eines DHCP-(Request)-Paketes sehen, wie er schematisch im Bild (DHCP-Paket) gezeigt ist. Das erste Feld gibt den Typ des Paketes an - hier Boot-Request. Die verwendete Hardware ist ein Ethernet, weshalb die MAC-Adressen 6Byte lang sind. Es traten keine Hops auf, da die Aktion im selben LAN stattfand. DHCP arbeitet mit dem verbindungslosen UDP. Deshalb muss es Transaktionen zuordnen können. Hierfür gibt es einen 32 bittigen Identifier. Darauf folgten die verstrichene Zeit und Flags. 5 insgesamt sind 255 Optionen möglich

106 96 KAPITEL 7. DHCP Abbildung 7.3: DHCP-Session unter der Lupe Interessant sind dann wieder die Blöcke der IP-Adressen. Der Client kann eine Adresse von einer noch gültigen Zuweisung besitzen (Client IP). Die vom Server zugewiesene Adresse steht in Your IP. Next Server kann die Adresse des nächsten zu kontaktierenden Servers beispielsweise TFTP enthalten. Sonst steht hier die Adresse des DHCP-Servers. Die Adresse des Relay-Agent enthält die IP des beteiligten Routers, wenn die Anfrage über ein DHCP-Relay zum Server gelangte. Im Beispiel sind alle Adressen leer ( ). Diese Informationen entnimmt der DHCP-Client nicht dem IP-Header. So können Next Server und die Absendeadresse des DHCP-Servers durchaus differieren. Weitere Felder sind für den Serverhostnamen und ein Bootfile (das dann per TFTP geholt werden könnte - nützlich für Diskless Clients) reserviert. Ab dann geht es weiter mit den verschiedenen DHCP-Optionen. Interessant ist vielleicht noch die Option 50 (Requested IP Address). Da der Client schoneinmal eine Lease bezogen hatte, versucht er die gleiche IP-Nummer wieder anzufordern. Das hat den Vorteil, dass die Maschine bestehende IP- Verbindungen nicht durch Adressenwechsel kappt. Die meisten anderen Optionen erklären sich selbst. Eine Liste aller dem ISC-Server bekannten Optionen liefert die Manpage: man dhcp-options. 7.3 DHCP-Server Konfiguriert wird der DHCP-Dämon (dhcpd) mittels /etc/dhcpd.conf. Es stehen etliche weitere Einstellungen zur Verfügung; diese können mit man dhcp-options angezeigt werden. Die DHCP-Konfigurationsdatei hängt in ihrer Ausgestaltung vom verfolgten Einsatzziel ab: So werden für Diskless X-Stations bzw. Linux-Workstations vielleicht eine Reihe zusätz-

107 7.3. DHCP-SERVER 97 licher Daten übertragen, die für den Betrieb von Windowsmaschinen nicht relevant sind. Entsprechende benutzerdefinierte Optionstrings werden eingeführt, um bestimmte Textfelder 6 z.b. zur Konfiguration des X-Servers zu kopieren. Es gibt eine Reihe von Möglichkeiten, um die /etc/dhcpd.conf zu strukturieren. Zusätzlich zum subnet -Statement hilft das group -Statement dabei - neben der Unterteilung nach Subnetzen - Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. So muss nicht für jeden Host die gesamte Palette wiederholt werden. Eine Beispielkonfiguration könnte wie folgt aussehen: option domain-name "subdomain.domain.site second.domain"; filename "/tftpboot/bootimg"; use-host-decl-names on; default-lease-time 72000; max-lease-time ; subnet netmask { option domain-name-servers , ; option ntp-servers ntps1.domain.site, ntps2.domain.site; option font-servers fontserver.domain.site; option x-display-manager x1.domain.site, x2.domain.site; # option netbios-name-servers ; option routers ; option broadcast-address ; # range ; } group { option lpr-servers ; host dxs02 { hardware ethernet 00:00:1C:D2:87:DF; fixed-address ; } [...] DHCP-Standardoptionen DHCP kann aufgrund seiner Flexibilität zum zentralen Konfigurationstool avancieren. Man kann versuchen, über diesen Dienst alle relevanten Informationen zum Betrieb von Linux Thin-Clients zu übertragen. Neben den klassischen Parametern, wie Hostname, IP-Adresse, Netzmaske und Gateway, zählt dazu eine Reihe von Server-IP s: X-Display-, Time-, Swap-, NIS-Server und weitere. Die DHCP-Konfigurationsdatei /etc/dhcpd.conf hängt in ihrem Umfang vom Einsatzziel ab: So werden für Diskless X-Stations vielleicht eine Reihe zusätzlicher Daten, z.b. über Informationen zum Font-, Print-, Swap- und NIS-Server übertragen, die für den X- Terminalbetrieb nicht erforderlich sind. # -- global options -- default-lease-time ; max-lease-time ; use-host-decl-names on; ddns-update-style none; subnet netmask { option broadcast-address ; option domain-name-servers ; option domain-name "test.site, test2.site"; option nis-domain "chnsmi20"; 6 Variablentyp string

108 98 KAPITEL 7. DHCP option nis-servers ; option log-servers ; option netbios-name-servers ; option routers ; # range ; } # -- client specific -- group { host test1 { hardware ethernet 00:80:48:C2:DD:6A; fixed-address ; } host test2 { hardware ethernet 00:E0:4C:39:10:21; fixed-address ; } } Das group Statement hilft hierbei - neben der Unterteilung nach Subnetzen - Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. So muss nicht für jeden Host die gesamte Palette wiederholt werden. Das Beispiel zeigt bereits einige typische Konfigurationsparameter des ISC-DHCP- Servers. Die default-lease-time und max-lease-time sind Ganzzahlwerte, die in Sekunden angeben, wie lange eine herausgegebene Adresse standardmäßig und maximal gültig ist. Dieses spielt besonders eine Rolle in dynamischen Netzen mit potenziell mehr verwalteten Maschinen als vorhandenen IP-Adressen. Mittels use-host-decl-names wird gesteuert, ob der Rechnername anhand des host -Statements übermittelt oder in einer eigenen Option definiert werden soll. Der ddns-update-style bestimmt über die Zusammenarbeit mit dem Domain Name Server. Soll keine stattfinden, weil alle Rechnernamen fest im DNS verankert sind, wird wie im Beispiel none gesetzt. Die meisten DHCP-Optionen sind selbsterklärend. Die komplette Liste aller definierbaren Optionen kann der Manpage zu dhcp-options entnommen werden. Die innerhalb der dhcpd.conf definierten Subnetze müssen innerhalb der gültigen Netzwerkkonfiguration des Servers liegen. Ausserhalb liegende Netze können nicht bedient werden. Innerhalb des subnet -Statements legt die range fest, welche Adressen im definierten Bereich dynamisch verwaltet werden. Der Server merkt sich herausgegebene IP-Adressen in einer gesonderten Datei, den dhcpd.leases, welche sich unterhalb der /var Verzeichnisstruktur in Abhängigkeit der verwendeten Distribution befindet DHCP-DNS-Verbindung Damit der ISC-DHCP-Server dynamische Updates im DNS-Server - es funktioniert nur die Zusammenarbeit mit BIND - vornehmen kann, sind einige Vorbereitungen nötig. In der Zonendefinitionsdatei /etc/named.conf habt man die Möglichkeit dieses zu konfigurieren: acl mynetwork { /24; ; }; [... ] zone "mydomain.site" in { type master; allow-update { WERT; }; file "master/mydomain.site"; }; zone " in-addr.arpa" {

109 7.4. BENUTZERDEFINIERTE OPTIONEN 99 }; type master; file "master/ rev"; allow-update { WERT; }; Dabei kann allow-update verschiedene Werte annehmen: none - keine Updates sind erlaubt Updates sind nur von der Maschine selbst (localhost) gestattet. allowupdate mynetwork; konfiguriert, dass aus dem eingangs definierten Quellen Update- Informationen akzeptiert werden. In der dhcpd.conf sollten mindestens die folgenden globalen Optionen auftauchen: ddns-updates on; ddns-domainname "mydomain.site"; ddns-update-style ad-hoc; allow unknown-clients; [... ] subnet netmask { range dynamic-bootp ; option subnet-mask ; option routers ; allow unknown-clients; } Beide Dienste müssen Sie nach erfolgter Konfiguration neu starten. Im Anschluss können Sie beispielsweise eine Windowsmaschine eine IP-Adresse vom Server beziehen lassen. Dann sieht man im Logfile die Interaktion von DHCP und DNS: [... ] Jan 12 21:05:52 hermes named[16798]: client #33708: updating\ zone mydomain.site/in : adding an RR Jan 12 21:05:52 hermes named[16798]: journal file master/mydomain.site. \ zone.jnl does not exist, creating it Jan 12 21:05:52 hermes dhcpd: if zx-spektrum.mydomain.site IN A rrset \ doesn t exist add zx-spektrum.mydomain.site IN A :\ success. Jan 12 21:05:52 hermes named[16798]: client #33708: updating\ zone in-addr.arpa/IN : deleting an rrset Jan 12 21:05:52 hermes named[16798]: client #33708: updating\ zone in-addr.arpa/IN : adding an RR Jan 12 21:05:52 hermes named[16798]: journal file master/ rev.jnl\ does not exist, creating it [... ] Vielen reicht eine Zugriffssteuerung anhand der IP-Nummer nicht. Diese kann oft zu einfach gefälscht werden. Seit einiger Zeit bietet BIND zur Absicherung sogenannte Transaction Signatures (TSIG). Sie basieren auf einer Einwege-Hashfunktion. Sie werden über die komplette DNS-Nachricht berechnet und als Resource Record an die Nachricht angehängt. 7.4 Benutzerdefinierte Optionen DHCP bietet die Möglichkeit bestimmte, sogenannte Vendoroptionen aufzunehmen, d.h. es können zusätzliche Optionen zu den bereits vorhandenen definiert werden. Hierfür kann der Codenummernbereich von verwendet werden. Wenn man umfangreiche Informationen übertragen will, sollte man die Paketgröße des BOOTP-Reply-Pakets über

110 100 KAPITEL 7. DHCP den Standard 7 hinaus erhöhen. Die Option kann nur Ganzzahlwerte enthalten, die jedoch die MTU-Size des Netzwerkes nicht überschreiten soll, da die meisten Clients keine fragmentierten DHCP-Antworten verarbeiten können. Diese Optionen werden zu Beginn der Konfigurationsdateien 8 des dhcpd bzw. dhclient definiert. Die folgende Liste ist eher als Beispiel denn als vollständige Aufzählung zu verstehen, da für gegebene Aufgaben die notwendigen Felder auch völlig anders aussehen können. # -- lot of information to be transferred -- dhcp-max-message-size 1200; # -- user defined options -- option o128 code 128 = string; option o129 code 129 = string; option menudflts code 160 = string; option motdline1 code 184 = string; option menuline1 code 192 = string; option menuline2 code 193 = string; option menuline3 code 194 = string; Wobei folgende Variablentypen verwendet werden können: string, integer, boolean, text, ipnumber. Diese lassen sich auch zu Arrays zusammenfassen. Das ist das klassische Verfahren, welches für die vordefinierten Optionen für Listen von IP-Nummern zum Einsatz kommt. Die Option 128 definiert ein Magic-Packet, welches die Auswertung von Menu-Optionen für Etherboot einschaltet. Standardwerte für die Menü-Auswahl, d.h. welches Feld nach einem gewissen Timeout gestartet werden soll, werden mit der Option 160 festgelegt. Die Zusammensetzung des Menüs, welches nach dem Kontakt von Etherboot mit dem DHCP- Server angezeigt wird, geschieht durch die Optionen 192 und folgende. Hierbei wird für jede Menü-Zeile ein eigenes Feld benötigt. Mittels der Option 129 sind Parameter zum Kernelstart übermittelbar, die z.b. auch den Root-Verzeichnispfad enthalten. Eine Message of the day 9 kann durch das Setzen der Option 184 erfolgen. 7.5 Die Verwendung von Vendor-Code-Identifiern Vendor-Code-Identifier sind als feste Optionen für DHCP definiert: vendor-class-identifier für die Identifizierung des Clients durch den Server und vendor-encapsulated-options zur Identifizierung des Servers seitens des Clients. Auf diese Weise lassen sich die DHCP-Anfragen verschiedener bootender Rechner voneinander differenzieren, so dass es gelingt an eine Maschine in Abhängigkeit vom anfragenden Client verschiedene Werte für die gleiche Option zurückzuliefern. Dieses ist zwingend notwendig, wenn PXE und Etherboot hintereinander verkettet booten sollen, da PXE zwar die identische IP-Konfiguration erhält, aber anstelle des Kernel-Images das Etherboot-PXE- Image zur Ausführung laden soll. Dieses sieht man am unten stehendem Beispiel: Es werden bestimmte Optionen nur gesetzt bzw. die Default-Option überschrieben, wenn in der Anfrage des Clients ein bestimmter String identifiziert werden kann. Die Interaktion mit PXE und Etherboot mittels VCI ist im folgenden Beispiel demonstriert. # -- vendor identifier dependend settings -- class "Etherboot" { match if substring (option vendor-class-identifier,0,9)="etherboot"; 7 Die Standardgröße des Bootp-Paketes beträgt 572 Byte. Eine Erhöhung auf z.b Byte kann durch dhcp-max-message-size 8üblicherweise 1024 erreicht werden. /etc/dhcpd.conf für den Server-Dämon sowie /etc/dhclient.conf für den Client 9 Hier das Textfeld über der Menu-Auswahl

111 7.6. DHCP-CLIENT 101 option o128 E4:45:74:68:00:00; option motdline1 = "Welcome to Testlabs"; option vendor-encapsulated-options 3c:09:53:74:75:64:69:6e:65:74:7a:ff; } class "PXEClient:" { match if substring (option vendor-class-identifier,0,10)="pxeclient:"; filename "/nfsroot/dxs/boot/eb-3c905c.pxe"; } [...] host dxs03 { hardware ethernet 00:00:B4:72:D2:4E; if substring (option vendor-class-identifier,0,3)="pxe" { filename "/nfsroot/dxs/boot/rtl8139.pxe"; } fixed-address ; } [...] Die class -Statements zeigen globale Definitionen. Es können aber auch hostspezifische Einstellungen getroffen werden, wie das untenstehende Beispiel zeigt. 7.6 DHCP-Client Von schlanken Implementierungen für Embedded Devices mal abgesehen 10 gibt es eigentlich nur eine wesentliche Serverimplementierung. Dafür gibt es aber verschiedene DHCP-Clients. Ein Client ist beim ISC-Paket dabei, das Programm dhclient. Mit den Kommandos dhcpcd, dem DHCP-Client-Daemon, und pump stehen alternative Clients zur Verfügung. Letztere verwendet man, wenn nur eine kleine Anzahl von Standardeinstellungen mittels DHCP vorgenommen werden soll. Im Gegensatz zu dhclient, welches auf ein externes Skript zum Anwenden der DHCP-Netzwerkkonfiguration angewiesen ist, arbeiten die beiden letztgenannten Kommandos direkt auf den betroffenen Dateien, wie z.b. auf der resolv.conf zur Einstellung der DNS-Client-Konfiguration. dhclient verwendet eine eigene Konfigurationsdatei. Die Konfiguration sollte passend zum DHCP-Server erfolgen, wenn mit benutzerdefinierten Optionen gearbeitet wird. Die Einstellungsdatei lautet /etc/dhclient.conf: # /etc/dhclient.conf # send dhcp-max-message-size 1200; send dhcp-lease-time 18000; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; timeout 60; retry 60; reboot 10; select-timeout 5; initial-interval 2; script "/sbin/dhclient-script"; dhclient schreibt, wenn er eine IP-Konfiguration von einem Server erhalten hat, die Daten in die Datei /var/lib/dhcp/dhclient.leases: lease { 10 dnsmasq ist ein solches Programm

112 102 KAPITEL 7. DHCP } interface "eth1"; fixed-address ; option subnet-mask ; option dhcp-lease-time 3600; option dhcp-message-type 5; option domain-name-servers ; option dhcp-server-identifier ; option broadcast-address ; option domain-name "mydomain.site"; renew /12/31 16:31:33; rebind /12/31 17:00:14; expire /12/31 17:07:44; Nachdem dhclient die DHCP-Informationen vom Server bezogen hat, geschieht die Eintragung bzw. Anwendung dieser mittels dhclient-script, welches im Anhang als Shell- Skript beispielhaft angeführt ist. dhclient-script wird von dhclient mittels Temporärskript in /tmp mit allen erhaltenen Variablen gestartet. Diese werden als Shell-Variablen in der aufrufenden Kommandozeile übergeben. Wärend es mit dhclient nicht möglich ist zwei un- Abbildung 7.4: DHCP-Client unter Windows98 abhängige Instanzen für zwei verschiedene Ethernet-Interfaces zu starten, bietet sich dhcpcd ethn 11 für eine solche Betriebsart an. Die Lease-Datei des dhcpcd sieht etwas anders aus. Jedoch finden sich die gleichen Konfigurationsdaten wieder: 11 ethn steht für das Interface auf dem die Anfrage geschickt werden soll, beispielsweise dhcpcd eth1 oder dhcpcd wlan0

113 7.6. DHCP-CLIENT 103 IPADDR= NETMASK= NETWORK= BROADCAST= DOMAIN= mydomain.site DNS= DHCPSID= DHCPGIADDR= DHCPSIADDR= DHCPCHADDR=00:0C:29:5A:B3:E0 DHCPSHADDR=00:50:56:ED:BC:96 DHCPSNAME= LEASETIME=60 RENEWALTIME=720 REBINDTIME=1575 INTERFACE= eth1 CLASSID= Linux default i686 CLIENTID=00:0C:29:5A:B3:E0 Hier können Admins kontrollieren, welche Daten der Client vom Server bezogen hat. dhcpcd kennt eine Reihe von Optionen, die sein Verhalten steuern: Option Bedeutung -d Generieren von Debug-Output -i VCID Schicken eines Vendor Class Identifiers. Andere Möglichkeit Clients anstatt mit der MAC-Adresse auseinanderzuhalten. -k Schicken eines SIGHUP an laufende dhcpcd Prozesse Tabelle 7.1: Optionen zur Steuerung des Verhaltens von dhcpcd Abbildung 7.5: Erneuern einer Lease unter Windows-XP Unter Windows gibt es das grafische Programm winipcfg für Windows 98/ME. Mit dem Klick auf Aktualisieren beschafft sich der Benutzer eine neue Lease vom DHCP-Server. Die Gültigkeit und andere Daten findet man im erweiterten Bereich. ipconfig -renew in der Kommandozeile regelt die dynamische IP-Beschaffung für die professionelleren Systeme, wie Windows2000 und XP.

114 104 KAPITEL 7. DHCP 7.7 DHCP mit LDAP-Backend In sehr großen Netzen ist die Verwaltung von sehr vielen Maschinen in einer einfachen Textdatei (dhcpd.conf) irgendwann nicht mehr zeitgemäß. Es kommt der Wunsch auf alle relevanten Informationen zu den einzelnen Maschinen in einer Datenbank zu verwalten. Das Ganze sollte dann auch noch dynamisch funktionieren: Nach einem Update der Datenbank sollte der DHCP-Server ohne Neustart mit den aktualisierten Informationen arbeiten. Hierzu hat Brian Masney 12 einen Patch für den aktuellen ISC DHCP der Version 3 gebastelt. Dieser ermöglicht eine Integration mit einem LDAP-Server. Die Struktur der DHCP-Konfiguration eignet sich von sich aus gut mit ihren Gruppen- und Subnetz-Abschnitten in einer hierarchischen Datenbank abgebildet zu werden. Der DHCP-Server der aktuellen SuSE-Distributionen ist bereits angepasst, bei Debian Testing oder Unstable Releases muss der Patch noch eingefahren werden. Ob das LDAP- Backend bereits Bestandteil des Servers ist, zeigt das Logfile beim Start: Jan 12 20:47:26 s2 dhcpd: Internet Systems Consortium DHCP Server V3.0.1 [... ] Jan 12 20:47:26 s2 dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file [... ] Um dann Ihren DHCP-Server zur Zusammenarbeit mit LDAP zu motivieren, sind einige Eintragungen in der globalen Sektion der Konfigurationsdatei notwendig. Dafür können dann die subnet, group und host Statements entfallen. Diese Informationen wandern in die Datenbank. ldap-server ; ldap-port 389; ldap-username "cn=dhcpd,ou=users,dc=mydomain,dc=site"; ldap-password "GeheiM"; ldap-base-dn "ou=computers,dc=mydomain,dc=site"; ldap-method dynamic; Die ersten fünf Deklarationen legen den Zugriff auf den LDAP-Server fest. IP-Nummer oder alternativ der Rechnername und die Portnummer sind selbsterklärend. Der ldapusername gibt an, mit welchem Account sich der DHCP-Server an den LDAP-Server bindet. Dieser Account muss über entsprechende Leserechte auf dem ihm zugewiesenen Abschnitt der Datenbank haben. Üblicherweise gehört zum LDAP-Benutzer auch ein Passwort (ldap-passwort). Die ldap-base-dn ist die Basis für Suchanfragen auf dem LDAP-Baum. Dann müssen keine langen Distinguished Names (dn) angegeben werden, sondern der Teil in der Base kann entfallen. Die letzte Option bestimmt mit dem Flag dynamic, dass der DHCP-Server bei jeder Anfrage den LDAP-Server befragt. Steht hier static holt er sich die Informationen genau einmal vom LDAP-Server und kappt dann die Verbindung zu diesem. Der LDAP-Server in der Standard-Konfiguration kennt zwar schon eine Reihe von Objektklassen, für die Daten des DHCP-Servers sind jedoch weitere notwendig, z.b. dhcphost, dhcpdgroup, dhcpoptions, dhcpserver,... Auf die Konfiguration eines LDAP-Servers wird hier nicht weiter eingegangen. Mit LD- AP beschäftigt sich ein eigener Abschnitt des Skriptes. 13 Für das Beispiel existiere bereits 12 masneyb 13 Wenn dieser Teil nicht in der aktuellen Ausgabe enthalten ist, kann dieser über beschafft werden.

115 7.7. DHCP MIT LDAP-BACKEND 105 ein lauffähiger Server, der für den Bereich dc=mydomain, dc=site eingerichtet ist. Ein LDIF zum Bestücken eines LDAP-Servers mit DHCP-Daten könnte so aussehen: # Anlage eines DHCP-Servers im LDAP-Baum dn: dc=myserver, dc=mydomain, dc=site objectclass: top objectclass: dhcpserver cn: myserver.mydomain.site dhcpservicedn: cn=network, dc=myserver, dc=mydomain, dc=site # Definieren eines Knotens "Network" unterhalb dieses Servers dn: cn=network, dc=myserver, dc=mydomain, dc=site cn: Network objectclass: top objectclass: dhcpservice objectclass: dhcpoptions dhcpprimarydn: cn=myserver.mydomain.site, dc=myserver, dc=mydomain, dc=site dhcpoption: domain-name "myserver.mydomain.site mydomain.site" dhcpoption: domain-name-servers , dhcpstatements: default-lease-time dhcpstatements: max-lease-time dhcpstatements: ddns-update-style ad-hoc # Unterhalb des Knotens "Network" Eintrag für das Netz # schaffen dn: cn= , cn=network, dc=myserver, dc=mydomain, dc=site cn: objectclass: top objectclass: dhcpsubnet objectclass: dhcpoptions dhcpnetmask: 24 dhcpoption: routers dhcpoption: subnet-mask # In diesem Netz einzelne Maschinen eintragen: ldaphost1 dn: cn=ldaphost1, cn= , cn=network, dc=myserver, dc=mydomain, dc=site cn: ldaphost1 objectclass: top objectclass: dhcphost dhcphwaddress: ethernet 00:c0:26:31:6a:13 dhcpstatements: fixed-address # In diesem Netz einzelne Maschinen eintragen: ldaphost2 dn: cn=ldaphost2, cn= , cn=network, dc=myserver, dc=mydomain, dc=site cn: ldaphost2 objectclass: top objectclass: dhcphost

116 106 KAPITEL 7. DHCP dhcphwaddress: ethernet 00:c0:26:31:6a:14 dhcpstatements: fixed-address Nach dem Neustart des DHCP-Servers sollte dieser in der Lage sein, die Daten per LDAP zu beziehen. Für die Fehlersuche empfielt es sich die Debug-Level sowohl des LDAP-Servers als auch des dhcpd hoch einzustellen. Aus Sicht des Autors ist die Anbindung des DHCP an LD- AP nicht wirklich optimal. Die Art der Datenbank wird kaum ausgenutzt. So gibt es für alle DHCP-Optionen ein einziges Attribut, welches letztendlich nur eine Zeile der Konfigurationsdatei ohne Semikolon speichert. Wenn in der dhcpd.conf: option domain-name-servers , ; stand, so steht in der LDAP-Datenbank im Attibut dhcpoption : domain-name-servers , In vielen Fällen würde man die Computer gerne in einer einheitlichen Liste unterhalb eines Knotens, beispielsweise ou=computer verwalten 14 und alle DHCP-spezifischen Daten in einem eigenen Knoten halten. Das ist derzeitig nicht möglich. So erfüllt LDAP lediglich die Funktion eines dynamischen Backends, kann aber nicht wirklich seine Stärken zu einer sinnvollen Maschinenverwaltung ausspielen. 7.8 Aufgaben DHCP 1) Worin besteht der Vorteil von DHCP gegenüber BOOTP? Nennen Sie einige Eigenschaften des ISC DHCPv3! 2) Bauen Sie einen DHCP-Server auf, der IP-Adressen dynamisch vergibt! a) Wie sieht der entsprechende Eintrag in der /etc/dhcpd.conf aus? b) Warum bekommt ein Rechner häufig dieselbe IP zugeteilt, die dieser schon einmal hatte? Wo werden diese Informationen abgelegt? c) Client-Seite: Verändern Sie die MAC-Adresse Ihrer Netzwerkkarte (Tip: ifconfig ethx hw ether 00:00:B4:34:35:XY, wobei X, Y Hexadezimalzahlen sein sollten, die sich von der Wahl der anderen Kursteilnehmer unterscheiden.) und starten Sie den Dienst zum dynamischen Bezug von IP-Nummern neu. Warum bekommen Sie nun eine andere IP als vorher zugeteilt? 3) Wenn man sehr viele Daten (z.b. eine grosse Reihe von Server-IP-Nummern) übergeben möchte, könnte der Platz im DHCP-Antwort-Paket nicht mehr ausreichen. Wäre es sinnvoll deshalb TCP statt UDP einzusetzen, um eine gesicherte Übertragung mehrerer Pakete zu erreichen? Welche anderen Möglichkeiten gibt es noch? 4) Nennen Sie verschiedene Hierarchielevel der definierten Optionen! Welche Level überschreiben welche? Wozu kann dieses nützlich sein? 14 Siehe das Beispiel Samba-LDAP für PDC

117 Kapitel 8 DNS 8.1 Einstieg Das Domain Name System (DNS) hatte es zu Zeiten des Internet-Booms bis in die Hauptnachrichten geschafft: Immer dann, wenn es juristische Auseinandersetzungen über bekannte Namen und Marken gab. Wenn jemand im Internet was zu Göttingen sucht, probiert er es am besten unter dem Namen der Stadt, also Keiner kennt die IP-Adresse des Auftritts Auch wenn es an der gerichtlichen Front ruhiger geworden ist, kommen täglich neue Domains hinzu. Viele haben sich vielleicht schon vor einiger Zeit eine eigene Webpräsenz mit eigenem Namen bei irgendeinem Provider einrichten lassen oder denken darüber nach eine Domain zu registrieren. Man frage einfach mal im eigenen Umfeld herum - bestimmt finden sich Bekannte und Verwandte als Inhaber einer Internet-Domain. Ebenfalls erweitert sich die Zahl der sogenannten Toplevel-Domains ständig. So ist die Landes-Toplevel-Domain de die weltweit zweitgrößte nach der generischen Domain com. Irgendjemand muss diese ganzen Namen auch verwalten. Darum kümmert sich der Domain Name Server. Auch für diese Aufgabe bietet sich Linux an Enstehungsgeschichte DNS ist inzwischen untrennbar mit dem Internet verknüpft. Rechner im weltweiten Internet werden in der überwiegenden Zahl über ihren Namen und nicht über ihre IP-Adresse angesprochen. Es ist jedoch so, dass das Internet-Protokoll ohne Probleme ohne DNS klarkommt, DNS jedoch als Dienst direkt auf IP angewiesen ist. Menschen können sich schliesslich Namen besser merken als Telefonnummern. Wenn auch das Beispiel sich nicht direkt übertragen lässt, zeigt es die Bedeutung. Jeder kennt Kaum aber jemand weiss, dass beim Ansurfen der Seite aus Deutschland 1 der Browser eine Verbindung zu IP oder 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 is an alias for is an alias for has address has address Das Netz kann aber ausschliesslich mit Binäradressen umgehen - auch die besser lesbare Dotted Quad Notation aus dem Beispiel ist nur eine Übersetzung für den menschlichen 1 je nach Provider, da es oft erstmal ein Proxy ist 107

118 108 KAPITEL 8. DNS Benutzer. Deshalb wird ein System für die Zuordnung von Namen zu Adressen - und umgekehrt benötigt. Am Anfang ging es mit einer einfachen Textdatei los. Diese Textdatei gibt es immer noch. In kleinen Netzen oder zu Zeiten in denen Ihre Maschine keine Netzwerkverbindung zu einem DNS-Server hat, soll sie trotzdem Namen und IPs zuordnen können: # /etc/hosts # Syntax: # IP-Address Full-Qualified-Hostname Short-HostnamePv6 addresses ::1 ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters localhost dionysos.mydomain.site dionysos # resolv other machines without DNS aphrodite.wg.site aphrodite athene.wg.site athene [... ] thetis.wg.site thetis Üblicherweise steht da nur noch die eigene Maschine drin, im Beispiel dionysos. Diese Einstellung landet in dieser Datei, wenn man die Maschine mit dem Installationstool der gerade verwendeten Distribution einrichtet Alle anderen Einträge gelten für spezielle Adressen, wie das lokale Loopback ( ). In einem kleinen Netzwerk, in dem sich wenig ändert, könnte man einfach weitere Rechner in diese Datei eintragen und diese anschliessend auf alle Maschinen verteilen. Im Beispiel lassen sich so aphrodite, athene... ohne Zurhilfenahme von DNS auflösen. Da gehen dann schnell die Probleme los: Nicht immer sind alle Rechner gleichzeitig an. Dann ist die Verteilung unvollständig. Bei häufigen Updates steigt mit der Zahl der Rechner und der Einträge die Fehlerwahrscheinlichkeit und ziemlich schnell hat der Admin keine Lust mehr. Das ging den Betreibern der frühen IP-Netze genau so. Das frühe Internet bestand aus wenigen Hosts und die Administratoren dieser Maschinen kannten sich alle persönlich. Das hörte mit der steigenden Zahl vernetzter Rechner irgendwann auf. Das Konzept einer einzigen flachen Datei liess nicht mehr aufrecht erhalten. Fragen der Übersichtlichkeit, Ausfallsicherheit und Redundanz liessen sich mit dem Dateikonzept nicht überzeugend lösen. Ein weiteres Problem tritt auf, wenn die User in gewissem Rahmen ihre Rechnernamen selbst verwalten wollen. Informatiker an der University of California in Berkeley machten sich Gedanken, wie sich das Problem lösen liesse. Das neue System sollte dabei dezentral verteilt, ausfallsicher sein und die Datenbestände schnell konvergieren. Die Berkeley Internet Name Domain Software - daher der Name BIND - ist der Standard auf den meisten Linux-/Unix-Systemen. Die Software ist OpenSource und derzeit in der Version 9.X verfügbar. Die aktuelle Version verrät einem das Kommando /usr/sbin/named -v. DNS war nicht der einzige Versuch. Viele Admins kennen sicherlich WIN, das Windows Name System. Dieses kann im P2P- oder Servermodus arbeiten, kennt aber nur eine flache Namenshierarchie, welche in früheren Versionen auf 255 Maschinen beschränkt war. WINS ist ein System für LANs - ohne große Benutzereingriffe verständigen sich die beteiligten Maschinen über ihre Namen. Sie verursachen dabei aber einen nicht unerheblichen

119 8.1. EINSTIEG 109 Netzwerkverkehr. Mit Windows2000 und dem Active Directory, welches als unterliegende Struktur DNS verwendet, verliert WINS weiter an Bedeutung DNS - Das virtuelle IP-Telefonbuch DNS ist ein hierarchisches System mit einer einzigen gemeinsamen Wurzel. Diese wird durch einen Punkt. symbolisiert. Dann folgen die sogenannten Toplevel-Domains. Hiervon gibt es zwei Typen: generische Domains und Länderkürzel. Die generischen Toplevel Domains, wie org, gov, com, mil, arpa und edu wurden schon im Herbst 1984 vorgeschlagen. net folgte ein Jahr später. Hinzu kamen auf dem obersten Level die zweibuchstabigen Länderkürzel nach ISO Eine vollständige Liste ist unter [1] erhältlich. Unterhalb dieser Hierarchiestufe kann man selbst, Organisationen oder Firmen Domains registrieren. Ab den folgenden Hierarchiestufen habt der Admin dann fast volle Freiheit, wenn er sich nur an die Benennungsstandards hält. Das Konzept des umgekehrten hierarchischen Baumes kennt man von den gängigen Dateisystemen her. Verfolgt man einen Pfad von Wurzel zu einem Knoten, so ergibt sich der jeweilige Verzeichnis- bzw. Dateinamen. Die einzelnen Ebenen werden beispielsweise bei Unix durch einen Schrägstrich (/), durch einen Backslash () bei Windows voneinander getrennt. Diese Struktur findet sich in weiteren Bereichen. Telefonnummern folgen international einem ähnlichen Prinzip: Zuerst findet man den Ländercode (+49), dann die Orts-Vorwahl (551) und schliesslich die Anschlussnummer (654321). Genauso setzt sich der komplette Rechnername 2 aus mehreren Teilen zusammen. Ausser dass als Trennelement der einzelnen Ebenen der Punkt (.) verwendet wird. Anders als in den beiden vorgenannten Beispielen dreht sich die Reihenfolge von Allgemein zu Speziell um: Der Rechnername steht links, gefolgt von den Zwischenebenen bis zur Wurzel, die rechts steht. So ist beispielsweise in www ein Name für einen konkreten Rechner. Dieser Rechner ist Mitglied in der Second-Level-Domain goe, die unterhalb der Toplevel-Domain net registriert wurde Regeln für die Namensgebung Damit am Ende die selbstgetauften Rechner der eigenen Domain im weltweiten Netz auch gefunden werden können, geht es nicht ohne Standards ab. Für die Zusammensetzung eines gültigen FQDN gelten einige Regeln: Jeder Teilname (label) umfasst maximal 63 Zeichen. Es muss mindestens ein Buchstabe enthalten sein, damit ein Verwechseln mit IP-Adressen ausgeschlossen wird. Die Gesamtlänge des FQDN darf 255 Zeichen inklusive der Punkte nicht überschreiten. Erlaubt sind die alphanumerischen Zeichen 0-9 und a-z. Groß- und Kleinschreibung spielt keine Rolle. Zusätzlich möglich ist die Verwendung des Bindestrichs -. Er kann im Gegensatz zu den anderen Zeichen nicht am Anfang oder Ende eines Namens stehen. Inzwischen sind auch Umlaute im Namen erlaubt. Hierfür gelten jedoch spezielle Regeln. Jeder FQDN endet mit einem Punkt. Das macht normalerweise keiner und ist ausserhalb der Zonendateien des BIND auch kein Problem. 2 in der Fachsprache mit FQDN - Full Qualified Domain Name bezeichnet

120 110 KAPITEL 8. DNS Für Umlautdomains, sogenannte International Domain Names (IDN) wird die sogenannte ACE-Umschrift verwendet. Anwender geben in ihrem Browser beispielsweise jörg.hänßler.de ein. Diesen String wandelt der Browser dann intern in ACE für die Abfrage an den Nameserver um. Das Ergebnis des Beispiels sieht dann so aus xn jrg-sna.xn hnssler-5wa.de. Viele Web-Browser beherrschen inzwischen den Umgang mit IDN, viele andere Client- Programme jedoch nicht. So liefert zwar ein Ergebnis im Konqueror, ein ping jedoch nur ein lapidares unknown host Ein ping auf die ACE-Umschrift (hier mller-kva.de) klappt natürlich. Die Längenbegrenzung des Teilstrings bleibt bestehen. So können Umlautdomains nicht die Länge von 63 Zeichen erreichen, da noch Platz für die Umschrift einzuplanen ist. Für nicht öffentliche Netze ist man nicht zwangsläufig an vorgegebene Toplevel-Domains gebunden, man kann sich einfach eine aussuchen. Wenn man jedoch für sein privates Netz einfach eine offizielle Domain wählt, wie beispielsweise testnetz.de, dann könnten Nutzer verwirrt werden. Sie würden dann unter Umständen versucht sein, diese Domain auch von anderen Orten als dem eigenen privaten nach aussen abgeschotteten Netz zu erreichen. Ein Name, wie hermes.wg.site macht durch den Toplevel.site klar, dass es diese Domain nicht offiziell gibt. Bis vor einiger Zeit war stattdessen die Pseudo-Toplevel-Domain.local Quasistandard. Sie ist aber für selbstkonfigurierende lokale Netze 3 gedacht Registrieren und Verwalten von Domains country generic Toplevel 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 Ausde fr uk net mil org com edu Second Level gwdg Domains uni-freiburg goe kernel google ftp www www ftp www linux www ftp ks Part of Domain Name Space www Abbildung 8.1: Ausschnitt aus dem Namensraum schnitt aus dem DNS-Namensraum des Internets. Neben den ursprünglich festgelegten dreibuchstabigen generischen Toplevel-Domains und den Länderkürzeln sind in jüngster Zeit weitere Domain-Endungen hinzugekommen. Durch die Moderation von ICANN wurden weitere Toplevel-Domains vorgeschlagen: aero, biz, coop, info, museum, name, pro oder eu. Unterhalb dieser neuen Toplevel-Domains können zum Teil schon (mindestens info, biz, name) Domains über verschiedene Registrare eingetragen werden. 3 Apple nennt diesen Dienst Rendevouz. Unter Linux gibt es dafür den mdnsd Dienst, der dynamisches DNS in lokalen Netzen bereitstellt.

121 8.2. IMPLEMENTATION 111 Für die einzelnen Toplevel-Domains ist nicht eine Organisation oder Firma zuständig. Für die Toplevel-Domain de regelt dieses DENIC. Sie ist eine eingetragene Genossenschaft. In ihr sind beispielsweise große Internet-Service-Provider und Diensteanbieter Mitglied. Diese können im Auftrag ihrer Kunden Domains registrieren. Die Informationen wem eine Domain gehört, wer für den Betrieb des Nameservers dieser Domain zuständig ist und weitere Daten sind in der sogenannten whois-datenbank gespeichert. Früher liessen sich diese Informationen per Kommandozeilen-Tool direkt abfragen, nun geht es nur noch über die Webschnittstellen der Registrare oder auch direkt bei Domain-Inhaber, administrativer oder technischer Ansprechpartner und Zonenverwalter können durchaus verschiedene Personen sein. Die meisten Registrare stellen zwei Möglichkeiten zur Verfügung eine Domain zu konnektieren, d.h. im Internet erreichbar zu machen. Der übliche Weg ist die Delegation. Das bedeutet, dass in den DENIC-Datenbanken die Adressen von mindestens zwei (maximal fünf) Nameservern vermerkt werden. Üblicherweise stellen die Registrare bei der Ersteintragung von Nameservern sicher, dass diese funktionieren. Die Daten des zugehörigen SOA-Records (SOA=Start Of Authority) des Nameservers sollten ich deshalb in folgendem Spektrum bewegen (Angaben in Sekunden): Eine alternative Möglichkeit eine Domain Variable Geforderte Zeiten in Sekunden refresh retry expire ttl Tabelle 8.1: Einstellungen im SOA zu konnektieren besteht darin, dass auf dem Nameserver des Registrars ein bis zu einige Dienste, die mit dieser Domain zusammenhängen direkt eingetragen werden. So können beispielsweise www. Name der Domain.de oder ftp. Name der Domain.de direkt mit einer IP-Adresse registriert werden. Dieses Verfahren wird als Konnektierung mittels NSentry- Einträgen bezeichnet. Das spart den eigenen Nameserver und macht bei kleinen Domains mit wenigen Diensten Sinn. 8.2 Implementation Ein Nameserver ist niemals für das gesamte Internet verantwortlich, sondern verwaltet lediglich einen Teil des Namensraumes. Bevor es jedoch um die Frage geht, welcher Nameserver sich um welchen Bereich des Namensraumes kümmert, sind einige Begriffe zu klären. Bisher kam der Ausdruck Domain, deutsch Domäne schon häufiger vor. Diesen sollte man nicht mit einer (Windows-)NT-Domäne verwechseln. Eine solche fasst auch Gruppen von Rechnern organisatorisch zusammen. Es stecken jedoch komplett andere Prinzipien hinter einer DNS- oder Windows-Domain Nameserver und Zuständigkeiten Bezogen auf den DNS-Namensraum ist ein Domain ein Knoten des Baumes mit allen darunter folgenden Verzweigungen. So sind die Maschinen ftp.uni-freiburg.de und Teile der Domain uni-freiburg.de. Die Rechner mit der gemeinsamen Domain können, müssen aber nicht in einem gemeinsamen IP-Subnetz liegen. Sie haben auch sonst nicht viel gemein oder müssen in irgendeiner weitergehenden Beziehung zueinander stehen.

122 112 KAPITEL 8. DNS Im Beispiel stehen der Rechner ftp.uni-freiburg.de und die Subdomain ks.uni-freiburg.de auf einer Hierarchiestufe. Unterhalb von ks können wiederum Rechner (im Beispiel www ) eingetragen sein oder weitere Subdomains folgen. Der Begriff Domian ist eine Frage der Organisation: Welche Hosts beinhaltet die DNS-Domain D? oder Unter welcher Domain ist die Person P oder Organisation O erreichbar? Ist man nun für eine solche Domain zuständig oder deren Eigentümer, betreibt man einen Nameserver. In diesem kann man dann beliebige Rechnernamen eintragen oder Sub- Domains festlegen. So ist ks.uni-freiburg.de eine Subdomain von uni-freiburg.de. Wenn man sich diese Organisation näher anschaut, stellt man fest, dass die Domainnames hierarchisch aufgebaut sind. Trotzdem ist nur ein Nameserver für diese Domain verantwortlich. Dieser Nameserver ist autoritativ. Die bis zu vier weiteren Nameserver, die man bei der Registrierung angeben kann, erfüllen Backup- und Redundanzfunktionen. Ein zentrales Konzept des DNS ist die Delegation. Die hierarchische Struktur des DNS erlaubt die Verteilung von Informationen. Das hat einige Vorteile: Die Daten werden an den Stellen gepflegt, wo sie bekannt sind. Oft kommunizieren in lokalen Netzen gerade die lokalen Maschinen direkt miteinander. Namensanfragen können direkt vor Ort mit kürzester Verzögerung beantwortet werden. Durch Delegation wird die Autorität für Subdomains auf andere Nameserver übertragen. Das passiert bei der Registrierung einer DE-Domain beim DENIC, wenn man eigene Nameserver angibt. Die neu eingetragene Domain ist eine Subdomain von DE. Bei der Delegation kann der Administrator entscheiden, welche Bereiche seiner Domain auf andere Nameserver übertragen werden sollen. In solchen Fällen spricht man von Zonen. Eine Zone ist allein durch Delegation definiert. Dieser Begriff bezeichnet deshalb meist die physikalischen Realisierung. An der Universität Freiburg ist beispielsweise die Subdomain informatik.uni-freiburg.de an einen eigenen Nameserver delegiert. Alles innerhalb dieser Subdomain bildet eine eigene Zone. Die Subdomain ks.uni-freiburg.de wird auf dem zentralen Nameserver der Domain uni-freiburg.de verwaltet. ks ist also Bestandteil der Zone uni-freiburg.de. Die Nameserver der Domain uni-freiburg.de wissen um ihre Schäfchen oder kennen jemanden, der um Teilmengen weiss (delegierte Subdomains). Was ist aber, wenn ganz allgemein irgendeine Domain aufgelöst werden soll? Die oberste Ebene bei den Nameservern bilden die sogenannten Root-Nameserver. Sie sind gleichzeitig autoritativ für die Top Level Domains. Diese kennen wiederum die verantwortlichen Nameserver für die zweite Ebene, z.b. goe.net oder uni-goettingen.de. Soll ein beliebiger Hostnamen aufgelöst werden, kommt einer der Root-Nameserver ins Spiel. Nur dieser kennt den autoritativen Nameserver der Second-Level Ebene. Die Erreichbarkeit der Root-Nameserver ist zentrales Element des DNS. Ein Ausfall dieser zentralen Maschinen hätte katastrophale Auswirkungen auf die Funktion des Internets. Diese mag dann zwar immer noch wie vorher funktionieren. Aber in dem Augenblick, wo IP-Adressen nicht mehr von Namen ermittelt werden können, ist die Kommunikation schnell nicht mehr möglich. Deshalb werden Root-Nameserver durch Caching entlastet und arbeiten ausschliesslich iterativ. Bisher ging es immer um die Auflösung von Namen zu IP-Adressen. Im Beispiel oben wurde auch schon kurz der umgekehrte Fall angesprochen. Was macht man aber, wenn man die IP-Adresse kennt und den zugehörigen Hostnamen oder die Domain wissen möchte? IP-Adressen in der dotted-quad-notation, also sowas wie ähneln sich vom Aufbau her den Domainnames. Das gilt ebenfalls für eine gewisse Hierarchie (solange die Subnetzaufteilung entlang der Punkte erfolgt) der IP-Adressen: ist als IP-Netz an die Universität Göttingen zugewiesen. Innerhalb dieses Netzes lassen sich beispielsweise Subnetze der Form festlegen. Das wird einfach dazu benutzt auch für die umgekehrte Auflösung das Konzept der hier-

123 8.3. DNS-SERVER MIT LINUX 113 archischen Datenbank und Delegation zu nutzen. Es stößt aber schneller an seine Grenzen in dem Augenblick, wo ein Netz der Form / in mehrere Teilnetze aufgeteilt werden soll, die unterschiedlichen Subdomains zugeordnet sind Caching Nameserver können selbstständig Anfragen weiterleiten, falls sie nicht selbst für die nachgefragte Zone autoritativ sind. Trotzdem ist es in den meisten Fällen ineffektiv, wenn bei gleichen Anfragen jedes Mal eine Weiterleitung erfolgt. Deshalb speichert der Server Namensauflösungen für eine gewisse Zeit zwischen (Caching). Die Aufbewahrungsdauer für einen Eintrag ist jedoch nicht trivial zu bestimmen. Es gibt Server deren IP-Adressen sich jahrelang nicht ändern. Es gibt aber auch Maschinen, die beispielsweise per DHCP eine dynamische Adresse beziehen und nur für eine gewisse (kurze) Zeit aktiv sind. Oder Site-Betreiber nutzen DNS zur Lastverteilung verschiedene Server und reichen deshalb verschiedene IPs für dieselbe Adresse heraus 4. Wie lange dieser Eintrag beibehalten werden soll, legt der verantwortliche Serverbetreiber der Zone mit der Time-To-Live (TTL) fest. Welche Möglichkeiten einem hier zur Verfügung stehen, klärt der Abschnitt zur Einrichtung eines BIND DNS-Servers. Darüber hinaus merkt sich der anfragende Server den autoritativen Nameserver für die jeweiligen Zonen. So vermeidet er, dass bei der Auflösung nicht alle Instanzen der Hierarchie durchlaufen werden müssen. Das hat den Vorteil bei unterschiedlichen Hosts der gleichen Zone sofort der verantwortlichen Server zu kennen. DNS kennt auch negatives Caching: In diesem Fall werden nicht existierende FQDN für einen bestimmten Zeitraum gemerkt, damit nicht jedes Mal auf ein Timeout gewartet werden muss - diese Zeit wird allerdings vom ursprünglich befragten Nameserver selbst vorgegeben Primärer und sekundäre Nameserver Beim Entwurf von DNS wurde sehr viel Wert auf Ausfallsicherheit gelegt. Aus diesem Grund ist es üblich, statt eines einzigen gleich mehrere Nameserver für eine Zone zu betreiben. Sekundäre Nameserver werden bei Änderungen der Zonendaten durch den primären benachrichtigt. Sie holen sich dann die aktuellen Zoneninformationen (Zonentransfer). Generell gilt: Es gibt immer nur ein primärer aber bis zu vier sekundäre Nameserver. Heute haben sich allerdings für den primären Master-Nameserver die Bezeichnung Master und für die sekundären Master-Nameserver die Bezeichnung Slaves durchgesetzt. Slave klingt etwas nachgeordnet. Trotzdem verbirgt sich hinter dieser Bezeichnung ein vollwertiger Nameserver. Da ein einzelner physikalischer Nameserver sowohl Master als auch Slave für unterschiedliche Zonen sein kann, ist diese Unterscheidung nicht immer eindeutig. 8.3 DNS-Server mit Linux Nameserver gehören zu den wichtigsten Diensten des Internets. Anders als Webserver agieren sie jedoch im Hintergrund. Wer irgendwelche Dienste im Netz anbietet, ist nicht nur darauf angewiesen, dass der Webauftritt attraktiv gestaltet ist und die Wartezeiten kurz sind, sondern auch, dass der Server überhaupt gefunden wird. Damit ist nicht der Eintrag in Suchmaschinen gemeint, sondern die Auflösung des Domain-Namens in eine IP-Adresse. Für eine ganze Reihe von Anwendungen, wie Mail ist auch die umgekehrte Auflögung von einer IP zu einem FQDN erwünscht. 4 siehe das Eingangsbeispiel für google.de

124 114 KAPITEL 8. DNS Ein Großteil der weltweiten DNS-Server laufen inzwischen auf einer Kombination von Linux und BIND. Bind9 besteht aus mehreren Paketen und ist für alle aktuellen Linux- Distributionen verfügbar Der Dämon Üblicherweise wird für den DNS der Bind verwendet. Der Dienst, der später als Daemon im Hintergrund läuft heisst named. Das dazugehörige Startskript /etc/init.d/bind9 unter Debian und /etc/init.d/named für anderen Distributionen. Oft findet man noch weitere Dateien im Sysconfig- oder Defaultsverzeichnis, die das Verhalten des Daemons steuern, ihn beispielsweise mit einer anderen UserID als root starten. Konfiguriert wird der named durch die /etc/named.conf bzw. /etc/bind/named.conf. Im folgenden bezieht sich die Beschreibung auf eine Debian-Installation. 5 named.conf ist die zentrale Konfiguration zum Verhalten des Servers und der Definition der verschiedenen Master- und Slave-Zonen. Die Server-Optionen sind für die bessere Übersichtlichkeit in eine weitere Datei named.conf.options oder ähnliche ausgelagert. In dieser Datei kann man beispielsweise die Forwarder definieren und ACLs für den Zugriff auf den Server festlegen. Auf diese Weise legt beispielsweise das Keyword listen-on für das üblicherweise benutzte IPv4 fest, auf welchem Port und auf welchen IP-Adressen der Server auf Anfragen lauscht. So läßt verhindern, dass ein lediglich interner Server, der auf einem Gateway läuft auch für externe Anfragen offen ist. So können Angreifer nicht per DNS erfahren, wie das interne Netz strukturiert sein könnte. Statt der Angaben von IP-Adressen oder Netzen lassen sich vor dem options -Block auch Access Control Lists (ACLs) definieren: acl localnet /24; /24; ; Diese trägt man dann direkt ein: listen-on port 53 localnet; ; Das Keyword listen-on-v6 regelt das Ganze für IPv6. forwarders definiert eine Liste von Servern, an die Anfragen weitergeleitet werden, wenn der Server diese nicht selbst beantworten kann. So kann man vom Cache Ihres Internetproviders profitieren. Normalerweise sucht ein Nameserver das Internet rekursiv ab, bis er die gesuchte Antwort findet. Durch diese Option wird stets der Nameserver Ihres Internetproviders zuerst befragt. Wenn es sich dabei um einen schnellen, viel benutzten Nameserver handelt, kann dies zu einer Geschwindigkeitssteigerung führen. ; /etc/bind/named.conf include "/etc/bind/named.conf.options"; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; 5 Andere Distributionen legen die Konfigurationsdateien und Daten oft woanders ab, beispielsweise unterhalb von /var/lib/named. Wenn man sich an der named.conf orientiert, findet man alle weiteren Dateien schnell, weshalb in der Darstellung nicht weiter auf Spezialitäten einzelner Distributionen eingegangen wird.

125 8.3. DNS-SERVER MIT LINUX 115 }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; include "/etc/bind/named.conf.local"; In der named.conf sind eine Reihe spezieller Zonen bereits definiert. So enthält die Datei db.root die Liste aller 16 Root-Nameserver. Ein Großteil dieser Maschinen steht in den USA, einige in Europa und eine Maschine in Japan. Ihre IP-Adressen sind fix. Diese Server werden iterativ befragt, wenn der eigene DNS eine Adresse nicht auflösen kann. Die Zone. ist deshalb vom Typ hint - der Nameserver ist für diese Zone nicht authoritativ, erfährt hier aber, wo er weiterfragen kann. Weiterhin gibt es einige spezielle Zonen, wie localhost oder 127.in-addr.arpa. Für diese Zonen ist ein Server immer authoritativ. Das verhindert, dass von schlecht konfigurierten Maschinen Anfragen auf einen Namen wie localhost oder eine IP aus / überhaupt ins Netz gelangen. Jeder Rechner mit installiertem IP-Stack hat auf dem Loopback-Interface üblicherweise die IP-Adresse definiert. Auch mit solchen Anfragen sollten keine entfernten Nameserver behelligt werden. Das gilt ebenfalls für IP-Adressen, die mit einer 0 6 und mit 255 beginnen. So fangen die lokale Broadcast-Adresse oder die meisten Netzmasken an. Alle diese speziellen Zonenfiles werden bei der Installation automatisch angelegt. Die eigenen Zonen definieren Sie der Übersichtlichkeit halber am besten in der Datei /etc/bind/named.conf.local oder dem Konzept der gewählten Distribution entsprechend Die DNS-Datenbank Es gibt zwei Arten von Zonen: Für die Master-Zonen ist der Server authoritativ, die Slave- Zonen kopiert er definiert durch die Update-Festsetzungen vom für die Zone authoritativen Server. zone "wg.site" in { type master; file "/etc/bind/db.wg.site"; allow-update { ; ; }; }; zone " in-addr.arpa" in { type master; file "/etc/bind/db "; allow-update { ; ; }; }; Die DNS-Datenbanken enthalten recht unterschiedliche Einträge: Zum einen muss eine Auflösung von FQDN in Richtung IP-Adressen und umgekehrt möglich sein, weiterhin sollten Informationen zu Nameservern vermerkt sein. Unter Umständen legt man ebenfalls Zonenfiles für die Rückwärtsauflösung von IPv6-Adressen und Telefonnummern nach ENUM an. Die Informationseinheit in einer DNS-Datenbank wird Resource Record (RR) genannt. Zu jedem Eintrag korrespondiert ein Typ, der die Art der enthaltenen Daten beschreibt, und eine Klasse, die den Netzwerktyp beschreibt, für den der Record gilt. Der Prototyp eines RR ist der A-Record, bei dem ein voll qualifizierter Domainname mit einer IP-Adresse assoziiert ist ist eine spezielle Adresse zur DHCP-Anfrage

126 116 KAPITEL 8. DNS Wie bereits erwähnt wurde, ist es möglich einem Host mehr als einen Namen zuzuordnen (Aliasing). Einer dieser Namen ist der offizielle Hostname, während alle weiteren nur Aliase sind, die mit dem offiziellen Namen verknüpft werden. Der Unterschied in der Eintragung liegt in der Bezeichnung: Der kanonische Hostname besitzt einen A-Record, während die anderen nur einen Record vom Typ CNAME verwenden. Ein Beispieleintrag für die Auflösung von Hostnamen nach IP-Nummern: ; /etc/bind/wg.site $TTL 360 ; 6 IN SOA ns.wg.site. dirk.wg.site. ( ; serial ; refresh (8 hours) 1800 ; retry (30 minutes) ; expire (5 weeks 6 days \ 16 hours) ; minimum (1 day) ) IN NS ns.wg.site. IN MX 10 mail.wg.site. IN MX 20 mail-backup.wg.site. ns IN A nameserver IN CNAME ns $TTL ; 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 "AMD Opteron" "Linux" IN TXT "WG-DNS for PE28" In den Zonendateien ist jeder mit einem Punkt. endende Rechnername ein exakter Rechnername. Alles, was ohne den abschließenden Punkt geschrieben wird, bezieht sich auf den Ursprung (hier wg.site). Damit würde aus dem Namen ns.wg.site für BIND ns.wg.site.wg.site werden, sicherlich nicht die Intention des Zonenadmins. hermes steht daher für hermes.ursprung. In der Beispielzonendatei ist wg.site. der Ursprung, damit wird aus hermes hermes.wg.site. Ein Beispieleintrag für die umgekehrte Auflösung: $TTL 360 ; 6 IN SOA ns.wg.site. dirk.goe.net. ( ; serial ; refresh (8 hours) 1800 ; retry (30 minutes) ; expire (5 weeks 6 days 16 hours) ; minimum (1 day) ) IN NS ns.wg.site. 254 IN PTR ns.wg.site. $TTL ; 1 day 21 IN PTR mail.wg.site. 22 IN PTR mail-backup.wg.site. 203 IN PTR aphrodite.wg.site.

127 8.3. DNS-SERVER MIT LINUX IN PTR dionysos.wg.site. $TTL 360 ; 6 minutes 251 IN PTR demeter.wg.site. 252 IN PTR hermes.wg.site. TTL gibt die Lebensdauer aller Einträge in der Zone an, die kein ausdrückliches TTL besitzen, welches vor dem IN als Integer-Sekunden-Wert eingetragen werden würde Starten und Anhalten des Nameservers Nachdem Sie Ihre Zonendateien für die Vorwärts- und Rückwärtsauflösung angelegt und diese in der named.conf(.local) eingetragen haben, steht nun der Start des Servers an: linux04:/etc/bind# /etc/init.d/bind9 start Das Stoppen des Dienstes oder den Neustart regeln Sie entsprechend über stop oder restart. Eventuell auftretende Fehlermeldungen liefert named in der Datei /var/log/syslog ab. Hier überprüft man, ob alle Ihre Zonenfiles ohne Beschwerden akzeptiert wurden. Im Logfile liefert named Informationen auf welchen Interfaces er lauscht, wieviele Prozessoren er in Anspruch nimmt und welche Zonenfiles er erfolgreich eingelesen hat. Wenn Sie den Dienst automatisch beim Hochfahren der Maschine starten wollen, sollten Sie einen entsprechenden Link in den Runlevelverzeichnissen auf das Startskript /etc/init.d/bind9 anlegen. Feb 11 21:17:57 linux04 named[13692]: starting BIND 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, #53 Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0, #53 Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0:1, #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 in-addr.arpa allows updates by IP address, which is insecure Feb 11 21:17:57 linux04 named[13694]: command channel listening on #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 in-addr.arpa/IN: loaded serial 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 Feb 11 21:17:57 linux04 named[13694]: running 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

128 118 KAPITEL 8. DNS man unbedingt aus Gründen der Redundanz Slaves vorsehen. Hier fällt der Aufwand jedoch bedeutend geringer aus, da man lediglich die namd.conf.local anpassen muss. Trägt man hier alle Zonen ein, für die diese Maschine als Slave zuständig sein soll. zone "wg.site" IN { type slave; masters { ; }; file /etc/named/secondary/db.wg.site; } Man starte den Slave neu, nachdem der Master bereits läuft. Damit alles klappt muss named im Verzeichnis /etc/named/secondary über Schreibrechte verfügen. Hier landen die Daten eines erfolgreichen Domain-Transfers. Im Logfile des Masters findet sich ein Hinweis auf diesen Vorgang: Feb 11 22:18:02 linux04 named[13722]: client #36606: transfer of wg.site/in : AXFR started Anhand der Seriennummer der Datei stellt der Slave fest, ob sich Daten auf dem Server geändert haben (sollten). Sie muss daher stets inkrementiert werden, wenn eine Änderung vorgenommen wurde. Quasistandard ist ein JJJJMMTTRR-Format, um die Seriennummer festzulegen steht also für den , die beiden letzten Stellen für die zweite Modifikation der Zonendatei an diesem Tag. Nun ist diese Zahl oft nicht so übersichtlich, als dass man nicht versehentlich einen Fehler macht und eine Stelle zuviel drin hat. Wenn die Slaves eine solche Seriennummer übernommen haben und anschliessend auf dem Master wieder eine korrigierte Nummer eingetragen ist, bekommen sie kein Update mehr mit. Ihre Nummer ist immer größer als die des Masters. Um dieses Dilemma in den Griff zu bekommen, kann man den folgenden Trick anwenden: Man trage (= ) ein. BIND arbeitet mit vorzeichenbehafteten 32 bit Zahlen. So ist diese der größtmögliche Wert und in der nächsten Runde wird wieder jede beliebige Seriennummer von den Slaves als Grund für ein Update akzeptiert. In den Beispielen wurde eine strenge Trennung von Master- und Slave-Servern angenommen. Das muss natürlich in der Realität nicht so sein. Hier sind viele Server authoritativ für eine Reihe von Zonen und sekundär für eine Anzahl anderer Zonen Delegation einer Subdomain In den bisherigen Beispielen stimmte eine Zone immer mit einer Domain überein. Ein Nameserver war für den gesamten Namensraum zuständig. Dieser war einfach strukturiert: maschinenname.domain.topleveldomain, z.b. hermes.wg.site. Nun erlaubt DNS aber Teile seines Namensraumes an andere Nameserver zu delegieren. So können Admins bestimmter organisatorischer Einheiten ihre Zone verwalten. Mit folgendem Eintrag in der Zonendatei des Beispiels (/etc/bind/db.wg.site) delegiert der Nameserver die Zone, in diesem Fall die Subdomain sub.wg.site an die Server ns1.sub.wg.site und ns2.sub.wg.site. [... ] sub IN NS ns1.sub.wg.site. IN NS ns2.sub.wg.site. ns1.sub IN A ns2.sub IN A [... ] Der Resource-Record NS regelt die Delegation. Damit weiss der Nameserver, dass Anfragen auf *.sub.wg.site an die dafür zuständigen Server ns1 und ns2.sub.wg.site weitergereicht werden. Deren Namen müssen natürlich ebenfalls zu IP-Adressen aufgelöst werden können. Deshalb sind die beiden Nameserver ebenfalls mit einem A-Record vertreten.

129 8.4. DYNAMISCHE UPDATES DER ZONENDATEIEN Dynamische Updates der Zonendateien Mit steigender Anzahl verwalteter Zonen und Hosts wird das Verfahren der händischen Manipulation der Zonendateien für Admins schnell aufwändig. Nebenher hat sich die Zahl mobiler Endgeräte deutlich ausgeweitet. Das sind Hosts, die oft in verschiedenen Netzen betrieben. Zudem sind sie oft nicht sehr lange angemeldet. Hier wünscht man sich ein Verahren, was ähnlich zu WINS dynamisch arbeitet. Mit BIND seit Version 8 kann man dynamische Änderungen an den Resource Records vornehmen (lassen), ohne dafür Dateien editieren und diese neu laden zu müssen. Solche Änderungen können auch durch externe Dienste, wie DHCP angestoßen werden. Um dieses zu erlauben, muss der Admin eine zusätzliche Zeile in die Zonendefinition einfügen: zone "wg.site." IN {... allow update { ; }; } Im Beispiel ist nur das Update von der Loopbackadresse erlaubt. Man kann natürlich auch Listen von IP-Adressen oder ACLs angeben. Dabei ist jedoch zu beachten, dass bei der Datenübertragung über das Netz DNS nicht automatisch verschlüsselt. Wie man dieses einschaltet, wird im folgenden Abschnitt erklärt. Um das neue Feature gleich mal auszuprobieren, kann nsupdate verwendet werden. Dieses Programm ist im BIND-Paket enthalten. Es arbeitet interaktiv ähnlich wie nslookup. Man gebe zuerst den DNS-Server an und dann einen Eintrag der hinzugefügt oder gelöscht werden soll. Nach dem Eintrag ist ein zweimaliges Enter erforderlich. linux:~ > nsupdate > server > update add newhost.wg.site 300 A > > update delete newhost.sg.site 300 A Damit die ganze Geschichte auch funktioniert, muss der Nameserver das Recht haben das Verzeichnis der Zonendateien und diese selbst zu schreiben. Im Beispiel wurde eine Datei /etc/bind/db.wg.site.jnl beim Hinzufügen eines Eintrages angelegt. Alle 15 Minuten macht BIND einen Dump der Zonendatei mit den neuen oder ohne die zwischendurch entfernten Einträge und erhöht dabei die Seriennummer automatisch Sicherheit Wie man im Beispiel sehen konnte, benötigte nsupdate keine besondere Authentifizierung, um Änderungen an den DNS-Daten vorzunehmen. Eine Absendeadresse ist leicht zu fälschen, weshalb man sich schnell einen besseren Schutz wünscht. Ebenfalls will kein Administrator ernsthaft, dass jeder beliebige Host im Internet vom eigenen DNS ein Zonentransfer anfordern kann. Dieser ist normalerweise den Slaves vorbehalten, um ihre Daten zu aktualisieren. Ebenfalls seit Version 8 implementiert BIND zur Erhöhung der Sicherheit sogenannte Transaction Signatures (TSIGs). Dieses sind digitale Signaturen, die HMAC-MD5 als Einwege-Hashfunktionen benutzt. Die Signatur ist dabei nicht nur von der Nachricht, sondern auch von einem Schlüssel abhängig. Der Hashwert wird über die komplette binäre Nachricht berechnet und als Resource Record (Typ TSIG) angehängt. Zur Verhinderung von Replay-Attacken ist das Datum Bestandteil der Signatur.

130 120 KAPITEL 8. DNS Das Bastelset zum Erzeugen der Schlüssel liefert BIND mit dnssec-keygen. Der Aufruf dnssec-keygen -b 128 -a HMAC-MD5 -n HOST hermes.wg.site generiert einen 128bit- Schlüssel, der genau einer Maschine zugeordnet ist. linux04:~# dnssec-keygen -b 128 -a HMAC-MD5 -n HOST hermes.wg.site Khermes.wg.site linux04:~# ls Khermes.wg.site * Khermes.wg.site key Khermes.wg.site private linux04:~# cat Khermes.wg.site key hermes.wg.site. IN KEY ynhdhu8mm0vnsdwivltfow== linux04:~# cat Khermes.wg.site private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: ynhdhu8mm0vnsdwivltfow== Das Kommando legt zwei Dateien im Arbeitsverzeichnis an. In der Datei mit der Endung *.key findet man den öffentlichen Schlüssel in der anderen *.private den privaten. Den öffentlichen Schlüssel läßt sich nun in die entsprechende Zonendatei integrieren. So kann er beispielsweise mit host -t KEY hermes.wg.site abgefragt und zur Verifikation des privaten Schlüssels herangezogen werden. Den privaten Schlüssel hinterlegt man in der Datei mit den Zonendefinitionen /etc/bind/named.conf.local: key hermes.wg.site. { algorithm hmac-md5; secret "Geq/RRYhuAIrlUzJKj49MQ=="; }; und sorgen dafür, dass nur noch ein Update unter Angabe des Schlüssels erfolgen darf: zone "wg.site" in { type master; file "/etc/bind/db.wg.site"; allow-update { key hermes.wg.site.; }; }; Nach den Änderungen muss der Server neu gestartet werden. Ausprobieren kann man das Ganze nun mit dem Aufruf von nsupdate mit der Angabe der Datei mit dem privaten Schlüssel: nsupdate -k Khermes.wg.site private Die Transaktionen werden nun mit dem Schlüssel signiert. Ohne Angabe des Schlüssels würde die Aktion mit einem REFUSED fehlschlagen. nsupdate ist sicherlich nicht die alltägliche Anwendung. Bei den Fragen der Sicherheit geht es eher um Zonentransfers. Hierzu muss der private Schlüssel sowohl auf dem Masterals auch auf dem Slave-DNS-Server eingetragen sein. Für Zonentransfers heisst die Option statt allow-update allow-transfer unter Beibehaltung der restlichen Syntax. Auf dem Slave sehen die Eintragungen nun wie folgt aus: key hermes.wg.site. { algorithm hmac-md5; secret "Geq/RRYhuAIrlUzJKj49MQ=="; }; server { keys { hermes.wg.site.; }; }; zone "wg.site" IN { type slave; masters { ; }; file /etc/named/secondary/db.wg.site; }

131 8.5. DNS BEKOMMT NEUE AUFGABEN DNS bekommt neue Aufgaben ENUM Voice-over-IP hat im zweiten Anlauf nach den ersten Startversuchen Ende der 90er Jahre richtig Schwung bekommen. Spätestens seit der letzten Cebit 2004 hat der Hype um die Telefonie über das Internet die breite Öffentlichkeit erreicht. Nun waren Telefonie und IP-Netze lange Zeit zwei völlig getrennte Dienste, ein Zustand mit dem große Telefonie-Anbieter, wie die Telekom gut leben konnten. Wärend im Hintergrund beide Dienste konvergieren, steht nach aussen noch ein entscheidender Unterschied: International erreicht man jeden Teilnehmer am öffentlichen Telefonnetz über die 1-3 stellige Ländervorwahl gefolgt von einer maximal 15-stelligen nationale Telefonnummer. Letztere besteht aus einer Vorwahl und Anschlußnummer, wobei das Vorwahlkonzept in unterschiedlichen Ländern verschieden gehandhabt wird. Rechner im Internet werden hingegen durch ihre weltweit eindeutige IP angesprochen. ENUM schlägt hier nun die Brücke und führt beide Systeme unter Zurhilfenahme von DNS zusammen. Definiert ist die Abbildung von Telefonnummern im Domain Name System in RFC2916 zu ENUM E.164. ENUM kann noch mehr, nämlich beliebige Kommunikationsformen (Mail, Webseite,...) auf eine Telefonnummer abbilden und diese hierarchisch anordnen. DNS ist deshalb für ENUM interessant, da es seit Jahren etabliert ist und damit eine schnelle Umsetzung erlaubt. Die Vergabe von Telefonnummern ist in jedem Land ein hoheitlicher Akt, in Deutschland übernimmt das die Regulierungsbehörde für Telekommunikation. Sie hatte beispielsweise Ende letzten Jahres mit der Entscheidung über die ortsunhabhängige Vorwahl 032 für SIP- Telefonanschlüsse von sich hören lassen. Damit Telefonnummern im DNS-System darstellbar sind, werden sie in eine eindeutige Domain verwandelt. Hierzu wurde die Domain e164.arpa eingeführt analog zu ihrem IP- Pendant in-addr.arpa der Reverse-Auflösung. Unterhalb dieser Domain trägt man nun einfach Subdomains für jede Ziffer einer Telefonnummer ein. Anders als bei IP-Adressen und Telefonnummern steht bei DNS die spezifischte Information ganz links: Die Toplevel- Domain ist immer die ganz rechte, die Secondlevel-Domain die zweite von Rechts und Subdomains sind dann weitere bis der Rechnername ganz links kommt. Deshalb dreht man die die Telefonnummer um. So wird aus ein Eintrag der Form e164.arpa. 1. Zunächst entferne man alle optischen Strkturierungen, wie +, -, Leerzeichen: Man ordne die Ziffernfolge um: Aus erhält man Man setze Punkte zwischen die Ziffern: Am Ende fügt man noch die ENUM-Domain e164.arpa an: e164.arpa Den nun generierten vollständigen Domainnamen kann DNS nun ganz normal wie eine IP auch im Nameservicebetrieb verwenden. RFC2915 definiert für das ENUM-Protokoll spezielle Nameserver-Einträge, um auf die einzelnen Kommunikationsadressen (Telefon, Mail...) zu verweisen. Zum Einsatz kommen sogenannte Naming Authority Pointer Records (NAPTR). Für jede Domain lassen sich mehrere dieser NAPTR-Einträge angeben. Sie erlauben ebenfalls Prioritäten (Preferenzen) festzulegen.

132 122 KAPITEL 8. DNS Mit ENUM ändert sich der Charakter eines Anrufes grundsätzlich: Zunächst wird über das DNS-System die Telefonnummer bis zum NAPTR-Eintrag ermittelt. Diese weist dann auf eine Nummer eines Telefons oder Faxes, eines Handys oder weiterer Geräte. ENUM gestattet so dem Inhaber einer Telefonnummer, quasi beliebig viele Dienste auf seine Nummer abzubilden. Das vereinfacht in Zukunft das Verfahren alternative Dienste durch Telekommunikationsendgeräte und Applikationen anzusprechen IPv6 Die nächste Generation der IP-Adressen steht schon länger vor der Tür. Für den Endbenutzer sicherlich noch nicht relevant, so tut sich jedoch schon hinter den Kulissen einiges. Entsprechend schreitet auch die Auf- und Umrüstung der IP-Dienste auf IPv6 voran. So ist BIND seit einiger Zeit in der Lage IPv6-Adressen genauso wie Ihre IPv4-Pendants vorwärts und rückwärts aufzulösen. Für IPv6 wurde ein neuer Ressourcentyp eingeführt: AAAA repräsentiert eine IPv6 Adresse (A entsprach 32bit, 4*A entsprechend 128bit). Einträge in der Zonen-Datei zur Vorwärtsauflösung könnten also so aussehen: [... ] aphrodite IN A aphrodite-ipv6 IN AAAA 3ffe:701:10:200:22:feb5:3456 dionysos IN A dionysos-ipv6 IN AAAA 3ffe:701:10:200:22:feb5:3457 Die Rückwärtsauflösung landet in einer eigenen Zonendatei (beispielsweise 5.b.e.f e.f.f.3.ip6.arpa): [... ] 3456 IN PTR aphrodite-ipv6.wg.site IN PTR dionysos-ipv6.wg.site. Ein Problem entsteht nun natürlich bei der Auflösung von Namen zu IP: Welche Informationen sollen zurückgeliefert werden: Beide IP-Adressen oder jeweils die eine oder andere? Darüberhinaus gibt es noch einige weitere Stolperfallen: Angenommen, man betreibt eine Maschine ausschliesslich mit einer IPv6 Adresse. Dann lässt sich nicht einfach im Resolver eine IPv4 Adresse für den Nameserver angeben. Die Maschine wäre in den meisten Fällen nicht in der Lage ihre Anfragepakete dorthin zu routen. Der IPv4 DNS Ihres Netzes kann aber Proxy-Funktionen übernehmen. Er lauscht nicht nur wie gewohnt auf den IPv4-Interfaces sondern bekommt auch eine IPv6-Adresse zugeteilt, die von den Clients im eigenen Netz erreicht werden kann. Der Server empfängt dann die Anfragen vom Client über das IPv6-Interface und holt seinerseits Erkundigungen über das klassische IPv4 Netz ein DNS als Bannerfilter Wie sehr es auf einen funktionierenden Nameservice ankommt, sieht man, wenn man einfach mal eine häufig benutzte Domain falsch auflöst. Wenn man im eigenen LAN einen DNS betreibt, den alle Maschinen benutzen (müssen), kann man diesen für alle möglichen Zonen als authoritativ deklarieren. Hierzu trägt man einfach eine Zone für die entsprechende Domain nach und verweisen auf ein dafür speziell definiertes Master-File. zone "google.de" in { type master; file "master/empty.zone"; };

133 8.6. AUFGABEN 123 zone "falkag.de" in { type master; file "master/empty.zone"; }; zone "doubleclick.net" in { type master; file "master/empty.zone"; }; Dabei spielt es überhaupt keine Rolle, wenn alle diese Zonen die identische Datei benutzen. In dieser wird lediglich dafür gesorgt, dass auf jede Anfrage eine zurückgeliefert wird. ; NULL Zone File for Ad Servers and other unwanted services IN SOA mydomain.site. me.mydomain.site. ( 131 ; serial number ; refresh 1800 ; retry ; expire ) ; minimum TTL ; Zone NS NS mydomain.site. A * IN A Das Beispiel zeigt die Nutzung eines Wildcards *. Es muss nicht für jeden Namen ein Eintrag existieren, diese können so einfach zusammengefaßt werden. Wenn man den Nameserver beispielsweise für doubleclick.net authoritativ macht, dann schlägt das Laden aller Banner und Webbugs fehl, die als Quelle eine Maschine dieser Domain angeben. Je nach Browser können dann einige Seiten etwas verändert aussehen, da plötzlich Seitenelemente von denen man nie vermutet hätte, dass sie von extern kommen, fehlen. Dies ist kein Allheilmittel. Jeder Anbieter kann natürlich statt eines FQDN auch eine IP in seine Webadressen schreiben. Trotzdem ist es ein recht einfaches probates Mittel, um seine Datenspur bei sehr großen Diensteanbietern einfach zu reduzieren. Es zeigt aber auch, dass wenn die wenigen zentralen Root-Server nicht erreichbar sind, nicht mehr viel funktionieren würde. 8.6 Aufgaben Rechnernamen im Internet 1. Welche Aufgabe hat der DNS? 2. Warum kann man nicht einfach bei der alten /etc/hosts als einfache Zuordnung zwischen IP und Hostnamen bleiben? 3. Warum kann man zwar auf der lokalen Maschine den Hostnamen ändern; es hat aber keine Auswirkungen für alle anderen Rechner? 4. Man änder den Hostnamen! Wo müsste die dauerhafte Änderung eingetragen sein? Man ändere nun einen Eintrag für einen Rechner in der /etc/hosts, warum kann man

134 124 KAPITEL 8. DNS diesen Rechner nun unter dem neuen Namen anpingen, obwohl der Besitzer dieses Rechners den Namen nicht geändert hat? 5. Wo trägt man auf einem Linuxrechner die IP-Nummern von Nameservern ein? Warum kann man da nicht einfach den Namen des (Nameserver-)Rechners eintragen? 6. Warum macht es Sinn, mehrere DNS-Server einzutragen? Wo trägt man diese ein? Domain Name Service (DNS) 1. Was ist eine sogenannte Toplevel-Domain? Welche gibt es traditionell, welche sind erst in jüngerer Zeit hinzugekommen? 2. Worin besteht der Unterschied zwischen DNS Resolver und DNS Nameserver? 3. Welche Resource Records (RR) gibt es? Welche Bedeutung haben diese jeweils? DNS Server 1. Worin unterscheiden sich rekursive und iterative Namensauflösung? Warum antworten die Root-Nameserver immer nur iterativ? Mit welchem Kommando kann man das geschilderte Phänomen am besten nachvollziehen? 2. Wieviele Root-Nameserver gibt es? Wo stehen diese? Wodurch ist deren Zahl begrenzt?

135 Kapitel 9 Webserver Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache des modernen WWW. Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat viel zur breiten Akzeptanz des Internets beigetragen. 9.1 Überblick Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle: Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und ausliefert. URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine Ressource. z.b URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar. URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.b. urn:isbn: Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DE- LETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert. HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann. 125

136 126 KAPITEL 9. WEBSERVER Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen Performace- Optimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge,...) zuordnen können. Dadurch können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene. HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen und Entwicklungen, die in den späten neunziger Jahren waren. 9.2 HTTP-Kommunikation telnet Trying Connected to Escape character is ^]. GET /hallo.html HTTP/1.1 Host :81!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head> <title>test-seite</title> </head> <body> <H1> Hauptüberschrift </H1> </body> </html> Connection closed by foreign host. Zwischen GET- und POST-Anfragen bestehen folgende wesentliche Unterschiede: Bei der GET-Methode werden die übergebenen Daten in die URL einkodiert und sind somit für jeden sofort lesbar, ein Beispiel sind Suchanfragen bei Google: utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:de-de:official Bei POST werden die Daten im Header übergeben. Dabei lassen sich wesentlich mehr Daten übergeben als in einer GET-Anfrage. Das Versenden der Daten an den Server geschieht für den Nutzer auf den ersten Blick scheinbar unsichtbar. Ein wesentlich größerer Unterschied ist allerdings, dass GET-Anfragen idempotent sind, was bedeutet, das sich die Seite aufgrund einer GET-Anfrage nicht ändert. Daraus ergibt sich auch, dass solche Seiten im Cache angelegt werden können. Mit POST-Seiten ist es jedoch genau andersherum, diese sind nicht idempotent und werden deshalb nicht im Cache abgelegt.

137 9.3. WAS IST EIN WEBSERVER? Was ist ein Webserver? Ein Server ist ein Programm, das bestimmte Anfragen auf einem bestimmten Port annimmt und verarbeitet. Ein Webserver liefert Dateien aus bestimmten Verzeichnissen (mit der Angabe von welchem Type 1 diese Dateien sind) über Netzwerk aus. Unter Umständen wird bei der Entscheidung, welche Dateien ausgeliefert werden, nach der angefragten Adresse unterschieden. Grundsätzlich wird auf die Anfrage mit der Auslieferung von Content-Type Text-html und dem Inhalt der Datei: /usr/local/httpd/htdocs/directory/example.html 2 von dem Webserver auf host.domain reagiert. 9.4 Apache 2 Der Apache 2 ist der weltweit meist-verbreitete Webserver. Ein Kernbestandteil des Erfolges ist die Tatsache, dass Apache ein Open-Source-Projekt ist. Der Aufbau ist modular, d.h. der Webserver hat einen schlanken Kern, welcher die Grundfunktionalität enthält und Erweiterungen können zusätzlich eingebunden werden (teilweise mit und teilweise ohne Neustart des Apache). Vielfach sind noch eine ältere Version des Servers 1.3.X im Einsatz. Neu in der Version 2.0 ist z.b. dass plattformspezifischer Code (z.b. Schreib- Lesezugriffe auf die Festplatte) in eine APR (Apache Portable Runtime) ausgelagert wurde. Dies ermöglicht es, dass für jedes Betriebssystem eine eigene Version der APR geschrieben und optimiert werden kann, was der Geschwindigkeit und Stabilität zu Gute kommt. Einheiten zur Abbildung von HTTP-Anfragen auf reale Ausführungseinheiten wurden ebenso ausgelagert. (Diese nennen sich MPMs [Multi Processing Modules].) Dies macht Sinn, da dieser Vorgang ebenso vom Betriebssystem abhängt (genauso wie von der konkret betrachteten Anwendung natürlich auch). Ebenso neu eingeführt in der Version 2.0 wurden Multi-Protokoll-Unterstützung auf Transportebene und IPv6-Unterstützung Erweiterte Funktionalität Virtual Hosts (IP- oder Name-basiert) SSL, sichere Verbindungen Authentifizierung CGI (Common Gateway Interface) Ausführen von Scripten und Programmen PHP SSI (Server Side Includes) 9.5 Konfiguration In den aktuellen Versionen hat Apache nur noch die Konfigurationsdatei httpd.conf. Allerdings machen viele Distributionen von der Möglichkeit gebrauch, andere Dateien mit Include einzubinden. 1 zb.: Content-Type Text-html 2 Wenn DocumentRoot auf /usr/local/httpd/htdocs gesetzt ist. Dazu später mehr.

138 128 KAPITEL 9. WEBSERVER Die Konfiguration besteht aus drei Abschnitten. Section 1: Global Environment Section 2: Main server configuration Section 3: Virtual Hosts Das Verhalten des Servers wird innerhalb dieser Sektionen mit sogenannten Direktiven gesteuert. Diese Direktiven stehen innerhalb von Konfigurationskontexten. globaler Kontext In der Konfigurationsdatei ausserhalb von Containern Container-Kontext Innerhalb von Container-Tags (zb.: Directory... /Directory ). Der Gültigkeitsbereich ist auf die Container beschränkt. Verzeichniskontext In zusätzlichen Konfigurationsdateien innerhalb der Verzeichnisstruktur. Der Name dieser Dateien kann mit AccessFileName festgelegt werden 3. Direktiven können in unterschiedlichem Kontext stehen, aber nicht jede Direktive kann in jedem Kontext verwendet werden. Die Apache-Dokumentation gibt für jede Direktive an, in welchem Kontext sie verwendet werden kann. Einige der wichtigsten Direktiven der Main Server Konfiguration sind: ServerType standalone inetd ServerRoot Das Verzeichnis, das für den Webserver die unterste Verzeichnisebene darstellt. ServerName Der Name des Webservers ist die URL unter der er erreichbar ist. DocumentRoot Das Verzeichnis in dem sich die Webseiten befinden, bzw. aus dem der Webserver Dateien ausliefern darf. User / Group Benutzer- bzw. Gruppenrechte, mit denen der Webserver läuft. ServerAdmin -Adresse des Administrators. An diese Adresse werden Servermeldungen geschickt und sie wird unter Umständen Benutzern mitgeteilt Optionen Eine wichtige Direktive ist die Options-Direktive mit der man festlegen kann, welche Server- Features verfügbar sind. Optionen können im Konfiguration-, Container- und Verzeichnis- Kontext gesetzt werden. ExecCGI : Ausführbarkeit von CGI-Programmen Includes : Ausführung von ServerSideInclude-Befehlen (SSI) Indexes : Verzeichnislisting anzeigen

139 9.5. KONFIGURATION 129 <Directory /home/www/> Options +Indexes -Includes </Directory> Abbildung 9.1: Options hinzugügen/entfernen Optionen können gesetzt, hinzugefügt(+) oder entfernt(-) werden. Im Beispiel 9.1 wird für das Verzeichnis /home/www/ die Option Indexes zu den allgemein gültigen Optionen hinzugefügt und die Option Includes von den allgemein gültigen Optionen entfernt (abgezogen). Im Beispiel 9.2 werden für das Verzeichnis /home/www2/ nur die Optionen Indexes und Includes gesetzt. Unabhängig von den allgemein gültigen Optionen. <Directory /home/www2/> Options Indexes Includes </Directory> Abbildung 9.2: Options setzen Module Zusätzliche Funktionalitäten können in Form von Modulen hinzugefügt werden. Module können mit LoadModule cgi_module /usr/lib/apache/mod_cgi.so AddModule mod_cgi.c im Global-Kontext geladen werden. Module bringen ihre eigenen Direktiven mit, die nach dem Laden verfügbar sind. Mit der Direktive IfModule kann man Container erzeugen, deren Direktiven nur ausgeführt werden, wenn das entsprechende Modul geladen ist (siehe 9.3, S. 130). Module können auch direkt in den Apache einkompiliert werden und sind dann ohne geladen werden zu müssen verfügbar. Für Apache gibt es eine Vielzahl Module, die nicht zur Standard-Distribution gehören. Wünscht man sich eine zusätzliche Funktion für seinen Webserver, lohnt es sich im Internet nach einem Modul zu suchen, das diese Funktionalität bereitstellt. Sollte man nicht fündig werden, kann man sich dank der offenen Quelltexte daran machen, selber ein solches Modul zu schreiben User-WWW Das Userdir-Modul ermöglicht es für jeden Benutzer ein Verzeichnis einzurichten, das bei einer Anfrage der Form vom Webserver ausgeliefert wird. Die Direktive UserDir legt den Namen des Verzeichnisses innerhalb der Home-Verzeichnisse fest, dessen Inhalt der Webserver ausliefern darf. Innerhalb eines Directory- Containers bezüglich /home/*/public html kann man das Verhalten des Webservers innerhalb dieses Verzeichnisses steuern. Beide Anweisungen sind unabhängig voneinander, man muss selber darauf achten, dass man das Verzeichnis konfiguriert, dass mit UserDir gesetzt ist. 3 Standard ist AccessFileName.htaccess

140 130 KAPITEL 9. WEBSERVER <IfModule mod_userdir.c> UserDir public_html </IfModule> <Directory /home/*/public_html> AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec </Directory> Abbildung 9.3: User-Webdirectory Bei SuSE-Linux sind die Direktiven bezüglich mod userdir in die Datei /etc/httpd/suse public html.conf ausgelagert. 9.6 Webserver Erweiterungen Die Anforderungen an den Apache Webserver sind in den letzten Jahren gestiegen, so dass das eigentliche ausführbare Programm permanent erweitert werden muss. Die Apache- Foundation 4 hat sich hier einer modernen Methode des Softwaredesigns bedient, bei der nicht das eigentliche Kernprogramm aufgebläht wird, sondern zusätzliche Funktionalität in externe Module ausgelagert wird. Der Kern-Server (core-server) bietet nur die notwendige Basisfunktionalität, wie die Implementierung eines TCP/IP-Servers. Alle zusätzlichen Features werden durch Module hinzugefügt. Durch diese Möglichkeit bleibt der Webserver schlank und verwendet je nach Konfiguration nur die Module, welche wirklich gebraucht werden. Dieses vermeidet unnötige Sicherheitslücken. In der Apache Modul Datenbank sind momentan (November 2005) über 400 Module gelistet bei steigender Anzahl. Zur Integration von Zusatzfunktionen kann man zwischen zwei Modularten unterscheiden: Ein statisches Modul wird zusammen mit dem Kern zu einem einheitlichen Paket kompiliert und damit fester Bestandteil des Webserver-Programms. Beim Hinzufügen oder Entfernen eines solchen Moduls kommt der Admin um eine Neukompilierung des Webservers nicht herum. Durch die feste Integration kann sich die Ausführungsgeschwindigkeit beim Starten des Apache und wärend der Laufzeit erhöhen, da keine zusätzlichen Initialisierungen für jedes Modul notwendig sind und der interne Code- Overhead sinkt. Ein Shared-Module kann dynamisch durch eine entsprechende Direktive in der Konfigurationsdatei httpd.conf hinzugefügt oder entfernt werden. Da die Konfigurationsdateien nur bei einem Start des Apache Webserver eingelesen werden, ist hier also lediglich ein Neustart des Webservers erforderlich. Diese Methode bringt zwar Einbußen der Performance des Webservers mit sich, jedoch ist es so sehr einfach möglich ein Modul schnell und ohne zeitaufwendige Neukompilierung des Webservers hinzuzufügen. 4 Der erste Apache-Webserver entstand aus dem damals aktuellen NCSA httpd 1.3 und zusätzlichen Erweiterungen und Patches (a patchy-webserver). Im Sommer 1999 begann die Entwicklung des Apache 2, welcher komplett neu geschrieben wurde. Die Apache Gruppe entwickelt heute sehr erfolgreich Erneuerungen am Apache Webserver.

141 9.6. WEBSERVER ERWEITERUNGEN Die Benutzer-Homepage - mod userdir In klassischen Multi-User-Umgebungen wie Universitäten und Schulen haben Benutzer mit Linux-Account üblicherweise auch die Möglichkeit eine eigene Homepage in ihrem Home- Verzeichnis anzulegen. Das Modul kümmert sich darum, dass der Webserver mit geeigneten Rechten auf ein Unterverzeichnis im User-Home, welches sonst ja vor unauthorisiertem Zugriff geschützt sein sollte, hineinschauen darf. Das Modul muss lediglich einmal konfiguriert werden. Anschliessend sind sämtliche Homepage-Verzeichnisse über den Webserver von außen erreichbar. Klassischer Weise erreicht man die Seiten der einzelnen Benutzer unter der URL username. Das hierfür bestimmte Verzeichnis im jeweiligen Home-Verzeichnis des Benutzers lässt sich in der Konfigurationsdatei mit der Direktive UserDir Unterverzeichnisname definieren. In den meisten Fällen heisst dieses Verzeichnis public html URL-Umschreiber mod rewrite Dieses Modul erlaubt Manipulationen der URL, durch sogenannte Regular Expressions, wie man sie auch von anderen Linux-Tools, wie sed oder grep kennt. Hierdurch kann der Webadmin unschöne URLs verändern, um sie zum Beispiel für Suchmaschinen freundlicher zu gestalten. Viele der Suchmaschinen können zwar dynamische Webinhalte indizieren, jedoch wird eine Internetseite sichtlich besser indiziert, wenn diese statisch ist. Deshalb wird recht häufig mod rewrite eingesetzt, um den Suchmaschinen Spidern eine dynamische Seite als statisch unterzuschieben. Dynamische Seiten sind oft durch URLs mit Parametern charakterisiert: uni-freiburg.de/php veranstaltungsdetail.php?id=7. Mittels mod rewrite kann man die URL so umschreiben, so dass die Seite auch Intern wandelt das Modul die URL wieder um, so dass die dynamische Seite mit sämtlichen Parametern aufgerufen wird. Dieses lässt sich durch eine einfache Direktive in der Apache Konfigurationsdatei httpd.conf umsetzen, wie die Abbildung von praxis-seminar.html auf php veranstaltungsdetail.php?id=7. RewriteEngine On RewriteRule ^(praxis-seminar7[0-9]+).html$ php_veranstaltungsdetail.php?id=$1 Die erste Zeile schaltet das Modul durch die Direktive RewriteEngine On ein. In der zweiten Zeile folgt dann die Regel für die Umschreibung. Der erste Parameter bildet das Suchmuster und der zweite Parameter das Ersetzungsmuster. Das Suchmuster lässt soch mittels regulärer Ausdrücke formulieren. Beim Ersetzungsmuster kann es sich um einfachen Text, aber auch Variablen des regulären Ausdrucks enthalten. Im gezeigten Beispiel steht $1 für das erste Klammerpaar im Suchmuster Zugriffskontrollen Die Module mod auth basic und mod auth digest erlauben die Einrichtung einer einfache Zugriffskontrolle über das HTTP Protokoll. Erfolgt ein Zugriff auf eine zugriffsbeschränkte Resource, dann schickt der Server den Status 401 und verlangt eine Authentifizierung des Benutzers durch Eingabe eines Benutzernamens und Passworts. Die Eingabe gleicht der Server mit den Einträgen der Passwort- und Gruppendatei ab. Besitzt der Benutzer die nötigen Rechte, gewährt der Webserver dem Benutzer den Zugriff. Um ein Verzeichnis auf dem Webserver vor unauthorisiertem Zugriff zu schützen, gibt es zwei Möglichkeiten: Zentral in der httpd.conf oder mit Hilfe von.htaccess-dateien in den zu schützenden Verzeichnissen. Für den zentralen Ansatz muss der Webadmin in der httpd.conf die nachfolgenden Zeilen hinzufügen.

142 132 KAPITEL 9. WEBSERVER <Directory "/srv/www/htdocs/secure"> AuthType Digest AuthName "privat" AuthDigestFile /srv/www/.htpasswd Require valid-user </Directory> Dabei handelt es sich bei /srv/www/htdocs/secure das zu schützende Verzeichnis, das mit der Digest-Methode abgesichert wird. Für einen Passwortschutz mittels.htaccess-datei(en) sind die folgenden Schritte zu unternehmen. Man erstellt die Datei im Verzeichnis mit dem entsprechenden Inhalt. <Directory> AuthType Digest AuthName "Mit MD5/Digest gesicherter Bereich" AuthDigestFile /srv/www/.htpasswd Require valid-user Require Group webadmins </Directory> Mit der Direktive AuthType wird die Authentifizierungsmethode festgelegt, wobei der Webadmin zwischen Basic und Digest wählen kann. Der Unterschied zwischen beiden Module liegt in der Art der Datenübertragung. Während die Basic Authentifizierung (mod auth basic) die Daten im Klartext überträgt und damit ein recht hohes Risiko eingeht, verschlüsselt das Modul mod auth digest die Daten vor der Übertragung mittels MD5. Da jedoch das Chiffrat abgefangen und mittels Bruteforce-Attacke interpretiert werden kann, empfiehlt sich bei sensiblen Bereichen die Übertragung zusätzlich mit Hilfe von SSL zu sichern. <Directory> AuthType Basic AuthName "Mit BasicAuth nicht wirklich gesicherter Bereich" AuthUserFile /srv/www/.htpasswd Require valid-user </Directory> AuthName definiert den Namen des geschützten Bereichs. Der hier definierte String wird dem Benutzer bei der Passwort-Abfrage präsentiert. Mit den Direktiven AuthUserFile und AuthGroupFile, beziehungsweise im Fall der Digest Authentifizierung AuthDigestFile und AuthDigestGroupFile wird der Pfad zu der Passwort- und Gruppendatei definiert. Die letzte Zeile des Beispiels legt zusätzlich fest, welche Benutzer berechtigt sind in das Verzeichnis zu wechseln. Hierzu verwendet man die Direktive Require, welche wie bei der Basic Authentifizierung einen gültigen Benutzer verlangt. #.htpasswd user01:secure_section01:fnxpraouunko3ocasde1cdf0l1ases1a user02:secure_section01:basd2w49eq0eab5wehz1sdf2r44f24cd user03:secure_section02:lse35aa81ca43dc8dsecdbe f Die in den Beispielen genannten Passwort- und Gruppendateien sind Textformate, die sich mit einem ganz normalen Editor bearbeiten lassen. Die Passworte muss man dabei nicht selbst erstellen, dieses regelt das Programm mit dem Namen htpasswd2 für die Basic Authentifizierung und htdigest2 für die Digest Authetifizierung. Durch den Aufruf htpasswd2 -c datei username oder entsprechend htdigest2 -c datei bereich username wird man zur Eingabe des Passwortes aufgefordert und anschliessend die Datei erzeugt. Das Hinzufügen von Benutzern in bestehende Dateien geschieht durch das Weglassen des Parameters -c. #.htgroup webadmins:user01 user02 normal_user:user03

143 9.6. WEBSERVER ERWEITERUNGEN 133 Bei sehr vielen Benutzern wird es wie bei der normalen Linux-User-Administration auch, irgendwann aufwändig die Informationen in einzelnen Dateien zu verwalten. Als Alternative bietet sich LDAP an. 5 Eine Basic Authentication kann auch gegen eine LDAP-Quelle laufen, die.htaccess zeigt die entsprechenden Einträge: AuthType Basic AuthName "Gegen LDAP authentifizierter Bereich" LDAP_Server localhost LDAP_Port 389 Base_DN "ou=user,dc=mydomain,dc=site" Require valid-user Kompression Das Modul mod deflate wurde mit der Apache Version 2 eingeführt und erlaubt die Kompression von Webinhalten durch Angabe eines Filters. Das Modul kann ausgehende, sowie auch eingehende Daten komprimieren. Der Datenverkehr wird hierzu über diesen Filter umgeleitet. Um dieses Modul zu aktivieren, trägt ein Admin die folgende Direktiven in der Apache-Konfigurationsdatei ein: SetOutputFilter DEFLATE <Directory "/srv/www/htdocs" AddOutputFilterByType DEFLATE Text/html </Directory> Das Web-DAV Modul Das Modul mod dav ermöglicht es dem Apache Webserver ein Verzeichnis nach dem DAV- Standard 6 bereit zu stellen. Dieses ermöglicht DAV-Clients, wie Subversion 7 Adobe Golive, Macromedia Dreamweaver oder dem Windows Explorer, auf das Verzeichnis zuzugreifen, als wären die Dateien auf der Festplatte der lokalen Maschine abgelegt. WebDAV ist eine Erweiterung des HTTP/1.1 Protokolls, welche bestehende Beschränkungen aufhebt. Mit dem HTTP Protokoll ist es theoretisch möglich mit einem HTTP-PUT einzelne Dateien hochzuladen. Diese Möglichkeit wird jedoch von den meisten Webservern mit der Fehlermeldung 405 quittiert. Durch die Erweiterung des Protokolls mit WebDAV ist es möglich ganze Verzeichnisse hochzuladen und dies gleichzeitig an eine Revisionskontrolle zu koppeln. Das WebDAV Protokoll setzt also auf das HTTP/1.1 Protokoll auf, übernimmt dessen Methoden für die Kommunikation und erweitert diese um seine eigenen Methoden: COPY - kopiert Collections (Web DAV für Verzeichnis) und Ressourcen innerhalb eines zusammenhängenden Namensraumes. LOCK - setzt eine Sperre auf eine Ressource oder Collection um einen Überschreibschutz zu implementieren. MKCOL - erzeugt eine Collection. MOVE - verschiebt eine Collection oder Ressource innerhalb eines zusammenhängenden Namensraumes. PROPFIND - ermöglicht es Metadaten, Eigenschaften einer Ressource zu lesen. 5 siehe hierzu... 6 Web-based Distributed Authoring and Versioning 7 Siehe hierzu den Abschnitt Softwareentwicklung

144 134 KAPITEL 9. WEBSERVER PROPPATCH - kann diese Metadaten ändern und löschen. UNLOCK - entfernt diesen Überschreibschutz wieder Nachfolgend sei ein einfaches Beispiel für WebDAV Freigabe demonstriert: DAVLockDB /usr/local/apache2/webdav <Location /srv/htdocs/> Dav On ForceType text/plain </Location> Mit der ersten Direktive legt man den Pfad zu der Lock-Datenbank fest. In dieser Datei wird abgespeichert, welche der vorhandenen Ressourcen gerade gesperrt sind. Dann folgt ein Location-Container mit dem wir das Verzeichnis definieren, für welches man individuelle Einstellungen vornehmen möchte. Mit der Direktive Dav On, wird die WebDAV Funktionalität für das Verzeichnis eingeschaltet. Beim Einsatz von WebDAV sollte der Admin unbedingt auf die notwendigen Sicherheitsvorkehrungen achten. Hierzu gehört mindestens ein Verzeichnisschutz. Am besten eignet sich jedoch die Verwendung eines virtuellen Host in Verbindung mit SSL-Absicherung und einer mod auth digest Authentifizierung Vrituelle Webserver Wenn man sich überlegt, wieviele Domains Webseiten bereitstellen, wird schnell klar, dass nicht für jede dieser Domain ein Webserver läuft. Oder womöglich für jede ein Rechner. Auch würde es für die wenigsten Privatpersonen Sinn machen, auf ihrem Computer zu hause einen öffentlichen Webserver zu betreiben, denn der sollte rund um die Uhr verfügbar sein. Da erscheint es auf Anhieb sinnvoll mehrere Domains über einen Webserver zu betreiben. Für Betreiber eines Webservers, also beispielsweise diverse große Webhoster, wäre es ziemlich aufwändig für jede Domain eine eigene Instanz des Webservers auf unterschiedlichen Ports einer Maschine oder auf verschiedenen IP s laufen zu lassen. Deshalb unterstützt Apache schon seit der Vorgängerversion virtuelle Server. Bei namensbasierten virtuellen Servern verwaltet der Apache mehrere Domains, welche alle die gleiche IP-Adresse besitzen. Eingehende Anfragen können nur deshalb an die richtige Domain weitergeleitet werden, weil der Domainname in der GET-Anfrage enthalten ist. Um den Apache für virtuelle Server zu konfigurieren, muss die httpd.conf oder die entsprechende Include-Datei 8 geändert werden. NameVirtualHost Schaltet Name Virtual Host ein und gibt an, auf welcher IP-Adresse auf entsprechende Anfragen reagiert werden soll. Gibt man anstatt einer IP ein * an, wird auf jeder an den Rechner gebundenen IP-Adresse Name Virtual Host eingeschaltet. ServerName Legt die URL fest, auf die sich der VirtualHost-Container bezieht. ServerAlias Alternative URL s, auf die sich der VirtualHost-Container bezieht. DocumentRoot Das Verzeichnis in dem sich die Dokumente befinden, die von diesem VirtualHost ausgeliefert werden dürfen. 8 Das hängt von der Konfiguration ab, die die jeweilige Distribution für den Apachen vorsieht. Anstatt diese Konfigurationen fest in die httpd.conf zu schreiben, ist es häufig so angelegt, dass virtuelle Server dynamisch generiert werden können, ohne den Apache jedes Mal neu starten zu müssen. SuSE verwendet beispielsweise ein eigenes Unterverzeichnis /etc/apache2/vhosts.d

145 9.7. SSL (SECURE SOCKET LAYER) 135 NameVirtualHost *:80 <VirtualHost *:80> ServerName ServerAlias my-domain.site *.my-domain.site DocumentRoot /srv/www/my-content </VirtualHost> <VirtualHost *:80> ServerName DocumentRoot /srv/www/othercontent </VirtualHost> Diese Konfiguration besagt, dass die virtuellen Server auf Port 80, egal auf welche IP, angesprochen werden. Es werden jeweils gültige Domainnamen definiert, sowie Stammverzeichnisse festgelegt. Alternativ wird bei einem IP-basierten virtuellen Webserver jeder Domain, die der Server bedienen soll eine eigene IP zugeordnet. Da IP-Adressen jedoch meistens knapp sind, wird dieses oft nur für SSL-gesichterte Sites eingesetzt. Möchte ein Client auf eine Domain zugreifen, dann muss er beim zuständigen DNS- Server nach der IP Adresse des Domainnamens fragen und kann den Webserver dann über diese IP Adresse ansprechen. Um diese Art virtuelle Webserver einzurichten, muss ein Webserver-Admin in der Konfigurationsdatei httpd.conf, oder je nach Distribution in der passenden Include-Datei, einen VirtualHost Container anlegen: <VirtualHost > ServerName DocumentRoot /srv/www/my-first-domain/htdocs </VirtualHost> <VirtualHost > ServerName DocumentRoot /srv/www/my-second-domain/htdocs </VirtualHost> Im obigen Beispiel wurden zwei VirtualHost Container angelegt, welche als Attribut die IP-Adresse mit führen. Bei einem IP basierten virtuellen Webserver müssen diese natürlich verschieden sein. Mit der Direktive ServerName wird DomainNamen konfiguriert, also unter welchem DNS-Namen der Server erreichbar sein soll. Die Direktive DocumentRoot legt die Dokumentenwurzel des virtuellen Webservers fest. Sie ist der Pfad zu dem Verzeichnis in dem die entsprechenden Webseiten lagern. 9.7 SSL (Secure Socket Layer) Daten werden über das HTTP Protokoll standardmäßig im Klartext übertragen und stellen gerade in Bezug mit vertraulichen Daten ein Sicherheitsrisiko dar. Gerade in Bereichen mit persönlichen oder wirtschaftlich relevanten Daten sollten gesicherte Verbindung zum Einsatz kommen. SSL ist eine Technik um Verbindungen zu verschlüsseln. Diese Verschlüsselung setzt oberhalb von TCP an und kann deshalb auch für andere TCP-basierte Dienste eingesetzt werden. Für die verschlüsselte Übertragung sensibler Daten von oder zu einer Webseite ist das HTTPS (HyperText Transfer Protokol Secure) definiert. Bei einer Anfrage, die mit beginnt, wird eine sichere, d.h. verschlüsselte, Verbindung vom Client zum Webserver aufgebaut. Die HTTPS-Anfragen nimmt der Webserver, wenn nichts anderes eingestellt ist, auf Port 443 entgegen.

146 136 KAPITEL 9. WEBSERVER Funktionsweise Für eine verschlüsselte Verbindung muss zumindest ein Kommunikationsschlüssel ausgetauscht werden, mit dem beide Seiten dann arbeiten. Zur Kommunikation wird aus Performanzgründen ein symetrisches Verschlüsselungsverfahren eingesetzt. Der Kommunikationsschlüssel wird über ein Public-Key-Verfahren ausgetauscht. Dazu benötigt mindestens der Webserver einen öffentlichen und einen privaten Schlüssel. Bei einem Verbindungsaufbau, schickt der Webserver ein x509-certificate, das seinen öffentlichen Schlüssel und seinen Namen beinhaltet, an den Client. Anhand dieses Certificates kann der Client einen Webserver, dem er einmal vertraut hat, wiedererkennen und mit Hilfe des öffentlichen Schlüssels einen Vorschlag für einen Kommunikationsschlüssel machen. Ist das Certificate von einer Instanz signiert, der der Client vertraut, kann er auch einem Webserver vertrauen, den er noch nicht kennt. 9 Abbildung?? zeigt, wie dem Webserver sein Certificate übergeben wird. Dabei müssen das zu verschickende Certificate mit dem öffentlichen Schlüssel und (! in einer anderen Datei) der private Schlüssel angegeben werden. SSLCertificateFile /etc/httpd/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/ssl.key/server.key Zertifikate Zertifikate 10 sind signierte Informationen über eine Instanz. Ein Certificate enhält mindestens einen eindeutigen Namen und den öffentlichen Schlüssel der Instanz. Damit eine andere Instanz das Certificate anerkennen kann, muss es von einer dritten Instanz, der beide Vertrauen, unterzeichnet sein. Das gilt als Beglaubigung, dass das Certificate echt ist. Eine solche vertrauensvolle Instanz nennt man Certificate Authorisation (CA). Der Name der Instanz wird in dem Certificate in der von LDAP bekannten Objektorientierten schreibweise angegeben (zb.: C=de, O=uni-math, CN= ). Dabei ist es für das Certificate eines Webservers wichtig, dass der Eintrag CN (Common- Name) die URL des Webservers beinhaltet. Mit dem Paket openssl kommt das Perl-Skript CA.pl, das bei der Erzeugung und Verwaltung von Certificaten hilft. /usr/share/ssl/misc/ca.pl -newcert -newreq -newca -sign -verify CA.pl benutzt openssl zur Bearbeitung von Certificaten. Eine ausgiebige Lektüre der Manpage von openssl kann dieses Skript überflüssig machen und versetzt in die Lage, Certificate feiner zu beeinflussen. Eine umfangreiche und gute Beschreibung des Umganges mit Certificaten findet man unter Zertifikate erzeugen Folgende Schritte führen zu einem Server-Certificate in der Datei newreq.pem und dem entschprechenden privaten Schlüssel in wwwkeyunsecure.pem. CA.pl -newcert Certification Authority und ca-certificat erstellen 9 So ist das Prinzip, in Wirklichkeit ist das Ganze ein bischen komplizierter. 10 engl. certificates

147 9.8. CGI (-MODUL) 137 CA.pl -newreq Certificate-Request. Erzeugt ein neues Certificate. Für ein Webserver- Certificate ist darauf zu achten, als CN den Namen der Webseite anzugeben. CA.pl -sign das neue Certificat mit dem ca-certificat signieren openssl rsa -in newreq.pem -out wwwkeyunsecure.pem Passphrase aus dem Certificat entfernen und den Privat-Key in eine eigene Datei auslagern Es ist zu empfehlen, für die ersten Versuche ein Verzeichnis anzulegen, in das man CA.pl kopiert und dort die entsprechenden Befehle aufruft Integration Hat man den Schlüssel erfolgreich erstellt, kann man in der Konfigurationsdatei httpd.conf oder je nach Distribution der passenden Include-Daten das Modul für ein Verzeichnis aktivieren. Dieses geschieht in der Regel mit einem IP-basierten 11 virtuellen Host: Listen 443 <VirtualHost *:443> DocumentRoot /srv/www/htdocs/ssl-gesichert ServerName :443 SSLEngine on SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key </VirtualHost> Durch die Listen-Direktive in der ersten Zeile sagt ein Admin dem Apache Webservern, dass er auf dem Port 443 antworten soll. Dann wird in einem VirtualHost-Container eingerichtet. In diesem schaltet die Direktive SSLEngine on die SSLUnterstützung für diesen virtuellen Server an. Mit den beiden Direktiven SSLCertificateFile und SSLCertificateKey- File gibt man den Pfad zu dem SSL-Zertifikat und SSL-Schlüssel an. Die Pfade in denen sich diese beiden Dateien befinden sollten natürlich ausreichend geschützt sein, damit ein potenzieller Angreifer keine Möglichkeit hat an den SSL-Schlüssel zu gelangen - ansonsten wäre diese Verschlüsselung wertlos. 9.8 CGI (-Modul) CGI (Common Gateway Interface) definiert eine Schnittstelle, die die Kommunikation zwischen Webservern und Programmen erleichtert. HTML-Dokumente können Variablen mittels Form-Tags über CGI an Programme übergeben. Diese sogenannten CGI-Progamme generieren oft wieder ganze Webseiten. So kann man ganze Internetauftritte über CGI- Programme steuern. Für die Variablenübergabe gibt es zwei Methoden. GET-Methode Die Variablen werden als Teil der URL übergeben. Man hat die Möglichkeit, einen Aufruf mit den Variablendefinitionen selbst zu formulieren, zb. direkt in die Adresszeile des Browsers einzugeben. Dabei werden die Variablen mit Wertzuweisung nach einem? an die URL angehängt. Mehrere Variablen-Wert-Paare werden dabei durch ein & getrennt. 11 Mit der namensbasierten Variante stößt man hier an die Grenzen, denn bevor der Browser in dem HTTP-Header den Domainnamen sendet, erfolgt das SSL Handshake. Zu diesem Zeitpunkt ist jedoch nur die IP Adresse und die Portnummer bekannt, welche bei den namensbasierten virtuellen Webservern zu mehreren Domains führen kann.

148 138 KAPITEL 9. WEBSERVER POST-Methode Die Variablen werden im Request-Header übergeben, sind also für den Benutzer nicht sichtbar. Das macht es für dritte zumindest schwerer, etwas über das Programm oder die Übertragenen Variablen heraus zu finden. Abbildung 9.4: Variablenübergabe per GET-Methode Grundsätzlich kann jede Art von Programm oder Skript vom Webserver Apache ausgeführt werden. Es ist dem Webserver aber nicht erlaubt, beliebige Programme auszuführen. Man muss für Verzeichnisse in denen CGI-Programme ausgeführt werden sollen, die Option ExecCGI setzen 12 und eine (oder mehrere) Dateiendungen definieren. Nur Dateien, die die eingetragene Endung haben und sich in einem Verzeichnis befinden, für das ExecCGI gesetzt ist, werden vom Webserver als CGI-Script aufgerufen. Aus Sicherheitsgründen sollte man die Ausführung von Programmen nur ausserhalb von DocumentRoot erlauben. Oft wird die Ausführung nur für ein cgi-bin genanntes Verzeichnis erlaubt, das sich ausserhalb von DocumentRoot befindet. In Abbildung 9.5 wird erst ein Alias auf das cgi-bin Verzeichnis gesetzt. Mit AddHandler wird definiert, dass Dateien mit der Endung.cgi als cgi-script interpretiert werden. Innerhalb eines Directory-Containers bezüglich /usr/local/httpd/cgi-bin/ wird die Option ExecCGI zu den geltenden Optionen hinzugefügt. ScriptAlias /cgi-bin/ /usr/local/httpd/cgi-bin/ AddHandler cgi-script.cgi <Directory /usr/local/httpd/cgi-bin/> Options +ExecCGI </Directory> Abbildung 9.5: mod cgi 9.9 PHP Bei den statischen Webinhalten sind die HTML-Seiten, welche der Webserver ausliefern soll, üblicherweise als Datei abgelegt. Der Webserver liefert einfach die komplette Datei aus, wenn ein Client die entsprechende Resource anfragt. Bei den dynamischen Webinhalten dagegen wird die HTML-Ausgabe erst mit Hilfe einer Skriptsprache zur Laufzeit erzeugt. Hier gibt es wieder zwei unterschiedliche Techniken, die Clientseitigen und die Serverseitigen. Die clientseitigen Skriptsprachen werden auf dem Clients selbst ausgeführt. Hierzu zählt zum Beispiel die Eingabe von Formularfeldern. Die HTML Seite, welche vom Webserver ausgeliefert wird, enthält den Quelltext der jeweiligen Skriptsprache, der dann vom Client geparst und ausgeführt wird. Das bekannteste und eines der ältesten Beispiele einer clientseitigen Skriptsprache ist Javascript. Die Auswahl wuchs im Laufe der Zeit, so dass Flash, Java oder ActiveX inzwischen von vielen Browsern oder ihren Erweiterungen unterstützt werden. Damit der Client den Quelltext ausführen kann, ist natürlich die Unterstützung 12 siehe Kapitel 9.5.1

149 9.9. PHP 139 der Skriptsprache erforderlich. Dies geschieht mit Hilfe von Plugins, die der Benutzer im Client installieren muss. Hier fangen dann oft die Probleme an: Die Performance ist da ein entscheidender Faktor. Bei den clientseitigen Skriptsprachen muss der Client selbst die Rechenleistung, welche für die Ausführung des Codes notwendig ist, bereitstellen. Unter Sicherheitsaspekten schneiden clientseitige Implementierungen oft schlecht ab, da ein Skript auf dem Client-Rechner oft beliebigen Code ausführen kann und damit auch Manipulationen am System selbst vornehmen könnte. Die Browserunterstützung zählt zu den weiteren Problemen, mit welchem sich die clientseitigen Skriptsprachen befassen müssen. Denn nicht für jeden Web-Browser existiert ein passendes Plugin. Der Netzwerktraffic schafft oft ein weiteres Problem. Man stelle sich vor, dass man ein clientseitiges Flash-Skript, welches mehrere Megabyte groß ist, hat. Auch wenn man nur einen kleinen Teil des Flashskriptes benötigt, muss man das komplette Skript vor der Ausführung herunterladen, was einen u.u. unverhältnismässig hohen Netzwerktraffic mit sich bringt, der gerade für kleine mobile Endgeräte problematisch sein kann. Diese Art der Probleme tritt nicht auf, wenn man auf serverseitige Skriptsprachen setzt. Diese verändern oder generieren die HTML-Seite noch vor der Auslieferung an den Client. Wird also eine Anfrage an einen Webserver gestellt, dann wird der Quelltext des Skripts noch auf dem Webserver geparst und ausgeführt. Die serverseitigen Skriptsprachen können wiederum ihre Daten aus Datenbanken beziehen, wie das oft bei den Content Management Systemen (CMS) der Fall ist. Ist das komplette Skript abgearbeitet, dann wird die erzeugte HTML-Seite an den Client ausgeliefert. Hier wird natürlich die Unterstützung der Skriptsprache durch den Webserver vorausgesetzt. Das bedeutet, dass nur Netztraffic in Höhe der generierten Seite anfällt und sich die Sicherheitsrisikten für die Endanwender in Grenzen halten. Sie bekommen ja statisches HTML zu sehen. Diese Erweiterungen werden üblicherweise durch Module integriert. Bekanntestes Beispiel dürfte bei den serverseitigen Skriptsprachen PHP mit deinem Apache Modul mod php4 sein. Weitere gängige serverseitige Programmiersprachen stehen mit ASP und JSP zur Verfügung. Auch bei serverseitigen Skriptsprachen sollten einige Aspekte beim Einsatz beachtet werden. Das permanente Generieren von Seiten on-demand kann die komplette Rechenleistung auf dem Webserver beanspruchen, was je nach Zugriffscharakteristik zu Einbußen in der Performance führen kann Das Apache-PHP-Modul Das Modul mod php bietet die Möglichkeit, PHP-Code innerhalb von HTML-Seiten auszuführen. Für Dateien, die vom PHP-Interpreter geparst werden sollen, muss eine Endung definiert werden (Abbildung 9.6). Der PHP-Interpreter gibt den eingelesen HTML-Code unverändert an den Client weiter. PHP-Code wird interpretiert und das Ergebnis direkt an den Client weiter gegeben. Für den Client sieht das so aus, als würde er eine reine HTML-Seite erhalten.

150 140 KAPITEL 9. WEBSERVER <IfModule mod_php4.c> AddType application/x-httpd-php.php AddType application/x-httpd-php.php4 AddType application/x-httpd-php-source.phps </IfModule> Abbildung 9.6: mod php <html> <body> <?php?> print <h1>.$titel..$number. </h1> ;. Abbildung 9.7: PHP-Code 9.10 SSI (Server Side Includes) Apache stellt mit SSI eine Möglichkeit zur Verfügung, Internetseiten mit dynamischen Inhalten zu versehen. Um SSI verfügbar zu machen, muss zumindest für einen Teil der Dateihierachie innerhalb von DocumentRoot die Option Include (siehe Kapitel 9.5.1) gesetzt sein. Ausserdem muss ein Dateityp an die Funktionalität gebunden werden (Abbildung 9.8). <Directory /home/www/ssi_here/> AddHandler server-parsed.shtml AddType text/shtml.shtml Options +Include </Directory> Abbildung 9.8: mod ssi SSI-Befehle werden innerhalb des HTML-Codes mit <!--# eingeleitet und mit--> abgeschlossen. SSI-Dateien werden vom Server geparst und die SSI-Befehle entsprechend interpretiert. Das Ergebniss der Interpretation wird an der Stelle des Befehls in die HTML-Seite eingesetzt. SSI definiert eine Vielzahl von Umgebungsvariablen, bietet die Möglichkeit Systemprogramme auszuführen und beinhaltet Befehle zur Flusskontrolle (Abbildung 9.9). Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache des modernen WWW. Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat viel zur breiten Akzeptanz des Internets beigetragen.

151 9.11. ÜBERBLICK 141 <html> <!--#echo "$DOCUMENT_NAME last modified: $LAST_MODIFIED" -->... <!--#exec cmd="ls -la" -->... </html> Abbildung 9.9: SSI-Code 9.11 Überblick Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle: Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und ausliefert. URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine Ressource. z.b URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar. URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.b. urn:isbn: Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DE- LETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert. HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann. Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen Performace- Optimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge,...) zuordnen können. Dadurch können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver

152 142 KAPITEL 9. WEBSERVER über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene. HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen und Entwicklungen, die in den späten neunziger Jahren waren HTTP-Kommunikation Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache des modernen WWW. Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat viel zur breiten Akzeptanz des Internets beigetragen Überblick Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle: Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und ausliefert. URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine Ressource. z.b URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar. URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.b. urn:isbn: Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DE- LETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert. HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann. Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen Performace- Optimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge,...) zuordnen können. Dadurch

153 9.14. HTTP-KOMMUNIKATION 143 können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene. HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen und Entwicklungen, die in den späten neunziger Jahren waren HTTP-Kommunikation Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache des modernen WWW. Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat viel zur breiten Akzeptanz des Internets beigetragen Überblick Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle: Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und ausliefert. URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine Ressource. z.b URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar. URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.b. urn:isbn: Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DE- LETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert. HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann. Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen Performace- Optimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Ant-

154 144 KAPITEL 9. WEBSERVER worten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge,...) zuordnen können. Dadurch können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene. HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen und Entwicklungen, die in den späten neunziger Jahren waren HTTP-Kommunikation 9.17 Dokumentation Eine umfangreiche und gut strukturierte Dokumentation findet man unter: Der wohl am meisten verbreitete Webserver (nicht nur in der Linux-/Unixwelt) ist der Apache httpd. Er unterstützt eine ganze Reihe von Skriptsprachen, wie Perl und PHP über Module, Sicherungsmechanismen, wie SSL und weitere Plugins. Die Konfigurationsdateien (Hauptdatei: httpd.conf und SSL-Keys sind unterhalb von /etc/httpd zu finden.

155 Kapitel 10 Mail Elektronische Post ( ) ist sicher eine der wichtigsten und beliebtesten Anwendungen im Internet. Der Austausch von Nachrichten ist dabei gleichzeitig einer der ältesten Dienste im Netz. Um mit einer Linux-Maschine Mail versenden und empfangen zu können, reicht es im einfachsten Fall aus, die passenden Einstellungen in einem der vielen Mail-Clients vorzunehmen. Inzwischen stehen hierfür eine ganze Reihe von Programmen zur Verfügung; angefangen mit den ausschliesslich konsolenbasierten Programmen, wie pine oder mutt bis hin zu ausgewachsenen grafischen Anwendungen, wie kmail, thunderbird bzw. mozilla oder evolution. Diese Programme, die zum Einliefern von Mails an Server und zum Empfang dienen, werden als MUA (Mail User Agent) bezeichnet. Manchmal findet man noch die Bezeichnung MRA (Mail Retrieval Agent). Dieses sind Programme die automatisiert Mails von einem Server holen und für den lokalen Zugriff auf dem System des Benutzers ablegen. Hierzu zählt beispielsweise fetchmail. Serverpgrogramme, die Mails weiterverschicken und in den lokalen Mailboxen der Emfänger ablegen, nennt man MTA (Mail Transfer Agent). Für letzteres kommen oft externe Programme zum Einsatz, die dann MDA (Mail Delivery Agent) heissen. MTAs lassen sich selbstverständlich mit Linux als Server aufsetzen. Es stehen dabei mehrere Implementierungen des SMTP (Simple Mail Transfer Protocol) zur Verfügung. Das älteste und umfangreichste Paket ist sicherlich Sendmail (sendmail), wobei wegen der kryptischen Bedienbarkeit sich weitere Implementationen, wie Exim (exim) oder auch ProcMail (procmail) durchsetzen konnten. Dies ist jedoch nur die eine Seite des Postamtes. Der User holt sich seine postlagernden Sendungen entweder mit POP3 (Post Office Protocol) ab und sieht sie ein bzw. verwaltet sie mit IMAP4. SMTP (Simple Message Transfer Protocol) Es ist das Übertragungsprotokoll der Server untereinander und wird von den Clients zun Einliefern der Post benutzt. POP (Post Office Protocol; derzeit aktuell in der Version 3) Die Clients benutzen es, um ihre Post vom Server abzuholen. Entgegen dem SMTP besteht dabei die Möglichkeit, die Mail auch teilweise auf dem Server zu verwalten (allerdings nur in beschränktem Maße). IMAP (Internet Mail Access Protocol; derzeit aktuell in der Version 4) IMAP wird wie POP 3 von den Clients benutzt, um Mails vom Server abzuholen. Es bietet aber gegenüber POP wesentlich mehr Flexibilität bei der Verwaltung der Post, so z.b. die Möglichkeit, Eingangskörbe auf dem Server zu verwalten oder auch Roaming Users, also Anwender, die von verschieden Orten aus auf den Server zugreifen wollen. 145

156 146 KAPITEL 10. MAIL LDAP (Lightweight Directory Access Protocol) Eine leichte Variante des DAP (Directory Access Protocol), welches von X.500 für den Zugriff auf die Datenbasis benutzt wird. LDAP wird derzeit von den neueren Mailclients (Outlook, Netscape) unterstützt, um auf globale Verzeichnisdienste zuzugreifen (Netcenter, VeriSign, Bigfoot etc.) 10.1 SMTP Im Folgenden geht es um das Prinzip hinter Mail Transfer Agents - Programme, die entgegennehmen und weiterleiten. SMTP (Simple Mail Transfer Protokol) ist ein Protokoll zur Übertragung von zwischen zwei MTAs. Ein MTA kann als Client (SMTP-Client) oder als Server (SMTP-Server) an einer SMTP-Kommunikation beteiligt sein 1. Der SMTP- Client baut über Netzwerk eine Verbindung zu dem SMTP-Server auf, um an diesen E- Mail zu übertragen. Das Übertragen einer , inklusive der relevanten Daten, wird als Mailtransfer bezeichnet. Eine abgeschlossene Kommunikation per SMTP wird als SMTP- Sitzung bezeichnet. Während einer SMTP-Sitzung können mehrere s übertragen werden. SMTP definiert Befehle und Antwort-Codes. Befehle werden vom SMTP-Client an den SMTP-Server gesendet. Mit diesen SMTP-Befehlen kann der Client die Kommunikation steuern. Antwort-Codes werden vom SMTP-Server als Reaktion auf die empfangenen Befehle an den SMTP-Client gesendet. SMTP enthält mittlerweile deutlich mehr Funktionalitäten, als zum einfachen Übertragen von nötig sind. HELO hostname domain Mit HELO leitet der SMTP-Client die Kommunikation ein. Als Parameter soll der Hostname des Clients gesendet werden. Der Parameter muss vorhanden sein, wird aber nicht überprüft. 2 EHLO hostname domain Identisch zu HELO, nur dass der Client damit zu verstehen gibt, dass er einen erweiterten SMTP-Befehlssatz (des ESMTP) unterstützt. Der Server soll daraufhin mitteilen, welche Erweiterungen des Befehlssatzes für die Kommunikation zur Verfügung stehen. MAIL Dieser Befehl leitet das Übertragen einer ein. Als Parameter muss die Absenderadresse übergeben werden. RCPT Dieser Befehl kann beliebig oft auf MAIL folgen. Mit jedem Aufruf wird eine Empfängeradresse übergeben. Es muss mindestens ein Aufruf von RCPT erfolgen. DATA Mit DATA signalisiert der SMTP-Client, dass er den Inhalt (Mail-Body) der E- Mail übertragen möchte. Nach einer positiven Antwort des Servers wird die zeilenweise übertragen. Ein Zeile, die ausschliesslich einen Punkt (. ) enthält, beendet die Übertragung des Inhalts der . QUIT Um die Kommunikation zu beenden, sendet der SMTP-Client den Befehl QUIT. Eine erschöpfende Beschreibung von SMTP liefert RFC RFCs (Requests for Comments) sind öffentlich zugängliche Dokumente, die Standartprotokolle (in IP-basierten Net- 1 siehe Client-Server-Modell 2 Zu den Begriffen Host und Domain siehe Kapitel DNS.

157 10.1. SMTP 147 zen) definieren. Diese Dokumente werden von der Internet Engineering Task Force (IETF) veröffentlicht und sind über verschiedene Webseiten verfügbar 3. Die Übertragung von ist einer der ältesten und meist genutzten Netzwerk- Dienste entwickelte Ray Tomlinson ein Verfahren zur Übertragung von Textnachrichten über ein Netzwerk. Mit den Programmen SNDMSG und READMAIL war die erste Komunikation per möglich. Im Laufe der Jahre entwickelte sich das Verfahren stark weiter. Jonathan B. Postel veröffentlichte 1981 die erste Spezifikation von SMTP als RFC wurde diese durch RFC 821 (auch von Postel) ersetzt. Anfang der 90er Jahre ( ) wurden mehrere Erweiterungen zu SMTP spezifiziert, die 2001 schliesslich zu RFC 2821 führten, welches die vorherigen ersetzt Adresse Eine -Adresse besteht aus einem Local Part und einem Domain Part. Beide werden durch -Zeichen voneinander getrennt. Der Local Part besteht aus dem - auf dem empfangenden System bekannten - Namen des Empfängers. Der Domain Part bezeichnet die Empfänger-, bzw. die Absenderdomain. Er besteht aus einer weltweit eindeutigen Domainbezeichnung. Diese Domainbezeichnung identifiziert das empfangende System und muss über DNS auflösbar sein (siehe DNS). (RFC 2142) Versenden einer Am Versand einer sind mehrere sogenannte Agenten beteiligt. Ein Programm zum Lesen und Verfassen von wird als Mail User Agent (MUA) bezeichnet. Eine E- Mail kann während des Transfers mehrere Mail Transfer Agents (MTA, siehe Kapitel SMTP) durchlaufen. Als Mail Delivery Agent (MDA) bezeichnet man ein Programm, das lokal für den Empfänger verfügbar macht. Ein MDA bekommt eine von dem lokalen MTA übergeben und speichert diese in der Inbox 4 des Empfängers. Als Outgoing-SMTP-Server einer Domain bezeichnet man einen MTA, an den alle zu versendenden s einer Domain per SMTP übertragen werden. Dieser übernimmt die weitere Auslieferung. Ein Mailexchanger ist ein MTA, der für die Annahme von für eine bestimmte Domain zuständig ist. Der Name und damit die IP-Adresse des Mailexchangers einer Domain muss über DNS in einem MX-Record verfügbar sein (siehe Kapitel DNS). Der Mailexchanger verfügt über Informationen zur weiteren Auslieferung einer innerhalb seiner Domain. Diese kann per SMTP an einen weiteren MTA oder an einen lokalen MDA erfolgen. Eine in einem MUA verfasste wird an den lokalen MTA übergeben, der sie per SMTP an den Outgoing-SMTP-Server seiner Domain übermittelt 5. Dieser wiederum sendet sie an den Mailexchanger der Empfängerdomain, welcher für die lokale Zustellung der in die Inbox des Empfängers zuständig ist. Tabelle 10.1 zeigt eine typische einfache SMTP-Sitzung zum Übertragen einer . Der SMTP-Client nimmt Kontakt zum SMTP-Server auf, der die Kontaktaufnahme mit dem Antwort-Code 220 und Informationen über sich selbst bestätigt. Daraufhin leitet der Client die Kommunikation mit HELO ein. Die mit HELO übergebene Zeichenkette soll der Identifikation dienen, wird aber an dieser Stelle ungeprüft übernommen. Wie es sich für u.a. 4 Im Deutschen oft einfach als Posteingang bezeichnet. 5 Viele MUAs sind in der Lage, die Aufgabe eines SMTP-Clients selbst zu übernehmen.

158 148 KAPITEL 10. MAIL Server: 220 golem.ehlers-schwichtenberg.info ESMTP Postfix Client: HELO schwichtenberg.net S: 250 golem.ehlers-schwichtenberg.info C: MAIL FROM: S: 250 Ok C: RCPT TO: S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Der Mail-Body. S: 250 Ok: queued as C1AD92BC346 C: QUIT S: 221 Bye Tabelle 10.1: Einfache Übertragung eine mit SMTP einen höflichen Server gehört, antwortet dieser mit seiner eigenen Identifikation. Mit dem Befehl MAIL wird die Übertragung der eigentlichen - der Mailtransfer - begonnen. Als Parameter werden FROM: und die Absenderadresse in spitzen Klammern übergeben. Nun kann der Client wiederholt Empfängeradressen mit dem Befehl RCPT und TO: und der Empfängeradresse in spitzen Klammern übertragen. Sowohl der Befehl MAIL als auch jeder Aufruf von RCPT wird bei Erfolg von dem Server mit dem Antwort-Code 250 OK beantwortet. Einige SMTP-Server überprüfen die Existenz der Absenderadresse. In jedem Fall sollte der Server überprüfen, ob er für die Zustellung von für die Empfängeradressen zuständig ist. Bei negativem Ergebnis sendet der Server einen Fehler-Code, um die Annahme der 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 für jegliche Empfängeradresse annimmt, bezeichnet man als Open-Relay (siehe Kapitel ). Sind alle Empfängeradresse übermittelt, wird die eigentliche Nachricht, der Mail-Body (siehe Kapitel ) übertragen. Der Client teilt dem Server mit dem Befehl DATA mit, dass er den Mail-Body übertragen möchte. Der Server sendet den Antwort-Code 354, um zu signalisieren, dass der Client mit dem zeilenweisen Übertragen der Nachricht fortfahren kann. Diese Übertragung wird mit einer Zeile, die einen einzelnen Punkt (. ) enthält, beendet, woraufhin der Server den Empfang mit 250 OK und der Identifikationsnummer, unter der er die Mail verwaltet, bestätigt. Damit ist der Mailtransfer beendet. Nun kann der Client mit MAIL einen weiteren Mailtransfer einleiten oder die Verbindung mit QUIT beenden Mail-Body Der Mail-Body besteht aus Headerzeilen mit Informationen über die und - getrennt durch eine Leerzeile - dem eigentlichen Text der Nachricht. Die meisten Headerzeilen werden von MUAs nicht angezeigt 6. Die während der SMTP-Sitzung übertragen -Adressen dienen in erster Linie den MTAs zur Auslieferung bzw. zur Rückführung einer . 6 Meistens ist es möglich, die Darstellung des kompletten Haeders einzuschalten.

159 10.1. SMTP 149 Return-Path: X-Original-To: Delivered-To: Received: from schwichtenberg.net (shani.schwichtenberg.net [ ]) by golem.ehlers-schwichtenberg.info (Postfix) with SMTP id C1AD92BC346 for Tue, 9 Mar :05: (CET) Message-Id: < C1AD92BC346@golem.ehlers-schwichtenberg.info> Date: Tue, 9 Mar :05: (CET) From: fschwic@schwichtenberg.net To: undisclosed-recipients:; Der Mail-Body Tabelle 10.2: Die aus Tabelle 10.1 Steht nach einem Mailtransfer in dem Mail-Body noch keine mit From: beginnende Zeile, kann der MTA diese Zeile mit der Absenderadresse einfügen. Date, Subject, To, From oder Äquivalente sollten in einer von vornherein vorhanden sein (RFC 822); sie können schon bei der ersten Auslieferung der per SMTP im Mail-Body stehen. Die SMTP-Sitzung aus Tabelle 10.1 führt dazu, dass die aus Tabelle 10.2 in der Inbox des Empfängers abgespeichert wird, wobei der Empfänger in dem MUA, mit dem er seine liest, normalerweise nur die Zeilen Date:..., From:..., To:... und den Text der Nachricht angezeigt bekommt. Ein MTA fügt zu jeder empfangenen Haederzeilen hinzu, die bei weiteren Übertragungen per SMTP Bestandteil des Mail-Body sind Header Der Header einer besteht aus mehreren Headerzeilen. Eine Headerzeile ist ein Eintrag, der mit einem Bezeichner gefolgt von einem Doppelpunkt und einem Leerzeichen beginnt. Besteht eine Headerzeile aus mehreren Textzeilen, so müssen die folgenden Textzeilen mit einem Whitespace beginnen. Bezeichner für Headerzeilen, die in keinem Standart definiert sind, müssen mit X- beginnen (RFC 2821). Return-Path Ein MTA, der eine endgültig zustellt 7, muss die Zeile Return-Path: <adresse> an den Anfang der setzen. Die einzutragende Adresse ist die während des Mailtransfers mit MAIL übergebene Absenderadresse (RFC 2821). Received Jeder MTA, der eine angenommen hat, muss vor der weiteren Auslieferung eine Received-Zeile an den Anfang des Mail-Body schreiben. Eine solche Zeile ist in drei Bereiche 7 final delivery ; wenn der MTA die an einen MDA übergibt oder in anderer Form aus dem SMTP-System nimmt.

160 150 KAPITEL 10. MAIL unterteilt: 1. Informationen über den SMTP-Client eingeleitet mit from. Dieser Bereich enthält die Identifikation des Clients. In der Regel ist das die mit HELO oder EHLO übergebene Zeichenkette. Zusätzlich sollen in runden Klammern TCP-Informationen über den Client eingefügt werden. Die meisten MTAs fügen die IP-Adresse des SMTP-Client (in eckigen Klammern) und den daraus resultierenden Hostnamen ein. 2. Informationen über den SMTP-Server selbst. Beginnend mit by werden der Hostname des Servers und Informationen über den Empfang (meistens Art der Software, Empfangsprotokoll und Identifikationsnummer der im Server) eingefügt. 3. Informationen über den Empfang der mit for, gefolgt von der mit RCPT übergebenen Empfängeradresse und - getrennt durch ein Semikolon - der Zeitpunkt des Empfangs. Weitere Headerzeilen Massage-Id: soll von dem System erzeugt werden, das die erstellt. Diese Zeile ist nicht zwingend erforderlich. Date, From, To und Subject sollen von vornherein Bestandteil einer sein (RFC 822). Der MUA in dem die erstellt wurde sollte diese Headerzeilen eintragen. Wenn diese nicht vorhanden sind, kann ein MTA sie einfügen. Die Einträge X-Original-To: und Deliverd-To: aus Tabelle 10.2 werden speziell von dem MTA Postfix eingefügt. Sie widersprechen dem Standart nicht, sind aber auch nicht verlangt Open-Relay Ein Open-Relay ist ein Mailexchanger oder ein Outgoing-SMTP-Server, der von beliebigen MTAs für beliebige Empfängeradressen annimmt und weiterleitet. Da die Angabe der Absenderadressen während einer SMTP-Sitzung nur unzureichend oder gar nicht überprüft wird, ermöglicht ein Open-Relay jedermann das anonyme Versenden von (siehe Kapitel ). Ein Mailexchanger sollte nur annehmen, deren Empfängerdomain in seinem Zuständigkeitsbereich liegt. Ein Outgoing-SMTP-Server sollte nur von authorisierten MTAs zur Weiterleitung annehmen Sicherheit Die Tatsache, dass unverschlüsselt übertragene 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 vorhanden sind, wenn sie beim Empfänger ankommt (siehe Kapitel ) und wie SMTP mißbraucht werden kann. Das Abholen von eines Benutzers von seiner Inbox ist nicht Bestandteil der SMTP-Übertragung. Der Benutzer kann direkten Zugriff auf seine Mailbox haben oder Protokolle wie POP oder IMAP benutzen. In diesem Bereich geht es hauptsächlich darum, dass kein Unbefugter auf die Mailbox zugreifen kann.

161 10.1. SMTP 151 Hat ein Benutzer eine verfasst, wird er diese in der Regel per SMTP an den Outgoing-SMTP-Server seiner Domain oder seines Providers übertragen. Die Übermittlung an einen Outgoing-SMTP-Server des Providers ist unproblematisch, da der Provider seine Kunden kennt und den Zugriff über die Kenntnis der IP-Adresse des Kundenrechners oder über die Vergabe eines Passwortes einschränken kann. Gleiches gilt für den Outgoing- SMTP-Server einer Domain, wobei hier die SMTP-Kommunikation sogar über ein geschlossenes internes Netzwerk erfolgt. In Bereichen, wo eingehende in einem internen Netzwerk verteilt werden muss, gibt es einen (oder auch mehrere) Mailexchanger, der aus dem Internet annimmt. Die interne Weiterleitung erfolgt in einem abgeschlossenen Netzwerk, in dem sich alle Rechner vertrauen können. In den frühen Zeiten des Internet war es notwendig, über eine Kette von SMTP- Servern zu übertragen, da sich nicht alle Rechner direkt erreichen konnten. Aus dieser Zeit stammt der Begriff des Mailrouting. Heutzutage ist die Entwicklung der Netzwerktechnologie und des Internet so weit, dass sich alle im Internet befindlichen Rechner gegenseitig erreichen können 8. Man kann also die sicherheitskritische Betrachtung des -Verkehrs auf die Kommunikation zwischen Outgoing-SMTP-Server, in der Rolle des SMTP-Client, und Mailexchanger als SMTP-Server reduzieren. Es sind durchaus Systemarchitekturen denkbar, die von einem so einfachen Modell abweichen. Diese lassen sich aber darauf zurückführen. Die Angaben, die von einem SMTP-Client während einer SMTP-Sitzung gemacht werden, sind fast beliebig. Nicht einmal an Stellen, an denen eine -Adresse erwartet wird, muss wirklich eine übertragen werden. Enthält eine Zeichenkette, die als -Adresse interpretiert wird, -Zeichen, geht der SMTP-Server normalerweise davon aus, dass es sich um einen Benutzernamen innerhalb seines Systems handelt und hängt gefolgt von seinem Domainnamen an. Die Identifikation des HELO oder EHLO-Befehls ist vollkommen beliebig. Empfängeradressen zu fälschen macht wenig Sinn. Jeder möchte, dass eine von ihm verschickte irgendwo ankommt. Ein ehrlicher Benutzer hat keinen Grund, eine falsche Absenderadresse anzugeben. Er hat Interesse daran, dass der Empfänger der ihm antworten kann und möchte auch benachrichtigt werden, wenn bei der Übertragung der Nachricht etwas schief geht. Ein Versender von unerwünschter 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 lahmlegen 9. Auch wäre es unter bestimmten Bedingungen möglich, ihn juristisch zur Verantwortung zu ziehen. Alle anderen Werte einer sind schon während der Übertragung Bestandteil des Mail-Body (siehe Kapitel ). Der Versender einer kann sich Werte für Absender ( From: ), Empfänger ( To: ), Betreff ( Subject: ) usw. und beliebige Received: -Zeilen ausdenken. Die einzigen verlässlichen Angaben sind die in der Received-Zeile des letzten MTA. Da dieser das System ist, von dem man seine direkt bezieht, kann man diesen Einträgen 8 Rechner hinter einem maskierenden Gateway muss man durchaus als nicht im Internet befindlich ansehen. Und solche, die sich hinter einer Firewall befinden, sind unter Umständen nicht erreichbar, obwohl sie sich im eigentlichen Sinn im Internet befinden. Nur bedeutet die Tatsache, dass ein Rechner einen Verbindungsaufbau ablehnt, natürlich nicht, dass man ihn nicht erreichen kann. 9 Was für einen Nutzen das Versenden einer solchen Nachricht für den Absender haben kann, soll hier nicht diskutiert werden. Es reicht aus, dass sowohl die Betreiber von Mailservern als auch die Empfänger maßgeblich belästigt werden.

162 152 KAPITEL 10. MAIL vertrauen. Kommando Argument Beschreibung HELO Systemname Beginn, Name des sendenden Systems MAIL From: Absenderadresse Beginn der Übermittlung RCPT To: Empfängeradresse Adressat der DATA Daten... Brieftext, Ende durch eine Zeile mit. HELP Topic Hilfestellung VRFY Mailadresse Mailadresse verifizieren EXPN Mailadresse Mailadresse expandieren (z. B. Liste) RSET Senden abbrechen, Zurücksetzen NOOP nichts tun QUIT Verbindung beenden Tabelle 10.3: Grundsätzliche SMTP-Befehle 10.2 sendmail Das Paket sendmail ist eines der ältesten INTERNET-Programme und wohl auch das mit dem schlechtesten Ruf. Am Anfang war es aufgrund diverser Sicherheitslücken ein beliebtes Einfalltor für Hacker und Co.; bei den Administratoren ist es wegen seiner schwierigen Konfiguration gefürchtet. Dennoch hat es sich zum Standard für UNIX/LINUX-MTAs erhoben und verdient auf jeden Fall eine genauere Betrachtung. Mit den Jahren ist sendmail, was die Sicherheit anbelangt, wesentlich besser geworden. Da es als OpenSource zur Verfügung steht, hatten Gott und die Welt Zeit und Muße, den Quellcode auf Fehler abzuklopfen und diese auszumerzen. Sendmail ist daher bei anständiger Konfiguration nicht unsicherer als andere Dienste auf einem UNIX-Server. Was die Konfiguration angeht, so haben sich die Programmierer die Kritik zu Herzen genommen und ein Tool entwickelt, welches die Arbeit erleichtert. Dieses Tool namens IDA ist bei SuSE im sendmail-paket bereits enthalten und wird intern von YaST aufgerufen exim Die Installation eines eigenen Mailservers auf einer Linux-Maschine hat den entscheidenden Vorteil, dass man die von selbst oder von anderen erstellten Mails jederzeit abschicken kann. Somit muss nicht jeder einzelne Client mit einem externen Mailserver die Verbindung aufbauen, sondern es lassen sich firmen-/organisationseigene Maildienste realisieren. Dazu muss aber zunächst z.b. exim neu konfiguriert werden (z.b. mittels eximconfig. Hierfür muss man über SuperUser-Rechte verfügen.): hermes:/# eximconfig You already have an exim configuration. Continuing with eximconfig will overwrite it. It will not keep any local modifications you have made. If that is not your intention, you should break out now. If you do continue, then your existing file will be renamed with.o on the end. [---Press return---]

163 10.4. POP 153 Kommando Argument Beschreibung USER Name Das Argument identifiziert eine Mailbox PASS String Der String enthält ein Mailbox-spezifisches Passwort QUIT Beendet die Verbindung Kommando Argument STAT Tabelle 10.4: Kommandos im Authorization State Beschreibung Liefert die Anzahl der gespeicherten Mails und die Größe der Mailbox zurück (in Byte) LIST Nummer Liefert die Nummer und Größe (in Bytes) aller Mails zurück Wird als Argument eine Mail-Nummer angegeben, wird nur die Größe dieser Mail ausgegeben RETR Nummer Gibt die Mail mit der als Argument übergebenen Nummer aus DELE Nummer Löscht die Mail mit der übergebenen Nummer NOOP RSET QUIT 10.4 POP Bewirkt die Antwort +OK. Dient zur Aufrechterhaltung der Verbindung, ohne daß ein Time-Out auftritt Setzt die aktive Verbindung zurück. Noch nicht ausgeführte Änderungen werden verworfen Beendet die Verbindung und führt alle gespeicherten Änderungen aus Tabelle 10.5: Kommandos im Transaction State Für den Transport bis zum Server mit dem Postfach findet i.d.r. das SMTP- Protokoll Anwendung. Da Benutzerrechner, auch in Zeiten totaler Vernetzung, nicht permanent im Netz sind wird die Übertragung zum Client des Empfängers getrennt geregelt. Häufig findet, seiner Einfachheit wegen, das Post Office Protocol in Version 3 (POP3) Einsatz. Auf der Seite des Servers bearbeitet der POP3-Daemon, entweder durch (x)inetd oder permanenten Daemon realisiert, auf Port 110 eingehende Verbindungen und stellt die E- Mails eines, durch Postfachname und Kennwort authentifiziertes Postfach, den Clients zur Verfügung. Eine komfortable Verwaltung der s bereits auf dem Postfach-Server ist mit POP3 nicht möglich. So muß eine s vor dem lesen komplett vom Client geladen werden und wird in Regelfall nach der Übertragung vom Server gelöscht. Dies führt zu inkonsistenzen beim gleichzeitigen Einsatz verschiedener Clients für ein Postfach. Denn Mails, welche bereits abgerufen wurden, sind für die anderen Clients nicht mehr erreichbar. Das vollständige Abrufen aller s vom Server hat Vorteile wenn eine Verbindung per Modem realisiert ist, da diese nach erfolgter Übermittlung wieder getrennt werden kann und keine weitere Kosten verursacht. Da das POP3 Protokoll sehr einfach aufgebaut ist kann man ein Postfach ggf. auch per Telnet bedienen: user@linux:/> telnet pop3.postfachserver.de 110 Trying a.b.c.d... <-- IP Adresse des POP3-Servers Connected to pop3.postfachserver.de. Escape character is ^]. +OK (rwcrpxc13) POP3 server USER username <-- Nutzer-/ Postfachname

164 154 KAPITEL 10. MAIL +OK PASS password +OK Maildrop ready LIST <-- Kennwort <-- Liste der s im Postfach anfordern +OK scan listing follows <-- Laufende Nummer der s und deren Gr201ï 1 2 [7m201ï 1 2 in Byte. RETR 1 <-- Anfordern von Mail Nummer 1 +OK Message follows Return-Path: <user@absender.net> Received: from mail.postfachserver.de ([unix socket]) by srv1 (Cyrus v2.1.15) with LMTP; Mon, 10 May :05: X-Sieve: CMU Sieve 2.2 Received: from absender.net (absender.net [a.b.c.d]) by pop3.postfachserver.de ( /8.12.6/SuSE Linux 0.6) with ESMTP id i4h55hqd for <user@postfachserver.de>; Mon, 10 May :05: Message-ID: <40A845E @sender.de> Date: Mon, 17 May :56: From: "Nutzername" <user@absender.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-us; rv:1.6) Gecko/ X-Accept-Language: de-de, en-us MIME-Version: 1.0 To: user@postfachserver.de Subject: test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.6 required=4.8 tests=awl,bayes_10,user_agent_mozilla_ua version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 ( exp) test. STAT <-- Anzahl der s im Fach +OK und deren Gesamtgröße DELE 1 <-- Löschen von Nummer 1 +OK message deleted LIST <-- Liste der s im Postfach +OK scan listing follows QUIT <-- Verbindung beenden +OK Connection closed by foreign host. Verbleibt noch die Nennung der Befehle RSET, welches Markierungen (als gelesen) einzelner s rückgängig macht, und TOP #msg #lines (optional) um von #msg die #lines angezeigt zu bekommen. An dieser Stelle ist auch ersichtlich, dass Benutzername und Kennwort in Klarschrift übertragen werden. Um das Postfach über eine verschlüsselte Verbindung abzurufen kann POP3 über SSL/TLS, auf Port 995, realisiert werden.

165 10.5. IMAP 155 Auf dem Server werden die s in zwei Ablageformaten verwaltet. Entweder im Mailbox-Format, wo alle Mails in einer fortlaufenden Datei je Nutzer im Verzeichnis /var/spool/mail gehalten werden oder im Maildir-Format, wo i.d.r. in einem Verzeichnis im Homevezeichnis des Nutzers je einer Datei pro abgelegt wird. Das Mailbox-Format kann viele kleine s, wie dies in der vorkommerziellen Ähra des Internets noch üblich war, ohne große Belastung der Server-Festplatten verarbeiten, verbraucht aber bei großen s viel Speicher. Beim Maildir-Format sind die Ansprüche an die Massenspeicher höher dafür die Speicherbelastung geringer, da nur einzelne Dateien verarbeitet werden müssen. Um mit POP3-Servern eine Filterung der Mails zu ermöglichen muß dies beim MTA implementiert werden. Denn der MTA stellt ankommende s direkt in die lokale Mailbox IMAP Für eine komfortable Verwaltung von s bereits auf dem Postfach-Server wurde das Internet Message Access Protocol (IMAP) entwickelt. Im Gegensatz zu POP3 verbleiben die s auf dem Server. Damit kommt IMAP vorallem den Bedürfnissen mobiler Benutzern entgegen, denn auch bei gleichzeitiger Verwendung verschiedener Mail-Client-Software und/oder Webfrontend bleiben die Daten konsistent. Die aktuelle Versionsnummer ist 4 und hat einen Komplexitätsgrad erreicht, welcher durch kaum einen IMAP-Client vollständig unterstützt wird. Um die s eines Postfaches lesen zu können wird, analog dem zum POP3 Protokoll, eine Verbindung zum Server aufgebaut. Bei IMAP werden im ersten Schritt nur die Headerinformationen der Mails im Postfach abgerufen und erst bei Bedarf, wenn der Inhalt der Mail beim Nutzer von Interesse ist (angezeigt durch Auswahl), der Body nachgeladen wird. Dies hat den Vorteil, dass eine mit großem Anhang nicht unnötig über eine langsame Modemleitung gesendet wird, denn bei Bedarf kann eine große von einem Terminal mit schnellerer Netzanbindung geladen werden ohne auf die Verwaltung und Beantwortung der verbleibenden Mails verzichten zu müssen. Ein weiterer Vorteil ist die Organisation des Postfaches mittels Unterverzeichnisse. Für IMAP sind Erweiterungen möglich, so z.b. der Zugriff auf Ordner durch verschiedene Nutzer. Damit lassen sich Arbeitsprozesse für Gruppen vereinfachen und Datenaufkommen durch Versenden von Kopien vermeiden. Diese Methode läßt sehr differenzierte administrative Einstellungen zu. Der Preis des Komforts ensteht durch aufwendige Serverimplementationen mit deutlich höheren Anforderungen an CPU und Speicher gegenber POP3-Servern. Desweiteren dauert eine IMAP-Sitzung bis der Nutzer diese beendet (oder Time-outs beim Server die Verbindung trennen). Damit sind die Kosten für Einwahlverbindungen i.d.r. höher. Dies läßt sich aber durch den Wechseln zwischen POP3 und IMAP, was durch die meisten IMAP-Server unterstützt wird, kompensieren. Drei der beliebtesten IMAP-Server fr Unix/Linux sind Courier-, Cyrus- und UW-IMAP. Alle bieten sehr umfangreiche Funktionen und Erweiterungsmöglichkeiten und sind für eine große Anzahl an Postfächern ( 20k) geeignet. So lassen sich z.b. die Postfach-Nutzer von den Systemnutzern trennen, Mailfilter-Sprachen einbinden und Quotas festlegen (was dringend empfohlen wird, da die Nutzer die Mailboxen meist als privaten File-Server missbrauchen). Es gibt daneben auch noch imap-daemonen welche IMAP, sehr rudimentär und ohne Funktionen welche über POP3 hinaus gehen, bereitstellen.

166 156 KAPITEL 10. MAIL Leider unterstützt kaum ein Client die Funktionen z.z. vollständig. Mulberry und pine sind zwei der seltenen Ausnahmen mit sehr umfangreichen IMAP-Funktionen. Die s werden entweder in einem Verzeichnis im Homeverzeichnis des Servers bereitgestellt oder unter /var/spool/imap in Nutzerverzeichnissen. Im Gegensatz zu POP3 ist nicht der MTA für die Abspeicherung neuer Mails zuständig, sondern der IMAP-Server selbst. Deshalb hat i.d.r. auch nur der IMAP-Server zugriff auf die entsprechenden Verzeichnisse, welche dieser u.a. mit separaten Index- und Quota-Tabellen für schnelleren Zugriff verwaltet. Die Haltung der s als quasi File-Server stellt erhöhte Ansprüche an die Festplatten und Speicherausstattung. Zum Einen müssen die Speicherkapazitäten wachsen, da die durchschnittlich auf dem Server gehaltenen Datenmenge gegenber POP3 drastisch ansteigt. Zum Anderen sind die Zugriffzeiten ausschlaggebend für die Gesamtperformance des Servers, da die Anzahl der Dateien steigt. Dies sind ausschlaggebenden Gründe warum IMAP-Server immer noch selten betrieben werden. Der Standard-Port für IMAP ist 443 und für IMAPS, die Variante über SSL/TLS, ist 993 reserviert Aufgaben Dienste 1. Welche IP Adresse hat der Server Womit wird diese ermittelt? 2. Wie heisst der Server mit vollständigem Rechner- und Domainnamen? 3. Welche TCP und UDP Ports sind auf dem Dozentensystem offen? Welchen Diensten sind diese zuzuordnen?

167 Kapitel 11 Fileserver 11.1 Unix-Netzwerkdateisystem - NFS NFS, das Network File System, ist wahrscheinlich der populärste und am häufigsten eingesetzte RPC basierende Netzwerkdienst. Er erlaubt, entfernte Verzeichnisse auf anderen Hosts so zu benutzen, als lägen diese Dateien lokal vor. Dies wird durch eine Mischung aus Kernel-Funktionalität auf der Client- und Server-Seite realisiert. Der Dateizugriff ist für den Client völlig transparent und funktioniert für eine ganze Reihe von Server- und Host-Architekturen. NFS bildet jede Art des Zugriffs auf Verzeichnisse und Dateien über einen Remote Procedure Call ab. Das erlaubt auf der einen Seite den gemeinsamen schreibenden Zugriff von mehreren Clients auf ein Dateisystem. Auf der anderen Seite generieren die verschiedenen Remote Procedure Calls gerade auf kleinen Dateien einen nicht unerheblichen Overhead. Dieses kann man sehr leicht ausprobieren in dem man einfach mal die Zeit misst, die es braucht ein Verzeichnis mit sehr vielen kleinen Dateien auf einer NFS-Quelle zu kopieren oder dasselbe mit einer einzigen gleichgrossen Datei anzustellen. NFS wird traditionell über das Transportprotokoll UDP abgewickelt, die Version 3 erlaubt eine alternative Verwendung von TCP. Es arbeitet als Remote Procedure Call (RPC) Dienst und erfordert für seinen Einsatz das Vorhandensein des Portmap-Daemonen (portmap). Die beiden alten Daemonen, die im Userspace agieren, heissen deshalb auch rpc.nfsd und rpc.mountd. Sie werden üblicherweise über ein gemeinsames Startskript bei SuSE /etc/init.d/nfsserver gestartet, welches bei seiner Einrichtung darauf achtet, dass der Portmapper vorher aufgerufen wird. Die Daemonen des Kernelspaces werden mittels analogen Startskriptes aufgerufen, wobei für den NFS-Daemon standardmäßig vier Threads gestartet werden. Die Zahl kann für hohe Anforderungen jedoch stark gesteigert werden. In den wenigsten Fällen lassen sich beide NFS-Implementationen problemlos nebeneinander installieren, da gemeinsame Dateien, wie das Startskript einge wesentliche Unterschiede aufweisen. Für wechselnde Experimentierumgebungen mit beiden Servertypen sind Anpassungen mindesten der Init-Skripten notwendig. Die Unterstützung für das Network Filesystem muss sowohl im Server- Kernel als auch im Kernel der Clients aktiviert sein. Im Kernel des Servers sollte für Test- und Überwachungszwecke auch die Clientunterstützung aktiviert sein. So kann über ein einfaches Loopbackmounten von NFS-Freigaben sehr leicht überprüft werden, ob diese korrekt eingerichtet sind. NFS bietet eine Reihe nützlicher Features: Daten, auf die von allen Benutzern zugegriffen wird, können auf einem zentralen Host gehalten werden - zentraler Fileserver für Home-Verzeichnisse. Clients mounten dieses 157

168 158 KAPITEL 11. FILESERVER Verzeichnis während der Bootphase bzw. wärend des Logins des Benutzers. Daten, die sehr große Mengen an Plattenspeicher einnehmen, können auf einem einzigen Rechner vorgehalten werden. So könnten etwa die Office-Pakete Star- oder OpenOffice an einer Stelle gespeichert und administriert werden. Administrative Daten können auf einem Host gehalten werden. So kann die Mühe entfallen bestimmte Datensätze nach ihrer Aktualisierung auf viele Homeverzeichnisse. Clients mounten dieses Verzeichnis während der Bootphase bzw. wärend des Logins des Benutzers. Die besondere Stärke liegt hier in der Verbindung mit NIS. So können sich die Benutzer dann an jedem System einloggen und arbeiten dennoch mit nur einem Satz von Dateien. Daten, die sehr große Mengen an Plattenspeicher einnehmen, können auf einem einzigen Rechner vorgehalten werden. So könnten etwa die Office-Pakete Star- oder OpenOffice an einer Stelle gespeichert und administriert werden. Administrative Daten können auf einem Host gehalten werden. So kann die Mühe entfallen bestimmte Datensätze nach ihrer Aktualisierung auf viele Rechner zu verteilen. NFS kann sowohl auf das Transportprotokoll UDP als auch TCP zurückgreifen. Die Verwendung von TCP ist jedoch erst in den neueren Versionen 3 und 4 ünterstützt. Es arbeitet als Remote Procedure Call (RPC) Dienst und erfordert deshalb für seinen Einsatz das Vorhandensein des Portmap-Daemonen (portmap). Die Daemonen zur Bereitstellung von NFS-Diensten werden üblicherweise über ein gemeinsames Startskript, bei SuSE /etc/init.d/nfsserver gestartet, welches bei seiner Einrichtung darauf achtet, dass der Portmapper vorher aufgerufen wird. Die Zahl der NFS-Daemonen liegt standardmäßig bei vier Threads. Die Zahl kann für hohe Anforderungen jedoch stark gesteigert werden. Die Unterstützung für das Network Filesystem muss sowohl im Server-Kernel als auch im Kernel der Clients aktiviert sein. Alternativ zur statischen Variante kann die NFS-Fähigkeit des Kernels auch mittels Module nachgeladen werden. Sein Alter merkt man NFS jedoch auch an: Es verfolgt ein generalistischen Ansatz und versucht es jedem Anwendungszweck einigermassen recht zu machen. Bis einschliesslich Version 3 muss das Sicherheitskonzept von NFS als weitgehend nichtexistent bezeichnet werden, da die IP-basierte und überhaupt nicht nutzerbasierte Authentifizierung, Angriffe auf die Daten in Benutzer-Homeverzeichnissen kaum abhalten konnte NFS im Einsatz Eine Freigabe, bei NFS export genannt, definiert man auf dem Server in der Datei /etc/exports: /home /home / (rw,async) *.my-domain.site(rw,async) Im Beispiel wurde das Home-Verzeichnis aller Benutzer für alle Maschinen im Subnetz mit der Netzmaske freigegeben. Freigaben lassen sich auf einzelne Maschinen oder auch auf Rechnernamen vornehmen. Letzteres zeigt die zweite Freigabe an alle Rechner deren IP-Adresse aufgelöst Mitglied der Domain my-domain.site sind. Der Beispielexport legt fest, dass das Clients auf der Freigabe schreiben dürfen, der Benutzer root jedoch davon ausgenommen ist. Für alle Schreibvorgänge wird eine sofortige Bestätigung

169 11.1. UNIX-NETZWERKDATEISYSTEM - NFS 159 angefordert. Mit der Option async für asynchrones Schreiben kann man das Schreib- und Leseverhalten verbessern, jedoch sinkt damit die Datensicherheit beim Schreiben. Dass der Systemadministrator vom Zugriff ausgeschlossen wurde, ist jedoch nur eine minimale Hürde Angreifern gegenüber. Es hindert keiner diese daran, einfach die passenden Benutzer-IDs auf seinem lokalen System anzulegen und sich dann mit diesen IDs in den interessierenden Verzeichnissen zu bewegen. Ein NFS-Server muss je nach Einsatzgebiet und Anzahl der zugreifenden Clients einges leisten. Von ihm hängt die Performance des Zugriffs auf entfernt liegende Dateien auf den Clients ab. Eine leistungsfähige CPU, viel Hauptspeicher, nicht zu langsame Festplatten und eine gute Netzwerkverbindung sind entscheidende Faktoren. Mit der heute üblichen Leistung auch der Einstiegsprozessoren, die man auf vielen Clients finden wird, kann eine 100 Mbit-Leitung durchaus bis an ihre theoretische Transfergrenze von über 10 Mbyte/s ausgelastet werden. Soll es nicht zu unnötigen Wartezeiten auf den Clients kommen, sollte der Server über ein oder mehrere Gigabit-Netzwerkinterfaces verfügen, die idealerweise an der Switch angeschlossen sind, welche die Verteilung an die Endgeräte übernimmt. Damit nicht alle Daten erneut von der Festplatte in den Hauptspeicher und dann über das Netzwerk geschaufelt werden müssen, macht ein großer Arbeitsspeicher Sinn. Durch diesen wird ein Cache häufig angeforderter Festplattenblöcke angelegt, welche dann direkt aus dem Hauptspeicher an den anfragenden Client ausgeliefert werden können NFS und Portmapper Das Network File System benötigt Remote Procedure Calls (RPC). Der Portmapper - repräsentiert durch den Dienst portmap - ordnet RPC-Anfragen den korrekten Dienste zu. RPC-Prozesse benachrichtigen portmap, wenn sie starten. Des Weiteren teilen die Anfragen die überwachte Port-Nummer sowie die Nummern des RPC-Programms mit, die aufgerufen werden. Der Client kontaktiert den Portmapper auf dem Server mit einer bestimmten RPC-Programmnummer. Dieser leitet dann den Client zur richtigen Port-Nummer um, damit er mit dem gewünschten Dienst kommunizieren kann. Da RPC-basierte Dienste für die Verbindungen mit ankommenden Client-Anfragen von portmap abhängig sind, muss er gestartet sein, bevor einer dieser Dienste gestartet wird. Andernfalls beobachtet man sehr lange Wartezeiten zum Beispiel bis zum Abschluss eines NFS-Mounts. Für die Zugriffssteuerung auf RPC-basierte Dienste des Servers kann man die Host-Zugriffsdateien (/etc/hosts.allow und /etc/hosts.deny) verwenden. Will man im Bereich RPC-Dienste debuggen, ist eine Zugeordnung der Portnummern sehr nützlich. Der Befehl rpcinfo zeigt jeden RPC-basierten Dienst mit Port-Nummer, RPC-Programmnummer, Version und dem Typ des Transport-Protokolls (TCP oder UDP) an. Die Ausgabe im folgenden Beispiel-Listing zeigt den Portmapper auf einer Maschine, die den kernelbasierten NFS-Dienst verwendet: s01:~ # rpcinfo -p program vers proto port tcp 111 portmapper udp 111 portmapper udp 2049 nfs udp 2049 nfs udp 2049 nfs_acl tcp 2049 nfs tcp 2049 nfs tcp 2049 nfs_acl udp status

170 160 KAPITEL 11. FILESERVER udp nlockmgr udp nlockmgr udp nlockmgr tcp status tcp nlockmgr tcp nlockmgr tcp nlockmgr udp 783 mountd tcp 786 mountd udp 783 mountd tcp 786 mountd udp 783 mountd tcp 786 mountd Die erste Spalte gibt die Dienstnummer an, wobei dem Portmapper mit die niedrigste zugeordnet ist. Der NFS-Dienst erhielt die Nummer und der Mount- Dienst die Diese Zahlen sind so festgelegt. Die zweite Spalte gibt Auskunft über die verwendete Protokollversion des Dienstes. Die gleiche Versionsnummer taucht zweimal auf, wenn der Dienst auf zwei verschiedenen Transportprotokollen, UDP und TCP, angeboten wird. Dabei hat die Protokollnummer des Portmappers nichts mit den Protokollnummern der anderen Dienste zu tun. Die Dienste selbst müssen jedoch in der Lage sein, mit dem jeweiligen Port-Mapper zusammenzuarbeiten. Der NFS-Server unterstützt die Versionen 2 und 3, der Mount-Server zusätzlich NFS- Version 1. Da Letzterer seine Dienste sowohl auf TCP als auch auf UDP anbietet, taucht er sechsmal in der Liste auf. Die Art des Transportprotokolls, auf dem ein Dienst arbeitet, kann der dritten Spalte entnommen werden. Die vierte Spalte liefert die Portnummer und die fünfte den Namen des gestarteten Dienstes, wie er auch in der Prozesstabelle (z.b. durch ps aux) angezeigt werden würde. Das nächste Beispiel zeigt eine Maschine, die NFS über den klassischen Userspace- Dienst ausschließlich in den NFS-Protokollversionen 1 und 2 anbietet. Solche Maschinen wird man jedoch zunehmend seltener finden, da die Implementierung von NFS im Linux- Userspace nicht mehr weiterentwickelt wird. Zusätzlich läuft ein weiterer RPC-Dienst zur NIS-Authentifizierung, der aber ebenfalls kaum noch irgendwo Verwendung findet. s05-alt:~ # rpcinfo -p Program Vers Proto Port tcp 111 portmapper udp 111 portmapper udp nlockmgr udp nlockmgr udp nlockmgr udp 803 ypbind udp 803 ypbind tcp 806 ypbind tcp 806 ypbind udp 829 mountd udp 829 mountd tcp 833 mountd tcp 833 mountd udp 2049 nfs tcp 2049 nfs udp 855 rquotad

171 11.1. UNIX-NETZWERKDATEISYSTEM - NFS udp 855 rquotad tcp 858 rquotad tcp 858 rquotad NFS-Clients Ein Client versucht, ein Verzeichnis von einem entfernten Host an sein lokales Verzeichnis zu mounten, genau wie er dies mit einem physikalischen Gerät machen würde. Allerdings ist die für ein entferntes Verzeichnis zu verwendende Syntax anders. Soll zum Beispiel das Verzeichnis /opt/applix vom Host server an /opt/office auf der Maschine gemountet werden, führt man folgenden Befehl aus: mount -t nfs -o ro,rsize=8192 server:/opt/openoffice /opt/office NFS-Server Die Freigaben, welche der NFS-Server zur Verfügung stellen soll, werden in der Datei /etc/exports definiert: /usr /opt/applix /tmp/users / (ro) / (ro) / (rw,no_root_squash) Der jeweilige NFS-Server muss je nach Einsatzgebiet und Anzahl der angeschlossenen Clients einges leisten. Von ihm hängt die Performance der Anwendungen auf den plattenlosen Geräten ab, da alle Zugriffe auf Dateien, Bibliotheken und Programme über ihn abgewickelt werden. Eine leistungsfähige CPU, viel Hauptspeicher, nicht zu langsame Festplatten und eine gute Netzwerkverbindung sind entscheidende Faktoren. Mit der heute üblichen Leistung auch der Einstiegsprozessoren, die man auf vielen Clients finden wird, kann eine 100 Mbit-Leitung durchaus bis an ihre theoretische Transfergrenze von über 10 Mbyte/s ausgelastet werden. Soll es nicht zu unnötigen Wartezeiten auf den Clients kommen, sollte der Server über ein oder mehrere Gigabit-Netzwerkinterfaces verfügen, die idealerweise an der Switch angeschlossen sind, welche die Verteilung an die Endgeräte übernimmt. Damit nicht alle Daten erneut von der Festplatte in den Hauptspeicher und dann über das Netzwerk geschaufelt werden müssen, macht ein großer Arbeitsspeicher Sinn. Durch diesen wird ein Cache häufig angeforderter Festplattenblöcke angelegt, welch dann direkt aus dem Hauptspeicher an den anfragenden Client ausgeliefert werden können NFS und (Un)Sicherheit Der Einsatz von NFS bis einschliesslich Version 3 ist unter Sicherheitsaspekten nicht problemfrei. Die Überprüfung ob ein bestimmtes Gerät auf den NFS-Server zugreifen darf oder nicht erfolgt lediglich anhand der IP-Nummer. Es werden keinerlei andere Credentials, wie Benutzerkennung oder Passwort abgefragt. Das vereinfacht den Einsatz von NFS im Umfeld von Diskless Clients oder zur Verteilung gemeinsamer Daten in nur lesbarem Zugriff. Sensible Daten sollten deshalb nicht mittels NFS-Freigaben bis zur Version 3 bereitgestellt werden. Hierfür sollten andere Netzwerkdateisysteme, wie Samba oder das Andrew File System (AFS) eingesetzt werden. Die Weiterentwicklung von NFS in der Version 4 bringt einige Fortschritte in Richtung Authentifizierung und Verschlüsselung der Daten.

172 162 KAPITEL 11. FILESERVER Auf jeden Fall sollten Administratoren nur NFS-Freigaben in das lokal zu bedienende Sub-Netz einrichten und einen NFS-Server nicht gleichzeitig als Gateway ins Internet oder ähnliches einsetzen. NFS-Zugriffe kann man nur teilweise per Firewall beschränken, da NFS und zusätzliche Dienste we gen der RPC-Architektur nicht mit bestimmten fest vorgegebenen Portnummern verknüpft sind Andrew Filesystem (AFS) Die Clientseite Das Kürzel AFS steht für Andrew File System oder A distributed File System. AFS wurde ursprünglich von der Carnegie-Mellon University entwickelt. Kommerzialisiert wurde AFS später von Transarc. Diese Firma wurde 1994 von IBM gekauft. IBM ihrerseits stellte im Jahre 2000 AFS als Open Source zur Verfügung. Seit dieser Zeit wird AFS von der OpenAFS Community gepflegt. AFS wird nicht mehr offiziell von IBM weiterentwickelt. Das Andrew File System (AFS) ist ein Netzwerk-Dateisystem, welches Dateien netzwerk- und weltweit zur Verfügung stellen kann. Dieses Dateisystem arbeitet nach dem Client-Server-Prinzip: Daten werden auf dem Fileserver gespeichert, der Zugriff erfolgt von Seiten der Clients. Die AFS-Unterstützung wird über ein Kernelmodul realisiert, welches alle benötigten Bibliotheksfunktionen zur Verfügung stellt. Zu diesem Modul werden Kernelprozesse gestartet, welche die Netzwerkinteraktion realisieren. Ausschnitt der Anzeige aller geladenen Module und AFS-Prozesse: linux:~/test # lsmod Module Size Used by Tainted: PF [...] nls_cp (autoclean) nls_iso (autoclean) smbfs (autoclean) snd-pcm-oss (autoclean) snd-mixer-oss (autoclean) [snd-pcm-oss] videodev (autoclean) libafs [...] linux:~/test # ps aux grep afs root ? SW Aug11 0:08 [afs_rxlistener] root ? SW Aug11 0:00 [afs_callback] root ? SW Aug11 0:00 [afs_rxevent] root ? SW Aug11 0:00 [afsd] root ? SW Aug11 0:00 [afs_checkserver] root ? SW Aug11 0:01 [afs_background] root ? SW Aug11 0:01 [afs_background] root ? SW Aug11 0:00 [afs_cachetrim] AFS besitzt gegenüber anderen verteilten Dateisystem wie z.b. Samba oder NFS einige Vorteile. Es arbeitet plattformunabhänig und verwendet zur Beschleunigung des Zugriffs auf jedem Client ein Cache von bis zu 2 GByte. Dieser dient zur Entlastung des Netzwerkes, zur Beschleunigung von Zugriffen und zur Überbrückung von Schwankungen, da AFS auf die Verwendung in Wide Area Networks angelegt ist. Für eine grössere Ausfallsicherheit können Volumes über mehrere Fileserver repliziert werden. Der Integrationsaufwand in das jeweilige Betriebssystem fällt jedoch höher aus, als für die meisten bereits genannten Filesysteme. Es existieren Implementationen für Win-

173 11.2. ANDREW FILESYSTEM (AFS) 163 dows 1, MacOS X und diverse UNIXe inklusive Linux. AFS kennt einen weltweit eindeutigen Namensraum. Egal wo und an welcher Maschine ein Benutzer arbeitet, der Pfad für einen Benutzer stellt sich immer identisch dar. Der Pfadname beginnt mit /afs (dem sogenannten Top Level). Auf der nächsten Hierarchieebene (Second Level) kommt der sogenannte Cell-Name. Die Zellennamen für bereits bestehende AFS-Zellen finden sich auf: Für die darin enthaltenen Unterverzeichnisse darunter existieren ebenfalls Konventionen, die eingehalten werden sollten. vgl. hierzu Tabelle auf S. 163 Name common public service sys type usr wsadmin Beschreibung Systemunabhängige Daten Öffentliche Daten Koordination und Konfiguration der Zelle Systemspezifische Daten z.b. i586 linux Home-Verzeichnisse für Benutzer Konfiguration von Clients Jedem Benutzer kann ein eigenes Volume zugeordnet werden. Sie bilden die Basis des ganzen Konzeptes, ihre Lage ist für den Client völlig transparent. Die Volumes können während des Betriebes von Fileserver zu Filserver verschoben werden. Auf diesem Volume wird ein Quota definiert. AFS implementiert eine ausgefeiltere Kontrolle über die Zugriffsberechtigungen mit Access Control Lists (ACLs), die anstelle der Unix-Rechte-Bits auf Verzeichnisebene zum Einsatz kommen. Jeder Benutzer kann eigene Gruppen erzeugen und verwalten. Wenn ein normaler Benutzer ohne Systemrechte eine Gruppe erzeugen will, muss er als Präfix seinen eigenen Namen verwenden. Dieses kann so aussehen: user:group Ausserdem sind die folgenden drei System- Gruppen schon definiert: system:anyuser, system:authuser und system:administrators, diese Gruppen sind in allen AFS Systemen vorhanden. system:anyuser sind alle Benutzer (mit oder ohne gültigem Token), system:authuser alle Benutzer mit gültigem Token und system:administrators Benutzer mit Administrator-Privilegien. Eine weitere Eigenschaft von AFS ist, dass es einen eigenen Login für die Freigabe seines Inhaltes benötigt. NFS in den Versionen 2 und 3 arbeitet mit einer IP-basierten Freigabe, die wenig Einschränkungen gegen geplanten Missbrauch bietet. Durch die Verwendung von Kerberos 4 bzw. 5 Authentifizierung kann es deshalb bedenkenloser als andere Netzwerkdateisysteme zur weltweiten Verteilung eingesetzt werden. Kommando Beschreibung kpasswd wird benutzt um das AFS-Passwort zu ändern klog Erwerben eines Tokens tokens Überblick der gültigen Tokens pts kann Benutzer und Gruppen anzeigen und verwalten fs kann ACLs und Quotas anzeigen/verwalten Tabelle 11.1: Einige wichtige AFS-Kommandos Mit der Authentifizierung gegenüber AFS, beim Login über PAM oder durch das Kommando klog <afs-username> erhält der angemeldete Benutzer ein Token. Dieses Token gestattet den Zugrif auf das AFS-Filesystem. Das Token hat aber nur eine begrenzte Gültigkeitsdauer. Nach Ablauf der Gültigkeit ist der Zugrif auf die AFS-Dateien wieder gesperrt. 1 für die Consumerwindows - Spielkonsolen Win95/98/ME - jedoch nur der Client

174 164 KAPITEL 11. FILESERVER Mit dem Befehl tokens kann man anschauen, welche Token gerade gehalten werden und wie lange die einzelnen Token noch gültig sind. Die Syntax der AFS-Kommandos ist etwas ungewohnt, da im Gegensatz zu den Standard- UNIX Kommandos die AFS-Kommandos nicht nur einem Zweck dienen, sondern mehrere Kommandos zu sogenannten Command Suites zusammenfassen. Die Syntax ist bei allen AFS Kommandos identisch: command suite operation code -switch <value> -flag Kommando fs help fs lq <dir> fs la <dir> fs sa <dir> <user> <rights> fs q Beschreibung erklärt alle zur Verfügung stehenden Optionen zeigt definiertes Quota für ein Verzeichnis an listet die gesetzten Rechte setzt Rechte für ein Verzeichnis Prozentangabe der Quotaauslastung Tabelle 11.2: Setzen und Ansehen der Zugriffsrechte Zur Anzeige der Rechte auf ein AFS-Verzeichnis (nur auf diese können AFS-Rechte gesetzt werden, auf einzelne Dateien nicht) verwendet man folgendes Kommando: dirk@lsfks02:/afs/.uni-freiburg.de/www/ks/htdocs/systeme> fs la Access list for. is Normal rights: webadmins rlidwka system:administrators rlidwka www rl rl dsuchod rlidwka Die Ausgabe zeigt, dass die Benutzer-IDs der eingeloggten Person an der Maschine nicht zwingend mit der AFS-Benutzer-ID übereinstimmen müssen. An der Linux-Maschine ist dirk eingeloggt, mit dem Kommando klog dsuchod und anschliessender Passwort-Eingabe hat sich der angemeldete Benutzer ein AFS-Token für den Zugriff auf die dsuchod freigeschalteten AFS-Bereiche geholt. Durch Eingabe des Kommandos fs quota oder kürzer fs q im AFS-Baum bekommt man die Meldung, wieviel Prozent des eigenen Quotas aufgebraucht sind: dirk@login02:/afs/.uni-freiburg.de/www/ks/htdocs/> fs q 74% of quota used. Eine ausführlichere Information mit Angabe des zur Verfügung stehenden und verbrauchten Speicherplatzes bekommt man mit: dirk@login02:/afs/.uni-freiburg.de/www/ks/htdocs/> fs lq Volume Name Quota Used %Used Partition % 73% Die Zugriffsberechtigungen von AFS beziehen sich immer auf ein ganzes Verzeichnis und alle darin enthaltenen Dateien. Sie beziehen sich nicht automatisch auf enthaltene Unterverzeichnisse. Wenn die Zugriffsberechtigung für eine einzelne Datei geändert werden soll, muss diese ein anderes Verzeichnis mit den gewünschten Zugriffsrechten verschoben werden. Die Zugriffsberechtigung wird dabei vom übergordneten Verzeichnis geerbt. AFS definiert insgesammt sieben Rechtearten, dabei beziehen sich vier Zugriffsrechte auf das Verzeichnis. Drei weitere Berechtigungen beziehen sich auf die Dateien innerhalb des Verzeichnisses

175 11.2. ANDREW FILESYSTEM (AFS) 165 Kürzel AFS-Recht Beschreibung a administer die ACLs ändern d delete Dateien und Verzeichnisse löschen oder verschieben i insert Neue Dateien und Verzeichnisse anlegen l lookup Inhalt des Verzeichnis kann aufgelistet werden und ein Wechsel in dieses Verzeichnis ist erlaubt r read Inhalt der Dateien lesen. Dazu gehört z.b. auch ls -l w write Ändern von Dateien k lock Ermöglicht das Ausführen von Programmen die über Systemcalls Dateien sperren (locks) Tabelle 11.3: AFS Rechteschema Beim Setzen des Rechtelevels lookup kann in das Verzeichnis gewechselt werden. Der Inhalt der Dateien kann nur dann auch gelesen werden, wenn ebenfalls die Berechtigung read zur Verfügung steht. Die wichtigsten Berechtigungen lassen sich zusammenfassen, wie in der Tabelle zur AFS Rechtegruppierung gezeigt. Zusammenfassung Beschreibung all alle Berechtigungen (rlidwka) none keine Berechtigung read nur lesen (rl) write lesen und schreiben (rlidwk), d.h. alle ausser a Tabelle 11.4: AFS Rechtegruppierung Ein nettes Feature ist, dass Rechteinhaber im AFS selbst Verzeichnisse für andere Benutzer bzw. Gruppen freigeben können. Hierzu dient zuerst einmal das Kommando pts. pts creategroup dsuchod:systeme group dsuchod:systeme2 has id -754 pts adduser user01 dsuchod:systeme fs sa testdir dsuchod:systeme rliwka Das Ergebnis des Gruppenanlegens ist eingerückt dargestellt. Anschliessend kann ein User (hier: user01) oder mehrere dieser Gruppe hinzugefügt werden. Mit dem AFS-Kommando fs sa testdir dsuchod:systeme rliwka wird dann ein Rechtemuster auf das Verzeichnis testdir für die Gruppe dsuchod:systeme eingetragen. Dieses Kommando muss entsprechend für alle gewünschten Verzeichnisse wiederholt werden. Dabei sollte man bedenken, dass auch übergeordnete Verzeichnisse zumindest ein Lookup-Recht für die Gruppe bekommen sollten. Das Anzeigen der Rechte im Verzeichnis testdir liefert dann folgendes: dirk@linux02:/afs/.uni-freiburg.de/www/ks/htdocs/systeme> fs la Access list for. is Normal rights: dsuchod:systeme rliwka

176 166 KAPITEL 11. FILESERVER webadmins rlidwka system:administrators rlidwka www rl rl dsuchod rlidwka 11.3 File Transfer Protocol Dateiarchiv - FTP-Server Eine der ältesten Internet-Anwendungen ist der Transport von Dateien. Hierfür wurde ein eigenes Protokoll geschaffen. FTP-Server haben heutzutage die Aufgabe große Datenmengen, meistens Softwarebestände einfach zugänglich zu machen. Meistens wird unter Linux der proftpd eingesetzt. Dieser wird über die Datei /etc/proftpd.conf eingerichtet. Der FTP-Server kann als standalone Prozess immer im Hintergrund laufen oder über den Internet-Superdämon inetd oder xinetd bei Bedarf gestartet werden. Ersteres bedeutet höheren Speicherverbrauch, die zweite Lösung benötigt durch den Start mehr Resourcen und braucht etwas längere Antwortzeiten FTP-Clients Nach dem Einloggen befindet man sich auf der Kommandoebene von FTP. Hier steht nicht der gesamte UNIX-Befehlswortschatz, sondern nur einige Befehle zur Dateiverwaltung und zum Datentransport zur Verfügung. Im folgenden sei mit Arbeitsrechner der Rechner gemeint, auf dem FTP gestartet wurde, und Zielrechner sei der Rechner, mit dem man per FTP die Verbindung hergestellt hat Das Minimal-FTP (TFTP) Das Trivial File Transfer Protocol (TFTP) 2 dient in erster Linie zur Übertragung von zu bootenden Netzkernels 3 oder eines PXE-Bootimages 4 für spezielle Programme zu einem sehr frühen Zeitpunkt des Rechnerstarts. Das Protokoll wird zu Beginn des Bootvorganges ausgeführt und muss meistens neben der BOOTP-Implentation auf einem 16 kbyte bzw. 32 kbyte EPROM Platz finden. Deshalb ist es auf geringen Codeumfang optimiert. tftp, die Client-Applikation, braucht man inzwischen häufiger mal wieder auf seiner Maschine, da viele Embedded Devices einen eingebauten TFTP-Server zum Update ihres Flash-ROMs haben. Es lässt sich ählich wie ftp interaktiv bedienen, wenn auch der Funktionsumfang vorgebenermassen ziemlich eingeschränkt ist. 2 TFTP wird in den folgenden RFCs beschrieben: RFC1350 : The TFTP Protocol (REVISION 2), Juli 1992 RFC2090 : TFTP Multicast Option, Februar 1997 RFC2347 : TFTP Option Extension, Mai 1998 RFC2348 : TFTP Blocksize Option, Mai 1998 RFC2349 : TFTP Timeout Interval and Transfer Size Options, Mai Welche Optionen dieser enthalten muss, welche Anpassungen notwendig sind und wie man ihn mit einer entsprechenden Bootsignatur versieht, wird in den folgenden Abschnitten erklärt 4 Die notwendigen Erweiterungen von TFTP im Zusammenhang mit PXE finden sich im RFC2349

177 11.4. DAS MINIMAL-FTP (TFTP) 167 Kommando Funktion cd Verzeichnis Verzeichnisse wechseln mkdir Verzeichnis Verzeichnisse anlegen rmdir Verzeichnis Verzeichnisse löschen auf dem Zielrechner lcd Verzeichnis Verzeichnis auf Arbeitsrechner wechseln dir zeigt das Directory des Zielrechners an ldir zeigt das Directory des Arbeitsrechners an!kommando aktiviert eine Shell auf dem Arbeitsrechner und führt Kommando aus put Dateiname kopiert Dateiname auf den Zielrechner mput Dateiname(n) wie put, nur sind hier die Wildcards ** und? erlaubt get Dateiname kopiert Dateiname vom Zielrechner auf den Arbeitsrechner mget Dateiname(n) entspricht get mit Platzhaltern ascii schaltet auf den für den Transport von ASCII-Dateien notwendigen ASCII-Modus um, Voreinstellung von Mickey- FTP bin schaltet auf den für den Transport von binären Daten notwendigen Binärmodus um? oder help zeigt eine Liste der zur Verfügung stehenden Befehle an quit beendet FTP Tabelle 11.5: Einige wichtige FTP-Kommandos

178 168 KAPITEL 11. FILESERVER In aktuellen Linux-Distributionen stehen oft mehrere Implementierungen zur Auswahl. Der in.tftpd ist die klassische Version, der atftpd kann mehr und kommt besser mit PXE klar. Die optimale Konfiguration in der jeweiligen Umgebung bekommt man wohl am besten durch Tests heraus. Es kann jedoch immer nur ein Dienst gleichzeitig auf einem Port betrieben werden. Der TFTP-Standard-Port ist UDP 69. TFTP bietet keinen Schutz durch Passwortauthentifizierung und sollte deshalb mit Vorsicht, d.h. mindestens durch Beschränkung des Hauptverzeichnisses auf den benötigten Bereich, aufgesetzt werden. Dazu kann durch den (x)inetd ein TFTP-Root angegeben werden, was einen Zugriff auf höhere Verzeichnis-Ebenen des Servers verhindert. Zur Illustration dienen die nachfolgenden Ausschnitte aus den jeweiligen Konfigurationsdateien. Der folgende Ausschnitt zeigt ein Teil der /etc/inetd.conf. [...] # # Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers". # tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd /boot bootps dgram udp wait root /usr/sbin/bootpd bootpd -c /nfsroot # [...] Oder: (Ausschnitt der /etc/xinetd.conf) [...] # disabled = bootps # disabled = tftp [...] service tftp { socket_type = dgram protocol = udp wait = yes user = nobody only_from = / /8 server = /usr/sbin/in.tftpd server_args = /nfsroot } Eine moderne Implementation von TFTP ist der atftpd, welcher auch im Standalone- Betrieb eingesetzt werden kann. Die Einstellungen erfolgen in den neueren Linux-Distributionen mittels Sysconfig-Datei: /etc/sysconfig/atftpd. Hier entnimmt das Runlevel-Skript üblicherweise die Startoptionen. Der erfolgreiche Start des TFTP-Servers (/etc/init.d/atftpd start) zeigt sich im System-Logfile auf diese Weise: Oct 6 21:50:39 hermes atftpd[25183]: Advanced Trivial FTP server started (0.7)... Oct 6 21:55:12 hermes atftpd[25184]: Serving /nfsroot/10.0/boot/vmlinuz to \ :41470 Angenommen, das Kernel-Image liegt im Verzeichnis /nfsroot/10.0/boot und trägt den Namen vmlinuz. Dann könnte der Test auf ein funktionierendes TFTP so aussehen:

179 11.5. WEITERE FILESERVER-KONZEPTE 169 rechner02:~ # atftp bootserver.mydomain.site tftp> get /nfsroot/10.0/boot/vmlinuz tftp> quit rechner02:~ # ls -lha vmlinuz -rw-r--r-- 1 root root 1.5M Oct 6 17:38 vmlinuz Liegt dann der Kernel in der richtigen Größe in dem Verzeichnis, aus dem man den TFTP- Client heraus gestartet hat, ging alles glatt. Der Eintrag im Logfile sieht dann wie oben gezeigt aus Weitere Fileserver-Konzepte Die Idee, Festplattenkapazitäten zu zentralisieren und einer ganzen Reihe verschiedener Maschinen übers ein Netzwerk zu Verfügung zu stellen, existiert schon lange. Im kommerziellen Umfeld haben sich neben den Lösungen mit sogenannten Network Attached Storage (NAS), die dateibasierte Dienste wie NFS oder SMB bereistellen, Storage Area Networks (SAN) etabliert, die meistens auf einer eigenen vom klassischen LAN unabhängigen Fibre-Channel Fabric basieren. Die Preise der einzelnen Komponenten liegen dabei weit über dem Gewohnten im privaten Bereich. Für den Anschluss von preiswerteren und leistungsärmeren Endgeräten versucht die Industrie den iscsi-standard zu verbreiten. Linux-Maschinen können iscsi benutzen, da der Kernel die notwendige Treiberunterstützung mitbringt. Der Overhead ist für den einfachen Standardarbeitsplatz jedoch immer noch sehr hoch, weshalb sich die Verbreitung noch sehr in Grenzen hält. Die Abbildung zeigt, dass Dateien oder Blöcke auf Server Netzwerk Client Anwendung ftp, scp, http Anwendung VFS LUFS VFS Dateisystem NFS, SMB Dateisystem Blockgerà t iscsi, AoE, NBD Blockgerà t Abbildung 11.1: Arbeitsweise von Blockgeräten und Dateisystemen verschiedenen Ebenen ausgetauscht werden können. Es wird hier nicht berücksichtigt wo Server und Client letztendlich implementiert sind, sondern auf welcher Ebene sie die Daten interpretieren. Das Linux Userland Filesystem (LUFS) spielt eine Sonderrolle - es kann beispielsweise die Dateien eines FTP-Servers als Dateisystem einhängen. Dieser durchaus sinnvolle Ansatz lässt sich mit einigen Einschränkungen auch weitaus günstiger realisieren. Parallel zu den kommerziellen Implementierungen von SANs haben sich Kernel-Entwickler darangemacht, Ähnliches auch für Linux zu implementieren. Seit vier Jahren liegt der Code für das Network Block Device dem Mainstream-Kernel bei. Ausgehend von diesem hat es weitere Entwicklungen auch für durchaus besondere Anforderungen gegeben.

180 170 KAPITEL 11. FILESERVER 11.6 Network Block Devices Netzwerkblockgeräte und Netzwerkdateisysteme unterscheiden sich deutlich voneinander, selbst wenn der Einsatzzweck am Ende recht ähnlich sein kann. Dateisysteme kümmern sich um den Zugriff auf Dateien - Blockgeräte abstrahieren in der Regel Hardware (z.b. Festplatten) und erlauben den Datenaustausch in Blöcken. Eine Verbindung zwischen beiden ergibt sich, wenn gewöhnliche Dateisysteme auf blockbasierte Geräte aufgebracht 5 werden, um die Dateien in Form von Blöcken festzuhalten. Ein modernes Betriebssystem steigert die Performance, indem es Blocktransfers zwischenspeichert, d.h. Blöcke werden nicht sofort auf Platte geschrieben, sondern zuerst noch im Speicher festgehalten. In dem sich ein Administrator auf ein Netzwerkdateisystem festlegt, bestimmt er die erlaubten Dateienarten, -größen und Zugriffssteuerungen. So kennt beispielsweise Samba in der Default-Konfiguration keine speziellen Unix-Dateien wie Sockets und Named Pipes, welches einige Applikationen und grafische Linux-Desktops stolpern lässt. Blockdevices erlauben prinzipiell den Einsatz beliebiger blockbasierter Dateisysteme, völlig unabhängig davon, ob sie lokal eingebunden werden oder per Netzwerk zur Verfügung stehen. Das erweitert die Auswahl ganz erheblich und erlaubt es speziellen Anforderungen, wie Kompression der Daten, zu berücksichtigen. Netzwerkblockgeräte lassen sich wie Netzwerkdateisysteme sowohl nur lesbar als auch schreibbar exportieren. Der wesentliche Unterschied ergibt beim gemeinsamen Schreiben auf eine Ressource. Netzwerkdateisysteme stellen hier beispielsweise Locking-Mechanismen bereit oder koordinieren Dateizugriffe so, dass keine Daten beschädigt werden. Netzwerkblockgeräte betreiben deutlich weniger Aufwand, d.h. ein Block wird gelesen oder geschrieben. Sicherheitsmechanismen beschränken sich darauf, dass Blocktransfers atomar durchgeführt werden. Blockgeräte interessieren sich insbesondere nicht dafür, ob die Blöcke mit einem Dateisystem in Verbindung stehen, d.h. sie haben keine Ahnung von der darüberliegenden Datenschicht und ihrer Organisation, was der verteilten Nutzung eines Netzwerkblockgeräts zusammen mit einem gewöhnlichen blockbasierten Dateisystem einige Schwierigkeiten bereit. Würden mehrere Clients gemeinsam ein Netzwerkblockgerät ausgestattet mit einem Dateisystem beschreiben, so gäbe es keine Instanz, die den verteilten Zugriff regelt. Die Dateisysteme, die letztendlich ein gemeinsames Blockgerät benutzten, wüssten nichts von ihrer gegenseitigen Existenz und keines davon würde es begreifen bzw. berücksichtigen, dass sich Blöcke plötzlich wie von Zauberhand verändern. Durch lokales Caching (und damit noch weniger Synchronisation) ist dann das Wirr-Warr perfekt und die Dateisysteme auf den unterschiedlichen Clients sehen bald nur noch uninterpretierbaren Müll, welches in den meisten Fällen fatale Auswirkungen haben dürfte. Dieses Problem spielt jedoch für spezielle Szenarien, wie beispielsweise den Betrieb von Linux Diskless Clients nur eine untergeordnete Rolle. Bei Netzwerkdateisystemen werden viele dieser Probleme vom Kernel abgenommen. Die Server für die einfachen Netzwerkdateisysteme, wie NFS oder Samba operieren direkt auf den normalen Verzeichnissen, wie sie an irgendeiner Stelle im Serverdateisystem eingehängt wurden. Damit kann ein und dasselbe Unterverzeichnis in verschiedenen Arten über das Netzwerk exportiert werden. Oft findet man diese Anwendung bei der Bereitstellung von Home-Verzeichnissen für Windows- und Unix-Clients. Das hat den wesentlichen Vorteil, dass Schreibvorgänge sowohl auf dem Server als auch unterschiedlichen Clients transparent sichtbar werden. So kann der Admin auf dem Server beispielsweise ein Software-Update 5 Dieser Vorgang wird gemeinhin als formatieren (einer Festplatte oder Partition,...) bezeichnet

181 11.7. NBDS IM EINSATZ 171 einspielen, welches sich recht schnell auf alle angeschlossenen Clients auswirkt NBDs im Einsatz Zu den ältesten netzwerktransparenten Blockgeräten zählt das Network Block Device NBD, welches seit dem späten 2.1er Kernel in den Code-Baum aufgenommen wurde. In den modularen Kernels der meisten Mainstream-Distributionen ist NBD deshalb üblicherweise als Modul enthalten. Es lässt sich einfach mit modprobe nbd laden. Es sollte keine Fehlermeldung erscheinen, andernfalls ist es nicht korrekt installiert. Die notwendigen Userspace-Tools liefern die meisten Distributionen als eigenes Paket mit. hermes:~ # modprobe nbd hermes:~ # which nbd-server /usr/bin/nbd-server hermes:~ # rpm -q nbd nbd Erste Versuche mit NBD Um Netzwerkprobleme auszuschliessen, führt man Tests zuerst am besten auf derselben Maschine durch. Am einfachsten operiert man mit einer weiteren Partition auf der nicht das Root-Filesystem des Servers liegt. Hat man diese nicht zur Verfügung kann man alternativ eine Container-Datei anlegen und diese mit einem Dateisystem der Wahl, welches vom Serverkernel unterstützt wird, formatieren. Erfolgreich getestet wurden an dieser Stelle die Dateisysteme ReiserFS, ext2 und XFS. Jedes Formatwerkzeug weist darauf hin, dass es sich bei der Datei nicht um ein Blockgerät handelt, was aber ohne Folgen ignoriert werden kann. hermes:~ # mkdir /exports hermes:~ # dd if=/dev/zero of=/exports/nbd-export bs=1024 count= Datensätze ein Datensätze aus bytes (102 MB) copied, 0, seconds, 84 MB/s hermes:~ # mke2fs nbd-export mke2fs 1.38 (30-Jun-2005) /exports/nbd-export ist kein spezielles Block-Gerät. Trotzdem fortsetzen? (y,n) y Dateisystem-Label= OS-Typ: Linux Blockgröße=1024 (log=0) [... ] hermes:~ # nbd-server 5000 /exports/nbd-export hermes:~ # nbd-client /dev/nbd0 Negotiation:..size = KB bs=1024, sz= hermes:~ # mount /dev/nbd0 /mnt hermes:~ # ls /mnt... lost+found hermes:~ # df Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf [... ] /dev/nbd % /mnt hermes:/ # time dd if=/dev/zero of=/mnt/text count=8192 bs= Datensätze ein Datensätze aus

182 172 KAPITEL 11. FILESERVER bytes (8,4 MB) copied, 0, seconds, 220 MB/s real user sys 0m0.046s 0m0.008s 0m0.036s Im Beispiel agiert der NBD-Server auf einer 100 MByte grossen Datei. Er bietet seine Dienste auf Port 5000 an. Die Portnummer kann frei gewählt werden. So lassen sich auch mehrere Server für verschiedenen Container starten. Der NBD-Client setzt das geladene Kernelmodul voraus und benötigt als Parameter beim Aufruf die IP-Adresse und Portnummer des Servers gefolgt vom Namen des lokal anzusprechenden Blockdevices. Zum (Performance-)Vergleich kann man die Datei einfach loopback mounten: hermes:/ # mount -o loop /exports/nbd-export /mnt hermes:/ # time dd if=/dev/zero of=/mnt/text count=8192 bs= Datensätze ein Datensätze aus bytes (8,4 MB) copied, 0, seconds, 243 MB/s real user sys 0m0.040s 0m0.008s 0m0.024s Der Performance-Verlust, zugegebenermaßen ist die Messmethode eher grob, hält sich bei der Verwendung des Netzwerkblockgerätes in Grenzen. Wenn alles auf einer Maschine geklappt hat, kann man darangehen und auf einer entfernten Maschine das Blockdevice einbinden. Dazu muss im Aufruf lediglich die Localhost-Adresse gegen die IP-Adresse des Servers getauscht werden. Möchte man eine Partition oder ein LVM-Volume an Stelle einer Datei exportieren, tauscht man den Dateinamen gegen den Namen des speziellen Devices aus: linux01:/ # nbd-server 5001 /dev/sda4 Nachdem der Server läuft, kann sich der Client auf diesen mit IP-Adresse und Portnummer verbinden. Die Verbindung wurde erfolgreich initialisiert, wenn nbd-client keine Fehlermeldung ausgibt. Die Verbindung zum Server kann vom Client durch den Aufruf von nbd-client -d /dev/nbd0 gelöst werden. Vorher sollte jedoch das eingehängte Blockdevice ausgemountet werden: linux01:/ # umount /mnt linux01:/ # nbd-client -d /dev/nbd0 NBD ist recht einfach gestrickt: Es überlässt die Integritätsprüfung der übertragenen Daten dem darunterliegenden TCP NBD und Filesysteme In der bisher geschilderten Anwendung des Blockdevices gelten die identischen Einschränkungen für eine Festplatte bzw. eine Partition auf dieser: Nur eine Maschine kann gleichzeitig lesend und schreibend darauf zugreifen. Es gibt anders als bei Netzwerkdateisystemen keinen eingebauten Mechanismus der sich um Locking oder den Abgleich der Buffer der verschiedenen Maschinen kümmert. Nun spielt dieses Szenario des gemeinsamen schreibenden Zugriffs in vielen Fällen, wie beispielsweise für das Root-Filesystem von Diskless Clients oder das Bereitstellen eines gemeinsamen Applikationsverzeichnisses keine Rolle. Dann kann man den Blockdevice-Server

183 11.7. NBDS IM EINSATZ 173 mit der Option -r im nur lesbaren Modus starten: Nun kann kein Client Änderungen am Blockdevice vornehmen. Bei Verwendung dieser Option sind Journaling-Filesysteme ausgeschlossen. Weder ext3, noch ReiserFS oder XFS liessen sich per nur lesbarem Blockdevice erfolgreich mounten. Die Fehlermeldungen fielen dabei je nach Dateisystem unterschiedlich harsch aus: hermes:~ # mount -t reiserfs /dev/nbd0 /mnt Kernel call returned: Connection reset by peerclosing: que, sock, done mount: wrong fs type, bad option, bad superblock on /dev/nbd0, missing codepage or other error In some cases useful info is found in syslog - try dmesg tail or so hermes:~ # mount -t xfs /dev/nbd0 /mnt/ Kernel call returned: Connection reset by peerclosing: que, sock, done mount: /dev/nbd0: Konnte den Superblock nicht lesen Auch der Einsatz der Mount-Option -o ro brachte keine Entspannung. Die Dateisysteme SquashFS und ext2 hatten jedoch keine Schwierigkeiten. Eine Alternative beschreiben die Autoren mit der Option -c. Dann kann der NBD- Server ein Copy-on-Write ausführen. Dazu legt er für jeden Client eine Datei an, in die alle Änderungen geschrieben werden. hermes:~ # nbd-server 5000 /exports/nbd-export -c hermes:~ # nbd-client /dev/nbd0 hermes:~ # mount -t xfs /dev/nbd0 /mnt hermes:~ # ls -al /exports insgesamt drwxr-xr-x 2 root root :39. drwxr-xr-x 23 root root :16.. -rw-r--r-- 1 root root :33 nbd-export -rw root root :39 nbd-export diff Hier sieht man nun, dass eine separate Datei für die Änderungen angelegt wird. Nach einem Disconnect des Clients gehen diese Änderungen verloren, obwohl die Datei selbst erhalten bleibt. Macht man nun das Experiment das Blockdevice unter einem der Journaling- Dateisysteme Readonly einzubinden, sieht man, dass trotzdem etwas auf das Device geschrieben wird. Das erklärt die vorher beschriebenen Probleme. Die -c Option wird von den Entwicklern des Network Block Device als nicht besonders performant beschrieben, weshalb sich hier besser clientseite Lösungen, wie UnionFS oder das COW-Modul anbieten. Generell muss auch beim NBD gesagt werden, dass das Sicherheitskonzept alles andere als ausgefeilt ist. Ähnlich zu NFS, jedoch deutlich unflexibler, kann man eine Liste von Rechnern angeben, denen der Zugriff auf das Device gestattet wird. Abhilfe könnten hier verschlüsselte Dateisysteme schaffen. Andernfalls hat man zumindest auf der Ebene der Sicherheit gegenüber einem NFS der Version 2 oder 3 nichts gewonnen DNBD - eine spezialisierte Alternative Neben NBD gibt es weitere freie Implementierung eines Netzwerkblockgeräts, wie beispielsweise ENBD, GNBD oder ANBD. Da die jeweiligen Blockgerätetreiber aber (noch) nicht Bestandteil des Kernels sind, sucht man ein installierbares Paket bei vielen Distributionen oft vergeblich. In diesem Fall müssen die Quellen von den unten angegeben Adressen selbst bezogen werden. Für den Mehraufwand bekommt man beispielsweise bei ENBD eine Fehlerbehandlung mit dem automatischen Wiederaufbau einer abgebrochenen Verbindung, der gleichzeitigen Benutzung mehrerer Kanäle und vieles mehr.

184 174 KAPITEL 11. FILESERVER Für ein recht spezifisches Umfeld, nämlich für den Diskless-Betrieb in Funknetzen, gibt es DNBD, welches hier auftretende Probleme auf besondere Art und Weise handhabt. In einem typischen Funknetz-Szenario assozieren sich Clients mit einem Access Point und benutzen dabei dieselbe Frequenz, was natürlich bedeutet, dass für eine funktionierende Kommunikation nur ein Client zu einem bestimmten Zeitpunkt senden darf. Hinzu kommt die niedrige Bandbreite, die bei den heute verwendeten Technologien, wie dem IE- EE b/a/g Standard, auf 54 Mbit/s begrenzt ist. Manche Hersteller versprechen zwar Datenraten von 108 Mbit/s - bei allen ist der effektive Durchsatz aber meist viel niedriger. Unabhängig von der Datenrate sind aber die Kosten für neue Clients, was die Größe der transferierten Datenmengen betrifft. Verdoppelt man die Anzahl der Clients, so lässt im Durchschnitt in einem bestimmten Zeitintervall nur noch die halbe Datenmenge je Client übertragen. Die Frage ist nun, ob es denn überhaupt möglich und sinnvoll ist, das Konzept festplattenloser Rechner zum Beispiel auf mobile Pools in Funknetzen auszuweiten. Das Problem der begrenzten Bandbreite und schlechten Skalierbarkeit zusammen mit dem Wunsch einer Fehlerbehandlung (z.b. mit Failover auf replizierte Server) und das in unzuverlässigen Netzen mit Paketverlusten, sprechen nicht gerade für einen solchen Einsatz. DNBD versucht deshalb, im Unterschied zu den bisher vorgestellten Netzwerkblockgeräten anfallende Datenmengen so weit wie möglich zu minimieren und dabei die Besonderheiten eines Funknetzes auszunutzen. Zuerst wird für ein vereinfachtes Protokoll auf Locking-Mechanismen verzichtet und nur lesbarer Zugriff erlaubt, was clientseitig beispielweise mit cowloop wieder aufgehoben werden kann. Zweitens werden Blöcke, die von einem Client angefordert werden und schließlich vom Server geliefert werden, von anderen Clients gecachet, falls diese später selbst Bedarf dafür haben sollten. Drittens wird UDP als verbindungsloses Protokoll verwendet und Paketverluste und andere Kommunikationsprobleme werden von DNBD selbst bearbeitet. Jetzt stellt sich nur noch die Frage, wie Blöcke abgefangen und gecachet werden können. Das gemeinsam benutzte Medium bei Funknetzen erlaubt zwar prinzipiell das Mithören der Kommunikation anderer Clients - leider unterstützen aber nicht alle Karten einen so genannten Promiscuous- bzw. Monitor-Modus. Und falls doch, so muss dieser für die jeweiligen Chipsätze meist auf unterschiedliche Art und Weise aktiviert werden. DNBD benutzt deshalb IP-Multicast, um eine Gruppe von Clients gleichzeitig zu adressieren. Eine IP-Multicast-Adresse liegt hier im Netz /4 - für Experimente sollte das Netz /8 benutzt werden. Bevor bei DNBD ein Client auf ein Netzwerkblockgerät zugreifen kann, versucht er vorhandene Server zu finden, indem er bestimmte Pakete an die gegebene Multicast-Adresse schickt. Die Server beantworten die Anfrage und liefern gleichzeitig Informationen über das vorhandene Blockgerät. Die Clients benutzen diese Daten zu Konfiguration und können fortan Blöcke anfragen. Die komplette Kommunikation funktioniert mit UDP aus mehreren Gründen: Das einfach gestrickte UDP (im Vergleich zu TCP) ist völlig ausreichend um Blöcke anzufordern und bietet die Möglichkeit eigene (meist zeitgesteuerte) Methoden für den Datenfluss etc. zu realisieren; außerdem ist Multicast mit TCP beim Linux-Netzwerkstack nicht implementiert und seine Verwendung wäre überhaupt nicht möglich gewesen. Für eine hohe Verfügbarkeit lassen sich Server zusätzlich replizieren. Neue Server werden von den Clients dabei automatisch gefunden, indem dauernd statistische Daten gesammelt werden, und Server mit niedrigen Antwortzeiten ausgesucht werden. Für den Einsatz von DNBD in kabelgebundenen Netzen wird wegen des Overheads der Multicast- Kommunikation allerdings noch abgeraten bis DNBD auch Unicast-Kommunikation unterstützt.

185 11.8. SPEZIELLE BLOCKDEVICE-ERWEITERUNGEN 175 Natürlich werden immer für sinnvolles Caching Lokalitätseigenschaften vorausgesetzt, d.h. in unserem Fall sollten unterschiedliche Clients in einem gewissen Zeitraum auf dieselben Blöcke zugreifen. Dies ist zum Beispiel beim simultanen Start von verschiedenen Diskless Clients in Funknetzen gegeben. Eine weitere Anwendung ist die Bereitstellung von Multimedia-Inhalten in Funknetzen: Mehrere Clients können eine DVD über ein WLAN abspielen, wobei dank des Caches auch Zeitdifferenzen erlaubt sind, ohne dass ein neuer Stream gestartet werden muss Spezielle Blockdevice-Erweiterungen In Umgebungen von Diskless Clients spielt die Beschreibbarkeit des Dateisystems eine besondere Rolle. Einerseits soll das Dateisystem auf dem Server sauber bleiben, d.h. Clients bekommen keinen Zugriff, Systemdateien zu verändern. Andererseits setzen Clients voraus, dass Dateien, die für den Betrieb notwendig sind, angelegt oder verändert werden können, z.b. /etc/resolv.conf. Bei einem nur lesbaren Blockgerät ergibt sich hier eine Möglichkeit, indem es mit cowloop (Copy-on-Write-Loopback Device) schreibbar gemacht wird. Geänderte Blöcke werden getrennt in einem so genannten sparse file aufbewahrt, welches sich wiederum in einer Ramdisk befinden kann. Anders als bei UnionFS, wo selbst bei kleinsten Änderungen an einer Datei diese schon komplett in die beschreibbare Schicht kopiert werden muss, geht cowloop sparsamer mit dem Platz um und vermerkt nur wirklich geänderte Blöcke. Es setzt dafür jedoch ein schreibbares Dateisystem voraus: Ein mit dem RO-Filesystem SquashFS formatiertes Netzwerkblockgerät wird auch durch spezielle Write-Loopback-Devices nicht veränderbar. Ein Nachteil bei dieser Benutzung von Netzwerkblockgeräten ist, dass sich die Clients nicht transparent updaten lassen. Änderungen am Blockdevice auf dem Server erfordern einen Neustart der Clients oder zumindest einen komplizierten Remount Mechanismus. Da Änderungen am System in der Praxis meist nur bei Sicherheitsupdates oder einem Umstieg auf eine neuen Ausgabe der Distribution wirklich notwendig sind, hält sich der Aufwand in Grenzen. Wurde ein Network Block Device wie im letzten Abschnitt beschrieben aufgesetzt, so lässt sich cowloop wie folgt einsetzen: linux01:~ # modprobe cowloop linux01:~ # cowdev -a /dev/nbd0 /tmp/nbd.cow /dev/cow/0 linux01:~ # mkdir /mnt/nbd-rw && mount /dev/cow/0 /mnt/nbd-rw linux01:~ # umount /mnt/nbd-rw && cowdev -d /dev/cow/0 In diesem Beispiel wird ein Netzwerkblockgerät mit der schreibbaren Datei /tmp/nbd.cow verknüpft und das neue Blockgerät dann gemountet. Schreibvorgänge in nbd-rw wirken sich deshalb nicht auf das zu Grunde liegende Netzwerkblockgerät aus. Falls sich cowloop über ein fehlendes /dev/cow/ctl oder /dev/cow/0 beschwert, so hilft linux01:~ # mkdir /dev/cow && mknod /dev/cow/ctl b linux01:~ # ln -s /dev/cowloop0 /dev/cow/0

186 176 KAPITEL 11. FILESERVER Dateisystem copy-on-write Blockgerà t Lesen Lesen und Schreiben nur lesbares Blockgerà t schreibbare Datei Abbildung 11.2: Das Cowloop-Blockgerät basiert auf einem weiteren Blockgerät und hält geänderte Blöcke in einer Datei fest

187 Kapitel 12 Samba 12.1 Samba - Brücke zwischen Microsoft- und Unix-Welt Für viele gehören Samba und Linux einfach zusammen - der Anteil von Samba an der Popularisierung von Linux ist nicht zu unterschätzen. Samba bildet eine der wichtigsten Brücken zwischen der Linux/Unix und Windowswelt. Dieses beginnt bei einfachen Verzeichnis- und Druckerfreigaben und läßt sich fortsetzen bis zu Single-Password- oder Single-Sign-On- Lösungen und komplexen Domaincontroller-Aufgaben, die ein Linux-Rechner übernehmen kann. Samba steht für die freie Implementierung eines Server Message Block Protokollservers. Samba spricht sich einfach besser aus und klingt netter als die Abkürzung des Protokollnamens SMB. Microsoft-Rechner benutzen dieses Protokoll untereinander, um auf Dateien und Drucker über ein Netzwerk zuzugreifen. In dieses Netzwerk können sich auch Linux oder Unixrechner dank Samba einklinken. Sie können dabei dank Samba als Client agieren oder auch tragendere Rollen übernehmen. Samba ist ein Open-Source-Projekt welches im Jahre 1991 von Andrew Tridgell an der Canberra University in Australien gestartet wurde. Entsprechend steht der in C geschriebene Source-Code jedem zur Verfügung. Jeder kann ihn anpassen, untersuchen und testen. Für Administratoren in Firmen und Organisationen das Wichtigste: Samba ist frei. Anders als für jede Microsoft Installation fallen für das Aufsetzen eines Samba-Servers oder die Benutzung der Samba-Dienste unter Linux keinerlei Lizenzgebühren an Einsatzgebiete von Samba SMB beschränkt sich nicht auf die Funktion als Netzwerkdateisystem oder Remote-Printer. Allein schon für diese beiden Aufgaben gibt es in der Unixwelt zwei verschiedene Dienste: Beispielsweise LPD für Drucker und NFS für Netzwerkdateisysteme. SMB kann eine ganze Menge mehr: Das Samba-Paket enthält SMB-Clients, mittels derer Unix-Rechner auf freigegebene Dateien oder Drucker anderer SMB-Server zugreifen können. Ein Linuxclient kann so Druckjobs an einen Windowsdrucker absetzen oder ein gemeinsames Dokumentenverzeichnis von einer Windowsmaschine einbinden. Diese Funktionalität stellt eine Bibliothek zur Verfügung, die von anderen Programmen genutzt werden kann, bsp. dem KDE-Konqueror. Für die Kommandozeile liefert Samba die Tools smbmount, smbclient und mount.cifs mit. Samba realisiert einige Erweiterungen des SMB-Dateisystems, damit bestimmte Unix- Dateien auf entfernten SMB-Freigaben abgelegt werden können. 177

188 178 KAPITEL 12. SAMBA Samba kann die Aufgaben des Windows-Namens-Dienstes (WINS) übernehmen: Als NetBIOS-Nameserver kann es Namen auf IP-Nummern und umgekehrt abbilden. Zusätzlich unterstützt es NetBIOS-Browsing und Browse-Master-Auswahl. Samba kann ein Single-Sign-On realisieren: Der Zugriff auf den Linux-Account und die Einbindung des Linux-Homeverzeichnisses unter Windows laufen mit identischen IDs und Passwort. Samba kann als primärer Domänen-Controller für Windows-Clients eingesetzt werden. Samba bringt Werkzeuge für entfernte Administrationsaufgaben für Windows-NTund Samba-Server mit Erste Versuche Wenn Samba schon auf der Maschine installiert ist, kann der Anwender schonmal erste Schritte wagen. Wenn nicht, überspringt er diesen Abschnitt und kümmert sich ersteinmal um die Installation. Samba funktioniert in beide Richtungen : Es stellt Client- und Serverfunktionalität bereit. Für viele, die von der Windows-Seite her kommen, ist es bekannt, wie Freigaben unter Windows erfolgen. Man gibt einfach mal ein Unterverzeichnis mit Klicken der rechten Maustaste auf den Ordner frei. Dann definiert man die Einstellungen in der Registerkarte... Abbildung 12.1: Freigeben eines Verzeichnisses unter WindowsXP und Setzen der Zugriffsrechte Windows-Server - Linux-Client Diese Freigabe oder Share kann nun von Linux aus eingebunden werden. Hierzu gibts das Kommando smbmount oder sein Nachfolger mount.cifs. Mounts können aus Sicherheitsgründen unter Linux nur vom Benutzer root ausgeführt werden. Jedoch gibt es auch Möglichkeiten dieses normalen Usern zu erlauben. In der Standardinstallation liefert smbmount bei unpriveligiertem Aufruf die Fehlermeldung smbmnt must be installed suid root for direct user mounts (500,500). Dem kann man unter

189 12.2. ERSTE VERSUCHE 179 Verzicht auf etwas Sicherheit abhelfen: chmod u+s /usr/bin/smbmnt /usr/bin/smbumount. Anschliessend bindet der Aufruf smbmount // /SharedFiles win -o username=dirk die Windows-Freigabe ShraredFiles an das Unterverzeichnis win. Die Verbindung erfolgt mit der Windows-UserID dirk, das Passwort fragt smbmount dann interaktiv ab. Anschliessend gibt das Kommando mount das eingebundene Verzeichnis in seiner Liste mit an: 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) // /SharedFiles on /home/dirk/win type smbfs (0) Der Inhalt des Verzeichnisses win sind die Dateien, die sich auf der Windows-Maschine im freigegebenen Ordner befinden. Es gibt jedoch einige Einschränkungen: Dateien und Ordner kann der Nutzer wie gewohnt anlegen. Die Dateien gehören immer ihm, das Unix- Rechtemuster wird nur zum Teil abgebildet. Nicht möglich sind spezielle Dateien, wie Links, Sockets oder Named Pipes. Der Vorteil von Samba: Anders als mit NFS oder Geräten muss kein passender Eintrag in der /etc/fstab stehen, um Benutzern das Einbinden von Windows- Freigaben zu erlauben. Umgekehrt wird der Nutzer das eingebundene Share durch den Befehl smbumount wieder los: smbumount win meldet die Freigabe ab und die Liste des Mount-Kommandos reduziert sich um den entsprechenden Eintrag. Für diese kleinen Experimente ist es nicht notwendig, dass die beiden Samba-Dämonen smbd und nmbd gestartet sind. Mit der Weiterentwicklung von Windows und Samba wird das lange Zeit vorherrschende SMB-Filesystem (smbfs) zunehmend durch das mächtigere CIFS (Common Internet File System) ersetzt. Dieses drückt sich auch im Mount-Kommando für die Client-Seite aus: mount.cifs // /SharedFiles win -o username=dirk bindet mit identischer Syntax ein Windows-Share an ein Linuxverzeichnis. Bisher ist dieses jedoch nur root vorbehalten oder man räumt auch hier mittels SUID-Bit Usern das Recht ein. Leider fehlt dazu noch ein passendes Pendant zum Ausmounten. Das Eintrag in der Mount-Liste sieht ein wenig anders aus: // /SharedFiles on /home/dirk/sharedfiles type cifs (rw,mand,nosuid,nodev) Ein weiteres Tool ist smbclient. Es kann neben anderen Funktionen dem Nutzer ein FTPähnliches Interface zum Verbinden auf SMB-Dienste bieten. dirk@linux:~> smbclient -U dsuchod //dsuchod.files.uni-freiburg.de/windows Password: Domain=[PUBLIC] OS=[Unix] Server=[Samba SUSE] smb: \> ls. D 0 Mon Sep 26 18:02: D 0 Sat Sep 24 01:44: AbiSuite D 0 Sat Jun 5 02:41: [... Haufen weitere versteckte Dateien mit Punkt am Anfang... ] Bilder D 0 Thu Apr 21 13:32: Desktop D 0 Thu Jun 30 22:28: Eigene Bilder D 0 Tue Aug 16 11:35: Eigene Musik D 0 Wed Sep 8 17:27: GNUstep D 0 Thu Jan 8 12:46:

190 180 KAPITEL 12. SAMBA IM01OLYM D 0 Mon Nov 17 16:37: Mail D 0 Mon Sep 26 18:07: OpenOffice.org1.1 D 0 Wed Oct 20 09:44: PDFs D 0 Mon Jan 10 19:06: PostScripts D 0 Wed Mar 31 13:41: Slides D 0 Fri Sep 10 14:28: artikel D 0 Wed Dec 22 14:48: [... Haufen weitere Dateien und Verzeichnisse... ] blocks of size blocks available smb: \> smb: \> put einstieg.txt putting file einstieg.txt as \einstieg.txt (1488,4 kb/s) (average 1488,5 kb/s) smb: \> get ToDo Dieses Beispiel benutzt einen Standard-Fileserver auf Samba-Basis. Eine Die Verbindung zu einer Freigabe erfolgt in der bekannten Windows-Syntax: //Rechnername/Freigabe oder //IP-Adresse/Freigabe, wobei einfach die Backslashes in Slashes umgeändert werden. Erstere haben in der Shell eine besondere Bedeutung. Wenn die Verbindung unter einer vorgegebenen UserID erfolgen soll, kann der Anwender diese mit der Option -U mitteilen. Bei der Verbindungsaufnahme fragt dann smbclient nach dem Passwort. Eine Verbindung auf eine Windows-Maschine unterscheidet sich bis auf die Statuszeile nicht: dirk@linux02:~> smbclient -U dirk // /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 Linux-Server - Windows-Client Dieser Fall ist der in der Realität sicherlich häufigere: Warum im Serverraum eine Maschine mit aufwändiger grafischer Benutzeroberfläche und nicht zu vernachlässigenden Lizenzkosten stellen, wenn es stabile und günstige Alternativen gibt? Die Serverfunktionalität stellen zwei Hintergrundsdienste, die Dämonen smbd und nmbd bereit. Letzterer kümmert sich dabei um den Windows-Namensdienst (WINS) und muss nicht zwingend laufen. Der Administrator konfiguriert beide Dienste mit der gemeinsamen Datei smb.conf. Diese befindet sich je nach Distribution üblicherweise im Unterverzeichnis /etc/samba. Für einen ersten Test legt der Admin eine Minimalkonfiguration dieser Datei an oder ändert die Vorgabe der liefernden Distribution passend ab. Für erste Versuche soll das Verzeichnis vorher frisch angelegte Verzeichnis /win-export benutzt werden. Auf dieses sollen die beiden Benutzer test1 und test2 nach Eingabe ihres Passworts zugreifen können. [global] workgroup = SAMBA netbios name = MYSMB os level = 2 unix extensions = Yes encrypt passwords = Yes map to guest = nobody socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY hosts allow = ALL

191 12.3. WEITERGEHENDE KONFIGURATION 181 log level = 10 [winshare] comment = Testfreigabe fuer Windows-Clients path = /win-export locking = No read only = Yes valid users = test1 test2 create mask = 0600 directory mask = 0750 Nach aussen bietet sich die Freigabe mit dem Namen winshare an. Dieser Name muss in keiner Weise mit dem Verzeichnis, welches exportiert wird, übereinstimmen. Im Übrigen ist die Groß- oder Kleinschreibung in der smb.conf mit Ausnahme der Pfadangaben unter Linux irrelevant. Die beiden Benutzer test1 und test2 müssen lediglich als System-Accounts existieren. User benötigen für Samba nicht zwingend Linux-Loginrechte oder einen Eintrag in der /etc/shadow. Da Linux und Windows verschiedene Verschlüsselungsverfahren für Passwörter benutzen, muss selbst bei Existenz eines gültigen Linux-Passworts ein neues Windows-Passwort generiert werden. Dieses triggert der Systemadministrator durch: linux:/win-export # smbpasswd -L -a test1 New SMB password: Retype new SMB password: Passwörter, die auf diese Weise generiert wurden, landen in der Datei /etc/samba/smbpasswd. Anschliessend steht der (Neu-)Start des Dienstes durch rcsmb restart oder /etc/rc.d/smb restart an. Anschliessend greift sich der Anwender eine Windowsmaschine, die mit dem gleichen Netzwerk, wie der frisch aufgesetzte Linux-Samba-Server verbunden ist und versucht am besten erstmal durch Eingabe der IP-Nummer die neue Freigabe unter Windows einzubinden. Wenn der Nutzer unter einer anderen UserID an seiner Windows-Maschine angemeldet ist, kann er diesen bei Windows-XP beim Anmelden an die Freigabe wechseln. Auch das Passwort muss nicht mit dem der Windows-Anmeldung übereinstimmen. Soll der Samba-Server automatisch beim Start der Linuxmaschine hochfahren, kann der SuSE-Admin diesen Dienst durch insserv smb,start=3,5; insserv nmb,start=3,5 für die Runlevel 3 und 5 aktivieren. Alternativ können auch Links in den entsprechenden Runlevel-Unterverzeichnissen /etc/init.d/rc3.d und /etc/init.d/ rc5.d angelegt werden. Der Sambaserver sollte dann auch im Microsoft Windows-Netzwerk auftauchen (Abb. xpsambatestnetz). Wenn der Anwender dann auf Samba klickt, sieht er in diesem Netz mindestens den Samba-Server Mysmb. Im Kommentar steht die Versionsbezeichnung von Samba. Wenn da etwas anderes erscheinen soll, fügt der Admin server string = Kommentar mit seinem Kommentar in der [global] Sektion ein Weitergehende Konfiguration Im gezeigten ersten Beispiel bekamen die beiden Benutzer test1 und test2 ein Verzeichnis auf einer Linux-Maschine nur lesend nach Eingabe ihres Benutzernamens und Passwortes zur Verfügung gestellt. Soll eine Anmeldung für diese Freigabe auch ohne Passwort möglich sein, kann der Admin das Schlüsselwort public = Yes definieren. Dann sollte er jedoch die Option valid users leeroder weglassen. Im Fall von Fehlern und zur Kontrolle des korrekten Starts des Samba-Servers sollte der Admin das Logfile des Dienstes kontrollieren. Standardmäßig wird dieses bei einer SuSE-Distribution unterhalb von /var/log/samba angelegt. Das Logfile des smbd heisst einfach log.smbd, das des nmbd entsprechend. [2004/11/10 16:09:36, 0] smbd/server.c:main(757) smbd version SUSE started. Copyright Andrew Tridgell and the Samba Team

192 182 KAPITEL 12. SAMBA Abbildung 12.2: Durch die direkte Eingabe der IP-Nummer umgeht der Anwender eventuelle Probleme bei der Windows-Namensauflösung [2004/11/10 16:09:36, 5] lib/debug.c:debug_dump_status(369) INFO: Current debug levels: all: True/10 tdb: False/0 printdrivers: False/0 lanman: False/0 smb: False/0 rpc_parse: False/0 rpc_srv: False/0 rpc_cli: False/0 passdb: False/0 sam: False/0 auth: False/0 winbind: False/0 vfs: False/0 idmap: False/0 quota: False/0 acls: False/0 doing parameter veto files = /*.eml/*.nws/riched20.dll/*.{*}/ [2004/11/10 16:09:36, 2] param/loadparm.c:do_section(3396) Processing section "[winshare]" doing parameter comment = Testfreigabe fuer Windows-Clients doing parameter path = /win-export doing parameter locking = No doing parameter read only = Yes

193 12.3. WEITERGEHENDE KONFIGURATION 183 doing parameter valid users = test1 test2 doing parameter create mask = 0600 doing parameter directory mask = 0750 [2004/11/10 16:09:36, 4] param/loadparm.c:lp_load(3913) pm_process() returned Yes [2004/11/10 16:09:36, 7] param/loadparm.c:lp_servicenumber(4026) lp_servicenumber: couldn t find homes [2004/11/10 16:09:36, 3] param/loadparm.c:lp_add_ipc(2363) adding IPC service [2004/11/10 16:09:36, 3] param/loadparm.c:lp_add_ipc(2363) adding IPC service [... ] Mit dem im Beispiel eingestellten Loglevel von 10 ist der Dienst ziemlich geschwätzig. Das macht bei funktionierendem Normalbetrieb weniger Sinn. Je nach Sicherheits- und Informationsbedürfnis genügt ein Loglevel von 0 bis 3 für die wichtigsten Ereignisse. Meldungen über Fehler in der Konfigurationsdatei landen in jedem Fall hier. Eine weitere Möglichkeit der Überprüfung des Server-Zustandes bietet das Kommando smbstatus. Einfach aufgerufen liefert es eine Liste der aktuell gültigen Verbindungen: linux:~ # smbstatus Samba version SUSE PID Username Group Machine test2 testgroup zxs ( ) Service pid machine Connected at winshare zxs Wed Sep 21 18:33: No locked files Homeverzeichnisse für Windows und Linux Sollen Benutzer ein gemeinsames Homeverzeichnis unter Linux und Windows benutzen, erlaubt dieses die spezielle Sektion [homes] in der Konfigurationsdatei /etc/samba/smb.conf: [homes] comment = Home Directories valid users = %S browseable = Yes read only = No create mask = 0640 directory mask = 0750 Möchte man einer Benutzergruppe das gemeinsame Zugriffsrecht auf eine Freigabe einräumen, muss diese vorher in /etc/group definiert sein. [gruppenfreigabe] comment = Beispiel einer Gruppenfreigabe read only = No browseable = No valid users force group = testgroup path = /gruppenfreigabe create mask = 0770 force create mode = 0770 directory mask = 0770 force directory mode = 0770

194 184 KAPITEL 12. SAMBA In diesem Beispiel dürfen alle Mitglieder der Gruppe testgroup sich mit dem Share verbinden. Alle Dateien und Verzeichnisse werden so angelegt, dass nur Gruppenmitglieder sie ändern dürfen. Die Maske 0770 erzwingt Gruppenschreibrechte und verhindert gleichzeitig, dass Dateien nur vom Erzeuger selbst geändert werden dürfen. Die Option browseable = No sorgt dafür, dass die Freigabe nicht in der Netzwerkumgebung auftaucht Druckerfreigaben Bis zu diesem Punkt wurden verschiedene Arten der Verzeichnisfreigaben diskutiert. Das SMB-Protokoll erlaubt es aber auch, Drucker im Netz gemeinsam zu benutzen. Hierzu gibt es die Sektion [printers] in der /etc/samba/smb.conf. [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No writable = yes public = yes Viele der Optionen sind nun schon von den anderen Beispielen bekannt. Die Pfadangabe dient nun nicht als Freigabe, sondern als Spoolverzeichnis. In diesem landen die abzuarbeitenden Jobs der berechtigten Benutzer. In den Globaleinstellungen der smb.conf sind zwei weitere Variablen zu definieren. Der Admin legt fest, welches Drucksystem Verwendung findet. Auf modernen Distributionen greift er üblicherweise auf das Common Unix Printer System (CUPS) zurück: printing = CUPS printcap name = CUPS Der Dienst CUPS muss vor Samba gestartet werden. Dieses überprüft insserv beim Anlegen der Runlevel-Links. Die Installation von Druckern unter Linux erledigt der Admin am einfachsten mit den mitgelieferten Konfigurationswerkzeugen, beispielsweise YaST2 von SuSE. Nach einem Neustart von Samba stehen die frisch definierten Druckerwarteschlangen auch Windows-Clients zur Verfügung Nachrichtendienst auf Linux-Clients Der Windows-Nachrichtendienst ist bei Anwendern, die mit ihrer Windows-Maschine direkt ins Internet gehen vielleicht etwas in Verruf geraten. Vielfach meldeten sich unaufgefordert explizite Damen, um ihre Services irgendwo im Netz anzubieten. Im abgeschlossenen privaten Netz kann der Dienst jedoch ganz nützlich sein. Damit auch ein Linux- Client Windows-Nachrichten empfangen kann, muss ein Samba laufen. Dieses wurde in der [global]-sektion um den Eintrag message command = sh -c /opt/kde3/bin/kpopup %s %f erweitert. Das Programm kpopup ist meistens ein eigenes Paket, welches unter Umständen nachinstalliert werden muss. Je nach Distribution können Pfad und Paketname variieren Die zentrale Samba-Konfigurationsdatei In den bisherigen Abschnitten kamen schon Beispiele für mögliche Varianten der smb.conf vor. Da es eine ziemlich große Zahl an Konfigurationsparametern, sollen die wichtigsten hier zusammengestellt werden. Eine gute Hilfe ist auch die Manpage (man smb.conf).

195 12.4. DIE ZENTRALE SAMBA-KONFIGURATIONSDATEI Struktur Die Datei smb.conf wird durch Konfigurationsblöcke strukturiert. Der Block [global] - er steht am besten immer am Anfang der Datei - ist immer vorhanden und definiert generelle Servereinstellungen. Daneben existiert eine weitere Gruppe von optionalen Blöcken, deren Namen fest vorgegeben sind. Der Block [homes] definiert die Freigabe der Homeverzeichnisse der auf einem Linuxsystem eingetragenen Benutzer. So können Admins dafür sorgen, dass ihre Nutzer sowohl unter Linux als auch unter Windows auf das selbe Homeverzeichnis zugreifen können. Mit [printers] erfolgt die Freigabe der auf einem Linuxrechner verfügbaren Drucker. [print$] ist eine spezielle Freigabe, die es Administratoren erlaubt, Druckertreiber bereit zu stellen. So müssen diese dann nicht mittels CD eingespielt werden, wenn ein Windows-Client auf einen Linuxdrucker zugreift für den dieser noch keinen Treiber installiert hat. Die Sektion [netlogon] spielt dann eine Rolle, wenn Samba über Datei- und Druckerfreigaben hinaus reichende Aufgaben übernehmen soll. Zusätzlich kann ein Samba-Administrator weitere Blöcke definieren. Die Namen dieser Blöcke entsprechen den Freigabenamen, die ein Windows-Client sieht oder anspricht. Die Zuweisung von Inhalten an eine Konfiguration erfolgt mittels simplem = - links steht der Variablenname und rechts die Zuweisung. Zuweisungen von mehr als einem Wert sind durch einfache Abstände voneinander getrennt Wichtige Optionen in der Sektion [global] workgroup = SAMBA - ordnet den Linux-Samba-Server in die Windows-Arbeitsgruppe oder Domain SAMBA ein. Diese Maschine erscheint sodann in der Windows-Netzwerkumgebung in einem Unterordner mit diesem Namen. netbios name = MYSMB - legt fest, dass die Maschine unter dem Windows-Namen MYSMB in der Netzwerkumgebung auftaucht und angesprochen werden kann. Dieser Name muss nicht identisch zum FQDN des TCP/IP Domain Name System sein. Soll Samba einfach den Linux-Rechnernamen benutzen, kann dieser Eintrag entfallen. os level = 64 - bestimmt darüber mit welchem Wert sich Samba für Browse-Wahlen anbietet. Das entscheidet beispielsweise über die Chance ein lokaler Masterbrowser einer Arbeitsgruppe zu werden. unix extensions = Yes - dieser Parameter stellt ein, ob Samba die CIFS Extensions für Unix unterstützt. Damit stehen dann Symbolische Links, Hard Links,... zur Verfügung. Nur interessant für Unix-Clients. encrypt passwords = Yes - neuere Windows-Clients erwarten verschlüsselte Passwörter. Deshalb kann nicht die klassische Unix-Shadow zum Einsatz kommen. Damit Samba korrekt authentifizieren kann, hat es entweder Zugriff auf eine lokale smbpasswd Datei oder kann gegen einen entsprechenden Dienst authentifizieren. log file = /var/log/log.%m - überschreibt die einkompilierte Default-Position des Logfiles. %m wird durch den Dienst nmbd oder smbd ersetzt, welcher Log-Informationen generiert. log level = 10 - steigende Werte generieren umfangreichere Logfiles. Es können einzelnen Komponenten unterschiedliche Loglevel zugeordnet werden: log level = 3 passdb:4 auth:8 winbind:3.

196 186 KAPITEL 12. SAMBA bind interfaces only = Yes - definiert, auf welchen Netzwerkschnittstellen der Samba-Server seine Dienste anbietet. Diese Option arbeitet mit der folgenden eng zusammen. interfaces = /24 - legt fest, dass sowohl das Loopback- Interface und das Interface mit der IP bedient werden. Letzeres umfasst ein Netzwerk von 256 Maschinen (Netzmaske ). hosts allow = All - legt keine Beschränkungen auf bestimmte Maschinen fest. Hier könnte sonst auch eine leerzeichengetrennte Liste von IP-Nummern stehen, die auf den Service zugreifen dürfen. message command = /bin/bash -c /usr/x11r6/bin/xterm -T WinPopup Message -e /usr/bin/vim %s; rm %s & - erlaubt es unter Linux ebenfalls Windows-Popup-Messages zu empfangen. Die Nachrichten reicht Samba an ein externes Programm - hier ein einfaches xterm mit vi weiter. %s enthält den Inhalt der Nachricht, %t ist der Zielname, an den die Nachricht ging. %f bezeichnet den Client, von dem die Nachricht kam Wichtige Optionen der anderen Abschnitte comment = All Printers oder comment = Gemeinsame Daten - setzen ein Kommentar für eine Freigabe fest, die an die Clients übermittelt wird. path = /win-export - legt für Dateifreigaben fest, welches Verzeichnis im Linux- Dateibaum Samba bereitstellen soll. Für Drucker definiert diese Variable das Spoolverzeichnis. create mask = definiert das Rechtemuster beim Anlegen von Dateien. Hierzu werden die Permissions vom Mapping von DOS oder Linux bestimmt und diese dann mit dem Muster UND-verknüpft. Das Muster entspricht dem von chmod bekannten. force create mask = erzwingt das Setzen eines bestimmten Bitmusters für die Zugriffsrechte. Im Bespiel würde eine Datei auf jeden Fall die Rechte -rw bekommen. directory mask = stellt das Analogon zu create mask dar. Es legt fest mit welchem Rechtemuster Samba neu angelegte Verzeichnisse versieht. Auch hier gibt es die Option force directory mask. valid users = test1 test2 - nimmt eine Leerzeichenseparierte Liste von Benutzern auf, die auf diesen Dienst verbinden dürfen. In der Sektion [homes] findet man hier valid users = %S. %S wird durch den Namen des sich anmeldenden Nutzers automatisch ersetzt. Deshalb muss nicht für jeden der vielleicht viele hundert oder tausend Benutzer umfassenden Maschine eine eigene Freigabe definiert werden. browseable = No - kontrolliert, ob die Freigabe in einer Browse-Liste der Netzwerkumgebung angezeigt wird oder nicht. read only = No oder writable = Yes - erlaubt dem Benutzer eines Services Dateien oder Verzeichnisse anzulegen und zu verändern. printable = Yes - erlaubt dem Client auf das Drucker-Spooler-Verzeichnis zu schreiben.

197 12.5. CONTROLLER-FUNKTIONALITÄT 187 public = Yes alternativ guest ok = Yes - legen fest, ob eine Verbindung ohne Passwort möglich ist. Die Rechte sind dann die des Gast-Accounts Virtuelle Samba-Server Der Apache-Webserver macht es seit einiger Zeit vor: Ein Server sollte in der Lage sein, mehr als eine Identität gleichzeitig anzunehmen. Auch das SMB-Protokoll kann namensbasierte virtuelle Server anzubieten. Dabei befinden sich alle in der gleichen Arbeitsgruppe. Sinn und Zweck dieser Übung - eine Maschine ist unter mehreren Namen in der Netzwerkumgebung sichtbar. Der Admin konfiguriert dieses Verhalten durch die Option netbios aliases = VIRTUAL01 VIRTUAL02 VIRTUAL03. Ein solcher Eintrag steht in der smb.conf in der Sektion [global]. Die Anzahl der Aliases (hier drei) schreibt Samba nicht vor. Kommt die Option netbios aliases zum Einsatz, muss auch der netbios name eingestellt sein. Das ist jetzt noch nicht besonders spannend: Schaut man sich nun in der Netzwerkumgebung auf dem Client die Freigaben von VIRTUAL01, so unterscheiden diese sich nicht von den anderen. Will man einem virtuellen Server nun eine angepasste Einstellung verpassen, braucht man eine separate smb.conf für diesen. Der Name der Datei lautet am besten auf smb.conf + Servername = smb.conf.virtual01. Hierin können nun wieder beliebige Freigaben eingestellt werden. Damit Samba weitere Konfigurationsdateien beim Start berücksichtigt, fügt man ein include Statement ein: include = /etc/samba/smb.conf.%l". %L setzt den Servernamen ein, der beim NetBIOS-Verbindungsaufbau angeforder wurde. Beim Aufsetzen der verschiedenen Dateien ist zu beachten, dass alle Freigaben der Hauptdatei auch für alle virtuellen Server gelten Controller-Funktionalität Die bisher vorgestellten Beispiele demonstrierten nur einen Teil der Sambafähigkeiten. Solche Konfigurationen sind eher in sehr kleinen und kleinen Netzwerken mit wenigen Rechnern und Nutzern sinnvoll. In vielen Fällen kann es für Administratoren attraktiv sein, den Samba-Server auch zur Namensauflösung als WINS-Server oder als Ersatz eines Primary Domain Controllers zu verwenden. Dann möchte er jedoch häufig auch Ziele, wie Single- Sign-On verwirklichen. Hierzu läßt sich Samba mit dem Directory-Dienst LDAP verbinden. Die notwendigen Konfigurationen sind dann jedoch deutlich komplexer Der Windows Namensdienst Viele werden sich fragen, wozu ein weiterer Namensdienst, wo es doch schon das Domain Name System (DNS) gibt. DNS ist fest mit TCP/IP verknüpft - SMB jedoch nicht, auch wenn es heute kaum noch jemand anders als zusammen mit diesem einsetzt. Viele kennen das Problem: Den Namen einer Person können sich viele noch merken, mit den dazugehörigen Telefonnummern wird es schwieriger. Dann zieht diese Person um und die Nummer ändert sich. Hier möchte man ein Telefonbuch haben, welches Namen Nummern zuordnen kann. Diese Aufgabe übernimmt der Windows Internet Name Service. Dieser unterscheidet sich signifikant vom klassischen DNS. So könnte man ja mal versuchen einer Windows- Maschine per DHCP einen Hostnamen zuzuweisen, was unter Linux/Unix kein Problem darstellt. Auch habt man sicherlich schnell festgestellt, dass Microsoft unter dem Konzept ein Windows-Domäne etwas ganz anderes sieht als ein Domain-Name, wie in Web-Adressen. Der NetBIOS-Name-Service wird in den RFCs 1001 und 1002 beschrieben. Er bietet Clients eine vergleichbare Art von Dienst wie DNS. Es bestehen jedoch einige wesentliche Hauptunterschiede. NetBIOS-Namen existieren in einem flachen Namensbereich.

198 188 KAPITEL 12. SAMBA Das ist beim DNS völlig anders. Keiner hindert einen daran, einen Rechner in der Subdomain pool01.lehrpools.rechenzentrum.uni-freiburg.de mit dem Namen dozenten-rechnervorne-links zu betreiben. Die Namenskomponenten zwischen den Punkten dürfen 63 und der Gesamtname nicht 255 Zeichen überschreiten. Damit lassen sich einige Hierarchiestufen erreichen. Unter WindowsXP gibt es zwei Möglichkeiten einen WINS-Server einzutragen. Zum einen kann der Admin des Netzes diese Information mittels DHCP an alle Clients verteilten: Abfragen lässt sich diese Information beispielsweise mit ipconfig -all in der Eingabeaufforderung. Alternativ kann man die IP für WINS auch fest bei der Alternativen Konfiguration von TCP/IP eintragen. Abbildung 12.3: Zwei Wege der Zuweisung der WINS-Server-Adresse NetBIOS Namen NetBIOS-Namen bestehen aus 16 alphanumerischen Zeichen, wobei a bis z, A bis Z und 0 bis 9 erlaubt sind. Zusätzlich dürfen die Sonderzeichen!@#$% ˆ&()- {}. vorkommen. Die ersten 15 Zeichen dienen der Benennung, das sechzehnte Zeichen ist eine Zahl von 0x00 bis 0xFF hexadezimal, die den Ressourcentyp des Namens bestimmt. Es gibt zwei Namenstypen: Entweder sie sind exklusiv einem Benutzer oder einer Maschine zugeordnet oder sie sind Gruppennamen. Letztere können gemeinsam benutzt werden. Der NetBIOS-

199 12.5. CONTROLLER-FUNKTIONALITÄT 189 ID Bedeutung < 00 > NetBIOS Name eines Rechners (Freigabename einer Workstation) < 03 > Messenger Service Name - verwendet zum Empfangen und Übertragen von Nachrichten, sowohl für User- als auch Rechnernamen < 06 > Routing und Remote Access Service (RAS) - Name des Servers < 1B > Domain Masterbrowser Name - wird von Maschinen im Netz genutzt, um den Primary Domain Controller (PDC) einer Windows-Domain zu kontaktieren < 1F > Network Dynamic Data Exchange (NetDDE) Dienst < 20 > Server-Dienstname - Zugriffspunkte für freigegebene Dateien und Verzeichnisse < 21 > RAS-Client < BE > Network Monitor Agent < BF > Network Monitor Utility Tabelle 12.1: Eindeutige Namen Name MYSMB< 00 > aus dem Beispiel des vorangegangenen Abschnitts ist ein eindeutiger Name. Er beschreibt den Computer MYSMB. Die Bezeichnung SAMBA-TESTNETZ< 1e > hingegen ist ein Gruppenname. Ihn benutzen Browsing-Clients, um einen Master- Browser unter sich zu bestimmen. NetBIOS-Namen spannen nur einen flachen Namensbereich auf. Trotzdem sind in einm gleichen logischen Subnetz mehrere Namensbereiche erlaubt. Diese werden durch den NetBIOS-Scope unterschieden. Der NetBIOS-Scope ist ein String, der zusammen mit dem NetBIOS-Namen 256 Zeichen nicht überschreiten darf. ID Bedeutung < 1D > Masterbrowser-Name - wird vom Client benutzt, um auf den Masterbrowser zuzugreifen (je nach Netz lokaler Masterbrowser) < 1E > Gruppenname - kommt bei der Wahl von Browse-Mastern zum Einsatz Tabelle 12.2: Gruppenressourcen Die Namensvergabe im NetBIOS geht anders als bei DNS vom Client aus: Eine Maschine versucht beim Start einen Namen zu registrieren. Dieses ist erfolgreich, wenn der Client-Rechner ein erfolgreiches Namensangebot gemacht und vom Server den Namen für sich erhalten hat. Versucht eine Maschine A einen im Scope schon vergebenen Namen zu registrieren, antwortet der Besitzer mit dem Hinweis, dass er den Namen behält. Dieses Verfahren ist eine Methode inaktive Hosts zu entdecken, die den Besitz eines Namens nicht offiziell aufgegeben haben. ID Bedeutung < 00 > Zum Empfang von Browser-Broadcasts < 1C > Arbeitsgruppenname - wird vom Domain Controller registriert und enthält eine Liste von Computern, die sich unter dieser Gruppe registriert haben Internet Gruppe < 1E > Gleiche Bedeutung, wie bei Gruppenressourcen < 20 > Identifikation eine Gruppe von Rechnern für administrative Zwecke Tabelle 12.3: Domänennamen

200 190 KAPITEL 12. SAMBA NetBIOS kennt zwei Methoden für die Registrierung und Auflösung von Namen: Broadcast und Point-to-Point. Die Point-to-Point-Registrierung und -Auflösung geschieht mittels eines eigenen Dienstes - NetBIOS-Nameserver (NBNS). Broadcast-Registrierung oder -Auflösung heißt, dass die Anfrage an alle Hosts im gleichen logischen Subnetz mit dem gleichen Scope gesendet wird. Router können diese Broadcasts weitergeben. Das ist in der Regel in größeren Netzen mit vielen Windwosmaschinen nicht sehr clever, da sehr viel Datenverkehr generiert wird. Diese Methode kam implizit in den Konfigurationsbeispielen der vorangegangenen Abschnitte zum Einsatz Der Nameserver (WINS) Ein WINS macht nicht nur zur Reduzierung der Menge des Broadcast-Datenverkehrs Sinn, die durch eine große Anzahl von NetBIOS-Clients erzeugt werden kann. Ein weiteres Problem in NetBIOS-Netzen ist die übliche Beschränkung der Broadcasts auf ein logisches Subnetz. Das führt dazu, dass Rechner in verschiedenen Subnetzen nicht über die Namen miteinander kommunizieren können. WINS löst beide Probleme. Die Aufgabe eines WINS übernimmt im Samba-Paket der nmbd. Die Aktivierung erfolgt durch die Option wins support = Yes. Ist bereits ein solcher Dienst im Subnetz vorhanden, steht in wins server die IP des entsprechenden Rechners. wins support sollte dann auf No gesetzt sein. Da die Namensvergabe durch die Clients initiiert wird, sind keine wesentlichen Einstellungen neben workgroup und eventuell netbios name in der smb.conf notwendig. Samba erlaubt es DNS und WINS miteinander zu verknüpfen. Wenn Samba als WINS- Server (wins support = Yes) agiert, kann der nmbd alle Namensanfragen im DNS versuchen zu finden, wenn er keinen entsprechenden Eintrag in der lokalen WINS-Datenbank gefunden hat. Der Parameter dns proxy bestimmt dieses Verhalten. Samba befragt standardmäßig den DNS, wenn ein Name nicht in WINS gefunden wird. Dieses Verhalten entspricht: dns proxy = Yes. Gibt es kein DNS im eigenen Netzwerk, macht Sambas dns proxy nicht viel Sinn. Mittels dns proxy = No läßt er sich deaktivieren. Eine Methode zur Namensauflösung in sehr kleinen Netzwerken ist der Weg über eine Textdatei. Das Konzept der lmhosts Datei kennt der Admin vielleicht schon Windows- Rechnern. Sie kann auch von Samba verwendet werden und entspricht funktionell der von Linux bekannten Datei /etc/hosts. Der einzige Unterschied: Sie ordnet IP-Adressen NetBIOS- Namen zu anstelle von Hostnamen. Samba schaut in der lmhosts nur für eigene Fragen nach, nicht für die Anfragen von anderen Maschinen im Netzwerk. Der Parameter name resolve order bestimmt dieses Verhalten. Wenn also die Reihenfolge name resolve order = lmhosts wins eingestellt ist, würde Samba selbst keine Namensanfragen per Broadcast aussenden und nicht versuchen, Namen über den DNS aufzulösen. Es würde nur in der lokalen lmhosts Datei nachschauen und bei Misserfolg den konfigurierten WINS-Server befragen. Eine NetBIOS-Namensanfrage macht nmblookup -R -U localhost MYSMB. Die Optionen sorgen dafür, dass ein WINS-Server befragt wird, anstatt lediglich ein Broadcast in das lokale Subnetz zu machen. Sambas lmhosts Datei und eine, die von Windows-Clients verwendet wird, unterscheiden sich im Format etwas. Es kann Sinn machen hier den PDC einzutragen, da manchmal sonst eine Verbindung auf diesen über Router hinweg fehlschlägt. Unter WindowsXP liegt diese Datei in /WINDOWS/system32/drivers/etc. Üblicherweise sieht ein Eintrag so aus: MYSMB #PRE #DOM:SAMBA Für einfache Hosts reicht die Kombination aus IP-Nummer und NetBIOS-Name.

201 12.6. SAMBA ALS PDC Samba als PDC Zur großen Form läuft Samba auf, wenn es nicht nur einfache Freigaben bereitstellt und Namen auflöst. Windowsnetze erlauben seit Windows-NT eine zentralisierte Steuerung. So können beispielsweise Benutzer zentral an einer Maschine authentifiziert werden, ohne dass sie auf dem lokalen Endgerät eingetragen sind. Hierzu führte Microsoft das Konzept der Domäne ein. Eine Domäne definiert eine Gruppe von Rechnern, die eine gemeinsame Benutzerdatenbank verwenden. Diese Benutzerdatenbank stellen sogenannte Primary (PDC) und Backup Domain Controller (BDC) zur Verfügung. Für jedes Domänenmitglied - dieses können Benutzer und Rechner sein - wird ein zentrales Konto angelegt. Für jedes Domänenmitglied muss ein Benutzerkonto, auch Computerkonto genannt, auf dem PDC existieren. Samba kann die Rolle des PDC, bisher jedoch noch nicht die eines BDC übernehmen. Hierzu stellt der Admin in der globalen Sektion der smb.conf zuerst folgende Optionen ein: workgroup = SAMBA netbios name = MYSMB os level = 64 domain master = Yes domain logons = Yes preferred master = Yes wins support = Yes wins proxy = Yes Einige Optionen sollten aus dem bisher gesagten bekannt sein. Der hohe OS-Level sorgt dafür, dass die Maschine die Wahl der Browser gewinnt. Nun sollte der Samba-Server neu gestartet werden: rcsmb restart; rcnmb restart. Die Sache mit Win9x-Clients ist einfach: Man kann den Samba-PDC sofort ohne weitere Konfiguration als Anmeldeserver verwenden. Beim Einsatz der professionellen Windowsvarianten NT, 2000 oder XP sind noch einige Nacharbeiten notwendig. Es müssen erst Computer-Konten existieren (Im Beispiel die Maschine zxs) und ein Benutzer root in die Samba-Passwort-Datenbank aufgenommen sein, bevor die Aufnahme einer solchen Maschine gelingt. useradd -d /var/tmp -s /bin/false zxs\$ smbpasswd -a -m zxs\$ smbpasswd -a root Nun sind auf der Windows-Maschine einige Schritte dran: Zuerst legt man einen Key in der Windows-Registry an. Das geschieht beispielsweise mittels Datei, die in die Registry geladen wird: Windows Registry Editor Version 5.00 [HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters] "requiresignorseal"=dword: Anschliessend startet man die Systemsteuerung und wählt dort den Unterpunkt System. In den nun angezeigten Systemeigenschaften geht es zur Karteikarte mit den Computernamen. Hierin erlaubt der Knopf Ändern die Aufnahme der Maschine in eine Windows- Domäne. Im nun erscheinenden Dialog legt man den NetBIOS-Namen der Maschine fest und tritt der Domäne bei. Dafür muss der Radio-Button Mitglied von Dommäne aktiviert und der Name der beizutretenden Domäne daneben eingetragen werden. Nach dem

202 192 KAPITEL 12. SAMBA Abbildung 12.4: WindowsXP-Maschine in eine Domäne aufnehmen Bestätigen durch OK erscheint ein Anmeldedialog für den Domain-Administrator. Das ist der Benutzer root, dem mittels smbpasswd ein Sambapasswort verpasst wurde. Wenn nun alles glatt ging, erscheint eine kurze Willkommensmeldung, die den Domänenbeitritt bestätigt (Siehe Abb. 12.6). Anschliessend muss der Client neu starten. Nach erfolgtem Start kommt nun der klassischen Anmelde-Dialog. Unter Optionen können Benutzer jetzt auswählen, ob sie sich lokal an der Maschine oder durch Authentifizierung gegen die Domain SAMBA anmelden wollen. Nun können sich alle Benutzer anmelden, die Samba bekannt sind. Wenn die Beispiele aus den vorangegangenen Abschnitten beibehalten wurden, sind das die Benutzer test1 und test Benutzerprofile und Logon-Skripten Beim ersten Test-Login sehen die Benutzerprofile der beiden test1 und test2 noch sehr nackt aus. Es erscheint lediglich die Windows-Voreinstellung des Desktops. Damit ein Benutzer an verschiedenen Workstations stets das gleiche Profil vorfindet, läßt sich das Profil serverbasiert speichern. Es wird dann wärend des Anmeldevorganges auf die Client- Maschine kopiert, vor der der Benutzer sitzt. Dieses kann nicht einfach umgangen werden, da viele Anwendungsprogramme ein lokales Profil verlangen, das nicht einfach, wie von Linux gewohnt, im Homeverzeichnis liegt. Da sich die Einstellungen im Laufe einer Sitzung ändern können, müssen sie auch wieder zurückgesichert werden. Das geschieht beim Abmelden von der Arbeitsstation. Will der Administrator ganz neue Benutzer hinzufügen, muss er diese erst als Linux- Accounts anlegen und anschliessend mit smbpasswd -a UserID in die Samba-Benutzerdatenbank kopieren. Nun müssen noch einige Eintragungen in der smb.conf vorgenommen werden. Mit dem Eintrag

203 12.6. SAMBA ALS PDC 193 Abbildung 12.5: Domänen-Aufnahme - Passwortdialog logon path = \\%N \%U\profile (für NT/2000/XP) ; alternativ: logon home = \\%N \%U\profile (für Windows 9x) in der [global]-section der smb.conf wird im Heimatverzeichnis des Benutzers ein Verzeichnis namens profile erstellt und das Profil dort gespeichert. Der Service erhält eine eigene Sektion in der Konfigurationsdatei: [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 Zur Aktivierung dieses Features ist ein Neustart des Servers erforderlich. Damit bei der Benutzeranmeldung noch Anpassungen seiner Umgebung vorgenommen werden können, kann ein Logon-Skript ausgeführt werden. Dieses definiert der Admin mittels logon script = scripts/default.bat Dieses Skript wird unter Windows ausgeführt, sollte also die richtigen Zeilenschaltungen besitzen. Entweder der Admin editiert es unter Windows selbst und kopiert es in das Netlogon-Verzeichnis. Oder man konvertiert die Datei entsprechend. Auch dieser Dienst besitzt einen eigenen Abschnitt: [netlogon] comment = Network Logon Service path = /hom/netlogon write list force group = ntadmin

204 194 KAPITEL 12. SAMBA Abbildung 12.6: Begrüßung in der neuen Domäne create mask = 0664 directory mask = 0775 browsable = No Ein Beispielskript für NT findet sich je nach eingesetzter Linux-Distribution im Samba- Doku-Paket unter:.../doc/.../samba/examples/ntlogon/ntlogon.conf Samba und LDAP Was in kleinen Netzen noch per Hand zu managen ist, will der Admin in großen Netzen professioneller regeln. Das Anlegen von Benutzern nach dem soeben beschriebenen Verfahren ist für große Netze mit vielen Linux- und Windows-Rechnern, an denen sich ein Nutzer anmelden kann, zu umständlich. Hier hilft eine hierarchische Datenbank weiter, die sich für solche Zwecke geradezu anbietet. LDAP - das Lightwight Directory Access Protocol (vgl. Kap. 13.3) ist ein verabschiedeter Internet-Standard. Microsoft verwendet dieses als Grundlage für seine Active Directory Service. OpenLDAP ist eine OpenSource-Implementierung, die standardmäßig bei Ihrer Linuxdistribution dabei sein sollte. LDAP arbeitet im Client- Server-Modell über TCP/IP. Samba kann als LDAP-Client agieren und alle Informationen, die es für seinen Betrieb braucht aus dem Directory beziehen und veränderte Daten wieder zurückschreiben. Diese Daten landen sonst in den *.tdb, die sich unter /etc/samba und /var/lib/samba finden. Sollte noch kein LDAP-Server auf der Samba-Maschine installiert sein, sollte man diesen Schritt nun nachholen. Neben den Basispaketen für den Server und die Client-Programme benötigt die Installation zusätzlich pam ldap, nss ldap und ldapsmb, wenn auch die Verwaltung der Linux-Benutzer mittels LDAP erfolgen soll.

205 12.7. SAMBA UND LDAP Konfiguration des LDAP-Servers Es gibt ein eigenes Kapitel dieses Skriptes 1. Im nächsten Schritt erweitert man die Liste der standardmäßig benutzten Schemas um eines für Samba3. Dieses installiert SuSE bereits automatisch in das richtige Verzeichnis. Kümmert sich Ihre Distribution nicht darum, findet man sicherlich das Schema als Beispiel in der Dokumentation des Samba-Paketes. Minimalkonfiguration der /etc/openldap/slapd.conf inlcude [... ] suffix rootdn rootpw /etc/openldap/schema/samba3.schema "dc=my-domain,dc=site" "cn=manager,dc=my-domain,dc=site" GeheiM Zusätzlich passen Sie die Benennung Ihrer LDAP-Wurzel an (suffix), definieren entsprechend den Datenbank-Manager (rootdn) und setzen für diesen ein Passwort (rootpw). Einige dieser Einstellungen finden Sie auch in der neuen smb.conf wieder (ldap *) Die neue Samba-Konfiguration Für den Schritt hin zu einem LDAP-Backend sichern Sie am besten Ihre bisherige Konfiguration und starten mit einer neuen. Eine sehr gute Hilfe und Bauanleitung liefert auch der Samba-Guide, der als PDF und HTML in der Samba-Dokumentation mitgeliefert wird. [global] unix charset = LOCALE workgroup = SMB-LDAP netbios name = MYSMBLDAP passdb backend = ldapsam:ldap:// / # username map = /etc/samba/smbusers log level = 1 smb ports = 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:// / idmap uid = idmap gid = map acl inherit = Yes add user script = /var/lib/samba/sbin/smbldap-useradd.pl -a -m %u delete user script = /var/lib/samba/sbin/smbldap-userdel.pl %u add group script = /var/lib/samba/sbin/smbldap-groupadd.pl -p %g delete group script = /var/lib/samba/sbin/smbldap-groupdel.pl %g add user to group script = /var/lib/samba/sbin/smbldap-groupmod.pl -m delete user from group script = /var/lib/samba/sbin/smbldap-groupmod.pl 1 zumindest in den meisten Kompilationen. (vgl. Kap. 13.3) Sonst gibt es das evtl. extra oder über per CVS zu beziehen.

206 196 KAPITEL 12. SAMBA set primary group script = /var/lib/samba/sbin/smbldap-usermod.pl -g % add machine script = /var/lib/samba/sbin/smbldap-useradd.pl -w %u logon script = scripts\logon.bat logon path = \\%L\profiles\%U logon drive = H: printcap name = CUPS printing = cups printer admin = Administrator [homes] comment = Home Directories valid users = %S read only = No inherit permissions = Yes browseable = No [profiles] comment = Network Profiles Service path = %H read only = No create mask = 0600 directory mask = 0700 store dos attributes = Yes [users] comment = All users path = /home read only = No inherit permissions = Yes [groups] comment = All groups path = /home/groups read only = No inherit permissions = Yes Vor dem Neustart des Samba-Servers mit der umgebauten Konfiguration entfernt der Admin am besten noch die alten *.tdb und *.dat Dateien aus den beiden oben angebenen Verzeichnissen. Da der Samba-Server mit dem LDAP-Server kommuniziert und Einträge anlegt, benötigt Samba das Manager-Passwort: linux2:/etc/samba # smbpasswd -w GeheiM Setting stored password for "cn=manager,dc=my-domain,dc=site" in secrets.tdb Dann wird es Zeit die Server mit: rcsmb (re)start; rcnmb (re)start; rcldap (re)start; - oder passend zur jeweiligen Distribution - neu zu starten. Am besten wirft man einen kurzen Blick ins Logfile /var/log/samba/log.smbd, ob keine Fehler aufgetreten sind. Der Befehl smbclient -L localhost -U% sollte nun eine Serverstatusmeldung generieren. Mit dem Kommando linux2:/etc/samba # net getlocalsid [2004/11/22 19:51:17, 0] lib/smbldap.c:smbldap_search_suffix(1101) smbldap_search_suffix: Problem during LDAP search: (No such object) SID for domain MYSMBLDAP is: S linux2:/etc/samba # ls -la secrets.tdb -rw root root 8192 Nov 22 19:45 secrets.tdb erzeugt man einen eindeutigen Idenfier für die Maschine. Anschliessend gibts auch wieder eine secrets.tdb.

207 12.7. SAMBA UND LDAP Die IDEALX-Skripten Nun braucht mal die idealx.com Samba-LDAP-Skripten. Die muss sich der Admin meistens nicht irgendwoher organisieren. Sie sollten Bestandteil des Samba-Doc-Paketes sein. Die Autoren des Samba-Guide schlagen vor die Skripten und ein zu kompilierendes mkntpwd in ein Unterverzeichnis /var/lib/samba/sbin zu verschieben. Auf einem SuSE-Linux ist mkntpwd bereits unter /usr/sbin installiert. Der Compile-Schritt kann entfallen. Also führt man in linux2:/usr/share/doc/packages/samba/examples/ldap/smbldap-tools # cd mkntpwd make cd.. mkdir /var/lib/samba/sbin cp *.pl *.pm mkntpwd/mkntpwd /var/lib/samba/sbin chmod 755 /var/lib/samba/sbin/smb*.pl chmod 644 /var/lib/samba/sbin/smb*.pm aus. Nun steht eine kleine Konfigurationsorgie der Datei smbldap conf.pm an. Diese im Lieblingseditor öffnen und los gehts: [... ] # Put your own SID # to obtain this number do: "net getlocalsid" $SID= S ; [... ] # LDAP Suffix # Ex: $suffix = "dc=idealx,dc=org"; $suffix = "dc=my-domain,dc=site"; [... ] # Where are stored Users # Ex: $usersdn = "ou=users,$suffix"; for ou=users,dc=idealx,dc=org $usersou = q(user); $usersdn = "ou=$usersou,$suffix"; # Where are stored Computers # Ex: $computersdn = "ou=computers,$suffix"; # for ou=computers,dc=idealx,dc=org $computersou = q(user); $computersdn = "ou=$computersou,$suffix"; # Where are stored Groups # Ex $groupsdn = "ou=groups,$suffix"; for ou=groups,dc=idealx,dc=org $groupsou = q(group); $groupsdn = "ou=$groupsou,$suffix"; [... ] # Bind DN used # Ex: $binddn = "cn=manager,$suffix"; for cn=manager,dc=idealx,dc=org $binddn = "cn=manager,$suffix"; # Bind DN passwd used # Ex: $bindpasswd = secret ; for secret $bindpasswd = "GeheiM"; [... ] # Login defs # Default Login Shell # Ex: $_userloginshell = q(/bin/bash); $_userloginshell = q(/bin/bash); # Home directory prefix (without username) # Ex: $_userhomeprefix = q(/home/);

208 198 KAPITEL 12. SAMBA $_userhomeprefix = q(/home/); [... ] $_usersmbhome = q(\\\\mysmbldap\\homes); [... ] $_userprofile = q(\\\\mysmbldap\\profiles\\); [... ] $_userhomedrive = q(h:); [... ] # Allows not to use smbpasswd (if $with_smbpasswd == 0 in # smbldap_conf.pm) but prefer mkntpwd... most of the time, it s # a wise choice :-) $with_smbpasswd = 0; $smbpasswd = "/usr/bin/smbpasswd"; $mk_ntpasswd = "/usr/sbin/mkntpwd"; Die Einträge für $usersou und $groupsou müssen natürlich mit den Definitionen in der smb.conf übereinstimmen. Man ist jedoch nicht auf user und group festgelegt und können geändert werden. Ähnliches gilt für den NetBIOS-Namen des Samba-Servers und den Buchstaben für das Home-Laufwerk. Für die meisten der derzeit aktuelle Samba-Versionen und Idealx-Skripten müssen Computer und Benutzer unterhalb eines gemeinsamen LDAP-Knotens angelegt sein. In diesem Beispiel wurden die Computer in user aufgenommen. Bei unterschiedlich gewählten Ablagen schlägt ein Domänenbeitritt fehl, da eine Maschine zwar sauber in den LDAP eingetragen, danach aber nicht wiedergefunden wird. Dieses Problem scheint mit den neuesten Samba-Versionen und Idealx-Skripten 2 behoben. Ebenfalls entfallen die Ergänzungen der Objektklassen. Dafür muss dann jedoch die LDAP Schema-Datei von Idealx und nicht die von Samba eingesetzt werden, da sonst einige Objekte nicht korrekt initialisiert werden. Am Ende der Datei muss der Pfad zu mkntpwd stimmen. Befinden sich LDAP- und Samba-Server nicht auf einer Maschine sind für den Netzwerkzugriff des Samba auf LDAP natürlich noch IP und Port oben in der Datei anzugleichen. Generell fügt das Skript umfangreichere Informationen ein, als für ein reines Samba-Backend benötigt würden. Zusätzlich sind auch alle Informationen für Unix-Benutzer enthalten. Leider sind die Skripten je nach eingesetzter Linux-Distribution nicht ganz passend zu einigen neueren LDAP-Versionen, so dass bei smbldap-populate.pl folgende oder ähnliche Fehlermeldung mehrfach auftreten kann: failed to add entry: no structural object class provided at./smbldap-populate2.pl line 323, <GEN1> line 8. Diese läßt sich in den Griff bekommen durch das Einfügen zweier struktureller LDAP- Objektklassen in die Datei smbldap-populate.pl Zeilen 323 und folgende: dn: cn=domain Admins,$groupsdn objectclass: posixgroup +objectclass: top +objectclass: namedobject objectclass: sambagroupmapping gidnumber: 512 cn: Domain Admins Das Ergebnis sieht dann so aus: linux2:/var/lib/samba/sbin #./smbldap-populate.pl Using builtin directory structure Version 0.8.5, die funktioniert nicht korrekt

209 12.7. SAMBA UND LDAP 199 adding new entry: dc=my-domain,dc=site adding new entry: ou=user,dc=my-domain,dc=site adding new entry: ou=group,dc=my-domain,dc=site adding new entry: ou=computer,dc=my-domain,dc=site adding new entry: uid=administrator,ou=user,dc=my-domain,dc=site adding new entry: uid=nobody,ou=user,dc=my-domain,dc=site adding new entry: cn=domain Admins,ou=group,dc=my-domain,dc=site adding new entry: cn=domain Users,ou=group,dc=my-domain,dc=site adding new entry: cn=domain Guests,ou=group,dc=my-domain,dc=site adding new entry: cn=administrators,ou=group,dc=my-domain,dc=site adding new entry: cn=users,ou=group,dc=my-domain,dc=site adding new entry: cn=guests,ou=group,dc=my-domain,dc=site adding new entry: cn=power Users,ou=group,dc=my-domain,dc=site adding new entry: cn=account Operators,ou=group,dc=my-domain,dc=site adding new entry: cn=server Operators,ou=group,dc=my-domain,dc=site adding new entry: cn=print Operators,ou=group,dc=my-domain,dc=site adding new entry: cn=backup Operators,ou=group,dc=my-domain,dc=site adding new entry: cn=replicator,ou=group,dc=my-domain,dc=site adding new entry: cn=domain Computers,ou=group,dc=my-domain,dc=site Nach erfolgreichem Durlauf von smbldap-populate.pl muss der LDAP-Server neu gestartet werden: rcldap restart. Als nächstes benötigt der LDAP-Server ein Container-Objekt für IDMAP-Informationen. Dieser ist überlicherweise nicht vorhanden und muss per Hand erzeugt werden. Dazu legen Sie eine Datei idmap.ldif mit folgendem Inhalt an: dn: ou=idmap,dc=my-domain,dc=site objectclass: top objectclass: organizationalunit ou: Idmap Diese Datei liegt im sogenannten LDIF vor - ein Austauschformat zwischen LDAP-Datenbanken. Mit dem Kommando ldapadd -x -D "cn=manager,dc=my-domain,dc=site"-w GeheiM -f idmap.ldif fügt man den Eintrag der LDAP-Datenbasis hinzu. Zur Kontrolle ob der LDAP-Server korrekt läuft und auf Requests antwortet, kann das Kommandozeilentool ldapsearch verwendet werden. Es funktioniert analog zu ldapadd zum Auslesen der Datenbank. linux2:/var/lib/samba/sbin # ldapsearch -x -b "dc=my-domain,dc=site" # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=site> with scope sub # filter: (objectclass=*) # requesting: ALL # # my-domain.site dn: dc=my-domain,dc=site objectclass: dcobject objectclass: organization dc: my-domain o: my-domain [... ] # Idmap, my-domain.site

210 200 KAPITEL 12. SAMBA dn: ou=idmap,dc=my-domain,dc=site objectclass: top objectclass: organizationalunit ou: Idmap # search result search: 2 result: 0 Success # numresponses: 21 # numentries: 20 Es sollte eine ziemlich lange Liste liefern. Dann wird es Zeit sich um den Name Service Switch zu kümmern, so dass dieser auch LDAP-Benutzer auflösen kann. Andernfalls kann Ihr System Samba-Usern keine System-User zuordnen. /etc/nsswitch.conf passwd: compat group: compat passwd_compat: ldap group_compat: ldap [... ] # oder alternativ passwd: files ldap group: files ldap Die Einstellungen in dieser Datei als auch die LDAP-Client-Konfiguration kann ebenfalls mit YaST2 vorgenommen werden (Abb. yast2-ldap-client Erreichbar in YaST2 über Netzwerkdienste LDAP-Client). # /etc/ldap.conf host 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:

211 12.7. SAMBA UND LDAP 201 Administrators:x:544: [... ] Nun wäre es nur noch ein kleiner Schritt auch den Zugriff auf die Linuxmaschine mittels PAM-LDAP einzurichten. Dieses würde aber den Rahmen des hier Beschriebenen sprengen. Auf diesem Wege können Administratoren jedoch ein single-password realisieren. Bisher waren nur Systembenutzer automatisch angelegt worden. Mit den entsprechenden Tools können nun weitere hingezufügt werden: linux2:/var/lib/samba/sbin #./smbldap-useradd.pl -m -a test1 linux2:/var/lib/samba/sbin #./smbldap-passwd.pl test1 Changing password for test1 New password : Retype new password : linux2:/var/lib/samba/sbin #./smbldap-usermod.pl -u 0 Administrator linux2:/var/lib/samba/sbin #./smbldap-passwd.pl Administrator Changing password for test1 New password : Retype new password : Der Administrator hat vorerst noch eine UID ungleich null. Das ändert man mit smbldapusermod.pl wie im Beispiel gezeigt. Für ihn brauchen Sie auch noch ein Passwort für den späteren Domänenbeitritt. Mittels - der im smb.conf Beispiel auskommentierten - username map kann der Administrator auch auf den Unix-Admin root abgebildet werden. Diese Nutzer stehen sofort auch unter Linux zur Verfügung, wie getent passwd oder id test1 3 zeigen. Dass der User auch für die Windowswelt sichtbar wird, zeigt: linux2:/var/lib/samba/sbin # pdbedit -Lv test1 Searching for:[(&(objectclass=sambadomain)(sambadomainname=smb-ldap))] smbldap_open_connection: connection opened Searching for:[(&(objectclass=sambadomain)(sambadomainname=smb-ldap))] smbldap_open_connection: connection opened init_sam_from_ldap: Entry found for user: test1 Unix username: test1 NT username: test1 Account Flags: [U ] User SID: S Primary Group SID: S 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 :45:51 GMT Kickoff time: Fri, 13 Dec :45:51 GMT 3 siehe hierzu auch den Teil zur Benutzerverwaltung mit LDAP

212 202 KAPITEL 12. SAMBA Password last set: Tue, 23 Nov :49:59 GMT Password can change: 0 Password must change: Fri, 07 Jan :49:59 GMT Last bad password : 0 Bad password count : 0 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Nun könnte der Admin noch eine Gruppe testgroup wie im einführenden Beispiel des letzten Abschnitts anlegen: smbldap-groupadd.pl -a testgroup. Hatte man schon das Problem, dass smbldap-polulate.pl gepatcht werden musste, bleibt es einem für smbldap tools.pm nicht erspart: Ab Zeile 283 müssen zwei Zuweisungen hinzugefügt werden: objectclass => top, objectclass => namedobject, die die Objektklasse posixgroup ergänzen. Treten weitere Probleme mit einem der anderen Tools auf, liegt es häufig an den Einstellungen zu den LDAP-Objekten. Ein letzter Test überprüft die korrekte Zuweisung der Gruppen: net groupmap list. Damit sollte nun das Setup abgeschlossen und ein PDC mit verändertem Backend aufgesetzt worden sein. Nun können Sie die Schritte wie im Abschnitt Samba als PDC beschrieben wiederholen. Die Domäne heisst nun etwas anders, um den Unterschied herauszustellen. Für den Windows-Client ändert sich nicht viel (Abb. smbldap-domain Einfügen einer Windows-XP Maschine in eine Domäne mit Samba/LDAP-Backend und Anmeldung an der neuen Domäne Abb. xp-sambatestnetz) Fazit von Samba-LDAP-Aktionen Der Aufwand für eine solche Aktion ist deutlich höher als ohne Verwendung von LDAP, da eine ganze Reihe von Schritten durchzuführen sind. Wegen der höheren Komplexität schleichen sich schneller Fehler ein. Ein Admin braucht schon eine Menge Geduld, um eventuell nicht passende Skripten anzupassen oder Software-Bugs zu umschiffen. Nicht jede Kombination von Samba und LDAP-Skripten funktioniert. Bei vermutlich jeder Distribution ist mit händischer Nach- und Anpassungsarbeit zu rechnen. Belohnt wird der Administrator am Ende jedoch von einer komfortablen Lösung zum bequemen Management einer Windows- Domäne ohne hierfür teure Microsoft-Server-Lizenzen beschaffen zu müssen. Fast nebenbei fällt ein elegantes single-password für Windows- und Linuxmaschinen ab. Zusätzlich kann LDAP dazu benutzt werden zentrale Adressbücher bereitzustellen oder eine generelle Verwaltung bestimmter IT-Ressourcen zu realisieren.

213 Kapitel 13 Ressourcenverwaltung 13.1 Einleitung In sehr grossen Netzen mit vielen gleichartigen Maschinen und vielen Benutzern, die sich an fast allen Maschinen anmelden können, ist die klassische dezentrale Verwaltung von Benutzern und Resourcen nicht mehr leistbar NIS Zielsetzung Wenn ein lokales Netzwerk betrieben wird, besteht ein Ziel üblicherweise darin, allen Benutzern eine Umgebung zur Verfügung zu stellen, die überall gleich konfiguriert ist. Die Benutzer sollen ein einheitliches Homeverzeichnis vorfinden und überall den gleichen Account verwenden, für den das gleiche Passwort gültig ist. Hierzu sind die lebenswichtigen Daten wie Account-Informationen zwischen allen Hosts zu synchronisieren. Darüberhinaus lassen sich auch weitere Dateien synchronisieren, wie die /etc/hosts, /etc/services, /etc/groups... Deshalb entwickelte Sun vor einiger Zeit NIS, das Network Information System. NIS bietet einfache Datenbank-Zugriffseinrichtungen, die verwendet werden können, um Informationen, wie sie in den Dateien passwd und groups enthalten sind, an alle Hosts im Netzwerk zu verteilen. NIS basiert auf RPC (Remote Procedure Call und besteht aus einem Server, einer Bibliothek für die Client-Seite und verschiedenen administrativen Tools. Bekannt wurde NIS unter dem Namen Yellow Pages ( Gelbe Seiten ), kurz YP, der heute immer noch häufig verwendet wird. Andererseits ist Yellow Pages ein eingetragenes Warenzeichen, so daß Sun den Namen fallen ließ. Da der Begriff aber gut merkbar war, bleiben manche Namen einfach hängen, und so lebt YP als Präfix für die Namen der meisten NIS-Befehle wie ypserv, ypbind, ypset etc. weiter NIS-Datenbanken NIS hält seine Datenbank-Informationen in sogenannten Maps (etwa: Zuordnungen), die Key/Value-Paare in Hashtables speichern. Die Maps werden auf einem zentralen Host vorgehalten, auf dem der NIS-Server läuft. Clients können die Informationen dann von diesem Server über verschiedene RPC-Calls abrufen. Die Maps selbst werden normalerweise aus Master-Textdateien wie /etc/hosts oder /etc/passwd generiert. Aus manchen Dateien werden mehrere Maps generiert, jeweils eine pro Suchschlüssel. Zum Beispiel können Sie die Datei hosts nach einem Hostnamen ebenso 203

214 204 KAPITEL 13. RESSOURCENVERWALTUNG wie nach einer IP-Adresse durchsuchen. Entsprechend werden zwei NIS-Maps daraus erzeugt: hosts.byname und hosts.byaddr. Im folgenden wird eine Aufstellung der gängigen Maps sowie der Dateien, aus denen sie generiert werden, gezeigt: Master-Datei /etc/hosts /etc/networks /etc/passwd /etc/group /etc/services /etc/rpc /etc/protocols /etc/aliases Mapfile(s) hosts.byname, hosts.byaddr networks.byname, networks.byaddr passwd.byname, passwd.byuid group.byname, group.bygid services.byname, services.bynumber rpc.byname, rpc.bynumber protocols.byname, protocols.bynumber mail.aliases Tabelle 13.1: NIS-Maps NIS-Server NIS-Client Die Konfigurationsdatei für NIS ist yp.conf. # Syntax: # ypserver <Name_of_ypserver> ypserver 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 Hierarchische Datenbank: LDAP Intro In verteilten Umgebungen werden Informationen über Personen, Anwendungen, Dateien, Drucker und andere, über das Netz zugängliche Ressourcen oft in einer speziellen Datenbank, einem sogenannten Directory gespeichert. Ein Directory Service ist ein Name Service, der neben der Zuordnung Name-Objekt auch Metadaten enthält. LDAP ist ein Kommunikationsprotokoll, das den Zugriff auf und die Aktualisierung von Directory Informationen regelt. Es ist ein offener Industriestandard und eine vereinfachte Alternative zum X.500 Standard. Die Netzwerkkommunikation wird mittels TCP/IP standardmäßig auf Port 389 abgewickelt. Es kann Bestandteil von Browsern, wie z.b. Netscape sein. Ursprünglich wurde die Entwicklung von Netscape vorangetrieben, um den eigenen Kunden ein übergreifendes Directory für Mail- und Webanwendungen anbieten zu können. Das Protokoll arbeitet im klassischen Client-Server-Modell und verwendet Strings zur Datendarstellung. X.500 wurde 1988 von der CCITT spezifiziert als eine Menge offener Systeme, die gemeinsam eine Datenbank halten, in der Informationen über Objekte der realen Welt abgelegt sind. Die CCITT spezifiziert im wesentlichen drei Protokolle: DAP (Directory Access Protocol), das zum Zugriff auf die Informationen dient, DSP (Directory Service Protocol), mit dem die Kommunikation zwischen Servern durchgeführt wird, und DISP

215 13.3. HIERARCHISCHE DATENBANK: LDAP 205 (Directory Information Shadowing Protocol). Allerdings setzt X.500 auf einem vollständigen ISO/OSI-Stack auf, was einen durchschlagenden Erfolg unmöglich machte. X.500 kann als vollständig bezeichnet werden: Nichts, was nicht in ihm gespeichert werden könnte. Das Verzeichnis stellt eine Objektdatenbank dar. Zu speichernde Informationen werden in Objektklassen beschrieben: Attributnamen, Typen und deren Wertebereich. Wesentliche Nachteile sind der hohe Implementationsaufwand und der schwergewichtige Zugriff: die Kommunikation zwischen Client und Server erzeugt eine recht hohe Netzlast, die einer allgegenwärtigen Nutzung hinderlich ist - denn schließlich spielt ein Verzeichnisdienst erst mit der allgemeinen Verwendung seine Stärken aus. LDAP schlägt eine Brücke Was kann mit LDAP abgebildet werden LDAP speichert seine Informationen in einer Baumhierarchie. Diese Hierarchie kann diverse Informationen enthalten. Einen Überblick verschafft RFC 2307, in dem mögliche Inhalte der LDAP Hierarchie spezifiziert sind: Benutzer Gruppen IP-Dienste IP-Protokolle RPC s NIS-Netzwerkgruppen Boot-Informationen Einhängepunkte für Dateisysteme IP-Hosts und Netzwerke RFC 822 konforme Mail-Aliase Hat man Daten in Datenbanken, so ist es wichtig, diese Informationen zu strukturieren. Besonders, wenn viele verschiedene Clients auf die Datenbank zugreifen wollen, zum Beispiel Netscape, Outlook und andere, muss die Struktur genau definiert sein. Wenn ein Mailclient eine -adresse braucht, muss er wissen, wie er diese bekommt. Eine zentrale Benutzerverwaltung setzt das Vorhandensein einer geeigneten Authentifizierungsinfrastruktur auf jeder Maschine voraus. Hierfür wurde ursprünglich von SUN vor inzwischen knapp 15 Jahren das Network Information System (NIS) entwickelt, welches lange Zeit den Standard einer verteilten Benutzerauthentifizierung und -verwaltung im Unix-Umfeld darstellte. Dieses wird in einem eigenen Abschnitt kurz erklärt. Mit den heute üblichen heterogenen Umgebungen, deren vielfältigen Authentifizierungsanforderungen (z.b. die Anmeldung an einem Radius-Server für Modem- oder ISDN-Einwahl) und den gestiegenen Sicherheitsforderungen konnte NIS nicht mehr mithalten. Neben den inzwischen recht umfänglichen Daten, die die Verwaltung eines Benutzers erfodert, kommen weitere Wünsche nach einer zentralisierten Organisation von Rechner-Pools hinzu. Diese Daten sollen meist ebenfalls geeignet abgelegt und komfortabel zugänglich gemacht werden. Solche Aufgaben übernehmen ab einem bestimmten Umfang der Anforderungen Datenbanken.

216 206 KAPITEL 13. RESSOURCENVERWALTUNG Das Datenmodell Bevor eine Datenbank mit Inhalten bestückt wird, sollte sich der Administrator mit ihrer Funktionsweise grob vertraut machen. Das betrifft den Aufbau und die Ablage der Daten sowie das zugrundeliegende Kommunikationsmodell. Es gibt immer eine einzige Wurzel root eines Directories. Diese kann später weder verschoben noch verändert werden. Unterhalb von Root kann entweder ein Country-Objekt c oder oder eine Organisation o angelegt werden. Ein Country-Objekt muss nicht, darf aber nur einmal existieren. Unterhalb von Country oder Root muss ein Organisationsobjekt o stehen. Davon kann es mehrere geben. Unterhalb von o folgen Blattobjekte, die Einträge oder Organisationsuntereinheiten ou. Einzelne Einträge werden vielfach durch ihren Common Name cn bezeichnet. Alternativ zur beschriebenen Hierarchie hat sich die Bezeichnung durch Domain Components durchgesetzt. Die Wurzel wird beginnend mit der Toplovel-Domain des Domain Name Service bezeichnet, in den darunterliegenden Hierachien folgen Second-Level-Domain und vergleichbar mit den Organizational Units Sublevel-Domain-Namen. Jedes Objekt im Verzeichnis muss einen eindeutigen Namen, den Distinguished Name dn haben. Der dn setzt sich aus den dn von der Wurzel aus zusammen, häufig wird der Common Name zur Benennung verwendet. Einträge in einem Objekt werden als Attribute bezeichnet. Ein Attribut ist der bereits angesprochene Common Name. Für eine einfache Benutzerverwaltung benötigt ein Linux-Sytem, wenn der Common Name den Realnamen einer Person oder Dienstes bezeichnet, noch einen eindeutigen String, welcher die User-ID bezeichnet, eine eindeutige Benutzer- und Gruppennummer, ein Homeverzeichnis, eine Loginshell und eventuell ein Passwort. Zusätzliche Daten, wie Telefonnummer, adresse, persönliche Webseite, Büro und weiteres können gespeichert werden, wenn aus der Datenbank auch die Adressbücher der Mitarbeiter gefüttert werden sollen. Ist der übergeordnete Container für das jeweilige Objekt bereits bestimmt, genügt zur Angabe auch ein Relative Distinguished Name rdn. Der Distinguished Name kann mit dem Primärschlüssel einer relationalen Datenbank verglichen werden. Jeder Directory-Eintrag beschreibt ein Objekt, welches eine Person, eine Verwaltungseinheite oder auch ein Server, Drucker usw. sein kann. Jeder Eintrag hat einen ausgezeichneten bzw. herausgestellten Namen, den distinguished name abgekürzt dn. Ein Eintrag kann eine Reihe weiterer Attribute besitzen, die einen Typ und einen bzw. mehrere Werte haben. Syntax bin ces cis tel dn Bedeutung Daten im Binärformat, Bilder, Ausführbare Dateien CaseSensitive, Textfelder CaseInSensitive, Textfelder Telefonnummer Distinguished Name Tabelle 13.2: Attribute im LDAP Auf Basis dieser Attribute sind allgemeine Eintragsschemata definierbar. Hierbei implementiert LDAP folgendes Namensmodell: Jeder ausgezeichnete Name (dn) besteht aus einer Sequenz von Teilen, die als relativ ausgezeichnete Namen bezeichnet werden. Alle Einträge sind hierarchisch eingeordnet. Ein Beispiel eines dn: cn=sandra Buchfing, ou=informatik,o=universität Freiburg,c=DE. Diese Informationen bzw. Teilbäume können dann über mehrere Server verteilt sein. Es gibt viele Definitionen, an die man sich halten muss, soll am Ende auch etwas funktionieren. Bei LDAP werden Objekte mit Eigenschaften verwendet. Jedes Objekt hat zunächst

217 13.3. HIERARCHISCHE DATENBANK: LDAP 207 Attribute Alias Syntax Beschreibung Beispiel CommonName cn cis Name eines Eintrages Sandra Buchfink surname sn cis Nachname einer Buchfink Person TelephoneNumber tel Telefonnummer organizationalunit ou cis Name einer Abteilung Informatik Organization o cis Name der Organisation Universität Freiburg Country c cis Name des Landes Deutschland, DE Owner dn Ausgezeichneter cn=sandra Buchfink, Name des Eintragbesitzers o=universität Freiburg,c=DE Tabelle 13.3: Beispiel einen eindeutigen Namen, an dem es von allen anderen unterschieden werden kann ( distinguished name, kurz: DN). Die Eigenschaften eines Objekts hängen davon ab, zu welcher Klasse es gehört (es kann sogar zu mehreren Klassen gehören). Klassen von Objekten Es sind nun Klassen für Personen definiert. Zu einer Person ( person ) gehören zwingend objectclass (die Objektklasse selbst), sn (der Nachname) und cn (commonname, etwa: üblicher Name, hier wird üblicherweise Vor- und Nachname verwendet). Zusätzlich gibt es optionale Attribute, die nicht unbedingt angegeben werden müssen. Diese sind hier description (beliebige Beschreibung), seealso (verweist auf ein anderes Objekt), telephonenumber (Telefonnummer), userpassword (ein Password). Da häufig noch mehr Attribute mit einer Person verknüpft sind, gibt es auch eine Objektklasse organizationalperson. Diese hat die gleichen geforderten Eigenschaften wie Person, aber erlaubt viele optionale Eigenschaften, wie zum Beispiel Felder der Adresse und eine FAX-Nummer. Es gibt noch mehr Klassen, zum Beispiel newpilotperson (die als optionale Eigenschaft eine -adresse mail einführt) und natürlich Klassen für Organisationen/Firmen, Abteilungen, Bilder, Dokumente, Geräte und so weiter. Eigenschaften von Klassen Wenn man also irgendwo eine Person im Verzeichnis hat, ist klar, dass diese ein cn haben muss, und eine Telefonnummer haben kann (und dass diese genau telephonenumber heißt). Soll ein Programm eine -addresse suchen, muss es nur nachschauen, ob es ein Attribut mail gibt. Es kann eben nicht sein, dass diese Eigenschaft oder anders heißt. mail ist vorgeschrieben, und nichts anderes. An diesem Beispiel kann man zeigen, dass eine natürliche Person zu mehreren Klassen gehört: person, organizationalperson und newpilotperson. Eine weitere Klasse ist top. Im Prinzip gehört so ziemlich jedes Objekt auch zur Klasse top, die lediglich vorschreibt, dass die Eigenschaft objectclass gesetzt sein muss (was bei allen Personenklassen ohnehin gefordert ist). Durch das Verwenden der Klassen definiert man, welche Eigenschaften vorhanden sein müssen, und welche vorhanden sein können. Eine Person darf zum Beispiel keine Farbtiefe haben, ein Bild hingegen schon. Verwendet man mehrere Klassen, so muss das entsprechende Objekt alle von mindestens einer Klasse geforderten Eigenschaften haben, und kann alle insgesamt erlaubten Eigenschaften haben.

218 208 KAPITEL 13. RESSOURCENVERWALTUNG Typen von Eigenschaften Den Eigenschaften sind Typen zugeordnet. Es gibt Typen, die eine Zeichenkette enthalten, und andere, die eine Telefonnummer enthalten. Diese Typen definieren weiterhin, wie Werte verglichen (und damit sortiert und gesucht) werden. Zeichenketten beispielsweise kann man abhängig von Groß- und Kleinschreibung vergleichen oder auch nicht. Bei Telefonnummer spielen gewisse Füllzeichen möglicherweise keine Rolle. Passwörter hingegen müssen genau übereinstimmen. Es gibt nun also Objekte (die zu bestimmten Klassen gehören). Diese werden nun anderen Objekten untergeordnet (beziehungsweise werden anderen Objekte viele zugeordnet, dies ist die richtige Reihenfolge). Diese baumartige Struktur kann man (mit etwas Phantasie) auch in der Realität finden: In Ländern gibt es Firmen, in Firmen gibt es Abteilungen und in Abteilungen letztlich Personen. So wird das in LDAP auch gesehen. Die Baumstruktur wird hier Directory Information Tree genannt, kurz DIT. Es gibt Länder (also Objekte der Klasse country [Land]) mit u.a. der Eigenschaft c (kurz für country), Firmen (organisations mit der Eigenschaft o), Abteilungen (Organisations Einheit, organisationalunit mit der Eigenschaft ou). Hierbei enthalten diese Objekte normalerweise viele weitere Eigenschaften; eine Firma hat zum Beispiel eine Postanschrift. Schema Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu gehören die Beschreibungen vieler Klassen und der verwendeten Typen. Es gibt verschiedene Schemata, und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) was jedoch nicht interoperabel mit anderen Diensten sein muss. Das liegt außerhalb der Betrachtungen dieses Textes. Der LDAP-Server speichert seine Informationen in einer baumartigen Struktur. Diese wird auch Directory Information Tree genannt, kurz DIT. Root dn: dc=local dn: dc=wg,dc=local rdn: ou=user rdn: ou=group rdn: ou=devices dn: uid=test01,ou=user,dc=wg,dc=local (rdn: uid=test01) dn: uid=test02,ou=user,dc=wg,dc=local (rdn: uid=test02) dn: uid=... Abbildung 13.1: Aufbau der LDAP-Datenstruktur für die Beispielkonfiguration Zum Speichern benutzt der LDAP-Server Objekte, die er mit Attributen versehen kann. Dadurch kann man die Struktur flexibel an die eigenen Bedürfnisse anpassen. Das RFC 2256 spezifiziert die Standard-Objekte des LDAP-Servers. Man wird zwar von niemandem gezwungen, diese Vorgaben auch zu benutzen. Um aber eine möglichst große Konformität zu erzielen, sollte man diese Vorgaben einhalten.

219 13.4. LDAP PRAKTISCH Das Protokoll LDAP ist ein Kommunikationsprotokoll, das den Zugriff auf und die Aktualisierung von Directory Informationen regelt. Es ist ein offener Industriestandard und eine vereinfachte Alternative zum X.500 Standard. Die Netzwerkkommunikation wird mittels TCP/IP standardmäßig auf Port 389 abgewickelt. Es kann Bestandteil von Browsern, wie z.b. Netscape sein. Ursprünglich wurde die Entwicklung von Netscape vorangetrieben, um den eigenen Kunden ein übergreifendes Directory für Mail- und Webanwendungen anbieten zu können. Das Protokoll arbeitet im klassischen Client-Server-Modell und verwendet Strings zur Datendarstellung. Das Protokoll definiert insgesamt neun Operationen: 1. bind - Verbinden mit einem LDAP-Server 2. authenticate - Anmeldung mit einer bestimmten ID, sonst erfolgt eine anonyme Bindung (welche üblicherweise den niedrigsten Privilegienlevel hat) 3. unbind - Verbindung mit dem Server geregelt beenden 4. abandon - Verbindung mit dem Server (ungeregelt) abbrechen 5. add - Hinzufügen von Objekten und Attributen 6. search - Suchen 7. modify - Ändern von Objekten und Attributen 8. compare - Vergleich 9. delete - Löschen von Objekten oder Attributen Die ersten vier Operationen dienen zum Verbinden, Abmelden und wechseln des Benutzerlevels. Mit verschiedenen Benutzerleveln sind üblicherweise verschiedene Zugriffsrechte verknüpft. Der Datenbank-Administrator, der mit rootdn in der Konfigurationsdatei angegeben wird, hat immer alle Rechte. LDAP erlaubt die Vergabe von Zugriffsrechten auf bestimmte Einträge und Attribute seiner Datenbasis. None erteilt keine Rechte, compare erlaubt Vergleiche. Es liefert wahr oder falsch für den Passwort-Check zurück, so muss das Passwort zum Vergleich die Datenbank nie verlassen. search gestattet das Suchen. read für Lesen ist die Kombination von compare und search, write erlaubt das Schreiben und delete das Löschen von Attributen und Einträgen LDAP praktisch Server- und Clientprogramme unter Linux Es existieren eine ganze Reihe von verfügbaren Produkten, die hierarchische Verzeichnisdienste nach dem LDAP-Standard definieren. Wie bei fast allen offenen Standards existiert mit dem OpenLDAP eine freie Implementierung, welche unter der GPL zur Verfügung steht. Der Daemon unter Linux heisst slapd und findet sich je nach Distribution unterhalb des Diensteverzeichnisses /usr/sbin. Die zentrale Konfigurationsdatei des LDAP-Servers slapd.conf befindet sich üblicherweise unterhalb von /etc/openldap. Die Datenbankdateien

220 210 KAPITEL 13. RESSOURCENVERWALTUNG landen üblicherweise unterhalb von /var/lib/ldap. Dieses Verzeichnis wird in der slapd.conf spezifiziert und kann dort entsprechend geändert werden. Mit dem LDAP-Paket werden eine Reihe von Userspace-Utilities mitinstalliert. Die beiden Programme slapadd und slapcat eignen sich für direkte Transformation des LDIF- Formats in das Datenbankformat und umgekehrt. Dazu wird kein laufender Server benötigt. Für Operationen auf der LDAP-Datenbank finden sich die Werkzeuge ldapsearch, ldapadd, ldapdelete und ldapmodify. Diese implementieren die im Abschnitt zum Protokoll genannten Operationen Eine einfache Beispielkonfiguration Damit ein erster kleiner Eindruck gewonnen werden kann wie LDAP funktioniert, folgt ein einfaches Beispiel für eine kleine Benutzerverwaltung. Dazu wird ein LDAP-Server auf der Maschine eingerichtet, auf der sich die beiden Benutzer test01 und test02 anmelden sollen. Dieses Setup erfordert keine verschlüsselten Verbindungen, da die gesamte Kommunikation über das Loopback-Interface 1 abgewickelt wird. Die Serverkonfigurationsdatei /etc/openldap/slapd.conf könnte wie folgt aussehen: # LDAP Server Konfigurationsdatei: /etc/openldap/slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema pidfile argsfile /var/run/slapd/slapd.pid /var/run/slapd/slapd.args access to attr=userpassword by anonymous auth by self write access to attr=objectclass,entry,mail,cn,sn,loginshell,userpassword by self write by * read access to attr=objectclass,entry,uid,mail,cn,sn,uidnumber,gidnumber,\ homedirectory,loginshell by * read access to * by users read by anonymous auth database ldbm directory /var/lib/ldap suffix "dc=wg,dc=local" rootdn "cn=manager,dc=wg,dc=local" rootpw nicht-weitersagen Nachdem die Konfigurationsdatei angelegt, die Existenz des Datenverzeichnisses und dessen Rechte überrüft wurden, kann der Dienst einfach einmal gestartet werden: 1 Interfacename: lo, IP-Adresse:

221 13.4. LDAP PRAKTISCH 211 /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -h ldap:// :389 -u ldap -g ldap In der Log-Datei /var/log/message kann der Erfolg der Aktion überprüft werden. Hier landen Meldungen zu Fehlern in der Konfigurationsdatei. Die Datei für die Einrichtung der Clientkommandos und das PAM-Modul: /etc/openldap/ldap.conf sollte die folgenden Zeilen enthalten: # LDAP Client Konfigurationsdatei: /etc/openldap/ldap.conf BASE dc=wg,dc=local URI ldap:// :389 Nun verbindet sich das Suchkommando ldapsearch -x schon mit der Datenbank. Es liefert jedoch noch keine Daten zurück, solange die Datenbank noch nicht gefüllt wurde. Am schnellsten geht die Bestückung der Datenbank durch das Anlegen einer Datei im LDAP- Austauschformat LDIF (Lightwight Directory Interchange Format). Die Objekte werden von der Wurzel aus folgend definiert und eingetragen: # LDIF-Datei zur Definition von zwei Beispielnutzern: user.ldif dn: dc=wg, dc=local objectclass: organization o: wg dn: ou=user, dc=wg, dc=local ou: user objectclass: organizationalunit dn: ou=group, dc=wg, dc=local ou: group objectclass: organizationalunit dn: cn=user, ou=group, dc=wg, dc=local objectclass: posixgroup 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: shadowmax: shadowwarning: 7 uidnumber: 1001

222 212 KAPITEL 13. RESSOURCENVERWALTUNG gidnumber: 100 homedirectory: /home/test02 loginshell: /bin/ksh dn: uid=test02, ou=user, dc=wg, dc=local uid: test02 cn: Test-User Nr. 2 sn: Test-User 2 objectclass: person objectclass: posixaccount objectclass: shadowaccount objectclass: top userpassword: topsecret shadowlastchange: shadowmax: shadowwarning: 7 uidnumber: 1002 gidnumber: 100 homedirectory: /home/test02 loginshell: /bin/bash Die Übertragung des LDIFs in die laufende Datenbank geschieht mittels des Kommandos: ldapadd -c -x -D cn=manager,dc=wg,dc=local -W -f user.ldif. Hier findet man den Datenbank-Manager-Account wieder, der in der Serverkonfigurationsdatei angegeben wurde. Beim Aufruf des Kommandos folgt die Frage nach dem zugehörigen Passwort. Nun liefert ldapsearch -x bereits einiges mehr. Die Daten, die zu sehen sind, sind diejenigen, welche für den anonymen Zugriff freigeben sind. Soll der vollständige Datensatz angezeigt werden, gibt man die Datenbank-Manager-Credentials mit: ldapsearch -x - D cn=manager,dc=wg,dc=local -w nicht-weitersagen. Dabei fällt auf, dass die Ausgabe im bereits bekannten LDIF-Format erfolgt. Der nächste Schritt ist nun die Einrichtung der PAM-Authentifizierung gegen die frisch eingerichtete LDAP-Datenbank. Dazu wird als Beispiel das PAM-Modul für den SSH-Login angepasst: # /etc/pam.d/sshd auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix2.so use_first_pass # set_secrpc account required pam_unix2.so password required pam_pwcheck.so password required pam_ldap.so use_authtok password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so session required pam_limits.so session required pam_env.so session optional pam_mail.so Weiterhin muss nun noch dem Name Service Switch die alternative zu den klassischen Dateien passwd und shadow mitgeteilt werden: # /etc/nsswitch.conf

223 13.4. LDAP PRAKTISCH 213 [... ] passwd: files ldap group: files ldap [... ] Anschliessend benötigt der Name Service Caching Daemon (nscd) eventuell noch einen Neustart und ein einfacher Test mit einem SSH-Login-Versuch kann erfolgen. Dieses sollte nun funktionieren, jedoch steht noch kein Homeverzeichnis zur Verfügung. Die Liste der mittels LDAP zur Verfügung gestellten Benutzerkennungen kann mittels getent angezeigt werden. Diese Einträge erscheinen nach den Daten aus der /etc/passwd Absicherung durch SSL Wenn die Datenkommunikation über das Loopback-Interface direkt auf der Maschine stattfindet, ist die Sicherheit der übertragenen Daten ausreichend gewährleistet. Anders sieht es aus, wenn LDAP-Pakete über ein Ethernet gehen. Deshalb kann eine LDAP-Verbindung analog zu einer HTTP-Verbindung den Secure-Socket-Layer (SSL) verwenden. Wegen der notwendigen Zertifikats- und Schlüsselerstellung bzw. -verwaltung gestaltet sich dieses etwas aufwändiger. Der schnellste Weg ginge über die Generierung eines selbstunterschriebenen Serverzertifikats. Da jedoch eine Reihe von Fehlern auftreten können und LDAP selbstunterschriebene Zertifikate bemängelt, wird von diesem Weg abgeraten. Besitzt man bereits ein von einer Certificate Authority (CA) unterschriebenes Serverzertifikat, kann man den nächsten Schritt überspringen. Da diese Zertifikate Geld kosten und in regelmäßigen Abständen verlängert werden müssen, besitzen meistens nur Betreiber großer Webserver solche. Das OpenSSL-Paket liefert die Lösung für dieses Problem mit - ein Shell-Skript führt durch die Einrichtung einer eigenen CA. Dazu wird ein eigenes Verzeichnis angelegt, z.b. /etc/localca. In diesem Verzeichnis startet der Aufruf von /usr/share/ssl/misc/ca.sh -newca (der angegebene absolute Pfad kann je nach Distribution variieren) die Einrichtung der CA: CA certificate filename (or enter to create) Making CA certificate... Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to./democa/private/./cakey.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank Country Name (2 letter code) [AU]:DE

224 214 KAPITEL 13. RESSOURCENVERWALTUNG State or Province Name (full name) [Some-State]:BaWue Locality Name (eg, city) []:Freiburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:WG Organizational Unit Name (eg, section) []:WG-LDAP Common Name (eg, YOUR name) []:wg.local Address []:. Für den Dateinamen kann mit Enter einfach ein Defaultwert übernommen werden, alle anderen Abfragen können wie oben gezeigt ausgefüllt und mit entsprechenden Werten übernommen werden. Das Passwort zur Absicherung der Schlüssel sollte sich für später gemerkt werden. Im definierten Verzeichnis finden sich unter democa/cacert.pem und democa/private/cakey.pem das Zertifikat unserer CA und der private Schlüssel. Im nächsten Schritt wird das Serverzertifikat generiert: openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to newreq.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:BaWue Locality Name (eg, city) []:Freiburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:WG Organizational Unit Name (eg, section) []:WG-LDAP Common Name (eg, YOUR name) []:wg.local Address []:. Please enter the following extra attributes to be sent with your certificate request A challenge password []:<passwort> An optional company name []:. Im großen und ganzen wiederholen sich die Abfragen der CA-Erstellung. Die zusätzlichen Attribute können leer gelassen werden. Dieses geschieht durch die Angabe eines Punktes.. Als Ergebnis existiert nun eine Datei newreq.pem im aktuellen Verzeichnis. Nun muss der neuerzeugte Schlüssel noch von unserer CA signiert werden. Hierzu kommt das bereits von der CA-Erstellung bekannte Skript zum Einsatz: /usr/share/ssl/misc/ca.sh -sign Using configuration from /etc/ssl/openssl.cnf Enter PEM pass phrase:<passwort der CA> Check that the request matches the signature

225 13.4. LDAP PRAKTISCH 215 Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE: DE stateorprovincename :PRINTABLE: BaWue localityname :PRINTABLE: Freiburg organizationname :PRINTABLE: WG organizationalunitname:printable: WG-LDAP commonname :PRINTABLE: wg.local Certificate is to be certified until Jun 16 09:07: 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: GMT Not After : Jun 16 09:07: 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: (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

226 216 KAPITEL 13. RESSOURCENVERWALTUNG DirName:/C=DE/ST=BaWue/L=Freiburg/O=WG/OU=WG-LDAP/CN=wg.\ local serial:00 Signature Algorithm: md5withrsaencryption 64:2f:46:48:e2:2b:e9:d4:99:47:5e:35:69:d2:1c:8f:33:c5: [... einige weitere Zeilen... ] 7c:9f:b2:ee:da:dc:26:fc:08:6f:2e:e6:07:4c:72:b0:88:89: d8:3a -----BEGIN CERTIFICATE----- MIIDJTCCAo6gAwIBAgIBATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJERTEO MAwGA1UECBMFQmFXdWUxETAPBgNVBAcTCEZyZWlidXJnMQswCQYDVQQKEwJXRzEQ [... etliche Zeilen... ] 1qZZj7c5u5UJHrngC/fRUr5nCgI0fJ+y7trcJvwIby7mB0xysIiJ2Do= -----END CERTIFICATE----- Signed certificate is in newcert.pem Damit liegt nun mit newcert.pem das Server Zertifikat unterschrieben von der eigenen CA mit dem privaten Schlüssel newreq.pem vor. Nun ist alles soweit vorbereitet und das Zertifikat kann in das entsprechende Verzeichnis für den Zugriff des LDAP-Servers verschoben werden. Dazu wird das Verzeichnis /etc/openldap/certificates erzeugt und die Zertifikate dort hineinkopiert oder -bewegt. cp democa/cacert.pem /etc/openldap/certificates/cacert.pem mv newcert.pem /etc/openldap/certificates/servercrt.pem mv newreq.pem /etc/openldap/certificates/serverkey.pem chmod 400 /etc/openldap/certificates/serverkey.pem chown -R ldap.ldap /etc/openldap/certificates Das letzte Kommando übergibt dem LDAP-Nutzer die Rechte für das Verzeichnis, da sonst der Serverschlüssel vom LDAP-Daemon nicht gelesen werden kann. In einem solchen Fall öffnet der Server keinen SSL-Port und hinterläßt eine Fehlermeldung in der Log-Datei. Nun müssen noch drei Zeilen am Anfang der Server-Konfigurationsdatei slapd.conf eingefügt werden: TLSCertificateFile /etc/openldap/certificates/servercrt.pem TLSCertificateKeyFile /etc/openldap/certificates/serverkey.pem TLSCACertificateFile /etc/openldap/certificates/cacert.pem Der Aufruf des LDAP-Daemon sieht nun etwas anders aus: /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -h ldaps:// :636 -u ldap -g ldap Zum einen wird mittels ldaps:// :636 das abgesicherte Protokoll gewählt und zum anderen kann nun der Server für die netzweite Benutzung zur Verfügung gestellt werden. Damit wie eingangs gezeigt die LDAP-Client-Programme wieder bequem funktionieren, wird eine Anpassung der ldap.conf erforderlich: BASE ou=user,dc=wg,dc=local URI ldaps:// :636 SASL_SECPROPS noactive TLS hard TLS_REQCERT allow

227 13.4. LDAP PRAKTISCH 217 Nun liefert der Aufruf der Kommandos ldapsearch -x oder getent passwd wieder die eingangs gezeigten Ausgaben. Dabei beschränkt sich dieses nicht mehr auf den Server selbst, sondern kann von jeder beliebigen Maschine im Netzwerk geschehen, wenn die Dateien ldap.conf und nsswitch.conf entsprechend eingerichtet wurden.

228 218 KAPITEL 13. RESSOURCENVERWALTUNG

229 Kapitel 14 Drucken im Netz 14.1 Einleitung Zum Drucken unter Unix gibt es verschiedene Ans atze: BSD-System System V CUPS Das BSD-System ist historisch gesehen das alteste und war lange bei SUN-Systemen im Einsatz. Das System V Drucksystem sollte mehr den Bed urfnisse grosser Unternehmen gerecht werden, ist aber sehr kompliziert. Cups (Common UNIX Printing System) versucht die beiden Ans atze zu verbinden und implementiert das Internet Printing Protocol, das als neuer Standard entwickelt wurde Anforderungen Folgende Anforderungen werden an ein Drucksystem gestellt? Zum einen sollten alle lokal anschließbaren Drucker funktionieren: USB Parallel Seriell Irda Bluetooth Zum anderen sollten alle Drucker im Netz verwendbar sein: Ethernet-Drucker Lokale Drucker an anderen LINUX/UNIX/MAC-Systemen Lokale Drucker an Windows-Systemen Desweitern sollte ein Drucker m oglichst viele Dateiformate annehmen und direkt verarbeiten k onnen. Hier besteht ein wesentlicher Unterschied zu MS-Windows-Systemen. Dort gibt es nur das Programm print im Kommandomodus, das direkt Textdateien ausdruckt. Das Kommando lpr unter Linux war urspr unglich auch nur f ur Textdateien ausgelegt, wurde aber durch Erweiterung um Filter flexibel. (s. Kap ) 219

230 220 KAPITEL 14. DRUCKEN IM NETZ Grundlagen Das Linuxdrucksystem basiert auf einem Filtermechanismus, an dessen Anfang das Dokument, am Ende das Device (z. B. /dev/lp0 = parallele Schnittstelle) steht. Das Druckkommando ist lpr (Line Printer). Mit lpr textdatei wird eine Textdatei auf den Standarddrucker gedruckt. Mit export PRINTER=color wird der Standarddrucker auf color gesetzt. Falls man einen anderen als den Standarddrucker verwenden möchte, kann kann man den gewünschten Drucker beim Aufruf mitangeben: lpr -Pdruckername textdatei Aber was genau passiert nach einem solchen Aufruf? Beim Aufruf von lpr werden die angegebenen Optionen interpretiert und angewendet. Anschliessend sorgt lpr dafür, dass die Datei in das Spoolverzeichnis des angegebenen Druckers geschickt wird. Der Spooler (früher lpd, heute meist LPRng nimmt den Druckauftrag entgegen und gibt einen Druckjob aus. In diesem Prozess werden die Ausgabeformate der jeweiligen Anwendung durch die Filter in ein Druckformat umgewandelt. Welches Druckformat der Drucker verwendet geht aus der PPD-Datei (PostScript Printer Description) hervor. Die PPD-Datei ist eine Textdatei, in der die anzuwendenden Filter gelistet sind. Die PPD-Dateien werden meist schon beim Installieren des Betriebssystems zur Verfügung gestellt. Auch CUPS stellt eine Reihe von PPD-Dateien zur Verfügung. Die Arbeit der Filter besteht darin, das Ausgabeformat automatisch zu erkennen und ein geeignetes Konvertierungsprogramm aufzurufen, um die Datei in PostScript umzuwandeln. Nachdem der Spooler den Druckauftrag entgegengenommen hat und die Filter die Datei in das Druckformat umgewandelt haben, befindet sich der Druckjob in der Warteschlage, der sogenannten Queue. Mit dem Befehl lpq kann man sich alle Druckjobs ausgeben lassen. Der Drucker bekommt die Druckjobs aus der Queue und druckt den PostScript-Code. Hierzu bedarf es eines Raster-Image-Prozessors (RIP), der für die Ausgabe des PostScript- Codes sorgt. Bei PostScript-fähigen Druckern ist der RIP im Drucker integriert, bei nicht- PostScript-kompatiblen Druckern wird ein Post-Script-Interpreter benötigt, der aus den PostScript-Informationen ein Datenformat erzeugt, das vom jeweiligen Drucker verstanden wird. Dieser Interpreter wird durch den druckerspezifischen Treiber zur Verfügung gestellt. Die Funktionsweise des Treibers geht aber natürlich über das Erzeugen des richtigen Datenformates weit hinaus. Aufgabe des Treibers ist es, die zu druckende Datei mit all den Informationen zu ergänzen, die für die optimale Nutzung der Hardware nötig sind. Diese Beschreibung der Funktionsweise des Drucksystems ist natürlich stark vereinfacht. Anhand der genaueren Betrachtung des CUPS (Common Unix Print System) werden die Zusammenhänge detailliert beschrieben werden. Unter den verschiedenen Systemen zur Konfiguration und Administration des Drucksystems unter Linux wird das CUPS am häufigsten verwendet. Es eignet sich sowohl für die Konfiguration von Einzelplatz Rechnern/Druckern, als auch für komplizierte Systeme im Netzwerk CUPS Im CUPS (Common Unix Printing System) übernimmt der cupsd die Aufgaben des lpd: Annehmen der Druckaufträge, ggf. Weiterleiten an die entsprechenden Filter, Einreihen in die Warteschlage und Aufruf des passenden Backends, das die fertigen Jobs in passender Form an den Drucker gibt. Der cupsd implementiert den neuen Standard IPP (Internet Printing Protocol) und stellt somit folgende zusätzliche Funktionalität zur Verfügung: Authentifizierung von Benutzern

231 14.2. CUPS 221 Verschlüsselung der Druckdaten bei der Übertragung Bekanntgabe verfügbarer Drucker im Netz IPP ist ein Protokoll der Anwendungsschicht und kann für verteiltes Drucken im Interund Intranet verwendet werden. Das Protokoll definiert die Interaktion zwischen CUPS- Server und -Client und ermöglicht dem Client Abfragen von Druckerinformationen Client-Server-Architektur Im CUPS ist jeder Rechner, an den ein Drucker angeschlossen ist, ein Server. Rechner, die entfernte Drucker nutzen wollen, sind Clients. Ein Standalone-Rechner, an dem ein Drucker angeschlossen ist, der mit CUPS verwaltet wird, ist sozusagen ein Client, der sein eigener Server ist. Jeder Server ist selbst für die Aufbereitung der Druckjobs zuständig, d.h. jeder Server muss sowohl die für das Druckformat des Druckers nötigen Filter, als auch den entsprechenden Treiber selber zur Verfügung stellen. Sämtliche gerätespezifischen Informationen gehen aus der PPD-Datei hervor (PostScript Printer Description), die mit dem Druckertreiber mitgeliefert wird. Durch die Verwendung des IPP, lässt sich der CUPS Dämon wie ein Webserver ansprechen. CUPS-Rechner kommunizieren über den IPP-Port 631. Der Zugriff auf das Webinterface erfolgt folglich über den Browser durch den Aufruf An diesen Port werden nicht nur die Druckdaten geschickt, sondern auch viele weitere Informationen. Da IPP auf HTTP 1.1 beruht, ist die Konfigurationsdatei /etc/cups/cupsd.conf der httpd.conf sehr ähnlich. Die wichtigsten Einstellungen werden in Kapitel erläutert. Eine weitere Besonderheit von CUPS sind die Backends. Sie sorgen für den Versand von Druckdaten zu den Ausagbegeräten oder anderen Servern. Die CUPS-Backends ermöglichen die Verbindung über verschiedene Schnittstellen und Protokolle mit dem Server. Für jedes Protokoll (parallel, seriell, USB oder Neztwerk) ist ein eigenes Backend zuständig. Die CUPS-Backends erlauben so, Druckjobs an alle herkömmlichen Drucker zu schicken. Abbildung 14.1: Cupsdiagramm IPP IPP ist ein Protokoll der Anwendunsschicht und wird in erster Linie für verteiltes Drucken im Netz verwendet. Das Protokoll definiert die Interaktion zwischen IPP-Client und IPP- Server, d.h. es wird definiert, wie die Daten für die Steuerung des Druckvorgangs verwendet werden, wie die Daten kodiert und wie sie transportiert werden. Der Datentransport mit IPP ist generell verschlüsselt. Desweiteren definiert IPP das s.g. Verzeichnisschema, über das ein

232 222 KAPITEL 14. DRUCKEN IM NETZ Verzeichnisserver nach verfügbaren Ausgabegeräten gefragt werden kann. Ausserdem bietet IPP die Möglichkeit, den Zugriff auf Drucker einzuschränken Funktionsweise Die Kommunikation zwischen Client und Server erfolgt gemäß dem bekannten Request- Response-Verfahren. Diese Anfragen und Antworten sind durch ASCII Code definiert und werden mittels des HTTP 1.1 Postmechanismus durchgeführt. Ein Request des Clients sieht wie folgt aus: ipp:druck.server/meindrucker/meindruckauftrag und führt dazu, dass der Client eine Verbindung zu Port 631 des Servers druck.server aufbaut und folgende Daten übermittelt: POST /meindrucker/meindruckauftrag HTTP/1.1 Host: druck.server:631 Content-type: application/ipp Transfer-Encoding: chunked... printer-url ipp://druck.server/meindrucker/meindruckauftrag Filter Die Filter findet man in/usr/lib/cups/filter/. Meist ersieht man schon aus dem Namen der Filter, welche Konvertierung er vornimmt. CUPS erkennt automatisch, welche Filtermechanismen angewendet werden müssen, d.h. welche Filter hintereinander angewandt werden müssen. Lediglich das Ausgabeformat muss man eintragen, sofern man ein anderes Format als PostScript verwenden möchte. (PostScript ist standardmässig vordefiniert.) Konfiguration Die Konfiguration von CUPS kann - wie bereits erwähnt - über den Browser durch einen Aufruf von geschehen. Eine weitere Möglichkeit zur Kofiguration des CUPS bietet Yast2. Es gibt aber auch schicke Webfrontends, die speziell für die Konfiguration von CUPS entwickelt wurden. Eine der bekanntesten Schnittstellen ist das KUPS (s. Möchte man die Konfiguration von Hand machen, beschränkt sich dies fast ausschliesslich auf folgende Dateien: In /etc/cups: cupsd.conf und mime.types In /var/log/cups: error log page log access log (f. Netzwerke) Die zwei wichtigsten Designentscheidungen bei der Konfiguration von CUPS sind Browsing On und Browse Poll. Sofern in der cupsd.conf eines CUPS-Rechners Browsing On gesetzt ist, stellt der Rechener per UDP-Broadcast den Namen des Druckers, Statusinformtionen und andere Zusatzinformationen zur Verfügung. Hierbei sollte man nicht ausser Acht lassen, dass die Broadcasts (entsprechend der TCP/IP-Spezifikation) nur bis zum nächsten Router oder

233 14.3. ALTERNATIVEN 223 Gateway weitergegeben werden. Wenn bei einem bestimmten Client nur die Browsing- Informationen eines bestimmten Servers verwendet werden sollen, kann man das in der Konfigurationdatei des Client durch Einträge der folgenden Art erreichen: BrowseAllow , BrowseDeny Das Gegenstück zum Browsing (per Broadcast) ist das Polling. In diesem Fall, warten die Clients nicht passsiv auf die Informationen über zur Verfügung stehende Drucker, sondern besorgen sich diese aktiv bei einem bestimmten Server. Hierzu verwendet man eine Angabe in Form von BrowsePoll :631, die dazu führt, dass der genannte Server nach verfügbaren Druckern gefragt wird, sobald gedruckt werden soll. Beim Polling gilt allerdings dieselbe Einschränkung des Broadcasts: Es könne nur Server im gleichen LAN angesprochen werden. Die Lösung diesen Problems ist, einen Router oder Gateway des eigenen LANs zum so.g. Browse-Relay zu machen Alternativen Zu den heute gängigen Alternativen zu CUPS zählen: TurboPrint: Ein kommerzielles Drucksystem, mit dem man bestmögliche Druckqualität erreichen kann. Nähere Informationen unter KDEPrint: Ein Modul der KDE-Oberfläche unter Linux. Es ermöglicht einen einfachen und intuitiven Zugriff auf sämliche CUPS-Funktionalitäten. Nähere Informationen unter printing.kde.org

234 224 KAPITEL 14. DRUCKEN IM NETZ

235 Kapitel 15 Wichtige Netzwerkkommandos 15.1 Offene Dateien und Netzwerkverbindungen Das Kommando lsof (ListOpenFiles) zeigt die geöffneten Dateien (zum Lesen oder Schreiben) an und die dazugehörenden Prozesse. Weiterhin werden offene Sockets (Netzwerkverbindung mit Portadresse), sowie verwendete Pipes und Filesockets angezeigt netstat netstat hat sich auf das Anzeigen offener Sockets, sowohl des Filesystems, als auch von Netzwerkverbindungen spezialisiert. Die Ausgabe von netstat -a hat folgendes Aussehen, wobei die Protokolle TCP, UDP und unix (Socket im Filesystem) in dieser Reihenfolge sortiert aufgeführt werden. > 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/ Überblick verschaffen, welche Netzwerkverbin- Mit netstat -M kann man sich einen dungen gerade maskiert werden: root@server:/ # netstat -M IP masquerading entries prot expire source destination ports tcp 0: test.local > 2183 (64155) tcp 0: test.local > 2187 (64156) tcp 0: test.local > 2188 (64157) 225

236 226 KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS tcp 1: test.local > 2195 (64159) tcp 0: test.local > 2192 (64158)... Wird die Option -n beim Aufruf des Kommandos aufgeführt, wird keine Namensauflösung durchgeführt, was die Anzeige stark beschleunigen kann, gerade bei IP-Nummern, die nicht im Nameserver bekannt sind. netstat -r liefert die Kernel-Routingtabelle in ähnlicher Weise, wie sie auch vom Kommando route angezeigt wird. Wenn Sie netstat mit dem Flag -i aufrufen, gibt es die Statistiken für die gerade aktiven Netzwerk-Schnittstellen aus. Geben Sie außerdem das Flag -a mit an, werden alle im Kernel vorhandenen Schnittstellen ausgegeben, nicht nur die konfigurierten Schnittstellen. An der Konsole produziert netstat -i in etwa folgendes: # 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 BLRU eth BRU Die Spalten MTU und Met geben die aktuelle MTU und Metrik des Interface an. Die mit RX bzw. TX überschriebenen Spalten geben an, wie viele Pakete: RX-OK/TX-OK fehlerfrei empfangen bzw. gesendet wurden RX-ERR/TX-ERR wie viele beschädigt waren RX-DRP/TX-DRP wie viele wegeworfen werden mußten RX-OVR/TX-OVR wie viele aufgrund eines Overruns verlorengingen Die letzte Spalte zeigt wieder die Liste der Flags, die für die Schnittstelle gesetzt sind. Das sind einbuchstabige Versionen der langen Flagnamen, die ifconfig ausgibt: Buchstabe B L M O P R U Bedeutung BROADCAST LOOPBACK PROMISC NOARP POINTOPOINT RUNNING UP Tabelle 15.1: Bezeichner 15.3 Systemprogramme Dämonen xinit, init, rinted, nfsd, smbd, nmbd, proftpd, httpd, dhcpd

237 15.4. NETZWERKKONFIGURATION Netzwerkkonfiguration ifconfig, route, ip, ping, nslookup, dig, tc, ifuser tcptraceroute ttcp (Throughput of UDP / TCP traffic) tcptrack (per connection bandwidth monitor) tcpstat tcpick, tcpflow, Netzwerktests ping traceroute mtr netdiag Net-Diagnostics (trafshow,strobe,netwatch,statnet,tcpspray,tcpblast) Netdiag contains a collection of small tools to analyze network traffic and configuration of remote hosts (strobe). It is of invaluable help if your system is showing strange network behaviour and you want to find out what your network is doing. nictools-nopci nictools-pci Diagnostic tools for many PCI ethernet cards These tools can help you to diagnostic problems with your ethernet cards or - in some cases - give those cards the final hint, to work in your network. alta-diag : Diagnostic and setup for the Sundance Alta NIC eepro100- diag : Diagnostic and setup for the Intel EEPro100 Ethercards epic-diag : Diagnostics and EEPROM setup for the SMC EPIC-100 myson-diag : Diagnostic and setup for the Myson mtd803 Ethernet chip natsemi-diag : Diagnostic and setup for the NatSemi DP83815 Ethernet chip ne2k-pci-diag : Diagnostics and EEPROM setup for PCI NE2000 clones ns820-diag : Diagnostic and setup for the NatSemi DP83820 Ethernet chip pcnet-diag : Diagnostic and setup for the AMD PCnet/PCI Ethernet chip rtl8139-diag : Diagnostics and EEPROM setup for RealTek RTL8129/8139 chips starfire-diag : Diagnostic and setup for the Adaptec Starfire DuraLAN tulip-diag : Diagnostic and setup for the Digital DC21x4* Ethercards chips via-diag : Diagnostic and setup for the VIA Rhine vt86c100 and vt3043 Ethernet chips vortex-diag : Diagnostics and EEPROM setup for the 3Com Vortex series winbond-diag : Diagnostic and setup for the Winbond w89c840 ethercards yellowfin-diag: Diagnostic and setup for the Packet Engines Yellowfin chip Das Kommando ping ist Teil jeder Linux-Distribution. Das Programm sendet ein spezielles Datagramm über das Netzwerk an einen anderen Rechner. Wenn dieser eingeschaltet ist und es empfängt sendet er es wieder zurück und man weiß, dass Rechner und Netzwerk in Ordnung sind. In der einfachsten Form sieht das so aus: dirk@randy2:~/vorlesung/lak> ping login PING login ( ) from : 56(84) bytes of data. 64 bytes from login3 ( ): icmp_seq=1 ttl=63 time=4.44 ms 64 bytes from login3 ( ): icmp_seq=2 ttl=63 time=0.219 ms 64 bytes from login3 ( ): icmp_seq=3 ttl=63 time=0.217 ms 64 bytes from login3 ( ): icmp_seq=4 ttl=63 time=0.218 ms ^C --- login.ruf.uni-freiburg.de ping statistics packets transmitted, 4 received, 0% loss, time 3030ms rtt min/avg/max/mdev = 0.217/1.275/4.448/1.831 ms

238 228 KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS ping sucht zunächst die richtige IP-Adresse zu dem angegebenen Rechnernamen heraus 1 und sendet dann in regelmäßigen Abständen ein bestimmtes Datagramm an diese Adresse. Für jeden dieser icmp echo requests wird der andere Rechner dann ein icmp echo reply als Antwort zurücksenden. Jede der Zeilen 64 bytes from... stellt eine solche empfangene Rückantwort dar. In jeder Zeile ist auch die Adresse des Absenders dieses Paketes angegeben, die Nummer des echo requests, auf den mit diesem Paket geantwortet wurde, die time to live (Lebensdauer) sowie die round trip time, das ist die Zeit in Millisekunden zwischen Absendung des request und Empfang des entsprechenden echo reply. Damit ist dies in gewissen Grenzen ein Maß für die Geschwindigkeit des Netzwerkes. ping würde endlos weiter seine Pakete senden, deshalb muß es abgebrochen werden. Dies geschieht durch gleichzeitiges Drücken der Tasten Control (Strg) und C. Danach gibt ping noch eine Statistik der gesendeten Pakete aus. In den letzten beiden Zeilen ist es: Die Anzahl der gesendeten, empfangenen, sowie unbeantworteten Pakete. Außerdem kürzeste, längste und mittlere Antwortzeit. Eine hohe Verlustrate an Paketen deutet auf Probleme mit der Verbindung hin, diese können durch schlechte Verbindungen, überlastete Router oder Kollisionen im lokalen Ethernet verursacht werden. Man kann mit ping die schadhafte Stelle lokalisieren, indem man nacheinander alle Knotenpunkte der Verbindung an-pingt und nachsieht, ab welchem Punkt die Verlustrate stark ansteigt. Mit traceroute (auch bei jeder Distribution dabei) kann man den Weg, den die Datagramme bei einer Verbindung zwischen zwei Rechnern zurücklegen, testen und anzeigen. Wie auch ping verwendet traceroute dazu das icmp Protokoll. Es verwendet jedoch einen Trick, um von jeder durchlaufenen Knotenstelle eine Rückmeldung zu bekommen, und das geht so: Das Feld time to live eines icmp-datagramms dient eigentlich dazu, zu verhindern, dass das Datenpaket ewig im Netz herumgeschickt wird, z.b. wenn es in eine Routing- Endlosschleife gerät. Zu diesem Zweck verringert jeder Router, der das Paket weiterleitet, den Zähler in diesem Datenfeld um eins. Wird dabei der Wert Null erreicht, so wird der Router, bei dem dies geschehen ist, eine icmp time to live expired Meldung an den ursprünglichen Absender des Datagramms senden um ihm mitzuteilen, dass das Datagramm abgelaufen ist. traceroute sendet nun nacheinander Datagramme ab, deren time to live (beginnend bei eins) jeweils um eins erhöht wird. Indem es nun die eingehenden icmp time to live expired Meldungen auswertet, kann es genau den Weg, den die Datagramme nehmen, verfolgen - bis der wirkliche Zielrechner erreicht ist. Das sieht dann so aus: dirk@test:~/vorlesung/lak> /usr/sbin/traceroute goe.net traceroute to goe.net ( ), 30 hops max, 40 byte packets ms ms ms ms ms ms 3 nsc-rz-gwn.fun.uni-freiburg.de ( ) ms ms \ ms 4 Freiburg1.Belwue.DE ( ) ms ms ms 5 Stuttgart1.BelWue.DE ( ) ms ms ms 6 Stuttgart2.BelWue.DE ( ) ms ms ms 7 Frankfurt1.BelWue.DE ( ) ms ms ms 8 ffm-b2-geth0-1.telia.net ( ) ms ms ms 9 ffm-b2-geth0-1.telia.net ( ) ms ms ms 10 ffm-bb2-pos2-3-0.telia.net ( ) ms ms ms 11 hbg-bb2-pos1-1-0.telia.net ( ) ms ms ms 12 hbg-b1-pos1-0.telia.net ( ) ms ms ms 13 dante hbg-b1.c.telia.net ( ) ms ms \ ms 14 cr-hannover1.g-win.dfn.de ( ) ms ms \ ms 1 Voraussetzung ist natürlich, dass /etc/hosts und der Nameserver richtig konfiguriert sind

239 15.4. NETZWERKKONFIGURATION ar-goettingen1.g-win.dfn.de ( ) ms ms ms 16 c12012-int.gwdg.de ( ) ms ms ms ms ms ms 18 stud9.stud.uni-goettingen.de ( ) ms ms \ ms Die erste Spalte gibt die Entfernung an, also der wievielte Knoten (Hop) in der Verbindung der bezeichnete Rechner ist. Dies entspricht dem Eintrag im time to live Feld des Datagramms, das vom angegebenen Rechner als expired gemeldet wurde. Der nächste Eintrag ist der Rechnername (falls dieser anhand der IP-Adresse herausgefunden werden kann) und dessen IP-Adresse. Dann kommen drei Einträge mit den Antwortzeiten für drei aufeinanderfolgende Datagramme an diesen Rechner. Der erste Punkt in der Verbindung ist also der Rechner gw. Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales Ethernet. Der nächste Router ist gw.uts - von dort kommen die Datagramme sehr viel langsamer zurück als von gw. Der Grund ist hier eine sehr langsame Verbindung über eine Funkstrecke. Der nächste Knoten ist bereits der gesuchte Rechner, minnie.vk1xwt. Auch hier kommen die Antworten nur sehr langsam. Dies liegt aber daran, dass die Antwortzeit jedes Rechners natürlich die Summe der Verbindungszeiten aller dazwischenliegenden Teilstrecken ist. In diesem Falle also vom eigenen Rechner zu gw; von dort zu gw.uts; und schließlich von gw.uts zu minnie.vk1xwt. Berücksichtigt man diese Aufsummierung der Zeiten, so sieht man, dass die letzte Verbindung von gw.uts zu minnie.vk1xwt ebenfalls sehr schnell ist. Diese beiden Rechner hängen also vermutlich auch an einem lokalen, schnellen Netzwerk. Taucht bei einem traceroute Aufruf hinter den Zeiten ein!n auf so weist dies auf ein nicht erreichbares Netzwerk hin. Es ist ein Zeichen dafür, dass ein Router nicht wußte, wohin er das Datagramm weiterleiten soll. Er sendet dann ein network unreachable Datagramm an den Absender zurück. Meist deutet es darauf hin, dass eine Netzverbindung (zeitweise) zusammengebrochen ist. Anhand der letzten angegebenen Adresse vor dieser Fehlermeldung kann man die defekte Stelle lokalisieren. Ebenfalls auftauchen kann ein!h als Hinweis darauf, dass ein Rechner (Host) nicht erreicht werden konnte. Dies bedeutet i.a. dass man bis in das lokale Netzwerk des Zielrechners gelangt ist, dieser sich aber nicht meldet (weil er z.b. abgeschaltet ist) Netzwerküberwachung netstat, tcpdump, ethereal, nmap, ntop, iptraf, xnetload, arpwatch, fping, ipgrab tcpdump kann die gesamte Aktivität auf dem Netzwerk überwachen indem es sämtlich Datagramme auf dem Weg in den eigen Rechner hinein oder heraus abhört. Damit lassen sich vom erfahrenen Administrator auch schwer zu identifizierende Netzwerkprobleme lokalisieren. tcpdump dekodiert jedes abgefangene Datagramm und zeigt es - in einer etwas kryptischen Form - als Text an. tcpdump bietet sich an, um Protokollfehler oder plötzliche Verbindungsabbrüche aufzuspüren. Denn man kann damit sehen, was auf dem Netzwerk passiert. Um es jedoch sinnvoll einsetzen zu können, bedarf es eines tieferen Verständnisses der Protokolle und wie sie arbeiten. Doch es kann auch einfach dazu benutzt werden, um sicherzustellen, dass z.b. Datagramme den eigenen Rechner wirklich über die richtige Schnittstelle verlassen oder, um zu überprüfen, ob irgendwelche Datagramme von außerhalb empfangen werden. Eine typische Ausgabe von tcpdump sieht etwa so aus: test2:/root # tcpdump -i eth0 tcpdump: listening on eth0 18:25: d config :20:da:e7:77: root :20:da:e7:\ 77:52

240 230 KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25: d config :20:da:e7:77: root :20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25: d config :20:da:e7:77: root :20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25: d config :20:da:e7:77: root :20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay 15 18:25: > OSPF-ALL.MCAST.NET: OSPFv2-hello 44: rtrid 132.\ backbone dr [ttl 1] 18:25: randy2.rz.uni-freiburg.de > dns0.fun.uni-freiburg.de.domain: PTR? in-addr.arpa. (44) (DF) 18:25: dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: NXDomain* 0/1/0 (137) 18:25: randy2.rz.uni-freiburg.de > dns0.fun.uni-freiburg.de.domain: PTR? in-addr.arpa. (40) (DF) 18:25: dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: /4/4 PTR [ domain] 18:25: randy2.rz.uni-freiburg.de > dns0.fun.uni-freiburg.de.domain: PTR? in-addr.arpa. (46) (DF) 18:25: dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: NXDomain* 0/1/0 (141) 18:25: randy2.rz.uni-freiburg.de > dns0.fun.uni-freiburg.de.domain: PTR? in-addr.arpa. (46) (DF) 18:25: dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895: 25561* 1/2/2 (173) 18:25: d config :20:da:e7:77: root :20:da:e7:\ 77:52 pathcost 0 age 0 max 20 hello 2 fdelay packets received by filter 0 packets dropped by kernel Wenn tcpdump ohne Argumente gestartet wird, wird das Netzwerk-Device mit der kleinsten Nummer, das kein Loopback-Device ist, überwacht. Es kann aber - wie im Beispiel - auch ein spezielles Device angegeben werden. tcpdump dekodiert dann jedes Datagramm das über diese Device übertragen wird und zeigt es in einer lesbaren Form an. Der erste Eintrag ist - wie leicht zu ersehen - der Zeitpunkt, zu dem das Datagramm gesendet oder empfangen wurde. Der weitere Inhalt der Zeile hängt dann von der Art des Datagramms ab. Die ersten beiden Zeilen im Beispiel zeigen, einen arp request. tcpdump gibt dabei auch die genaue Art des icmp Datagramms an. Das Größer-Zeichen ( ) gibt die Richtung an, in der das Datagramm übermittelt wurde (es zeigt vom Sender zum Empfänger). Die restlichen Zeilen protokollieren den Aufbau einer telnet Verbindung von albert.vk2ktj zu gw.vk2ktj Die Zahl am Ende jeden Rechnernamens gibt die verwendete Socket Nummer an, zu diesem Zweck wertet tcpdump die Datei /etc/services aus. Beispiel: tcpdump -i eth1 host 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

241 Kapitel 16 Netzwerküberwachung 16.1 Überblick Inzwischen ist der Rechnerarbeitsplatz in Firmen und Organisationen zum Standard avanciert. Viele Dienste, wie der Druck- oder Fileserver, die Firewall, der Mail- und Webserver werden üblicherweise auch in kleineren Firmennetzwerken angeboten. Die Zahl der Maschinen hat damit einen so großen Umfang angenommen, dass sich nicht mehr durch einfaches Draufgucken ihre vielfältigen Aufgaben überwachen lassen. Mit diesem Wachstum der LANs (Local Area Networks) entsteht die Notwendigkeit sich einen schnellen und umfassenden Überblick über den Zustand eines Netzes und der angeschlossenen Maschinen verschaffen zu können. Deshalb existieren inzwischen einige, teilweise konkurrierende Protokolle zur Überwachung von Workstations und aktiven Netzwerkkomponenten. Das am häufigsten verwendete Verfahren zur Überwachung und Konfiguration eingesetzter Komponenten ist das Simple Network Management Protocol (SNMP). Eine Reihe ernsthafter Leute hat sich eine Reihe wichtiger Gedanken für ein ernsthaftes Problem gemacht und SNMP erfunden: Wie kann eine Organisation Hunderte oder Tausende (wenn nicht noch mehr) aktiver Netzwerkkomponenten und Maschinen sowie das zugrunde liegende Netzwerk beobachten und steuern? SNMP basiert auf der TCP/IP Protokoll-Suite. Es etabliert durch seine starke Standardisierung ein einheitliches Modell zur Kontrolle und Verwaltung von Netzwerken. Ein wesentlicher Vorteil dieses Protokolls liegt neben seiner weiten Verbreitung in der flexiblen Erweiterbarkeit. SNMP erlaubt die schnelle und einfache Übertragung von Datenpaketen zur Zustandsbeschreibung von Netzwerkgeräten. Jedoch genügt es in einigen Fällen nicht, festzustellen, dass ein bestimmter Dienst aktiv ist, indem man überprüft, ob der entsprechende Prozess in der Liste laufender Programme auftaucht. Es geht nicht darum, eine Innenansicht einer Maschine festzustellen, sondern den Zustand zu überprüfen, wie er sich aus Sicht des Benutzers darstellt. Vielfach ist erst dann eine Aussage sinnvoll, wenn ein Testzugriff über das Netzwerk erfolgreich durchgeführt wurde. Für diese Art des Monitoring bieten sich Web-, FTP- und Mailserver sowie Authentifizierungsdienste an, da nur so eine Nutzbarkeit aus Sicht des Users emuliert werden kann SNMP - Das Simple Network Mangement Protocol Überblick Das Konzept von SNMP beinhaltet eine verteilte Management Architektur. Das Managementproblem wird in zwei Teile aufgespalten und es werden für jeden Teil separate Stan- 231

242 232 KAPITEL 16. NETZWERKÜBERWACHUNG dards definiert. Der erste Teil befaßt sich mit dem Austausch von Informationen. SNMP basierende Netzwerkmanagementlösungen arbeiten im Client-Server-Modell. Anwendungen welche zum Sammeln von Daten oder zur Steuerung von Geräten dienen, werden Agenten genannt. Der Management Host kann diese Daten von den Agenten abfragen. Das Protokoll bestimmt zum einen, wie die Client-Software funktioniert und die Austauschformate zwischen Management Host und Agenten aussehen, sowie die Form der Namen und Adressen. Zum zweiten wird festgelegt, welche Daten ein gemanagtes Gerät vorhalten muss, wie diese benannt sind und welche Syntax zum Ausdruck bestimmter Werte und Zustände verwendet wird. SNMP verfolgt einen minimalistischen Ansatz: Das Set der zugelassenen Operationen ist sehr beschränkt, ein paar Befehle verschaffen die gesamte Funktionalität. SNMP wurde von der IETF in etlichen RFC s standardisiert (ua. 1155, 1157, 1212, 1213, , 1450). Hierin wurde festgelegt, dass SNMP mittels des verbindungs- und quittungslosen Unified Data Protocol (UDP) kommuniziert. Der Austausch zwischen Agent und Monitor erfolgt dabei standardmäßig auf Port 161. Die Management Station kann Daten von den zu überwachenden Agenten (zyklisch) pollen, welche als Server fungieren. Die MIB-Informationen können dann grafisch aufbereitet, dargestellt oder anders verarbeitet werden. Die Host sind jedoch auch in der Lage, gewisse Ereignisse mittels sogenannter Traps ( Falltüren ) an die Management Station über Port 162 zu melden. Der Informationsaustausch zwischen den Agenten und dem Überwachungs-Client läuft im Hintergrund ab und versucht die Netzwerkbelastung gering zu halten. SNMP liegt inzwischen in der dritten Version (SNMPv3) vor, jedoch sind die Unterschiede zu den Vorgängern gering und die meisten Befehle und Strukturen abwärts kompatibel Die Datendefinition Ein überwachtes Objekt muss bestimmte Zustands- und Kontrolldaten vorhalten, da sie vom Manager abgefragt werden können. Dazu gehören bei Routern sicherlich die Routingtabellen, sowie einkommender und ausgehender Datenverkehr. Switches werden bestimmte Portstatistiken zu transferierten Paketmengen und dabei aufgetretenen Fehlern vorhalen; ein Drucker kann die Zahl der ausgeworfenen Seiten und die Länge der Druckerwarteschlange bereithalten. Obwohl dem Manager der Zugriff auf diese Daten erlaubt wird, sagt SNMP nichts Genaueres darüber aus, welche Informationen auf welchem Gerätetyp erhältlich sind. Stattdessen definiert ein weiterer Standard die Details. In der Management Information Base (MIB) werden die Informationen vermerkt, sowie welche Bedeutung sie haben, welche Operationen auf ihnen ausgeführt werden können und welche Werte sie annehmen können. So hat ein Paketzähler für einen Switchport einen Integerwert, der nur lesbar ist und nicht verändert werden kann. Eine Variable, die den Zustand desselben Ports beschreibt (ob dieser ein- oder abgeschaltet ist) wird den Zustandswert enthalten und les-/schreibbar sein. Der Vorteil MIBs unabhängig von SNMP zu definieren, liegt darin, dass Hersteller von Netzwerkkomponenten neue Variablen einführen können. Ein Benutzer kann dieselbe Netzwerkmanagementsoftware, wie für die bekannten MIBs verwenden. Natürlich wird kein Gerät die Daten liefern, die in ihm unbekannten MIBs definiert sind. Trotzdem bleibt die Sprache und das Protokoll von SNMP gleich. Zu Zeiten von SNMPv1 und v2 waren alle Daten in einer einzigen MIB festgelegt. SNMPv3 erlaubt verschiedene MIBs zu definieren. In der System-MIB (MIB-II) sind grundlegende Verwaltungsdaten abgelegt, wovon einige in der Tabelle gezeigt sind. Die MIB-II wird von den meisten Herstellern unterstützt. Darüberhinaus definiert jeder Anbieter von netzwerkfähiger Hardware weitere MIBs, z.b. die Host-MIB (MIB für Endgeräte).

243 16.3. DIE DATENDEFINITION 233 MIB Informationen zu/über system Überwachtes Gerät, Standort, Eigentümer, Software, Uptime, Ansprechpartner... interfaces Eingebaute reale und virtuelle Netzwerkinterfaces: Mehrere bei Routern und Switches, meistens eines bei Rechnern, Druckern... ip IP-Daten, wie Routingtabelle, Paketzähler... tcp TCP-Daten, wie offene Verbindungen, Paketzähler udp UDP-Daten, wie offene Ports, Paketzähler snmp Statistiken und Zähler des SNMP-Agenten host Statistiken und Daten klassischer Workstations, wie Speicher, Festplatten, Zahl der Nutzer... Tabelle 16.1: Einige Standard-MIBs Der SNMP-Namensraum und die Management Information Bases Der SNMP-Datenraum ist großzügig und universell erweiterbar angelegt. Große Teile sind für zukünftige Ergänzungen reserviert und für die evtl. Migration mit anderen baumartigen Datenstrukturen freigehalten. Ein weiterer Standard definiert das Regelwerk zum Festlegen und Identifizieren der MIB Variablen. Dieses grundlegende Format heißt SMI (Structure of Management Information). Um das Protokoll einfach zu halten, legt SMI einige Restriktionen zu den in den MIBs erlaubten Variablen fest, bestimmt deren Benennung und die Definition von Variablentypen. Hierzu gehören z.b. der Zähler (Counter, Integervariable im Bereich von 0..2ˆ32-1) oder die IP-Adresse (4 Oktets). Die Datentypen können wiederum zu Tabellen oder Folgen kombiniert werden. Zur Bennenung der MIB-Variablen und deren Referenzierung verwendet SMI den ASN.1- Standard (Abstract Syntax Notation der ISO). Dieses ist eine formale Sprache mit zwei Ausprägungen: Einem kompakten maschinen-lesbaren Teil für die Verwendung im Kommunikationsprotokoll und einer für Menschen lesbaren Form der Daten zur Beschreibung in Dokumenten. ASN.1 fordert dabei eine sehr hohe Präzision (z.b. die Angabe des Wertebereichs einer Variablen), um eine gute Interoperabilität zu gewährleisten. Die Variablen der MIBs sind in einer baumartigen Struktur abgelegt, dem Object Identifier Namespace, welcher von ISO und ITU verwaltet wird. Der Aufbau ähnelt ein wenig dem vom Domain Name System oder Dateisystemen bekannten. Der Namensraum ist global, d.h. alle eingetragenen Zweige sind eindeutig. Subnamensräume können jedoch delegiert werden, so dass nicht jeder neue Eintrag bei den o.g. Organisationen beantragt werden muss. Die Wurzel des Bauses ist unbenannt, danach folgen die managenden Organisationen (ISO, ITU und ISO+ITU gemeinsam). Das Trennzeichen zwischen den Hierarchieebenen ist der Punkt. Angesprochen werden kann jeder Host über eine Nummer, wobei zur Vereinfachung des Zugriffes auch Namen erlaubt sind. Diese dienen jedoch wie beim DNS eher der Bequemlichkeit; sie sind keine Eigenschaften des Hierarchiebaumes und werden nicht bei der Client-Server-Kommunikation verwendet. Der für SNMP interessanteste Teil des Namensraums wird mittels der sogenannten MIBs aufgespannt. Sie definieren die unterschiedlichen Daten-Domains, die mittels SNMP abgefragt werden können. Sie beinhalten das Schema der abfragbaren Informationen und die Übersetzung der OIDs in ihre jeweiligen Namen. Dabei sind die obersten Ebenen des Datenbaumes für die Definition der Berechtigungen an einzelne Gruppen reserviert. Der spannendere Abschnitt des SMI-Baumes startet mit OID , welcher den Namen

244 234 KAPITEL 16. NETZWERKÜBERWACHUNG iso.org.dod.internet trägt. Hier finden sich die System-, Interface-, TCP/IP, hostspezifische und weitere (herstellerdefinierte) MIBs. Ansehen kann man sich die MIBs mit einem Texteditor, komfortabel wird es jedoch erst mit grafischen Tools. Cheops und TKined haben eingebaute Funktionen um MIBs zu visualisieren, richtig komfortabel wird es mit Mbrowser (siehe [7]), welcher auf Net- SNMP aufsetzt und ein GTK-GUI verwendet. Mit mbrowser lassen sich auch die Standard- SNMP-Kommandos, wie get, set, walk absetzen, die weiter unten in ihrer Kommandozeilenausführung besprochen werden Die SNMP-Agenten Jeder einzelne Knoten im Netz - Netzwerkkomponenten oder auch Endgeräte, welche sich mittels SNMP verwalten lassen, verfügen über einen Management Agenten. Dieser stellt Informationen in strukturierter Form zur Verfügung. Anhand dieser erfolgt die Überwachung und Konfiguration des jeweiligen Gerätes. Die Datenstruktur wird als Management Information Base (MIB) bezeichnet. Die Agenten sind üblicherweise als Softwarelösung in den Netzknoten und Endgeräten umgesetzt. Diese Implementation erfolgt bei den Anbietern aktiver Netzwerkkomponenten meistens herstellerspezifisch. Auf einer Linux- bzw. Unix- Workstation stehen dafür mehrere Implementationen zur Verfügung. Die Lösungen reichen von C++-Implementationen, wie dem Open-SNMP, die in C geschriebene Toolsuite des CMU bzw. Net-SNMP, Bibliotheken die TCL/TK zu Grunde legen, wie scotty bis hin zu Java- oder Perl-basierten Umsetzungen. Ihre Funktionalität unterscheidet sich in den von den Agenten unterstützten MIBs sowie den Werkzeugen zur Erlangung und Visualisierung der Daten Der Kommunikations-Code der Agenten Nun sind die Datentypen und die Struktur der zur Verfügung stehenden Daten definiert. Jetzt sollen diese zwischen dem Agenten und dem Management System ausgetauscht werden. Hierzu sind vier grundlegende Operationen und ihre Erweiterungen definiert: Jede Bitte um einen Satz von Daten muss einen vollständigen Pfad für die erwünschte Information beinhalten. Das Schreiben und Lesen von Feldern auf einem Knoten der SMI- Hierarchie erfolgt mit set und get. Mittels get-next lassen Tabelleninformationen schrittweise anfordern. Die Berechtigung zum Lesen bzw. Schreiben der einzelnen OIDs erfolgt bei SNMPv1 bzw. v2 mittels Communitystring und die Angabe der zum Lesen berechtigten Hosts oder Netzwerke. Die Funktion set ist nicht ganz unkritisch, da es die eine Steuerung von Geräten erlaubt, wie z.b. das Abschalten von Ports auf Switches oder Routern. Dieses ist jedoch unter Sicherheitsaspekten nicht unproblematisch, da die Daten meistens unverschlüsselt übertragen werden und erst die Spezifikation von SNMPv3 komplexere Authentifizierung erlaubt. Eine Trap (Kommando trap) geht den umgekehrten Weg. Sie erlaubt es Benachrichtigung unabhängig von einer Anfrage des Clients an diesen zu übermitteln. Dieses kann für das Auftreten bestimmter Ereignisse oder Bedingungen festgelegt werden, läßt sich jedoch nicht für beliebige Felder definieren. Standard-Traps sind z.b. die Information zum Start des Servers, Traps, die Ausfälle oder Wiederbelebungen von Netzwerkverbindungen kundgeben und einige Authentifizierungsprobleme. Der Mechanismus zur Definition von Trap-Nachrichten hängt von der jeweiligen Server-Implementierung ab. Switches und Router kennen andere und meistens weitaus mehr verschiedene Traps als Endgeräte, die jedoch

245 16.4. SNMP-IMPLEMENTIERUNGEN UNTER LINUX 235 meistens nicht genormt sind. Auf einer Linux-Workstation ist es schließlich einfacher andere Konzepte als SNMP-Traps zur Behandlung von Ausnahmesituationen umzusetzen SNMP-Implementierungen unter Linux Wie bereits kurz erwähnt stehen unter Linux einige Implementierungen von SNMP zur Verfügung. Jedoch soll sich der Artikel auf die aus Sicht des Autors beste und vollständigste Umsetzung beziehen: Net-SNMP. Nachdem die Entwicklung des bisher im Linuxumfeld recht weit verbreiteten Paketes der Carnegie Mellon University (CMU) etwas eingeschlafen ist, genießt das Projekt Net-SNMP zunehmende Beachtung. Es ist aus einem Projekt der University of California in Davis hervorgegangen. Das Paket steht unter der GPL und kann über die Projekthomepage (siehe [] netsnmp.org) bezogen werden. In den meisten Fällen wird man es nicht mehr selbst kompilieren müssen, da es Bestandteil vieler Linuxdistributionen ist. Gründe es selbst zu übersetzen, könnten in notwendigen Bugfixes oder experimentellen neuen Features liegen. Das Net-SNMP-Paket beinhaltet eine C-Bibliothek mit den wesentlichen Funktionen, den Agenten (SNMP-Server, d.h. snmpd) und Programme zur Datenbeschaffung, welche die vier Standardkommandos get, get-next und trap enthalten. Die Syntax und die Namen der Standardkommandos sind festgelegt, die der von verschiedenen SNMP-Paketen mitgelieferten Programme jedoch nicht! Bei der Vorstellung des Monitoring-Tools Nagios im zweiten Teil sieht man, das dieses eine eigene SNMP-Umsetzung mitbringt. Auch Programm MRTG zur Darstellung der Auslastung von Netzwerkinterfaces (siehe []) beziehen ihre Daten vom SNMP-Agenten, verwenden aber die Aufrufe aus ihrer eigenen Bibliothek. Net-SNMP implementiert die Funktionalität von SNMPv3 und is modular mittels AgentX erweiterbar Kommandos zur Datenbeschaffung Das Beste zum Ausprobieren der verschiedenen SNMP-Kommandos ist eine Maschine oder Netzwerkkomponente im eigenen Subnetz. Der Communitystring zur Authentifizierung gegenüber dem Agenten sollte bekannt und die eigene IP-Nummer als zugelassen auf der entsprechenden Maschine eingetragen sein. Handelt es sich beim beobachteten Gerät um einen Net-SNMP-Agenten, werden diese Informationen im Bereich [A]-[D] (siehe Beispiel weiter unten) der Konfigurationsdatei angegeben. snmpget target-host community sysdescr.0 liefert z.b. die Beschreibung des Gerätes: system.sysdescr.0 = 3Com SuperStack II snmpget target-ip community liefert das identische Ergebnis. Die Kommandos von Net-SNMP gehorchen dabei folgender Syntax: Programmname [Optionen...] <hostname> {<community>} [<OID>...] Die Object ID kann immer als Nummer und so als Definition in einer installierten MIB angegeben, als Name angegeben werden. Mittels der Optionen lassen sich die SNMP-Version (1,2 oder 3) für die Anfrage angeben sowie Spezifika für einzelne Versionen setzen. Daüberhinaus kann bestimmt werden, wie die Ein- und Ausgabe und die Darstellung der MIB formatiert werden soll oder Debuginformationen generiert werden. Snmpget, snmpgetnext und die abgeleiteten Tools wird man selten direkt einsetzen. Sie eignen sich für Tests und

246 236 KAPITEL 16. NETZWERKÜBERWACHUNG einfache Shellskripten. Für die visuelle Darstellung z.b. der Auslastung einzelner Ports eines Linuxrouters oder eines Switch kommt MRTG (Multi Router Traffic Grapher, siehe Kap. 16.8) in Frage, da hier neben dem momentanen Zustand auch Zeitreihen gut darzustellen sind. Mit dem Programm snmptranslate läßt sich vergleichbar mit nslookup im Domain Name System eine Übersetzung zwischen Nummer und Name auslesen. Darüberhinaus bekommt man weitere Informationen, z.b. eine Beschreibung der Variablen und ihren Typ angezeigt. Kasten: Ausgabe des Kommandos snmptranslate -Td -OS system.sysdescr sysdescr OBJECT-TYPE -- FROM SNMPv2-MIB, RFC1213-MIB -- TEXTUAL CONVENTION DisplayString SYNTAX OCTET STRING (0..255) DISPLAY-HINT "255a" MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system s hardware type, software operating-system, and networking software." ::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 1 } Programme, wie snmpnetstat, snmpstatus oder snmpdf vereinfachen wichtige Standardanfragen, z.b. nach offenen TCP-Verbindungen und UDP-Ports, dem Gerätetyp und seinen Interfaces oder dem freien Speicherplatz. Hier sind im Gegensatz zu snmpget, snmpgetnext, snmptable keine OIDs anzugeben. Da es recht aufwändig ist, sich mittels snmpget oder snmpgetnext einen umfassenden Überblick über den Baum verfügbarer Daten eines Endgerätes oder Netzwerkknotens zu verschaffen, bringt snmpwalk Erleichterung. Dieses Programm erlaubt es den gesamten Datenbaum eines Agenten sukzessive abzufragen oder Unterbäume vollständig abzulaufen. Letzteres geschieht über die Angabe eines Teils des OID. Je länger der Object Identifier wird, desto genauer wird der abzufragende Teil des Baumes eingegrenzt und kürzer wird die Ausgabe Konfiguration des UCD-SNMP Der Kopf definiert die Zugriffs-Policies Der Server snmpd, welcher als Softwareagent auf der zu beobachtenden Maschine läuft wird mittels /etc/ucdsnmpd.conf gesteuert und üblicherweise durch ein Runlevel-Skript in /etc/init.d gestartet. Die ersten vier Abschnitte ([A]-[D]) der Konfigurationsdatei dienen der Authentifizierung, wobei jeweils zu überlegen ist, welche Hosts welche Daten pollen dürfen. In den meisten Fällen genügt eine Beschränkung auf das lokale Subnetz, wobei jedoch auch ausschließlich die Management Station (also der Rechner, von dem die Überwachung läuft) eingetragen werden kann. Der Agent kann mehrere unterschiedliche Access-Regeln definieren. Eine solche Regel besteht aus einer MIB, die alle Bereiche der MIB enthält, auf welche

247 16.6. KONFIGURATION DES UCD-SNMP 237 ein Zugriff für die Nutzergruppe gestattet ist. Festgelegt wird weiterhin der Zugriffsmodus, welcher im Beispiel für Anfragen aus dem Netzwerk nur lesend erfolgen darf. Die Gesamtheit der Verwaltungsrechte wird in einem Community Profile zusammengefaßt. Anhand des vom Client mitgelieferten Community Passworts (hier immer mit community bezeichnet) bestimmt der Agent, ob MIB Objekte für die aktuelle Anfrage sichtbar sind oder modifiziert werden dürfen. Wird das eigene LAN als unsicher eingeschätzt, kann eine Authentifizierung nach SNMPv3 eingestellt werden. Die Steuerung erfolgt mit den Kommandos snmpusm für die Benutzer- und snmpvacm für Zugriffsrechteverwaltung. Jedoch sind Probleme mit Clients zu erwarten, welche nicht SNMPv3 beherrschen. Ohne weitere Konfiguration stellt Net-SNMP die meisten der üblichen Variablen der Standard-MIB unter Linux zur Verfügung. Abschnitt [E] erlaubt das Setzen der Standardvariablen Location- und Kontakt OID. Wer einen näheren Blick auf die unterschiedlichen MIBs werfen möchte, kann unterhalb des Verzeichnisses /usr/share/mibs/(ietf) bzw. /usr/share/snmp/mibs nachsehen. Zum Standard gehören auch die Netzwerkinformationen zu den konfigurierten Interfaces, Daten zu ARP, ICMP, TCP, jeweils inklusive der Anzahl der transferierten Pakete in verschiedenen Kategorien Parameter der Enterprise -Erweiterungen Über den Standard hinaus schafft Net-SNMP eine Schnittstelle, festzustellen, ob bestimmte Prozesse laufen. Die MIB befindet sich im Enterprises Unterbaum ( ) und wird mit der ID 2021 als UCD-SNMP-MIB eingehangen. Die Prozesstabelle wiederum findet sich unterhalb der ID 2, zusammengesetzt numerisch unterhalb In der Konfiguationsdatei wird nach dem Schlüsselwort proc das zu überwachende Programm und dann die Zahl der minimal und maximal erlaubten Instanzen eingetragen werden. Abgefragt werden kann diese Tabelle z.b. mit: snmptable target-host community welches als Ausgabe in Abhängigkeit der gezeigten Konfigurationsdatei folgendes produziert: SNMP table: enterprises.ucdavis.prtable prindex prnames prmin prmax prcount 1 automount X kdm ypbind sshd axnet rwhod cron xinetd chooser Erweiterung durch externe Skripten und Programme Abschnitt [G] beschäftigt sich mit einem speziellen, weil flexiblen Zweig des Unterbaumes enterprises.ucdavis (hier ). Hier wird dem Agenten erlaubt ein externes Skript auszuführen und das Resultat zurückzumelden. Dieser Bereich wird nicht fest vorgegeben, sondern kann vom Administrator in der Konfigurationsdatei definiert werden. Jede weitere Zeile erzeugt einen weiteren Indexeintrag in die MIB-Tabelle. snmpwalk target-host public enterprises.ucdavis.exttable.extentry.extresult

248 238 KAPITEL 16. NETZWERKÜBERWACHUNG liefert eine Ergebnisliste zurück, wobei die Ergebnisse die Shell-Variable des Rückgabewertes ($?) repräsentieren: enterprises.ucdavis.exttable.extentry.extresult.1 = 34 enterprises.ucdavis.exttable.extentry.extresult.2 = 33 enterprises.ucdavis.exttable.extentry.extresult.3 = 28 enterprises.ucdavis.exttable.extentry.extresult.4 = 0 enterprises.ucdavis.exttable.extentry.extresult.5 = 0 enterprises.ucdavis.exttable.extentry.extresult.6 = 0 enterprises.ucdavis.exttable.extentry.extresult.7 = 252 enterprises.ucdavis.exttable.extentry.extresult.8 = 253 enterprises.ucdavis.exttable.extentry.extresult.9 = 254 enterprises.ucdavis.exttable.extentry.extresult.10 = 255 enterprises.ucdavis.exttable.extentry.extresult.11 = 153 Dieses Ergebnis läßt sich auch mit dem Kommando snmpbulkget -v2c... erziehlen, wobei mit der Option -v2c eine Session nach SNMPv2c zwischen dem Client und dem Agent generiert wird. Die MIB (bzw. ein Teilzweig dieser) wurde im vorliegenden Fall dazu eingesetzt, externe Shellskripten auszuführen, welche wiederum das /proc-device des Kernels auslesen und die evtl. erhaltenen Daten über den Returnwert zurückgeben. Die Erweiterung hier dazu benutzt, Informationen des System Management Busses (SMB, spezieller Bus moderner Mainboards zur Steuerung und Überwachung von Komponenten) zu CPU-Temperatur und Drehzahl der verschiedenen Lüfter auszuwerten: Listing des Bash-Skriptes: # script for reading lm_sensor information from procfs to pass # them via net-snmp # case "$1" in *temp*) EXIT=( cat /proc/sys/dev/sensors/*/$1 2>/dev/null echo 20 ) EXIT3=${EXIT[2]} EXIT=${EXIT3%.*} if test! $EXIT ; then EXIT=25 ; fi ;; *fan*) EXIT=( cat /proc/sys/dev/sensors/*/$1 2>/dev/null echo 200 ) EXIT=${EXIT[1]} ;; esac exit $EXIT Eine Einschränkung besteht jedoch im maximalen Return-Wert, welcher 255 nicht überschreiten kann. Vorsicht ist auch geboten, wenn man versucht, temporäre Daten auf der Festplatte zwischenzuspeichern, da diese potentiellen Angreifern einen Einstieg erlauben könnten. Den Weg der Daten bis zur Anzeige im Monitoring-Tool kann man sich so veranschaulichen: 16.7 Überwachung weiterer Parameter Der anschließende Abschnitt ([H]) definiert das Verhalten eines weiteren Astes in der UCD- SNMP-MIB. Mit den Object Identifiers diesen Bereiches läßt sich der verbleibende Festspeicherplatz nach Lage im Dateisystembaum beobachten. Der Zahlenwert definiert die untere

249 16.7. ÜBERWACHUNG WEITERER PARAMETER 239 Grenze, ab der eine Warnmeldung in die Ergebnistabelle eingetragen wird. Das nächste Beispielkommando liefert die z.b. prozentuale Belegung der als Rootfilesystem gemounteten Festplatte: snmpget target-host public 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 ( ). Die Ganzzahlwerte nach dem Schlüsselwort geben die Maximalwerte an, bis zu denen kein Warneintrag analog zur Dateisystembelegung generiert wird. Die vorhergehenden Beispiele bezogen sich auf die Net-SNMP-Implementation, eine Zusammenarbeit mit anderen Komponenten ist natürlich angestrebt und klappt entsprechend. Z.B. lässt sich mit dem Befehl: dirk@linux:~/kurs> snmpset 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) Weitergehende Ergänzungen Wem die einzeilige Ausgabe nur des Rückgabewertes in Abschnitt [G] nicht genügte, findet seine Vorstellungen evtl. in [J] gelöst. Mit diesem MIB-Bereich ist es möglich mehrzeilige Ausgaben zuzulassen, die als entsprechende Tabelleneinträge zurückgeliefert werden. In der Beispielkonfigurationsdatei werden die OIDs ( ) definiert. Diese generieren verschiedene Ausgaben zur Hardwareausstattung und angemeldeten lokalen Benutzern der Maschine aus dem Aufruf von externen Programmen. Auf diese Weise kann Informationsbeschaffung auf SNMP abgebildet werden, welches dann ein Einloggen auf dem Zielsystem unnötig macht. Eine Konfigurationszeile ist so aufgebaut, dass nach dem Schlüsselwort exec die OID des Objektes angegeben wird, gefolgt vom Namen des Objekts, dem Aufruf des korrespondierenden externen Programms oder Skriptes inklusive eventueller Optionen. Eine ganze Reihe weiterer Laufzeitinformationen ließe sich auf diesem Wege beschaffen. Jedoch gibt es einige Einschränkungen bezüglich der verwendeten Datenfelder (nur Text- Felder oder Return-Codes bis zum maximalen Wert von 255 sind erlaubt), so dass nach einer Testphase (z.b. der Auswertung der Meldungen des SMB) über eine feste Einbindung als Modul nachgedacht werden sollte. Eine Anleitung, wie ein Modul für den UCD-SNMP zu schreiben ist und wie die dazugehörige MIB designt werden muss, findet sich auf der Projekt-Homepage. In der Tutorial-Sektion findet sich die Beschreibung eines Toolkits, welches das Programmieren eigener Erweiterungen mittels C erlaubt. Enthalten sind in der Schritt-für- Schrittanleitung ein Makefile, der Beispiel-Code einer SNMP-Applikation und eine Tutorial- MIB mit Headerdatei und eine C-Sourcedatei. Header und C-Source sind zum größten Teil mit mib2c erstellt worden, was einen guten Ausgangspunkt für eigene Versuche liefert. Beim Neuübersetzen des Agenten kann das experimentelle Modul eingefügt werden. Auf diesem Wege könnte der Umweg über das oben beschriebene Shellskript zugunsten einer festen Implementierung abgelöst werden. Damit würden sich weiterhin die Beschränkungen der Variablen aufheben lassen, da man deren Deklaration mittels MIB selbst in der Hand hat.

250 240 KAPITEL 16. NETZWERKÜBERWACHUNG Parameter der Host-Ressource-Erweiterungen Wurden die SNMP-Bibliotheken und der Agent mit der Unterstützung für die HOST- RESOURCES-MIB übersetzt, stehen weitere Informationen zur Verfügung. Unterhalb des Datenbaumes , 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 /22 public com2sec mynetwork /8 public # [B] Second, map the security names into group names: group MyRWGroup v1 local group MyRWGroup v2c local group MyRWGroup usm local group MyROGroup v1 mynetwork group MyROGroup v2c mynetwork group MyROGroup usm mynetwork # [C] Third, create a view for us to let the groups have rights to: view all included.1 # [D] Finally, grant the 2 groups access to the 1 view with different # write permissions: # context sec.model sec.level match read write notif access MyROGroup "" any noauth exact all none none access MyRWGroup "" any noauth exact all all none # [E] System contact information syslocation Internet-AG Universitaet Goettingen syscontact <dirk@goe.net> # [F] Process checks. proc automount 2 2 proc X 2 1 proc kdm 1 1 proc ypbind 4 1 proc sshd 10 1 proc axnet 1 0 proc rwhod 1 0 proc cron 1 0 proc xinetd 1 0 proc chooser 1 0 # [G] Executables/scripts exec sensors /bin/sh /usr/share/snmp/sensors temp1 exec sensors /bin/sh /usr/share/snmp/sensors temp2 exec sensors /bin/sh /usr/share/snmp/sensors temp3 exec sensors /bin/sh /usr/share/snmp/sensors fan1 exec sensors /bin/sh /usr/share/snmp/sensors fan2 exec sensors /bin/sh /usr/share/snmp/sensors fan3 exec empty /bin/echo 252 exec empty /bin/echo 253

251 16.8. MRTG ALS FRONTEND ZUR ANZEIGE VON ZEITREIHEN 241 exec empty /bin/echo 254 exec empty /bin/echo 255 exec user_activity /bin/sh /usr/share/snmp/uabic # [H] disk checks disk / disk /tmp # [I] load average checks load # [J] Extensible sections exec users /usr/bin/who exec pci_devices /sbin/lspci exec cpuinfo /bin/cat /proc/cpuinfo 16.8 MRTG als Frontend zur Anzeige von Zeitreihen Der Multi Router Traffic Grapher ist nun eine Anwendung, welche es ermöglicht auf Basis von SNMP Netzwerkgeräte zu überwachen. Zur Visualisierung erzeugt MRTG HTML-Code. In diesen Code werden PNG-Grafiken eingebunden, welche die Belastung einer bestimmten Einheit (Netzwerkinterface, Zahl der Benutzer, Load der Maschine) visualisieren. MRTG erzeugt diese Grafen fortlaufend mit jedem Aufruf des Programms. Das Tool basiert auf einem Perl-Skript, das das Simple Network Management Protocol (SNMP) benutzt, um die Daten von den Netzwerkkomponenten oder Endgeräten zu pollen. Ein C-Programm protokolliert die Werte mit, um erzeugt daraus Auslastungsstatistiken und Auslastunggrafen. In Ergänzung zur der detaillierten, täglichen Ansicht, erzeugt MRTG Grafen, die den Duchsatz der letzten sieben Tage, der letzten vier Wochen und der letzten zwölf Monate wiedergeben. Dies ist möglich, da MRTG allen Daten, die es aus dem Router ausließt, in eine Log-Datei schreibt. Für die Beobachtung längerer Zeiträume bietet sich eine Kombination mit dem RRD-Tool an. Dieses ist eine spezielle Datenbank, welche ihre Einträge im Round-Robin-Verfahren speichert. MRTG speichert die Informationen über die zu üeberwachenden Systeme in der Datei mrtg.cfg. In dem MRTG-Paket befindet sich ein Perl-Skript, welches das Erzeugen einer Konfigurationsdatei erheblich vereinfacht: cfgmaker. Falls man MRTG selbst übersetzt hat, findet man cfgmaker in dem Unterverzeichnis./run. Ein Aufruf zur Erzeugung der Konfigurationsdatei könnte so aussehen: cfgmaker --global WorkDir: /www/mrtg --output /etc/mrtg.cfg --global \ Options[_]: bits,growright <community>@<target-host.domain> Listing einer Beispielkonfigurationsdatei mrtg.cfg: ###################################################################### # Multi Router Traffic Grapher -- Sample Configuration File ###################################################################### # This file is for use with mrtg # Global configuration WorkDir: /var/www/mrtg WriteExpires: Yes Title[^]: Traffic Analysis for

252 242 KAPITEL 16. NETZWERKÜBERWACHUNG # 2048kBit leased line # #Title[leased]: a 2048kBit leased line #PageTop[leased]: <H1>Our 2048kBit link to the rest of the internet</h1> #Target[leased]: 1:public@router.my.domain #MaxBytes[leased]: Einige abschließende Worte zu SNMP Während SNMP recht einfach und flexibel einzusetzen ist, hat es jedoch auch einige Nachteile. Das Sicherheitsmodell der Version 1 und 2 ist schwach. Verwendet man SNMP zum Setzen von Variablen kann leicht etwas schief gehen, so dass man z.b. den Switchport abschaltet über den man mit dem Netzwerk verbunden ist. Schwierig wird es auch aufkommende objektorientierte Ansätze, wie die Beschreibung mittels XML in SNMP umzusetzen. SNMP war lange Zeit die Spezialität weniger Netzwerkadministratoren und Programmierer, so dass das Wissen darüber immer noch nicht sehr weit verbreitet ist. Inzwischen wurde die erdrückende Vormacht der Kommandozeile durch eine Reihe grafischer Erweiterungen aufgelöst, so dass auch SNMP-Neulingen ein zügiger Einstieg gelingen kann. Trotz der genannten Probleme ist SNMP aus Sicht des Autors das beste Protokoll zur Netzwerküberwachung. Es ist universal, bandbreitenschonend und wirklich plattform unabhängig. Die Hersteller von Netzwerkkomponenten setzen weiterhin auf SNMP, alle neuen Gerätetypen die herauskommen, wie z.b. Access-Points für Wireless LAN, verfügen über eine entsprechende Schnittstelle. SNMP in der dritten Version, wie es vor einiger Zeit spezifiziert wurde, erlaubt bessere Authentifizierungsverfahren und Verschlüsselung der Daten. Darüberhinaus ist es mittels Modularisierung über Sub-Agenten flexibler geworden. Die Popularität von Linux und die inzwischen mit Net-SNMP und anderen frei zur Verfügung stehenden Implementationen haben ihren Betrag zur Verbreitung von SNMP erbracht. Alle großen Linux Distributionen enthalten eine ganze Reihe von SNMP Software, mit der sich viele anstehende Probleme bereits lösen lassen. Ein attraktives Tool zur Visualisierung spezieller SNMP-Variablen, wie die Auslastung eines Endgerätes oder einzelner Schnittstellen von Netzwerkknoten, wurde mit MRTG bereits vorgestellt. NetSaint, welches neben anderen Überwachungsfunktionen SNMP zum Sammeln der Daten einbezieht, soll im zweiten Teil dieses Artikels besprochen werden Weiterführende Literatur [1] Homepage des Net-SNMP: [2] Scotty-SNMP-Bibliothek: schoenw/scotty [3] MRTG-Homepage: [4] Projektbericht zur Überwachung großer Netzwerke an der Universität Göttingen - dsuchod/dgsvgr [5] Cheops der Klassiker: [6] Cheops Next-Generation: [7] MIB-Browser: [8] Douglas E. Comer, TCP/IP

253 WEITERFÜHRENDE LITERATUR 243 OID Datentyp Beschreibung Standard-OIDs (MIB- II) system.sysdescr text Geräteinformation: Hersteller, Name des Modells, Version der SOftware o.ä. system.syslocation text Aufstellungsort des Gerätes system.sysuptime int Millisekunden seit dem Start des Agenten system.syscontact text Kontakt zum Admin des Gerätes system.sysname text Name der Maschine; üblicherweise der DNS- Name interfaces.ifnumber int Zahl der vorhandenen Netzwerkschnittstellen interfaces.iftable table Array der verschiedenen Infos pro Schnittstelle (Name, Typ, Geschwindigkeit, MTU) at.attable table ARP-Tabelle ip.ipforwarding int Bei Geräten mit mehreren Interfaces: 1, falls IP-Forwarding stattfindet, sonst 2 ip.ipaddrtable table IP-Informationen der versch. Interfaces (Broadcast-, Routeradressen, Netzmasken und Metrik) icmp.* int Eine Menge von ICMP-Statistiken tcp.tcpconntable table Liste der bestehenden TCP-Verbindungen mit Status udp.udptable table Liste der offenen UDP-Sockets snmp.* int Eine Menge von SNMP-Statistiken OIDs der UCD-SNMP- MIB prtable.* table Tabelle der auf minimal und maximal laufende Instanzen zu überwachende Prozesse memory.memtotalreal int Menge des zur Verfügung stehenden Arbeitsspeichers exttable.* table Ausbaubare Spezial-MIB zur Ausführung von Programmen und Skripten latable.* int Load Average Werte (1, 5, 15 Minuten Intervall) systemstats.* int Eine Menge systemspezifischer Variablen und Maximalwerte ucdexperimental.* Eintrag für die später beschriebene eigene MIB-Erweiterung Tabelle 16.2: Beispieldaten (OIDs) der Standard-MIBs

254 244 KAPITEL 16. NETZWERKÜBERWACHUNG Kommando get-request get-nextrequest get-bulkrequest response set-request inform-request trap Bedeutung Ermittele den Wert einer bestimmten Variablen Ermittele den Wert der nächsten Variablen ohne ihren genauen Namen zu kennen Ermittele einen Block von Variablen (z.b. Tabellen) Anwort auf o.g. Requests Speichere einen bestimmten Wert in eine Variable Referenz zu weiteren z.b. Proxy-Daten Antwort, ausgelöst durch einen Event-Trigger Tabelle 16.3: Das SNMP-Kommando-Set OID hrsystem hrstorage hrdevice hrswrun hrswrunperf hrswinstalled Bedeutung Zahl der laufenden Prozesse und angemeldeten Benutzer Speicher der verschiedensten Form, wie Real Memory, Swap, Memory Buffers Liste verfügbarer Geräte, wie Drucker, Prozessor, Mainboardchipset Liste der laufenden Prozesse (wie ps ) CPU-Verbrauch der laufenden Prozesse Liste der installierten RPM-Pakete (setzt ein System auf Basis des Redhat-Package-Managers voraus) mit Installationsdatum Tabelle 16.4: Variablen der Host-MIB

255 Kapitel 17 Systemsicherheit 17.1 Generelle Überlegungen Sichere Rechner bzw. Betriebssysteme kann es nicht geben. Diese werden von Menschen geschaffen und die Ideen zur Sicherheit werden meistens durch Bequemlichkeit, Unaufmerksamkeit oder Schlampigkeit wieder ausgehebelt. Weiterhin möchte kein Administrator Tag und Nacht vor einer Maschine hocken und nachsehen, was die Benutzer, Services (Dienstprogramme) und die verschiedenen Prozesse so treiben. Generell gibt es zwei Sicherheitsbereiche, die man unterscheiden kann: Die (physikalische) Sicherheit der Maschine selbst und Angriffsmöglichkeiten aus dem Netzwerk bzw. Internet. Eine weitere Möglichkeit sich aktiv gegen Angreifer aus dem Netz zu schützen und auch nur bestimmte Kanäle aus dem eigenen Netz zuzulassen, ist das Aufsetzen einer Firewall ( Schutzwand ); vgl. Kap Sicherheit auf dem Rechner Einleitung Ein Angriff eines Hackers war bereits im ersten Schritt erfolgreich, wenn er sich unerlaubt als ganz normaler Benutzer Zugriff auf einer Maschine verschaffen konnte. Dann sind seine Rechte schon weit höher als wenn er noch von aussen versuchen muss, auf das Gerät einzudringen. Deshalb sollte es immer Politik bei der Vergabe von Dateirechten geben, normalen Systembenutzern immer gerade soviele Rechte einzuräumen, wie sie zum Arbeiten benötigen. Deshalb laufen inzwischen auch viele Dienste, wie z.b. der Nameserver Bind (Daemon: named) oder der X-Displaymanager gdm unter einer eigenen BenutzerID und nicht mehr mit Rootrechten. So bedeutet ein erfolgreicher Einbruch in diese Dienste noch nicht eine automatische Übernahme der Maschine Passwörter Das Passwort sollte nicht trivial sein! Worte, die in einem Lexikon zu finden sind, haben als Passwort keinen Wert. Knackprogramme benutzen genau solche Lexika, um bekannte Worte vorwärts, rückwärts und in Kombinationen durchzuprobieren. Der Einwand man habe keine schützenswerte Daten in seinem Account und müsse darum nicht so viel Aufwand treiben ist vordergründig verständlich, aber dennoch nicht richtig. In einem Beispiel versteht man es besser: Möglicherweise hat ein Mieter in einem 245

256 246 KAPITEL 17. SYSTEMSICHERHEIT Mietshaus tatsächlich keine Wertgegenstände, die ihm schützenswert erscheinen, doch es ist nicht akzeptabel, dass er darum die Haustüre offen stehen läßt und damit das Eigentum der Mitbewohner gefährdet. Obendrein, wenn die Bude abbrennt, wird auch dieser Mieter gewahr, dass das Gebäude, sein Dach über dem Kopf, doch ein schützenswertes Objekt darstellt. Um im Bild zu bleiben, auch die Weitergabe von Schlüsseln (Passwörtern) an Dritte ist in diesem Rahmen nicht akzeptabel! Deshalb genügt es auch nicht, wenn das Rootpasswort besonders sicher ist. Bereits mit den Rechten eines normalen Benutzers hat man mehr Möglichkeiten des Einbruchs als mit gar keinem Account auf einer Maschine. Die Konfiguration zur Passwortsicherheit (Gültigkeitsdauer von User-Passwörtern, Fehlversuche beim Login, Länge des Passwortes) werden in der Datei /etc/login.defs eingestellt Der Admin-Account Den Account des Administrators root nur so lange verwenden, wie unbedingt notwendig, z.b. für die Installation von Software, die allen Benutzern zur Verfügung gestellt werden soll. Keinesfalls als root die tägliche Arbeit machen. Dafür existieren die gewöhnlichen Benutzeraccounts, deren Rechte für die Standardaufgabenstellungen ausreichen. Administrative Aufgaben sollten niemals müde oder in Eile ausgeführt werden, da mit root -Rechten leicht irreversible Schäden angerichet werden können /etc/passwd und /etc/shadow Ein System sollte das Passwort der Benutzer unbedingt nicht in /etc/passwd speichern! Die Datei /etc/passwd ist für die Welt lesbar und muss es auch sein, damit der eine oder andere Dienst funktioniert. Das Problem dabei ist, dass somit jeder mit einem Cracker bewaffnet auf Passwortsuche gehen kann, solange die Passwörter in dieser Datei stehen. Es leuchtet ein, dass ein Passwort, das in einer Datei steht, die nur root lesen kann, diese Hintertüre schließt. Also: Shadow-Passwort (in /etc/shadow) benutzen! Locken oder ausloggen Aus demselben Grund wie zuvor, ist beim Verlassen einer Maschine darauf zu achten, dass man bei allen Konsolen ausgeloggt ist oder diese gelockt hat. Arbeiten mehrere Leute an der Konsole, dann sollte man so nett sein und die Sitzung beenden (und nicht nur den Bildschirm sperren) Setuid und Verzeichnisse Es ist darauf zu achten, dass normale Benutzer in System-Verzeichnissen wie /etc, /bin, /usr/bin, /sbin usw. keine Schreibberechtigung besitzen. Sollten sie es doch haben, so können sie dort ein Programm unterbringen (z.b. Verschreiber zu ls oder cd (ls-al ld la ks xs vf...)). Das Programm wartet, bis es einmal ausversehen von root aufgerufen wird... und Voila! Es wird ein Programm z.b. mit dem Namen gainr nach /tmp, /var/tmp oder sonst wo hin geschrieben, das nichts anderes als eine Shell mit setuid ROOT ist. Ruft man dann als normaler Benutzer gainr auf, so ist man plötzlich root - ganz ohne Passwort. Erste Konsequenz: Ein normaler Benutzer soll NUR Zugriff auf sein Home-Verzeichnis und auf /tmp haben! Zweite Konsequenz: Die Variable PATH des Benutzers root muss restriktiv gehalten werden. Das aktuelle Arbeitsverzeichnis hat im PATH von root nichts verloren! Dritte Konsequenz: Die Liste der setuid root (-rwsr-xr-x) Programme regelmäßig mit der Frage nach Wachstum kontrollieren.

257 17.3. LITERATUR Setuid und Mounting Mit dem Mounten ist es genauso, nur noch einfacher für den Hacker. Ein wechselbares Medium darf nie und nimmer setuid-fähig sein! Ansonsten stellt sich der Hacker zuhause ein Medium her mit einer Shell, die root gehört und das setuid-bit gesetzt hat (vergl. gainr. Dieses mountet er im Zielsystem (oder läßt es vom Admin mounten...) und...voila! Einfach aufrufen und fertig! Das Mountkommando kann aus Sicherheitsgründen nur vom Superuser aufgerufen werden. Sollen normale User dazu in die Lage versetzt werden, ist die /etc/fstab bzw. die Konfiguration des Automounters anzupassen. Dann sollte man darauf achten, dass für diese Bereiche keine Ausführungsrechte für Programme gesetzt werden (Option: noexec) Browser, CGI / Java-Applet und Binaries, per Mail Grundsätzlich sind alle Programme, die über einen grauen Kanal von außen kommen, als hoch gefährlich einzustufen. Ein Binary, das per Mail kommt und zur Ausführung gebracht wird, kann alles enthalten, wovor sich der Admin in schlimmsten Fieberträumen fürchtet. Auch ein Java-skript kann im Prinzip tun was es will, auch die Datensicherheit korrumpieren. Ein einfaches CGI-Skript einer Suchmaschine ist ein echtes Risiko. Wie in der CT 4 98 beschrieben, reicht es aus, ein Semikolon gefolgt von einem subversiven Befehl als Suchbegriff einzugeben und schon steht da anstelle eines grep-parameters ein falsch abgesetzter grep-befehl gefolgt von einem Befehl frei nach Hackers Wahl. Auf Grund der Vielzahl von Schwachstellen und Programmierfehlern sollten Web-Browser an sich für den User root tabu sein und nur unter der ID normaler User ausgeführt werden!! Physikalischer Zugriff Derjenige, der physikalischen Zugriff zu einer Maschine hat, ist eigentlich auch schon root! Das liegt daran, dass die Konsole zugreifbar ist. Um es nicht ganz so einfach zu machen, sollten bootfähige und wechselbare Laufwerke (z.b. floppy) von der Boot-Fähigkeit abgehalten werden. Der Durchschnitts-Hacker braucht aber diese Laufwerke ohnehin nicht. Dieser ist mit einer Reset-Taste oder einem Netzstecker, sowie einer Konsole vollkommen zufrieden. Der lilo ohne Passwortschutz erlaubt einfachste Angriffe! Abhilfe: Die Maschine unter Verschluss halten. Keiner Maschine, die nicht unter Verschluss ist oder mit dem Internet verbunden ist, kann man vertrauen Literatur Einschlägige Mailing-Listen abonnieren und Webseiten untersuchen THE DENIAL OF SERVICE PAGE Linux-Mailinglisten Monografien gibt es inzwischen auch einige zum Thema... z.b.: Simson Garfinkel, Gene Spafford, Practical Unix and Internet Security 2.Edition, O Reilly, 2000, ISBN

258 248 KAPITEL 17. SYSTEMSICHERHEIT 17.4 Sicherheit im Netzwerk Einleitung Die erste Hürde, die sich Angreifern stellt, ist üblicherweise der lokale Zugang auf ein System. Dazu benötigen sie meistens eine gültige UserID mit Passwort bzw. den Zugriff über einen auf der Maschine verfügbaren Netzwerkdienst, wie den Web-, NFS-, Nameserver etc. Dieser Zugriff kann durch das ablauschen von Verbindungen, wie z.b. telnet, ftp, pop3,... Anfragen erfolgen, die keine verschlüsselten Passwörter verwenden. Die andere Möglichkeit ist die Ausnutzung von Sicherheitslücken in verfügbaren Diensten. Deshalb sollten beim Aufsetzen eines Servers immer überlegt werden, welche Dienste überhaupt notwendig sind und aus welchem Bereich der Zugriff erfolgen können soll. So wird z.b. der Webserver weltweit erreichbar sein, das Login, NFS, bzw. Samba für den Zugriff der Webadministratoren meistens jedoch nur aus einem beschränkten Netzwerkbereich erforderlich sein Gesicherte Verbindungen Das Internet-Protokoll IP und die Transportprotokolle UDP und TCP bringen keinerlei Sicherheit mit. Die Pakete können auf dem Transportweg verfälscht und der Inhalt leicht abgelauscht werden. Hiergegen sind Vorkehrungen zu treffen, die an verschiedenen Stellen der Verbindung ansetzen können: Host 1 Sicherung Host2 Anwendung S-HTTP, PGP, ecash Anwendung Transport SOCKS, SSL Transport Netzwerk IPSec Netzwerk Datensicherung PAP, CHAP, PPTP Datensicherung Tabelle 17.1: Verschiedener Ansatz von Absicherung Bekannt sind inzwischen sicherlich die Kryptosoftware zum Mailversand, PGP und der Telnetersatz SSH. Diese setzen an der Anwendungsschicht an. Die Absicherung der Transportschicht kann durch SSL (Secure Sockets Layer) erfolgen, was von verschlüsselten HTTP- Verbindungen bekannt sein sollte. IPSec setzt an der Netzwerkschicht an und soll zum einen die Herkunft der Pakete sicherstellen und zum Anderen das Mitlesen der Daten verhindern und diese vor unerkannter Manipulation schützen. Ausführliche Erläuterungen zu IPsec erfolgen im nächsten Kapitel ssh und scp Es ist immer damit zu rechnen, dass irgendwo hinter den nächsten beiden Ecken ein Hacker sein Laptop genau in das Netz-Segment eingeklinkt hat, in dem man sich befindet. Die Folge davon ist, dass alles, was man Klartext über das Netz schickt oder was man geschickt bekommt, mitgelesen werden kann. Das betrifft TCP genau so wie UDP! Der Hacker muss also nur warten, bis sich irgend ein Benutzer auf einer anderen Maschine einloggt (telnet, pine, ftp...) und dann genau die folgenden Pakete dieser beiden Maschinen mitprotokollieren. In der Folge erhält er einen Account-Namen und ein Passwort, das dazu paßt.... Abhilfe schafft man hier durch Verwendung der ssh (SecureShell) und SecureCopy scp zum Kopieren von Dateien über Rechnergrenzen hinweg. Damit baut man einen verschlüsselten

259 17.4. SICHERHEIT IM NETZWERK 249 Kanal zwischen zwei Rechnern auf: > ssh > ssh -l dirk s1.goe.net > ssh -l dirk s1.goe.net Netscape Auch wenn man dann X-Anwendungen startet, benutzen diese den verschlüsselten Kanal (Hier spart man sich sogar gegenüber telnet das Setzen der DISPLAY-Variablen). Das Setzen von Umgebungsvariablen wird im Abschnitt zur Shell erörtert. Im letzten der Beispiele, die oben gezeigt wurden, hat man sich nicht mehr auf der Maschine eingeloggt, sondern nur noch ein Kommando abgesetzt, welches remote ausgeführt wird. Möchte man sich regelmässig auf verschiedenen Rechnern einloggen und nicht jedesmal sein Passwort für diese Verbindung angeben, kann man einen Schlüssel auf dem entsprechenden Rechner generieren und den Public-Teil in der Datei: /.ssh/authorized keys (im Homeverzeichnis unterhalb des versteckten Verzechnisses.ssh) speichern. > ssh-keygen -t dsa Mit dem Tool ssh-agent kann man sich das Leben noch erleichtern: Dieser fragt zu begin einer Sitzung die Passphrase für die gesammelten Schlüssel ab und authentifiziert jede bereits einmal aufgebaute Verbindung automatisch ohne weitere Nachfrage Der Intenet- Super -Daemon (x)inetd Viele Dienste, die nicht sehr häufig nachgefragt werden, wie z.b. telnet, talk und ftp müssen nicht permanent im Hintergrund laufen und die CPU, sowie den Arbeitsspeicher belasten. Sie werden auf Anforderung durch den (x)inetd gestartet und nach Beendigung der Verbindung wieder geschlossen. Der xinetd stellt die weiterentwickelte Form des inetd dar und kann die oben genannte Forderung nach der Beschränkung des Zugriffs von sich aus erfüllen. In der Konfigurationsdatei des Dienstes der /etc/xinetd.conf können Bereiche angegeben werden, von denen der Zugriff auf einen bestimmten Dienst erlaubt wird: service ftp { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/proftpd server_args = -p 0 only_from = /16 } Der inetd benötigt hierzu noch den TCP-Wrapper tcpd, welcher über die Dateien /etc/hosts.deny und /etc/hosts.allow gesteuert wird. Generell gilt natürlich, dass alle Dienste, die nicht benötigt werden, auf jeden Fall deaktiviert werden sollten. Gerade diese bergen häufig die Gefahr, dass (weil man nicht an sie denkt) hierüber der erfolgreiche Angriff stattfindet.

260 250 KAPITEL 17. SYSTEMSICHERHEIT xhost + und das unsichtbare Fenster Mit xhost + serviert man potentiellen Einbrechern die gewünschten Informationen auf einem goldenen Tablett! Das einzige, was der Hacker zu tun hat, ist ein unsichtbares Fenster auf dem Bildschirm zu platzieren. Dieses bekommt natürlich, weil es zu oberst liegt, alle Informationen von Maus und Keyboard exklusiv. Je nach Gutdünken des Hackers werden diese Informationen an die Fenster, an die sie eigentlich gerichtet sind, weitergeleitet oder eben auch nicht. Der Hacker kann alles mitprotokollieren oder das keyboard/maus toten Mann spielen lassen oder alles andere, was das Herz begehrt, mit dem Bildschirm anstellen. Ein Login-Bildschirm über Nacht auf s Display gezaubert, bringt am nächsten Morgen ein sicheres Passwort rhosts Es ist grundsätzlich abzulehnen, den eigenen Account gegenüber einem Benutzer zu öffnen, der behauptet, sich auf einer Maschine zu befinden, die ihrerseits behauptet, einen bestimmten Namen zu tragen. Man sieht schon jetzt wie fragil das Konstrukt ist... Jeder kann irgendetwas behaupten, aber darum ist demjenigen noch kein Account zu öffnen. Das Konzept der R-Tools (Steuerung über die.rhosts im eigenen Homeverzeichnis) wie sie einmal von Sun eingeführt wurden, ist in der heutigen Zeit obsolet geworden. Dazu gibt es SecureShell und -Copy und den SSH-Agent, wenn man vermeiden will, bei jedem Login auf einer anderen Maschine immer wieder ein Passwort eingeben zu müssen Überprüfung der Netzwerksicherheit eigener und anderer Rechner Es gibt inzwischen eine ganze Reihe von Programmen, mit denen sich der Netzwerkverkehr überwachen und überprüfen lässt. Dieses sind zum einen die Tools zum Mitlauschen des Datenverkehrs tcpdump, ntop und ethereal. Gerade das letzte Tool ist besonders zu empfehlen, da es über ein komfortables grafisches Frontend, gute Packetviewer und Filterfunktionen verfügt. ntop ist ein textbasiertes interaktives Programm, welches aktuelle Verbindungen und die dabei umgesetzten Datenmengen nach Verbindung und Protokollart aufzeigt. tcpdump arbeitet an der Kommandozeile und schneidet Pakete mit, welche an der Netzwerkschnittstelle angenommen werden. Bei allen Tools lassen sich auch Nicht-IP- Protokolle registrieren. Die Untersuchung auf bestimmte Dienste, d.h. offene Ports von Rechnern oder in Netzwerken, lässt sich mit dem Portsniffer nmap bewerkstelligen. nmap -O /16 nmap -sp /24 nmap -st nmap -su Feststellen des Betriebssystems im Class-B-Subnetz Ping-Scan (Erreichbarkeit von Rechnern Class-C-Subnetz Scan auf offene TCP-Ports der Maschine mit der IP Scan auf offene UDP-Ports der Maschine mit dem FQDN Tabelle 17.2: NMAP im Einsatz

261 17.5. AUFGABEN Firewall Inzwischen gibt es drei Firewallimplementationen für den Linuxkernel: Das ipfwadm führte diese Funktionalität in den 2.0.er Kernel als ein wichtiges neues Feature ein. Die Firewallingfähigkeit wurde mit ipchains im Kernel der 2.2.er Serie stark verbessert und wird deshalb in einem eigenen Kapitel beschrieben. Der Kernel 2.4 bringt eine weiter verbesserte Firewall mit netfilter mit sich, ist aber abwärtskompatibel über Kernelmodule zu ipfwadm und ipchains Aufgaben Secure Shell 1. Wie sieht das Kommando aus, wenn man sich auf eine entferne Maschine (Remote- Login) mit dem Rechnernamen test.domain.local verbinden will und man die Benutzer- ID userid auf der entfernten Maschine verwenden will und unter einer anderen ID auf der Ausgangsmaschine angemeldet ist? 2. Wie könnte der SCP-Kopierbefehl aussehen, wenn eine Datei namens unterlagen.txt vom Rechner test.domain.local unter der UserID root in das lokale Verzeichnis auf dem eigenen Rechner kopiert werden soll? 3. Welches Problem liegt vor, wenn ich folgende Meldung zu sehen bekomme? ssh : WARNING: REMOTE HOST IDENTIFICATION HAS 8014: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 8014: Someone could be eavesdropping on you right now (man-in-the-middle attack)! 8014: It is also possible that the RSA host key has just been changed. 8014: The fingerprint for the RSA key sent by the remote host is 53:8c:4b:13:f6:df:2e:d1:e5:cf:21:12:a4:c2:ea:c : Please contact your system administrator. 8014: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. 8014: Offending key in /home/user/.ssh/known_hosts: : RSA host key for has changed and you have requested strict checking. 8014: Host key verification failed. 4. Wie kann ich mich auf anderen Maschinen per SSH unter Vermeidung der Eingabe eines Passwortes anmelden? Wann benötigt man dieses? 5. Wie tunnele ich eine POP3-Verbindung (Port 143) von meiner Maschine (z.b. mymachine.dyndns.org) auf den POP3-Server (z.b. pop3.mydomain.local), wo ich über einen SSH-Zugang verfüge?

262 252 KAPITEL 17. SYSTEMSICHERHEIT

263 Kapitel 18 Sicheres IP 18.1 Sicherheitsprobleme des derzeitigen IP-Standards Intro Die Idee und erste Implementationen des Internet Protokolls gehen auf die Anfänge der 70er Jahre zurück. Sicherheitserwägungen spielten bei der Entwicklung des IP zu begin nur eine nachrangige Rolle bzw. wurde bewußt auf höhere Protokollschichten verlagert. Die Datenpakete, in die Datenströme aufgeteilt werden, passieren auf ihrem Weg zwischen Sender und Empfänger eine ganze Reihe von Routern. Der Weg selbst ist in den meisten Fällen nicht vorherbestimmt (von besonderen Ausnahmen einmal abgesehen). So können Pakete, obwohl sie zwischen Partnern innerhalb einer Stadt ausgetauscht werden, durchaus mehrfach Landesgrenzen überschreiten. An der Weiterleitung dieser Datenströme sind dann meistens mehrere Provider beteiligt, die über sehr unterschiedliches Know-How und Sicherheitsvorstellungen verfügen können Offener Datentransport Für den Transport von Daten in einem Netzwerk, d.h. eine Kommunikation zwischen zwei Rechnern A und B, benötigt man offene und gemeinsame Standards, damit eine Verbindung zustande kommen kann. Hierfür reicht es aus, dass jeweils die Datenheader der verwendeten Protokolle genormt und für alle am Transport Beteiligten interpretierbar sind. Da Empfänger und Absender nicht direkt miteinander kommunizieren, sondern ihre Pakete nur an den nächsten Router (meistens einfach an das Default-Gateway) ausliefern, lassen sich Aussagen über die Authentizität und die Richtigkeit des Inhaltes von Paketen nicht machen. Für erfahrene Anwender bzw. Benutzer einschlägiger Programme ist es überhaupt kein Problem IP-Pakete mitzulesen (z.b. dsniff, ethereal,...). Dieses kann bereits im eigenen LAN geschehen. Jedoch kann auch jede Maschine auf dem Weg der Datenpakete diese mitlesen. Beides läßt sich in den seltensten Fällen feststellen. Selbst wenn Pakete auf ihrer Reise verändert werden, kann man dies nicht einfach feststellen, da die Prüfsummen von IP- und TCP-Header natürlich auch vom Fälscher korrekt eingetragen werden. Genausowenig läßt sich feststellen, ob der Absender wirklich der erwartete Kommunikationspartner ist oder ob sich der Man-in-the-Middle eingeschaltet hat. Viele Benutzer werden sicherlich sagen, dass andere mit ihren Daten nichts anfangen können und dass sie nicht relevant sind. Trotzdem möchte man sicherlich nicht, dass jemand seine Mailbox bei einem Webmailer ausräumt oder Mails unter dem eigenen Namen verschickt. Wenn vielleicht mit einer einfachen Mailadresse noch keine kostenpflichtigen Dienste aufgerufen werden können, so lassen sich doch Mails mit sehr üblen Inhalten ver- 253

264 254 KAPITEL 18. SICHERES IP Abbildung 18.1: Snapshot einer Ethereal-Analyse fassen, die den oder die AccountinhaberIn in Schwierigkeiten bringen können. Oder aber jemand verwendet mitgehörte Ebay-Daten dazu, Gebote auf eigene Artikel zu platzieren. Das folgende Listing zeigt einen Ausschnitt einer Google-Sitzung; viele Informationen kann man sofort und ohne großen Aufwand direkt entnehmen. b a 11 df 06 9c d f f 71 3d ).GET /search?q= b b 65 2b b 6d 65 wie+hacke+ich+me e 2b 6e a d f 2d 38 in+netz&ie=iso d c 3d d &hl=de&meta d f 31 2e 31 0d 0a = HTTP/1.1..User d e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f -Agent:Mozilla/ 00a0 35 2e f 6d c 65 3b 5.0 (compatible; 00b0 20 4b 6f 6e f 72 2f 33 3b 20 4c 69 Konqueror/3; Li 00c0 6e d 0a a nux)..referer: h 00d a 2f 2f e 67 6f 6f 67 6c 65 ttp:// 00e0 2e f 0d 0a a de/..Accept: te 00f f 2a 2c d f 6a xt/*, image/jpeg c d f 70 6e 67 2c d 61, image/ png,ima f 2a 2c 20 2a 2f 2a 0d 0a ge/*, */*..Accep d 45 6e 63 6f e 67 3a d 67 7a t-encodi ng:x-gz c a c e ip, gzip,identi d 0a d ty..accept-chars a f 2d d 31 2c 20 et: iso , d 38 3b 71 3d 30 2e 35 2c 20 2a 3b 71 utf-8;q= 0.5,*;q d 30 2e 35 0d 0a d 4c 61 6e =0.5..Accept-Lan