Provided by: manpages-pl_20060617-1_all bug

NAZWA

       tcpd - urządzenie kontroli dostępu do usług internetowych

OPIS

       Program  tcpd może zostać skonfigurowany do monitorowania nadchodzących
       żądań usług telnet, finger, ftp, exec, rsh, rlogin, tftp, talk,  comsat
       i   innych,   które   mają   mapowanie  typu  jeden-na-jeden  na  pliki
       wykonywalne.

       Program wspiera zarówno gniazda typu 4.3BSD jak i  TLI  z  System  V.4.
       Funkcjonalność  może  być  ograniczona  gdy  protokół  pod TLI nie jest
       protokołem internetowym (internet protocol).

       Działanie jest następujące: kiedy  tylko  pojawi  się  żądanie  usługi,
       demon  inetd uruchamia program tcpd zamiast oczekiwanego serwera.  tcpd
       loguje żądanie i wykonuje pewne  dodatkowe  sprawdzenia.  Gdy  wszystko
       jest w porządku, tcpd uruchamia odpowiedni serwer i wyłącza się.

       Dodatkowe  opcje  to:  kontrola dostępu w oparciu o wzorce, podglądanie
       nazw użytkownika wg RFC 931 itp, ochrona przeciw hostom,  które  udają,
       że  mają  inną  nazwę  hosta  niż rzeczywiście, a także ochrona przeciw
       hostom udającym czyjś inny adres sieciowy.

LOGOWANIE

       Połączenia monitorowane przez tcpd są  komentowane  poprzez  syslog(3).
       Każdy  rekord  zawiera  znak czasu, nazwę hosta klienta, a także żądaną
       usługę.  Te wiadomości mogą być przydatne  do  wykrywania  niechcianych
       działań, szczególnie gdy połączone są dane z logów wielu hostów.

       Aby   dowiedzieć  się,  gdzie  wędrują  twoje  logi,  sprawdź  w  pliku
       konfiguracyjnym demona syslog, zwykle /etc/syslog.conf.

KONTROLA DOSTĘPU

       Opcjonalnie, tcpd wspiera prosty mechanizm kontroli dostępu, opartej na
       porównywaniu  wzorców.   Umożliwia  to akcję podczas wywoływania komend
       powłoki, kiedy  wzorzec  będzie  odpowiadał.  Dla  szczegółów  obejrzyj
       stronę podręcznika hosts_access(5).

WERYFIKACJA NAZWY HOSTA

       Schemat  autentykacji  niektórych  protokołów  (rlogin,  rsh) bazuje na
       nazwach  hosta.  Niektóre  implementacje  wierzą  nazwie  hosta,  którą
       otrzymują  od  losowego  serwera  nazw;  inne implementacje są bardziej
       ostrożne, lecz używają wadliwych algorytmów.

       tcpd  weryfikuje  nazwę  hosta  klienta,  która  jest  zwracana   przez
       zapytanie  serwera  DNS adres->nazwa, poprzez sprawdzenie nazwy hosta i
       adresu zwróconego  przez  zapytanie  serwera  DNS  nazwa->adres.  Jeśli
       pojawi  się  niezgodność,  tcpd wnioskuje, że ma do czynienia z hostem,
       który udaje, że ma nazwę innego hosta.

       Jeśli źródła są skompilowane z -DPARANOID, tcpd  porzuci  połączenie  w
       wypadku  niezgodności  nazwy/adresu.  W przeciwnym wypadku, nazwa hosta
       może być porównana z  "dziką  kartą"  PARANOID,  po  czym  może  zostać
       podjęte odpowiednie działanie.

HOST ADDRESS SPOOFING

       Opcjonalnie,  tcpd  wyłącza  opcje  rutowania  źródeł  (source-routing)
       gniazd na każdym połączeniu, z którym  ma  do  czynienia.  Załatwia  to
       problem  większości ataków od hostów, które udają adres, nienależący do
       ich  sieci.  Usługi  UDP  nie  odnoszą  z  tego  zabezpieczenia  żadnej
       korzyści. Opcja ta musi być włączona podczas kompilacji.

