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, wieviele 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, wieviele 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.

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 IP-Adresse 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 bespielsweise notwendig, wenn man gleichnamige Dienste über TCP und UDP laufen hat. 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.

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.