Konfiguracja serwerów regionalnych
Transkrypt
Konfiguracja serwerów regionalnych
Konfiguracja serwerów regionalnych Maja Górecka-Wolniewicz, UCI UMK ([email protected]) dokument przygotowany w ramach projektu B-R eduroam-PIONIER wersja 1.0 Spis treści 1. Wstęp.....................................................................................................................................................1 2. Oprogramowanie radsecproxy..............................................................................................................1 2.1. Pobieranie......................................................................................................................................2 2.2. Kompilacja.....................................................................................................................................2 2.3. Start serwera – opcje ...................................................................................................................2 2.4. Konfiguracja..................................................................................................................................2 2.4.1. Podstawowe opcje...........................................................................................................................................3 2.4.2. Bloki................................................................................................................................................................3 3. Przykład konfiguracji...........................................................................................................................4 1. Wstęp W dokumencie Koncepcja wdrożenia usługi eduroam w sieci Pionier [1] wskazano, że istotnym elementem struktury eduroam w sieci PIONIER są Regionalni Operatorzy eduroam. Serwery regionalne będą funkcjonowały w pierwszej fazie projektu na poziomie drugim, poniżej krajowych, a docelowo będą elementem dynamicznej struktury eduroam. Serwery regionalne, podobnie jak serwery krajowe, działają wyłącznie w funkcji elementu pośredniczącego w przekazywaniu zlecenia (proxy). W opracowaniu [1] została omówiona potrzeba tworzenia rozwiązań opartych na protokole RadSec, gdyż właśnie takie podejście, jako znacząco bezpieczniejsze będzie dominowało w przyszłości. Protokół RadSec został zaprojektowany przez Open System Consultants Pty. Ltd., firmę pod której szyldem jest tworzone oprogramowanie Radiator, w odpowiedzi na brak możliwości korzystania z protokołu RADIUS w oparciu o TLS. Dokument [2] definiuje protokół i przedstawia sposób jego implementacji. RadSec miał być z założenia rozwiązaniem pośrednim, nadającym się do szybkiego wdrożenia, zanim powstaną implementacje protokołu Diameter ([3], uważanego za następce RADIUS-a. Okazało się, że tego typu podejście przyjęło się, na jego bazie jest obecnie definiowana wersja 2 uwzględniająca dynamiczne połączenia pomiędzy serwerami ([4]). Opracowanie [5] omawia szczegóły związane z wdrożeniem protokołu RadSec w eduroam. Ogólnodostępne oprogramowanie FreeRADIUS na razie nie implementuje protokołu RadSec, zgodnie z zapowiedzią będzie zawierało taką funkcjonalność w przyszłości. RadSec jest dostępny w komercyjnym oprogramowaniu Radiator. Implementacją tego rozwiązania zainteresował się Stig Venaas z UNINETT-u (Norwegia). Na początku 2007 roku udostępnił on publicznie pierwszą wersję pakietu radsecproxy, realizującego funkcjonalność pośredniczącego serwera RADIUS, zarówno w warstwie transportowej UDP, jak i zgodnie z protokołem RadSec. 2. Oprogramowanie radsecproxy Obecna wersja oprogramowania to 1.1-beta, lada chwila ma zostać oddana wersja radsecproxy-1.1. Obszerne informacje o pakiecie są dostępne na stronach http://software.uninett.no/radsecproxy. Gdy projekt radsecproxy startował, podstawowym założeniem było zbudowanie oprogramowania pełniącego funkcję pośredniczącego serwera, które będzie oszczędne z punktu widzenia zasobów serwera, wydajne i proste w konfiguracji. Początkowo serwer pośredniczący miał wyłącznie udostępniać połączenia za pośrednictwem protokołu RadSec (RADIUS poprzez TCP), gdyż właśnie tego typu rozwiązań brakowało, jednak szybko stwierdzono, że przydatna będzie również funkcjonal- ność typowego serwera pośredniczącego RADIUS. Dzięki temu oprogramowanie radsecproxy jest idealne w miejscach, gdzie jedynym zadaniem serwera jest przekazywanie pakietów do właściwego serwera. Taką rolę spełniają serwery krajowe i regionalne w polskiej usłudze eduroam. Pakiet radsecproxy wspiera zarówno IPv4, jak i IPv6. 2.1. Pobieranie Oprogramowanie można pobrać ze strony: http://software.uninett.no/radsecproxy/index.php?page=download Jest dostępna zarówno wersja źródłowa, jak i binaria dla konkretnych systemów. Ponieważ oprogramowanie ciągle rozwija się, warto korzystać z repozytorium SVN, np. poprzez polecenie: svn co https://svn.testnett.uninett.no/radsecproxy 2.2. Kompilacja Jeśli decydujemy się na samodzielną konfigurację, po rozpakowaniu źródeł należy przejść do katalogu źródłowego i wykonać polecenie make Efektem kompilacji będzie program radsecproxy, który należy skopiować do ulubionego katalogu systemowego zawierającego często uruchamiane programy (/usr/bin, /usr/local/bin, /opt/local/bin). 2.3. Start serwera – opcje radsecproxy startując domyślnie czyta konfigurację z pliku /etc/radsecproxy.conf. Jeśli chcemy utrzymywać konfigurację w innym miejscu, np. w katalogu /opt/radsecproxy.conf.d/ w pliku main.conf, to startując serwer musimy dodać opcję -c <plik>: radsecproxy -c /opt/radsecproxy.conf.d/main.cf Serwer domyślnie startuje w tle. Jeśli zależy nam na tym, by pracował w pierwszym planie, to należy dodać opcję -f (run in foreground). Gdy chcemy wyłącznie przetestować konfigurację, to pozwoli na to opcja -p (pretend). W fazie uruchamiania oprogramowania warto ustawić najwyższy poziom debugowania, co robimy albo poprzez wpis LogLevel 4 w pliku konfiguracyjnym, albo dodając opcję -d 4 w wywołaniu. 2.4. Konfiguracja Podczas przetwarzania pliku konfiguracji, domyślnie /etc/radsecproxy.conf, ignorowane są wszelkie „puste” znaki, typu dodatkowe odstępy i znaki tabulacji. W każdym wierszu ignorowane są znaki odstępu i tabulacji na początku i końcu wiersza. Jeśli pierwszym znakiem wiersza jest #, to wiersz jest traktowany jako komentarz. W konfiguracji na ogół nie ma znaczenia wysokość liter. Dozwolone są dwa typy struktur konfiguracyjnych: ● pierwsza (prostsza) ma postać: opcja wartość, gdzie w polu opcja jest umieszczana dopuszczalna nazwa opcji, np. LogLevel, a w polu wartość, wartość nadana danej opcji, np. 4; ● druga (bardziej rozbudowana) to blok, czyli struktura mająca minimum dwa wiersze o postaci: typ_bloku nazwa { opcja wartość opcja wartość } 2 Jedna z opcji, mająca specjalny charakter, pomaga zwiększyć czytelność konfiguracji: Include <plik> W ten sposób można w określonym miejscu wstawiać zawartość wskazanego pliku, zawierającego fragmenty konfiguracji. Szczegółowy opis opcji oraz wszystkich dozwolonych bloków: Client, Server, Realm, TLS, Rewrite można znaleźć na stronie: http://software.uninett.no/radsecproxy/index.php?page=documentation 2.4.1. Podstawowe opcje Najistotniejsze podstawowe opcje to: ● ListenUDP oraz ListenTCP – służą do zadeklarowania interfejsu sieciowego oraz portu, na ● SourceUDP oraz SourceTCP – służą do ustalenia, jaki adres oraz jaki port pojawi się w pa- ● LoopPrevention – włączenie tej opcji (on) powoduje, że są pomijane pakiety, które przychodzą od klienta zdefiniowanego w bloku o nazwie AAA i według reguł obsługi domen, opisanych poprzez zestaw bloków Realm mają zostać przekierowane do serwera określonego w bloku o takiej samej nazwie AAA; w ten sposób w oprogramowaniu radsecproxy zaimple- których nasłuchuje serwer, szczególnie ważne, gdy nasz komputer ma kilka interfejsów sieciowych; kietach wysyłanych przez serwer; należy pamiętać, że ustalenie, że serwer nasłuchuje na danym adresie, nie oznacza, że ten adres pojawi się w pakietach wyjściowych – jeśli nasz serwer działa na adresie 11.22.33.44 i taki adres ma pojawiać się w pakietach wyjściowych, to należy użyć w konfiguracji zarówno opcji ListenUDP / ListenTCP, jak i SourceUDP / SourceTCP; mentowano zapobieganie pętlom. 2.4.2. Bloki Dozwolone bloki to: Client, Server, Realm, TLS, Rewrite. Bloki Client i Server ustalają dane dotyczące odpowiednio klienta i serwera. Należy zwrócić uwagę na napis nazwa_bloku w strukturze Client nazwa_bloku {...} Server nazwa_bloku {...} nazwa_bloku to nazwa unikatowa dla dajnego bloku, jest to albo IP klienta/serwera, albo pełna na- zwa domenowa, albo unikatowa nazwa identyfikująca konkretny blok. Jeśli w bloku nie definiujemy opcji host, to nazwa bloku musi być albo adresem IP, albo nazwą domenową klienta/serwera. Funkcjonowanie radsecproxy jako serwera pośredniczącego oznacza, że w większości przypadków klient jest jednocześnie serwerem. Zastosowanie tych samych nazw bloków Client i Server, przy włączonej opcji LoopPrevention pozwoli automatycznie eliminować ewentualne pętle. Inną ważną opcją w bloku Client / Server jest type – opcja służąca do ustalenia, w jakim trybie ma pracować klient / serwer. Możliwe wartości – udp i tls, ustalają sposób komunikacji klienta / serwera: ● udp – za pomocą protokołu RADIUS; ● tls – za pomocą protokołu RadSec. W przypadku komunikacji RadSec istotna jest definicja zasad realizacji szyfrowanej komunikacji. Reguły definiujemy w bloku tls. Możliwa jest definicja dowolnej liczby bloków tls. Na ogół jeden z bloków tls ma nazwę default, lub defaultclient, lub defaultserver. Taki blok obowiązuje dla klienta / serwera, jeśli nie została w danym bloku Client / Server użyta opcja tls nazwa. Je3 śli w konfiguracji radsecproxy definiujemy co najmniej jeden blok klienta / serwera, zawierający opcję type tls, to musi w niej zostać umieszczony co najmniej jeden blok tls. Blok tls wskazuje, z jakiego: ● pliku certyfikatu serwera, ● pliku klucza prywatnego serwera, ● pliku certyfikatu urzędu certyfikacyjnego lub katalogu zawierającego certyfikaty korzysta połączenie. Domyślnie, jeśli klient/serwer używa TLS-a, to dokonywane jest sprawdzenie, czy certyfikat klienta / serwera ma w polu CN lub SubjectAltName taką samą nazwę, jak wskazana dla klienta/serwera nazwa domenowa lub adres IP. Sprawdzenie to można wyłączyć umieszczając w bloku Client / Server opcję certificateNameCheck off. Kolejnym ważnym blokiem jest Realm. Jego nazwa to albo domena, albo wyrażenie regularne dopasowujące domenę, albo znak * oznaczający „wszystko”. Jeśli domena pobrana z atrybutu User-Name zlecenia zostanie dopasowana do nazwy bloku Realm, to pakiet podlega obsłudze zgodnie z opcjami wskazanymi w danym bloku. Blok Realm typowo zawiera opcję server nazwa, wskazującą serwer obsługujący tę domenę (można podać więcej niż jeden serwer, definiując w ten sposób serwery zastępcze). Reasumując, konfiguracja serwera radsecproxy zawiera: ● opcje podstawowe; ● bloki Client, opisujące klientów serwera proxy; ● bloki Server, opisujące serwery, do których radsecproxy może przekierować zlecenia; ● bloki Realm, definiujące przypisanie domena – serwer; ● bloki tls, definiujące sposób bezpiecznej komunikacji poprzez specyfikacje certyfikatu klienta/serwera, klucza prywatnego, certyfikatu urzędu certyfikacji. 2.4.3. Certyfikaty do komunikacji TLS Jeśli korzystamy z protokołu RadSec niezbędne jest dysponowanie odpowiednimi certyfikatami, które należy wskazać w konfiguracji. Zgodnie z opisem [1], serwery regionalne będą docelowo wpięte w dynamiczną strukturę europejską. Mimo że pierwsza faza realizacji projektu bazuje na hierarchicznej strukturze serwerów, certyfikaty używane przez serwery regionalne mają mieć od początku docelową postać, uzgodnioną w ramach europejskiej usługi. Każdy administrator serwer regionalnego otrzyma od Koordynatora, za pomocą bezpiecznej formy komunikacji, pliki certyfikatów, które należy wskazać w konfiguracji w bloku tls. Wszystkie bezpieczne połączenia będą korzystały z tego certyfikatu serwera. Natomiast do weryfikacji będzie używany wskazany certyfikat urzędu CA. W przypadku usługi eduroam certyfikaty serwera są podpisane przez urząd eduGAINSCA, podlegający pod eduGAINCA (http://sca.edugain.org/cacert/). W tej sytuacji w bloku tls można albo w opcji CACertificateFile wskazać plik zawierający oba certyfikaty, albo w opcji CACertificateFile wskazać certyfikat eduGAINCA, a w katalogu podanym w opcji CACertificatePath umieścić certyfikat eduGAINSCA. Na etapie testów, można wystawić własne certyfikaty serwera, przy czym należy pamiętać, że certyfikat serwera musi zawierać rozszerzenia: TLS Web Server Authentication, TLS Web Client Authentication, gdyż serwer proxy występuje raz jako klient, raz jako serwer. Poza tym, testy powiązań RadSec w tym przypadku muszą albo odbywać się pomiędzy serwerami korzystającymi z tego samego urzędu certyfikacyjnego, albo trzeba wskazać plik certyfikatu urzędu obowiązujący w danym połączeniu. 4 3. 3.1. Przykład konfiguracji Plik /etc/radsecproxy.conf może mieć następującą postać: ListenUDP 11.22.33.44:1812 listenTCP 11.22.33.44:2083 SourceUDP 11.22.33.44 SourceTCP 11.22.44.44 LogLevel 3 LogDestination file:///opt/radsecproxy/rp.log LoopPrevention on # definiujemy pliki certyfikatu serwera, klucza prywatnego oraz CA tls default { CACertificateFile /etc/radsecproxy.conf.d/eduGAIN-chain.pem CertificateFile /etc/radsecproxy.conf.d/radius.pem CertificateKeyFile /etc/radsecproxy.conf.d/radius.key # jeśli klucz prywatny nie jest zaszyfrowany, # kasujemy opcję CertificateKeyPassword CertificateKeyPassword "aaaa" } # klienci w pliku clients.conf include /etc/radsecproxy.conf.d/clients.conf # serwery w pliku servers.conf include /etc/radsecproxy.conf.d/servers.conf # domeny w pliku realms.conf include /etc/radsecproxy.conf.d/realms.conf 3.2. Plik /etc/radsecproxy.conf.d/clients.conf zawiera definicje bloków Client, np.: Client UNI1 { type udp host 22.33.44.55 secret klucz_tajny_uni1 } Client UNI2 { type udp host nazwa.domenowa.pl secret klucz_tajny_uni2 } # pozostali klienci korzystają z RadSeca Client UNI3 { type tls host nazwa.domenowa.pl } Client radius1.eduroam.pl { type tls } 5 Client radius2.eduroam.pl { type tls } 3.3. Plik /etc/radsecproxy.conf.d/servers.conf zawiera definicje bloków Server, np.: Server UNI1 { type udp host 22.33.44.55 secret klucz_tajny_uni1 } Server UNI2 { type udp host nazwa.domenowa.pl secret klucz_tajny_uni2 } # pozostali klienci korzystają z RadSeca Server POL1 { type tls host nazwa.domenowa.pl } Server radius1.eduroam.pl { type tls } Server radius2.eduroam.pl { type tls } Plik /etc/radsecproxy.conf.d/realms.conf zawiera definicje bloków Server, np.: # domena uni.lodz.pl i jej poddomeny – obsługuje serwer UNI1, RADIUS Realm /uni\.lodz\.pl$/ { server UNI1 } # domena umed.lodz.pl i jej poddomeny – obsługuje serwer UNI2, RADIUS Realm /umed\.lodz\.pl$/ { server UNI2 } # domena p.lodz.pl i jej poddomeny – obsługuje serwer UNI2, RadSec Realm /p\.lodz\.pl$/ { server POL1 } # reszta do serwerów krajowych - RadSec Realm * { server radius1.eduroam.pl server radius2.eduroam.pl } 6 Materiały towarzyszące [1] Koncepcja wdrożenia usługi eduroam w sieci Pionier, dokument przygotowany w ramach projektu B-R eduroam-PIONIER [2] RadSec, a secure, reliable RADIUS Protocol, Open System Consultants Pty. Ltd., http://www.open.com.au/radiator/radsec-whitepaper.pdf [3] Diameter Base Protocol, RFC 3588 [4] RadSec Version 2 – A Secure and Reliable Transport for the RADIUS Protocol, draft-winterradsec-1, http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt [5] Wykorzystanie technologii RadSec w usłudze eduroam, M. Górecka-Wolniewicz, http://eduroam.pl/Dokumentacja/radsec.pdf 7