xinetd

defaults-Block¶

Erwartungsgemäß gelten Direktiven aus dem defaults-Block für alle Services. Beispiel:

defaults
{
        # Was geloggt werden soll:
        log_type = SYSLOG daemon
        log_on_success = HOST PID
        log_on_failure = HOST
        # Pro Client max. 5 parallele Verbindungen zu jedem Service:
        per_source  = 5
}

Typische defaults-Optionen¶

Folgende Optionen gehören zu den interessanteren und eignen sich zur Verwendung im defaults-Block. Die meisten davon können allerdings auch in service-Blöcken verwendet werden, um für bestimmte Dienste die Standardeinstellungen zu überschreiben.

log_type

• Über die log_type-Direktive wird festgelegt, wohin der xinetd Zugriffe protokollieren soll - entweder direkt in eine Datei (FILE) oder über den Syslog-Mechanismus (SYSLOG). Als weiteres Argument wird dann entweder die Syslog-Facility oder die Datei angegeben. Beispiele:

log_type SYSLOG daemon
log_type FILE /var/log/xinetd.log

log_on_success

• Mit der Direktive log_on_success gibt man an, welche Informationen bei einem erfolgreichen Verbindungsaufbau protokolliert werden sollen. Das folgende Beispiel loggt die Prozess-ID des gestarteten Server-Prozesses, die IP-Adresse des zugreifenden Clients, den Statuscode nach Beenden des Servers und die Dauer der Verbindung:

log_on_success PID HOST EXIT DURATION

log_on_failure

• Das Pendant zu log_on_success heißt log_on_failure und gibt an, was bei einem verweigerten Verbindungsversuch protokolliert wird. So wird z.B. neben dem Festhalten der Host-IP auch versucht, eine Ident-Abfrage nach dem Benutzer zu machen und im Erfolgsfall die entfernte Benutzer-ID zu protokollieren. Heutzutage läuft allerdings auf den wenigsten Rechnern ein Ident-Daemon, so dass man sich das USERID eigentlich auch sparen kann.

log_on_failure HOST USERID

instances

• Dieser Wert - entweder eine Zahl oder die Zeichenkette UNLIMITED - legt fest, wie viele Serverprozesse ein Dienst gleichzeitig laufen lassen kann. Wird diese Zahl erreicht, werden weitere Verbindungsversuche abgewiesen.

instances 25

per_source

• Mit diesem Wert - ebenfalls entweder eine Zahl oder die Zeichenkette UNLIMITED - legt man fest, wie viele Instanzen von einer einzigen IP-Adresse parallel gestartet werden können.

service-Blöcke¶

Für jeden Service, den der xinetd betreuen soll, benötigt man einen service-Block mit einem Namen, der im Allgemeinen direkt der Datei /etc/services entnommen ist, und damit auch den Port bestimmt. (Das bedeutet, dass es verschiedene gleichnamige service-Blöcke für TCP- und UDP-Dienste geben kann.) Man kann auch in den Dateien im Verzeichnis /etc/xinetd.d mehrere solcher Sektionen unterbringen, tut dies aber im Allgemeinen nur, wenn diese in einer Beziehung zueinander stehen. Beispiele:

service test
{
        socket_type = stream
        protocol    = tcp
        port        = 3000
        type        = UNLISTED
        wait        = no
        user        = nobody
        server      = /bin/echo
        server_args = Hallo Welt! 
}

service finger
{
        socket_type = stream
        protocol    = tcp
        wait        = no
        user        = nobody
        server      = /usr/sbin/in.fingerd
}

Typische service-Optionen¶

Diese Optionen werden sinnvollerweise service-spezifisch eingesetzt, obwohl man einige bei Bedarf auch in der defaults-Sektion einsetzen kann.

disabled

• disabled = yes führt dazu, dass der Service nicht gestartet wird. disabled = no ist die Voreinstellung.

socket_type
protocol
wait
user
server
server_args

• Diese Deklarationen haben dieselbe Bedeutung, wie die entsprechenden Spalten aus der Konfiguration des herkömmlichen inetd. Der einzige Unterschied ist der, dass der Name des auszuführenden Programms nicht in den server_args wiederholt werden darf.

env, passenv

• Bestimmt, welche Umgebungsvariablen gesetzt, gelöscht und/oder vererbt werden. Die Optionen sammeln ihre Werte an, wenn sie mehrfach vorkommen, d.h. eine Zuweisung mit = wirkt bei ihnen genauso wie += (man 5 xinetd.conf 🇬🇧 Stichwort "accumulating"). Bei passenv ist auch -= möglich, um Variablennamen nachträglich von der Vererbung auszuschließen.

• Die Werte von auf diese Weise angegebenen Umgebungsvariablen können derzeit keine Leerzeichen enthalten. (manpage zu xinetd 1:2.3.15-7, Kapitel "Bugs": "There is no way to put a SPACE in an environment variable.")

group

• Entsprechend dem Attribut user kann man mit group eine Gruppenkennung festlegen, unter der der Prozess läuft.

port

• Bestimmt die Portnummer des Dienstes. Wenn der Servicename in der Datei /etc/services vorkommt, ist dieses Attribut überflüssig.

interface

• Dieses Attribut akzeptiert eine oder mehrere IP-Adressen des Rechners und gibt an, an welcher Schnittstelle der Dienst laufen soll. Damit kann man z.B. sensible Dienste auf das interne Interface eines Routers beschränken.

type

• Kann u.a. die Werte INTERNAL oder UNLISTED annehmen. Ersteres bezeichnet einen der oben schon erwähnten internen xinetd-Services (echo, chargen, daytime, etc.), letzteres bezeichnet Dienste, die nicht in der /etc/services aufgelistet sind. Ein ungelisteter Service muss eine port-Deklaration enthalten.

id

• Unterschiedliche Services mit demselben Namen können über diese ID unterschieden werden. Das ist beispielsweise notwendig, wenn gleichnamige Dienste über TCP und UDP laufen. Beispiele:

id chargen-stream
id chargen-dgram

only_from
no_access

• Zugriffskontrolle: Wird only_from angegeben, haben nur bestimmte Hosts Zugriff auf den Service. no_access verweigert dagegen den Zugriff. Findet sich ein Client in beiden Deklarationen, so gilt die spezifischere. Es können jeweils mehrere Angaben gemacht werden, z.B. so:

only_from 192.168.0.1 192.168.1.0/24 freund.de
no_access boese.com 192.168.1.13

Eine weitere Art der Zugriffskontrolle bietet die TCP-Wrapper-Bibliothek (s.u.).

access_times

• Hiermit lässt sich ein tägliches Zeitfenster angeben, während der Service den Benutzern offen steht. Außerhalb dieser Zeit wird der Zugriff verweigert. Als Referenz wird die Systemzeit incl. eingerichteter Zeitzone genutzt.

access_times 08:00-18:00

Migrations-Tools¶

Mit itox (alt) und xconv.pl (neu) liefert das xinetd-Paket gleich zwei Werkzeuge, um die alte inetd.conf in das neue Format umzuwandeln:

itox < /etc/inetd.conf > xinetd
xconv.pl < /etc/inetd.conf > xinetd 

Die damit entstandene Datei xinetd kann dann noch überarbeitet und dann in das Verzeichnis /etc/xinet.d geschoben werden. Leider funktioniert die Umwandlung nicht immer ganz perfekt und die Voreinstellungen für die speziellen xinetd-Optionen gefallen nicht immer. Das Ergebnis sollte deswegen auf jeden Fall noch kontrolliert und bei Bedarf angepasst werden.

⚓︎