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.

BŁĘDY

       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

       Autorami polskiego tłumaczenia niniejszej strony podręcznika man są: Przemek Borys (PTM)
       <pborys@dione.ids.pl> i Robert Luberda <robert@debian.org>.

       Polskie tłumaczenie jest częścią projektu manpages-pl; uwagi, pomoc, zgłaszanie błędów na
       stronie http://sourceforge.net/projects/manpages-pl/. Jest zgodne z wersją  7.6.q
       oryginału.

                                                                                          TCPD(8)