Provided by: manpages-pl_4.25.1-1_all 
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
Autorami polskiego tłumaczenia niniejszej strony podręcznika są: 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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)