Inhalt

4. Grundkonfiguration

Die folgenden Abschnitte sollte man gut durchlesen, denn ihr Verständnis ist sehr wichtig, bevor man mit der tatsächlichen Konfiguration beginnen kann. Es handelt sich um grundlegende Prinzipien, die unabhängig davon sind, welche Art von Netzwerk letztendlich verwendet wird.

4.1 Was brauche ich für den Anfang?

Einige Dinge benötigt man, bevor man sich mit der Zusammenstellung und Konfiguration seines Netzwerkes beschäftigen kann. Die wichtigsten davon sind:

Aktuelle Kernel Quelldateien

Der derzeit installierte Kernel hat oft nicht die Treiber für die gewünschte Hardware und Netzwerk-Protokolle eingebunden. Hier ist eine Neukompilation des Kernels mit den entsprechenden Optionen notwendig.

Die jeweils aktuelle Kernel-Version befindet sich auf

ftp.funet.fi:/pub/Linux/PEOPLE/Linus/v2.0

Normalerweise wird das Archiv mit den Quelltexten in das Verzeichnis /usr/src/linux entpackt. Weiterführende Informationen dazu, wie man Patches einspielt und den Kernel übersetzt, findet man im Kernel HOWTO. Die Konfiguration der verschiedenen Module beschreibt das Module HOWTO.

Solange nicht besonders auf eine besondere Kernel-Version verwiesen wird, sollte man bei den Standard-Kernels bleiben. Dies sind die Versionen mit gerader zweiter Ziffer. Die Entwickler-Kernel, gekennzeichnet durch eine ungerade zweite Ziffer wie derzeit 2.1.x, können strukturelle Veränderungen oder Test-Code enthalten, die im Zusammenspiel mit anderen Programmen des Systems zu Problemen führen können. Wer sich nicht sicher ist, daß er mit derartigen Schwierigkeiten umgehen kann, sollte bei den Standard-Versionen bleiben.

Aktuelle Hilfsprogramme

Diese Programme (englisch: network tools) dienen dazu, die Netzwerk Devices, Kernel-Schnittstellen zur Hardware, zu konfigurieren. Damit können also zum Beispiel Netzwerkadressen zugeordnet werden oder routes definiert werden.

Normalerweise kommen alle neueren Linux Distributionen mit diesen Hilfsprogrammen. Wer sie bei der Erstinstallation weggelassen hat, muß diese in jedem Fall installieren.

Wer keine fertige Distribution verwendet, muß sich die Quellen selbst besorgen und die nötigen Programme kompilieren. Dies ist aber nicht weiter schwierig.

Die Programme werden von Bernd Eckenfels betreut und können via FTP bezogen werden:

Auf jeden Fall muß man sich vergewissern, daß die Version sich auch mit dem eingesetzten Kernel verträgt. Um die gegenwärtig, also als dieser Text geschrieben wurde, aktuelle Version zu installieren, geht man wie folgt vor:

# cd /usr/src
# tar xvfz net-tools-1.32-alpha.tar.gz
# cd net-tools-1.32-alpha
# make config
# make
# make install

Wer außerdem auch beabsichtigt, ein Firewall aufzusetzen oder IP Masquerading zu verwenden, wird darüberhinaus das Programm ipfwadm benötigen. Die aktuellste Version bekommt man über:

ftp.xos.nl:/pub/linux/ipfwadm
Auch dort gibt es unterschiedliche Versionen, man muß deshalb darauf achten, die für den eigenen Kernel passende auszuwählen.

Die Installation ist dann ganz einfach. Folgendes Beispiel zeigt dieses an Hand der aktuellen Version:

# cd /usr/src
# tar xvfz ipfwadm-2.3.0.tar.gz
# cd ipfwadm-2.3.0
# make
# make install

Anwendungsprogramme

Mit Anwendungen sind hier Programme wie telnet oder ftp sowie die zugehörigen Server gemeint. David Holland (dholland@hcs.harvard.edu) verwaltet inzwischen eine Distribution mit den am weitesten verbreiteten Programmen. Man erhält sie hier:

ftp.uk.linux.org:/pub/linux/Networking/base

Zur Installation der derzeit aktuellen Version geht man folgendermaßen vor:

# cd /usr/src
# tar xvfz /pub/net/NetKit-B-0.08.tar.gz
# cd NetKit-B-0.08
# more README
# vi MCONFIG
# make
# make install

Adressen

Die reinen Internet Protokoll Adressen bestehen aus 4 Bytes. Standardmäßig schreibt man diese in einer durch Punkte getrennten Dezimalschreibweise: Jedes Byte wird in eine Dezimalzahl umgewandelt (0-255), wobei führende Nullen weggelassen werden, außer wenn die Zahl Null ist. Diese vier Zahlen werden dann, durch einen Dezimalpunkt ».« getrennt, hintereinander aufgeschrieben. Für gewöhnlich bekommt jedes Interface eines Rechners eine eigene IP Adresse. Es ist zwar erlaubt, daß verschiedene Schnittstellen eines Rechners dieselbe Adresse verwenden, dies wird aber normalerweise nicht gemacht.

Ein Internet Protokoll Netzwerk besteht aus einer fortlaufenden Sequenz von IP Adressen. Alle Adressen innerhalb eines solchen Netzwerkes haben einige Ziffern mit den anderen gemeinsam. Dieser übereinstimmende Teil wird als »Netzwerk-Anteil« bezeichnet, die verbleibenden Ziffern bilden den Host-Anteil (Rechner-Teil). Die Anzahl an Bits die bei allen Adressen im Netz gleich ist, bezeichnet man als Netmask. Ihre Aufgabe ist es, festzustellen, ob ein Rechner zu diesem Netzwerk gehört, oder nicht. Hier ein Beispiel:

-----------------  ---------------
Host Address       192.168.110.23
Network Mask       255.255.255.0
Network Portion    192.168.110.
Host portion                  .23
-----------------  ---------------
Network Address    192.168.110.0
Broadcast Address  192.168.110.255
-----------------  ---------------

Jede Adresse, die bitweise mit der Netmask durch ein logisches UND verknüpft wird, ergibt so die Adresse des Netzwerkes, zu der sie gehört. Die Netzwerk-Adresse besitzt deshalb immer die kleinste Nummer aus dem Bereich des Netzwerkes, und der Host-Anteil ist immer Null.

Die Broadcast Adresse ist eine besondere Adresse, auf die jeder Rechner eines Netzwerkes zusätzlich zu seiner eigenen, eindeutigen reagiert. An diese Adresse werden Datagramme gesendet, die jeder Rechner im Netzwerk erhalten soll. Einige besondere Datentypen wie Routing-Informationen oder Warnungen werden über diese Broadcast Adresse verbreitet, damit alle Rechner sie sofort erhalten. Es gibt zwei verwendete Standards dafür, wie eine solche Broadcast Adresse aussieht. Am weitesten verbreitet ist es, die höchste Nummer des Adressbereiches zu verwenden, im obigen Beispiel also die 192.168.110.255. An einigen Stellen wird auch die Netzwerk-Adresse für diesen Zweck verwendet. In der Praxis ist es egal, welche dieser Adressen verwandt wird. Es muß nur sichergestellt sein, daß alle Rechner des Netzes mit derselben Broadcast-Adresse konfiguriert werden.

In einer recht frühen Phase der Entwicklung des IP Protokolles wurden einige willkürlich gewählte Bereiche des Adressraumes zu Netzwerken zusammengefaßt, die man als Klassen bezeichnet. Diese Klassen stellen die Standard-Größen für ein Netzwerk dar, die Aufteilung ist wie folgt:

------------------------------------------------------------
|  Netzwerk | Netmask       | Netzwerk Adressen            |
|  Klasse   |               |                              |
------------------------------------------------------------
|     A     | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
|     B     | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
|     C     | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
| Multicast | 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
------------------------------------------------------------

Welcher dieser Adressen man verwenden sollte, hängt vom jeweiligen Fall ab; eventuell muß man eine Kombination der unten aufgeführten Aktionen durchführen.

