Der Xinetd-Service

Einleitung

'Xinetd' ist ein quelloffener Superserver, der auf vielen Unix-Systemen läuft. Xinetd steht für extended internet daemon und verwaltet verschiedene Internetdienste wie FTP-Server, HTTP-Server und andere.

Der Xinetd stellt verschiedene Zugangskontrollen zur Verfügung, wie zum Beispiel TCP-Wrapper-Zugangskontrolllisten, außerdem vielfältige Log-Fähigkeiten und die Möglichkeit, Dienste nach Uhrzeit zur Verfügung zu stellen. Xinetd kann das System in der Anzahl der zu startenden Server/Daemons einschränken und besitzt Verteidigungsmechanismen gegen Portscanner und andere Angriffsarten.

Das Menü im Setup-Programm

Das Menü im Setup-Programm ist wie folgt aufgebaut:

1. Service administration

x. Xinetd - administration

1. View documentaion

2. Edit configuration

3. Show status

4. Stop Xinetd

5. Start Xinetd

6. Advanced configuration file handling

Änderung der Konfiguration

Die Konfiguration kann über den Menüpunkt „Edit configuration“ geändert werden.

Nachdem der Editor beendet wurde wird die Konfiguration mit dem eischk-Programm automatisch auf syntaktische und teilweise auch auf semantische Fehler geprüft. Werden Fehler festgestellt, so werden diese gemeldet und der Benutzer zur Korrektur aufgefordert. Wird eine solche Korrektur nicht durchgeführt, so kann es zu unvorhersehbaren Fehlfunktionen bei den Diensten kommen.

Es wird zusätzlich gefragt, ob die Konfiguration angewendet (aktiviert) werden soll. Wird dieses verneint, so unterbleibt die Aktivierung.

Wird die Aktivierung bestätigt, werden über ein Skript die durchgeführten Änderungen wirksam gemacht.

Die Konfigurationsdatei

Die Konfigurationsdatei (/etc/config.d/xinetd) enthält in einer Reihe von Abschnitten die Parameter, die die einzelnen Dienste parametrisieren bzw festlegen, ob ein Dienst überhaupt zur Verfügung gestellt wird oder nicht.

Die Parameter

Xinetd (general settings)

START_XINETD

Soll der Xinetd-Daemon gestartet werden (yes) oder nicht (no)?

Gültige Werte: yes,no

Standardeinstellung: START_XINETD='no'

Services (settings)

XINETD_TIME_SERVICE

Soll der sogenannte Time Service (RFC 868) sowohl via UPD und TCP bereitgestellt werden (yes) oder nicht (no)? über diesen Dienst auf Port 37 können andere Rechner einen Zeitabgleich mit dem eisfair-Server durchführen.

Gültige Werte: yes,no

Standardeinstellung: XINETD_TIME_SERVICE='no'

XINETD_DAYTIME_SERVICE

Soll der sogenannte Daytime Service (RFC 867) sowohl via UPD und TCP bereitgestellt werden (yes) oder nicht (no)? über diesen Dienst auf Port 13 können andere Rechner die akutelle Uhrzei und das Datum in einer Zeile vom eisfair-Server abfragen.

Gültige Werte: yes,no

Standardeinstellung: XINETD_DAYTIME_SERVICE='no'

XINETD_ECHO_SERVICE

Soll der sogenannte Echo Service (RFC 862) sowohl via UPD und TCP bereitgestellt werden (yes) oder nicht (no)? Aufgabe des Dienstes auf Port 7 ist es, alle empfangenen Daten unverändert vom eisfair-Server zum Client zurückzusenden.

Gültige Werte: yes,no

Standardeinstellung: XINETD_ECHO_SERVICE='no'

XINETD_DISCARD_SERVICE

Soll der sogenannte Discard Service (RFC 863) sowohl via UPD und TCP bereitgestellt werden (yes) oder nicht (no)? Aufgabe des Dienstes auf Port 9 ist es, alle empfangenen Daten zu verwerfen. Es wird keine Antwort vom eisfair-Server gesendet

