Jeśli korzystasz z usług Network Information

SYSADMIN Oparta na Kerberosie autoryzacja w NIS Bilety zaufania Infrastruktura oparta na usługach Network Information Service (NIS) i Kerberos umożliwia administratorom zarządzanie dużą ilością użytkowników, zapewniając jednocześnie bezpieczne logowanie. Możliwości kryptograficzne Kerberosa, pozwalające zastąpić niebezpieczne usługi oparte na IP, są kluczem do budowy tej infrastruktury. THORSTEN SCHERF Jeśli korzystasz z usług Network Information Service do scentralizowanego zarządzania użytkownikami, masz spory problem związany z bezpieczeństwem szczególnie, jeśli używasz NIS do zarządzania bazą haseł typu shadow. Idea plików shadow jest taka, żeby chronić zaszyfrowane hasła przed bezpośrednim dostępem użytkowników. Jeśli NIS zajmuje się obsługą tego pliku, zhaszowane hasła są przesyłane przez sieć przy każdym logowaniu. Napastnik może oczywiście przechwycić te dane używając sniffera typu Ethereal, a następnie przeprowadzić próbę łamania haseł metodą słownikową lub brute force. Spójrzmy, co oferuje Kerberos [1]. Kerberos wykorzystuje do ochrony haseł techniki szyfrujące i pomysłowe rozwiązanie problemu transportu informacji o autoryzacji od klienta. W tym artykule zajmiemy się systemem NIS w wersji 2, używającym Kerberosa 5 do autoryzacji. Mimo że ukazał się już NIS 3, obecnie dla Linuksa dostępny jest jedynie klient, serwer jest wciąż w stadium rozwoju. NIS 3, zwany też NIS+, jest również o wiele bardziej skomplikowany do konfiguracji. Jeśli chcesz się dowiedzieć czego więcej o NIS+, zajrzyj do dokumentu NIS HOWTO [2]. Trzygłowa hydra Administratorzy często traktują filrewalle jako rozwiązanie wszystkich problemów związanych z bezpieczeństwem. Tymczasem Listing 1: Konfiguracja klienta NIS 01 # 02 # domain NISDOMAIN server HOSTNAME 03 # Użyj serwera HOSTNAME dla domeny NISDOMAIN. 04 # 05 # domain NISDOMAIN broadcast 06 # Użyj adresu broadcast dla domeny NISDOMAIN 07 # 08 # ypserver HOSTNAME 09 # Użyj serwera HOSTNAME dla lokalnej domeny. 10 # Adres IP musi być w /etc/hosts. 11 # 11 # broadcast 12 # Na koniec spróbuj adresu broadcast 13 # jako ostatniej deski ratunku 14 # 15 # 16 domain EXAMPLE server nis1.notexample.com większość zagrożeń pochodzi z sieci lokalnej. Napastnik działający od tej strony może łatwo przechwytywać hasła. Rozwiązaniem tego problemu może być oprogramowanie takie jak Kerberos. Programiści z Massachusetts Institute of Technology (MIT) stworzyli Kerberosa, żeby zapewnić bezpieczną autoryzację dla aplikacji pracujących w architekturze klient-serwer. W tym celu Kerberos wykorzystuje silne szyfrowanie i protokół autoryzacji oparty na wydawaniu specjalnych biletów. Popularne usługi, takie jak FTP lub POP3, zazwyczaj oznaczają zagrożenie dla bezpieczeństwa sieci ponieważ nazwy użytkowników i ich hasła są przesyłane od klienta do serwera w postaci czystego tekstu. Kerberos usuwa to niebezpieczeństwo, sprawiając, że żadne niezaszyfrowane hasła nie są przesyłane. Kerberos utrudnia również podszywanie się (spoofing) i inne klasyczne ataki, dając również możliwość jednorazowej autoryzacji (single sign-on), tzn. że po dokonaniu (jednorazowej) autoryzacji, użytkownik ma dostęp do wszystkich usług. Klienci raz autoryzują www.linux-magazine.pl Czerwiec 2004 59

