Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 1
Einführung in das Arbeiten mit Netzwerken

Historisches

Die Idee des Netzwerkes ist wahrscheinlich so alt wie die Telekommunikation selbst. Denken Sie an die Menschen, die in der Steinzeit gelebt haben, als Trommeln verwendet wurden, um Nachrichten auszutauschen. Stellen Sie sich vor, Höhlenmensch A möchte Höhlenmensch B einladen, sich gegenseitig mit Steinen zu bewerfen. Leider leben die beiden zu weit voneinander entfernt, als daß B hören könnte, was A trommelt. Welche Möglichkeiten hat A nun? Er kann 1. zu B hinübergehen, 2. sich eine größere Trommel besorgen oder 3. C bitten, der auf halber Strecke zwischen A und B wohnt, die Nachricht weiterzuleiten. Die letzte Möglichkeit wird Netzwerk genannt.

Natürlich haben die Geräte und Hilfsmittel unserer Vorfahren eine ziemliche Entwicklung durchgemacht. Heute unterhalten sich Computer über riesige Kabelstränge, Glasfasern, Mikrowellen und ähnliches, damit wir uns für das samstägliche Fußballspiel verabreden können.(1) In der folgenden Beschreibung wollen wir uns damit befassen, mit welchen Mitteln und auf welchen Wegen dies erreicht wird. Dabei lassen wir den Teil mit den Kabeln ebenso weg wie den mit dem Fußball.

In diesem Buch werden wir zwei verschiedene Arten von Netzwerken beschreiben: solche, die auf UUCP, und solche, die auf TCP/IP basieren. Dabei handelt es sich um Protokoll- und Softwarepakete, die die Mittel zum Datentransport zwischen zwei Computern zur Verfügung stellen. In diesem Kapitel sehen wir uns beide Netzwerkarten an und erläutern die zugrundeliegenden Prinzipien.

Wir definieren ein Netzwerk als eine Reihe von Hosts, die in der Lage sind, miteinander zu kommunizieren. Häufig sind diese Rechner von den Diensten einer Reihe von dedizierten Hosts abhängig, die Daten zwischen den Teilnehmern übertragen. Hosts sind häufig Computer, müssen es aber nicht unbedingt sein. Auch X-Terminals oder intelligente Drucker können Hosts sein. Ansammlungen von Hosts werden auch Sites genannt.

Kommunikation ist ohne so etwas wie eine Sprache oder einen Kode nicht möglich. In Computernetzwerken werden diese »Sprachen« kollektiv als Protokolle bezeichnet. Nun sollten Sie dabei nicht an geschriebene Protokolle denken, sondern vielmehr an eine sehr formalisierte Art des Verhaltens, wie sie beispielsweise bei Staatsempfängen zu beobachten ist. In ähnlicher Weise sind auch die in Computernetzwerken verwendeten Protokolle nichts anderes als sehr strenge Regeln für den Austausch von Nachrichten zwischen zwei oder mehreren Computern.

UUCP-Netzwerke

UUCP ist die Abkürzung für »UNIX to UNIX Copy«. Es begann als Programmpaket zur Übertragung von Dateien über serielle Leitungen, zur Steuerung dieser Transfers und zur Ausführung von Programmen auf entfernten (remote) Sites. Seit seiner ersten Implementierung in den späten siebziger Jahren hat das System viele, auch schwerwiegende, Änderungen erfahren, dennoch sind die angebotenen Dienste eher spartanisch. Das Haupteinsatzgebiet liegt nach wie vor bei Wide-Area-Netzwerken, die auf Telefon-Wählleitungen basieren.

UUCP wurde 1977 zuerst von den Bell Laboratories für die Kommunikation zwischen deren UNIX-Entwicklungs-Sites entworfen. Mitte 1978 verband dieses Netzwerk bereits über 80 Sites. An Anwendungen bot es hauptsächlich E-Mail und Weiterleitungen von Druckaufträgen, allerdings lag die Hauptaufgabe des Systems im Verteilen neuer Software und Bugfixes. Heutzutage ist UUCP nicht mehr nur auf die UNIX-Umgebung beschränkt. Es existieren sowohl freie als auch kommerzielle Portierungen für eine ganze Reihe unterschiedlicher Plattformen wie AmigaOS, DOS, TOS, etc.

Einer der großen Nachteile von UUCP-Netzwerken ist die geringe Bandbreite. Auf der einen Seite schränken die Telefoneinrichtungen die maximale Übertragungsrate stark ein. Andererseits arbeiten UUCP-Links selten mit permanenten Verbindungen, statt dessen rufen sich die Hosts in regelmäßigen Intervallen über Wählleitungen an. Daher verbringt eine Nachricht, die über ein UUCP-Netz verschickt wird, die meiste Zeit damit, auf der Festplatte eines Host herumzuliegen und darauf zu warten, daß wieder eine Verbindung hergestellt wird.

Trotz dieser Einschränkungen gibt es immer noch viele UUCP-Netzwerke, die die ganze Welt umspannen. Betrieben werden sie meistens von Hobbyisten, die privaten Benutzern Netzwerkzugänge zu vernünftigen Preisen anbieten. Der Hauptgrund für die Beliebtheit von UUCP liegt sicher darin, daß es, im Vergleich zum Internet, so spottbillig ist. (Das ändert sich gerade ...) Um Ihren Computer in einen UUCP-Knoten zu verwandeln, benötigen Sie nur ein Modem, eine funktionierende UUCP-Implementierung und einen weiteren UUCP-Knoten, der bereit ist, Sie mit Mail und News zu versorgen.

Wie UUCP benutzt wird

Die UUCP zugrundeliegende Idee ist ziemlich einfach: Wie der Name es andeutet, werden grundsätzlich Dateien von einem Host auf den anderen kopiert. Sie können damit aber auch verschiedene Aktionen auf einem entfernten (»remote«) Host durchführen.

Stellen Sie sich vor, daß Ihre Maschine auf einen Host, nennen wir ihn einfach mal swim, zugreifen darf und dort den lpr-Befehl für Sie ausführen soll. Mit dem folgenden Befehl könnten Sie dieses Buch auf swim ausdrucken:(2)

$ uux -r swim!lpr !netguide.dvi

Mit uux, einem Befehl aus dem UUCP-Paket, wird ein Job auf swim initiiert. Der Job besteht aus der Eingabedatei netguide.dvi und der Anforderung, diese Datei an den lpr-Befehl zu übergeben. Mit der Option -r weisen Sie uux an, das entfernte System nicht direkt anzusprechen, sondern den Job zwischenzuspeichern, bis eine Verbindung hergestellt wurde. Diese Technik wird Spooling genannt.

