16.4. xinetd-Konfigurationsdateien

Die Konfigurationsdateien für xinetd sind folgende:

16.4.1. Die /etc/xinetd.conf Datei

Die Datei /etc/xinetd.conf enthält allgemeine Konfigurationseinstellungen, die jeden Service unter Kontrolle von xinetd betreffen. Bei jedem Start des xinetd Service wird diese Datei gelesen, um also Konfigurationsänderungen wirksam werden zu lassen, muss der Administrator den xinetd Service neu starten. Unten ein Beispiel einer /etc/xinetd.conf Datei:

defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}
includedir /etc/xinetd.d

Diese Zeilen kontrollieren verschiedene Aspekte von xinetd:

AnmerkungAnmerkung
 

Die Einstellungen log_on_success und log_on_failure in /etc/xinetd.conf werden oftmals von den servicespezifischen Logdateien geändert. Aus diesem Grund können mehr Informationen als von der Datei angezeigt im Servicelog enthalten sein. Weitere Informationen zu Protokoll-Optionen finden Sie unter Abschnitt 16.4.3.1.

16.4.2. Das /etc/xinetd.d/ Verzeichnis

Die Dateien im Verzeichnis /etc/xinetd.d/ enthalten die Konfigurationsdateien für jeden Service, der von xinetd verwaltet wird, sowie die Dateinamen, die zu dem Service gehören. Wie xinetd.conf wird diese Datei nur gelesen, wenn der xinetd Service gestartet wird. Um Änderungen wirksam werden zu lassen, muss der Administrator den xinetd Service neu starten.

Die Dateien in /etc/xinetd.d/ verwenden dieselben Konventionen und Optionen wie /etc/xinetd.conf. Der Hauptgrund dafür, dass sich diese in eigenen Konfigurationsdateien befinden, ist die Anpassung zu vereinfachen und andere Services damit weniger zu beeinflussen.

Um einen Überblick über die Struktur dieser Dateien zu erhalten, betrachten Sie die Datei /etc/xinetd.d/telnet:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}

Diese Zeilen kontrollieren verschiedene Aspekte des vsftpd Service:

16.4.3. Ändern von xinetd Konfigurationsdateien

Es gibt eine große Anzahl an Direktiven für xinetd geschützte Dienste. Dieser Abschnitt beschreibt einige der häufig verwendeten Optionen.

16.4.3.1. Protokoll-Optionen

Die folgenden Protokoll-Optionen stehen für /etc/xinetd.conf und die servicespezifischen Konfigurationsdateien im Verzeichnis /etc/xinetd.d/ zur Verfügung.

Hier eine Liste der häufig verwendeten Protokoll-Optionen:

  • ATTEMPT — Protokolliert einen fehlgeschlagenen Versuch (log_on_failure).

  • DURATION — Protokolliert die Zeitdauer der Dienstnutzung seitens eines Remote-Systems (log_on_success).

  • EXIT — protokolliert das Beenden oder das Endsignal des Dienstes (log_on_success).

  • HOST — Protokolliert die IP-Adresse des Remote-Host-Rechners (log_on_failure und log_on_success).

  • PID — Protokolliert die Prozess-ID des Servers, an den die Anfrage gesendet wird (log_on_success).

  • USERID — Protokolliert den Remote- Benutzer mithilfe der in RFC 1413 definierten Methode für alle Multithreaded-Stream-Dienste (log_on_failure und log_on_success).

Eine vollständige Liste der Protokoll-Optionen finden Sie auf der man-Seite zu xinetd.conf.

16.4.3.2. Zugriffskontroll-Optionen

Benutzer von xinetd-Services können wählen, ob sie die Host-Zugriffskontrolldateien der TCP-Wrappers, Zugriffskontrolle mittels xinetd-Konfigurationsdateien oder eine Mischung von beidem verwenden wollen. Informationen zum Gebrauch von Host-Zugriffskontrolldateien der TCP-Wrappers finden Sie in Abschnitt 16.2.

In diesem Abschnitt wird der Einsatz von xinetd für die Kontrolle von Zugriffen auf bestimmte Services besprochen.

AnmerkungAnmerkung
 

Im Gegensatz zu TCP-Wrapper, muss der xinetd-Administrator nach jeder Änderung den xinetdService neu starten, damit diese wirksam werden.

Im Gegensatz zu TCP-Wrappers, betrifft die Zugriffskontrolle durch xinetd lediglich die Services, die durch xinetd kontrolliert werden.

Die xinetd-Host-Zugriffskontrolle unterscheidet sich von der von TCP-Wrappers verwendeten Methode. Während TCP-Wrapper die gesamte Zugriffskonfiguration in zwei Dateien ablegt, /etc/hosts.allow und /etc/hosts.deny, kann jede Dienstdatei in /etc/xinetd.d ihre eigenen Zugriffskontrollregeln enthalten.