się do sieci i uzyskują automatycznie dostęp do usług, które chroni Kerberos. Kerberos obsługuje proces autoryzacji. Nie zajmuje się natomiast obsługą informacji, takich jak nazwa logowania, domyślna powłoka czy ścieżka do katalogu domowego. Obsługą tych danych zajmuje się usługa katalogowa taka jak NIS. AS KDC TGS Rozproszony Kerberos Architektura rozproszona Kerberosa zapewnia wysoki poziom bezpieczeństwa. Klient najpierw otwiera połączenie do centrum dystrybucji kluczy KDC (Key Distribution Center) patrz Rysunek 2. Ten proces jest całkowicie przezroczysty dla użytkownika i jest wykonywany przez program login albo kinit. KDC składa się z dwóch elementów logicznych: serwera autoryzacji AS (Authentication Server) i serwera przyznawania biletów TGS (Ticket Granting Server). Serwer autoryzujący czeka na żądania klienta i sprawdza, czy użytkownik ma uprawnienia do dostępu do usługi w ramach określonej strefy Kerberos. Po sprawdzeniu, że użytkownik istnieje w bazie Kerberos, AS generuje losowy klucz sesji i tzw. Ticket Granting Ticket (TGT). TGT zawiera kilka istotnych informacji, takich jak nazwa hosta klienta i jego adres IP, data ważności biletu, stempel czasowy i klucz sesji. Kerberos szyfruje TGT przy pomocy klucza, który jest znany jedynie serwerowi autoryzującemu i serwerowi przyznającemu bilety. Serwer wysyła bilet do klienta wraz z kluczem bieżącej sesji. Żeby zapobiec podsłuchowi, bilet jest szyfrowany przy pomocy zhaszowanego hasła klienta. Wpisz hasło Po odebraniu odpowiedzi (w formie zaszyfrowanego TGT i klucza sesji) od serwera autoryzacji lokalny system wyświetla zaproszenie do logowania. Klient NIS dokonuje konwersji hasła do postaci klucza DES, który jest używany do odszyfrowania odebranego TGT. Klient przechowuje odszyfrowane TGT w specjalnym buforze i usuwa hasło z pamięci. Użytkownik może udowodnić swoją tożsamość przy pomocy TGT tak długo, jak bilet jest ważny. Kiedy bilet wygasa, użytkownik będzie musiał zalogować się jeszcze raz i cała procedura zostanie powtórzona. Hasło i TGT potwierdzają tożsamość użytkowników lokalnej stacji roboczej. Jeśli taki użytkownik chce skorzystać z usługi sieciowej, np. FTP, musi poprosić centrum dystrybucji kluczy o przyznanie specjalnego TGT Client ST ST Rysunek 1: W trakcie sesji Kerberos hasło nigdy nie przechodzi przez sieć w formie niezaszyfrowanej. W Red Hat Linux konfiguracja klienta NIS jest prosta, ponieważ narzędzie Authconfig zawiera odpowiednie menu konfiguracyjne (patrz Rysunek 1). Należy po prostu podać nazwę serwera i domeny NIS. Narzędzie zapisuje zmiany w /etc/yp.conf (patrz Listing 1). Authconfig zmienia również plik /etc/sysconfig/network, ponownie dodając nazwę domeny NIS, która będzie używana po restarcie. Trzecim krokiem konfiguracji NIS przez program Authconfig jest plik /etc/nsswitch.conf. Plik określa, gdzie i w jakiej kolejności klient wyszukuje informacji o hasłach i plikach hosta. Oto wymagane wpisy: passwd: files nis shadow: files group: files nis W tym przypadku klient najpierw sprawdzi lokalne pliki /etc/passwd i /etc/group, a następnie sprawdzi mapy NIS passwd i group. Możesz pominąć wpis files, jeśli nie potrzebujesz lokalnej autoryzacji. To jednak uniemożliwi lokalne logowanie nawet użytkownikowi root. Primerg y Konfiguracja klienta NIS Server Rysunek 2: Administratorzy mogą użyć narzędzia Authconfig do konfiguracji klienta NIS, a szczególnie określenia domeny i serwera NIS. Authconfig zmienia również plik PAM /etc/pam.d/system-auth, tak żeby hasło użytkownika na serwerze NIS było zmieniane, jeśli należy do kont obsługiwanych przez NIS. Użytkownicy mogą do zmiany hasła użyć programu yppasswd. No koniec program Authconfig uruchamia usługę klienta NIS, ypbind w tle, aby otworzyć połączenie do serwera NIS. 60 Czerwiec 2004 www.linux-magazine.pl