UUCP erlaubt auch die Weiterleitung von Jobs und Dateien über mehrere Hosts hinweg, vorausgesetzt, daß diese kooperieren. Stellen Sie sich vor, daß swim über einen UUCP-Link zu groucho verfügt, der ein großes Archiv mit UNIX-Anwendungen zur Verfügung stellt. Um die Datei tripwire-1.0.tar.gz auf Ihre Site herunterzuladen, müssen Sie den folgenden Befehl eingeben:

$ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz

Der erzeugte Job weist swim an, die Datei von groucho herunterzuladen und an Ihre Site zu übersenden, wo sie von UUCP in der Datei trip.tgz abgelegt wird. Gleichzeitig werden Sie über Mail benachrichtigt, daß die Datei eingetroffen ist. Das ganze läuft in drei Schritten ab. Zuerst wird der Job von Ihrem Rechner an swim geschickt. Sobald auf swim wieder eine Verbindung zu groucho besteht, wird die Datei heruntergeladen. Im letzten Schritt wird die Datei dann von swim auf Ihren Host übertragen.

Die heutzutage wichtigsten von UUCP-Netzwerken angebotenen Dienste sind Elektronische Post und News.

Elektronische Post -- kurz E-Mail -- erlaubt den Austausch von Nachrichten mit Benutzern auf anderen Hosts, ohne daß Sie wissen müssen, wie diese Hosts anzusprechen sind. Die Aufgabe der Weiterleitung einer Nachricht von Ihrem Host zum Zielsystem wird vollständig vom sog. Mail-Transport-System übernommen. In einer UUCP-Umgebung wird E-Mail üblicherweise mit Hilfe des rmail-Befehls übertragen. Das Programm wird dabei auf einem benachbarten Host ausgeführt, wobei ihm die Adresse des Empfängers und die eigentliche Nachricht übergeben werden. rmail übergibt die Nachricht dann an den nächsten Host und so weiter, bis das gewünschte Ziel erreicht ist. Wir werden dies im Kapitel 13, Elektronische Post detailliert behandeln.

News könnte man als eine Art verteiltes elektronisches Schwarzes Brett (Bulletin Board) beschreiben. Häufig bezieht sich der Ausdruck auf Usenet-News, dem bei weitem bekanntesten News-Netzwerk, mit einer geschätzten Teilnehmerzahl von 120.000 Sites. Der Ursprung des Usenet reicht bis ins Jahr 1979 zurück. Nachdem UUCP mit der neuen UNIX-V7-Version ausgeliefert worden war, hatten drei Studenten die Idee eines allgemeinen Informationsaustausches innerhalb der UNIX-Gemeinde. Sie stellten eine Reihe von Scripten zusammen, die zum ersten Netnews-System wurden. Im Jahr 1980 verband dieses Netzwerk die drei Sites: duke, unc und phs an zwei Universitäten in North Carolina. Daraus erwuchs schließlich das Usenet. Obwohl es als UUCP-basiertes Netzwerk begann, ist es nicht länger an einen bestimmten Netzwerktyp gebunden.

Die grundlegende Informationseinheit ist der Artikel. Sie können einen Artikel in eine Hierarchie von Newsgruppen einspeisen (»posten«), die bestimmten Themenbereichen gewidmet sind. Die meisten Sites empfangen nur einen Teil aller Newsgruppen, die durchschnittlich ca. 200 MB an Artikeln pro Tag umfassen.

In der UUCP-Welt werden News normalerweise über einen UUCP-Link verschickt, indem alle Artikel der angeforderten Gruppe zu einer Reihe von Batches zusammengepackt werden. Diese werden dann an die empfangende Site geschickt, wo sie an den rnews-Befehl zum Entpacken und zur weiteren Bearbeitung übergeben

UUCP ist auch bei einer Reihe von Archiv-Servern das bevorzugte Medium. Sie erreichen diese Server üblicherweise, indem Sie sich über eine Telefonleitung mittels UUCP einwählen und sich als Gastbenutzer einloggen. Danach können Sie Dateien aus öffentlich zugänglichen Bereichen herunterladen. Solche Gastzugänge verwenden häufig uucp/nuucp als Loginnamen und Paßwort, oder etwas in der Art.

TCP/IP-Netzwerke

Obwohl UUCP eine durchaus vernünftige Wahl für das kostengünstige Anwählen von Netzwerkknoten darstellt, gibt es doch viele Situationen, in denen die verwendete Technik des Zwischenspeicherns und Weiterleitens nicht flexibel genug ist. Ein gutes Beispiel für die Grenzen von UUCP sind lokale Netzwerke (»Local Area Network«, oder kurz »LAN«). Solche lokalen Netzwerke bestehen aus einer kleinen Anzahl von Maschinen, die in einem Gebäude oder vielleicht auch nur auf einem Stockwerk stehen und untereinander verbunden sind, um eine homogene Arbeitsumgebung bereitzustellen. Typischerweise wollen Sie auf diesen Rechnern Dateien gemeinsam nutzen oder Anwendungen auf verschiedenen Maschinen ausführen.

Diese Aufgaben benötigen eine völlig andere Herangehensweise an Netzwerke. Statt komplette Dateien samt Job-Beschreibungen weiterzuleiten, werden alle Daten in kleinere Einheiten (Pakete) zerlegt, die dann unmittelbar an den Zielrechner weitergeleitet werden. Im Zielrechner werden die Pakete dann wieder zusammengesetzt. Ein solches Netzwerk wird als paketorientiertes Netzwerk (im Englischen packet-switched) bezeichnet. Unter anderem können Sie auf diese Weise interaktive Anwendungen über das Netzwerk ausführen. Der Preis für diese Möglichkeit ist die wesentlich erhöhte Komplexität der Software.

Die Lösung, die von UNIX-Systemen -- und vielen nicht-UNIX-Sites -- übernommen wurde, ist als TCP/IP bekannt. In diesem Abschnitt werden wir die darunterliegenden Konzepte betrachten.

Einführung in TCP/IP-Netzwerke

Die Wurzeln von TCP/IP liegen in einem Forschungsprojekt, das von der amerikanischen »Defense Advanced Research Projects Agency« (DARPA) im Jahre 1969 finanziert wurde. Was unter dem Namen ARPANET als experimentelles Netzwerk begann, wurde im Jahre 1975 in den normalen Betrieb übernommen, nachdem es sich als erfolgreich erwiesen hatte.

Im Jahre 1983 wurde das neue TCP/IP-Protokoll als Standard übernommen, und alle Hosts im Netzwerk mußten es von nun an einsetzen. Während ARPANET langsam zum Internet heranwuchs (wobei das ARPANET im Jahre 1990 zu existieren aufhörte), hatte sich TCP/IP schon auf Netzwerken außerhalb des Internet verbreitet. Herausragend sind dabei sicherlich lokale UNIX-Netzwerke, aber dank der zunehmenden Verbreitung schneller digitaler Telefoneinrichtungen wie ISDN hat TCP/IP auch eine vielversprechende Zukunft als Protokoll für Dialup-Netzwerke.

Als konkretes Beispiel für die Diskussion von TCP/IP in den folgenden Abschnitten führen wir die irgendwo in Fredland stehende Groucho-Marx-Universität (GMU) ein. Die meisten Institute betreiben ein eigenes lokales Netzwerk, während andere eines gemeinsam nutzen, und wieder andere gleich mehrere betreiben. Alle sind aber über das Internet durch einen gemeinsamen Hochgeschwindigkeitslink miteinander verbunden.

Stellen Sie sich vor, Ihre Linux-Kiste ist mit einem LAN von UNIX-Hosts im mathematischen Institut verbunden (nennen wir sie einfach mal erdos). Um nun auf einen Host im physikalischen Institut, sagen wir auf quark, zugreifen zu können, müssen Sie den folgenden Befehl eingeben:

$ rlogin quark.physics
Welcome to the Physics Department at GMU
(ttyq2) login:

Wenn der Prompt erscheint, müssen Sie Ihren Loginnamen, z. B. andres, und Ihr Paßwort eingeben. Nach der korrekten Eingabe wird auf quark eine Shell gestartet, in der Sie arbeiten können, als würden Sie an der Konsole des Systems sitzen. Sobald Sie die Shell verlassen, erscheint wieder der Prompt Ihrer eigenen Maschine. Sie haben damit gerade eine der grundlegendsten auf TCP/IP zur Verfügung stehenden Anwendungen verwendet: remote Login, das Einloggen an einem entfernten Rechner.

Während Sie in quark eingeloggt sind, möchten Sie vielleicht eine X11-basierte Anwendung, beispielsweise ein Plot-Programm oder einen PostScript-Previewer, ausführen. Um nun der Anwendung mitzuteilen, daß die Fenster auf dem Bildschirm Ihres Rechners erscheinen sollen, müssen Sie die Umgebungsvariable DISPLAY setzen:

$ export DISPLAY=erdos.maths:0.0

Wenn Sie nun die Anwendung starten, wird Ihr eigener X-Server statt dem auf quark befindlichen angesprochen; alle Fenster erscheinen auf Ihrem Bildschirm. (Das setzt natürlich voraus, daß X11 auf erdos läuft.) Der Punkt ist hier, daß TCP/IP es quark und erdos erlaubt, X11-Pakete hin und her zu schicken, und Ihnen so vorgaukelt, daß Sie an einem System arbeiten. Das Netzwerk ist hier völlig transparent.

Eine weitere sehr wichtige Anwendung in TCP/IP-Netzwerken ist NFS, was für Network File System steht. NFS ist eine weitere Möglichkeit, Netzwerke transparent zu machen, weil es Ihnen erlaubt, Verzeichnishierarchien von anderen Hosts zu mounten. Diese erscheinen dann auf Ihrem Rechner so, als wären es lokale Dateisysteme. Beispielsweise könnten die Home-Verzeichnisse aller Benutzer auf einer zentralen Maschine gehalten werden, von dem aus alle anderen Hosts im LAN die Verzeichnisse mounten können. Der Effekt ist, daß sich Benutzer an jeder beliebigen Maschine einloggen können und sich dennoch immer in ihrem jeweiligen Home-Verzeichnis wiederfinden. Auf die gleiche Weise können Sie Anwendungen, die einen großen Platzbedarf haben (wie z. B. TEX), auf nur einem Rechner installieren und diese Verzeichnisse dann an andere Maschinen exportieren. Wir kommen noch in Kapitel 11, Das Network File System auf NFS zurück.

Das sind natürlich nur einige Beispiele für das, was Sie über TCP/IP-Netzwerke alles machen können. Die Möglichkeiten sind nahezu unbeschränkt.

Wir werfen nun einen genaueren Blick darauf, wie TCP/IP funktioniert. Diese Informationen helfen Ihnen zu verstehen, wie und warum Sie Ihre Maschine konfigurieren müssen. Wir beginnen mit einer Untersuchung der Hardware und arbeiten uns dann langsam vor.

Ethernet

Die in LANs am weitesten verbreitete Hardware ist im allgemeinen unter dem Namen Ethernet bekannt. Einfache Ethernets sind in der Installation relativ günstig, was, zusammen mit einer Übertragungsrate von 10 Megabit pro Sekunde, sicherlich für die große Popularität gesorgt hat.

Ethernet gibt es in drei Varianten: Thick, Thin, und Zweidraht (»Twisted Pair«). Thin- und Thick-Ethernet verwenden beide ein Koaxialkabel, das sich aber jeweils in der Dicke und in der Art, wie ein Host an dieses Kabel angeschlossen wird, unterscheidet. Thin-Ethernet arbeitet mit einem T-förmigen BNC-Steckverbinder, den Sie in das Kabel einfügen und auf einen entsprechenden Stecker auf der Rückseite Ihres Computers aufstecken. Bei Thick-Ethernet müssen Sie ein kleines Loch in das Kabel drillen und einen Transceiver mit Hilfe eines sog. »Vampire Taps« einsetzen. Ein oder mehrere Hosts können dann mit diesem Transceiver verbunden werden. Bei Thin- und Thick-Ethernet kann das Kabel eine maximale Länge von 200 bzw. 500 Metern besitzen. Es wird daher auch 10base-2 oder 10base-5 genannt. »Twisted Pair« verwendet ein zweiadriges Kupferkabel und üblicherweise zusätzliche Hardware, die als aktiver Hub bekannt ist. Twisted Pair wird auch 10base-T genannt. Auch wenn das Hinzufügen eines weiteren Host bei einem Thick-Ethernet eine etwas haarige Angelegenheit ist, bringt es doch das Netzwerk nicht zum Absturz. Fügen Sie einen Host in ein Thinnet ein, legen Sie dagegen das Netzwerk zumindest für ein paar Minuten lahm, weil Sie das Kabel anschneiden müssen, um den Verbinder einzufügen.