Anbinden eines einzelnen Linux-Rechners in ein bestehendes Netz

In diesem Fall muß man sich an den Administrator des Netzes wenden und ihn um folgende Informationen bitten:

Mit diesen Angaben kann man dann sein Netzwerk unter Linux konfigurieren.

Neubildung eines Netzwerkes, daß keine Verbindung zum Internet hat

Wer sich ein kleines privates Netzwerk zulegen will und nicht beabsichtigt, dieses jemals mit dem Internet zu verbinden, kann im Prinzip seine Adressen völlig frei auswählen. Aus Sicherheitsgründen, und um trotzdem eine gewisse Konsistenz in der Adressenvergabe zu wahren, wurden jedoch einige Bereiche des Adressraumes speziell für diesen Zweck reserviert. Sie sind im RFC 1597 festgelegt:

------------------------------------------------------------
|            Adressbereiche f. private Nutzung             |
------------------------------------------------------------
| Netzwerk | Netmask       | Netzwerk Adressen             |
| Klasse   |               |                               |
------------------------------------------------------------
|    A     | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
|    B     | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
|    C     | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
------------------------------------------------------------

Zuerst sollte man sich überlegen, wie groß das eigene Netz sein soll und dann einen geeigneten Bereich auswählen.

4.2 Wo muß ich die Konfiguration durchführen?

Unter Linux gibt es unterschiedliche Ansätze, wie die Boot-Prozedur abläuft. In jedem Fall wird aber, nachdem der Kernel geladen ist, ein Programm mit dem Namen init gestartet. init liest dann die Konfigurationsdatei /etc/inittab und beginnt den eigentlichen Boot-Prozeß. Es gibt verschiedene Versionen des init-Programmes, und das ist auch bereits der Hauptgrund für die unterschiedlichen Bootkonzepte der verschiedenen Distributionen.

Für gewöhnlich enthält /etc/inittab einen Eintrag der Form

si::sysinit:/etc/init.d/boot

Diese Zeile legt den Namen desjenigen Shell-Scriptes fest, das den Bootprozeß steuert. In gewisser Weise handelt es sich um das Äquivalent zu der Datei AUTOEXEC.BAT in DOS.

Meist werden von diesem Script aus weitere Scripte aufgerufen, und oft ist eines davon dann für die Konfiguration des Netzwerkes zuständig.

Die folgende Tabelle gibt einen Anhaltspunkt, welche Dateien das für die diversen Distributionen sind:

-------------------------------------------------------------------------------
Distrib. |Schnittstellen Konfig./Routing              |Server Initialisierung
-------------------------------------------------------------------------------
Debian   |/etc/init.d/network                         |/etc/init.d/netbase     
         |                                            |/etc/init.d/netstd_init
         |                                            |/etc/init.d/netstd_nfs
         |                                            |/etc/init.d/netstd_misc
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1                          |/etc/rc.d/rc.inet2 
-------------------------------------------------------------------------------
RedHat   |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------

Die meisten modernen Distributionen stellen ein Programm zur Verfügung, mit dem man die gängigsten Netzwerk Schnittstellen konfigurieren kann. Es lohnt sich auf jeden Fall, diese Programme auszuprobieren, bevor man sich an eine manuelle Installation macht.

--------------------------------------------
Distrib   | Netzwerk Konfigurations Programm
--------------------------------------------
RedHat    | /sbin/netcfg
Slackware | /sbin/netconfig
--------------------------------------------

4.3 Anlegen der Netzwerk Schnittstellen

In vielen Varianten von Unix haben die verschiedenen Netzwerk Devices feste Einträge im Verzeichnis /dev. Nicht so bei Linux. Hier werden diese Einträge dynamisch von der Software angelegt, die entsprechenden Dateien in /dev müssen also nicht vorhanden sein.

In fast allen Fällen werden die Device-Einträge für das Netzwerk automatisch von den jeweiligen Treibern angelegt, sobald diese bei der Initialisierung die entsprechende Hardware vorfinden. So legt der Ethernet-Treiber z.B. die Schnittstellen eth[0..n] an, durchnumeriert in der Reihenfolge, in der die Hardware gefunden wird. Der ersten Karte wird der Eintrag eth0 zugeordnet, der zweiten eth1 usw.

Manche Device-Einträge, insbesondere für SLIP und PPP, werden jedoch erst aufgrund von Benutzerprogrammen angelegt. Auch in diesem Fall gilt die sequentielle Durchnumerierung, sie werden eben nur nicht bereits beim Booten des Systems angelegt. Das liegt daran, daß sich die Anzahl der aktiven SLIP oder PPP Geräte bei laufendem Betrieb ändern kann - im Gegensatz zu Ethernetkarten. Diese Fälle werden später genauer behandelt.

4.4 Konfiguration der Netzwerk Schnittstelle

Hat man sich alle benötigten Programme und Informationen besorgt, kann mit der Konfiguration der Netzwerk Schnittstelle begonnen werden. Mit Konfiguration ist dabei gemeint, der Schnittstelle die Adresse zuzuteilen sowie für andere einstellbare Parameter die richtigen Werte einzusetzen. Das hierfür am meisten verwendete Programm ist ifconfig, was für Interface Configure, also Schnittstellenkonfiguration, steht.

Ein typisches Beispiel für den Einsatz von ifconfig ist etwa

# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
In diesem Fall wird die Schnittstelle eth0 mit der Adresse 192.168.0.1 sowie der Netmask 255.255.255.0 konfiguriert. Das abschließende up aktiviert die Schnittstelle.

Der Kernel hat einige voreingestellte Standardwerte für viele der Konfigurationsparameter. So kann man natürlich Netzwerkadresse und Broadcastadresse für eine Schnittstelle festlegen. Tut man dies nicht, wie im obigen Beispiel, dann versucht der Kernel für diese Parameter vernünftige Werte anzunehmen. Dies macht er anhand der Netzwerk-Klasse der angegebenen IP-Adresse. In diesem Fall wäre das ein Klasse-C Netz, dementsprechend benutzt der Kernel 192.168.0.0 als Netzwerk-Adresse und 192.168.0.255 als Broadcast-Adresse.

ifconfig besitzt unzählige Parameter. Die wichtigsten davon sind

up

Aktiviert die Schnittstelle.

down

Deaktiviert die Schnittstelle.

[-]arp

(De-)aktiviert das Protokoll zur Auflösung von Adressen (address resolution protocol) für diese Schnittstelle.

[-]allmulti

(De-)aktiviert den sogenannten »promiscuous mode«. In diesem Modus kann man eine Schnittstelle anweisen auch Datenpakete anzunehmen, die nicht an diese Schnittstelle adressiert sind. Dies ist sehr wichtig für Programme wie tcpdump.

mtu N

Legt die MTU fest.

netmask addr

Legt die Netmask für die Schnittstelle fest.

irq addr

Legt den verwendeten Interrupt der Hardware fest. Dies funktioniert aber nur für einige wenige Geräte.

[-]broadcast [addr]

Damit kann die Adresse für Broadcast-Meldungen festgelegt werden oder die Annahme solcher Pakete abgeschaltet werden.

[-]pointopoint [addr]

Hiermit wird die Adresse des Rechners am anderen Ende der Verbindung festgelegt. Dieses findet z.B. im Falle von SLIP und PPP Verbindungen Verwendung.

hw <type> <addr>

Damit lassen sich für bestimmte Netzwerk-Typen die Hardware Adressen festlegen. Das ist für Ethernet kaum nützlich, für andere Typen wie AX.25 aber schon.

ifconfig kann im Prinzip zur Konfiguration jeder beliebigen Netzwerk Schnittstelle verwendet werden. Einige Programme wie pppd oder dip machen dies jedoch selbständig, sodaß sich ein manueller Aufruf von ifconfig in diesem Fall erübrigt.

4.5 Konfiguration des Name Resolver

