[[Vorlage(Getestet, general)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] [:Dienste: Serverdienste starten/stoppen] [:inetd: Herkömmliche inetd-Server] }}} [[Inhaltsverzeichnis(2)]] Der [http://www.xinetd.org/ xinetd] {en} 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: * Zugriffsbeschränkung nach Tageszeit * Verschiedene Dienste an unterschiedliche Schnittstellen binden * Verbindungen an andere Rechner weiterleiten * Einzelne Konfigurationsdateien für jeden Dienst möglich Allgemeines über Sinn und Zweck und die grobe Funktionsweise eines inetd-Servers bietet der [:inetd: 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. {{{#!vorlage 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 [:inetd: 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: {{{#!vorlage Befehl 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 }}} {{{#!vorlage 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 [http://de.wikipedia.org/wiki/Ident Ident-Abfrage] {de} 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``[[BR]] ``protocol``[[BR]] ``wait``[[BR]] ``user``[[BR]] ``server``[[BR]] ``server_args`` * Diese Deklarationen haben dieselbe Bedeutung, wie die entsprechenden Spalten aus der [:inetd: 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 ``+=`` ([http://web.archive.org/web/20180112175838/https://manpages.debian.org/stretch/xinetd/xinetd.conf.5.en.html man 5 xinetd.conf] Stichwort "accumulating"). Bei ``passenv`` ist auch ``-=`` möglich, um Variablennamen nachträglich von der Vererbung auszuschließen. ``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``[[BR]] ``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 ([#tcpwrapper 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 }}} {{{#!vorlage Experten 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: {{{#!vorlage Befehl 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. [[Anker(tcpwrapper)]] = 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 [:inetd: betreffenden Abschnitt des inetd-Artikels] verwiesen sei. Der Umweg über den '''tcpd''' ist allerdings nicht nötig. = Links = * [http://www.xinetd.org/ xinetd-Homepage] {en} * [http://www.xinetd.org/faq.html xinetd-FAQ] {en} * [:Serverdienste:] {Übersicht} Übersichtsseite # tag: Netzwerk, Server, System