04.pdf

Rozdział 4

Protokoły zabezpieczeń

Rozwi ą zania natychmiastowezobacz na stronie

Konfigurowanie protokołów z kluczami tajnymi (shared secrets protocol)

Zastosowanie Centrum Dystrybucji Kluczy (Key Distribution Center — KDC)

Podstawowe wiadomo ś ci o podprotokołach (subprotocols) protokołu Kerberos

Analiza biletów protokołu Kerberos (Kerberos tickets)

Delegowanie uwierzytelniania

Konfigurowanie zasad domeny protokołu Kerberos (Kerberos domain policy)

Zastosowanie interfejsu usługodawcy obsługi zabezpiecze ń (Security Support Provider Interface)

W skrócie

Protokoły

Protokoły s ą zasadnicz ą cz ęś ci ą ka Ŝ dego systemu zabezpiecze ń , a podstawowe wiadomo ś ci o

protokołach zastosowanych w systemie Windows 2000 s ą koniecznym elementem wyposa Ŝ enia

administratora. Jednak protokołów nie konfiguruje si ę od razu, jak np. Active Directory czy zasady

grupowe (Group Policy). Przed przyst ą pieniem do konfigurowania protokołu, konieczna jest

znajomo ść zasad ich działania oraz skutków, jakie poci ą gaj ą za sob ą wprowadzane zmiany.

Niniejszy rozdział zawiera wi ę cej teorii ni Ŝ którykolwiek z pozostałych w tej ksi ąŜ ce i

jednocze ś nie mniej gotowych rozwi ą za ń i opisów czynno ś ci. Nie jest to bynajmniej złe —

poka ź na wiedza o protokołach zabezpiecze ń jest konieczna.

Zabezpieczenia warstwy transportowej (transport layer security) oparte na protokole Secure

Sockets Layer 3 (SSL 3/TLS) opisano w rozdziale 6., przy okazji omawiania certyfikatów z

kluczem publicznym (public key certificates). Zabezpieczenia protokołu IP (IP security) na

poziomie sieci omówiono w rozdziale 10. Pozostaje NT LAN Manager (NTLM) i protokół

Kerberos 5 . Protokołu NTLM u Ŝ ywa si ę , aby zapewni ć zgodno ść wsteczn ą (backward

compatibility) z poprzednimi wersjami sieciowych systemów operacyjnych Microsoftu (Microsoft

Network Operating Systems — NOS), takimi jak Windows NT 4 i LAN Manager. Tak wi ę c

wi ę ksza cz ęść niniejszego rozdziału po ś wi ę cona jest protokołowi Kerberos .

Rozwi ą zania pokrewne zobacz na stronie

Ustanawianie zabezpiecze ń sieci WWW (World Wide Web Security)

Porównanie protokołów NTLM i Kerberos

Usługodawca zabezpiecze ń NTLM w celu uwierzytelniania korzysta z procedury wyzwanie-

odpowied ź (challenge-response). Usługodawca zabezpiecze ń (security provider) zna hasło danego

u Ŝ ytkownika lub, ś ci ś lej mówi ą c, wyci ą g uzyskany za pomoc ą funkcji skrótu MD4 (MD4 hash of

the password). Za pomoc ą funkcji skrótu MD4 (MD4 hash) szyfruje losowo wygenerowany blok

danych i odsyła go do klienta (wyzwanie — challenge). Nast ę pnie klient rozszyfrowuje blok

danych i przesyła z powrotem do serwera. Je ś li klient równie Ŝ zna prawidłowe hasło, dane zostan ą

rozszyfrowane poprawnie i serwer zarejestruje danego klienta jako uwierzytelnionego. Z kolei

usługodawca zabezpiecze ń (security provider) generuje niepowtarzalny znacznik dost ę pu (access

token), który jest przesyłany do klienta, aby korzystał z niego w przyszło ś ci. Kolejne

uwierzytelnienia klienta dokonywane s ą na podstawie tego znacznika (token) i usługodawca

zabezpiecze ń (security provider) NTLM nie musi powtarza ć procedury uwierzytelniania

wyzwanie-odpowied ź (challenge-response).

Wskazówka: MD2 , MD4 i MD5 są algorytmami wyznaczania funkcji skrótu wiadomości

(message digest) opracowanych dla potrzeb aplikacji tworzących podpisy cyfrowe, w których

duŜy blok wiadomości (message) musi zostać „skompresowany” w sposób bezpieczny, zanim

zostanie podpisany za pomocą klucza prywatnego. Opis i kody źródłowe wymienionych

powyŜej trzech algorytmów moŜna znaleźć w dokumentach Requests For Comment (RFC) od

1319 do 1321. Więcej informacji dostępnych jest na stronie internetowej RSA Laboratory

www.rsasecurity.com/rsalabs/ , a szczególnie pod adresem Frequently Asked Questions (FAQ)

www.rsasecurity.com/rsalabs/faq/3-6-6.html .

Protokół Kerberos korzysta z idei biletów po ś rednich (proxy tickets). We ź my pod uwag ę , np.

proces A, który wywołuje aplikacj ę B. Nast ę pnie aplikacja B staje si ę personifikacj ą procesu A