Der Name Resolver ist ein Teil der Standardbibliothek von Linux. Seine Aufgabe ist es, benutzerfreundliche Rechnernamen wie ftp.funet.fi in rechnerfreundliche IP-Adressen wie 128.214.248.6 zu übersetzen.

Aus was besteht ein Name?

Jeder ist wohl inzwischen mit Rechnernamen im Internet vertraut, doch mancher versteht nicht genau, wie sie gebildet werden. Namen im Internet haben eine hierarchische Struktur, bilden also so etwas wie einen Baum mit Verästelungen. Eine Domain ist eine Gruppe von Namen. Eine solche Domain kann wiederum unterteilt sein in mehrere Subdomains. Eine Toplevel Domain ist eine Domain, die nicht mehr Subdomain einer anderen ist. Diese Toplevel Domains sind im RFC 920 festgelegt. Beispiele für die bekanntesten Toplevel Domains sind:

COM

Kommerzielle Organisationen

EDU

Bildung und Lehre

GOV

Regierungsstellen

MIL

Militärische Organisationen

ORG

Andere Organisationen

Länderkennzeichen

Diese sind gebildet aus zwei Buchstaben, die für ein Land stehen.

Jede dieser höchsten Domänen hat nun Unterdomänen. So gibt es für viele Länder wieder eine Unterteilung entsprechend der höchsten Domänen, also etwa com.au und gov.au für kommerzielle und staatliche Organisationen in Australien. Aus historischen Gründen liegen praktisch alle nicht länderspezifischen Toplevel Domänen in den USA, obwohl auch diese einen spezifischen Länder-Code (.us) besitzen.

Die nächste Ebene der Unterteilung stellt meist der Name der Organisation dar. Weitere Unterdomänen sind dann sehr unterschiedlich, oft basieren sie auf internen Strukturen der jeweiligen Organisation, jedoch kann der Netzadministrator jedes ihm sinnvoll erscheinende Kriterium zur Unterteilung verwenden.

Der erste, am weitesten links stehende Teil des Namens ist immer der eindeutige Name des jeweiligen Rechners, man bezeichnet ihn als hostname, der übrige Teil rechts davon wird domainname genannt. Beide zusammen bilden den Fully Qualified Domain Name.

Am Beispiel meines eigenen Email Rechners ist der vollständige Domainname perf.no.itg.telstra.com.au. Das heißt, der Rechnername (hostname) ist perf, der domainname no.itg.telstra.com.au. Die oberste Domain (toplevel domain) ist Australien (.au) und es handelt sich um eine kommerzielle Organisation (.com). Der Name der Firma ist telstra, und die Namensgebung der internen Unterdomänen basiert auf der Firmenstruktur, in diesem Fall befindet sich der Rechner in der Information Technology Group, Sektion Network Operation.

Welche Informationen brauche ich?

Natürlich muß man wissen, zu welcher Domäne der Rechner gehören soll. Weiterhin benötigt die Software, die das Übersetzen von Namen in gültige IP-Adressen übernimmt, die Adresse eines Domain Name Servers, dessen IP-Nummer man sich ebenfalls besorgen muß.

Es gibt insgesamt drei Dateien, die editiert werden müssen, auf jede von ihnen wird im folgenden eingegangen.

/etc/resolv.conf

/etc/resolv.conf ist die zentrale Konfigurationsdatei für den Name Resolver. Das Format ist sehr einfach, es ist eine Textdatei mit einem Schlüsselwort pro Zeile. Normalerweise werden drei davon benutzt, dies sind:

domain

Dieser Eintrag bestimmt den Namen der lokalen Domain.

search

Mit diesem Eintrag kann man die Namen von zusätzlichen Domänen angeben, in denen nach einem Hostnamen gesucht wird.

nameserver

Mit diesem Eintrag - es können mehrere davon angegeben werden - gibt man die IP Adresse eines Domain Name Servers an.

Eine typische Datei /etc/resolv.conf sieht etwa so aus:

domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1

In diesem Beispiel ist der Standard Domain Name, der an nicht vollständige angegebene Rechnernamen angehängt wird, maths.wu.edu.au. Wird der Rechner in dieser Domain nicht gefunden, wird auch in der Domäne wu.edu.au gesucht. Weiterhin sind zwei unabhängige Nameserver Einträge vorhanden. Beide können von der Name Resolver Software benutzt werden, um Namen aufzulösen.

/etc/host.conf

In der Datei /etc/host.conf können einige Verhaltensweisen der Name Resolving Software festgelegt werden. Das Format dieser Datei ist ausführlich in der Online Hilfe zu resolv(8) beschrieben. Jedoch wird in praktisch allen Fällen das folgende Beispiel ausreichend sein:

                          
order hosts,bind                                          
multi on  

Mit diesen Einträgen wird festgelegt, daß die Software zunächst in der Datei /etc/hosts nach einer Namen - Adressen Zuordnung sucht, bevor der Nameserver gefragt wird. Außerdem sollen alle gültigen Adresseinträge, die in /etc/hosts gefunden werden, als Antwort geliefert werden, und nicht nur der erste.

/etc/hosts

In der Datei /etc/hosts können die IP Adressen von lokalen Rechnern eingetragen werden. Ein Rechner, dessen Namen in dieser Datei auftaucht, wird auch ohne eine Nachfrage bei dem Domain Name Server gefunden. Der Nachteil dabei ist aber, daß man diese Datei selber auf dem aktuellen Stand halten muß, wenn sich die IP Adresse eines hier eingetragenen Rechners ändert. In einem gut verwalteten System wird man hier meist nur Einträge für das Loopback Interface sowie den lokalen Rechnernamen vorfinden:

# /etc/hosts
127.0.0.1      localhost loopback
192.168.0.1    name.dieses.rechners

Wie man am ersten Eintrag sieht, sind auch mehrere Namen je Adresseintrag erlaubt.

4.6 Die Konfiguration des Loopback Interface

Das loopback Interface ist eine spezielle Schnittstelle, über die man eine Verbindung zum eigenen Rechner aufbauen kann. Es gibt einige Gründe, warum dies sinnvoll sein kann, zum Beispiel wenn man Netzwerk Software testen will, ohne dabei von anderen Teilnehmern des Netzes gestört zu werden. Die Standard IP Adresse für dieses Loopback Interface ist 127.0.0.1. Unabhängig, auf welchem Rechner man arbeitet, ein

telnet 127.0.0.1
baut immer eine Verbindung zum lokalen Rechner auf.

Die Konfiguration dieser Schnittstelle ist äußerst einfach und sollte auf jeden Fall vorgenommen werden:

# ifconfig lo 127.0.0.1
# route add -host 127.0.0.1 lo

Der route-Befehl wird im nächsten Kapitel ausführlich behandelt.

4.7 Routing

Routing ist ein wichtiges Thema, es ließen sich leicht Bände damit füllen. Obwohl die meisten nur recht geringe Ansprüche an das Routing haben, trifft das für einige nicht zu. Im folgenden werden nur die grundlegenden Aspekte des Routing behandelt. Wer weitergehende Informationen zu diesem Thema benötigt, der sei auf die Literaturhinweise zu Beginn dieses Dokumentes verwiesen.

Zunächst zum Begriff selber: Was ist IP Routing? Hier ist die Definition, die ich selber verwende:

IP Routing ist der Prozeß über den ein Rechner mit unterschiedlichen Netzwerkanbindungen entscheidet, über welche Verbindung ein empfangenes IP Datagramm weitergeleitet werden soll.

Dies soll an einem Beispiel eines typischen Routers in einem Büro verdeutlicht werden. Dieser habe eine PPP Verbindung zum Internet, bedient über einige Ethernet Segmente lokale Workstations und ist über eine weitere PPP Verbindung mit einer Zweigstelle verbunden. Empfängt dieser Router nun ein Datagramm von irgendeiner dieser Verbindungen, so wird über das Routing festgelegt, über welche der Verbindungen das Datagramm weitergereicht wird. Jeder Rechner benötigt das Routing, denn selbst der einfachste Rechner am Internet besitzt mindestens zwei Netzwerk Schnittstellen, nämlich das Loopback Interface sowie die normale Schnittstelle zum restlichen Netzwerk, also Ethernet, PPP oder SLIP.

