NAZWA

       tcpd - usługa 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  jeden  do  jednego  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).

       Możliwe  są  dwa następujące sposoby działania: uruchomienie programu tcpd przed usługą uruchamianą przez
       inetd albo skonsolidowanie usługi z biblioteką  współdzieloną  libwrap,  tak  jak  to  udokumentowano  na
       stronie  podręcznika  host_access(3).  Gdy  usługa  jest  uruchamiane  przez  inetd,  to  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 oparta na wzorcach, podglądanie nazw użytkownika  wg  RFC 931  itp.,
       ochrona  przeciw  komputerom,  które  udają,  że  mają  inną nazwę domenową niż w rzeczywistości, a także
       ochrona przeciw komputerom podszywającym się pod czyjś inny adres sieciowy.

LOGOWANIE

       Połączenia monitorowane przez tcpd są raportowane przez 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 są zapisywane logi, należy przejrzeć konfigurację demona syslog, zwykle w pliku
       /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ł. Szczegóły opisano na
       stronie podręcznika hosts_access(5).

WERYFIKACJA NAZWY HOSTA

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

       tcpd weryfikuje nazwę komputera klienta, która jest zwracana przez zapytanie  serwera  DNS  adres->nazwa,
       sprawdzając nazwę komputera i adres zwróconego przez zapytanie serwera DNS nazwa->adres. Jeśli pojawi się
       niezgodność, tcpd wnioskuje, że ma do czynienia z komputerem podszywającym się pod inny komputer.

       Jeśli źródła są skompilowane z -DPARANOID, tcpd porzuci połączenie w wypadku niezgodności nazwy/adresu. W
       przeciwnym  wypadku,  nazwa  komputera  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 wyszukiwania RFC 931 itp. są włączone (opcja kompilacji), tcpd  spróbuje  uzyskać  nazwę  użytkownika
       klienta.  Powiedzie  się  to tylko, jeśli na komputerze klienta pracuje demon kompatybilny z RFC 931. 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 /inne/miejsce
            # mv /usr/sbin/in.fingerd /inne/miejsce
            # cp tcpd /usr/sbin/in.fingerd

       Przykład  zakłada,  że  demony sieciowe są w /usr/sbin. Na niektórych systemach, demony sieciowe znajdują
       się w /usr/sbin lub /usr/libexec, 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, należy dokonać następujących edycji w pliku konfiguracyjnym
       inetd (zwykle /etc/inetd.conf):

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

       stanie się:

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

       Przykład zakłada, że demony sieciowe są w /usr/sbin. Na niektórych systemach,  demony  sieciowe  znajdują
       się  w  /usr/sbin  lub  /usr/libexec, czasem nie mają przedrostka "in." w nazwie albo plik konfiguracyjny
       inetd nie zawiera pola z identyfikatorem użytkownika.

       Podobne zmiany będą wymagane dla innych usług, które mają być objęte tcpd. Po ich dokonaniu należy wysłać
       programowi inetd(8) "kill -HUP", aby zaczęły działać.

PRZYKŁAD 3

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

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

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

USTERKI

       Niektóre  demony  UDP  (i  RPC)  zwlekają chwilę po tym, jak zakończą pracę, aby móc ewentualnie obsłużyć
       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ż użycie gwiazdki w
       /etc/hosts.equiv.

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

PLIKI

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

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

ZOBACZ TAKŻE

       hosts_access(3), funkcje biblioteki libwrap.
       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

TŁUMACZENIE

       Tłumaczenie niniejszej strony podręcznika: Przemek Borys <pborys@dione.ids.pl> i Robert Luberda
       <robert@debian.org>

       Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać
       zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ
       ODPOWIEDZIALNOŚCI.

       Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-
       list@lists.sourceforge.net.

                                                                                                         TCPD(8)