Die meisten Leute ziehen Thin-Ethernet vor, weil es sehr billig ist. Steckkarten für den PC werden für unter DM 100 angeboten. Der Preis für Kabel liegt bei ein bis zwei Mark pro Meter. Bei größeren Installationen ist Thick-Ethernet die bessere Wahl. Beispielsweise wird am mathematischen Institut der GMU Thick-Ethernet verwendet, damit das Netzwerk nicht immer heruntergefahren werden muß, wenn ein neuer Rechner hinzugefügt wird.

Ein Nachteil der Ethernet-Technologie ist die begrenzte Länge der Kabel, was die Verwendung auf LANs beschränkt. Auf der anderen Seite können Sie aber mehrere Ethernet-Segmente miteinander verbinden, indem Sie sogenannte Repeater, Bridges oder Router verwenden. Repeater kopieren einfach die Signale zwischen zwei oder mehreren Segmenten, was bedeutet, daß 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 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 angesprochen, die in die Firmware der Ethernet-Karte fest eingetragen ist. Diese Adressen werden üblicherweise als eine Sequenz von zweistelligen Hexadezimalzahlen geschrieben, die jeweils durch Doppelpunkte voneinander getrennt werden (beispielsweise aa:bb:cc:dd:ee:ff).

Ein von einem Rechner ausgesandter Frame wird von allen vorhandenen Rechnern registriert, aber nur der Ziel-Host liest das Paket und verarbeitet es. Versuchen zwei Stationen zur gleichen Zeit zu senden, tritt eine sog. Kollision auf. Diese Kollision wird dadurch aufgelöst, daß beide Stationen den Sendevorgang abbrechen und einige Augenblicke später wiederholen.

Andere Arten von Hardware

Bei größeren Installationen wie an der Groucho-Marx-Universität ist Ethernet üblicherweise nicht die einzig verwendete Ausrüstung. Bei der GMU sind die LANs aller Institute mit dem Universitäts-Backbone verbunden, einem Glasfaserkabel, über das FDDI (Fiber Distributed Data Interface) läuft. 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. Die Hauptvorteile von FDDI liegen in der Geschwindigkeit von bis zu 100 Mbps und einer maximalen Kabellänge von bis zu 200 Kilometern.

Bei Langstrecken-Netzwerklinks wird häufig eine andere Technik verwendet, die auf einem Standard namens X.25 basiert. Viele der sogenannten öffentlichen Datennetze, wie Tymnet in den USA oder Datex-P in Deutschland, bieten diesen Service an. Für X.25 wird eine spezielle Hardware, namentlich ein »Packet Assembler/Disassembler« oder PAD benötigt. X.25 definiert selbst eine Reihe von Netzwerk-Protokollen, wird dessenungeachtet aber häufig genutzt, um TCP/IP-basierte Netzwerke mit auf anderen Protokollen basierenden Netzen zu verbinden. Weil IP-Pakete nicht einfach auf X.25-Pakete umgesetzt werden können (umgekehrt übrigens auch nicht), werden sie einfach in X.25-Pakete »eingepackt« und über das Netzwerk geschickt.

Öfter benutzen Amateurfunker ihre Geräte, um ihre Computer zu vernetzen. Diese Technik wird Packet-Radio oder Ham-Radio genannt. Das bei Ham-Radio verwendete Protokoll wird als AX.25 bezeichnet und ist von X.25 abgeleitet.

Andere Techniken verwenden langsame, aber billige serielle Leitungen für den Zugriff über Wählleitungen. Das erfordert wieder ein anderes Protokoll für die Übertragung von Paketen, zum Beispiel SLIP oder PPP, die wir später beschreiben werden.

Das Internet-Protokoll (IP)

Natürlich wollen Sie nicht, daß Ihr Netzwerk auf ein Ethernet beschränkt ist. Idealerweise sollten Sie ein Netzwerk ohne Rücksicht darauf verwenden können, welche Hardware es verwendet und aus wie vielen Untereinheiten es besteht. Beispielsweise finden Sie bei einer größeren Installation wie der Groucho-Marx-Universität üblicherweise eine ganze Reihe separater Ethernets, die auf irgendeine Art und Weise miteinander verbunden werden müssen. Am mathematischen Institut der GMU wird mit zwei Ethernets gearbeitet: ein Netzwerk mit schnellen Maschinen für Professoren und wissenschaftliche Mitarbeiter und eines mit langsamen Maschinen für die Studenten. Beide Netze hängen am universitätseigenen FDDI-Backbone.

Die Verbindung wird von einem speziellen Host, einem sogenannten Gateway, verwaltet, der ein- und ausgehende Pakete zwischen den beiden Ethernets und der Glasfaserleitung kopiert. Nehmen wir beispielsweise einmal an, Sie sitzen im mathematischen Institut und wollen von Ihrem Linux-Rechner aus auf quark im LAN des physikalischen Instituts zugreifen. Die Netzwerk-Software kann die Pakete nicht direkt an quark schicken, weil es sich nicht in demselben Ethernet befindet. Die Software muß sich nun also auf ein Gateway verlassen, das das Paket entsprechend weiterleitet. Das Gateway (nennen wir es mal sophus) leitet die Pakete an das Gateway niels weiter, das diese Funktion für das physikalische Institut übernimmt. Die Übertragung erfolgt über den Backbone, und niels liefert die Daten dann an den Zielrechner aus. Der Datenfluß zwischen erdos und quark ist in Abbildung 1--1 dargestellt.

Abbildung 1-1. Die drei Schritte beim Senden eines Datagramms von erdos an quark

Dieses Schema der Weiterleitung von Daten an einen entfernten Host wird Routing genannt, und die Pakete werden in diesem Zusammenhang häufig als Datagramme bezeichnet. Um die Dinge etwas zu vereinfachen, werden Datagramme über ein einziges Protokoll ausgetauscht, das von der verwendeten Hardware völlig unabhängig ist: IP, oder Internet Protocol. In Kapitel 2, Aspekte der Netzwerarbeit mit TCP/IP werden wir IP und Routing detaillierter behandeln.

