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.
Einige Dinge benötigt man, bevor man sich mit der Zusammenstellung und Konfiguration seines Netzwerkes beschäftigen kann. Die wichtigsten davon sind:
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.0Normalerweise 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.
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:
ftp.inka.de:/pub/comp/Linux/networking/NetTools/
ftp.linux.uk.org:/pub/linux/Networking/PROGRAMS/NetTools/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/ipfwadmDie 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
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/baseZur 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
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.
In diesem Fall muß man sich an den Administrator des Netzes wenden und ihn um folgende Informationen bitten:
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.
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
--------------------------------------------
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.
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
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
Aktiviert die Schnittstelle.
Deaktiviert die Schnittstelle.
(De-)aktiviert das Protokoll zur Auflösung von Adressen (address resolution protocol) für diese Schnittstelle.
(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.
Legt die MTU fest.
Legt die Netmask für die Schnittstelle fest.
Legt den verwendeten Interrupt der Hardware fest. Dies funktioniert aber nur für einige wenige Geräte.
Damit kann die Adresse für Broadcast-Meldungen festgelegt werden oder die Annahme solcher Pakete abgeschaltet werden.
Hiermit wird die Adresse des Rechners am anderen Ende der Verbindung festgelegt. Dieses findet z.B. im Falle von SLIP und PPP Verbindungen Verwendung.
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.
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.
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:
Kommerzielle Organisationen
Bildung und Lehre
Regierungsstellen
Militärische Organisationen
Andere Organisationen
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.
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 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:
Dieser Eintrag bestimmt den Namen der lokalen Domain.
Mit diesem Eintrag kann man die Namen von zusätzlichen Domänen angeben, in denen nach einem Hostnamen gesucht wird.
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.
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.
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.
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
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.
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
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
192.168.1.* direkt über das Ethernet Device
eth0 geleitet werden:
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
-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
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
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
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.
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
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
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
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:
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:
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.
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.
/etc/services,
in der den unterschiedlichen Portnummern Namen zugeordnet werden, und
/etc/inetd.conf, die Konfigurationsdatei des inetd
Netzwerk Daemons.
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
Ein einzelnes Wort, welches den jeweiligen Service beschreibt.
Dieses Feld besteht aus zwei Einträgen.
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.
Je nach verwendetem Protokoll steht hier
tcp oder udp.
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.
Zusätzliche Namen, unter denen dieser Service angesprochen werden kann.
#) wird ignoriert.
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
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
Name des Dienstes, entsprechend dem Eintrag in
/etc/services.
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.
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.
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.
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.
Dies ist der Name inklusive vollem Pfad des zu startenden Servers.
Dieser Eintrag umfaßt die gesamte restliche Zeile und ist optional. Hier können zusätzliche Argumente für das Serverprogramm übergeben werden.
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
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 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
/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
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.
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.
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
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
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.
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]
Eine durch Kommata getrennte Liste von Namen der
Dienste, für die der Eintrag gelten soll, z.B. ftpd, telnetd
oder fingerd.
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.
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.
# /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)
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.
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.
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.
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.
Hier noch ein paar weitere Hinweise, auch wenn der eine oder andere davon geeignet ist, Glaubenskriege unter Unix-Administratoren hervorzurufen.
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.
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.