Also, wie funktioniert nun dieses Routing? Jeder einzelne Rechner hat eine eigene Liste mit Vorschriften für das Routing, man nennt sie die Routing Table. Diese Tabelle enthält Zeilen mit typischerweise mindestens drei Spalten. Die erste Spalte enthält die Zieladresse, die zweite Spalte die Schnittstelle, über die das Datenpaket weitergeleitet werden soll, und die dritte enthält optional die IP Adresse eines anderen Rechners (Gateway), der das Datenpaket zu seinem nächsten Etappenziel leitet. Unter Linux kann man sich diese Tabelle mit dem folgenden Befehl ansehen:

# cat /proc/net/route
Der eigentliche Vorgang des Routing ist sehr einfach: Ein eingehendes Datenpaket wird entgegengenommen, seine Zieladresse wird untersucht und mit den Einträgen in der Tabelle verglichen. Der Eintrag, der der Zieladresse am besten entspricht, wird selektiert und das Datenpaket an die in diesem Eintrag festgelegte Schnittstelle weitergeleitet. Ist für die Adresse auch ein Gateway eingetragen, wird das Paket an diesen Rechner adressiert, andernfalls wird angenommen, daß der Zielrechner zu dem Netzwerk gehört, mit dem die benutzte Schnittstelle verbunden ist.

Um die Routing Table zu verändern, gibt es einen speziellen Befehl. Dieser Befehl übernimmt die Kommandozeilenargumente und setzt sie in die entsprechenden Systemaufrufe um, die den Kernel dazu veranlassen, die entsprechenden Einträge in der Routing Table hinzuzufügen, zu entfernen oder zu verändern. Aus naheliegenden Gründen heißt dieser Befehl route.

Ein einfaches Beispiel: Nehmen wir an, wir befinden uns an einem Ethernet Netzwerk. Es sei ein Klasse C Netz mit der Adresse 192.168.1.0. Unsere eigene IP Adresse ist 192.168.1.10, und der Rechner 192.168.1.1 ist ein Router mit Verbindung zum Internet.

Zunächst muß natürlich die Schnittstelle wie bereits beschrieben konfiguriert werden, also etwa

# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
Als nächstes muß in die Routing Table eingetragen werden, daß Datagramme an alle Adressen 192.168.1.* direkt über das Ethernet Device eth0 geleitet werden:
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
Über den Schalter -net im obigen Befehl wird dem route Programm mitgeteilt, daß es sich um einen Eintrag für ein ganzes Netzwerk handelt. Die andere Alternative ist ein Eintrag host, bei dem nur eine einzige IP Adresse eingegeben wird.

Mittels diesem Eintrag ist der eigene Rechner nun in der Lage, zu allen anderen Rechnern im lokalen Ethernet IP Verbindungen aufzubauen. Doch was ist mit Rechnern, die sich außerhalb dieses Netzes befinden?

Es wäre sehr umständlich und nicht praktikabel, für jedes denkbare Netzwerk einen entsprechenden Eintrag anzufügen. Aus diesem Grund gibt es eine Standardeinstellung in der festgelegt wird, wie mit Paketen zu verfahren ist, die nicht gesondert in der Routing Table aufgeführt sind: die Default Route. Im obigen Beispiel heißt das: Alles was nicht im lokalen Netz ist, wird über den Router weitergeleitet - der wird dann schon wissen, wie mit dem Paket zu verfahren ist. Den entsprechenden Eintrag in der Routing Table erzeugt man folgendermaßen:

# route add default gw 192.168.1.1 eth0
Durch den Parameter gw wird dem route-Befehl mitgeteilt, daß die folgende Adresse die IP-Adresse eines Gateway Rechners oder eines Routers ist, an den die Pakete weitergeleitet werden.

Die komplette Konfiguration sieht also so aus:

# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
# route add default gw 192.168.1.1 eth0
Ein Blick in die rc-Dateien, die beim Bootprozeß das Netzwerk initialisieren, sollte ähnliche Einträge wenn auch mit anderen Adressen zu Tage bringen, denn es ist eine sehr verbreitete Konfiguration.

Wir können uns nun an ein etwas komplizierteres Beispiel wagen. Nehmen wir an, wir wollten einen einfachen Router konfigurieren, z.B. den bereits erwähnten mit mehreren lokalen Netzen und einer PPP Verbindung zum Internet. Für drei lokale Ethernet Segmente würde die Routing Tabelle etwa folgendermaßen aufgebaut:

# route add 192.168.1.0 netmask 255.255.255.0 eth0
# route add 192.168.2.0 netmask 255.255.255.0 eth1
# route add 192.168.3.0 netmask 255.255.255.0 eth2
# route add default ppp0
Für jede der an diesen Router angeschlossenen Workstations hätte die Routing Tabelle dieselbe einfache Form wie im vorangegangenen Beispiel. Lediglich der Router muß alle drei Netzwerke separat aufführen, da er ja die Aufteilung der Datenpakete auf diese Netze durchführen muß. Bleibt also nur noch die Frage, warum in der default route der Eintrag gw fehlt. Der Grund dafür ist, daß es sich bei einer PPP-Verbindung wie auch bei einer Verbindung über das SLIP Protokoll um eine Verbindung zwischen genau zwei Rechnern handelt. Der Kernel »weiß« also, welchen Rechner er über die PPP-Verbindung anspricht, und die zusätzliche Angabe einer Gateway-Adresse ist in diesem Falle überflüssig. Lediglich für Ethernet-, Arcnet- oder Token Ring Verbindungen ist die Angabe einer Gatewayadresse zwingend vorgeschrieben, da hier über eine Verbindung eine große Zahl an Rechnern erreicht werden kann.

Was macht das routed Programm?

Die oben beschriebene Konfiguration ist optimiert auf einfache Netzwerke mit nur wenigen, unveränderlichen Pfaden zu den unterschiedlichen Zielen. In einem komplexen Netzwerk werden die Dinge jedoch etwas schwieriger. Doch zum Glück betrifft das nur die wenigsten.

Das größte Problem des manuellen oder statischen Routing, das im vorigen Abschnitt beschrieben wurde, tritt auf, wenn ein Rechner im Netzwerk ausfällt, der als Router arbeitet. In diesem Fall besteht die einzige Möglichkeit, ein Datenpaket dennoch zum Ziel weiterzuleiten darin, von Hand einzugreifen und die entsprechenden Routes manuell zu ändern - vorausgesetzt natürlich, es existiert solch ein alternativer Weg. Das ist umständlich, langsam und fehleranfällig. Deshalb wurden unterschiedliche Mechanismen entwickelt, um die Routing Tabelle automatisch anzupassen, falls ein Netzwerkfehler auftritt und »Umwege« zum Ziel bekannt sind. All diese Techniken bezeichnet man als dynamische Routing Protokolle.

Die bekanntesten dynamischen Protokolle sind RIP (Routing Information Protocol) und OSPF (Open Shortest Path First Protocol). RIP ist besonders in kleinen Netzwerken wie mittelgroßen Betrieben oder Gebäude-Netzwerken sehr verbreitet. OSPF ist moderner und insbesondere darauf ausgelegt, in großen Netzwerken benutzt zu werden, in denen es eine große Zahl an Wegen durch das Netzwerk gibt. Die am weitesten verbreiteten Vertreter dieser Protokolle sind routed (RIP) und gated (OSPF). routed ist normalerweise Bestandteil jeder Linux Distribution, ansonst bekommt man es mit dem Paket NetKit (s.o.).

Ein Beispiel für die Verwendung dynamischen Routings ist die folgende Konfiguration:

    192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                      255.255.255.0