Der Hauptvorteil von IP besteht darin, daß es physikalisch verschiedene Netzwerke zu einem scheinbar homogenen Netzwerk zusammenfaßt. Das wird als »Internetworking« bezeichnet, und das daraus resultierende »Meta-Netzwerk« wird Internet genannt. Beachten Sie an dieser Stelle den feinen Unterschied zwischen einem Internet und dem Internet. Das Internet ist der offizielle Name eines bestimmten globalen Internets.

Natürlich benötigt IP auch ein hardwareunabhängiges Adressierungsschema. Dies wird dadurch erzielt, daß jedem Host eine eindeutige 32-Bit-Zahl zugewiesen wird, die sog. IP-Adresse. Dargestellt wird eine IP-Adresse üblicherweise durch vier Dezimalzahlen, eine für jeden 8-Bit-Anteil, die durch Punkte voneinander getrennt sind. Zum Beispiel könnte quark die IP-Adresse 0x954C0C04 besitzen, die Sie dann als 149.76.12.4 schreiben würden. Dieses Format wird auch Dotted Quad Notation genannt.

Sie werden bemerkt haben, daß wir nun drei verschiedene Arten von Adressen haben: Zum einen haben wir Hostnamen wie z. B. quark, dann gibt es IP-Adressen, und zum Schluß gibt es noch Hardware-Adressen wie die 6-Byte-Ethernet-Adresse. Das alles muß irgendwie so zusammen passen, daß, wenn Sie rlogin quark eingeben, der Netzwerk-Software die IP-Adresse von quark übergeben werden kann. Liefert IP irgendwelche Daten an das physikalische Institut, muß es irgendwie herausfinden, welche Ethernet-Adresse zu welcher IP-Adresse gehört.

Mit dieser Thematik werden wir uns in Kapitel 2 ausführlicher befassen. Im Moment genügt es, sich zu merken, daß die für das Finden einer Adresse benötigten Schritte als Auflösen des Hostnamens, oder im Englischen als Hostname Resolution, bezeichnet werden, mit dem Ziel der Abbildung von Hostnamen auf IP-Adressen. Address Resolution ist dagegen der Prozeß, bei dem IP-Adressen auf Hardware-Adressen abgebildet werden.

IP über serielle Leitungen

Bei seriellen Leitungen gibt es einen als SLIP (Serial Line IP) bekannten »de facto«-Standard. Eine modifizierte Version von SLIP ist CSLIP, oder Compressed SLIP, bei der die IP-Header komprimiert werden, um die relativ geringe Bandbreite von seriellen Links besser auszunutzen. Ein anderes serielles Protokoll ist PPP, oder Point-to-Point Protocol. PPP bietet gegenüber SLIP eine ganze Reihe weiterer Features, einschließlich einer Überprüfung der Zugangsberechtigung. Der Hauptvorteil gegenüber SLIP liegt darin, daß es nicht auf den Transport von IP-Datagrammen beschränkt ist, sondern so entwickelt wurde, daß beliebige Datagramm-Arten übertragen werden können.

Transmission Control Protocol (TCP)

Mit dem Übertragen von Datagrammen von einem Host zum anderen ist es nicht getan. Wenn Sie sich in quark einloggen, wollen Sie eine zuverlässige Verbindung zwischen Ihrem rlogin-Prozeß auf erdos und dem Shell-Prozeß auf quark. Das bedeutet aber, daß die übertragenen Informationen vom Sender in Pakete aufgeteilt und vom Empfänger wieder zu einem richtigen Datenstrom zusammengesetzt werden müssen. So trivial Ihnen das auch vorkommen mag, so beinhaltet diese Aufgabe doch eine Reihe kritischer Aspekte.

Eine sehr wichtige Sache, die Sie über IP wissen sollten ist, daß es (absichtlich) nicht zuverlässig ist. Stellen Sie sich vor, daß 10 Leute in Ihrem Ethernet gleichzeitig anfangen, die neueste Release von XFree86 vom FTP-Server der GMU herunterzuladen. Die Menge der zu übertragenden Daten könnte für das Gateway zuviel sein, weil es zu langsam oder nicht ausreichend mit Speicher bestückt ist. Wollen Sie nun ein Paket an quark übertragen, könnten die Puffer von sophus gerade voll sein, und der Rechner wäre in diesem Fall nicht in der Lage, das Paket weiterzuleiten. IP löst dieses Problem, indem es dieses Paket einfach »vergißt«. Die Verantwortung für die Integritätsprüfung und die Vollständigkeit der Daten liegt daher bei den kommunizierenden Hosts, die entsprechend Sorge dafür tragen müssen, im Fehlerfall Datenpakete erneut zu senden.

Dies wird von wieder einem anderen Protokoll namens TCP, oder Transmission Control Protocol, erledigt, das einen zuverlässigen Dienst auf IP aufbaut. Das Hauptmerkmal von TCP ist, daß es IP verwendet, um bei Ihnen den Eindruck zu erwecken, daß eine einfache Verbindung zwischen den beiden Prozessen auf Ihrem Host und auf der entfernten Maschine existiert. Sie müssen sich also nicht darum kümmern, wie und auf welcher Route die Daten tatsächlich reisen. Eine TCP-Verbindung arbeitet grundsätzlich wie eine zwei-Wege-Pipe, bei der beide Prozesse schreiben und lesen können. Stellen Sie es sich wie ein Telefonat vor.

TCP identifiziert die Endpunkte einer solchen Verbindung anhand der IP-Adressen der beiden Hosts und der Nummer eines sog. Ports auf jedem Host. Ports können Sie sich als eine Art Zugangspunkt für Netzwerk-Verbindungen vorstellen. Wenn wir bei unserem Telefonbeispiel bleiben, können Sie IP-Adressen mit Vorwahlnummern (Nummern für bestimmte Städte) und Portnummern mit dem lokalen Kode (Nummern der individuellen Teilnehmer) vergleichen.

In unserem rlogin-Beispiel öffnet die Client-Anwendung (rlogin) einen Port auf erdos und stellt eine Verbindung mit Port 513 auf quark her, den der rlogind-Server verwendet. Auf diese Weise wird eine TCP-Verbindung hergestellt. Über diese Verbindung führt rlogind zuerst die Autorisierung durch und startet (»spawnt«) eine Shell. Die Standard-Ein- und Ausgabe der Shell wird in die TCP-Verbindung umgeleitet (»redirection«). Das bedeutet, daß alles, was Sie unter rlogin auf Ihrer Maschine eingeben, über den TCP-Stream geleitet und als Standardeingabe für die Shell verwendet wird.

User Datagram Protocol

