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:
Viele der aktuellen Distributionen kommen bereits mit vorkompilierten Kernel und unterstützen typische PC-Hardware. Zusätzlich sind bereits alle im Kernel verfügbaren Treiber als Module kompiliert. Deshalb ist es oft möglich, auf das Kernelkompilieren zu verzichten. Beispiele sind 3COM, NE2000 und Intel Netzwerkkarten sowie die weitverbreiteten Billigkarten mit Realtek Chipsatz. Dieser Abschnitt bietet die notwendigen Informationen, wenn es trotzdem notwendig wird, ein Kernelupdate durchzuführen, weil die eigene Hardware erst in neueren Kernelversionen unterstützt wird.
Der derzeit installierte Kernel hat oft nicht die Treiber für die gewünschten Hardware- und Netzwerk-Protokolle eingebunden. Hier ist eine Neukompilation des Kernels mit den entsprechenden Optionen notwendig.
Für Nutzer der großen Distributionen wie Redhat, Debian oder SuSE ist das typischerweise nicht notwendig. Solange weitverbreitete Hardware eingesetzt wird, sollte sich keine Notwendigkeit zum Kompilieren des Kernels ergeben.
Die aktuellen Kernelsourcen können z.B. von
www.de.kernel.org/pub/linux/kernelftp.kernel.org, diese ist jedoch oft schwer überlastet.
Benutzen Sie deshalb möglichst einen Mirror.
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
Modules mini-HOWTO (Englisch).
Die Datei README aus den Kernelsourcen ist eine gute
Informationsquelle, seien Sie also ein tüchtiger Leser.
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 Routen 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 Philip Blundell betreut und können von Freshmeat oder direkt über die Homepage bezogen werden:
http://freshmeat.net/projects/net-tools/?topic_id=150
http://www.tazenda.demon.co.uk/phil/net-tools/
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, eine Firewall aufzusetzen oder IP
Masquerading zu verwenden, wird darüber hinaus je nach Kernel
Programme wie ipfwadm oder ipmasqadm benötigen.
Deren Installation werden unter anderem in der
Firewall and Proxy Server HOWTO (Englisch) und der
Linux IP Masquerade HOWTO (Englisch) beschrieben.
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. 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 stellt deshalb immer die zahlenmäßig kleinste Adresse des Adreßbereichs des Netzwerkes dar, 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 gleichzeitig erhalten. Es gibt zwei verwendete Standards
dafür, wie eine solche Broadcast Adresse aussieht. Am weitesten
verbreitet ist es, die höchste Nummer des Adreßbereiches zu verwenden,
im obigen Beispiel also die 192.168.110.255. Aus verschiedenen
Gründen wird manchmal 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 Adreßraumes 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 Anwendungsfall 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 Adreßraumes 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. Heute scheint jeder
zur System V Variante, die von Miguel van Smoorenburg entwickelt wurde,
zu tendieren.
Trotz des Faktes, daß das init Programm immer dasselbe
ist, wird das Booten des System von jeder Distribution anders
gelöst.
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-Skriptes fest, das den
Bootprozeß steuert. In gewisser Weise handelt es sich um das
äquivalent zu der Datei autoexec.bat in MS-DOS.
Meist werden von diesem Skript aus weitere Skripte 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
-------------------------------------------------------------------------------
SuSE |/etc/init.d/network |/etc/init.d/nfsserver
| |/etc/init.d/inetd
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1 |/etc/rc.d/rc.inet2
-------------------------------------------------------------------------------
RedHat |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------
Bitte beachten Sie, daß Debian, RedHat und neuere SuSE-Versionen ganze
Verzeichnisse mit Skripten zum Starten von Systemdiensten nutzen.
Und gewöhnlich sind die Konfigurationsdaten nicht in diesen Skripten
enthalten. RedHat und neuere SuSE-Versionen sichern die Konfigurationsdaten
im Verzeichnis /etc/sysconfig, von wo diese durch die Bootskripte
ausgelesen werden. Für weitere Details des Bootprozesses sollten
die /etc/initab und die init-Dokumentation gelesen
werden. Das Linux Journal hat dazu einen
http://www.iar.unlp.edu.ar/~fede/revistas/lj/Magazines/LJ56/3016.htmlDie 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.
-------------------------------------------------
Distribution | Netzwerk Konfigurationsprogramm
-------------------------------------------------
RedHat | /sbin/netcfg
Slackware | /sbin/netconfig
SuSE | /sbin/yast
-------------------------------------------------
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 durch die Ausführung 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 ihre 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. Zum
Entfernen der Schnittstelle reicht ein Aufruf von:
ifconfig eth0 down
Der Kernel hat für viele der Konfigurationsparameter voreingestellte
Standardwerte. 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 würde der Kernel 192.168.0.0 als Netzwerk-Adresse
und 192.168.0.255 als Broadcast-Adresse benutzen.
ifconfig besitzt unzählige Parameter. Die wichtigsten davon sind
Aktiviert die Schnittstelle.
Deaktiviert die Schnittstelle.
(De-)aktiviert das ARP-Protokoll (Adress Resolution Protocol) zur Auflösung von Adressen für diese Schnittstelle.
Ein-/Ausschalten des All-Multicast Modus. Ist er eingeschaltet, so werden alle Multicastpakete vom Netzwerk empfangen unabhängig davon, ob sie an die Schnittstelle adressiert sind oder nicht.
Legt die MTU (Maximum Transfer Unit) 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.
Mit dem Kernel 2.2 sind eine Anzahl von Optionen hinzugekommen. Dazu gehören unter anderem Tunneling- und IPV6-Optionen. Die zusätzlichen Optionen sind im Folgenden aufgeführt.
Mit dieser Option kann der Promiscuous Mode der Schnittstelle aktiviert/deaktiviert werden. Ist er eingeschaltet, empfängt die Schnittstelle alle Packete aus dem Netzwerk gleichgültig ob sie an die Schnittstelle adressiert waren oder nicht.
Dieser Parameter setzt die Metrik einer Schnittstelle.
Setzt die Remote IP Adresse bei Point-to-Point
Verbindungen (wie PPP). Dieser Parameter ist jedoch überholt,
stattdessen sollte die Option pointopoint verwendet werden.
Setzt eine IPv6 Adresse für eine Schnittstelle.
Entfernt die IPv6 Adresse einer Schnittstelle.
Erzeugt ein neues SIT (IPv6-in-IPv4) Device das zum angegebenen Ziel tunnelt.
Setzt die I/O-Basisadresse für dieses Gerät.
Setzt die Startadresse für den Shared Memory Bereich, der durch dieses Gerät genutzt wird. Nur wenige Geräte benötigen diese Option.
Setzt den physikalischen Anschluß oder den
Medientyp, der vom Gerät verwendet wird. Nicht alle Geräte können
diese Einstellung ändern, und bei denjenigen, bei denen dies
möglich ist, variieren die unterstützten Werte. Typische Werte
für type sind 10base2 (Thin Ethernet),
10baseT (Twisted-Pair 10Mbps Ethernet),
AUI (externer Transceiver) und so
weiter. Der spezielle Medientyp auto kann benutzt
werden, damit der Treiber automatischen den Typ des
Mediums erkennt. Wiederum unterstützen dies nicht
alle Treiber.
Setzt die Hardwareadresse dieser
Schnittstelle, wenn der Gerätetreiber diese Operation unterstützt.
Das Schlüsselwort muß vom Namen der Hardwareklasse
und der ASCII-Darstellung der Hardwareadresse
gefolgt werden. Zur Zeit werden unter anderem folgende
Hardwareklassen unterstützt: ether (Ethernet), ax25 (AMPR AX.25),
ARCnet und netrom (AMPR NET/ROM).
Setzt die Multicastflag der Schnittstelle. Dies sollte im Normalfall nicht benötigt werden, da die Treiber die Flag selbst setzen.
Die IP-Adresse, die der Schnittstelle zugewiesen wird.
Setzt die Länge der Sendewarteschlange des Geräts. Es kann nützlich sein, diesen Wert auf eine kleinen Wert für langsame Geräte mit hoher Paketlaufzeit (Modems, ISDN) zu setzen, um zu verhindern, daß schnelle Großübertragungen interaktiven Verkehr wie Telnet zu sehr stören.
Die Namensauflösung (Name Resolver) ist ein Teil der Standardbibliothek
von Linux. Ihre 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
Mit dem Internet zusammenhängende 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.
Jede der Toplevel Domänen hat Subdomänen. Die Toplevel Domänen, die auf Länderkennzeichen basieren sind oft in Subdomänen, welche die com, edu, gov, mil und org Domänen nachbilden, unterteilt. So stehen com.au und gov.au z.B. für kommerzielle Organisationen und Regierungsorganisationen von Australien. Das ist jedoch keine allgemeingültige Regel, das Verfahren wird durch die Behörden jeder Domäne selbst festgelegt.
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 Mailservers ist der vollständige
Domänenname perf.no.itg.telstra.com.au. Das heißt, der Rechnername
(Hostname) ist perf, der Domainname
no.itg.telstra.com.au. Die oberste Domäne (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.
Typischerweise sind Domänennamen kürzer. Mein ISP (Internet Service
Provider) z.B. nutzt systemy.it. Meine Non-Profit Organisation
heißt linux.it ohne irgendeine com oder org Subdomäne.
Mein eigener Rechner ist morgana.systemy.it und
rubini@linux.it ist die gültige E-Mail Adresse. Zu beachten ist,
daß der Besitzer der Domäne ebenso das Recht hat, Hostnamen zu registrieren
wie Subdomänen. So kann die LUG I (Linux User Group Italy) die Domäne
pluto.linux.it nutzen, da der Besitzer von linux.it
einverstanden war und eine Subdomäne für die LUG geöffnet hat.
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 Manual Page 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
Adreßeinträ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:
127.0.0.1 localhost loopback
192.168.0.1 name.dieses.rechners
Wie man am ersten Eintrag sieht, sind auch mehrere Namen je Adreßeintrag erlaubt.
Soll ein eigener lokaler Name Server betrieben werden, ist das nicht schwer. Dazu sollte die DNS HOWTO und die mit der BIND (Berkeley Internet Name Domain) Version ausgelieferte Dokumentation zu Rate gezogen werden.
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. Gleich 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.
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 des Büros 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 im Netzwerk 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. In Kernelversion 2.4 enthält diese Tabelle acht Spalten. Wichtig sind die ersten drei Spalten. Spalte eins enthält die Schnittstelle, über die Datenpakete weitergeleitet werden, wenn sie an das in der zweiten Spalte angegebene Ziel (eine Rechner- oder Netzadresse) gerichtet sind. Spalte drei enthält die optionale IP Adresse eines anderen Rechners (Gateway), der das Datenpaket zu seinem nächsten Etappenziel leitet. Unter Linux kann man sich die Routing Tabelle mit dem folgenden Befehl ansehen:
cat /proc/net/route
Alternativ kann man die folgenden Kommandos benutzen:
/sbin/route -n
netstat -r
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 Tabelle 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 Tabelle hinzuzufügen, zu entfernen
oder zu verändern. Aus naheliegenden Gründen heißt dieser Befehl
route.
Ein einfaches Beispiel: Nehmen wir an, wir wollen einen Rechner
an ein vorhandenes LAN anschließen. Dieses 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ß die Routing Tabelle erweitert werden, so
daß Datagramme an alle Adressen 192.168.1.* direkt
über die Schnittstelle 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 Aufruf mit
-host, bei dem nur eine IP Adresse mitgegeben 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 Tabelle 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 Tabelle 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.
Die oben beschriebene Konfiguration ist für einfache Netzwerke mit nur wenigen, unveränderlichen Pfaden zu den unterschiedlichen Zielen optimiert. 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 Routen 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:
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:
#
# 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
Da immer wieder neue Dienste eingeführt werden, kann die
Datei nie ganz aktuell sein. Um die eigene Kopie der Datei
aktuell zu halten, schlage ich vor, sie mit einer /etc/services
aus einer der aktuellen Distributionen abzugleichen.
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:
#
# 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. Sie 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 unter anderem die Security HOWTO (Englisch).
Ein wichtiger Sicherheits-Grundsatz 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
Manual Page ftpd(8) 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 and Proxy Server HOWTO (Englisch) beschrieben.
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 Zugriffe erlauben.