Provided by: manpages-pl_20060617-4_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

INFORMACJE O TŁUMACZENIU

       Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu Tłumaczenia Manuali i może
       nie być aktualne. W razie zauważenia różnic między powyższym opisem a rzeczywistym
       zachowaniem opisywanego programu lub funkcji, prosimy o zapoznanie się z oryginalną
       (angielską) wersją strony podręcznika.

                                                                                          TCPD(8)