Natürlich ist TCP nicht das einzige bei TCP/IP-Netzwerken verwendete Protokoll. Obwohl für Anwendungen wie rlogin geeignet, ist der zu verwaltende Overhead für manche Anwendungen völlig undenkbar. Statt dessen wird ein mit TCP verwandtes Protokoll namens UDP (User Datagram Protocol) verwendet. Genau wie TCP erlaubt auch UDP einer Anwendung, mit einem Dienst auf einem entfernten Rechner über einen bestimmten Port in Kontakt zu treten. Es wird aber keine Verbindung aufgebaut, sondern es werden nur einzelne Pakete an den entsprechenden Dienst gesandt -- daher der Name.

Ein Dienst, der im allgemeinen UDP verwendet, ist NFS. (Manche NFS-Implementationen bieten alternativ auch eine TCP-Verbindung an; das wird aber nur selten genutzt.)

Mehr zu Ports

Sie können sich Ports als Zugangspunkte für Netzwerk-Verbindungen vorstellen. Will eine Anwendung einen Dienst anbieten, verwendet sie einen bestimmten Port und wartet auf Clients. (Dieses Warten ist auch als »Horchen« oder Listening am Port bekannt.) Möchte ein Client den Dienst nutzen, bestimmt er einen Port auf seinem lokalen Rechner und baut eine Verbindung zu dem Port des Servers auf dem entfernten Host auf.

Eine wichtige Eigenschaft von Ports ist, daß, wenn erst einmal eine Verbindung zwischen dem Client und dem Server aufgebaut wurde, sich jede Kopie des Servers an den Server-Port anhängen und nach weiteren Clients horchen kann. Das ermöglicht beispielsweise mehrere entfernte Logins, die alle Port 513 verwenden, gleichzeitig auf demselben Host. TCP ist in der Lage, die verschiedenen Verbindungen zu unterscheiden, weil sie alle von unterschiedlichen Ports oder Hosts kommen. Wenn Sie sich zum Beispiel zweimal von erdos aus in quark einloggen, verwendet der erste rlogin-Client den lokalen Port 1023 und der zweite Port 1022. Beide stellen aber eine Verbindung zu Port 513 auf quark her.

Dieses Beispiel zeigt die Verwendung von Ports als Treffpunkt, der von Clients angelaufen wird, wenn ein bestimmter Dienst in Anspruch genommen werden soll. Damit ein Client auch die richtige Portnummer anspricht, muß über diese Nummern eine Vereinbarung zwischen den Administratoren beider Systeme getroffen werden. Bei Diensten, die so weit verbreitet sind wie rlogin, werden die Nummern zentral verwaltet. Dies wird von der IETF (Internet Engineering Task Force) erledigt, die in regelmäßigen Abständen ein RFC namens Assigned Numbers veröffentlicht. Dieses Dokument beschreibt unter anderem die Portnummern der bekannten Dienste. Linux verwendet eine Datei namens /etc/services, die Servicenamen mit Nummern verbindet.

Zu bemerken wäre noch, daß TCP und UDP zwar beide auf Ports aufbauen, diese Nummern aber nicht zu Konflikten führen. Das bedeutet, daß beispielsweise TCP-Port 513 mit UDP-Port 513 nicht identisch ist. Tatsächlich dienen diese Ports als Zugriffspunkte auf zwei verschiedene Dienste, nämlich rlogin (TCP) und rwho (UDP), um genau zu sein.

Die Socket Library

Beim UNIX-Betriebssystem ist die Software, die all diese Aufgaben und Protokolle durchführt, üblicherweise direkt in den Kernel integriert, und so ist es auch bei Linux. Die gängigste Programmierschnittstelle in der UNIX-Welt ist die Berkeley Socket Library. Der Name stammt von einer bekannten Analogie, die Ports als Steckdosen (Sockets) und den Verbindungsaufbau zu einem Port als »Einstecken« beschreibt. Die Bibliothek stellt eine bind-Funktion bereit, mit der Sie einen entfernten Host, ein Transport-Protokoll und einen Dienst spezifizieren können, zu dem ein Programm eine Verbindung herstellen oder an dem es horchen kann. Zu diesem Zweck stehen die Funktionen connect, listen und accept bereit. Die Socket-Bibliothek ist noch etwas allgemeiner gehalten, denn sie bietet nicht nur eine Klasse von TCP/IP-basierten Sockets (die AF_INET-Sockets), sondern auch eine Klasse, die Verbindungen verwaltet, die auf dem lokalen Rechner stattfinden (die AF_UNIX-Klasse). Einige Implementierungen können auch mit anderen Klassen wie dem XNS-Protokoll (Xerox Networking System) oder X.25 umgehen. Unter Linux ist die Socket Library Teil der Standard C Library (libc). Zur Zeit werden neben TCP/IP- und UNIX-Sockets auch noch die Protokolle IPX (Novell), AX.25 und NET/ROM (Ham-radio) sowie Appletalk unterstützt.

Netzwerke unter Linux

Als Ergebnis der Bemühungen von Programmierern aus aller Welt wäre Linux ohne das globale Netzwerk nicht denkbar gewesen. Es ist also nicht weiter überraschend, daß bereits in den frühen Entwicklungsphasen verschiedene Leute damit begannen, es um Netzwerk-Fähigkeiten zu erweitern. Eine UUCP-Implementierung lief nahezu von Anfang an unter Linux. Die Arbeit an TCP/IP-basierter Netzwerktechnik begann ungefähr im Herbst 1992, als Ross Biro und andere das entwickelten, was später unter dem Namen Net-1 bekannt wurde.

Nachdem Ross im Mai 1993 mit der aktiven Entwicklung aufhörte, begann Fred van Kempen mit der Arbeit an einer neuen Implementierung, wobei größere Teile des Kodes neu geschrieben wurden. Diese Implementierung war unter dem Namen Net-2 bekannt. Die erste öffentliche Release, Net-2d, war im Sommer 1993 (als Teil des 0.99.10-Kernel) verfügbar und wurde seitdem von verschiedenen Leuten (besonders von Alan Cox) verwaltet und erweitert und ist nun als Net-2Debugged bekannt. Nach Behebung vieler Fehler und nach zahlreichen Verbesserungen des Kodes wurde es in Net-3 umbenannt, nachdem Linux 1.0 verfügbar war. Diese Version des Netzwerk-Kodes ist im Moment auch in den offiziellen Kernel-Releases enthalten.