Serwer NIS zarządza informacjami o użytkownikach i hostach, udostępniając te informacje klientom w ramach tej samej domeny NIS. Administratorzy mogą wykorzystać NIS do centralizacji zarządzania użytkownikami i hostami. Użytkownicy mogą uzyskać dostęp do bazy używając dowolnego klienta NIS do autoryzacji. Żeby umożliwić taką autoryzację, administrator musi po prostu zezwolić NIS na zarządzanie plikami /etc/passwd i /etc/group. Serwer NIS może również zarządzać o wiele częściej stosowanymi plikami haseł shadow. Konfiguracja serwera NIS Zanim rozpoczniemy konfigurację serwera, administrator musi najpierw określić nazwę dla nowej domeny NIS. Zdecydowanie nie powinna być ona taka, jak nazwa domeny DNS, ponieważ ułatwiłoby to zadane hakerom. W tym artykule przykładowa domena NIS nosi po prostu nazwę example. Tworzymy zatem wpis NISDO- MAIN=example w pliku /etc/sysconfig/network. Teraz, dla poprawnej konfiguracji musimy dostosować plik Makefile, który znajduje się w katalogu /var/yp. Większość ustawień domyślnych nie wymaga zmiany. Parametr MINUID określa minimalną listę użytkowników, którymi NIS może zarządzać. Parametr MINGID oznacza to samo, ale dla grup użytkowników. W naszym przykładzie musimy dla zmiennej MERGEPASSWD określić wartość false, ponieważ NIS nie będzie zajmował się sprawdzaniem haseł. Ostatnim krokiem jest wskazanie NIS, żeby zarządzał naszymi kontami użytkowników i grup, w tym celu dodajemy all: passwd group. NIS może oczywiście o wiele więcej, jednak inne opcje nie są nam teraz potrzebne. Konfiguracja NIS NIS nie korzysta z plików /etc/passwd czy /etc/group, ale używa narzędzia makedbm do tworzenia plików GDBM, które w terminologii NIS określane są mianem map. Makedbm tworzy dwie mapy NIS z każdego pliku. Każda mapa jest sortowana według innych kryteriów. Mapa pliku passwd jest sortowana według nazwy logowania (passwd.byname) i identyfikatora użytkownika (passwd.byuid). Wprowadzenie polecenia /usr/lib/yp/ypinit m spowoduje zainicjowanie serwera, nowe mapy znajdziesz w katalogu /var/yp. Zostanie utworzony katalog o takie samej nazwie jak twoja domena NIS. Baza NIS zawiera wpisy dla istniejących w chwili migracji kont użytkowników. Jeśli później będziesz dodawać użytkowników lub grupy, będzie trzeba zsynchronizować te informacje z mapami NIS. Administratorzy mogą to wykonać poleceniem make -C /var/yp. Serwer NIS rozpoczyna nasłuchiwanie z momentem uruchomienia usług portmap i ypserv. W celu uruchomienia tych usług należy zmodyfikować wpisy w katalogach /etc/init.d/. Redundancja i bezpieczeństwo W przypadku zcentralizowanej usługi katalogowej, takiej jak NIS, bardzo ważne jest posiadanie serwera zapasowego. Dzięki temu użytkownicy będą mieli możliwość logowania w przypadku, gdy główny serwer NIS nie będzie działać. Serwer zapasowy jest łatwy do uruchomienia. Po prostu podajemy adres IP serwera pierwszorzędnego jako argument polecenia ypinit: /usr/lib/yp/ypinit -s U Master-Server-IP Od tej chwili druga maszyna będzie miała taką samą mapę jak serwer główny (nastąpi synchronizacja). Pozostają jeszcze dwa kroki serwer zapasowy musi być skonfigurowany jako klient NIS, a plik /var/yp/ypservers na serwerze podstawowym musi wskazywać serwer zapasowy. Administratorzy powinni również przyjrzeć się temu, jak są zabezpieczone ich serwery NIS. Pamiętajmy, że klient NIS może wyświetlać zawartość każdego pliku, którym zarządza NIS. Polecenie ypcap passwd wyświetli mapę haseł. W tym przypadku passwd to alias dla passwd.byname i passwd.byuid. Plik /var/yp/nicknames zawiera więcej podobnych aliasów. Mimo że klient nie będzie miał dostępu do zaszyfrowanych haseł użytkowników, ponieważ ustawienie MERGEPASSWD=false w pliku Makefile, to i tak serwer udostępnia informacje o nazwach użytkowników. Dlatego administratorzy powinni ograniczyć dostęp do map NIS. Służy do tego plik /var/yp/securenets (patrz Listing 2), który zawiera listę dozwolonych sieci. Na poziomie IP najlepiej użyć reguł filtrujących, które ograniczą dostęp do portmappera. Reguła filtrująca mogłaby wyglądać w następujących sposób: iptables -t filter -A FORWARD U -p udp -dport 111 -s U 192.168.0.0/24 -d 192.168.0.100 U -j ACCEPT W tym przykładzie 192.168.0.0/24 to sieć posiadająca prawo dostępu, natomiast portmapper działa pod adresem 192.168.0.100. Należy jednak pamiętać, że te ograniczenia będą odnosiły się także do dowolnych, innych usług, które posługują się portmapperem. To samo ma zastosowanie, jeśli używasz TCP Wrappers do ochrony portmappera. biletu. Dlatego klient kontaktuje się najpierw z serwerem TGS (Ticket Granting Server), który przyznaje tzw. Service Ticket (ST), właśnie taki specjalny bilet dający dostęp do jednej określonej usługi w tym przypadku do FTP. Żądanie biletu dla usługi Żądanie biletu dla usługi jest o wiele bardziej skomplikowane niż pobieranie TGT. Klient przesyła żądanie do TGS. Żądanie jest generowane w oparciu o nazwę usługi, do której klient chce uzyskać dostęp i używany TGT. Żądanie obejmuje nazwę klienta, jego adres IP oraz dokładny czas po stronie klienta i jest szyfrowane kluczem sesji TGT. Klient wysyła zaszyfrowane żądanie i sam TGT do serwera przyznającego bilety. TGS deszyfruje żądanie i TGT, a następnie porównuje zawartość, zwłaszcza adres IP. Jeśli informacje potwierdzające tożsamość są identyczne, serwer generuje nowy klucz sesji, w którym przyznaje klientowi dostęp do żądanej usługi (w naszym przykładzie do FTP). Nowy klucz sesji jest zawarty w bilecie usługi, który serwer przyznający bilety właśnie wygenerował. Całość jest szyfrowana kluczem sesji TGT i przekazywana do klienta. Klient odbiera bilet dla usługi (ST) i prze- Rysunek 3: Program konfiguracyjny Authconfig zawiera opcję konfiguracji strefy (realm) i kontrolera domeny Kerberos. 62 Czerwiec 2004 www.linux-magazine.pl

