Wer klug zu dienen weiß, ist halb Gebieter. -- Publilius Syrus

12 Netzwerkdienste

In diesem Kapitel möchten wir uns nun mit ersten grundlegenden Diensten auseinandersetzen, die Linux- und Unix-Systeme mit sich bringen. Davon gibt es übrigens eine ganze Menge. In den folgenden Kapiteln werden dann noch besonders wichtige und populäre Dienste wie Nameserver und SSH sowie der Einsatz von Linux als »LAMP«-Server besprochen.

12.1 inetd und xinetdtd

Superserver?

Als Erstes wollen wir uns mit den sogenannten »Superservern« befassen. Dabei handelt es sich um die zwei Dienste inetd und xinetd. Je nach Distribution bzw. Derivat wird entweder standardmäßig der inetd oder der neuere und bessere xinetd auf Ihrem System vorhanden sein. Welchen Dienst Sie am Ende benutzen, ist aber in diesem Buch prinzipiell egal – wir besprechen beide Dienste. <Sind wir nicht toll ...>

Zur grundlegenden Funktionsweise ist zu sagen, dass die Superserver darauf warten, dass bestimmte Netzwerkverbindungen hergestellt werden. Ist zum Beispiel eine FTP-Funktionalität konfiguriert, wird der entsprechende FTP-Dienst erst gestartet, wenn eine Verbindungsanfrage seitens eines Clients vorliegt.

Es gibt dabei sowohl superserver-interne als auch -externe Dienste. Die internen Dienste sind kleine Dienste, für die man keine extra Binaries verwenden will. Sie brauchen also nicht explizit über ein anderes Programm gestartet werden, sondern werden vom Superserver selbst bereitgestellt. Externe Programme, etwa ein FTP-Server, werden in einem eigenen Prozess gestartet und kommunizieren dann indirekt mit dem Client, da sich zwischen den beiden Endpunkten immer noch der Superserver befindet.

Diese Superserver können sowohl mit UDP- als auch mit TCP-Diensten, ja sogar mit RPC-Diensten umgehen. <RPC steht für Remote Procedure Call und wird zum Beispiel von NFS und NIS verwendet. Es erlaubt sogenanntes Distributed Computing. Nähere Informationen hierzu erhalten Sie in A. Tannenbaums Buch »Verteilte Systeme«.>

Aber warum sollte man überhaupt so etwas wie Superserver einsetzen wollen?

Ein über den (x)inetd verwalteter Dienst wird erst gestartet, wenn ein Verbindungswunsch vorliegt. Ein entsprechender Serverdienst wird also nur aktiv, wenn er auch wirklich benötigt wird. Für selten genutzte Dienste können so Ressourcen gespart werden, auch wird man hier die durch den Start des Dienstes bedingte minimale Verzögerung bei der ersten Antwort vom Server akzeptieren.

Einen Serverdienst bezeichnet man als standalone, wenn er nicht durch einen Superserver gestartet wird und stattdessen permanent im Hintergrund läuft und auf Anfragen wartet.

Eine Anleitung zur Programmierung von superserver-basierten Diensten finden Sie in [Stevens00A].

12.1.1 inetd

Zunächst wollen wir uns mit der alten, aber immer noch sehr stark verbreiteten Variante inetd beschäftigen.

Veröffentlicht wurde der Dienst mit 4.3BSD, spätere Weiterentwicklungen mit SunOS 4.1 fügten die Unterstützung für Sun RPC hinzu. Unter BSD wurde 1999 der IPv6-Support durch das KAME-Projekt hinzugefügt.

Die primäre Konfiguration des Superservers erfolgt über die Datei /etc/ inetd.conf. Der Aufbau der Datei ist, wie für Unix-Systeme üblich, sehr einfach. Sehen wir uns einmal eine solche Konfigurationsdatei an: <Leider mussten wir aufgrund der Seitenbreite die Lesbarkeit dieses Listings etwas beeinträchtigen. Die Backslashes am Ende der Zeile zeigen wie immer an, dass eine Zeile in der darauffolgenden Zeile fortgesetzt wird.>

ftp    stream tcp  nowait root \ 
       /usr/libexec/ftpd ftpd -US 
ftp    stream tcp6 nowait root \ 
       /usr/libexec/ftpd ftpd -US 
telnet stream tcp  nowait root \ 
       /usr/libexec/telnetd telnetd -k 
telnet stream tcp6 nowait root \ 
       /usr/libexec/telnetd telnetd -k 
shell  stream tcp  nowait root \ 
       /usr/libexec/rshd rshd -L 
shell  stream tcp6 nowait root \ 
       /usr/libexec/rshd rshd -L 
uucpd  stream tcp  nowait root \ 
       /usr/libexec/uucpd uucpd 
uucpd  stream tcp6 nowait root \ 
       /usr/libexec/uucpd uucpd 
finger stream tcp  nowait _fingerd \ 
       /usr/libexec/fingerd fingerd -lsm 
finger stream tcp6 nowait _fingerd \ 
       /usr/libexec/fingerd fingerd -lsm 
... 
... 
echo   dgram udp  wait   root    internal 
echo   dgram udp6 wait   root    internal 
... 
... 
sprayd/1 dgram rpc/udp wait root \ 
       /usr/libexec/rpc.sprayd rpc.sprayd

Listing 12.1 Ausschnitt aus einer inetd.conf

Betrachten wir zunächst die erste Spalte. In dieser Spalte ist der Name des Dienstes angegeben. Dadurch wird der Superserver über den zu verwendenden Port informiert. Wie Sie sich sicherlich erinnern, werden diese Informationen aus der Datei /etc/services bezogen. Hinter einem Slash kann zusätzlich die Dienst-Version angegeben werden.

Die zweite Spalte gibt an, ob es sich um einen datagramm- (dgram) oder einen verbindungsorientierten Dienst (stream) handelt. UDP ist ein Datagramm-Protokoll. Daher wird bei UDP-Diensten dgram gesetzt und bei TCP-Diensten, da TCP ein verbindungsorientierter (Stream-)Dienst ist, stream. <In der Netzwerkprogrammierung ist dieser Wert als »Socket-Type« bekannt. Bei einem Aufruf von socket() wird entsprechend SOCK_DGRAM oder SOCK_STREAM als Parameter übergeben.>

Die dritte Spalte gibt das Protokoll an. Unterstützt werden tcp für TCP mit IPv4, tcp6 für TCP mit IPv6 und dasselbe analog für UDP mit udp und udp6. Außerdem kann man RPC mit beiden Protokollen verwenden (was dann durch einen Slash in der Form rpc/Protokoll angegeben wird) oder Unix-Domain-Sockets via unix-Keyword einsetzen. <Wenn Sie diese Informationen schlau mit denen des letzten Absatzes kombinieren, werden Sie feststellen, dass dgram nur in Verbindung mit udp und stream nur in Verbindung mit tcp genutzt wird.>

Spalte Numero vier ist nur für UDP-Dienste interessant. Hier wird entweder wait oder nowait angegeben.

Handelt es sich um einen Dienst, der so programmiert ist, dass er jeweils nur eine »Verbindung« handhaben kann, wird wait verwendet. inetd startet in diesem Fall den Dienst und wartet auf dessen Beendigung, bevor neue »Verbindungen« entgegengenommen werden. Wird hingegen nowait angegeben, muss der Server in der Lage sein, mehrere »Verbindungen« gleichzeitig zu handhaben. <Dies funktioniert beispielsweise durch Threads und Child-Prozesse.>

Anschließend folgt die Angabe eines Benutzers. Mit den Berechtigungen des Benutzers wird der Dienst gestartet. Im Übrigen ist es auch möglich, eine Gruppe anzugeben, was man in der Form user.group oder user:group schreibt.

Die nächste Spalte gibt die Binary an, das gestartet werden soll – oder eben das Keyword internal für einen inetd-internen Dienst.

Alle folgenden Spalten sind Parameter für die Binary. Der erste Parameter, C-Programmierer kennen ihn vom Argument-Vektor argv[], ist der Programmname selbst, die nächsten Parameter sind optional und abhängig vom jeweiligen Dienst.

12.1.2 tcpd

Was inetd nun aber noch fehlt, ist eine Zugriffskontrolle. Diese wickelt man bei Bedarf über tcpd ab.

Dieses Programm nennt sich TCP-Wrapper und wird zwischen inetd und den jeweiligen Dienst gesetzt. Es überprüft die Autorisierung einer Verbindung anhand zweier Konfigurationsdateien: /etc/hosts.allow und /etc/hosts.deny.

Die Vorgehensweise ist dabei die folgende: Ist ein Dienst/Client in der hosts.allow gelistet, wird die Verbindung erlaubt. Ist dort nichts zu finden, wirft tcpd einen Blick in die hosts.deny. Ist dort ein entsprechender Eintrag zu finden, wird die Verbindung nicht erlaubt. Ist in keiner dieser Dateien ein Eintrag zu finden, wird die Verbindung wiederum erlaubt.

Um einen Dienst, der über inetd gestartet werden soll, zusätzlich mit dem tcpd zu überprüfen, wird anstelle der Binaries des Dienstes die Binary des tcpd angegeben. Aus einem Eintrag wie

finger stream tcp nowait nobody /usr/libexec/fingerd \ 
       fingerd

Listing 12.2 Ohne tcpd

wird folglich ein Eintrag der Form

Dienst [stream/dgram] Protokoll [no]wait Benutzer  \ 
tcpd-Binary [Dienst-Name bzw. Binary des externen  \ 
Dienstes]

Listing 12.3 Mit tcpd

finger stream tcp nowait nobody /usr/libexec/tcpd \ 
       fingerd

Listing 12.4 Mit tcpd

12.1.3 xinetd

Die Konfiguration des xinetd <Das »x« steht hierbei für extended (also erweitert), da xinetd als verbesserte Version des inetd angesehen wird.> gestaltet sich geringfügig komplizierter. Belohnt wird der Mehraufwand aber mit vielen zusätzlichen Features:

Schutz vor Denial-of-Service-(DoS-)Attacken

Logging via syslog und eigenes Logging-System

Zugriffskontrolle und Unterstützung der Dateien hosts.allow und hosts.deny – daher wird kein tcpd mehr benötigt!

Verbindungsbeschränkungen

Tageszeitbezogene Bewilligungen von Verbindungen

Dienste können nun explizit auf bestimmten Adressen, beispielsweise nur lokal, angeboten werden.

Weiterleitung von TCP-Verbindungen auf (interne) Rechner

Die xinetd.conf

Basic Setup

Die Konfiguration des xinetd wird in der Datei /etc/xinetd.conf abgewickelt. Diese Datei ist allerdings anders aufgebaut als die /etc/inetd.conf. Zunächst einmal werden Standardattribute konfiguriert, was in der defaults-Sektion erledigt wird.

Zunächst wird festgelegt, dass nie mehr als 10 Serverdienste (instances) gleichzeitig laufen sollen. Will man keine Begrenzung, kann man statt einer Zahl auch das Keyword »UNLIMITED« eintragen.

Protokolliert wird über die Datei xinetd.log in /var/log, und bei erfolgreichen Verbindungen (log_on_success) werden der Hostname, die Prozess-ID, die Benutzer-ID, die Verbindungszeit und der Exit-Status protokolliert. Bei einem Fehler (log_on_failure) werden hingegen der Hostname, die User-ID, der Grund für den Fehler (ATTEMPT) sowie einige weitere Informationen (RECORD) ausgegeben.

Durch das Schlüsselwort only_from lassen wir im Beispiel nur Zugriffe von den Rechnern im Netz 192.168.1.0/24 zu. Das Schlüsselwort disabled wird nur im Sektionsbereich defaults angewandt und unterbindet die Nutzung einiger Dienste.

defaults 
{ 
    instances        = 10 
    log_type         = FILE /var/log/xinetd.log 
    log_on_success   = HOST PID USERID DURATION EXIT 
    log_on_failure   = HOST USERID ATTEMPT RECORD 
    only_from        = 192.168.1.0/24 
 
    disabled = finger 
    disabled += systat netstat 
    disabled += exec 
}

Listing 12.5 Eine defaults-Sektion

Dienste konfigurieren

Kommen wir nun zur expliziten Konfiguration eines Dienstes. Als Beispiel soll wieder ein FTP-Server dienen:

service ftp 
{ 
    socket_type    = stream 
    wait           = no 
    user           = root 
    server         = /usr/sbin/wu.ftpd 
    server_args    = -a 
    instances      = 2 
    access_times   = 8:00-13:00 14:00-19:00 
    nice           = 10 
    only_from      = 192.168.1.123 192.168.1.124 
}

Listing 12.6 Konfiguration eines FTP-Servers

Für TCP wählt man auch beim xinetd die Stream-Option als Socket-Type und als Analogon zu inetds (no)wait das no beim wait-Flag. Der FTP-Dienst soll als Superuser gestartet werden (user). Das Binary ist wu.ftpd, und als Parameter für den Aufruf des Programms wird -a übergeben.

Der Server soll von 8 bis 13 Uhr und von 14 bis 19 Uhr erreichbar sein, zum Beispiel, weil von 13 bis 14 Uhr Mittagspause ist und nachts alle Mitarbeiter ... zumindest die meisten ... schlafen.

Weiterhin soll die Nice-Priorität auf 10 gesetzt und der Zugriff nur von den Hosts 192.168.1.123 und 192.168.1.124 gestattet werden.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.