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

Wstęp

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.

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.

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).

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.

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

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.

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.

Bibliografia

• FreeRadius – Beginner’s Guide, Dirk van der Walt, Packt Publishing Ltd, 2011
• Dokumentacja projektu Eduroam (PL)
• Extensible Authentication Protocol: RFC 3748
• Protokół RADIUS: RFC 2865
• RADIUS accounting: RFC 2866
• protokół Diameter RF6733
• RadSec IETF RFC draft
• Chargeable User Identity RFC 4372

 —Adam Smutnicki