Bezpieczeństwo sieci Wi-Fi – część 8. (WPA/WPA2-Enterprise: RADIUS)

13 stycznia 2014, 09:02 | Teksty | 1 komentarz
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

 

Wstęp

RADIUS (Remote Authentication Dial In User Service) jest to protokół sieciowy realizujący zadanie centralnego uwierzytelniania i autoryzacji (RFC 2865) oraz rozliczalności (RFC 2866). Po angielsku określany jest jako protokół AAA (authentication, authorization, accounting).

Specyfikacja protokołu powstała w 1991 roku. Ze względu na szerokie wsparcie sprzętowo-programowe jest powszechnie używany przez ISP (Internet Service Providers) w celu kontroli dostępu do Internetu oraz rozliczania zakresu świadczonej usługi.

RADIUS stanowi kompleksowe rozwiązanie pozwalające realizować koncepcję AAA w bardzo szerokim zakresie:

  • uwierzytelnianie (authentication) – ze względu na wykorzystanie protokołu EAP uzyskuje się wiele mechanizmów uwierzytelniania użytkowników, które mogą być wykorzystane w zależności od posiadanej infrastruktury, baz i formatów przechowywania danych o użytkownikach, zastosowania infrastruktury PKI, wymaganego poziomu bezpieczeństwa itp.
  • autoryzacja (authorization) – możliwość realizacji zarządzania i kontroli dostępu użytkowników, w zależności od wielu parametrów, np. pora dnia, dzień tygodnia, zarządzanie użytkownikiem w sieci przez przypisane do konkretnego VLAN-u itp.
  • rozliczalność (accounting) – prowadzenie rozliczania różnych parametrów dotyczących sesji użytkownika, np. zużyty transfer, czas połączenia itp.

Jak to zostało wspomniane w poprzedniej części, RADIUS jest najczęściej używanym protokołem do realizacji standardu 802.1X.

 

Protokół RADIUS

RADIUS jest protokołem typu klient–serwer, działa z wykorzystaniem protokołu UDP, korzysta z portu 1812 dla uwierzytelniania i autoryzacji oraz z portu 1813 do realizacji mechanizmów rozliczalności. Pakiet protokołu RADIUS składa się między innymi z następujących pól:

  • określenia typu komunikatu,
  • pola authenticator służącego do uwierzytelniania odpowiedzi od serwera i ukrycia przesyłanego hasła użytkownika,
  • listy AVP (Attribute value pairs) – pary: atrybut–wartość,
  • listy VSP (Vendor-Specific Attributes) – analogicznie jak AVP, są to atrybuty specyficzne dla danego producenta sprzętu.

Zdefiniowane są następujące typy komunikatów:

  • Access-Request,
  • Access-Accept,
  • Access-Reject,
  • Access-Challenge,
  • Accounting-Request,
  • Accounting-Response.

Jak widać powyżej, sam pakiet protokołu RADIUS nie jest bardzo skomplikowany. Komunikacja w ramach protokołu obywa się według następującego schematu:

  1. Klient (NAS) serwera RADIUS wysyła do serwera zapytanie „Access-Request” wraz z odpowiednią listą AVP.
  2. Serwer odpowiada jednym z 3 komunikatów:
  • Access-Accept – urządzenie może zostać podłączone,
  • Access-Reject – urządzenie nie może zostać podłączone do sieci,
  • Access-Challenge – wymagane jest przesłanie dodatkowych danych.

W przypadku otrzymania „Access-Challenge” od serwera NAS przesyła odpowiedź do urządzenia chcącego się podłączyć i pośredniczy w transmisji dodatkowych danych. W ten sposób realizowane jest rozszerzenie powyższego schematu. Po uzyskaniu odpowiednich odpowiedzi od NAS, serwer RADIUS przyznaje lub zabrania dostępu. Taki model pozwala na zestawienie wspomnianego wcześniej (w kontekście EAP) tunelu TLS (wymagającego wymiany większej liczby komunikatów niż tylko dwa) pomiędzy serwerem a urządzeniem użytkownika.