Die folgenden Optionen werden in den xinetd-Dateien für die Host-Zugriffskontrolle unterstützt:

  • only_from — Erlaubt nur den angegebenen Host-Rechnern die Nutzung des Dienstes.

  • no_access — Sperrt aufgeführten Host-Rechnern den Zugriff auf den Dienst.

  • access_times — Den Zeitraum, in dem ein bestimmter Dienst verwendet werden kann. Der Zeitraum muss im 24-Stunden Format (HH:MM-HH:MM) angegeben werden.

Die Optionen only_from und no_access können eine Liste von IP-Adressen oder Hostnamen verwenden, oder ein gesamtes Netzwerk spezifizieren. Wie TCP-Wrappers, kann durch die Kombination der xinetd-Zugriffskontrolle und der entsprechenden Protokollierkonfiguration die Sicherheit durch das Sperren von Anfragen von gesperrten Hosts und das Protokollieren aller Verbindungsversuche erhöht werden.

Zum Beispiel kann die folgende /etc/xinetd.d/telnet-Datei verwendet werden, um den Telnet-Zugriff einer bestimmten Netzwerkgruppe auf ein System zu verweigern und den gesamten Zeitraum für die Anmeldung von zugelassenen Benutzern einzuschränken:

service telnet
{
        disable         = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        no_access       = 10.0.1.0/24
        log_on_success  += PID HOST EXIT
        access_times    = 09:45-16:15
}

In diesem Beispiel erhält jedes System des Unternetzes 10.0.1.0/24, wie zum Beispiel 10.0.1.2, beim Versuch, auf Telnet zuzugreifen, die folgende Meldung:

Connection closed by foreign host.

Außerdem werden diese Anmeldeversuche in /var/log/secure protokolliert:

May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Wenn Sie TCP-Wrapper zusammen mit der Zugriffskontrolle von xinetd verwenden, müssen Sie die Beziehung dieser beiden Zugriffskontroll-Mechanismen verstehen.

Im Folgenden wird die Abfolge der Vorgänge in xinetd beschrieben, wenn ein Client eine Verbindung anfordert:

  1. Der xinetd-Daemon greift auf die Host-Zugriffsregeln der TCP-Wrapper durch einen libwrap.a Library-Aufruf zu. Besteht eine Dienstverweigerungs-Regel für den Client Host, wird die Verbindung nicht aufgebaut. Besteht eine Zugrifferlaubnis, wird die Verbindung an xinetd weitergegeben.

  2. Der xinetd-Daemon überprüft seine eigenen Zugriffskontroll-Regeln für den xinetd-Service und den angeforderten Service. Besteht eine Dienstverweigerungs-Regel für den Client Host, wird die Verbindung nicht aufgebaut. Ansonsten startet xinetd eine Instanz des angeforderten Services und gibt die Kontrolle an diesen weiter.

WichtigWichtig
 

Seien Sie vorsichtig beim Verwenden von TCP-Wrapper Zugriffskontrollen zusammen mit xinetd Zugriffskontrollen. Eine Fehlkonfiguration kann höchst unerwünschte Folgen nach sich ziehen.

16.4.3.3. Bindungs- und Umleitungs-Optionen

Die Dienstkonfigurationsdateien für xinetd unterstützen auch die Bindung des Dienstes an eine besondere IP-Adresse und Umleitung der eingehenden Anfragen für diesen Dienst an andere IP-Adressen, Hostnamen oder Ports.

Die Bindung wird von der bind -Option in den Dienstkonfigurationsdateien kontrolliert und verknüpft den Dienst mit einer IP-Adresse auf dem System. Nach der Konfiguration lässt die bind Option nur Anfragen für die richtige IP-Adresse zum Zugriff auf den Dienst zu. So kann jeder Dienst je nach Bedarf mit verschiedenen Netzwerkschnittstellen gebunden werden.

Dies ist besonders nützlich bei Systemen mit mehreren Netzwerkadaptern oder mehreren IP-Adressen. Sie können beispielsweise Telnet zum Abhören von Schnittstellen konfigurieren, die mit einem privaten Netzwerk und nicht mit dem Internet verbunden sind.

Die Option redirect akzeptiert eine IP-Adresse oder einen Hostnamen gefolgt von einer Port-Nummer. Sie konfiguriert den Service, alle alle Anfragen für diesen Dienst an eine bestimmte Adresse und Portnummer weiterzuleiten. Diese Eigenschaft kann verwendet werden, um auf eine andere Port-Nummer auf demselben System zu verweisen, die Anfrage an eine andere IP-Adresse auf demselben Rechner weiterzuleiten, die Anfrage an ein anderes System oder eine andere Port-Nummer zu verschieben. Die Eigenschaft kann auch für eine Kombination dieser Optionen verwendet werden. Auf diese Weise kann ein Benutzer, der sich für einen bestimmten Dienst an einem System anmeldet, ohne Unterbrechung umgeleitet werden.