(impersonates A), tzn. aplikacja B w ustalony sposób działa jak A. Jednak je ś li B, działaj ą c jako

A, wywoła inn ą aplikacj ę (C), to domy ś lnie aplikacja C b ę dzie personifikacj ą B (impersonate B), a

nie A, poniewa Ŝ uprawnienia dotycz ą ce zabezpiecze ń (security privileges) procesu A nie zostan ą

delegowane do aplikacji C. Prawdziwe delegowanie (delegation) — takie, jakie zapewnia protokół

Kerberos — oznacza, Ŝ e je ś li aplikacja B, która jest działaj ą cym w ą tkiem (thread) A, wywoła inn ą

aplikacj ę — C — to aplikacja C mo Ŝ e by ć personifikacj ą A (impersonate A). Aplikacja B posiada

bilet po ś redni (proxy ticket) aplikacji A, który umo Ŝ liwia personifikacj ę A (impersonate A) nawet,

je ś li wywołuje inne aplikacje.

Komputery pracuj ą ce pod kontrol ą systemów Windows 3.11, Windows 95, Windows 98 lub

Windows NT 4 b ę d ą korzystały z protokołu NTLM przy uwierzytelnianiu sieciowym (network

authentication) w domenach Windows 2000. Komputery pracuj ą ce pod kontrol ą systemu

Windows 2000 b ę d ą korzystały z protokołu NTLM w przypadku uwierzytelniania przez serwery

systemu Windows NT 4 i przy dost ę pie do zasobów znajduj ą cych si ę w domenach systemu

Windows NT 4. Ale w systemie Windows 2000 głównym protokołem jest Kerberos . Korzy ś ci z

zastosowania protokołu Kerberos do uwierzytelniania s ą nast ę puj ą ce:

uwierzytelnianie wzajemne (mutual authentication) — protokół NTLM pozwala serwerowi na

weryfikowanie to Ŝ samo ś ci klientów, ale nie umo Ŝ liwia klientom sprawdzania to Ŝ samo ś ci

serwera ani nie daje serwerowi mo Ŝ liwo ś ci zweryfikowania to Ŝ samo ś ci innego serwera.

Protokół Kerberos gwarantuje, Ŝ e obydwie strony poł ą czenia sieciowego wiedz ą , Ŝ e druga

strona poł ą czenia jest tym, za co si ę podaje,

szybsze poł ą czenia — w przypadku uwierzytelniania za pomoc ą protokołu NTLM serwer

aplikacji, aby uwierzytelni ć ka Ŝ dego klienta, musi doł ą czy ć si ę do kontrolera domeny (DC).

W przypadku uwierzytelniania za pomoc ą protokołu Kerberos , serwer nie musi odwoływa ć

si ę do kontrolera domeny (DC), ale zamiast tego mo Ŝ e uwierzytelni ć klienta, sprawdzaj ą c

jego dane uwierzytelniaj ą ce (credentials). Klienci uzyskuj ą dane uwierzytelniaj ą ce

(credentials) dla danego serwera tylko raz, a potem korzystaj ą z nich ponownie w trakcie

logowania sieciowego (network logon session),

prostsze zarz ą dzanie relacjami zaufania (trust management) — jedn ą z głównych korzy ś ci

uwierzytelniania wzajemnego (mutual authentication) w przypadku protokołu Kerberos jest

to, Ŝ e relacje zaufania pomi ę dzy domenami systemu Windows 2000 domy ś lnie s ą obustronne

(two-way) i przechodnie (transitive). Je ś li sie ć zawiera kilka drzew, to dane uwierzytelniaj ą ce

— wydane przez domen ę w dowolnym drzewie — s ą uznawane w całym drzewie,

Uwaga: Przechodnia relacja zaufania (transitive trust) oznacza, Ŝe jeśli A ufa B i B ufa C, to A

ufa C. Relacje zaufania ustanawiane za pomocą protokołu Kerberos są przechodnie, a relacje

ustanawiane za pomocą protokołu NTLM — nie.

uwierzytelnianie delegowane (delegated authentication) — zarówno protokół NTLM , jak i

protokół Kerberos dostarczaj ą informacji potrzebnych usłudze do personifikowania

(impersonate) swojego klienta lokalnie, ale niektóre aplikacje rozproszone zostały

zaprojektowane tak, Ŝ e usługa zewn ę trzna (front-end service) musi personifikowa ć

(impersonate) klientów (clients), ł ą cz ą c si ę z usługami wewn ę trznymi (back-end services) na

innym komputerze. Protokół Kerberos zawiera mechanizm po ś rednicz ą cy (proxy

mechanism), który pozwala usłudze na personifikowanie klienta, kiedy ten ł ą czy si ę z innymi

usługami. Protokół NTLM takiego mechanizmu nie zawiera,

współdziałanie (interoperability) — implementacja protokołu Kerberos w wersji firmy

Microsoft jest oparta na specyfikacji przedstawionej grupie roboczej Internet Engineering

Task Force (IETF). W wyniku tego implementacja protokołu Kerberos w systemie Windows

