JAK NAZWISKO? - Linux Magazine

Warsztat administratora: Ident
SYSADMIN
Wskazówki speców: Identd w serwerach linuksowych
JAK NAZWISKO?
W zeszłym miesiącu przedstawiliśmy narzędzia
wspomagające uruchamianie i zarządzanie usługami.
W tym zaprezentujemy protokół Ident, który umożliwia
tworzenie powiązań między nazwami użytkowników
i połączeniami TCP.
MARC ANDRÉ SELIG
M
iesiąc temu pisaliśmy o tym, jak
działają procesy serwera uruchamiane z poziomu usługi inetd [1].
Natomiast niniejszy artykuł o protokole Ident
ma na celu uświadomienie możliwości i pułapek, jakie wiążą się z konfigurowaniem serwerów uniksowych. Protokół Ident jest bardzo
prosty i służy do przypisywania nazwy użytkownika w systemie-kliencie do określonego
połączenia TCP.
Z protokołu Ident często korzystają usługi
FTP, IRC i SMTP. Kiedy nawiązywane jest
połączenie FTP, w zależności od konfiguracji niektóre serwery wymagają od klienta podania nazwy użytkownika lokalnego, który
takie połączenie otwiera. Proces ten został zilustrowany na Rysunku 1.
Następnie sam serwer FTP staje się klientem – ale protokołu Ident. Otwiera połączenie z portem 113 systemu, który uzyskuje dostęp do usługi FTP. Ponieważ port ten może
zostać dowiązany tylko przez roota (jest to je-
den z portów zastrzeżonych, noszących numery poniżej 1024), można ufać, że otrzymana odpowiedź będzie zgodna z prawdą.
Sam protokół jest oparty na prostej zasadzie: klient Ident wysyła dwa numery
portów połączenia FTP do serwera Ident
(na Rysunku 1 są to porty 33812 i 21). Demon Ident sprawdza w systemie, który
użytkownik jest właścicielem procesu dowiązanego do portu 33812 i zwraca klientowi identyfikator tego użytkownika. Niektóre demony zamiast identyfikatora użytkownika zwracają specjalnie spreparowany ciąg znaków.
Ident a bezpieczeństwo
Ident jest starą technologią, opracowaną
w czasach, gdy większość Uniksów była systemami wielodostępnymi, pracującymi w serwerowniach i zarządzanymi przez przynajmniej jednego administratora. Kiedy użytkownik zachował się nieprzyzwoicie i zaata-
Rysunek 1: Kiedy klient nawiązuje połączenie, serwer FTP żąda podania nazwy użytkownika,
który to połączenie otworzył.
WWW.LINUX-MAGAZINE.PL
kował z takiego systemu inny serwer, administrator bez trudu identyfikował winowajcę.
Demon Ident pomagał administratorowi
sprawdzić, kto korzystał z jakich usług. Operator zaatakowanego serwera kontaktował się
po prostu z administratorem komputera,
z którego nadszedł atak, i przekazywał mu zarejestrowaną przez klienta Ident nazwę użytkownika. To pozwalało szybko dotrzeć do
konta osoby, która przekroczyła uprawnienia.
Jednak usługa Ident spełnia swoje zadanie
tylko w przypadku występków szytych grubymi nićmi. Zabezpieczenie to bardzo łatwo
obejść nawet początkującym włamywaczom.
Dlatego Ident nie daje praktycznie żadnej
ochrony, tym bardziej, że nie obsługuje uwierzytelniania ani autoryzacji.
Znane problemy
Po stronie klienta Ident może wręcz stwarzać
zagrożenie. Użytkownik łączący się z nieznanym serwerem może niechcący udostępnić
wiele informacji o swoim komputerze. Ktoś
o złej woli może je wykorzystać do przeprowadzenia ataku na ten komputer. Dlatego
niektóre implementacje usługi zamiast „loginu” wysyłają specjalnie spreparowany ciąg
znaków (składający się z zaszyfrowanej nazwy użytkownika i znacznika czasu), a właściwą nazwę użytkownika rejestrują w dzienniku systemowym. Wtedy prawdziwa nazwa
użytkownika w ogóle nie dociera do zdalnego
systemu.
Ident pochodzi z czasów infrastruktur
z komputerem centralnym, dlatego dziś jego
NUMER 15 KWIECIEŃ 2005
63
SYSADMIN
Warsztat administratora: Ident
przydatność jest niewielka. Większość użytkowników w Internecie dysponuje dziś własnymi komputerami i sami sobie są administratorami. Mogą spowodować, że demon
Ident będzie odsyłał takie informacje, jakie
sobie zażyczą. Innymi słowy, nie można już
ufać odpowiedziom demonów Ident, nie mówiąc już o wykorzystywaniu ich na potrzeby
uwierzytelniania.
Jeszcze raz podkreślmy więc: Ident nie nadaje się do zabezpieczania komputerów. Natomiast znajomość i właściwe korzystanie z tego narzędzia mogą nam pomóc w rozwiązaniu
niektórych problemów z siecią. Wiele serwerów internetowych (w szczególności demony
IRC i SMTP) wymaga od łączących się z nimi
klientów identyfikacji przez protokół Ident.
Jeśli użytkownik nie uruchomił tej usługi
w swoim systemie, otwieranie połączenia może się przeciągać. Opóźnienie spowodowane
jest tym, że klient odrzuca przychodzące żądania Ident, a serwer próbuje dopóty, dopóki nie
wyczerpie się przeznaczony na to limit czasu.
Udostępnienie usługi Ident ma więc sens.
Spójrzmy, w jaki sposób możemy zainstalować jej serwer.
Instalujemy usługę Ident
Większość dystrybucji Linuksa zawiera
przynajmniej jedną implementację protokołu Ident. Ponieważ usługa ta jest wykorzystywana rzadko, warto jest uruchamiać ją z poziomu „superserwera” inetd lub Xinetd [1].
Jeśli korzystamy ze starszego rozwiązania inetd, do pliku /etc/inetd. conf dodajemy następujący wpis:
ident stream tcp nowait nobodyU
/usr/sbin/in. identd
Jeśli zaś w posiadanej dystrybucji działa
system Xinetd, musimy utworzyć plik o na-
Listing 1: Wpis serwera
Xinetd dla usługi identd
# file /etc/xinetd. d/identd
service ident
{
socket_type
= stream
protocol= tcp
wait
= no
user
= nobody
server
=
/usr/sbin/in. identd
disable
= no
}
64
NUMER 15 KWIECIEŃ 2005
zwie /etc/xinetd. d/identd i tam wprowadzić zawartość Listingu 1. W niektórych dystrybucjach są już dostępne gotowe konfiguracje, które wystarczy uaktywnić. W przypadku inetd trzeba w tym celu usunąć znaki #
sprzed odpowiednich linijek. W programie Xinetd linijkę disable = yes
odpowiedniej usługi zmieniamy na
disable = no.
Po zmianie konfiguracji do odpowiedniego „superserwera” wysyłamy
sygnał HUP, co spowoduje, że ponownie odczytuje on pliki konfiguracyjne
(killall -HUP inetd lub killall -HUP xinetd).
Rysunek 2: Ruter konfigurujemy tak, aby
przekazywał dane protokołu Ident.
Konfiguracja zapory
Skonfigurowanie i uruchomienie demona może nie wystarczyć. Wiele współczesnych komputerów zabezpieczonych jest zewnętrzną lub
lokalną zaporą sieciową. Poprawnie skonfigurowany filtr nie wpuszcza pakietów Ident. To
także może tłumaczyć opóźnienia w komunikacji z niektórymi serwerami internetowymi –
zapora po prostu ignoruje pakiety przychodzące pod port 113. Większość serwerów nie
czeka długo na odpowiedź z usługi Ident, ale
kilkusekundowe opóźnienie przed otwarciem
połączenia jest zawsze zauważalne.
Żeby nie czekać, możemy wywiercić dziurkę w zaporze. Narzędzie IPtables, dostępne
w jądrze 2.4 lub nowszym, umożliwia zdefiniowanie reguł, na podstawie których akceptowane są pakiety przychodzące serwera
Ident oraz związane z nimi odpowiedzi. Żeby
umożliwić przesyłanie takich pakietów, jako
root wydajemy następujące polecenia:
iptables
ident -j
iptables
ident -j
-I INPUT -p tcp -dportU
ACCEPT
-I OUTPUT -p tcp -sportU
ACCEPT
Rutery dostępowe
Powyższa konfiguracja zdaje egzamin, ale
tylko wtedy, gdy system jest podłączony bezpośrednio do Internetu przez modem albo linię ISDN czy DSL. Jeśli posiadamy ruter
udostępniający połączenia i przekazujący
pakiety do Internetu z komputerów sieci lokalnej, musimy odpowiednio zmodyfikować
obowiązujące na nim reguły zapory (Rysunek 2). Sposób, w jaki to zrobimy, zależy od
posiadanego rutera.
Przeskakujemy NAT
Teraz wszystkie komputery w sieci mogą wymieniać pakiety Ident z klientami zdalnymi.
WWW.LINUX-MAGAZINE.PL
Co jednak, jeśli w sieci stosowana jest technologia tłumaczenia adresów (NAT), dzięki
której pod jednym adresem IP funkcjonuje
więcej komputerów?
Tym razem nie wystarczy odpowiednio
skonfigurować filtr pakietów. Przychodzące
żądania Ident zawsze kierowane są pod zarezerwowany port o numerze 113. Potrzebna
byłaby inteligentna zapora, pamiętająca,
który komputer otworzył połączenie ze zdalnym adresem IP i odpowiednio kierująca
kolejne pakiety.
Jeśli nie chcemy tworzyć tak skomplikowanych konfiguracji, a jednocześnie przeszkadzają nam opóźnienia przy otwieraniu
połączeń FTP, IRC lub innych, filtr pakietów można po prostu skonfigurować tak, żeby zamiast ignorować pakiety Ident – odrzucał je. „Załatwiamy” to następującą regułką
IPtables:
iptables -I INPUT -p tcp -dport U
ident -j REJECT -reject-withU
tcp-reset
Komputer wysyłający żądanie otrzymuje
wtedy odpowiedź, że żądana usługa nie jest
dostępna. Zamiast czekać na upłynięcie limitu czasu, zdalny komputer od razu zaniecha prób nawiązania połączenia przez protokół Ident.
■
INFO
[1] Marc André Selig, „Herding Daemons:
Server Management with inetd and Xinetd”:
Linux Magazine International, nr 52.
[2] RFC 1413, protokół Ident:
http://www.faqs.org/rfcs/rfc1413.html