tcpd - usługa kontroli dostępu do usług internetowych
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.
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.
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).
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.
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.
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.
Detale używania
tcpd zależą od informacji o
ścieżce, która została wkompilowana w program.
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.
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ć.
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.
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.
Domyślne lokacje tabel kontroli dostępu do hosta to:
/etc/hosts.allow
/etc/hosts.deny
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.
Wietse Venema ([email protected]),
Department of Mathematics and Computing Science,
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513,
5600 MB Eindhoven, The Netherlands
Autorami polskiego tłumaczenia niniejszej strony podręcznika
są: Przemek Borys <
[email protected]> i Robert Luberda
<
[email protected]>
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
[email protected]