tcpd

Autres langues

Langue: pl

Autres versions - même langue

Version: 55867 (openSuse - 09/10/07)

Autres sections - même nom

Section: 8 (Commandes administrateur)

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