Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- xinetd-Konfigurationsdateien

17.4. xinetd-Konfigurationsdateien

Die Konfigurationsdateien f�r xinetd sind folgende:

  • /etc/xinetd.conf — Die globale xinetd Konfigurationsdatei.

  • /etc/xinetd.d/— Das Verzeichnis, das alle servicespezifischen Dateien enth�lt.

17.4.1. Die /etc/xinetd.conf Datei

Die Datei /etc/xinetd.conf enth�lt allgemeine Konfigurationseinstellungen, die jeden Dienst unter Kontrolle von xinetd betreffen. Bei jedem Start des xinetd Dienst wird diese Datei gelesen, um also Konfigurations�nderungen wirksam werden zu lassen, muss der Administrator den xinetd Dienst 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:

  • instances — Bestimmt die H�chstzahl der Anfragen, die xinetd gleichzeitig bearbeiten kann.

  • log_type — Weist xinetd an, die Protokolldatei authpriv zu verwenden, welche Log-Eintr�ge in die Datei /var/log/secure schreibt. Das Hinzuf�gen einer Direktive wie FILE /var/log/xinetdlog w�rde eine benutzerdefinierte Log-Datei mit dem Namen xinetdlog im Verzeichnis /var/log/ erstellen.

  • log_on_success — Konfiguriert xinetd zum Protokollieren, wenn die Verbindung erfolgreich ist. Standardm��ig werden die Remote-Host-IP-Adresse und die ID des Servers, der die Anfrage verarbeitet, aufgezeichnet.

  • log_on_failure — Konfiguriert xinetd zum Protokollieren wenn die Verbindung fehlschl�gt oder nicht zugelassen ist.

  • cps — Konfiguriert xinetd, f�r einen bestimmten Dienst nicht mehr als 25 Verbindungen pro Sekunde zuzulassen. Wenn diese Grenze erreicht wird, wird der Dienst f�r 30 Sekunden zur�ckgezogen.

  • includedir /etc/xinetd.d/ — Enth�lt Optionen der servicespezifischen Konfigurationsdateien im Verzeichnis /etc/xinetd.d/. Weitere Informationen zu diesem Verzeichnis finden Sie unter Abschnitt 17.4.2.

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 in der Log-Datei eines Dienstes angezeigt werden, als die /etc/xinetd.conf Datei selbst anzeigt. Weitere Informationen zu Protokoll-Optionen finden Sie unter Abschnitt 17.4.3.1.

17.4.2. Das /etc/xinetd.d/ Verzeichnis

Das Verzeichnis /etc/xinetd.d/ enth�lt die Konfigurationsdateien f�r jeden einzelnen Dienst, der von xinetd verwaltet wird sowie die Dateinamen, die mit dem Dienst korrelieren. Wie xinetd.conf wird diese Datei nur gelesen, wenn der xinetd Dienst gestartet wird. Um �nderungen wirksam werden zu lassen, muss der Administrator den xinetd Dienst 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 Dienste 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 Dienst:

  • service — Definiert den Dienstnamen, meistens einer in der Datei /etc/services aufgelistet.

  • flags — Legt jegliche Anzahl von Attributen f�r die Verbindung fest. REUSE weist xinetd an, den Socket for eine Telnet-Verbindung wiederzuverwenden.

  • socket_type — Setzt den Netzwerk-Sockettyp auf stream.

  • wait — Legt fest, ob der Dienst single-threaded (yes) oder multi-threaded (no) ist.

  • user — Legt fest unter welcher Benutzerkennung der Prozess abl�uft.

  • server — Legt die ausf�hrbare Bin�rdatei fest.

  • log_on_failure — Bestimmt die Protokoll-Parameter f�r log_on_failure zus�tzlich zu den in xinetd.conf eingestellten.

  • disable — Legt fest, ob der Dienst aktiv oder inaktiv ist.

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

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.

AnmerkungAnmerkung
 

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.

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.

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire