ubuntuusers.de

Du betrachtest eine alte Revision dieser Wikiseite.

xinetd

Fehlendes Makro

Das Makro „Getestet“ konnte nicht gefunden werden.

 * [1]: [:Pakete installieren: Installation von Programmen]
 * [2]: [:Terminal: Ein Terminal öffnen]
 * [3]: [:Editor: Einen Editor öffnen]
 * [4]: [:Dienste: Serverdienste starten/stoppen]
 * [5]: [:inetd: Herkömmliche inetd-Server]

Der xinetd 🇬🇧 ist ein vollwertiger Ersatz für den Internet-Superserver 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 nur das folgende Paket installiert werden [1]:

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

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

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

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.

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.

⚓︎

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 21. Juni 2008 14:45 von Ingo0308 erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Netzwerk, Server, System