ubuntuusers.de

xinetd

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Der xinetd 🇬🇧 ist ein vollwertiger Ersatz für den Internet-Superserver Archiv/inetd und bietet noch zahlreiche zusätzliche Optionen. Der Preis für diese mächtigen Zusätze besteht darin, dass die relativ simple Syntax der Datei /etc/inetd.conf nicht mehr ausreichte, um diese Möglichkeiten abzubilden. xinetd benutzt deswegen eine eigene Konfigurationsdatei mit einer komplett anderen Syntax.

Folgende Möglichkeiten, die mit dem regulären inetd nicht zur Verfügung stehen, sind vielleicht besonders geeignet einen dazu bringen, es mal mit dem xinetd zu versuchen:

Allgemeines über Sinn und Zweck und die grobe Funktionsweise eines inetd-Servers bietet der gleichnamige Wiki-Artikel, weswegen hier nicht alles wiederholt werden soll. Es empfiehlt sich, diesen Artikel gelesen zu haben, auch wenn man sich bereits für den xinetd entschieden hat.

Installation

Es muss das folgende Paket installiert werden [1]:

  • xinetd (seit 18.04 in universe)

Paketliste zum Kopieren:

sudo apt-get install xinetd 

Oder mit apturl installieren, Link: apt://xinetd

Konfiguration

Wie schon erwähnt unterscheidet sich die Konfiguration des xinetd von der der anderen inetds. Der Grund ist, dass die zahlreichen Optionen jedes Dienstes sich nur schwer in einer Zeile unterbringen ließen. Die Struktur der Datei /etc/xinetd.conf besteht deswegen hauptsächlich aus einer default- und einzelnen service-Sektionen, die von geschweiften Klammern eingeschlossen werden.

Außerdem besteht die Möglichkeit, über die include- und includedir-Direktiven andere Dateien in die Konfiguration einzubinden. Unter Ubuntu wird über diesen Mechanismus standardmäßig das komplette Verzeichnis /etc/xinetd.d eingebunden, so dass man dort für jeden Service eine eigene Datei anlegen kann. Das ist übersichtlicher, als eine einzige lange Datei zu pflegen.

Hinweis:

Der Name der Konfigurationsdatei darf nur große und kleine Buchstaben, Ziffern, Unterstriche und Bindestriche enthalten. Andernfalls wird die Datei ignoriert. Das exakte Zeichenalphabet wird durch folgenden regulären Ausdruck definiert: ^[a-zA-Z0-9_-]+$. Punkt und Umlaute sind also beispielsweise nicht erlaubt.

Die internen Dienste besitzen dort bereits passende Dateien, auch wenn sie erst einmal deaktiviert sind (was im Allgemeinen auch gut so bleiben kann). Sie eignen sich aber gut als Vorlage für eigene Service-Deklarationen.

Nach Änderungen an der Konfiguration muss man den Server nicht neustarten, sondern es reicht, ihm ein Signal zum Neuladen zu schicken:

sudo /etc/init.d/xinetd reload 

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

Hinweis:

Wird kein log_type angegeben, loggt der xinetd standardmäßig zwar nach SYSLOG.daemon, ignoriert aber spezielle Angaben zu log_on_success oder log_on_failure. Man sollte deswegen immer einen korrekten log_type angeben.

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

access_times 08:00-18:00

Experten-Info:

Dies sind bei weitem nicht alle Möglichkeiten, die der xinetd bietet. Eine vollständige Liste der Optionen bietet die Manpage xinetd.conf. Darunter so interessante Möglichkeiten wie Port-Weiterleitung (Option redirect) oder das Öffnen von Fake-Ports als Falle für Neugierige. Wer einen dieser Ports kontaktiert wird dann für eine bestimmte Zeitspanne komplett gesperrt. (flags SENSOR)

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.

TCP-Wrapper

Der xinetd bietet einkompilierte TCP-Wrapper-Unterstützung, also Zugriffskontrolle über die Dateien /etc/hosts.allow und /etc/hosts.deny. Diese funktioniert genau so wie beim herkömmlichen inetd, so dass auf den betreffenden Abschnitt des inetd-Artikels verwiesen sei. Der Umweg über den tcpd ist allerdings nicht nötig.

Diese Revision wurde am 1. Mai 2019 19:48 von Beforge erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: System, Server, Netzwerk