Der xinetd-Daemon kann diese Umleitung durch Erzeugen eines Prozesses ausführen, der während der Verbindung des anfragenden Client-Rechners mit dem Host-Rechner, der den eigentlichen Dienst liefert, im Stay-Alive-Modus läuft, und Daten zwischen den zwei Systemen austauscht.

Der eigentliche Stärke der bind und redirect -Optionen liegt in deren kombinierten Verwendung. Durch Bindung eines Dienstes an eine bestimmte IP-Adresse auf einem System und dem darauffolgenden Umleiten der Anfragen für denselben Dienst an einen zweiten Rechner, der nur für den ersten Rechner sichtbar ist, können Sie ein internes System verwenden, um Dienste für vollkommen unterschiedliche Netzwerke zur Verfügung zu stellen. Ansonsten können diese Optionen verwendet werden, um die Zeit zu begrenzen, während derer ein Dienst auf einem Multihomed-Rechner einer bekannten IP-Adresse ausgesetzt ist, sowie jegliche Anfragen für diesen Dienst an einen anderen Rechner weiterzuleiten, der eigens für diesen Zweck konfiguriert ist.

Nehmen wir zum Beispiel ein System, das als Firewall mit diesen Einstellungen für seine Telnet-Dienste verwendet wird:

service telnet
{
        socket_type		= stream
        wait			= no
        server			= /usr/sbin/in.telnetd
        log_on_success		+= DURATION USERID
        log_on_failure		+= USERID
        bind                    = 123.123.123.123
        redirect                = 10.0.1.13 23
}

Die Optionen bind und redirect in dieser Datei stellen sicher, dass der telnet-Dienst auf dem Rechner für eine externe IP-Adresse (123.123.123.123) bestimmt ist, und zwar die Internet-seitige. Außerdem werden alle an 123.123.123.123 gesendete Telnet-Anfragen über einen zweiten Netzwerkadapter an eine interne IP-Adresse (10.0.1.13) weitergeleitet, auf die nur die Firewall und interne Systeme Zugriff haben. Die Firewall sendet dann die Kommunikation von einem System an das andere, und für das sich verbindende System sieht es so aus, als ob es mit 123.123.123.123 verbunden sei, während es in Wirklichkeit mit einem anderen Rechner verbunden ist.

Diese Eigenschaft ist besonders nützlich für Benutzer mit Breitbandverbindungen und nur für feste IP-Adressen. Wird Network Address Translation (NAT) verwendet, sind die Systems hinter dem Gateway-Rechner, die nur interne IP-Adressen verwenden, außerhalb des Gateway-Systems nicht zugängig. Wenn jedoch bestimmte Services, die mit xinetd kontrolliert werden, mit den Optionen bind und redirect konfiguriert sind, kann der Gateway-Rechner als eine Art Proxy zwischen externen Systemen und einem bestimmten internen Rechner fungieren, der konfiguriert ist, um den Service zur Verfügung zu stellen. Außerdem sind die verschiedenen xinetd-Zugriffskontroll- und Protokollieroptionen auch für zusätzlichen Schutz, wie zum Beispiel Begrenzung der Anzahl von gleichzeitigen Verbindungen für den weitergeleiteten Service, verfügbar.

16.4.3.4. Ressourcen-Management-Optionen

Der xinetd-Daemon kann einen einfachen Grad an Schutz vor Denial of Service (DoS) Angriffen (Dienstverweigerungs-Angriffe) liefern. Untenstehend finden Sie eine Liste an Direktiven, die Ihnen beim Einschränken der Auswirkung dieser Angriffe helfen:

  • per_source — Definiert die Höchstanzahl von Verbindungen von einer bestimmen IP-Adresse mit einem bestimmen Dienst. Es werden nur ganze Zahlen als Argument akzeptiert und er kann in xinetd.conf und in den servicespezifischen Konfigurationsdateien im Verzeichnis xinetd.d/ verwendet werden.

  • cps — Definiert die Höchstzahl der Verbindungen pro Sekunde. Diese Option akzeptiert zwei ganzzahlige Argumente getrennt durch eine Leerstelle. Die erste Zahl ist die Höchstzahl von Verbindungen zum Service pro Sekunde. Die zweite Zahl ist die Anzahl der Sekunden, die xinetd warten muss, bis der Service wieder aktiviert wird. Es werden nur ganze Zahlen akzeptiert, und die Option kann in xinetd.conf und in den servicespezifischen Konfigurationsdateien im Verzeichnis xinetd.d/ verwendet werden.

  • max_load — Definiert den Schwellenwert für die CPU-Nutzung eines Dienstes. Es werden Kommazahlen-Argumente.

Es gibt noch weitere Ressource-Management-Optionen für xinetd. Im Kapitel Server-Sicherheit im Red Hat Enterprise Linux Sicherheitshandbuch und auf der xinetd.conf man-Seite finden Sie weitere Informationen.