Powyższy schemat wydaje się być nieskomplikowany, ale siła protokołu RADIUS tkwi we wspominanych wcześniej AVP. To właśnie AVP niosą dodatkowe informacje niezbędne do realizacji różnych metod EAP, zestawiania tunelu TLS czy zarządzania użytkownikiem w sieci, np. przydzielanie użytkownika do konkretnego VLAN-u lub nadawanie ustalonej konfiguracji sieciowej.

1. Identyfikator użytkownika

Serwer RADIUS uwierzytelnia użytkownika, wykorzystując otrzymany unikatowy login. W zależności od użytej metody EAP oprócz loginu użytkownik przesyła hasło lub certyfikat w celu potwierdzenia swojej tożsamości. Login użytkownika składa się z 2 elementów:

  • nazwy użytkownika,
  • realmu – fragmentu identyfikującego użytkownika w ramach danej organizacji (użycie realmu jest opcjonalne w zależności od przyjętej implementacji w danej sieci).

W związku z tym login ma postać user@realm, jednak znak @ nie jest jedynym dopuszczalnym separatorem obu wartości (zależy to od konfiguracji serwera).

2. Roaming

Wygodna skalowalność infrastruktury opartej o protokół RADIUS w dużej mierze przyczyniła się do jego popularności. Protokół ten pozwala na realizację funkcjonalności proxy dającej możliwość komunikacji pomiędzy wieloma systemami.

Serwer RADIUS po otrzymaniu komunikatu Access-Request w pierwszej kolejności sprawdza, czy dane zapytanie jest do niego adresowane. Odbywa się to na podstawie realmu.

Serwer RADIUS sprawdza, czy ma skonfigurowany dany realm, jeśli tak, to analizuje takie zapytanie.

Jeśli nie, to dostępne są 2 możliwości:

  1. odrzucić prośbę o podłączenie przez wysłanie Access-Reject,
  2. użyć funkcji proxy i przekazać zapytanie do innego serwera, który będzie je w stanie obsłużyć.

W przypadku drugiego scenariusza serwer, który jako pierwszy otrzymał zapytanie, stanowi proxy i pośredniczy w wymianie komunikatów pomiędzy serwerem macierzystym dla danego realmu, a użytkownikiem. Analiza realmu pozwala na podjęcie decyzji, do jakiego serwera należy przesłać dane zapytanie uwierzytelniające.

Dzięki tej funkcjonalności, możliwe jest realizowanie roamingu – użytkownik ma możliwość korzystania z innych sieci niebędących pod zarządem macierzystej organizacji. W tym przypadku obsługa AAA tego użytkownika jest przekazywana do macierzystego serwera. Przy odpowiedniej konfiguracji możliwe jest zapewnienia całkowitej anonimowości użytkownika znajdującego się w gościnnej sieci. Serwer pośredniczący nie będzie znał nawet jego loginu, a jedyną posiadaną informacją będzie realm identyfikujący organizację macierzystą gościa. Macierzysty serwer RADIUS wyśle tylko zgodę na wpuszczenie użytkownika do gościnnej infrastruktury – bez podawania wrażliwych danych.

Tak daleko posunięta ochrona prywatności użytkownika odbiera możliwość zapewnienia odpowiedniej rozliczalności działań prowadzonych przez tego użytkownika w sieci, w której gości. Z punktu widzenia bezpieczeństwa tej sieci, jest to niepożądane.

Dlatego powstały mechanizmy takie jak CUI (Chargeable User Identity RFC 4372).

CUI pozwala na nadanie unikatowego, ale anonimowego identyfikatora każdemu użytkownikowi. CUI nie ujawnia w żaden sposób tożsamości użytkownika, lecz jest dla niego stałe i jest przesyłane do serwera RADIUS instytucji goszczącej. Dzięki temu instytucja dopuszczające gościnnie użytkownika, nie pozna jego tożsamości, ale będzie w stanie zidentyfikować jego działania. Pozwala to np. na zakazanie dostępu do infrastruktury danemu użytkownikowi, nadal bez posiadania informacji o jego tożsamości.

3. Tożsamości użytkownika

W zależności od użytej metody EAP, mogą pojawić się pojęcia tzw. tożsamości zewnętrznej i tożsamości wewnętrznej. Dotyczy to przypadków, w których w ramach sesji uwierzytelniającej EAP zestawiany jest tunel TLS, np. EAP-TLS, EAP-TTLS, EAP-PEAP. Dla tych metod w ramach protokołu RADIUS przenoszony jest tunel TLS, w którym z kolei znajduje się kolejna komunikacja oparta o protokół RADIUS – metoda enkapsulacji protokołów sieciowych.

