Bezpieczny Radius
8 października 2007 14:35
Patryk Królikowski
W każdej sieci, gdzie poważnie myśli się o bezpieczeństwie dostępu bezprzewodowego wcześniej czy później musi zostać uruchomiony serwer RADIUS. Jego konfiguracja w celu uzyskania oczekiwanej funkcjonalności to jedna sprawa. Inną kwestią - bardzo często niestety traktowaną po macoszemu - jest zapewnienie temu serwerowi odpowiedniego poziomu bezpieczeństwa.
Bezpieczeństwo Radiusa-a jest o tyle istotne, że to on podejmuje decyzję o zezwoleniu na dostęp do sieci lub o odmowie. Warto więc jeszcze przed jego uruchomieniem spełnić kilka warunków, które podniosą poziom bezpieczeństwa.
Należy zacząć od platformy systemowej, na której Radius będzie uruchomiony. Najświeższe łaty i aktualizacje to podstawa. Sama usługa serwera powinna być jedyną "chodzącą" w systemie. Takie podejście pozwala zminimalizować możliwe podatności, które mogą być wykorzystane do przejęcia serwera. Po instalacji nie zaszkodzi przeskanowanie systemu z zewnątrz np. Nessusem.
A co z samym serwerem Radius? Jednym z podstawowych składników jego konfiguracji (pod względem bezpieczeństwa) jest hasło współdzielone (shared secret). Jest to nic innego, jak element tworzący klucz szyfrujący, którym posługują się: serwer Radius, urządzenie będące bramą do sieci (klient Radius-NAS) oraz łączący się z siecią komputer. Oprócz samego hasła, klucz tworzy kilka innych składników (np. dodatkowe atrybuty czy ID). Wszystko to poddawane jest działaniu funkcji skrótu MD5. Dzięki tak utworzonemu kluczowi mogą zostać zaszyfrowane przesyłane informacje. Wydawałoby się, że jest to mechanizm dość bezpieczny. Niestety, wszystkie z dodatkowych elementów, które tworzą całość klucza (oprócz hasła) mogą zostać łatwo podsłuchane. Wówczas za pomocą metody brute force/słownikowej można próbować odgadnąć hasło porównując wartości funkcji skrótu.
Najsłabszym zatem elementem jest tutaj hasło, które powinno być odpowiednio skomplikowane. Zalecane jest wykorzystywanie maksymalnej długości hasła, jaką jest w stanie obsłużyć zarówno serwer, jak i klient (NAS). W przypadku haseł współdzielonych uważa się, że powinno ono zawierać przynajmniej 22 znaki (w tym znaki specjalne, litery i cyfry). Serwer Radius pozwala też na wskazanie różnych haseł dla każdego ze swoich klientów, co powinno być skrupulatnie wykorzystane. Definiując klientów serwera Radius trzeba też zwrócić uwagę na to, czy wskazujemy ich adres IP czy FQDN. Zdarza się, że FQDN odnosi się do wielu adresów IP. W takim przypadku tylko pierwszy z nich zostanie wykorzystany. Lepiej jest zatem w takich przypadkach wskazywać konkretny adres IP.
W infrastrukturze z udziałem serwera Radius (i wykorzystującej 802.1x) niezwykle istotny jest również wybór stosowanego protokołu uwierzytelniania. Dużo zależy od samego serwera. Dla przykładu Microsoft IAS w W2k3 wspiera EAP TLS i EAP MD5. Z kolei popularny FreeRadius pozwala skorzystać z prawie wszystkich (choć jest nieco trudniejszy w konfiguracji). Protokołów jest wiele i warto cokolwiek o nich wiedzieć:
1) EAP (Extensible Authentication Protocol) - pozwala na przekazywanie danych uwierzytelniających pomiędzy serwerem Radius, NAS-em oraz klientem. W pakiecie PPP sygnalizuje jego obecność pojawienie się wartości C227 (HEX) w trzecim oktecie. Ma kilka wariantów, które różnią się od siebie poziomem bezpieczeństwa:
- EAP MD5 - opiera się na hasłach, które szyfrowane są funkcją MD5. Podatny na ataki MITM. W środowiskach korporacyjnych nie powinien być stosowany.
- EAP TLS - opiera się na certyfikatach, zapewnia dwustronne uwierzytelnianie serwera Radius i NAS-a. Wymaga posiadania infrastruktury PKI, wygenerowania i utrzymywania certyfikatów zarówno dla serwera i klienta. Starszy sprzęt (Access pointy) może go nie wspierać.
- EAP TTLS - podobnie jak EAP TLS opiera się na certyfikatach i zapewnia dwustronne uwierzytelnianie serwer Radius i NAS-a. Jest łatwiejszy w utrzymaniu ponieważ wymaga certyfikatu jedynie po stronie serwera. Współpracuje nieźle ze starszym sprzętem. Po stronie klienta stosowane jest hasło szyfrowane TLS-em. Możliwe jest też wykorzystanie wielu typów uwierzytelniania (w tym CHAP, MS-CHAPv2).
- LEAP (Lightweight EAP) - zmodyfikowana przez Cisco wersja EAP podobna do MS-CHAP. Korzysta z algorytmów MD4 i DES. Zapewnia dwustronne uwierzytelnienie oparte na hasłach. Z uwagi na wiele podatności nie powinna być stosowana w środowiskach korporacyjnych. EAP-FAST jest nowszą wersją LEAP, która zapewnia wyższy poziom bezpieczeństwa.
- PEAP (Protected EAP) - opiera się na certyfikacie podczas uwierzytelniania serwera (EAP-TLS) i haśle przy uwierzytelnianiu klienta. Miał być protokołem wspólnie wykorzystywanym przez wiodących producentów. Niestety jego twórcy (przede wszystkim Cisco i Microsoft) zaimplementowały go różnie. PEAP w wydaniu Microsoftu wykorzystuje MSCHAPv2.
- MS-CHAPv2 - zbliżona koncepcyjnie do EAP-MD5. Algorytm MD5 został tutaj zastąpiony słabszym - MD4.
2) CHAP - oparty na mechanizmach Challenge Response. W procesie uwierzytelniania użytkowników wykorzystuje algorytm MD5 do wykonania funkcji skrótu hasła i przesyła ją zamiast samego hasła.
3) PAP - uwierzytelnia użytkowników przesyłając ich hasła otwartym tekstem.
Spośród nich ani PAP ani też CHAP nie powinny być pod żadnym pozorem wykorzystywane. Najwyższy poziom bezpieczeństwa gwarantuje EAP-TLS.
Po dokonaniu tych wyborów należy przyjrzeć się komunikacji pomiędzy poszczególnymi komponentami układanki. W szczególności należy ograniczyć komunikację pomiędzy serwerem Radius, a NAS-em oraz pomiędzy serwerem Radius i bazą, z której najprawdopodobniej będzie korzystał przy pobieranie danych uwierzytelniających. W typowym scenariuszu taką bazę stanowi albo serwer SQL, albo LDAP. Połączenie pomiędzy serwerem Radius, a NAS-em najczęściej wymaga otworzenia portów 1812 oraz 1813 UDP, choć wartości te dają się konfigurować (np. w open source-owym FreeRadius).
W starszych instalacjach wykorzystywane są także porty 1645 i 1646 UDP. Warto pomyśleć o zabezpieczeniu transmisji pomiędzy poszczególny komponentami infrastruktury, a wiec serwerem Radius i NAS-em oraz serwerem Radius i repozytorium danych (AD,LDAP,SQL). Do zabezpieczenia tego pierwszego dobrze nadaje się IPsec. W przypadku drugiego sporo zależy od rodzaju repozytorium. Jeżeli jest to LDAP lub AD można skorzystać z wbudowanych mechanizmów szyfrowania SSL. W przypadku niestandardowego repozytorium można pomyśleć o kanale IPsec.
AudioBot - odsłuchaj materiał
wydrukuj
wyślij do znajomego
odpowiada...