RFC 931

       Gdy  podglądy  RFC  931  etc.  są  włączone  (opcja  kompilacyjna) tcpd
       spróbuje uzyskać nazwę użytkownika  klienta.  Powiedzie  się  to  tylko
       jeśli  na  hoście  klienta  pracuje  kompatybilny z RFC 931 daemon. Nie
       działa to na połączeniach zorientowanych datagramowo i może  spowodować
       zauważalne spowolnienia w wypadku połączeń z PC.

PRZYKŁADY

       Detale  używania  tcpd  zależą  od  informacji o ścieżce, która została
       wkompilowana w program.

PRZYKŁAD 1

       Ten przykład odnosi się do przypadku, gdy tcpd oczekuje, że  oryginalne
       demony sieciowe zostaną przeniesione w "inne" miejsce.

       Aby  monitorować  dostęp do usługi finger, przenieś oryginalnego demona
       finger w "inne" miejsce, a  zamiast  niego  zainstaluj  tcpd.  Nie  rób
       żadnych zmian w plikach konfiguracyjnych.

            # mkdir /other/place
            # mv /usr/etc/in.fingerd /other/place
            # cp tcpd /usr/etc/in.fingerd

       Przykład  zakłada,  że  demony  sieciowe  są  w /usr/etc. Na niektórych
       systemach, demony sieciowe znajdują się w /usr/sbin lub /usr/libexec, a
       czasem nie mają przedrostka `in.' w nazwie.

PRZYKŁAD 2

       Ten  przykład  odnosi  się  do  przypadku, gdy tcpd oczekuje, że demony
       sieciowe są w swoim oryginalnym miejscu.

       Aby monitorować dostęp do usługi finger, dokonaj następujących edycji w
       pliku     konfiguracyjnym    inetd    (zwykle    /etc/inetd.conf    lub
       /etc/inet/inetd.conf):

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

       stanie się:

            finger  stream  tcp  nowait  nobody  /some/where/tcpd     in.fingerd

       Podobne zmiany będą wymagane dla innych usług, które  mają  być  objęte
       tcpd.  Po  ich  dokonaniu  wyślij  do  inetd(8) sygnał `kill -HUP', aby
       zmiany zaczęły działać. Użytkownicy AIX mogą skorzystać  tu  z  komendy
       `inetimp'.

PRZYKŁAD 3

       W  wypadku  demonów,  które nie istnieją w ogólnym katalogu ("tajnych",
       czy  innych),  zmień  plik  konfiguracyjny  inetd  tak,  aby  wskazywał
       absolutną ścieżkę dla pola nazwy procesu. Na przykład:

           ntalk  dgram  udp  wait  root  /some/where/tcpd  /usr/local/lib/ntalkd

       Tylko  ostatni  komponent  (ntalkd)  ścieżki zostanie użyty do kontroli
       dostępu i do logowania.

BŁĘDY

       Niektóre demony UDP (i RPC) zwlekają chwilę po tym, jak zakończą pracę,
       a  kiedy  nadchodzi  następne  żądanie.  W pliku konfiguracyjnym inetd,
       usługi  te  są  zarejestrowane  z  flagą  wait.  Tylko  żądanie,  które
       uruchomiło taki daemon zostanie zalogowane.

       Program   nie   działa  z  usługami  RPC  poprzez  TCP.  Usługi  te  są
       zarejestrowane w pliku inetd jako rpc/tcp. Jedyną nietrywialną  usługą,
       która  jest  dotknięta  tym  ograniczeniem,  jest  rexd,  używany przez
       komendę on(1). Nie jest to wielka strata. Na większości  systemów  rexd
       jest mniej bezpieczny niż /etc/hosts.equiv.

       Żądania  typu  broadcast  RPC (np: rwall, rup, rusers) zawsze jawią się
       jako  pochodzące  od  hosta  odpowiadającego.  Jeśli  klient  rozgłasza
       żądanie  do  wszystkich  demonów  portmap  w  jego  sieci: każdy daemon
       portmap przekazuje żądanie lokalnemu  demonowi.  Z  kolei  demony  typu
       rwall itp. widzą, że żądanie pochodzi od hosta lokalnego.

PLIKI

       Domyślne lokacje tabel kontroli dostępu do hosta to:

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

ZOBACZ TAKŻE

       hosts_access(5), format tabel kontroli dostępu tcpd.
       syslog.conf(5), format pliku kontrolnego syslogd.
       inetd.conf(5), format pliku konfiguracyjnego inetd.

AUTORZY

       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, The Netherlands

                                                                       TCPD(8)