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.

                                                                                                         TCPD(8)