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