Net-3 bietet Gerätetreiber (»Device Driver«) für eine große Anzahl unterschiedlicher Ethernet-Karten, aber auch SLIP (zur Übertragung von Daten über serielle Leitungen) und PLIP (für parallele Leitungen). Mit Net-3 verfügt Linux über eine TCP/IP-Implementierung, die sich in lokalen Netzwerken sehr gut verhält. Der gezeigte Durchsatz schlägt sogar einige der kommerziellen UNIX-Versionen für PCs. Nachdem in der Kernelreihe 1.1.* die Stabilisierung des Kode im Vordergrund stand, geht die Entwicklung seit 1.3.1 wieder verstärkt in Richtung einer Erweiterung der vorhandenen.

Darüber hinaus gibt es verschiedene Projekte, die die Vielseitigkeit von Linux erhöhen sollen. Ein PPP-Treiber (das Point-to-Point-Protokoll, ein anderer Weg, Netzwerkpakete über serielle Leitungen zu übertragen) ist im Moment im Beta-Stadium. Treiber für Ham-Radio-Protokolle AX.25 und Netrom sowie Appletalk befinden sich im Alpha-Stadium. Alan Cox hat auch einen Treiber für das IPX-Protokoll von Novell implementiert, diese Bemühungen liegen augenblicklich aber leider auf Eis, weil Novell nicht bereit ist, die notwendige Dokumentation für die darüberliegenden Protokollschichten zur Verfügung zu stellen. Eine weitere, sehr vielversprechende Unternehmung ist samba, ein freier NetBIOS-Server für UNIX-Systeme, geschrieben von Andrew Tridgell.(3)

Verschiedene Streiflichter der Entwicklung

Fred setzte die Entwicklung mit Net-2e fort, das ein sehr überarbeitetes Design des Netzwerk-Layers aufwies. Allerdings hat man später nicht mehr viel von Net-2e gehört.

In absehbarer Zukunft wird uns aber wohl Net-3 erhalten bleiben. Alan arbeitet momentan auf Hochtouren an Erweiterungen wie IP Multicasting und verbesserter Unterstützung für UNIX-Sockets und das IPv6-Protokoll, dem zukünftigen Nachfolger von IP.

Auch wenn die verschiedenen Netzwerk-Implementierungen alle bestrebt sind, dieselben Dienste anzubieten, so gibt es auf Kernel- und Treiberebene doch erhebliche Unterschiede. Aus diesem Grund können Sie auch ein System, das mit einem Net-2e-Kernel arbeitet, nicht mit den Utilities von Net-2d oder Net-3 konfigurieren und umgekehrt. Diese Aussage gilt nur für Befehle, die intern sehr eng mit dem Kernel zusammenarbeiten. Anwendungen und gängige Netzwerkbefehle wie rlogin oder telnet laufen mit jedem Kernel.

Dennoch sollten Sie sich von den verschiedenen Netzwerkversionen nicht verwirren lassen. Solange Sie nicht an der aktiven Entwicklung teilnehmen, müssen Sie sich nicht darum kümmern, welche Version des TCP/IP-Kodes Sie benutzen. Parallel zu den offiziellen Kernel-Releases gibt es immer auch Netzwerk-Utilities, die mit dem im Kernel integrierten Netzwerk-Kode kompatibel sind.

Wo Sie den Kode herbekommen

Die neueste Version des Linux-Netzwerk-Quellkodes können Sie über »anonymous FTP« von verschiedenen Servern herunterladen. Die offizielle FTP-Site für Net-3 ist sunacm.swan.ac.uk, gespiegelt von sunsite.unc.edu unter system/Network/sunacm, das wiederum von einer Reihe deutscher Server wie ftp.gwdg.de oder ftp.uni-erlangen.de gespiegelt wird.

Die neuesten Kernel finden Sie auf nic.funet.fi in /pub/OS/Linux/PEOPLE/Linus; sunsite und tsx-11.mit.edu spiegeln dieses Verzeichnis.

Wie Sie Ihr System verwalten

In diesem Buch befassen wir uns hauptsächlich mit Installations- und Konfigurationsfragen. Administration bedeutet aber wesentlich mehr als das -- nachdem Sie einen Dienst eingerichtet haben, müssen Sie ihn auch am Laufen halten. Den meisten Diensten müssen Sie nicht besonders viel Aufmerksamkeit schenken, während andere wie Mail und News die Erledigung von Routineaufgaben von Ihnen verlangen, um Ihr System auf dem neuesten Stand zu halten. Diese Aufgaben werden wir in späteren Kapiteln behandeln.

Das absolute Verwaltungsminimum ist die regelmäßige Prüfung der System- und der einzelnen Anwendungs-Logdateien auf Fehler und ungewöhnliche Ereignisse. In der Regel erledigen Sie dies durch das Schreiben einer Reihe administrativer Shell-Scripten, die periodisch von cronaus ausgeführt werden. Die Source-Distributionen einiger bedeutender Anwendungen wie smail oder C-News enthalten solche Scripten. Sie müssen diese entsprechend Ihren Anforderungen und Bedürfnissen anpassen.

Die Ausgabe von jedem Ihrer cron-Jobs sollte per E-Mail an einen administrativen Account gesandt werden. Per Voreinstellung senden viele Anwendungen Fehlerreports, Benutzungsstatistiken oder Zusammenfassungen von Logdateien an den root-Account. Das macht nur Sinn, wenn Sie sich gelegentlich als root einloggen; besser ist es dagegen, die Mail von rootan Ihren persönlichen Account weiterzuleiten, indem Sie ein Mail-Alias einrichten, wie dies in Kapitel 14, smail zum Laufen bringen beschrieben ist.

Gleichgültig, wie sorgfältig Sie Ihre Site konfiguriert haben, Murphys Gesetz garantiert, daß ein Problem auftauchen wird. Darum bedeutet die Verwaltung eines Systems auch, daß Sie für Beschwerden verfügbar sein müssen. Normalerweise erwarten die Leute, daß der Systemadministrator zumindest als root per E-Mail erreichbar ist, es existieren aber auch andere Adressen, die häufig verwendet werden, um eine Person zu erreichen, die für einen bestimmten Aspekt der Verwaltung zuständig ist. Beispielsweise werden Beschwerden über eine fehlerhafte Mail-Konfiguration üblicherweise an postmaster adressiert. Probleme mit dem News-System werden dem Benutzer, newsmaster oder usenet mitgeteilt. Mail an hostmaster sollte an die Person weitergeleitet werden, die sich um die grundlegenden Netzwerkdienste und den DNS-Service (falls vorhanden) kümmert.