Gültige Werte: yes,no

Standardeinstellung: XINETD_DISCARD_SERVICE='no'

XINETD_CHARGEN_SERVICE

Soll der sogenannte Chargen Service (RFC 864) sowohl via UPD und TCP bereitgestellt werden (yes) oder nicht (no)? über diesen Dienst auf Port 19 können andere Rechner Testen und Debuggen mit dem eisfair-Server durchführen.

Gültige Werte: yes,no

Standardeinstellung: XINETD_CHARGEN_SERVICE='no'

Die Funktion des Xinetd

Der Xinetd ist als Superserver konzipiert und kann gewissen Dienste starten, wenn sie angefragt werden. Dies kann insbesondere dann ein Vorteil sein, wenn Speicher knapp ist; damit werden dann Dienste nur gestartet, wenn sie auch wirklich gebraucht werden.

Beispielsweise wird der telnetd erst dann gestartet, wenn eine Anfrage auf dem zu telnetd gehörenden Port ankommt. So ist es auch zu erklären, dass – bis auf die Zeitpunkte, zu denen ein User per Telnet eingeloggt ist – nie ein telnetd-Prozess in der Prozessliste zu finden ist.

Konfiguration der Services für den Xinetd

Es wurde die Bearbeitung sogenannter <service>.expert-Dateien implementiert. Falls eine Datei <service>.expert (z.B. ftp.expert) im Verzeichnis /etc/Xinetd.d existiert, so wird diese Datei in die originale Servicedatei <service> eingefügt.

Das folgende Beispiel zeigt, was passiert.

Originale Servicedatei /etc/xinetd.d/ftp

  service ftp
  {
    server = /usr/sbin/pure-ftpd
    server_args =  -l unix -A -E -k 95% -I 15 -c 20 -S 21
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    disable = no
  }

Expertdatei /etc/xinetd.d/ftp.expert

    per_source = 2
    only_from = 192.168.1.11

Zusammengefügte Datei /etc/xinetd.d/ftp

  service ftp
  {
  #B Expert
    per_source = 2
    only_from = 192.168.1.11
  #E Expert
    server = /usr/sbin/pure-ftpd
    server_args =  -l unix -A -E -k 95% -I 15 -c 20 -S 21
    socket_type = stream
    protocol = tcp
    wait = no
    user = root
    disable = no
  }

Die Datei /etc/xinetd.d/ftp.expert wurde in die Datei /etc/xinetd.d/ftp nach der öffnenden geschweiften Klammer aber vor dem Inhalt der Originaldatei, eingefügt.

Zwei spezielle Kommentarzeilen wurde hinzugefügt

  #B Expert
  #E Expert

Siehe: (Man-xinetd) für eine Beschreibung der Xinetd Konfigurationsdatei.

Das obige Beispiel limitiert den Zugriff via ftp auf eine einzige IP-Adresse (only_from = 192.168.1.11) und limitiert zusätzlich die Anzahl der Verbindungen auf 2 (per_source = 2).

Achtung: Bitte vorsichtig mit dieser Option umgehen, da es so sehr einfach ist eine fehlerhafte Konfigurationsdatei für den Xinetd zu erzeugen. Bitte in Datei /var/log/messages nachschauen, ob der Xinetd erfolgreich startet.

Bitte auf keinen Fall die beiden speziellen Kommentarzeilen verändert oder löschen. Sie sind sehr wichtig, wenn <service>.expert-Dateien gelöscht bzw. verändert werden und dadurch natürlich auch die Inhalte der Servicedatei geändert werden müssen.

Die Behandlung der <service>.expert-Dateien wird bei jedem Start des Xinetd durchgeführt (z.B. bei /etc/init.d/xinetd start).

Die Idee für <service>.expert-Dateien stammt von Tobias Becker.

	1.		View documentaion
	2.		Edit configuration
	3.		Show status
	4.		Stop Xinetd
	5.		Start Xinetd
	6.		Advanced configuration file handling