SYSADMIN Wydarzenia w trakcie sesji Kerberos Użytkownik loguje się na lokalnej maszynie i przesyła żądanie logowania do serwera autoryzacji AS (Authentication Server). Serwer autoryzacji odpowiada, przekazując w odpowiedzi Ticket Granting Ticket (TGT). Klient ustanawia połączenie do usługi obsługiwanej przez Kerberosa, żądając wydania biletu specyficznego dla usługi Service Ticket (ST). Serwer przydzielający bilety TGS (Ticket Granting Server) generuje ST. Klient przekazuje bilet do usługi obsługiwanej przez Kerberosa. Użytkownik jest autoryzowany, połączenie jest ustanawiane, a użytkownik nie musi się ponownie autoryzować w okresie ważności biletu ST. kazuje go do serwera FTP, aby potwierdzić tożsamość klienta. Klient ponownie przesyła żądanie dostępu do usługi (tak jak dla TGS) i przesyła go do serwera. Jeśli treść ST i żądanie dostępu zgadzają się, klient otrzymuje dostęp do serwera. Klient już jest zautoryzowany wobec serwera i nie potrzebuje już wpisywać nazwy użytkownika i hasła. Nie ma ochrony bez NTP Powyższy sposób daje skuteczną ochronę przeciwko snifferom i przeciwko przechwyceniu biletu usługi, którego można by było użyć do prób podszywania się. Czynnikiem niezbędnym do prawidłowego działania autoryzacji klienta jest synchronizacja czasu w sieci lokalnej. Można do tego użyć usługi NTP (Network Time Protocol) [3]. Jednak ponieważ samo NTP jest niebezpieczną usługą IP, należy ją chronić używając szyfrowania. Pod Oprogramowanie Dla celów tego artykułu wykorzystaliśmy dystrybucję Red Hat 9. Opisane przykłady będą działać również w innych dystrybucjach - takich jak Red Hat Enterprise 3.x czy Fedora Core 1. Należy mieć jedynie zainstalowane następujące pakiety RPM [6]: krb5-workstation-1.3.1-6 krb5-libs-1.3.1-6 krb5-server-1.3.1-6 pam_krb5-2.0.4-1 adresem [3] znajdują się informacje na temat szyfrowania NTP. Serwer Kerberos Serwer Kerberos zarządza bazą, w której przechowywani są użytkownicy. Serwer taki musi być specjalnie chroniony także fizycznie. Należy unikać uruchamiania innych usług na maszynie, na której działa serwer Kerberos, ponieważ zmniejsza to poziom bezpieczeństwa. Obiekty reprezentują zarówno usługi korzystające z Kerberos-a, jak i hosty. Obiekt ma następującą strukturę: Primary/instance@REALM (instancja jest opcjonalna). Użytkownik może wyglądać następująco: thorsten/admin@notexample.com. Obiekt serwera FTP może wyglądać następująco: ftp/station1.notexample.com@ NOTE- XAMPLE.COM. Strefa (realm) jest rodzajem zbiornika dla nazw użytkowników w określonym obszarze 01 #/etc/krb5.conf 02 [logging] 03 default = FI- LE:/var/log/krb5libs.log 04 kdc = FILE:/var/log/krb5kdc.log 05 admin_server = FI- LE:/var/log/kadmind.log 06 07 [libdefaults] 08 ticket_lifetime = 24000 09 default_realm = NOTEXAMPLE.COM 10 dns_lookup_realm = false 11 dns_lookup_kdc = false 12 13 [realms] 14 NOTEXAMPLE.COM = { 15 kdc = kdc1.notexample.com:88 16 admin_server = kdc1.notexample.com:749 Listing 2: Securenets 01 # Zezwalamy na dostęp dla localhost-a: 02 host 127.0.0.1 03 04 # Zezwalamy na dostęp hosta z sieci 192.168.0.0/24: 05 255.255.255.0 192.168.0.0 06 07 # Zezwalamy na dostęp globalny (niebezpieczne!): 08 #0.0.0.0 0.0.0.0 i wygląda jak pisana dużymi literami nazwa domeny DNS. Baza Kerberos przechowuje hasła użytkowników i usług wraz z nazwami użytkowników. Serwer jest całkiem prosty w konfiguracji. Wprowadź nazwę strefy (realm) Kerberos w pliku /etc/krb5.conf (patrz Rysunek 3). Użyj polecenia kdb5_util create, żeby utworzyć bazę danych w pliku /var/kerberos/krb5kdc. Do zarządzania bazą lokalnie używamy polecenia kadmin.local, a zdalnie kadmin. Oczywiście zakładamy, że usługa kadmin działa na KDC i że do pliku /var/kerberos/krb5kdc/kadm5.acl dodano odpowiedniego administratora. Żeby dodać nowego użytkownika do bazy danych, użyj add_principal, np.: Password thorsten Dodawanie użytkownika usługi lub stacji roboczej przebiega podobnie:: Listing 3: Konfiguracja klienta Kerberos 17 default_domain = notexample.com 18 } 19 20 [domain_realm] 21.example.com = NOTEXAMPLE.COM 22 example.com = NOTEXAMPLE.COM 23 24 [kdc] 25 profile = /var/kerberos/krb5kdc/kdc.conf 26 27 [appdefaults] 28 pam = { 29 debug = false 30 ticket_lifetime = 36000 31 renew_lifetime = 36000 32 forwardable = true 33 krb4_convert = false 34 } www.linux-magazine.pl Czerwiec 2004 63