Systemsicherheit

Ein anderer wichtiger Aspekt der Systemadministration in einer Netzwerkumgebung ist der Schutz Ihres Systems vor Eindringlingen. Nachlässig verwaltete Systeme bieten böswilligen Menschen viele Ziele. Die Angriffe reichen von geknackten Paßwörtern bis hin zum Ethernet-Snooping, und die verursachten Schäden reichen von gefälschten Mails über Datenverlust bis hin zur Verletzung Ihrer Privatsphäre. Wir werden auf die Probleme im einzelnen dort eingehen, wo die Probleme auch wirklich auftreten. Gleichzeitig stellen wir Ihnen einige gängige Schutzmaßnahmen dagegen vor.

Dieser Abschnitt beschreibt einige Beispiele und grundlegende Techniken zur Systemsicherheit. Natürlich können die behandelten Aspekte nicht alle Sicherheitsthemen im Detail erläutern, denen Sie begegnen könnten; sie dienen bloß dazu, die möglichen Probleme zu verdeutlichen, die auftreten könnten. Aus diesem Grund ist das Lesen eines guten Buches über Sicherheit ein absolutes Muß, besonders bei einem vernetzten System.

Die Systemsicherheit beginnt mit guter Systemadministration. Das beinhaltet die Überprüfung von Eigentums- und Zugriffsrechten aller aktiven Dateien und Verzeichnisse, die Überwachung privilegierter Accounts etc. Beispielsweise überprüft das Programm COPS Ihr Dateisystem und gängige Systemdateien auf ungewöhnliche Rechte und andere Anomalien. Es ist auch klug, ein Paßwort-Paket zu verwenden, das verschiedene Regeln auf das Paßwort des Benutzers anwendet, um es so schwer wie möglich zu machen, es zu erraten. Das Shadow-Paßwort-Paket beispielsweise verlangt, daß ein Paßwort aus mindestens fünf Zeichen besteht und sowohl groß- als auch kleingeschriebene Buchstaben (und Zahlen) enthält.

Wenn Sie einen Dienst über das Netzwerk verfügbar machen, sollten Sie sicherstellen, daß Sie ihm die »geringsten Privilegien« zuweisen, d. h. ihm keine Dinge erlauben, die für seine Arbeit nicht benötigt werden. Zum Beispiel sollten Programme die UID nur, wenn unbedingt nötig, auf root oder einen anderen privilegierten Account einstellen dürfen. Zum Beispiel sollten Programme nur dann unter root-Berechtigung laufen wenn unbedingt nötig. Wenn ein Dienst nur für eine sehr eingeschränkte Anwendung eingesetzt werden soll, sollten Sie nicht zögern, ihn so restriktiv zu konfigurieren, wie es diese spezielle Anwendung zuläßt. Sollen andere beispielsweise direkt von Ihrer Maschine booten können, müssen Sie TFTP (Trivial File Transfer Protocol) installieren, damit sie grundlegende Konfigurationsdateien aus Ihrem /boot-Verzeichnis herunterladen können. Wird es nun aber ohne Beschränkungen verwendet, erlaubt TFTP jedem Benutzer überall auf der Welt jede allgemein lesbare Datei von Ihrem System herunterzuladen. Sollte dies nun nicht in Ihrem Sinne sein, warum also nicht den TFTP-Dienst auf das /boot-Verzeichnis beschränken?(4)

Diesen Gedanken weiterspinnend, könnten Sie verschiedene Dienste auch auf die Benutzer bestimmter Hosts wie beispielsweise Ihres lokalen Netzwerks einschränken. In Kapitel 9, Wichtige NetzwerkFeatures stellen wir tcpd vor, das das für eine ganze Reihe von Netzwerk-Anwendungen tut.

Ein weiterer wichtiger Punkt ist die Vermeidung »gefährlicher« Software. Natürlich kann jede Software gefährlich sein, weil sie fehlerhaft sein kann, was clevere Leute ausnutzen könnten, um sich Zugang zu Ihrem System zu verschaffen. Solche Dinge kommen vor, und es kann keinen vollständigen Schutz davor geben. Dieses Problem betrifft freie und kommerzielle Software gleichermaßen. Jedoch sind Programme, die besondere Privilegien benötigen, naturgemäß gefährlicher als andere, weil jedes Schlupfloch dramatische Konsequenzen nach sich ziehen kann.(5)

Sie können niemals ausschließen, daß Ihre Sicherheitsvorkehrungen nicht doch fehlschlagen, egal, wie sorgfältig Sie waren. Sie sollten daher sicherstellen, daß Sie Eindringlinge frühzeitig erkennen. Die Überprüfung der Logdateien ist ein guter Ansatzpunkt, aber der Eindringling ist möglicherweise so clever und entfernt alle Spuren. Andererseits existieren Tools wie tripwire, geschrieben von Gene Kim und Gene Spafford, mit denen Sie überprüfen können, ob bei lebenswichtigen Systemdateien der Inhalt oder die Zugriffsrechte verändert wurden. tripwire berechnet verschiedene Checksummen über diese Dateien und speichert diese in einer Datenbank. Bei nachfolgenden Läufen werden die Checksummen erneut berechnet und mit den gespeicherten verglichen, um Veränderungen zu erkennen.


Fußnoten

(1)
Dessen ursprünglicher Geist (siehe oben) ist auch heute noch manchmal erkenntlich.
(2)
Wenn Sie bash, die GNU Bourne Again Shell, verwenden, müssen Sie dem Ausrufezeichen einen Backslash »\« voranstellen, weil es als History-Zeichen eingesetzt wird.
(3)
NetBIOS ist das Protokoll, auf dem Anwendungen wie lanmanager und Windows for Workgroups basieren.
(4)
Wir kommen darauf noch im Kapitel 9, Wichtige NetzwerkFeatures zurück.
(5)
Wenn Sie einen Netzwerkdienst anbieten, der ein setuid-Programm benötigt, müssen Sie doppelt vorsichtig sein, nichts in der Dokumentation zu übersehen, damit Sie nicht versehentlich ein Sicherheitsloch öffnen. Im Jahr 1988 brachte der RTM-Wurm einen großen Teil des Internet zum Teil dadurch zum Erliegen, daß er eine Lücke in einigen sendmail-Programmen ausnutzte. Diese Lücke wurde schon seit langen geschlossen.

Inhaltsverzeichnis Einleitung Kapitel 2