Tożsamość zewnętrzna to dane przedstawiane serwerowi przed nawiązaniem tunelu TLS, a tożsamość wewnętrzna – analogicznie – dane przedstawiane w ramach komunikacji RADIUS wewnątrz tunelu TLS.

Celem takiego podejścia jest ochrona danych użytkownika, gdyż nawet login może zostać uznany za dane wrażliwe. W praktyce tożsamość zewnętrzna zazwyczaj ma postać anonymous@realm, a tożsamość wewnętrzna zawiera już prawdziwy login. Dzięki temu, podglądając komunikację sieciową, nie ma możliwości nie tylko poznania hasła, ale nawet loginu użytkownika. Tożsamość zewnętrzna używana jest tylko i wyłącznie do identyfikacji serwera RADIUS zajmującego się obsłużeniem zapytania uwierzytelniającego, a do tego wystarczy tylko realm. Dodatkowo podczas korzystania z funkcji roamingu serwery pośredniczące w przekazywaniu zapytań protokołu RADIUS nie są w stanie poznać tożsamości użytkownika, który nawiązuje połączenie, ponieważ widzą tylko tożsamość zewnętrzną. Tożsamość wewnętrzna jest znana tylko serwerowi macierzystemu, z którym nawiązany jest tunel TLS.

4. Rozliczalność

Z tej funkcjonalności protokołu RADIUS bardzo chętnie korzystają ISP czy operatorzy telekomunikacyjni. To właśnie w ich usługach jesteśmy w stanie zauważyć najprościej działanie mechanizmów opartych na rozliczalności. Przykładem takich działań może być zliczanie minut połączeń, sumy transferu w Internecie, liczby pakietów itp.

Po poprawnym uwierzytelnieniu użytkownika i przyznaniu mu dostępu do sieci NAS wysyła do serwera RADIUS zgłoszenie rozpoczęcia sesji zliczającej parametry połączenia. W czasie jej trwania, co pewien okres, do serwera przesyłane są aktualizacje zawierające informację o statystykach sesji. Po jej zakończeniu NAS wysyła do serwera RADIUS informację o zakończeniu zliczania danych dotyczących sesji.

 

Bezpieczeństwo

1. Protokół RADIUS

Sam protokół RADIUS nie posiada dedykowanych mechanizmów zabezpieczania transmisji, poza jedynym polegającym na tym, że transmituje hasło zakodowanie MD5. Niestety dziś nie zapewnia to wymaganego poziomu ochrony.

Bezpieczeństwo danych dostępowych użytkownika, takich jak login i hasło, zapewniane jest przez wybranie odpowiednio bezpiecznej metody EAP, najlepiej stosującej tunel TLS. Jednak takie rozwiązanie nie zapewnia poufności pozostałych atrybutów przenoszonych przez protokół RADIUS, które można uznać za wrażliwe, np. identyfikator przydzielonego VLAN-u lub konfigurację sieciową.

Jeśli użytkownik porusza się w ramach własnej infrastruktury, nie stanowi to tak poważnego problemu, jednak w przypadku gdy wykorzystywana jest funkcjonalność „roamingu” użytkowników, takie dane są transmitowane przez obcą sieć.

Z tego powodu opracowano protokół określany jako RadSec, którego celem jest naprawienie dwóch najpoważniejszych niedociągnięć RADIUSa. RadSec tłumaczone jest jako RADIUS over TLS.

RadSec eliminuje zawodność transmisji przez użycie TCP zamiast UDP oraz zapewnia poufność wszystkich atrybutów protokołu RADIUS dzięki transmisji danych w tunelu TLS.

Niestety nadal stosunkowo niewiele pakietów oprogramowania wspiera RadSec. Jeden z najpopularniejszych serwerów RADIUS, FreeRADIUS wprowadził je dopiero w wersji 3.0, wydanej w październiku 2013 roku.