Es gibt drei Router: A, B und C. Jeder ist für ein Ethernet Segment mit einem Klasse C IP Netzwerk (Netmask 255.255.255.0) zuständig. Darüberhinaus verfügt jeder Router über jeweils eine PPP-Verbindung zu jedem der anderen beiden Router; diese bilden also ein Dreieck.

Ganz offensichtlich könnte die Routing Tabelle für Router A folgendermaßen aussehen:

# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
Dies funktioniert aber nur, solange die Verbindung zwischen Router A und B besteht. Bricht diese Verbindung zusammen, können Rechner des Ethernet Segmentes von Router A keinen Rechner des Segmentes von Router B mehr erreichen, da A die Datagramme über die PPP-Verbindung an B weiterreichen will. Sie können immernoch Verbindungen zu den Rechnern des Segmentes C aufbauen, und diese wiederum können problemlos mit Rechnern im Segment B kommunizieren, da die Verbindung zwischen B und C immernoch besteht.

Es wäre also naheliegend daß A die an B gerichteten Pakete an C sendet und diese dann von C an B weitergeleitet werden. Für genau diese Art von Problemen sind die dynamischen Protokolle wie RIP ausgelegt. Würde auf jedem der drei Router A, B und C ein Routing Daemon laufen, würden diese im Falle eines Netzwerkfehlers die Routing Tabellen der drei Router automatisch den neuen Gegebenheiten anpassen. Ein derartiges Netz zu konfigurieren ist sehr einfach, es sind lediglich zwei Schritte notwendig. Hier das Beispiel für Router A:

# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# /usr/sbin/routed
Der Routing Daemon routed erkennt beim Start automatisch alle aktiven Netzwerkschnittstellen und sendet und erkennt über diese Schnittstellen Meldungen, um festzustellen, ob Änderungen in der Routing Tabelle nötig sind.

Die war nur eine sehr kurze Beschreibung, was dynamisches Routing ist, und in welchen Fällen man es verwendet. Wer genauere Informationen benötigt, sei auf die am Anfang dieses Textes genannten Quellen verwiesen.

Wichtige Punkte im Zusammenhang mit dynamischen Routing sind:

  1. Einen Routing Daemon benötigt nur, wer auf seinem Rechner mehrere verschiedene mögliche Routes zu einer Zieladresse besitzt.
  2. Der Routing Daemon ändert automatisch die Routing Table, um sie an Änderungen im Netzwerk anzupassen.
  3. RIP ist für kleine und mittelgroße Netzwerke ausgelegt.

4.8 Die Konfiguration von Netzwerk Servern und Diensten

Netzwerk Server und Dienste bezeichnet diejenigen Programme, die es einem Nutzer von außerhalb (remote user) erlauben, ihren Rechner zu benutzen. Dieser Nutzer stellt eine Netzwerkverbindung zu ihrem Rechner, oder besser zu einem Server-Programm auf ihrem Rechner, her. Dieser Server, man nennt ihn auch Netzwerk Daemon, überwacht einen Port. Er nimmt ankommende Verbindungswünsche entgegen und führt dann die jeweiligen Aktionen aus. Es gibt zwei unterschiedliche Methoden, wie ein solcher Netzwerk-Daemon arbeitet:

Standalone

Der Daemon überwacht selber den Port. Im Falle einer ankommenden Verbindung übernimmt der Daemon selbst die Arbeit und stellt die gewünschte Dienstleistung zur Verfügung.

inetd Servers

Der inetd Server ist ein besonderer Daemon, der allgemein darauf spezialisiert ist, eingehende Netzwerkverbindungen zu beantworten. Er besitzt eine eigene Konfigurationsdatei, in der festgelegt wird, welche Programme er starten muß, wenn auf einem Port eine TCP oder UDP Anfrage eintrifft. Diese Ports werden in einer anderen Datei beschrieben, davon später mehr.

Es gibt zwei wichtige Konfigurationsdateien, die an die eigenen Bedürfnisse angepaßt werden müssen. Dies sind /etc/services, in der den unterschiedlichen Portnummern Namen zugeordnet werden, und /etc/inetd.conf, die Konfigurationsdatei des inetd Netzwerk Daemons.

/etc/services

Die Datei /etc/services ist eine einfache Datenbasis, die jedem Port einen für Menschen leichter verständlichen Namen zuordnet. Das Format dieser Datei ist sehr einfach: Es handelt sich um eine Textdatei, und jede Zeile stellt einen Eintrag der Datenbasis dar. Ein solcher Eintrag besteht aus drei Feldern, die durch beliebig viele Leerzeichen getrennt sind. Diese drei Felder sind:

Name      Port/Protokoll       Aliases     # Kommentar
Name

Ein einzelnes Wort, welches den jeweiligen Service beschreibt.

Port/Protokoll

Dieses Feld besteht aus zwei Einträgen.

Port

Eine Zahl, die die Portnummer angibt, unter der der jeweilige Service angesprochen werden kann. Die meisten der üblichen Services haben festgelegte Nummern. Dieses wird in RFC 1340 beschrieben.

Protokoll

Je nach verwendetem Protokoll steht hier tcp oder udp.

Es ist wichtig darauf hinzuweisen, daß ein Eintrag 18/tcp etwas ganz anderes ist als ein Eintrag 18/udp. Es gibt keinen technischen Grund, warum ein Service über beide Protokolle zur Verfügung stehen sollte. Nur in seltenen Ausnahmefällen ist dies der Fall, dann wird man beide Einträge, also für udp und tcp finden.

Aliases

Zusätzliche Namen, unter denen dieser Service angesprochen werden kann.

