17.4. xinetd-Konfigurationsdateien

17.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 Protokollierungs-Optionen finden Sie auf der xinetd.conf man-Seite.

17.4.3.2. Zugriffskontroll-Optionen

Benutzer von xinetd-Diensten k�nnen w�hlen, ob sie die Host-Zugriffskontrolldateien der TCP-Wrapper, Zugriffskontrolle mittels xinetd-Konfigurationsdateien oder eine Mischung von beidem verwenden wollen. Informationen zum Gebrauch von Host-Zugriffskontrolldateien der TCP-Wrapper finden Sie in Abschnitt 17.2.

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

	Anmerkung
	Im Gegensatz zu TCP-Wrappern, muss der xinetd-Administrator nach jeden �nderungen den xinetd-Dienst neu starten, damit diese wirksam werden. Im Gegensatz zu TCP-Wrapper, betrifft die Zugriffskontrolle durch xinetd lediglich die Dienste, die durch xinetd kontrolliert werden.

Die xinetd-Host-Zugriffskontrolle unterscheidet sich von der von TCP-Wrappern 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-Wrapper, 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
}

Wenn wie in diesem Beispiel ein Client System des 10.0.1.0/24 Netzwerks, wie zum Beispiel 10.0.1.2, versucht auf Telnet zuzugreifen, erh�lt dies 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 Zugriffserlaubnis, wird die Verbindung an xinetd weitergegeben.

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

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

17.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. Auf diese Weise kann jeder Dienst je nach Bedarf an verschiedene 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 Dienst, 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 Systeme hinter dem Gateway-Rechner, die nur interne IP-Adressen verwenden, au�erhalb des Gateway-Systems nicht zug�ngig. Wenn jedoch bestimmte Dienste, 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 Dienst 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 Dienst, verf�gbar.

17.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 Dienst pro Sekunde. Die zweite Zahl ist die Anzahl der Sekunden, die xinetd warten muss, bis der Dienst 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 akzeptiert.

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.