ftp ftp/ftp.notu example.com host host/station1.u notexample.com Hasła dla usług muszą być znane samym serwerom. Można to osiągnąć dokonując ekstrakcji hasła usługi z bazy Kerberos: ktadd -k U /etc/krb5.keytab host/station1.u notexample.com Po wykonaniu tych wszystkich czynności, w bezpieczny sposób skopiuj plik /etc/krb5.keytab na maszynę, na której ma działać usługa (można do tego użyć np. polecenia scp). Uruchom następnie KDC, wpisując service krb5kdc start (w Red Hat), aby uruchomić serwer Kerberos. AUTOR Thorsten Scherf jest specjalistą z zakresu bezpieczeństwa sieci, który pracuje dla firmy Red Hat, gdzie zajmuje się rozwojem projektów i szkoleniami. Rysunek 4: Bilet użytkownika po kinit. Korzystanie z usług Kerberos Żeby uruchomić usługę opartą na Kerberos, musisz najpierw zainstalować ją na komputerach, które mają ją udostępniać. Kerberos może obsługiwać wiele usług jednocześnie na jednej maszynie. Przykładowo katalog /usr/kerberos/sbin zawiera wersję demona FTP ftpd ze wsparciem dla Kerberosa. Jego plik konfiguracyjny gssftp znajduje się w katalogu /etc/xinetd.d. Możesz użyć tego pliku do określenia, czy demon Xinetd powinien uruchamiać tę usługę i jakie mają być ogólne prawa dostępu. Kerberos może zabezpieczać każdą usługę, która obsługuje GSS API (Generic Security Service, [4]). Administratorzy muszą pamiętać o zasadzie, że port TCP/UDP może być przypisany tylko do jednej usługi. Zatem jeśli będziesz chcieć używać obsługującej Kerberosa usługi ftpd, będziesz musiał wyłączyć i usunąć dotychczas wykorzystywanego demona FTP. Należy też dokonać konfiguracji pliku /etc/krb5.conf na serwerach (patrz Listing 3). Konfiguracja klienta Kerberos Administratorzy korzystający z Red Hat-a mogą użyć narzędzia Authconfig (patrz Rysunek 3), aby dokonać konfiguracji stacji roboczej, tak jak w przypadku NIS (patrz opis w ramce). Wprowadź strefę Kerberos, KDC i serwer administracyjny w naszym przykładzie jest to ta sama maszyna co stacja robocza. Narzędzie Authconfig dodaje te parametry do plików /etc /krb5.conf (patrz Listing 3) i /etc/pam.d/system-auth. Klient Kerberos-a wywołuje moduł PAM pam_krb5.so w system-auth po to, żeby przekazać nazwę użytkownika do KDC (a właściwie serwera autoryzacji), żądając TGT. Alternatywnie możesz zastąpić program obsługi logowania, /bin/login, wersją z obsługą Kerberos-a, która znajduje się w katalogu /usr/kerberos/sbin. Po przekazaniu tożsamości użytkownika (niezbędnej do autoryzacji stacji roboczej w tej konfiguracji), do użytkownika zostaje przypisany ważny TGT. Polecenie klist lub klist -5 (oznacza obsługę biletów Kerberos-a w wersji 5) pozwala użytkownikowi sprawdzić poprawność biletu. Program klist wyświetla nie tylko odebrane bilety, ale także dodatkowe informacje, takie jak nazwa usługi i szczegóły na temat ważności biletu. Normalnie bilet jest ważny tylko 10 godzin, ale można zmienić to ustawienie w pliku /etc/krb5.conf. Użytkownicy mogą zmieniać swoje hasła na serwerze Kerberos, używając narzędzia kpasswd. A co na to Windows? Klienci korzystający z MS Microsoft mogą również używać Linux KDC dla celów autoryzacji [5]. Poza tym pamiętajmy, że kontroler domeny Windows (od 2000 wzwyż) jest po prostu kombinacją serwera Kerberos i LDAP (Lightweight Directory Access Protocol). Żeby dołączyć klienta Windows, należy przede wszystkim zdefiniować hosta Windows w bazie Kerberos. Klienci Windows muszą również wiedzieć, którego KDC będą używać, znać strefę (realm) Krberos oraz hasło hosta. Całkiem łatwo można to wszystko ustawić używając Ksetup, programu zawartego w Windows 2000 Resource Kit. Dodatkowo klienci Windows muszą mieć możliwość pobierania informacji o użytkownikach z usługi katalogowej (takiej jak LDAP). NIS się niestety do tego nie nadaje, ponieważ jest przeznaczony do obsługi systemów uniksowych. Bez wymówek Kerberos znacząco podnosi bezpieczeństwo sieci, chroniąc przed przesyłaniem haseł czystym tekstem. Kerberos jednak nie pomoże, jeśli użytkownicy będą korzystać z usług, które nie należą do strefy (realm) Kerberosa. Jeśli Kerberos nie potrafi obsługiwać usługi, z której korzystasz, być może najlepiej pozbyć się tej usługi. Tak czy inaczej jeśli potrzebujesz bezpiecznej autoryzacji, nie ma już żadnych wymówek! INFO [1] Kerberos: http://web.mit.edu/kerberos [2] NIS HOWTO: http://www.linux-nis.org/nis-howto [3] NTP: http://www.eecis.udel.edu/ ~mills/ntp/servers.html [4] GSS API RFC: http://www.faqs.org/rfcs/rfc1964.html [5] Kerberos 5 Interoperability: http://www.microsoft.com/windows2000/ techinfo/planning/security/kerbsteps.asp [6] Serwer FTP Red Hat-a: ftp://ftp.redhat.com/redhat/linux/9/ en/os/i386/redhat/rpms [7] Connection Tracking: http://www.sns.ias.edu/~jns/security/ iptables/iptables_conntrack.html 64 Czerwiec 2004 www.linux-magazine.pl