Die Konfigurationsdateien für xinetd sind folgende:
/etc/xinetd.conf — Die globale xinetd Konfigurationsdatei.
/etc/xinetd.d/ Verzeichnis — Das Verzeichnis, das alle servicespezifischen Dateien enthält.
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:
instances — Bestimmt die Höchstzahl der Anfragen, die xinetd gleichzeitig bearbeiten kann.
log_type — Weist xinetd an, die Protokolldatei authpriv, die Log-Einträge in die Datei /var/log/secure zu verwenden. 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 15.4.2.
![]() | Anmerkung |
---|---|
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 15.4.3.1. |
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 vsftpd:
service ftp { socket_type = stream wait = no user = root server = /usr/sbin/vsftpd log_on_success += DURATION USERID log_on_failure += USERID nice = 10 disable = no } |
Diese Zeilen kontrollieren verschiedene Aspekte des vsftpd Service:
service — Definiert den Servicenamen, meistens entsprechend eines Services in der Datei /etc/services file.
socket_type — Setzt den Netzwerk-Sockettyp auf stream.
wait — Bestimmt, ob ein Service Single-Threaded (yes) oder Multi-Threaded (no) ist.
user — Bestimmt die User ID, unter der der Prozess abläuft.
server — Bestimmt die auszuführende Binärdatei.
log_on_success — Bestimmt die Protokoll-Parameter für log_on_success zusätzlich zu den in xinetd.conf eingestellten.
log_on_failure — Bestimmt die Protokoll-Parameter für log_on_failure zusätzlich zu den in xinetd.conf eingestellten.
nice — Bestimmt den Server-Priority-Level.
disable — Bestimmt, ob der Service aktiv oder inaktiv ist.
Es gibt eine große Anzahl an Direktiven für xinetd geschützte Dienste. Dieser Abschnitt beschreibt einige der häufig verwendeten 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).
RECORD — Zeichnet die Informationen über das Remote-System auf, wenn der Dienst nicht gestartet werden kann. Nur besondere Dienste, wie zum Beispiel login and finger, können diese Option verwenden (log_on_failure).
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.
Benutzer von xinetd-Diensten können wählen, ob sie die TCP-Wrapper Host-Zugriffskontrolldateien, Zugriffskontrolle mittels xinetd -Konfigurationsdateien oder eine Mischung von beidem verwenden wollen. Informationen über den Gebrauch von TCP-Wrapper Host-Zugriffskontrolldateien finden Sie in Abschnitt 15.2. In diesem Teil wird der Einsatz von xinetd für die Kontrolle von Zugriffen auf bestimmte Dienste besprochen.
![]() | Anmerkung |
---|---|
Im Gegensatz zu TCP-Wrapper, muss der xinetd-Administrator nach jeder Änderung den xinetdService neu starten, damit diese wirksam werden. |
Die xinetd-Host-Zugriffskontrolle unterscheidet sich von der von TCP-Wrapper 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 } |
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:
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.
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.
![]() | 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. |
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 21 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 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.
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 Security im Red Hat Linux Security Guide und auf der xinetd.conf man-Seite finden Sie weitere Informationen.
Zurück | Zum Anfang | Vor |
xinetd | Zum Kapitelanfang | Zusätzliche Ressourcen |