2000 stanowi podstaw ę współdziałania z innymi sieciami (szczególnie z sieciami zgodnymi z

e standardem POSIX ), w których do uwierzytelniania stosuje si ę protokół Kerberos .

Protokół uwierzytelniania Kerberos umo Ŝ liwia wzajemne uwierzytelnianie (mutual authentication)

pomi ę dzy klientem a serwerem oraz pomi ę dzy dwoma serwerami, zanim pomi ę dzy nimi zostanie

ustanowione poł ą czenie sieciowe. Protokół przyjmuje, Ŝ e pocz ą tkowe transakcje (transactions)

pomi ę dzy klientami a serwerami maj ą miejsce w otwartej sieci, w której wi ę kszo ść komputerów

nie jest zabezpieczonych i „napastnicy” mog ą monitorowa ć oraz dowolnie modyfikowa ć pakiety

tak, jak w Internecie. Protokół Kerberos gwarantuje, Ŝ e nadawca wie, kim jest odbiorca i

odwrotnie oraz gwarantuje, Ŝ e nikt z zewn ą trz nie b ę dzie mógł si ę podawa ć za Ŝ adn ą ze stron.

Rozwiązania natychmiastowe

Konfigurowanie protokołów z kluczem

tajnym (shared secrets protocol)

W protokole Kerberos zastosowano uwierzytelnianie wymagaj ą ce kluczy tajnych (shared secrets).

Je ś li tylko dwoje ludzi zna klucz tajny (secret), wówczas ka Ŝ dy z nich mo Ŝ e zweryfikowa ć

to Ŝ samo ść drugiej strony przez uzyskanie potwierdzenia, Ŝ e osoba ta zna ten sam klucz tajny

(secret). Załó Ŝ my, Ŝ e np. Bonnie cz ę sto wysyła wiadomo ś ci do Clyde’a, który musi mie ć pewno ść ,

Ŝ e wiadomo ść od Bonnie jest autentyczna, zanim zacznie działa ć zgodnie z otrzymanymi

informacjami. Bonnie i Clyde jako rozwi ą zanie tego problemu wybrali hasło, które nie b ę dzie

udost ę pniane nikomu innemu. Je ś li z wiadomo ś ci od Bonnie b ę dzie wynikało, Ŝ e nadawca zna to

hasło, Clyde b ę dzie wiedział, Ŝ e nadawc ą jest Bonnie.

W jaki sposób Bonnie poka Ŝ e, Ŝ e zna to hasło? Mogłaby zamie ś ci ć w zako ń czeniu swojej

wiadomo ś ci co ś na wzór bloku podpisu (signature block). Jest to sposób prosty i wydajny, ale

b ę dzie bezpieczny tylko wtedy, gdy Bonnie i Clyde b ę d ą pewni, Ŝ e nikt inny nie czyta ich poczty.

Niestety, wiadomo ś ci s ą przesyłane przez sie ć , z której korzysta Szeryf, posiadaj ą cy analizator

sieci (network analyzer). Tak wi ę c Bonnie, jedynie podaj ą c hasło,nie mo Ŝ e udowodni ć , Ŝ e je zna,

tylko musi wykaza ć si ę jego znajomo ś ci ą bez przesyłania przez sie ć .

W protokole Kerberos rozwi ą zano ten problem za pomoc ą kryptografii z kluczem tajnym (secret

key cryptography). Zamiast współdzielenia hasła, partnerzy komunikacji współdziel ą klucz

(cryptographic key) i stosuj ą go do weryfikowania to Ŝ samo ś ci drugiej strony. Klucz wspólny

(shared key) musi by ć symetryczny (symmetric). Innymi słowy, ten sam klucz słu Ŝ y do

szyfrowania i odszyfrowywania. Jedna ze stron udowadnia znajomo ść klucza poprzez

zaszyfrowanie cz ęś ci danych, a druga — rozszyfrowuj ą c te dane. Uwierzytelnianie za pomoc ą

klucza tajnego (secret key authentication) rozpoczyna si ę , gdy jedna ze stron przedstawi warto ść

uwierzytelniaj ą c ą (authenticator) w postaci cz ęś ci danych zaszyfrowanych za pomoc ą klucza

tajnego. Zestaw danych do tworzenia warto ś ci uwierzytelniaj ą cej (authenticator) za ka Ŝ dym razem

musi by ć inny, w przeciwnym razie stara warto ść uwierzytelniaj ą ca mógłaby by ć wykorzystana

ponownie przez kogo ś , komu udałoby si ę podsłucha ć wymian ę danych. Po otrzymaniu warto ś ci

uwierzytelniaj ą cej (authenticator) odbiorca odszyfrowuje j ą . Je ś li odszyfrowanie przebiegło

pomy ś lnie, to odbiorca wie, Ŝ e osoba przedstawiaj ą ca t ę warto ść zna wła ś ciwy klucz. Tylko dwoje

ludzi ma wła ś ciwy klucz; odbiorca jest jedn ą z nich, wi ę c osoba przedstawiaj ą ca warto ść

uwierzytelniaj ą c ą musi by ć t ą drug ą .

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: