JAK NAZWISKO? - Linux Magazine
Transkrypt
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