BEZEICHNUNG¶

tcpd - Zugriffssteuerungseinrichtung für Internet-Dienste

BESCHREIBUNG¶

Das Programm tcpd kann zur Überwachung eingehender Anfragen für telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat und anderer Dienste verwandt werden, die eine Eins-zu-Eins-Beziehung mit ausführbaren Dateien haben.

Das Programm unterstützt sowohl 4.3BSD-artige Sockets als auch System-V.4-artige TLI. Die Funktionalität kann eingeschränkt sein, wenn das Protokoll unterhalb der TLI kein Internet-Protokoll ist.

Es gibt zwei mögliche Betriebsmodi: Ausführung von tcpd vor durch inetd(8) gestarteten Diensten oder das Linken eines Daemons gegen die dynamischen Bibliothek libwrap, wie das in der Handbuchseite hosts_access(3) beschrieben ist. Der Betrieb wenn inetd(8) gestartet wird ist wie folgt: Immer, wenn eine Anfrage für einen Dienst eintrifft, wird der Deamon inetd(8) dazu verleitet, das Programm tcpd anstelle des gewünschten Servers auszuführen. tcpd protokolliert die Anfrage und führt ein paar zusätzliche Prüfungen durch. Wenn alles stimmt, führt tcpd das geeignete Server-Programm aus und verschwindet wieder.

Optionale Funktionalitäten sind: Muster-basierte Zugriffssteuerung, Client-Benutzernamen-Suche mit RFC-931-usw.-Protokoll, Schutz vor Rechnern, die vorgeben, den Rechnernamen eines anderen Rechners zu besitzen und Schutz vor Rechnern, die vorgeben, die Netzwerkadresse von jemanden anderen zu besitzen.

PROTOKOLLIERUNG¶

Von tcpd überwachte Verbindungen werden über die Einrichtung syslog(3) gemeldet. Jeder Datensatz enthält einen Zeitstempel, den Rechnernamen des Clients und den Namen des angeforderten Dienstes. Diese Information kann zur Erkennung unerwünschter Aktivitäten nützlich sein, insbesondere wenn die Protokolldateiinformationen von mehreren Rechnern zusammengeführt werden.

Um herauszufinden, wo Ihre Protokolle abgelegt werden, untersuchen Sie die Konfigurationsdatei von Syslog, normalerweise /etc/syslog.conf.

ZUGRIFFSSTEUERUNG¶

Optional unterstützt tcpd eine einfache Form der Zugriffssteuerung, die auf Mustervergleichen basiert. Diese Zugriffssteuerungssoftware stellt Einhängepunkte für die Ausführung von Shell-Befehlen bereit, wenn ein Treffer gefunden wird. Die Details hierzu finden Sie in der Handbuchseite hosts_access(5).

RECHNERNAMEN-ÜBERPRÜFUNG¶

Das Authentifizierungsschema einiger Protokolle (rlogin, rsh) verlässt sich auf Rechnernamen. Einige Implementierungen glauben die Rechnernamen, die sie von einem zufälligen Name-Server bekommen; andere Implementierungen sind vorsichtiger, verwenden aber einen fehlerhaften Algorithmus.

tcpd überprüft die Client-Rechnernamen, die von dem Adresse→Name-DNS-Server zurückgeliefert werden, indem sie den Rechnernamen und die Adresse nachschlagen, die von dem Name→Adressen-DNS-Server zurückgeliefert wird. Falls hier ein Unterschied erkannt wird, schließt tcpd, dass er es mit einem Rechner zu tun hat, der vorgibt, den Rechnernamen von einer anderen Maschine zu besitzen.

Falls die Quellen mit »-DPARANOID« kompiliert wurden, wird tcpd bei Unstimmigkeiten zwischen Rechnernamen und -Adresse die Verbindung abbrechen. Andernfalls kann der Rechnername mit dem PARANOID-Platzhalter verglichen werden und danach eine geeignete Aktion ausgeführt werden.

RECHNER-ADRESSENFÄLSCHUNG¶

Optional deaktiviert tcpd Quell-Routing-Socket-Optionen bei jeder von ihm gehandhabten Verbindung. Dies beseitigt die meisten Angriffe von Rechnern, die vorgeben, eine Adresse zu haben, die zu einem Netzwerk eines Dritten gehört. UDP-Verbindungen profitieren nicht von diesem Schutz. Diese Funktionalität muss bereits beim Kompilieren aktiviert werden.

RFC 931¶

Wenn Nachschlagen gemäß RFC 931 usw. aktiviert ist (dies wird beim Kompilieren entschieden), wird tcpd versuchen, den Namen des Client-Benutzers zu ermitteln. Dies wird nur erfolgreich sein, falls auf dem Client-Rechner ein RFC-931-konformer Daemon läuft. Das Nachschlagen von Client-Benutzer-Namen wird bei Datagram-orientierten Verbindungen nicht funktionieren und kann zu spürbaren Verzögerungen bei Verbindungen von PCs führen.

BEISPIELE¶

Die Details der Verwendung von tcpd hängen von der Pfadnameninformation ab, die in das Programm einkompiliert wurde.

BEISPIEL 1¶

Dieses Beispiel gilt, wenn tcpd erwartet, dass die ursprünglichen Netzwerk-Daemons an einen »anderen« Ort verschoben werden.

Um den Zugriff auf den Dienst finger zu überwachen, wird der Finger-Daemon an einen »anderen« Ort verschoben und tcpd anstelle des ursprünglichen Finger-Daemons installiert. An den Konfigurationsdateien wird keine Änderung benötigt.

# mkdir /anderer/Ort
# mv /usr/sbin/in.fingerd /anderer/Ort
# cp tcpd /usr/sbin/in.fingerd

In diesem Beispiel wird angenommen, dass die Netzwerk-Daemons sich in /usr/sbin befinden. Auf einigen Systemen befinden sich die Netzwerk-Deamons in /usr/sbin oder in /usr/libexec, oder haben kein Präfix ».in.« in ihrem Namen.

BEISPIEL 2¶

Dieses Beispiel gilt, wenn tcpd erwartet, dass die Netzwerk-Deamons an ihrem ursprünglichen Ort verblieben sind.

Um den Zugriff auf den Dienst finger zu überwachen, führen Sie die folgenden Bearbeitungen an der Konfigurationsdatei von inetd(8) (normalerweise /etc/inetd.conf) durch:

finger  stream  tcp  nowait  nobody  /usr/sbin/in.fingerd  in.fingerd

Daraus wird:

finger  stream  tcp  nowait  nobody  /usr/sbin/tcpd     in.fingerd

In diesem Beispiel wird angenommen, dass sich die Netzwerk-Daemons in /usr/sbin befinden. Auf einigen Systemen befinden sich die Netzwerk-Daemons in /usr/sbin oder in /usr/libexec oder haben kein Präfix ».in.« in ihrem Namen oder es gibt kein Feld »userid« in der Konfigurationsdatei von inetd(8).

Ähnliche Änderungen werden für andere Dienste benötigt, die von tcpd abgedeckt werden sollen. Senden Sie ein kill -HUP an den Prozess inetd(8), damit die Änderungen wirksam werden.

BEISPIEL 3¶

Falls sich Daemons nicht in einem typischen Verzeichnis befinden (»geheim« oder anders), bearbeiten Sie die Konfigurationsdatei von inetd(8), so dass sie einen absoluten Pfadnamen für das Prozessnamensfeld festlegt. Beispiel:

    ntalk  dgram  udp  wait  root  /usr/sbin/tcpd  /usr/local/lib/ntalkd

Nur die letzte Komponente (»ntalkd«) des Pfadnamens wird für die Zugriffssteuerung und Protokollierung verwandt.

FEHLER¶

Einige UDP- (und RPC-)Daemons hängen noch einige Zeit herum, nachdem sie ihre Arbeit erledigt haben, falls noch eine weitere Anfrage hereinkommt. In der Konfigurationsdatei von inetd(8) werden diese Dienste mit der Option wait registriert. Nur die Anfrage, die solch einen Daemon gestartet hat, wird protokolliert.

Das Programm funktioniert nicht mit RPC-Diensten über TCP. Diese Dienste werden als rpc/tcp in der Konfigurationsdatei von inetd(8) registriert. Der einzige nichttriviale Dienst, der von dieser Einschränkung betroffen ist, ist rexd, der von dem Befehl on(1) verwandt wird. Dies ist kein großer Verlust. Auf den meisten Systemen ist rexd weniger sicher als ein Platzhalter in /etc/hosts.equiv.

RPC-Broadcast-Anfragen (Beispiel: rwall, rup, rusers) scheinen immer von dem antwortenden Rechner zu kommen. Folgendes passiert: der Client verteilt die Anfrage an alle portmap-Daemons im Netzwerk: Jeder portmap-Daemon leitet die Anfrage an einen lokalen Daemon weiter. Für Daemons wie rwall(1) scheint dann die Anfrage vom lokalen Rechner zu kommen.

DATEIEN¶

Die Standardorte der Rechner-Zugriffssteuerungstabellen sind:

/etc/hosts.allow
/etc/hosts.deny

SIEHE AUCH¶

hosts_access(3), Funktionen, die durch die Bibliothek libwrap bereitgestellt werden.
hosts_access(5), Format der tcpd-Zugriffssteuertabellen.
syslog.conf(5), Format der Syslogd-Steuerdatei.
inetd.conf(5), Format der Inetd-Steuerdatei.

AUTOREN¶

Wietse Venema <wietse@wzv.win.tue.nl>,
Department of Mathematics and Computing Science,
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513,
5600 MB Eindhoven, Niederlande

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.