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 2.0
Spis treści
1. Wstęp.................................................................................................................................1
2. Oprogramowanie radsecproxy...........................................................................................2
2.1. Pobieranie...................................................................................................................2
2.2. Kompilacja ..................................................................................................................2
2.3. Start serwera – opcje .................................................................................................2
2.4. Konfiguracja................................................................................................................3
2.4.1. Podstawowe opcje...................................................................................................................3
2.4.2. Bloki.........................................................................................................................................3
2.4.3. Certyfikaty do komunikacji TLS................................................................................................5
3. Obsługa pakietów rozliczeniowych.....................................................................................5
4. Przykład konfiguracji..........................................................................................................5
4.1. Plik /etc/radsecproxy.conf może mieć następującą postać:........................................5
4.2. Plik /etc/radsecproxy.conf.d/clients.conf.....................................................................6
4.3. Plik /etc/radsecproxy.conf.d/servers.conf ...................................................................7
4.4. Plik /etc/radsecproxy.conf.d/realms.conf.....................................................................7
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, ale zgodnie z zapowiedzią będzie zawierało taką funkcjonalność w przyszłości, trwają już prace nad tym. RadSec jest dostępny w komercyjnym oprogramowaniu Radiator. Implementacją tego rozwiązania zainteresował się Stig Venaas (wówczas UNINETT, 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.3. 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ż funkcjonalność 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
Obecnie stabilną wersją jest 1.3. Dla tej wersji w kwietniu 2009 została zgłoszona poprawka modyfikująca sposób logowania informacji dotyczącej odpowiedzi Access-Accept / AccessReject. Wszystkie serwery regionalne powinny działać na oprogramowaniu zawierającym tę poprawkę. Do chwili pojawienia się kolejnej wersji, należy więc pobierać oprogramowanie radsecproxy z repozytorium podwersji (SVN):
svn co https://svn.testnett.uninett.no/radsecproxy/branches/release-1.3
2.2.
Kompilacja
Jeśli decydujemy się na samodzielną kompilację, 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
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ść
}
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, który definiuje dany fragment 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 / ListenTLS – służą do zadeklarowania interfejsu sieciowego oraz portu, na których nasłuchuje serwer, szczególnie ważne, gdy nasz komputer ma kilka interfejsów sieciowych; klienci UDP i TCP domyślnie korzystają z portu 1812, klienci TLS/DTLS jako domyślny port przyjmują 2083;
●
SourceUDP / SourceTLS – służą do ustalenia, jaki adres oraz jaki port pojawi się w pakietach 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 / ListenTLS, jak i SourceUDP / SourceTLS;
●
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
zaimplementowano zapobieganie pętlom.
2.4.1.
Bloki
Dozwolone bloki to: Client, Server, Realm, TLS, Rewrite. 3
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 danego bloku, jest to albo IP klienta/serwera, albo pełna nazwa 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. Za pomocą bloków Server są również definiowane serwery, do których mają być przekazywane pakiety rozliczeniowe.
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 / tcp / tls / dtls, ustalają sposób komunikacji klienta / serwera:
●
udp – za pomocą protokołu RADIUS UDP;
●
tcp – za pomocą protokołu RADIUS TCP;
●
tls – za pomocą protokołu RadSec (TLS+TCP);
●
dtls – za pomocą protokołu RadSec (TLS+UDP);
●
udp – za pomocą protokołu RADIUS UDP;
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. Jeś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:
●
plik certyfikatu serwera,
●
plik klucza prywatnego serwera i hasło dla klucza prywatnego, jeśli jest on zaszyfrowany,
●
plik certyfikatu urzędu certyfikacyjnego.
Domyślnie, jeśli klient/serwer używa TLS­a, to realizowane 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 UserName 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;
4
●
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.
W pierwszym etapie serwery regionalne eduroam korzystają wyłącznie z komunikacji UDP.
2.4.1.
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 certyfikatów 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 zarówno w roli klienta, jak i w roli serwera. 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.
Komunikacja RadSec zostanie włączona w ramach hierarchicznego modelu serwerów eduroam w drugim etapie wdrażania usługi.
3.
Obsługa pakietów rozliczeniowych
Przekazywania pakietów rozliczeniowych (accounting) jest w eduroam kwestią sporną. Europejska Polityka eduroam, ani Polska Polityka eduroam, nie rozstrzygają czy pakiety rozliczeniowe muszą być przekazywane przez serwery proxy. Zasada dbałości o prywatność użytkownika podpowiada, że dane rozliczeniowe nie powinny być przekazywane na zewnątrz instytucji udostępniającej sieć, jednak taka decyzja musi być podjęta w danej instytucji. Serwery proxy powinny w jak najmniejszym stopniu ingerować w treść przesyłanych pakietów, w szczególności nie powinny odrzucać żadnych poprawnych pakietów.
Transport pakietów rozliczeniowych jest wyróżniony tylko w przypadku stosowania standardowego protokołu RADIUS, ponieważ na ten cel przydziela się wydzielony port. W ramach RadSec pakiety wszystkich rodzajów przekazywane są jednym kanałem transportowym.
Jeśli w bloku Realm nie występuje opcja accountingServer, to pakiety rozliczeniowe (UDP) są domyślnie ignorowane. Można w bloku Realm umieścić opcję accountingResponse on Wówczas radsecproxy umieści w swoim logu informacje rozliczeniowe i odeśle nadawcy pakiet Accounting-Responce. W ten sposób przekazujemy klientowi informację, że komunikaty rozliczeniowe nie mają być przekazywane.
Ponieważ przyjmujemy, że ewentualne pakiety rozliczeniowe powinny być przekazywane do serwera realizującego accouning, to opcja accountingResponse on nie może być stosowana i niezbędne jest stosowanie dyrektywy accountingServer.
5
4.
Przykład konfiguracji
Poniższa konfiguracja jest nakierowana na uruchomienie serwerów regionalnych w pierwszym etapie usługi eduroam w Polsce. Konfiguracja związana z kolejnymi etapami zostanie przedstawiona w kolejnych dokumentach (patrz [6]).
4.1.
Plik /etc/radsecproxy.conf może mieć następującą postać:
ListenUDP
11.22.33.44:1812
ListenUDP
11.22.33.44:1813
listenTLS
11.22.33.44:2083
SourceUDP
11.22.33.44
SourceTLS
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
W pierwszym etapie wdrażania serwerów regionalnych uruchamiana jest komunikacja UDP, zatem blok tls oraz dyrektywy ListenTCP, ListenTLS, ListenDTLS,należy zakomentować.
4.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
6
}
Client radius1.eduroam.pl {
type tls
}
Client radius2.eduroam.pl {
type tls
}
W pierwszym etapie wdrażania serwerów regionalnych ograniczamy się do definiowania klientów UDP.
4.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
}
Server UNIACCT {
type udp
host acct-nazwa
port 1813
secret klucz_tajny_acct
}
# 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
}
W pierwszym etapie wdrażania serwerów regionalnych ograniczamy się do definiowania serwerów UDP.
4.4.
Plik /etc/radsecproxy.conf.d/realms.conf
Zawiera definicję obsługiwanych domen.
# domena uni.lodz.pl i jej poddomeny – obsługuje serwer UNI1, RADIUS
7
Realm /uni\.lodz\.pl$/ {
server UNI1
accountingserver UNIACCT
}
# domena umed.lodz.pl i jej poddomeny – obsługuje serwer UNI2, RADIUS
Realm /umed\.lodz\.pl$/ {
server UNI2
accountingserver UNIA
}
# domena p.lodz.pl i jej poddomeny – obsługuje serwer UNI2, RadSec
Realm /p\.lodz\.pl$/ {
server POL1
accountingResponse on
}
# odrzucamy pakiety z pustą poddomeną
realm /^.*@$/ {
replymessage "Misconfigured client: empty realm!"
}
# odrzucamy pakiety z nieobsługiwanych poddomen lodz.pl
realm /lodz\.pl/ {
replymessage "Nie obslugujemy tej poddomeny"
}
# reszta do serwerów krajowych - RadSec
Realm * {
server radius1.eduroam.pl
server radius2.eduroam.pl
}
Jeśli w ramach bloku realm nie podamy serwera (server), natomiast wskażemy replymessage, to radsecproxy wyśle odpowiedź Access-Reject.
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, draftwinter-radsec-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
[6] Konfiguracja serwerów regionalnych – etap 2, wdrożenie protokołu RadSec, M.
Górecka-Wolniewicz, dokument przygotowany w ramach projektu B-R eduroamPIONIER
8