Jeglicher Text nach dem Hash-Zeichen (#) wird ignoriert.

Ein Beispiel für /etc/services

Alle modernen Linux Distributionen enthalten bereits eine gute Version dieser Datei. Falls aber jemand seinen eigenen Rechner von Grund auf selber aufbauen will, hier ist die mit der Debian Distribution gelieferte Version.

# /etc/services:
# $Id: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $
#
# Netzwerk Dienstes, Internet Ausführung
#
# Man beachte, daß es zur Zeit die Politik von IANA ist, eine einzelne,
# gut bekannte Port Nummer sowohl für TCP als auch UDP zuzuweisen. Daher
# gibt es oft auch einen UDP Eintrag, obwohl das entsprechende Protokoll
# UDP garnicht unterstützt.
# Aktualisiert durch RFC 1340, "Assigned Numbers" (Juli 1992). Nicht
# alle Ports sind enthalten, sondern nur die weiter verbreiteten.

tcpmux          1/tcp                           # TCP port service multiplexer
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
qotd            17/tcp          quote
msp             18/tcp                          # message send protocol
msp             18/udp                          # message send protocol
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp
ftp             21/tcp
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp                          # SSH Remote Login Protocol
telnet          23/tcp
# 24 - privat
smtp            25/tcp          mail
# 26 - nicht zugewiesen
time            37/tcp          timserver
time            37/udp          timserver
rlp             39/udp          resource        # resource location
nameserver      42/tcp          name            # IEN 116
whois           43/tcp          nicname
re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
re-mail-ck      50/udp                          # Remote Mail Checking Protocol
domain          53/tcp          nameserver      # name-domain server
domain          53/udp          nameserver
mtp             57/tcp                          # deprecated
bootps          67/tcp                          # BOOTP server
bootps          67/udp
bootpc          68/tcp                          # BOOTP client
bootpc          68/udp
tftp            69/udp
gopher          70/tcp                          # Internet Gopher
gopher          70/udp
rje             77/tcp          netrjs
finger          79/tcp
www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol
link            87/tcp          ttylink
kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
kerberos        88/udp          kerberos5 krb5  # Kerberos v5
supdup          95/tcp
# 100 - reserviert
hostnames       101/tcp         hostname        # usually from sri-nic
iso-tsap        102/tcp         tsap            # part of ISODE.
csnet-ns        105/tcp         cso-ns          # also used by CSO name server
csnet-ns        105/udp         cso-ns
rtelnet         107/tcp                         # Remote Telnet
rtelnet         107/udp
pop-2           109/tcp         postoffice      # POP version 2
pop-2           109/udp
pop-3           110/tcp                         # POP version 3
pop-3           110/udp
sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
auth            113/tcp         authentication tap ident
sftp            115/tcp
uucp-path       117/tcp
nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
ntp             123/tcp
ntp             123/udp                         # Network Time Protocol
netbios-ns      137/tcp                         # NETBIOS Name Service
netbios-ns      137/udp
netbios-dgm     138/tcp                         # NETBIOS Datagram Service
netbios-dgm     138/udp
netbios-ssn     139/tcp                         # NETBIOS session service
netbios-ssn     139/udp
imap2           143/tcp                         # Interim Mail Access Proto v2
imap2           143/udp
snmp            161/udp                         # Simple Net Mgmt Proto
snmp-trap       162/udp         snmptrap        # Traps for SNMP
cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
cmip-man        163/udp
cmip-agent      164/tcp
cmip-agent      164/udp
xdmcp           177/tcp                         # X Display Mgr. Control Proto
xdmcp           177/udp
nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
nextstep        178/udp         NeXTStep NextStep       # server
bgp             179/tcp                         # Border Gateway Proto.
bgp             179/udp
prospero        191/tcp                         # Cliff Neuman's Prospero
prospero        191/udp
irc             194/tcp                         # Internet Relay Chat
irc             194/udp
smux            199/tcp                         # SNMP Unix Multiplexer
smux            199/udp
at-rtmp         201/tcp                         # AppleTalk routing
at-rtmp         201/udp
at-nbp          202/tcp                         # AppleTalk name binding
at-nbp          202/udp
at-echo         204/tcp                         # AppleTalk echo
at-echo         204/udp
at-zis          206/tcp                         # AppleTalk zone information
at-zis          206/udp
z3950           210/tcp         wais            # NISO Z39.50 database
z3950           210/udp         wais
ipx             213/tcp                         # IPX
ipx             213/udp
imap3           220/tcp                         # Interactive Mail Access
imap3           220/udp                         # Protocol v3
ulistserv       372/tcp                         # UNIX Listserv
ulistserv       372/udp
#
# spezielle UNIX Dienste
#
exec            512/tcp
biff            512/udp         comsat
login           513/tcp
who             513/udp         whod
shell           514/tcp         cmd             # no passwords used
syslog          514/udp
printer         515/tcp         spooler         # line printer spooler
talk            517/udp
ntalk           518/udp
route           520/udp         router routed   # RIP
timed           525/udp         timeserver
tempo           526/tcp         newdate
courier         530/tcp         rpc
conference      531/tcp         chat
netnews         532/tcp         readnews
netwall         533/udp                         # -for emergency broadcasts
uucp            540/tcp         uucpd           # uucp daemon
remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
klogin          543/tcp                         # Kerberized `rlogin' (v5)
kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
#
webster         765/tcp                         # Network dictionary
webster         765/udp
#
# Aus "Assigned Numbers":
#
#> Die registrierten Ports werden nicht von der IANA kontrolliert
#> und können auf den meisten Systemen von Prozessen gewöhnlicher
#> Benutzer verwendet werden.
#
#> Ports werden in TCP [45,106] verwendet, um die Endpunkte von
#> logischen Verbindungen, die für länger dauernden Austausch
#> von Daten verwendet werden, zu kennzeichnen. Um Dienste für
#> unbekannte Nutzer anzubieten, wird ein Port definiert, um
#> Kontakt zu diesem Service aufzunehmen. Diese Liste definiert die
#> Ports, die von den Server Prozessen für die Kontaktaufnahme 
#> verwendet werden. Während IANA die Benutzung dieser Ports nicht
#> kontrollieren kann, registriert sie die Verwendung dieser Ports.
#
ingreslock      1524/tcp
ingreslock      1524/udp
prospero-np     1525/tcp                # Prospero non-privileged
prospero-np     1525/udp
rfe             5002/tcp                # Radio Free Ethernet
rfe             5002/udp                # Actually uses UDP only
bbs             7000/tcp                # BBS service
#
#
# Kerberos (Athena/MIT Projekt) Dienste
# Man beachte, daß diese für Kerberos v4 und nicht offiziell sind.
# Auf Rechner, die v4 verwenden, sollte vor diesen das Hash Zeichen
# entfernt werden und die obigen v5 Einträge auskommentiert werden.
#
kerberos4       750/udp         kdc     # Kerberos (server) udp
kerberos4       750/tcp         kdc     # Kerberos (server) tcp
kerberos_master 751/udp                 # Kerberos authentication
kerberos_master 751/tcp                 # Kerberos authentication
passwd_server   752/udp                 # Kerberos passwd server
krb_prop        754/tcp                 # Kerberos slave propagation
krbupdate       760/tcp         kreg    # Kerberos registration
kpasswd         761/tcp         kpwd    # Kerberos "passwd"
kpop            1109/tcp                # Pop with Kerberos
knetd           2053/tcp                # Kerberos de-multiplexor
zephyr-srv      2102/udp                # Zephyr server
zephyr-clt      2103/udp                # Zephyr serv-hm connection
zephyr-hm       2104/udp                # Zephyr hostmanager
eklogin         2105/tcp                # Kerberos encrypted rlogin
#
# Nicht offizielle aber (für NetBSD) notwenige Dienste
#
supfilesrv      871/tcp                 # SUP server
supfiledbg      1127/tcp                # SUP debugging
#
# Datagram Delivery Protocol Dienste
#
rtmp            1/ddp                   # Routing Table Maintenance Protocol
nbp             2/ddp                   # Name Binding Protocol
echo            4/ddp                   # AppleTalk Echo Protocol
zip             6/ddp                   # Zone Information Protocol
#
# Debian GNU/Linux Dienste
rmtcfg          1236/tcp                # Gracilis Packeten remote config server
xtel            1313/tcp                # french minitel
cfinger         2003/tcp                # GNU Finger
postgres        4321/tcp                # POSTGRES
mandelspawn     9359/udp        mandelbrot      # network mandelbrot

# Lokale Dienste

/etc/inetd.conf

Die Datei /etc/inetd.conf ist die Konfigurationsdatei des Server Daemons inetd. Bei einer eingehenden Anfrage nach einem bestimmten Service sieht der Daemon in dieser Datei nach, was zu tun ist. Für jeden Service, den man anbieten will, muß ein entsprechender Eintrag vorhanden sein, in dem festgelegt wird, welcher Daemon bei einer Anfrage gestartet werden soll, und wie dies zu geschehen hat.

Auch hier ist das Dateiformat sehr einfach, es handelt sich ebenfalls um eine reine Textdatei, in der in jeder Zeile ein anzubietender Service beschrieben wird. Das Zeichen # dient als Kommentarzeichen, nachfolgender Text wird ignoriert. Jede Zeile enthält sieben Felder, die jeweils durch eine beliebige Anzahl von Leerzeichen oder Tabulatoren voneinander getrennt sind. Die Bezeichnungen der einzelnen Felder sind folgende:

service  socket_type  proto  flags  user  server_path  server_args
service

Name des Dienstes, entsprechend dem Eintrag in /etc/services.

socket_type

Dieser Eintrag beschreibt den Typ des Socket, der für den Dienst gilt. Erlaubte Einträge sind stream, dgram, raw, rdm und seqpacket. Die Gründe für die Unterteilung sind technischer Natur, aber als Faustregel kann man davon ausgehen, daß praktisch alle TCP basierten Dienste stream verwenden, während UDP basierte Dienste dgram benutzen. Nur in ganz seltenen Fällen wird ein Dienst einen anderen Typ verwenden.

proto

Das für diesen Service gültige Protokoll. Es muß mit dem Eintrag in /etc/services übereinstimmen, normalerweise also entweder tcp oder udp. Für Server, die Sun RPC (Remote Procedure Call) verwenden, lauten die Einträge rpc/tcp oder rpc/udp.

flags

Hier gibt es nur zwei mögliche Einträge. Dem inetd Server wird damit angezeigt, ob das gestartete Serverprogramm den Socket nach dem Start wieder freigibt oder nicht. Danach entscheidet sich, ob für eine weitere eingehende Anfrage ein neuer Prozeß gestartet werden muß, oder ob der laufende Prozeß auch die neuen Anfragen bearbeitet. Die Regeln hierfür sind etwas schwierig, aber auch hier gilt als Faustregel: TCP-Dienste benötigen den Eintrag nowait, UDP-Dienste verwenden wait. Es gibt hier aber etliche Ausnahmen, im Zweifelsfall sollte man sich am Beispiel orientieren.

user

Dieser Eintrag legt den Nutzernamen entsprechend /etc/passwd fest, mit dessen Rechten der Server gestartet wird. Dies wird oft aus Sicherheitsgründen gemacht. Verwendet man hier der Benutzer nobody, so werden die möglichen Folgeschäden eingegrenzt, sollte doch jemand die Sicherheitsmechanismen des Systems umgehen. Allerdings benötigen viele Server die Rechte des Systemadministrators, weshalb hier meist root steht.

server_path

Dies ist der Name inklusive vollem Pfad des zu startenden Servers.

server_args

Dieser Eintrag umfaßt die gesamte restliche Zeile und ist optional. Hier können zusätzliche Argumente für das Serverprogramm übergeben werden.

Ein Beispiel für /etc/inetd.conf

Wie auch im Falle von /etc/services gehört ein funktionierendes /etc/inetd.conf zum Standardumfang jeder Distribution. Der Vollständigkeit halber hier die Version der Debian Distribution.

# /etc/inetd.conf: weitere Informationen finden sich in inetd(8) 
#
# Datenbank der Internet Server Konfiguration
#
#
# Modifiziert für Debian von Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Interne Dienste
#
#echo           stream  tcp     nowait  root    internal
#echo           dgram   udp     wait    root    internal
discard         stream  tcp     nowait  root    internal
discard         dgram   udp     wait    root    internal
daytime         stream  tcp     nowait  root    internal
daytime         dgram   udp     wait    root    internal
#chargen        stream  tcp     nowait  root    internal
#chargen        dgram   udp     wait    root    internal
time            stream  tcp     nowait  root    internal
time            dgram   udp     wait    root    internal
#
# Dieses sind die Standardienste.
#
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
#fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd
#
# Shell, login, exec und talk sind BSD Protokolle.
#
shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd
login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
#exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
#
# Mail, news und uucp Dienste
#
smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd  
#nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
#uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
#comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
#
# POP
#
#pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
#pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
#
# "cfinger" ist für den GNU finger Server, der für Debian verfügbar ist.
# Hinweis: Die augenblickliche Implementation des "finger" Daemons
#          erlaubt es, als "root" gestartet zu werden.
#
#cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
#finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
#netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat
#systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
#
# Der TFTP Dienst wird vor allem für das Booten von anderen Rechner
# angeboten. Auf den meisten Rechnern läuft dieses nur, falls sie als
# Bootserver für andere Rechner dienen.
#
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
#tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
#bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
#
# Kerberos Authentifikation Dienst (muß eventuell verändert werden)
#
#klogin         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
#eklogin        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
#kshell         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
#
# Dienste, die nur auf dem Kerberos Server laufen (muß eventuell 
# verändert werden).
#
#krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
#kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
#
# RPC basierte Dienste
#
#mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
#rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
#rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
#walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
#
# Ende von inetd.conf.
ident           stream  tcp     nowait  nobody  /usr/sbin/identd        identd -i

4.9 Weitere Konfigurationsdateien im Netzwerkumfeld

Es gibt noch eine ganze Reihe an Dateien, die mit der Netzwerkkonfiguration unter Linux zu tun haben. Die meisten davon wird man nie verändern müssen, es lohnt sich aber dennoch, sie kurz zu beschreiben, damit klar wird, was darinsteht, und wozu sie gut sind.

/etc/protocols

/etc/protocols ist eine Datei, in der Protokollnamen und Identifikationsnummern einander zugeordnet werden. Sie wird vorwiegend von Programmierern verwendet, damit sie in ihren Programmen die Dienste anhand ihres Namens verwenden können. Außerdem verwenden Programmen wie tcpdump diese Datei, um anstelle von Nummern Namen ausgeben zu können. Die Standardsyntax dieser Datei ist

Protokollname   Nummer   Alias
Die Datei /etc/protocols der Debian Distribution sieht so aus:
# /etc/protocols:
# $Id: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $
#
# Internet (IP) Protokolle
#
# Für NetBSD basierend auf RFC 1340 (Assigned Numbers, Juli 1992)
# auf den neusten Stand gebracht.

ip      0       IP              # internet protocol, pseudo protocol number
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # Internet Group Management
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
egp     8       EGP             # exterior gateway protocol
pup     12      PUP             # PARC universal packet protocol
udp     17      UDP             # user datagram protocol
hmp     20      HMP             # host monitoring protocol
xns-idp 22      XNS-IDP         # Xerox NS IDP
rdp     27      RDP             # "reliable datagram" protocol
iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
xtp     36      XTP             # Xpress Tranfer Protocol
ddp     37      DDP             # Datagram Delivery Protocol
idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
rspf    73      RSPF            # Radio Shortest Path First.
vmtp    81      VMTP            # Versatile Message Transport
ospf    89      OSPFIGP         # Open Shortest Path First IGP
ipip    94      IPIP            # Yet Another IP encapsulation
encap   98      ENCAP           # Yet Another IP encapsulation

/etc/networks

Die Datei /etc/networks hat eine ähnliche Funktion wie /etc/hosts. Es stellt eine einfache Datenbasis für die Zuordnung von Netzwerknamen und -adressen dar. Der einzige Unterschied zu letzterem besteht darin, daß nur zwei Einträge je Zeile erlaubt sind, und zwar folgendermaßen:

Netzwerkname   Netzwerkadresse

Auch hier ein kleines Beispiel:

loopnet    127.0.0.0
localnet   192.168.0.0
amprnet    44.0.0.0

Bei Programmen wie route wird ein Netzwerk, das einen Eintrag in /etc/networks hat, mit seinem Namen anstelle der reinen Netzwerkadresse angezeigt.

4.10 Netzwerksicherheit und Zugangskontrolle

Zu Beginn dieses Abschnittes eine kleine Warnung: Einen Rechner oder gar ein Netzwerk gegen unerlaubtes Eindringen abzusichern, ist ein äußerst schwieriges Unterfangen. Ich selber betrachte mich nicht als Experten auf diesem Gebiet, und obwohl die im folgenden beschriebenen Mechanismen sicherlich hilfreich sind, möchte ich all denen, die wirklich um die Sicherheit ihres Systems besorgt sind, raten, selber geeignete Literatur zu suchen. Im Internet findet man viele gute Hinweise dazu.

Ein wichtiger Grundsatz zur Sicherheit ist »Aktivieren Sie keine Dienste, die sie nicht benötigen.« Die meisten Distributionen sind heute mit einer Vielzahl von Servern ausgestattet, die beim Bootprozeß automatisch gestartet werden. Um ein Mindestmaß an Systemsicherheit zu gewährleisten, sollten Sie sich die Datei /etc/inetd.conf in Ruhe ansehen und alle nicht benötigten Dienste durch Einfügen eines # am Zeilenanfang auszukommentieren. Gute »Kandidaten« hierfür sind shell, login, exec, uucp und ftp sowie informelle Dienste wie finger, netstat und systat.

Es gibt eine große Zahl an Sicherheits- und Zugangskontrollmechanismen, ich werde im folgenden die wichtigsten davon kurz beschreiben.

/etc/ftpusers

Die Datei /etc/ftpusers bietet eine einfache Möglichkeit, einzelne Personen vom Zugang über FTP auszuschließen. Die Datei wird vom Daemonen ftpd gelesen, wenn eine FTP-Verbindung aufgebaut wird. Die Datei enthält einfach eine Liste mit den Benutzernamen all derer, denen ein Login verboten werden soll. Hier ein Beispiel:

# /etc/ftpusers - Benutzer, die sich nicht per FTP 
# einloggen dürfen
root
uucp
bin
mail

/etc/securetty

Mit dieser Datei wird festgelegt, an welchen (virtuellen) Terminals (ttys) sich der Systemverwalter root einloggen darf. /etc/securetty wird vom Login-Programm, normalerweise /bin/login, gelesen und enthält eine Liste der erlaubten Terminals. Auf allen anderen kann root sich nicht einloggen:

# /etc/securetty - ttys, auf denen sich root einloggen
# darf
tty1
tty2
tty3
tty4

Die tcpd Hostzugangskontrolle

Das Programm tcpd ist ihnen vielleicht schon in der Datei /etc/inetd.conf aufgefallen. Es stellt Kontroll- und Zugangskontrollmechanismen für diejenigen Dienste zur Verfügung, für die es konfiguriert wird.

Wird es von inetd gestartet, so liest es zwei Dateien, anhand derer der Zugang zum überwachten Server gewährt oder verboten werden kann.

Die beiden Steuerdateien werden jeweils solange gelesen, bis ein zutreffender Eintrag gefunden wird. Wird ein solcher zutreffender Eintrag nicht gefunden, wird angenommen, daß der Zugang für jeden erlaubt ist. Gelesen werden die Dateien in der Reihenfolge /etc/hosts.allow, /etc/hosts.deny. Die beiden Dateien werden in den folgenden Abschnitten beschrieben. Für eine detaillierte Beschreibung sei auf die manual pages verwiesen; host_access(5) ist hier ein guter Startpunkt.

/etc/hosts.allow

Dies ist eine der Konfigurationsdateien des Programmes /usr/sbin/tcpd. In /etc/hosts.allow wird eingestellt, welchen anderen Rechnern der Zugang zu Diensten auf dem eigenen Rechner gestattet werden soll. Das Dateiformat ist sehr einfach:

# /etc/hosts.allow
#
# <service list>: <host list> [: command]

service list

Eine durch Kommata getrennte Liste von Namen der Dienste, für die der Eintrag gelten soll, z.B. ftpd, telnetd oder fingerd.

host list

Eine durch Komma getrennte Liste von Rechnernamen; es können hier auch IP-Adressen angegeben werden. Außerdem können Platzhalter verwendet werden. Beispiele hierfür sind gw.vk2ktj.ampr.org (bestimmter Rechner), .uts.edu.au (alle Rechner deren Name mit dieser Zeichenkette endet) oder 44. (alle IP-Adressen, die mit der angegebenen Ziffernfolge beginnen). Weiterhin existieren einige besondere, die die Konfiguration vereinfachen. Einige davon sind ALL (jeder Rechner), LOCAL (Rechner ohne Dezimalpunkt ».« im Namen, also solche der lokalen Domain) sowie PARANOID (Rechner, deren Namen nicht der Adresse entspricht; dient der Vermeidung von Spoofing). Ein letzter nützlicher Eintrag ist EXCEPT. Dadurch können Listen mit Ausnahmen definiert werden, wie in einem späteren Beispiel erläutert wird.

command

Dies ist ein optionaler Parameter. Hier kann ein Programm mit seinem vollständigen Pfad angegeben werden, welches jedesmal ausgeführt wird, wenn die entsprechende Regel erfüllt ist. Es kann beispielsweise ein Programm gestartet werden, das herauszufinden versucht, wer gerade auf dem anderen Rechner eingelogged ist, oder eine Meldung an den Systemadministrator schickt, daß gerade jemand versucht, diesen Dienst zu nutzen. Zur Kommandogenerierung existieren einige Platzhalter, die automatisch gesetzt werden: %h ist der Name des Rechners, der die Verbindung aufbauen will, oder seine IP-Adresse. %d ist der Name des Daemons, der gestartet werden soll.

Ein Beispiel:
# /etc/hosts.allow
#
# Mail ist jedem erlaubt
in.smtpd: ALL
# Telnet und FTP nur von lokalen Rechnern sowie meinem
# Rechner zu Hause
telnetd, ftpd: LOCAL, meinrechner.zuhause.org.au
# Finger ist allen erlaubt, aber es wird protokolliert,
# woher die Anfrage kommt
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

/etc/hosts.deny

Dies ist eine der Konfigurationsdateien des Programmes /usr/sbin/tcpd. In /etc/hosts.deny wird eingestellt, welchen Rechnern der Zugang zu Diensten auf dem eigenen Rechner verboten werden soll.

Ein einfaches Beispiel sieht etwa so aus:

# /etc/hosts.deny
#
# Kein Zugang für Rechner mit suspektem Namen
ALL: PARANOID
#
# Verbot für ALLE Rechner
ALL: ALL

Der Eintrag PARANOID ist hier redundant, da der folgende Eintrag in jedem Fall einen Zugang unterbindet. Jeder der beiden Einträge ist eine sinnvolle Einstellung, abhängig von den jeweiligen Bedürfnissen.

Die sicherste Konfiguration ist ein Eintrag ALL: ALL in /etc/hosts.deny zusammen mit einer Datei /etc/hosts.allow in der im einzelnen festgelegt wird, für wen der Zugang erlaubt wird.

/etc/hosts.equiv

Die Datei /etc/hosts.equiv erlaubt es, einzelnen Rechnern und Benutzern den Zugang zur eigenen Maschine ohne Paßwortabfrage zu ermöglichen. Dies ist in einer sicheren Umgebung hilfreich, in der man alle anderen Maschinen unter Kontrolle hat. Andernfalls ist es aber ein großes Sicherheitsrisiko. Denn der eigene Rechner ist nur so sicher wie der unsicherste Rechner, dem man vertraut. Wer großen Wert auf höchste Sicherheit legt, sollte diesen Mechanismus nicht verwenden, und auch den Nutzern nahelegen, die Datei .rhosts nicht zu verwenden.

Konfiguration des FTP-Daemons

Viele Besitzer von vernetzten Rechnern sind daran interessiert, anderen Personen das Übertragen von Daten von und zum eigenen Rechner zu ermöglichen, ohne ihnen einen expliziten Account einzurichten. Dazu dient der FTP Server. Es muß aber sichergestellt sein, daß der FTP-Daemon korrekt für den anonymen Zugang konfiguriert ist. Die Seite ftpd(8) der Online-Hilfe beschreibt die dazu notwendigen Schritte in einiger Länge. Diesen Tips sollte man unbedingt folgen. Außerdem ein wichtiger Tip: Verwenden sie auf keinen Fall einfach eine Kopie der eigenen Datei /etc/passwd im anonymen Heimatverzeichnis /etc. Stellen sie sicher, daß alle unwichtigen Einträge entfernt werden, sonst stehen Angriffen durch Paßwortentschlüsselung Tür und Tor offen.

Einrichtung eines Firewall

Eine extrem sichere Methode gegen Angriffe über das Netzwerk ist es, erst gar keine Datagramme an den Rechner heranzulassen. Dieses wird in einem eigenen Dokument beschrieben, dem Firewall HOWTO.

Weitere Tips und Vorschläge

Hier noch ein paar weitere Hinweise, auch wenn der eine oder andere davon geeignet ist, Glaubenskriege unter Unix-Administratoren hervorzurufen.

sendmail

Obwohl die Verwendung des sendmail-Daemons sehr weit verbreitet ist, taucht er mit erschreckender Regelmäßigkeit in Warnungen vor Sicherheitslöchern auf. Es obliegt jedem selber, ob er sendmail verwenden will.

NFS und andere Sun RPC Dienste

Seien Sie vorsichtig damit. Es gibt bei diesen Diensten eine große Zahl potentieller Sicherheitsrisiken. Allerdings ist es schwierig, für etwas wie NFS eine Alternative zu finden. Wenn Sie diese Dienste benutzen, seien Sie vorsichtig, wem Sie einen Zugriff darauf erlauben.


Inhalt