Na szczęście parę lat temu stworzony został projekt o nazwie RadSecProxy stanowiący prostą implementację funkcji proxy protokołu RADIUS przy pomocy RadSec. Pozwala na odbieranie zapytań protokołu RADIUS i przekazywanie ich dalej przy pomocy protokołu RadSec. Najczęściej instalowany jest na tym samy hoście co serwer RADIUS, gwarantując, że transmisja niezabezpieczona protokołem RADIUS nie wycieknie poza danego hosta.

2. Dostęp do serwera RADIUS

Ze względu na specyfikę funkcji pełnionej przez serwer RADIUS wskazane jest ograniczenie dostępu urządzeniom, które mogą przesyłać zapytania uwierzytelniające. W praktyce, realizuje się to przez filtrowanie transmisji w warstwie sieciowej na firewallu oraz przez użycie sekretu, którym musi się przedstawić urządzenie dostępowe lub serwer proxy chcące przesłać zapytanie do serwera. W przypadku zastosowania RadSec istnieje możliwość autoryzacji urządzeń dostępowych z wykorzystaniem infrastruktury PKI.

 

Podsumowanie

Powyższy opis prezentuje podstawy działania protokołu RADIUS i porusza zagadnienia bezpieczeństwa samego protokołu. Widać wyraźnie, że protokół, który na pierwszy rzut oka wydaje się dość prosty, pozwala na realizację wielu zaawansowanych mechanizmów EAP, włącznie z tunelowaniem i szyfrowaniem.

RADIUS, jak każde rozwiązanie, posiada pewne mankamenty, które uwidoczniły się w ciągu ponad 20 lat jego funkcjonowania. Najważniejsze z nich to:

  • brak obsługi TCP,
  • brak obsługi szyfrowania komunikacji RADIUS,
  • zbyt mała przestrzeń dostępnych AVP,
  • dodatkowe funkcjonalności związane z wykrywaniem serwerów proxy.

Z tego powodu powstał protokół Diameter (RFC 6733) (Diameter = 2xRadius :)), którego celem było rozwiązanie tych problemów. Jednak nie jest on tak bardzo rozpowszechniony jak RADIUS.

Jednym z ciekawszych przykładów wdrożenia WPA/WPA2-Enterprise jest projekt eduroam (PL), który zapewne jest znany wielu Czytelnikom.

W skrócie, projekt polega na realizacji dostępu do Internetu dla środowisk akademickich (studenci i pracownicy) w skali całego świata. Oznacza to, że posiadając dane dostępowe, można znaleźć się po drugiej stronie globu, pójść do dowolnego kampusu uniwersyteckiego i podłączyć się do Internetu przy pomocy sieci Wi-Fi nazwanej eduroam.

W tym przypadku uwierzytelnienie zostanie dokonane przez instytucję macierzystą, zapewne gdzieś w Polsce, a instytucja goszcząca ufa polskiemu serwerowi i pozwala użytkownikowi na dostęp do Internetu. Zazwyczaj serwery RADIUS są połączone z bazami danych użytkowników na uniwersytetach i każdy student/pracownik automatycznie uzyskuje dostęp do tej usługi. Ze względu na opisywane już cechy WPA/WPA2-Enterprise, korzystanie z takiej sieci, jest o wiele bezpieczniejsze niż z publicznie dostępnych AP oferowanych przez niektóre uczelnie. Dla poprawnie skonfigurowanego profilu eduroam nie ma możliwości podłączenia się do fałszywej infrastruktury podstawionej przez atakującego.

Kończąc omawianie protokołu RADIUS, chciałbym zakończyć teoretyczne wprowadzenie do tematyki WPA/WPA2-Enterprise. Następna część cyklu będzie już poświęcona implementacji konkretnego rozwiązania opartego o serwer FreeRADIUS.

 

Bibliografia

 —Adam Smutnicki

 

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. KuraDomowa

    „Bezpieczeństwo danych dostępowych użytkownika, takich jak login i hasło, zapewniane jest przez wybranie odpowiednio bezpiecznej metody EAP, najlepiej stosującej tunel TLS. Jednak takie rozwiązanie nie zapewnia poufności pozostałych atrybutów przenoszonych przez protokół RADIUS..” – to te „pozostałe atrybuty” nie są przenoszone w tunelu TLS tak jak login i hasło?

    Odpowiedz

Odpowiedz