»Wer klug zu dienen weiß,
ist halb Gebieter.«
– Publilius Syrus

17 Netzwerkdienste

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

17.1 inetd und xinetd

Superserver?

Als Erstes wollen wir uns mit den sogenannten »Superservern« befassen. Dabei handelt es sich um die beiden 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 nutzen, ist aber für die weitere Lektüre prinzipiell egal – wir besprechen beide. [Fn. 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 sind dabei kleine Dienste, für die man keine gesonderten 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. [Fn. 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 Andrew Tanenbaums Buch »Verteilte Systeme« [TanVanSt07].] Aber warum sollte man überhaupt so etwas wie Superserver einsetzen wollen?

Ein von (x)inetd verwalteter Dienst wird erst gestartet, wenn ein Verbindungswunsch vorliegt. Der entsprechende 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, sondern permanent im Hintergrund läuft und auf Anfragen wartet.

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

17.1.1 inetd

Zunächst wollen wir uns mit der alten, aber immer noch sehr 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: [Fn. Leider ist aufgrund der Seitenbreite die Lesbarkeit dieses Listings etwas beeinträchtigt. Die Backslashes am Ende der Zeile zeigen wie immer an, dass eine Zeile in der darauffolgenden Zeile fortgesetzt wird.]

Listing 17.1 Ausschnitt aus einer inetd.conf

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

Betrachten wir zunächst die erste Spalte. Sie gibt den Namen des Dienstes an und informiert den Superserver über den zu verwendenden Port. Wie Sie sich sicherlich erinnern, werden diese Informationen aus der Datei /etc/services bezogen. Hinter einem Slash kann zusätzlich die Dienstversion 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 stream, da TCP ein verbindungsorientierter (Stream-)Dienst ist . [Fn. 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 Transport-Layer-Protokoll des Dienstes an. Unterstützt werden tcp für TCP über IPv4, tcp6 für TCP über 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. [Fn. Wenn Sie diese Informationen mit denen des letzten Absatzes klug kombinieren, werden Sie feststellen, dass dgram nur in Verbindung mit udp genutzt wird und stream nur in Verbindung mit tcp.]

Spalte 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. [Fn. 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 in der Form user.group oder user:group anzugeben.

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

Alle folgenden Spalten sind zu übergebende Startparameter für das festgelegte Programm. 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.

17.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

Listing 17.2 Ohne tcpd

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

wird folglich ein Eintrag der Form

Listing 17.3 Mit tcpd: Form

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

Listing 17.4 Mit tcpd: ein Beispiel

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

17.1.3 xinetd

Die Konfiguration des Superservers xinetd [Fn. 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 explizit auf bestimmten Adressen, beispielsweise nur lokal, angeboten werden.
Weiterleitung von TCP-Verbindungen auf (interne) Rechner

Die xinetd.conf

Basic Setup

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

Als Erstes wird festgelegt, dass nie mehr als 10 Serverdienste (instances) gleichzeitig laufen sollen. Möchte man keine Begrenzung, kann man statt einer Zahl auch das Keyword UNLIMITED eintragen.

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

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

Listing 17.5 Eine defaults-Sektion

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
}

Dienste konfigurieren

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

Listing 17.6 Konfiguration eines FTP-Servers

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
}

Für TCP wählt man auch beim xinetd die Stream-Option als Socket-Typ und als Analogon zu (no)wait bei inetd 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 schlafen ... zumindest die meisten.

Außerdem 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.

Name
E-Mail
Ihr Kommentar