Linux - tcp_wrappers - kontrola dostępu

Tcp_wrappers - kontrola dostępu

Integralną częścią większości dystrybucji Linuxa jest demon Wrapper o nazwie tcpd. Daje on administratorowi wysokiej jakości narzędzie kontrolujące przychodzące żądania połączeń. Jest on uruchamiany przez demona inetd, a w pliku /etc/inetd.conf ścieżki do poszczególnych demonów usług sieciowych zostały zastąpione ścieżką do tcpd.
W momencie otrzymania żądania danej usługi tcpd najpierw sprawdza informacje kontroli dostępu, a następnie uruchamia odpowiednią usługę, bądź odrzuca żądanie. Wrapper pełni więc dwie podstawowe funkcje: rejestruje żądania usług sieciowych oraz zajmuje się kontrolą dostępu do nich. I właśnie rejestracja żądań jest jedną z najistotniejszych funkcji monitorowania, udostępniając ważne informacje, zwłaszcza, jeśli szukamy potencjalnych intruzów. Do rejestracji komunikatów wykorzystywany jest demon syslogd, a konkretnie jego funkcja authpriv. Zaglądając do pliku /etc/syslog.conf możemy się przekonać, gdzie system rejestruje komunikaty, czyli miejsce przechowywania odpowiednich plików. Zazwyczaj jest to /var/log/secure.
Istnieją dwa zasadnicze pliki definiujące zasady postępowania podczas kontroli dostępu. Są to: /etc/hosts.allow oraz /etc/hosts.deny . Pierwszy z nich zawiera wpisy wskazujące na hosty, które mogą korzystać z poszczególnych usług, natomiast w pliku hosts.deny umieszcza się te hosty, od których żądania usług będą odrzucane.
Jako jedną z pierwszych czynności zaraz po zainstalowaniu systemu na serwerze, który będzie udostępniał jakiekolwiek usługi, proponuję wpisanie linii ALL:ALL w pliku hosts.deny. Zabronimy w ten sposób dostępu wszystkim, którzy żądają jakichkolwiek usług. Dopiero w pliku hosts.allow można wymieniać poszczególne usługi oraz hosty, które z nich będą mogły korzystać. Zapisów w obu plikach dokonujemy w formacie:

usługi : klienty [:polecenie powłoki]

Usługi, to zwyczajnie poszczególne usługi (mogą mieć postać listy usług oddzielanych przecinkami) lub słowo ALL, czyli wszystkie. Klienty, to nazwy hostów (także może być zapisana w postaci listy nazw hostów, domen, numerów sieciowych poszczególnych komputerów oddzielonych przecinkami) lub słowo LOCAL (wszystkie lokalne, czyli nie zawierające części nazwy domeny), czy też ALL oznaczające zwyczajnie wszystkie hosty. Polecenie powłoki, jako opcjonalny wpis, może zawierać konkretne polecenie, które tcpd wykona, gdy wpis zostanie dopasowany. Gdy tak się stanie, demon tcpd zarejestruje uzyskanie (bądź nie uzyskanie) dostępu i wykonuje polecenie, które zostało wpisane. Zazwyczaj cecha dodatkowego przetwarzania poprzez umieszczanie poleceń powłoki jest używana tylko w pliku hosts.deny, aby zebrać więcej informacji np. na temat intruza lub poinformować administratora o próbie niewłaściwego uzyskania dostępu do serwera, czyli potencjalnym ataku. Do programu Wrapper dołączany jest także program safe_finger, który może zostać użyty do konstrukcji poleceń. Jest on dużo bezpieczniejszy, niż zwykły finger. Do konstrukcji poleceń możesz również użyć zmiennych, które umożliwiają pobranie konkretnych wartości z nadchodzącego połączenia. A oto ich lista:

%a - adres IP klienta

%A - adres IP serwera

%c - wszystkie dostępne informacje o kliencie

%d - nazwa procesu demona usługi sieciowej

%h - nazwa hosta klienta (jeśli nie jest dostępna, używany jest adres IP)

%H - nazwa hosta serwera

%n - nazwa hosta klienta (jeżeli nie jest dostępna, używane jest słowo UNKNOWN. Jeżeli natomiast wyszukiwanie DNS nazwy hosta klienta i adresu IP nie zgadzają się, użyte zostaje słowo kluczowe PARANOID)

%N - nazwa hosta serwera

%p - ID procesu (PID) demona usługi sieciowej

%s - wszystkie dostępne informacje o serwerze

%u - nazwa użytkownika klienta (jeżeli nie jest dostępna, użyte zostanie słowo kluczowe UNKNOWN)
Za pomocą standardowej składni kontroli dostępu możemy zdefiniować prawie każdą potrzebną regułę. Jednak jeśli to nie wystarcza, można skorzystać z opcjonalnego rozszerzenia kontroli dostępu programu Wrapper. Jednak w takim przypadku należy skompilować własną wersję programu z włączoną opcją PROCESS_OPTIONS (jeśli korzystasz np. z Red Hata 6.2, to Wrapper standardowo działa już według nowych zasad). Składnia języka kontroli dostępu zostanie wtedy rozszerzona i przedstawia się następująco:

usługi : klienty : opcja : opcja ...

Do każdej reguły można zastosować wiele opcji, m.in.:

allow - przyznaje żądaną usługę (musi pojawiać się na końcu reguły!)

deny - odmawia przyznania żądanej usługi (również musi się pojawiać na końcu reguły)

spawn polecenie powłoki - wykonuje polecenie jako proces podrzędny

twist polecenie powłoki - wykonuje polecenie zamiast żądanej usługi

keepalive - wysyła do klienta komunikat sygnalizujący aktywność, a jeśli klient nie odpowiada, to połączenie zostaje zerwane

linger sekundy - określa, jak długo mają trwać próby dostarczenia danych po zamknięciu połączenia przez serwer

rfc931 [czas oczekiwania] - użycie protokołu IDENT w celu sprawdzenia nazwy użytkownika klienta. Czas definiuje, ile sekund serwer ma czekać na odpowiedź.

banners ścieżka - wyświetla u klienta zawartość pliku z komunikatem. Ścieżka określa nazwę katalogu zawierającego pliki nagłówkowe (banner files). Wyświetlony zostaje ten plik, który posiada taką samą nazwę, jak proces demona danej usługi sieciowej.

nice [numer] - ustawia wartość nice dla procesu usługi. Jądro używa wartości nice do obliczenia priorytetów szeregowania.

umask maska - ustawia wartość umask dla plików tworzonych przez dany proces

user użytkownik [.grupa] - uruchamia proces usługi sieciowej z określonym ID użytkownika i ID grupy, niezależnie od tego, co jest zdefiniowane w ident.conf

setenv nazwa wartość - ustawia zmienną środowiskową dla środowiska uruchomieniowego procesu.

A oto przykład:

in.rshd : ALL : spawn /usr/sbin/safe_finger -l @%c | /bin/mail -s %h%d root : DENY

Zdalny system próbuje uruchomić rshd, jednak w pierwszej kolejności uruchamiane jest polecenie safe_finger, a jego wyniki są wysyłane do konta administratora. Następnie połączenie jest zamykane.
Masz naprawdę duże pole do popisu podczas konstruowania reguł kontroli dostępu, więc wykorzystaj to, by zwiększyć bezpieczeństwo swojego systemu. Należy jednak pamiętać, iż nawet korzystając z rozszerzonej składni Wrappera, możemy chronić tylko usługi uruchamiane przez inetd lub takie, które same z siebie czytają pliki hosts.allow i hosts.deny. Dla innych usług należy użyć ściany ogniowej, a o tym możesz przeczytać w artykule: Ipchains - reguły ściany ogniowej.

<<< powrót do strony głównej