POLITECHNIKA WARSZAWSKA

WYDZIAŁ ELEKTRYCZNY
INSTYTUT STEROWANIA I ELEKTRONIKI PRZEMYSŁOWEJ

PRACA DYPLOMOWA MAGISTERSKA

na kierunku Informatyka

Maciej Cichocki

Nr ind. 181912
Rok. akad. 2005/2006

INSTALACJA I KONFIGURACJA SERWERA AUTENTYKACJI DOSTEPU DO

SIECI LOKALNEJ NA WYBRANYM PRZYKŁADZIE

Zakres pracy:
1. Wstęp
2. Przegląd literatury
3. Zaprojektowanie i implementacja systemu w oparciu o wybrane technologie (NIS+,
Free RADIUS, GNU RADIUS, 3Com)
4. Opis wykonanych czynności
5. Wnioski

Kierownik Zakładu Sterowania

Opiekun naukowy:

dr inż. Waldemar Graniszewski

Konsultant:

mgr inż. Grzegorz Świątek

Termin wykonania: wrzesień 2006

Praca wykonana i zaliczona pozostaje
własnością Instytutu i nie będzie
zwrócona wykonawcy
SPIS TREŚCI

Rozdział 1................................................................................................................................... 5
Wprowadzenie............................................................................................................................ 5
1.1 Krótka historia Ethernetu ........................................................................................... 5
1.2 Specyfikacja zadania. ................................................................................................. 8
1.3 Urządzenia warstwy drugiej....................................................................................... 8
1.4 Model bezpieczeństwa AAA...................................................................................... 9
Rozdział 2................................................................................................................................. 11
Protokół RADIUS – ................................................................................................................. 11
Remote Authentication Diall In User Service.......................................................................... 11
2.1 Charakterystyka protokołu RADIUS ....................................................................... 11
2.2 Uwierzytelnianie przy użyciu protokołu RADIUS .................................................. 12
2.3 Procesy wykonywane przez RADIUS serwer.......................................................... 14
2.4 Pakiet Challenge/Response. ..................................................................................... 15
2.5 Współpraca z PAP oraz CHAP. ............................................................................... 15
2.6 Proxy. ....................................................................................................................... 16
2.7 Protokół UDP. .......................................................................................................... 17
2.8 Zasady retransmisji. ................................................................................................. 18
2.9 Sprawdzanie aktywności serwera............................................................................. 18
Rozdział 3................................................................................................................................. 20
Pakiety RADIUS serwera......................................................................................................... 20
3.1 Format pakietu.......................................................................................................... 20
3.2 Typy pakietów.......................................................................................................... 21
3.3 Access-Request. ....................................................................................................... 21
3.4 Access-Accept.......................................................................................................... 22
3.5 Access-Reject. .......................................................................................................... 23
3.6 Access-Challenge. .................................................................................................... 23
Rozdział 4................................................................................................................................. 25
Atrybuty występujące w pakietach Access Request RADIUS serwera................................... 25
4.1 User-Name. .............................................................................................................. 26
4.2. User-Password.......................................................................................................... 27
4.3. CHAP-Password....................................................................................................... 27
4.4. NAS-IP-Address....................................................................................................... 27
4.5. NAS-Port.................................................................................................................. 28
4.6. Service-Type ............................................................................................................ 28
4.7. Framed-Protocol....................................................................................................... 29
4.8. Framed-IP-Address .................................................................................................. 29
4.9. Framed-IP-Netmask ................................................................................................. 29
4.10. Framed-Routing ................................................................................................... 29
4.11. Filter-Id................................................................................................................. 30
4.12. Framed-MTU ....................................................................................................... 30
4.13. Framed-Compression ........................................................................................... 30
4.14. Login-IP-Host....................................................................................................... 30
4.15. Login-Service ....................................................................................................... 31
4.16. Login-TCP-Port.................................................................................................... 31
4.17. Nieprzypisany....................................................................................................... 31
4.18. Reply-Message ..................................................................................................... 31
4.19. Callback-Number ................................................................................................. 31

2
 4.20. Callback-Id ........................................................................................................... 32
4.21. Nieprzypisany....................................................................................................... 32
4.22. Framed-Route....................................................................................................... 32
4.23. Framed-IPX-Network........................................................................................... 32
4.24. State...................................................................................................................... 32
4.25. Class ..................................................................................................................... 32
4.26. Vendor-Specific ................................................................................................... 32
4.27. Session-Timeout................................................................................................... 33
4.28. Idle-Timeout......................................................................................................... 33
4.29. Termination-Action.............................................................................................. 33
4.30. Called-Station-Id .................................................................................................. 33
4.31. Calling-Station-Id................................................................................................. 33
4.32. NAS-Identifier...................................................................................................... 33
4.33. Proxy-State ........................................................................................................... 34
4.34. Login-LAT-Service.............................................................................................. 34
4.35. Login-LAT-Node ................................................................................................. 34
4.36. Login-LAT-Group................................................................................................ 34
4.37. Framed-AppleTalk-Link ...................................................................................... 34
4.38. Framed-AppleTalk-Network................................................................................ 35
4.39. Framed-AppleTalk-Zone...................................................................................... 35
4.40. CHAP-Challenge.................................................................................................. 35
4.41. NAS-Port-Type .................................................................................................... 35
4.42. Port-Limit ............................................................................................................. 36
4.43. Login-LAT-Port ................................................................................................... 36
4.44. Tabela Atrybutów................................................................................................. 36
Rozdział 5................................................................................................................................. 38
Protokół RADIUS Accounting................................................................................................. 38
5.1 Procesy wykonywane przez RADIUS Accounting serwer. ..................................... 38
Rozdział 6................................................................................................................................. 39
Pakiety Accounting RADIUS serwera..................................................................................... 39
6.1 Rodzaje pakietów Accounting. ................................................................................ 39
6.2 Pakiet Accounting Request. ..................................................................................... 40
6.3 Pakiet Accounting Response.................................................................................... 41
Rozdział 7................................................................................................................................. 42
Atrybuty występujące w pakietach Access Request RADIUS serwera................................... 42
7.2 Acct-Input-Octets ..................................................................................................... 43
7.3 Acct-Output-Octets .................................................................................................. 43
7.4 Acct-Session-Id ........................................................................................................ 43
7.5 Acct-Authentic ......................................................................................................... 43
7.6 Acct-Session-Time ................................................................................................... 43
7.8 Acct-Input-Packets ................................................................................................... 43
7.9 Acct-Output-Packets ................................................................................................ 44
7.10 Acct-Terminate-Cause ............................................................................................. 44
7.11 Acct-Multi-Session-Id.............................................................................................. 45
7.12 Acct-Link-Count ...................................................................................................... 45
7.13 Tabela atrybutów...................................................................................................... 46
Rozdział 8................................................................................................................................. 48
Architektura serwera RADIUS. ............................................................................................... 48
8.1 Serwer RADIUS, struktura katalogów..................................................................... 48
8.1.1 radclient................................................................................................................... 49

3
 8.1.2 radeapclient ............................................................................................................. 50
8.1.3 radlast ...................................................................................................................... 51
8.1.4 radrelay.................................................................................................................... 51
8.1.5 radsqlrelay. .............................................................................................................. 52
8.1.6 radclient radtest. ...................................................................................................... 52
8.1.7 radclient radwho...................................................................................................... 53
8.1.8 radzap ...................................................................................................................... 54
8.1.9 radiusd ..................................................................................................................... 54
Rozdział 9................................................................................................................................. 60
Instalacja i konfiguracja serwera RADIUS. ............................................................................. 60
9.1 Serwer RADIUS - instalacja. ................................................................................... 60
9.2 Serwer RADIUS - konfiguracja. .............................................................................. 62
9.2.1 clients.conf .............................................................................................................. 62
9.2.2 eap.conf ................................................................................................................... 62
9.2.1 radiusd.conf ............................................................................................................. 63
9.2.3 users......................................................................................................................... 80
Rozdział 10............................................................................................................................... 85
Protokół autentykacji EAP. ...................................................................................................... 85
Rozdział 11............................................................................................................................... 86
Oprogramowanie użytkownika. ............................................................................................... 86
11.1 Certyfikaty................................................................................................................ 86
11.2 Dostosowanie maszyny użytkownika. ..................................................................... 90
Rozdział 12............................................................................................................................... 92
Bibliografia............................................................................................................................... 92

4
Rozdział 1

Wprowadzenie

1.1 Krótka historia Ethernetu

Sieci komputerowe liczą sobie już ponad 30 lat. Początki sieci to system radiowy
ALOHA, który powstał w 1968 na Uniwersytecie Hawajskim. ALOHA jest systemem
radiowym wynalezionym przez Normana Abramsona. System ten został opracowany w celu
połączenia komputera mainframe IBM 360 zlokalizowanego w głównym kampusie wyspy
Oahu z czytnikami kart i terminalami znajdującymi się na różnych wyspach i statkach.
System ten początkowo działał z prędkością 4800b/s, która w późniejszym czasie została
zwiększona do 9600b/s. Była to pierwsza sieć komputerowa. Nie działała szybko, natomiast
skuteczność jej przepustowości wynosiła 17% teoretycznej przepustowości. W 1972 roku
usprawniono sieć ALOHA zwiększając jej efektywność dwukrotnie. Praca Normana
Abramsona była kamieniem milowym i podstawą większości używanych obecnie systemów z
rozgłaszaniem pakietów (Ethernet, systemy komunikacji satelitarnej).
W roku 1972 Robert Matcalf zoptymalizował działanie system ALOHA, zwiększając
tym samym jego efektywność do prawie 100%. Pod koniec roku 1972 wraz z David’em
Boggs’em opracowali sieć łączącą różne komputery ALTO (były to pierwsze komputery z
interfejsem graficznym) z drukarką EARS (pierwsza drukarka laserowa). Sieć stworzona
przez tych panów nazwana została ALTO ALOHA (ze względu na oparcie się na systemie
ALOHA). I tak 22 maja 1972 roku zaczęła działać pierwsza sieć lokalna dla komputerów
osobistych. Tego dnia także powstała nazwa sieci Ethernet. Prędkość tej sieci wynosiła
2,94Mb/s (jest to wartość teoretyczna). Sieć ta oparta była na grubym kablu koncentrycznym.
Pod koniec roku 1976 łączyła ona ponad 100 węzłów 1000 metrowym kablem. W 1977
technologia ta przyjęła nazwę Carier-Sense Multiple Access with Collision Detection
(CSMA/CD).
Lata 1979-1983 to czas standaryzacji Ethernet. W latach 70 oprócz technologii
Ethernet pojawiło się także wiele inny technologii takich ja MCA, ARCnet. Wizja
przekształcenia technologii Ethernet w standard przemysłowy zapewniła jej zwycięstwo nad
pozostałymi. W 1979 trzy firmy: DEC, Intel i Xerox opublikowały Ethernet Blue Book
Ethernet V1.0, zwaną inaczej specyfikacją DIX. Początkowo Ethernet działał z szybkością
2,94Mb/s. Następnie DIX określił jej prędkość na 20Mb/s, która została później zmniejszona
do 10Mb/s. Przez kolejne 2 lata DIX opracował standard Ethernet V2.0.
W czerwcu 1981 organizacja IEEE powołała komisję 802.3, aby opracować
międzynarodowy standard w oparciu o pracę DIX. W 1983 komisja skończyła prace nad
standardem IEEE 10BASE5. Standard ten pozwalał na budowę sieci o prędkości 10Mb/s przy
użyciu pasma podstawowego i na odległość pomiędzy węzłami do 500 metrów.
W latach 1980-82 powstają pierwsze produkty Ethernetowe. Powstaje firma
Computer, Communication and Compatibility Corporation (3Com Corporation). Firma
wprowadza na rynek pierwszą kartę EtherLink ISA. Był to techniczny przełom. Karta ta
wykorzystywała zaawansowaną technologię półprzewodnikową, była to pierwsza karta dla
szyny ISA komputera klasy PC. Technologia VLSI spowodowała znaczne zmniejszenie
kosztów karty. Przed wprowadzeniem tej karty wszystkie urządzenia Ethernet działały z
zewnętrznym transceiverem. Użycie technologii VLSI pozwoliło na integrację transceivera z

5
kartą EtherLink. Powstał nowy standard sieci opartych o cienki kabl koncentryczny –
10BASE2.
Technologia Ethernet ciągle się rozwijała. W 1983 rozpoczęto prace nad
prowadzeniem Ethernetu po nieekranowanej skrętce telefonicznej (UTP). Powstała koncepcja
topologii gwiazdy (jeden centralny punkt, z którym łączą się komputery), tzw. StarLAN. W
1986 zostaje ogłoszony nowy standard Ethernetu opartego na UTP: 1BASE5. Standard ten
pozwalał na przesyłanie danych po nieekranowanej skrętce z prędkością 1Mb/s na
odległościach pomiędzy węzłami nie większymi niż 500 m
Od roku 1986 wiele producentów sprzętu komputerowego zaczęło sprzedawać
koncentratory i karty sieciowe StarLAN.
Pod koniec lat osiemdziesiątych StarLAN posiadała kilka milionów połączeń. Jednak
ze względu na jej niską wydajność technologia ta nie uzyskała odpowiedniego poparcia
przemysłu i rynku. W 1987 SynOptics zaprezentował technologię LATTISNET. Umożliwiała
ona przesyłanie danych z szybkością 10Mb/s po zwykłym kablu telefonicznym. W niedługim
czasie po tym wydarzeniu organizacja IEEE ogłosiła LANTTISNET standardem 10BASE-T.
Był to Ethernet przesyłany po skrętce telefonicznej.
Od połowy lat 80 na rynku pojawiało się coraz więcej komputerów klasy PC. Pojawił
się nowy komputer Apple Macintosh z innowacyjnym graficznym interfejsem użytkownika,
rozwijał się także rynek drukarek laserowych. Użytkownicy komputerów chcieli drukować,
używać nowych technologii i podłączać się do sieci. Dzięki powstaniu systemu sieciowego
Novell NetWare (1985) oraz pojawieniu się standardu 10BASE-T technologia Ethernet mogła
nadal prężnie się rozwijać.
W międzyczasie firma IBM prowadziła badania nad technologią TokenRing. W 1985
rozpoczęła sprzedaż produktów dla sieci TokenRing o prędkości 4Mb/s, trzy lata po
pokazaniu się pierwszej karty EtherLink ISA. Mimo, że TonekRing był o ponad połowę
wolniejszy od sieci 10BASE-T, posiadał pewną zaletę. Oparty był o okablowanie
strukturalne, co oznaczało sieć opartą na centralnie położonym koncentratorze oraz
podłączonymi do niego węzłami.
Po tych wydarzeniach stało się jasnym, że przyszłość sieci komputerowych leży w
okablowaniu strukturalnym oraz kablu typy skrętka telefoniczna.
Szybkie sieci 10BASE-T oparte na skrętce telefonicznej zapoczątkowała firma
SynOptics, której pierwszy produkt: LATTISNET pojawił się na rynku 17 sierpnia 1987 roku.
Tego samego dnia zespół inżynierów IEEE 802.3 spotkał się by przedyskutować najlepszy
sposób implementacji Ethernetu o szybkości 10Mb/s po kablu UTP. Prace badawcze nad
nową technologią trwały ponad trzy lata, prowadzone były przez różne firmy. Ostatecznie
nowy standard został oparty o wieloportowy repeater oraz ulepszoną technologię SynOptics
LATTISNET. Standard 802.3i/10BASE-T został oficjalnie przyjęty jesienią 1990 roku.
Sprzedaż produktów Ethernet przez następny rok praktycznie została podwojona dzięki
nowym repeterom 10BASE-T oraz dzięki kartom sieciowym.
Na początku lat 80 powstał system NetWare firmy Novell. System ten umożliwiał
dostęp do współdzielonych drukarek, wysyłanie poczty, wymianę plików i dostęp do
centralnych baz danych. Sukces systemu NetWare spowodował jeszcze większe
zapotrzebowanie na karty Ethernet. I w taki sposób technologia Ethernet stała się w ciągu
czterech lat (1988-1992) standardem sieci lokalnych na całym świecie. Wzrost sprzedaży na
rynku Ethernet zwiększył się dziesięciokrotnie (z jednego miliona urządzeń w 1998 do
dziesięciu milionów w 1992).
Pod koniec lat 80 do istniejących sieci dodawane były nowe komputery osobiste i
serwery, co zwiększało natężenie ruchu sieciowego. Komputery PC stawały się coraz bardziej
popularne. Silniejsze komputery wyposażone w graficzny interfejs użytkownika generowały
więcej ruchu związanego właśnie z tym interfejsem. Wiele sieci lokalnych było łączonych ze

6
sobą z wykorzystaniem współdzielonego medium. Takie połączenia powodowały
dramatyczny wzrost natężenia ruchu w sieciach.
Wszystkie te zjawiska stworzyły zapotrzebowanie na szybszą infrastrukturę sieci.
Do łączenia sieci LAN stały się bardzo popularne dwuportowe mosty (bardzo stare
urządzenia, pamiętające początki technologii Ethernet), pozwalały one utrzymać ruch w sieci
lokalnej na odpowiednim poziomie. Pod koniec lat 80 pojawiła się nowa generacja tych
mostów – wieloportowe mosty inteligentne. Natomiast w roku 1990 pojawił się całkiem inny
typ mostu – Kalpana EtherSwitch EPS-700.
Innowacyjność tego urządzenia polegała na architekturze umożliwiającej wiele
równoczesnych transmisji danych podobnie jak w przełączniku telefonicznym.
Wykorzystywało ono technologię cut-through, co zmniejszyło opóźnienia wprowadzane przez
przełącznik. Do analizy pakietów używane były dedykowane układy logiczne zamiast
procesora, mostowanie wykonywane było sprzętowo, a nie programowo, co także znacznie
przyspieszyło przełączanie pakietów.
Przełącznik EtherSwitch stworzył nową klasę produktów: przełączniki sieciowe.
Kolejnym przełomowym krokiem w technologii Ethernet było wprowadzenie pełnego
dupleksu. Zwykły Ethernet działał w trybie pół dupleksu. Maszyna nie mogła jednocześnie
odbierać i wysyłać danych. Od roku 1993 firma Kalpana dodała do swoich przełączników
możliwość pracy w trybie pełnego dupleksu. To rozwiązanie znalazło bardzo szybko wielu
naśladowców. W roku 1997 organizacja IEEE ogłasza standard 802.3x, mówiący o pełnym
dupleksie i kontroli przepływu.
Kolejnym etapem rozwoju sieci było zwiększenie ich prędkości do 100Mb/s. Prace
nad większą wydajnością zaczęły się w roku 1992. W październiku 1993 roku Fast Ethernet
Alliance opublikował specyfiakację 100BASE-X, dziś znane pod nazwą 100BASE-TX.
Jednocześnie firma Grand Junction zaczęła sprzedawać nowe urządzenia i karty Fast
Ethernet: Fast-Switch 10/100 oraz FastNIC100. Nowa technologia Fast Ethernet rozwijała się
coraz prężniej i obejmowała coraz to większe regiony rynku. W marcu 1995 IEEE
zaaprobowało standard 802.3u. Fast Ethernet stał się standardem i mocno wszedł na rynek.
Po bardzo dobrym przyjęciu się standardu 802.3u organizacja IEEE poddała
standaryzacji jeszcze kilka innych innowacyjnych rozwiązań. Były to Gigabit Ethernet
802.3z, nowy standard dotyczący transmisji w trybie full-duplex i kontroli przepływu IEEE
802.3x, standard wprowadzający priorytety pakietów 802.3p oraz standard sieci wirtualnych
802.3Q, a także nie opisana standardem możliwość przełączania w warstwie trzeciej.
W 1994 roku firma Bay Networks zaprezentowała swój pierwszy przełącznik dla sieci
Fast Ethernet o nazwie 28115. Był to pierwszy szkieletowy przełącznik o portach 10/100.
Przełączniki firmy Grand Junction posiadały porty albo 10Mb/s, albo 100Mb/s i były
przeznaczone dla grup roboczych (miały mniejsze tablice portów MAC). Model 28115
posiadał jeszcze jedną rewolucyjną funkcję: możliwość definiowania sieci wirtualnych.
Lata 1995-1998 to czas rozwoju technologii Gigabit Ethernet. Przez cały rok 1997
IEEE pracowało nad zdefiniowaniem standardu. Najpierw skupiono się na opracowaniu
standardu dla połączeń full-duplex po kablu światłowodowym. Jednak była także potrzeba
opracowania standardu dla kabla miedzianego. Zatem grupa Gigabit Ethernet podzieliła się na
dwa obozy. Grupa 802.3z skupiła się na implementacji opartej na kablach światłowodowych i
pełnym dupleksie. Natomiast zespół 802.3ab zajął się opracowaniem standardu dla kabla
miedzianego. Oficjalne wydanie standardu 802.3z przypadło na czerwiec 1998 roku.
Specyfikacja ta zawiera mechanizm CSMA/CD dla sieci Gigabit Ethernet oraz trzy standardy
okablowania: 1000BASE-SX oraz LX dla kabla światłowodowego oraz 1000BASE-CX dla
kabla miedzianego znanego pod nazwą twinax. Ratyfikowany został także standard 802.3ab,
znany pod nazwą 1000BASE-T i wykorzystujący cztery pary kabla kategorii piątej.

7
 Tak wygląda ewolucja sieci Ethernet. Rozwój tej technologii spowodował wzrost
zapotrzebowania na coraz to lepsze i bardziej zaawansowane urządzenia przełączające i
trasujące. Wraz z rozwojem szybkich sieci komputerowych wzrosło także zapotrzebowanie na
bezpieczne udostępnianie zasobów oraz usług sieciowych. [1]

1.2 Specyfikacja zadania.

Głównym zagadnieniem poruszanym w tej pracy jest problem bezpieczeństwa sieci.
Każda sieć narażona jest na ataki dlatego należy używać rozwiązań, które będą pomagały
nam zmagać się z niepowołanymi gośćmi chcącymi korzystać z usług oraz zasobów naszej
sieci. W przypadku sieci przewodowych pierwszą przeszkodą na jaką natknie się potencjalny
intruz jest dostęp fizyczny do urządzenia dostępowego. W przypadku dużych sieci, gdzie nie
jest możliwe, aby każde gniazdo było pod stałą obserwacją osoby zaufanej, gdy po prostu nie
jesteśmy w stanie zabezpieczyć fizycznie wszystkich gniazd sieciowych (a w mało której
sieci tak się zdarza), osoba niepożądana bardzo szybko może uzyskać dostęp fizyczny do
sieci. Jeśli nie zastosujemy odpowiednich mechanizmów bezpieczeństwa, wówczas intruz
może w poważny sposób zaszkodzić naszym zasobom i usługom sieciowym. Bardzo ważne
jest zatem by opracować odpowiednią politykę bezpieczeństwa, najlepiej opierającą się na
modelu bezpieczeństwa AAA (Authentication, Authorization and Accounting) [4]. Chodzi o
to by ewentualny użytkownik sieci, nim uzyska dostęp do jej zasobów musiał najpierw
dokonać uwierzytelnienia swojej osoby, aby potwierdzić swoją tożsamość, następnie musi
zostać dokonana autoryzacja, aby użytkownik otrzymał dostęp tylko do usług oraz zasobów,
które są właśnie dla niego przeznaczone i jemu potrzebne. Dobrze byłoby ostatecznie
logować kto i kiedy miał dostęp do zasobów sieci. Oprogramowaniem, które doskonale
spełnia nasze oczekiwania w odniesieniu do modelu AAA jest RADIUS serwer.
Tematem tej pracy magisterskiej jest zagadnienie bezpieczeństwa sieci LAN. Jednym
ze sposobów ochrony sieci jest filtrowanie ruchu w warstwie drugiej, wykorzystując w tym
celu urządzenia dostępowe.
Aby osiągnąć bezpieczeństwo w sieci należy spełnić podstawowe wymogi:
• Uwierzytelnianie użytkowników otrzymujących dostęp do sieci.
• Szyfrowanie danych przesyłanych przez użytkownika podczas uwierzytelnienia.
• Logowanie czasu i lokalizacji użytkowników.
• Dobór odpowiednich urządzeń warstwy drugiej. Przełączników pozwalających na
zaawansowaną konfigurację zabezpieczeń na portach.
• Instalacja i konfiguracja serwera RADIUS, pozwalającego nam zrealizować model
bezpieczeństwa AAA.
• Dostosowanie maszyn użytkowników do współpracy z RADIUS serwerem.

1.3 Urządzenia warstwy drugiej.

Urządzeniami pracującymi w warstwie drugiej są m.in., koncentratory i przełączniki.
Koncentrator jest urządzeniem pracującym w warstwie drugiej modelu OSI (warstwa
łącza danych). Jest on centralnym miejscem podłączenia wszystkich klientów. Jego
funkcjonowanie opiera się na adresach fizycznych MAC. Na ich podstawie przesyła on
pakiety do odpowiednich portów, przy pomocy koncentratora nie mamy możliwości
tworzenia dodatkowych segmentów sieci. Służy on jedynie jako miejsce podłączenia
użytkownika.
Przełącznik jest urządzeniem pracującym również w warstwie łącza danych.
Nowoczesne konstrukcje potrafią korzystać z informacji zawartych w warstwach wyższych,

8
jest to głównie funkcjonalność związana z routingiem, zagadnieniem jakości usług oraz
bezpieczeństwem. Łączy on ze sobą klienty w punkcie centralnym. Funkcjonowanie
przełącznika tak jak w przypadku koncentratora opiera się na wykorzystaniu adresów MAC,
przełącznik jednak potrafi używać tych adresów do segmentacji sieci (możemy tworzyć
VLANy – wirtualne sieci lokalne), a także do filtrowaniu ruchu na ich podstawie.
Koncentrator jest urządzeniem nieco starszym od przełącznika. Nie oferuje nam on
żadnych mechanizmów zapewniających jakość usług (QoS). Przełącznik natomiast w
zależności od stopnia skomplikowania, oferuje nam priorytetyzację pakietów (np. wg
standardu 803.1p), klasyfikację i reklasyfikację na podstawie zestawu kryteriów, ograniczanie
zajmowanego przez dany rodzaj ramek/pakietów pasma, czy również ograniczanie
dostępnego pasma wykorzystując port lub VLAN. Taki zestaw funkcjonalności stanowi
wielką zaletę w sieci, w której pracuje wiele różnych usług i aplikacji a użytkownik jest w
stanie świadomie określić politykę kontroli ruchu.
Mówiąc o bezpieczeństwie na poziomie warstwy łącza danych należy zauważyć, że
koncentratory nie oferują żadnych mechanizmów zapewniania bezpieczeństwa w sieci. Każda
stacja podłączona do koncentratora otrzymuje transmisje do innych stacji i jest w stanie
efektywnie, bez żadnych specjalnych zabiegów podsłuchać cały ruch występujący w sieci,
przykładowo uwierzytelnianie innej osoby.
Dlatego chcąc filtrować i zabezpieczać ruch w warstwie drugiej, musimy skorzystać z
przełączników. Przełączniki domyślnie uczą się, do którego portu wysyłać dane adresowane
dla konkretnego adresu MAC, co już wymaga od atakującego podjęcia jakiegoś rodzaju
aktywnego działania ( wprowadzenia w błąd przełącznika, lub przełącznika i atakowanej
stacji), by przechwytywać ruch nie adresowany bezpośrednio do nich. Większość
produkowanych obecnie przełączników daje możliwość ograniczenia ilości źródłowych
adresów MAC pojawiających się na konkretnym porcie do konkretnej wartości. Mechanizm
ten chroni przed atakiem typu przepełnienie bufora, kiedy to atakujący generuje dużą ilość
losowych adresów MAC, przepełniając w ten sposób pamięć przełącznika co w efekcie
prowadzi do zamiany go w koncentrator. Atak taki umożliwiają popularne aplikacje dsniff i
ettercap. Jeszcze bardziej zaawansowane konstrukcje pozwalają za filtrowanie ruchu na
podstawie danych z nagłówka IP czy nawet warstwy czwartej – portów TCP/UDP.
Tak jak już wspomniałem na przełącznikach istnieje możliwość podziału sieci LAN na
VLANy, które w większości przypadków skutecznie blokują komunikację pomiędzy dwoma
różnymi stacjami w dwóch różnych VLANach. Dalszy podział, w ramach pojedynczego
VLANu zapewnia koncepcja Private VLANu, która oddziela komunikację pomiędzy stacjami
w tym samym VLANie. W takiej konfiguracji stacje nawet w tym samym VLANie mogą
komunikować się jedynie z wyznaczonym routerem i każdy rodzaj komunikacji stacja-stacja
musi odbywać się za jego pośrednictwem. Dodatkowym mechanizmem bezpieczeństwa w
warstwie drugiej jest ratyfikowany niedawno protokół 802.1X. Stacja podłączona do portu
pracującego w trybie 802.1X musi najpierw przejść zakończone sukcesem uwierzytelnienie,
nim będzie mogła wysłać i odebrać jakiekolwiek inne ramki do/z sieci poza ramkami
protokołu EAP.[1,2]

1.4 Model bezpieczeństwa AAA

Model AAA (Authentication, Autorization, Accounting) oznacza trzy wymagania,
które muszą być spełnione w celu zapewnienia bezpieczeństwa sieci: uwierzytelnianie
(Authentication), autoryzacja (Autorization) i logowanie działalności użytkownika
(Accounting).
Architektura AAA to model klient-serwer. W modelu tym serwerem AAA może być
serwer RADIUS lub inny, zarządzający profilami użytkowników, natomiast klientami AAA –

9
urządzenia obsługujące protokoły komunikacji z serwerem AAA, na przykład są to punkty
dostępowe lub przełączniki. Użytkownicy sieci dokonują autoryzacji oraz uwierzytelniania,
komunikując się z serwerem AAA przez klienta AAA.
Uwierzytelnianie to identyfikacja użytkownika zgłaszającego chęć skorzystania z sieci
oraz weryfikacja autentyczności informacji, którą on przekazuje. Najprostszym sposobem
uwierzytelniania użytkownika jest żądanie podania przez niego, jego nazwy/loginu i hasła.
Czasem użytkownik może dostarczać także dodatkowych informacji uwierzytelniających w
odpowiedzi na generowane przez system autentykacji zapytania.
Pomyślne zakończenie procesu autentykacji jest warunkiem koniecznym uzyskania
dostępu do zasobów sieci.
Autentykacja w modelu AAA daje administratorowi serwera dostępowego możliwość
konfiguracji listy metod autentykacji definiowanych per-usługa lub per-użytkownik i
skojarzenia takiej listy z wybranymi interfejsami lub usługami.
Każda lista metod autentykacji w celu uaktywnienia musi zostać związana z
interfejsem serwera dostępowego. Zasada ta nie odnosi się do listy domyślnej (default), która
znajduje zastosowanie dla wszystkich tych interfejsów dla których nie wskazano wprost innej
listy. Wszystkie metody autentykacji, za wyjątkiem autentykacji lokalnej, zabezpieczeń
dostępu do linii serwera dostępowego oraz dostępu do trybu uprzywilejowanego interpretera
EXEC muszą być konfigurowane w modelu AAA.
Autoryzacja określa, jakie prawa dostępu do usług ma użytkownik. Między
autoryzacją i uwierzytelnianiem istnieje ścisła relacja. Im więcej usług jest dostępnych dla
użytkownika, tym silniejsze powinny być stosowane zabezpieczenia uwierzytelniające.
Zasada ta działa również w drugą stronę: z im mniejszego zakresu usług użytkownik może
korzystać, tym słabsze mogą być zabezpieczenia.
Logowanie pozwala na zapis informacji o włączających się do sieci użytkownikach i o
usługach z jakich będą korzystać. Możliwe jest dzięki temu dynamiczne reagowanie
administratorów na niepokojące zdarzenia w sieci. [4]

10
Rozdział 2

Protokół RADIUS –
Remote Authentication Diall In User Service
Koncepcja scentralizowanego zarządzania dostępem do usług sieci
teleinformatycznych powstała w latach 90. Efektem rozwiązań, które pojawiły się w tym
czasie, było zalecenie RFC 2058 oraz nieco późniejsze RFC 2138. Dotyczyły one zarówno
centralnej bazy danych o uprawnieniach użytkowników korzystających z połączeń
modemowych jako metody dostępu do usług internetowych, jak i protokołu wymiany
wiadomości AAA między użytkownikami i bazą danych. Powstała w ten sposób nowa usługa,
polegająca na zapewnieniu bezpiecznego dostępu do sieci dzięki sprawdzeniu tożsamości
użytkownika – RADIUS (Remote Authentication Dial In User Service). Popularność usług
internetowych spowodowała, że usługi RADIUS rozpowszechniły się również w sieciach
komputerowych łączących dużą liczbę komputerów. [3]

2.1 Charakterystyka protokołu RADIUS

Remote Authentication Dial-In User Service (RADIUS) jest pracującym w
architekturze klient/serwer rozproszonym systemem autentykacji. W systemie tym klient
skonfigurowany jest na serwerze dostępowym, przełączniku lub routerze, serwerem natomiast
jest zdalny wielodostępowy host z uruchomionym dedykowanym oprogramowaniem
RADIUS. Przechowuje on bazę danych o uprawnionych do korzystania z zasobów sieci
użytkownikach i ich prawach. Poprawnie skonfigurowany serwer dostępowy odwołuje się do
jego wiedzy w celu dokonania autentykacji, autoryzacji i sporządzania logów o
użytkownikach korzystających z zasobów sieci.
RADIUS jest protokołem umożliwiającym przenoszenie wiadomości
uwierzytelniania, autoryzacji oraz konfiguracji pomiędzy urządzeniem dostępowym NAS
(Network Access Server) oraz serwerem uwierzytelniania RADIUS. Urządzenie NAS
przekazuje informacji o użytkowniku do serwera RADIUS. Serwer RADIUS odbiera od
użytkowników wiadomości, dokonuje ich uwierzytelnienia i przekazuje informacje niezbędne
do konfiguracji klienta (NAS). Umożliwia to świadczenie przez NAS niezbędnych usług.
Serwer RADIUS może działać jako klient proxy dla innych serwerów RADIUS lub
serwerów uwierzytelniania innego typu. Komunikacja między serwerem RADIUS i klientem
NAS wymaga wzajemnego uwierzytelnienia, do czego wykorzystuje się wspólny klucz.
Również hasła użytkowników są szyfrowane, dzięki czemu serwer RADIUS może być
umieszczony w zupełnie innej części sieci niż użytkownicy wymagający uwierzytelniania.
RADIUS jest protokołem w pełni otwartym. Specyfikacja protokołu jest publicznie
dostępna w formie dokumentu RFC, a oprogramowanie protokołu jest rozpowszechniane bez
pobierania żadnych opłat w formie kodu źródłowego.
Kod ten może podlegać modyfikacjom w celu dostosowania do wszystkich aktualnie
wykorzystywanych systemów bezpieczeństwa. Na routerach i serwerach dostępowych Cisco
protokół RADIUS jest implementowany w ramach modelu AAA. Konfiguracja
bezpieczeństwa w systemie AAA przewiduje możliwość współistnienia protokołu RADIUS z
innymi protokołami podobnego przeznaczenia takimi jak: TACACS+, Kerberos oraz
autentykacją na podstawie lokalnych baz użytkowników na serwerze dostępowym.
Protokół RADIUS znajduje zastosowanie w:

11
 • sieciach, do których dostęp odbywa się poprzez serwery dostępowe różnych
producentów, z których każdy obsługuje RADIUS-a,
• sieciach, w których użytkownik jest uprawniony do wykorzystania jednej określonej
usługi lub jednego określonego hosta (istnieje możliwość takiej konfiguracji praw
użytkownika, aby na przykład mógł on uruchomić tylko sesję terminalową Telnet lub
tylko protokół PPP),
• w sieciach wymagających logowania informacji o użytkownikach, mających dostęp
do jej zasobów.
RADIUS-a nie można wykorzystać:
• w sieciach, w których pracują protokoły AppleTalk Remote Access Protocol (ARAP),
NetBIOS Frame Control Protocol (NBFCP), NetWare Asynchronous Service Interface
(NASI), X.25 PAD,
• dla zapewnienia autentykacji połączeń router-to-router (protokół RADIUS nie
zapewnia mechanizmów autentykacji działających w obie strony takiego połączenia),
• w środowiskach sieci, w których użytkownicy winni korzystać z wielu serwisów
sieciowych (protokół RADIUS zwykle wiąże użytkownika z jednym tylko rodzajem
usługi). [5]

2.2 Uwierzytelnianie przy użyciu protokołu RADIUS

W odpowiedzi na próbę zalogowania się użytkownika do sieci serwer dostępowy
generuje zapytanie o dane użytkownika, w tym jego identyfikator i hasło. Po wprowadzeniu
tych danych z poziomu terminala użytkownika, jego identyfikator wraz z zakodowanym
hasłem zostają wysłane do serwera RADIUS. Rolę serwera autentykacji spełnia host, na ogół
pracujący pod kontrolą systemu operacyjnego Unix z uruchomionym dedykowanym
oprogramowaniem serwera RADIUS. Po sprawdzeniu danych użytkownika skutkiem ich
skonfrontowania z zawartością własnych baz danych serwer RADIUS może odpowiedzieć
jednym z następujących komunikatów:
• Access-Accept - oznacza sukces autentykacji.
• Access-Reject - użytkownik nie został poprawnie zautentykowany,
dostęp do zasobów sieci jest zostaje zablokowany.
• Access-Challenge - prośba o wprowadzenie dodatkowych danych
autentykacyjnych.
Po udanej autentykacji, serwer RADIUS sprawdza, jakie usługi są dostępne dla
danego użytkownika (np. telnet, rlogin, połączenia terminalowe LAT, oprogramowanie
protokołów SLIP czy PPP, możliwość wywołania interpretera EXEC).
Serwer RADIUS na etapie autoryzacji sprawdza też czy działania danego
użytkownika w sieci nie powinny podlegać restrykcjom wynikłym z list dostępu.

12
 Uwierzytelnianie przedstawia poniższy rysunek:

1.Użytkownik łączy się do zdalnego serwera dostępowego, klienta RADIUSA,

wykorzystując połączenie dial-up lub VPN. Następnie przesyła do klienta informacje
uwierzytelniające, zwykle nazwę i hasło.
2.Klient, dysponując tymi informacjami, wysyła do serwera RADIUS żądanie dostępu
„Access-Request” (Areq), zawierające takie atrybuty jak: nazwa użytkownika, jego hasło i
identyfikator oraz identyfikator portu, z którym użytkownik jest skojarzony. Hasło nie jest
przesyłane jawnie, lecz maskowane za pomocą funkcji MD5.
3. W przypadku braku odpowiedzi od serwera klient NAS ponawia przesyłanie
wiadomości AReq przez czas zdefiniowany w konfiguracji. Gdy nie ma dostępu do serwera
podstawowego, istnieje możliwość autoryzacji w alternatywnych serwerach, których listę
przechowuje klient NAS.
Serwer, otrzymując żądanie AReq, uwierzytelnia źródło wiadomości, dzięki
przydzielonym, wspólnym kluczom, po czym odszukuje w swojej bazie danych nazwę
zgodną z nazwą klienta żądającego uwierzytelnienia. Po znalezieniu tej nazwy serwer
sprawdza hasło i uprawnienia danego użytkownika.
4. Serwer RADIUS może dodatkowo przesłać zapytanie o uwierzytelnienie
użytkownika do innego serwera AAA. W przypadku niezgodności danych (błędnego hasła,
portu, lub nieobsługiwania przez NAS użytkownika) serwer nie uwierzytelni użytkownika i
przesyła do klienta wiadomość o odrzuceniu prośby o autentykację – "Access-Reject" (ARej).
W przeciwnym wypadku serwer przesyła żądanie dodatkowych informacji od użytkownika
"Access-Challenge" (AChal).
5. Wiadomość ta jest interpretowana przez klienta, który oczekuje od użytkownika
dostarczenia wymaganych informacji. W odpowiedzi klient przesyła ponownie wiadomość
AReq do serwera, lecz z innym identyfikatorem, wstawiając jednocześnie w miejsce
przesłanego już wcześniej hasła użytkownika żądane przez serwer zaszyfrowane informacje.
6.Serwer RADIUS odpowiada albo wiadomością potwierdzenia dostępu – Access-
Accept (AApt), albo odrzucenia użytkownika – ARej, albo też kolejną wiadomością – AChal.
Jeśli procedura uwierzytelniania zakończy się pomyślnie, serwer RADIUS w wiadomości
AApt przesyła do klienta wszystkie niezbędne dane konfiguracyjne dotyczące
uwierzytelnianego użytkownika. Wiadomości uwierzytelniania przesyłane są między
klientem i serwerem RADIUS za pośrednictwem protokołu UDP.

13
 Kiedy użytkownik zrywa połączenie, serwer zdalnego dostępu zawiadamia o tym
serwer RADIUS i informacja o zakończeniu sesji zapisywana jest do dziennika serwera

2.3 Procesy wykonywane przez RADIUS serwer.

W przypadku, gdy klient skonfigurowany zostanie by używać RADIUS serwera,
każdy użytkownik musi zaprezentować swoje dane autentykacyjne przed klientem.
Użytkownik może podać swój login oraz hasło. W przypadku użytkowników posługujących
się protokołami takimi jak PPP [14] czy SLIP [15], dane o użytkowniku zaszyte są w tych
protokłach i za ich pośrednictwem przekazywane klientowi.
Gdy klient uzyska już informacje o użytkowniku wówczas może rozpocząć proces
autentykacji używając RADIUS serwera. Klient tworzy zapytanie "Access-Request". W
zapytaniu tym zawarte są atrybuty takie jak jego nazwa, hasło, ID klienta oraz numer portu,
do którego klient będzie mógł uzyskać dostęp.
Pakiet Access-Request przesyłany jest do RADIUS serwera poprzez sieć. Jeżeli klient
nie otrzyma żadnej odpowiedzi przez określoną ilość czasu, wówczas RADIUS ponawia
żądanie określoną ilość razy. W przypadku, gdy główny serwer RADIUS nie dopowiada, jest
wyłączony lub z jakiś innych powodów nieosiągalny, wówczas klient może wystosować
swoje pytanie do innych serwerów RADIUS.
W przypadku, gdy serwer RADIUS otrzyma żądanie od klienta, zostaje sprawdzona
autentyczność klienta. Jeżeli serwer RADIUS nie posiada informacji o kliencie, wówczas
żądanie klienta zostanie odrzucone. Jeżeli natomiast klient poprawnie uwierzytelni swoją
tożsamość, wówczas RADIUS serwer sprawdza czy w jego bazie użytkowników (lub bazie z
której korzysta) znajduje się dane użytkownika przesyłana przez klienta. Dany użytkownik
musi spełniać wszystkie dotyczące niego wymagania wyspecyfikowane w pliku
konfiguracyjnym RADIUS-a. Zawsze wymagane jest hasło, mogą być to także inne dane
autentykacyjne w zależności od wybranej przez nas metody autentykacji.
Jeżeli zapytanie tego wymaga RADIUS serwer może wysłać zapytenie do innych
serwerów, w takim przypadku RADIUS serwer staje się klientem.
Jeżeli jakiekolwiek atrybuty proxy (Proxy-State) pojawią się w zapytaniu Access-
Request, nie mogą być one zmodyfikowane i muszą być przesłane w takiej kolejności i
postaci w jakiej się pojawiły. Inne atrybuty mogą być umieszczone przed, za lub nawet
pomiędzy atrybutem Proxy-State.
Jeżeli jakikolwiek warunek nie jest spełniony, RADIUS serwer przesyła odpowiedź
"Access-Reject", która oznacza że użytkownik zostanie odrzucony. Dodatkowo RADIUS
może przesłać w pakiecie Access-Reject wiadomość, która może zostać przedstawiona przez
klienta użytkownikowi. Żadne inne atrybuty (prócz Proxy-State) nie są dozwolone w pakiecie
Access-Reject.
Jeżeli wszystkie warunki są spełnione, RADIUS serwer może wysłać użytkownikowi
pakiet Access-Challenge, na które użytkownik musi odpowiedzieć. Access-Challenge może
zawierać wiadomość tekstową, którą klient następnie przedstawi użytkownikowi, a także
atrybuty stanu (State attribute).
Klient, po otrzymaniu Access-Challenge informuje o tym użytkownika i żąda od niego
odpowiedzi. Następnie klient na nowo przesyła pakiet Access-Request zawierający nowy ID,
hasło użytkownika oraz State Attribute z pakietu Access-Challenge. Jedynie wartości 0 lub 1,
atrybutu State mogą być obecne w odpowiedzi. Serwer może odpowiedzieć na to nowe
zapytanie na trzy sposoby. Może przesłać pakiet Access Accept, Access-Reject, lub kolejny
pakiet Access-Challenge.
Jeśli wszystko jest w porządku, lista atrybutów związanych z danym użytkownikiem
umieszczana zostaje w pakiecie Access-Accept. Wartości atrybutów zawierają informacje

14
takie jak rodzaj serwisu dostarczanego użytkownikowi (np. SLIP, PPP, Login User) oraz
wszystkie pozostałe informacje potrzebne w celu dostarczenia użytkownikowi dokładnie
takich usług jakie są przeznaczone dokładnie dla niego. W przypadku SLIP lub PPP może to
być adres IP, maska podsieci, MTU, itp. Może to być także nazwa protokołu jakiego ma
używać użytkownik oraz nazwa hosta użytkownika.[5]

2.4 Pakiet Challenge/Response.

Podczas przesyłania pakietu Challenge użytkownikowi wysyłana jest losowa liczba z
żądaniem zaszyfrowania jej, a następnie odesłania wyniku z powrotem. Uprawnieni
użytkownicy powinni być wyposażeni w urządzenia typu karty inteligentne lub
oprogramowanie, które ułatwi odesłanie właściwej odpowiedzi. Nieuprawnieni użytkownicy
nie będą posiadać ani odpowiednich urządzeń ani odpowiedniego oprogramowania
wymaganego do przeprowadzenia szyfrowania.
Pakiet Access-Challenge standardowo zawiera Reply-Message, w której
przechowywana jest liczba challenge (losowa liczba o której była mowa powyżej), który
zostanie przedstawiony użytkownikowi. Jest bardzo mało prawdopodobne, praktycznie
niemożliwe, że liczba ta powtórzy się. Liczba ta generowana jest przez serwer, który wie
jakiego typu autentykacji będzie używać uprawniona osoba. To pozwala serwerowi na
wygenerowanie unikalnej pseudolosowej liczby o odpowiednim rdzeniu i odpowiedniej
długości.
Użytkownik po otrzymaniu liczby challenge szyfruje ją używając odpowiedniego
oprogramowania lub urządzenia. Następnie przekazuje ją z powrotem do klienta, którego
zadaniem jest przekazanie liczby RADIUS serwerowi w drugim pakiecie Access-Request.
Jeżeli otrzymana odpowiedź jest taka jakiej oczekiwał serwer RADIUS, wówczas odpowie on
pakietem Access-Accept i użytkownik otrzyma dostęp do sieci, w przeciwnym przypadku
otrzymamy Access-Reject co oznacza, że połączenie zostaje dla nas zamknięte.
Poniższy przykład ilustruje przebieg autentykacji z użyciem RADIUS serwera.
Urządzenie dostępowe NAS(Network Access Server), w tym przypadku przełącznik
wysyła do RADIUS serwera pakiet Access-Request, zawierający atrybuty takie jak: NAS-
Identifier, NAS-Port, User-Name, User-Password (może to być zwyczajny tekst np. "haslo").
Po otrzymaniu pakietu Access-Request server jako odpowiedź wysyła klientowi pakiet
Access-Challenge zawierający atrybuty State oraz Reply-Message, gdzie przechowywana jest
liczba challenge, np. "Challenge 12345678, potwierdź swoją tożsamość.", zadaniem NAS
będzie pokazanie tej wiadomości użytkownikowi. NAS prosi użytkownika o odpowiedź, a
następnie po jej otrzymaniu przesyła nowy pakiet Access-Request do serwera RADIUS
(pakiet posiada nowy ID), zawierający NAS-Identifier, NAS-Port, User-Name, User-
Password (szyfrowana odpowiedź przesłana przez użytkownika) oraz tą samą wartość
atrybutu State jaka została przesłana przez serwer w pakiecie Access-Challenge. Serwer
RADIUS następnie przesyła Access-Accept, jeżeli odpowiedź zawiera pożądane wartości,
bądź Access-Reject w przeciwnym wypadku. RADIUS może także przesłać kolejne zapytanie
Access-Challenge.[5]

2.5 Współpraca z PAP oraz CHAP.

W przypadku protokołu PAP [16], NAS pobiera PAP ID oraz hasło i przesyła te
informacji w pakiecie Access-Request jako User-Name oraz User-Password. NAS może także
dołączyć atrybuty takie jak Service-Type=Framed-User oraz Framed-Protocol=PPP, by
serwer RADIUS mógł dostarczyć żądaną usługę użytkownikowi.

15
 W przypadku CHAP [17], NAS generuje losową liczbę (128 bitową) i wysyła ją
użytkownikowi, który zwraca odpowiedź CHAP razem z wartościami CHAP ID oraz CHAP-
Response jako CHAP-Password. Losowa liczba może być dołączona do CHAP-Challenge lub
,jeśli ma długość 128 bitów, może zostać dołączona do pakietu Access-Request. NAS może
także przesłać atrybuty takie jak Service-Type=Framed-User oraz Framed-Protocol=PPP, by
serwer RADIUS mógł dostarczyć żądaną usługę użytkownikowi.
RADIUS serwer szuka hasła opartego na User-Name, szyfruje liczbę challenge
używając funkcji MD5 i CHAP ID, hasło oraz CHAP challenge (pobierane z atrybutu CHAP-
Challenge, jeżeli jest obecny w przeciwnym przpadku z Access-Request), następnie tworzy
CHAP-Password. Jeżeli wszystko pasuje wówczas RADIUS przesyła pakiet Access-Accept,
w przeciwnym wypadku Access-Reject.
Jeżeli RADIUS nie jest w stanie przeprowadzić autentykcji wówczas przesyła pakiet
Access-Reject. CHAP wymaga by hasło było nieszyfrowane, gdyż tylko wtedy serwer może
dokonać szyfrowania CHAP challenge, a następnie porównać wynik z odpowiedzią CHAP.
Jeżeli hasło nie występuje w postaci czysto tekstowej wówczas serwer musi wysłać Access-
Reject klientowi.[5]

2.6 Proxy.
Serwer RADIUS może zostać skonfigurowany jako serwer Proxy dla innych
serwerów RADIUS. Wówczas jeden serwer RADIUS otrzymuje Authentication Request,
bądź Accounting Request od klienta RADIUS-a (czyli od NAS), przekierowuje żadanie do
zdalnego serwera RADIUS, następnie otrzymuje od niego odpowiedź, którą przekazuje
klientowi, możliwe są zmiany w odpowiedzi, odzwierciedlające lokalną politykę
administrowania. Powszechnym użyciem RADIUS proxy jest roaming. Roaming pozwala na
udostępnianie zasobów danej sieci jednostkom znajdującym się w innych sieciach fizycznych.
Usługa proxy działa w następujący sposób. NAS przesyła swoje żądanie Access-
Request do serwera, którego zadaniem jest przekazanie zapytania do serwera zdalnego.
Zdalny serwer po otrzymaniu żądania przesyła odpowiedź (Access-Accept, Access-Reject lub
Access-Challenge) do serwera proxy, który następnie przesyła odpowiedź do urządzenia
NAS. Atrybut User-Name może zawierać identyfikator "Network Access", potrzebny w celu
pełnienia usług Proxy. To, który zdalny serwer odbierze zapytanie od serwera proxy powinno
zostać określone w regułach autentykacji. Reguła autentykacji może być częścią
identyfikatora Network Access (tzw. reguła "named realm"). Ewentualnie może być to
określone w jakikolwiek dowolny inny sposób zdefiniowany na serwerze proxy, np. Called-
Station-Id (tzw. "numberad realm").
Jeden RADIUS server może jednocześnie pełnić funkcję serwera proxy jak i zdalnego
serwera dostępowego. Jeden serwer proxy może pełnić funkcję proxy jednocześnie dla
dowolnej liczby zdalnych serwerów. Serwer zdalny natomiast może mieć przypisanych do
siebie dowolną liczbę serwerów proxy i dostarczać autentykacji dla wielu reguł. Serwer proxy
może natomiast pełnić funkcję proxy dla innego serwera proxy, tworząc w ten sposób łańcuch
proxy, należy jednak uważać by uniknąć zapętlenia.
Komunikacja pomiędzy NAS, a serwerem zdalnym RADIUS, przy użyciu serwera
RADIUS proxy.
1. NAS wysyła żądanie access-request do serwera proxy.
2. Serwer proxy przesyła owe żądanie do serwera zdalnego.
3. Serwer zdalny wysyła odpowiedź do serwera proxy, może być to Access-
Accept, Access-Reject, bądź Access-Challenge. W tym przykładzie zakładamy
iż wysłana została odpowiedź Access-Accept.
4. Serwer proxy wysyła odpowiedź Access-Accept do NAS.

16
 Serwer proxy musi ominąć jakiekolwiek atrybuty Proxy-State obecne w przesyłanym
pakiecie (żądania czy też odpowiedzi). Jego działanie nie może być uzależnione od
zawartości atrybutu Proxy-State, dodanej przez poprzedni serwer proxy.
Jeżeli jakiekolwiek atrybuty Proxy-State obecne są w żądaniu otrzymanym od klienta,
wówczas serwer proxy musi dołączyć te atrybuty w odpowiedzi przesyłanej do klienta.
Serwer proxy może włączać atrybuty Proxy-State do zapytań Access-Request, podczas
forwardowania zapytań lub może je pomijać. Jeżeli serwer proxy pominie atrybuty Proxy-
State podczas forwardowania zapytań, wówczas musi je koniecznie dołączyć do odpowiedzi
przesyłanej do klienta.
Szczegółowy opis operacji z użyciem serwera proxy.
1. NAS wysyła pakiet access-request do serwera proxy. Serwer proxy rozszyfrowuje
hasło użytkownika – "User-Password", jeżeli jest ono obecne w pakiecie, używając w tym
celu hasła "shared secret", które znane jest klientowi NAS. Jeśli w zapytaniu użyty został
atrybut CHAP-Password, natomiast serwer nie wie nic o atrybucie CHAP-Challenge,
wówczas serwer proxy musi pozostawić "Request-Authenticator" niezmienionym ", lub
skopiować go do atrybutu CHAP-Challenge.
Serwer proxy może dodać atrybut Proxy-State do pakietu (jeden serwer nie może
dodać więcej niż jednego atrybutu). Jeżeli dany serwer proxy dodaje swój atrybut Proxy-
State, wówczas atrybut ten zostanie dodany po innych atrybutach Proxy-State, które obecne
są w danym pakiecie (serwer może nie forwardować pozostałych atrybutów, ale koniecznie
musi pozostawić ich zawartość w nietkniętym stanie). Serwer proxy nie może zmienić
kolejności jakichkolwiek atrybutów tego samego typu, włączając w to również atrybut Proxy-
State.
2. Serwer proxy szyfruje hasło User-Password, jeżeli jest ono obecne w pakiecie,
używając wspólnego ze zdalnym serwerem hasła, ustawia Identyfikator (jeśli jest wymagany)
i następnie przesyła Access-Request do serwera zdalnego.
3. Serwer zdalny weryfikuje używane przez użytkownika hasło User-Password,
CHAP-Password, lub inne dane autentykacyjne, i następnie zwraca odpowiedź access-accept,
access-reject lub access-challenge z powrotem do serwera proxy. W tym przykładzie
zakładamy, że wysłany pakiet to pakiet access-accept. Zdalny serwer musi skopiować
wszystkie atrybuty Proxy-State, w takiej kolejności w jakiej występują (kopiowane są tylko
atrybuty Proxy-State) i dołączyć je w niezmienionej postaci do pakietu odpowiedzi.
4. Serwer proxy weryfikuje poprawność autentykatora "Response Authenticator",
używając hasła znanego sobie oraz serwerowi zdalnemu. W przypadku, gdy weryfikacja nie
powiedzie się, wówczas odrzuca on pakiet. Jeżeli pakiet pomyślnie przejdzie weryfikację,
wówczas serwer proxy usuwa ostatni atrybut Proxy-State (jeśli taki jest), podpisuje "Response
Authenticator" używając wspólnego z NAS hasła, przywraca identyfikator by pasował do
identyfikatora otrzymanego od NAS i wysyła Access-Accept do urządzenia NAS.
Może zajść potrzeba by serwer proxy zmienił atrybuty z przyczyn lokalnego
bezpieczeństwa. Mimo wszystko serwer nie może zmienić następujących atrybutów: Proxy-
State, State i Class.
Konfigurując serwer proxy należy uważać jakie wartości nadawane są atrybutowi
"Service-Type", ma to znaczenie w przypadku, gdy nadajemy pewnym użytkownikom prawa
administracyjne.[5]

2.7 Protokół UDP.

RADIUS serwer jako protokołu transportowego używa protokołu UDP [18]. Protokół
ten został wybrany z przyczyn czystko technicznych. Aby to wyjaśnić należy przyjrzeć się
trochę dokładniej charakterystyce protokołu RADIUS.

17
 W czasie pracy RADIUS serwera mamy do czynienia z przesyłaniem różnego rodzaju
pakietów. Są one przesyłane bardzo często i ważne jest by były przesyłane szybko i sprawnie.
Jeżeli nie powiedzie się zapytanie do głównego serwera RADIUS, wówczas wtórny
serwer musi zostać odpytany. Aby spełnić te wymagania, kopia zapytania musi być
przechowywana ponad warstwą transportową, by umożliwić alternatywną transmisję.
Oznacza to, że wymagany jest także określenie czasu retransmisji.
Wymagania czasowe protokołu UDP są znacząco inne niż protokołu TCP. Protokół
RADIUS nie wymaga śledzenia zgubionych podczas transmisji danych, które tylko
spowalniałoby autentykację użytkownika.
Bezstanowa natura protokołu UDP upraszcza jego użycie. Podczas autentykacji mogą
wystąpić pewne nieprzewidziane zdarzenia typu restartowanie serwera RADIUS,
restartowanie NAS, zerwania połączenia, itp. W przypadku protokołu TCP wszystkie te
zdarzenia są w odpowiedni sposób obsługiwane, nie jest to jednak potrzebne podczas
autentykacji przy użyciu protokołu RADIUS. Protokół UDP pomija obsługę wszystkich
nieprzewidzianych zdarzeń. Protokuł UDP upraszcza implementację serwera.
Początkowo serwer RADIUS działał w sposób jednowątkowy. Polegało ta na tym, że
w jednym momencie mógł obsłużyć tylko jedno zapytanie i odpowiedź. Nie było to
wygodnym rozwiązaniem, gdyż uwierzytelnienie w rzeczywistości trwało nawet kilka
sekund. Nikt z użytkowników RADIUS serwera nie zgodziłby się na zbyt długie oczekiwanie
na autentykację. Stało się oczywiste, że serwer musi obsługiwać zapytania w trybie
wielowątkowym. Prostą drogą do osiągnięcia tego celu było wykorzystanie protokołu
UDP.[5]

2.8 Zasady retransmisji.

W przypadku, gdy RADIU serwer oraz alterantywny RADIUS serwer używają tego
samego hasła dla klienta, można wówczas retransmitować pakiety o tym samym ID oraz
atrybucie Request Authenticator do serwera alternatywnego, ponieważ zawartość tych
atrybutów nie zmienia się. Można jednak użyć nowej wartości Request Authenticator, jeżeli
tylko chcemy.
Jeżeli zmienimy zawartość atrybutu User-Password, wówczas będzie potrzeba użycia
nowych wartości Request Authenticator oraz ID.
Jeżeli NAS retransmituje zapytania ciągle do tego samego RADIUS serwera i atrybuty
zapytania nie zmieniają wartości, wówczas należy użyć tych samych wartości Request
Authenticator, ID oraz portu źródłowego. Jeżeli jakakolwiek wartość się zmieni, należy użyć
nowych wartości Request Authenticator oraz ID.
NAS może używać tego samego ID dla wszystkich serwerów, lub może komunikować
się z każdym serwerem przy użyciu innego ID. Jeżeli zachodzi potrzeba użycia więcej niż 256
ID dla jednego NAS, wówczas można użyć dodatkowych portów do wysyłania zapytań i
przydzielić każdemu ID inny port. Ten mechanizm pozwala na obsłużenie szesnastu
milionów zapytań do jednego serwera w jednym momencie.[5]

2.9 Sprawdzanie aktywności serwera.

Nie jest zalecane sprawdzanie czy RADIUS serwer jest uruchomiony przy pomocy
polecenia ping. Nie wnosi ono żadnych korzyści, lepiej wysłać prośbę o autentykację.
Natomiast jeśli chcemy monitorować RADIUS serwer, możemy posłużyć się protokołem
SNMP [19].[5]

18
19
Rozdział 3

Pakiety RADIUS serwera.

3.1 Format pakietu.
Pakiety RADIUS serwera opakowane są w pakiety UDP i umieszczane w polu danych
tych pakietów, pole portu źródłowego ma wartość 1812. Gdy generowana jest odpowiedź
porty źródłowy i docelowy są zarezerwowane.
Poniżej przedstawiony jest schematycznie format pakietu.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Authenticator

Attributes ...

Pole Code jest ośmiobitowym polem, identyfikuje ono typ pakietu RADIUS-a. Jeżlie
odebrany pakiet posiada błędne pole kodu, wówczas jest odrzucany.
Każdy typ pakietu ma przypisaną wartość dziesiętną, tak jak na poniższym rysunku.

Wartość dziesiętna Typ pakietu

1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server
(eksperymentalne)
13 Status-Client
(eksperymentalne)
255 Zarezerwowane

Kody 12 i 13 są zarezerwowane, ale nieużywane. Przeznaczone są do późniejszego

użycia.
Pole Identifier wykorzystywane jest przy dopasowywaniu zapytań i odpowiedzi.
Dzięki temu polu RADIUS może w krótkim czasie wykryć np. zduplikowane zapytania.
Pole Length jest 16 bitowym polem. Identyfikuje ono długość pakietu łącznie z polami
Code, Identifier, Length, Authenticator oraz Attribute. Wszystkie bity ponad zdefiniowaną
długość zostaną zignorowane. Jeżlie pakiet jest krótszy niż podaje to pole Length, wówczas
zosatnie on także odrzucony. Minimalna długość pakietu to 20 bitów, maksymalna natomiast
wynosi 4096.
Pole Authenticator ma długość 128 bitów. Pole to używane jest w celu autentykacji
odpowiedzi z RADIUS serwera, wykorzystywane jest podczas ukrywania hasła.

20
 W pakietach Access-Requeset, pole Authenticator to losowa 128 bitowa wartość
zwana Request Authenticator. Wartość ta powinna być nieprzewidywalna i unikalna przez
cały czas ważności hasła wymienianego pomiędzy klintem, a RADIUS serwerem (tzw.
"shared secret"). Jest to ważne, gdyż w pewnych okolicznościach mogłoby dojść do ataku
przy użyciu odgadniętego Request Authenticator oraz wcześniej przechwyconej odpowiedzi
serwera. Zatem Request Authenticator powinien wykazywać globalną i czasową unikalność.
Wartość Request Authenticator występująca w pakiecie Access-Request także
powinna być nieprzewidywalna, gdyby była możliwa do odgadnięcia wówczas istniałoby
ryzyko podszycia się za RADIUS serwer i odbieranie pakietów Access-Request przez osobę
atakującą.
Protokoły takie jak RADIUS nie są w stanie obornić się przed fizyczną kradzieżą
pakietów przepływających podczas autentykacji, mimo wszystko dzięki unikalnej wartość
Request Authenticator sesja autentykacji jest skutecznie zabezpieczona.
NAS oraz RADIUS serwer wymieniają się hasłem. Hasło to poprzedzone jest przez
wartość Request Authenticator. Przy użyciu funkcji MD5 generowana jest 128 bitowa
wartość, następnie wykonywana jest operacja xor na tej liczbie oraz na haśle podanym przez
użytkownika. Ten wynik umieszczany jest w atrybucie User-Password.
Pole Authenticator w pakietach takich jak Access-Accept, Access-Reject, oraz
Access-Challenge nazywane jest Response Authenticator. Zawiera ono haszowany funkcją
MD5 strumień bitów, w którym zawarte są pola Identifier, Length, Request Authenticator z
pakietu Access-Request oraz atrybuty odpowiedzi, poprzedzone hasłem shared secret. Zatem
Respone Authenticator wygląda w następujący sposób:

ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

Uwagi.
Hasło używane pomiędzy NAS oraz RADIUS serwerem powinno być przynajmniej
128 bitowe i skonstruowane wg. zasad tworzenia dobrego hasła. Nie powinna być to
absolutnie pusta wartość, gdyż może to spowodować łatwe fałszownie pakietów.
RADIUS musi używać źródłowego adresu IP pakietów RADIUS UDP by określić
jakiego shared secret używa, w ten sposób pakiety mogą być przesyłane przez serwer proxy.
Serwery proxy muszą być zdolne do przetwarzania otrzymywanych pakietów,
ponieważ każdy proxy serwer może dodać do pakietu atrybut Porxy-State, zatem odbierając
dany pakiet, docelowy serwer musi być w stanie odrzucić atrybut Proxy-State. Tylko pakiety
Proxy-State mogą być odrzucane nic innego nie może zostać zmienione.[5]

3.2 Typy pakietów.

Typ pakietu RADIUS określony jest przez pole Code w pierwszych ośmiu bitach
pakietu. [5]

3.3 Access-Request.
Pakiety Access-Request wysyłane są do RADIUS serwera przez urządzenie
dostępowe NAS. Przenoszone są w nim informacje o tym czy użytkownik ma dostęp do
określonego NAS oraz informacje o usługach do jakich użytkownik będzie miał dostęp. W
przypadku, gdy chcemy dokonać autentykacji jakiegoś użytkownika, pakiet przesyłany do
RADIUS serwera, w polu Code musi mieć wartość "1" co odpowiada pakietowi Access-
Request.
Po otrzymaniu pakietu Access-Request od klienta, RADIUS musi wysłać odpowiedź.

21
 Access-Request powinien zawierać atrybut User-Name, a także atrybuty NAS-IP-
Address lub NAS-Identifier lub oba.
Access-Request musi zawierac takie atrybuty jak User-Password lub CHAP-Password
lub State. Nie może zawierać obydwu atrybutów User-Password i CHAP-Password. Jeżeli w
przyszłości pewne nowe metody autentykacyjne pozwolą na korzystanie z innych informacji
w celu autentykacji, wówczas te inne (nowe) atrybuty będą mogły zostać użyte w pakiecie
Access-Request zamiast User-Password lub CHAP-Password.
Pakiet Access-Request powinien zawierać także atrybuty NAS-Port lub NAS-Port-
Type lub jednocześnie oba, chybaże dostęp o jaki prosi użytkownik nie wymaga identyfikacji
portu lub NAS nie uwzględnia identyfikacji portu.
Access-Request może zawierać dodatkowe atrybuty jako reguły przetwarzania
zapytań dla serwera, ale serwer nie musi honorować tych reguł.
Przesyłane hasło użytkownika szyfrowane jest algorytmem RSA Message Digest
Algorithm MD5 [13].
Poniżej przedstawiony został poglądowny rysunek pakietu Access-Request.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Request Authenticator

Attributes ...

Wartoś 1 umieszczona w polu Code identyfikuje pakiet Access-Request.

Pole Identifier musi być zmienione jeżeli zajdą jakiekolwiek zmiany w polu Attributes
i jeśli dla poprzedniego żądania została wysłana poprawna odpowiedź. Aby zaszła
retransmisja wówczas to pole musi pozostać niezmienione.
Pole Request Authenticator musi zostać zmienione za każdym razem, gdy zajdą
zmiany w polu Identifier.
Pole Attributes ma zmienną długość, zawiera listę atrybutów wymaganych w celu
dostarczenia odpowiednich usług oraz wszelkie opcjonalne atrybuty.[5]

3.4 Access-Accept.
Pakiet Access-Accept wysyłany jest przez RADIUS serwer, dostarczając niezbędnych
informacji, koniecznych do rozpoczęcia korzystania przez użytkownika z żądanych przez
niego usług.
Jeśli wszystkie atrybuty przesłane w pakiecie Access-Request są zgodne z
oczekiwaniami RADIUS serwera, wówczas ten musi wysłać pakiet, z polem Code
ustawionym na 2, co odpowiada pakietowi Access-Accept.
Gdy pakiet Access-Accept jest odbirany, jego pole Identifier sprawdzane jest z polem
trwającego żądania Access-Request. Pole Response Authenticator musi zawierać prawidłową
odpowiedź w odniesieniu do trwającego Access-Request. Nieważne pakiety są odrzucane.

22
 Rysunek przedstawia pakiet Access-Accept.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Response Authenticator

Attributes ...

Wartoś 2 umieszczona w polu Code identyfikuje pakiet Access-Accept.

Pole Identifier jest kopią pola Identifier z pakietu Access-Request, który spowodował
aktualną odpowiedź Access-Accept.
Pole Response Authenticator obliczane jest z wartości Access-Request tak jak opisano
to wcześniej.
Pole Attributes ma zmienną długość, może zawierać zero lub więcej atrybutów. [5]

3.5 Access-Reject.
Jeśli jakakolwiek wartość odebranych przez serwer atrybutów jest nieakceptowalna,
wówczas RADIUS musi wysłać pakiet z ustawionym polem Code na wartość 3 (oznacza ona
pakiet Access-Reject). Pakiet Access-Reject może zawierać jeden lub więcej atrybutów
Reply-Message zawierających odpowiedź tekstową dla użytkownika.
Rysunek przedstawia pakiet Access-Reject.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Response Authenticator

Attributes ...

Wartoś 3 umieszczona w polu Code identyfikuje pakiet Access-Reject.

Pole Identifier jest kopią pola Identifier pochodzącego z Access-Request, które
spowodowało tą odpowiedź Access-Reject.
Pole Response Authenticator obliczane jest z wartości Access-Request tak jak opisano
to wcześniej.
Pole Attributes ma zmienną długość, może zawierać zero lub więcej atrybutów. [5]

3.6 Access-Challenge.
Pakiet Access-Challenge jest dodatkowym zapytaniem serwera RADIUS, kierowanym
do użytkownika w procesie autentykacji. Pakiet Access-Challenge identyfikuje pole Code
ustawione na wartość 11.
Pole Attributes może zawierać jeden lub więcej atrybutów Reply-Message, również
pojedynczy atrybut State lub żadnego. Mogą zstać dołączone atrybuty Vendor-Specific, Idle-
Timeout, Session-Timeout and Proxy-State. Żadne inne atrybuty nie są dopuszczlne w
pakiecie Access-Challenge.

23
 Gdy pakiet Access-Accept jest odbierany, jego pole Identifier sprawdzane jest z polem
trwającego żądania Access-Request. Pole Response Authenticator musi zawierać prawidłową
odpowiedź w odniesieniu do trwającego Access-Request. Nieważne pakiety są odrzucane.
Jeżeli NAS nie obsługuje pakietów challenge/response, wówczas powinno
potraktować pakiety Access-Accept i Access-Challenge jak pakiet Access-Reject.
Jeżeli NAS wspomaga challenge/response, wówczas po otrzymaniu prawidłowego
pakietu Access-Challenge powinno wysłać nowy pakiet Access-Request do RADIUS
serwera. NAS może (ale nie musi) wyświetlić użytkownikowi informację, następnie poprosić
użytkownika o odpowiedź. Następnie wysyła oryginalny pakiet Access-Request z nowym ID
oraz nowym Request Authenticator. Atrybut User Password zaminiany jest natomist z
szyfrowaną odpowiedzią użytkownika. Do pakietu dołączony jest także atrybut State
pochodzący z pakietu Access-Challenge (jeśli wogóle jakiś był obecny). Maksymalnie jedna
instancja atrybutu State może być obecna w pakiecie Access-Request.
NAS, który wspomaga PAP przekierowuje Reply-Message do wdzwaniającego się
klienta i akceptuje odpowiedź PAP, której może użyć pomimo że użytkownik udzielił
odpowiedzi. Jeśli NAS nie wspomaga PAP, wówczas musi potraktować Access-Challenge
jako pakiet Access-Reject.
Rysunek przedstawia pakiet Access-Challenge.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Response Authenticator

Attributes ...

Wartoś 11 umieszczona w polu Code identyfikuje pakiet Access-Challenge.

Pole Identifier jest kopią pola Identifier pochodzącego z Access-Request, które
spowodowało tą odpowiedź Access-Challenge.
Pole Response Authenticator obliczane jest z wartości Access-Request tak jak opisano
to wcześniej.
Pole Attribtes ma zmienną długość, może zawierać zero lub więcej atrybutów. [5]

24
Rozdział 4

Atrybuty występujące w pakietach Access Request

RADIUS serwera.
W tym rozdziale nastąpi krótki opis możliwych do wybrania atrybutów. Nie będą to
wszystkie możliwe atrybuty RADIUS serwera, lecz najczęściej używane.
Atrybuty wykorzystywane są przez żądania i odpowiedzi do przenoszenia określonych
informacji dotyczących autentykacji, autoryzacji oraz szczegółów konfiguracyjnych
zestawianego połączenia.
Koniec listy atrybutów identyfikowany jest przy pomocy wartości pola Length
pakietów RADIUS-a. Pewne atrybuty mogą być włączane kilkakrotnie w jednym pakiecie. Ile
razy dany atrybut może wystąpić w danym pakiecie i czy wogóle może w nim wystąpić
określa opis każdego z nich.
Jeśli występują atrybuty o tym samym polu Type, kolejność ich występowania musi
być przestrzegana przez każdy serwer proxy. Kolejność atrybutów o różnych wartościach
pola Type nie jest istotna. Ani RADIUS ani jego klient nie potrzebują żadnych informacji o
kolejności atrybutów mających różne pola Type. Atrybuty o tym samym polu Type nie
powinny sąsiadować ze sobą.
Poniższy rysunek przedstawia ogólną postać każdego atrybutu.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
Type Length Value

Pole typu ma długość ośmiu bitów. Wartości jakie mogą się tu pojawić przedstawione
są w "Assigned Numbers" [20]. Zarówno RADIUS jak i jego klient mogą ignorować atrybuty
o nieznanej wartości Type.
Opisane tu zostały wartości pola Type, wykorzystywane przez RADIUS serwer:

1 User-Name
2 User-Password
3 CHAP-Password
4 NAS-IP-Address
5 NAS-Port
6 Service-Type
7 Framed-Protocol
8 Framed-IP-Address
9 Framed-IP-Netmask
10 Framed-Routing
11 Filter-Id
12 Framed-MTU
13 Framed-Compression
14 Login-IP-Host
15 Login-Service
16 Login-TCP-Port
17 (unassigned)

25
 18 Reply-Message
19 Callback-Number
20 Callback-Id
21 (unassigned)
22 Framed-Route
23 Framed-IPX-Network
24 State
25 Class
26 Vendor-Specific
27 Session-Timeout
28 Idle-Timeout
29 Termination-Action
30 Called-Station-Id
31 Calling-Station-Id
32 NAS-Identifier
33 Proxy-State
34 Login-LAT-Service
35 Login-LAT-Node
36 Login-LAT-Group
37 Framed-AppleTalk-Link
38 Framed-AppleTalk-Network
39 Framed-AppleTalk-Zone
40-59 (reserved for accounting)
60 CHAP-Challenge
61 NAS-Port-Type
62 Port-Limit
63 Login-LAT-Port

Pole Length ma długość ośmiu bitów. Określa ono rozmiar atrybutu poprzez
zsumowanie długości samego atrybutu, długości pola Type i pola Length. Jeśli atrybut
przesyłany w pakiecie Access-Request ma długość niezgodną z prawdą, wówczas jako
odpowiedź powinien zostać wysłany pakiet Access-Reject. Jeśli taki atrybut (o źle określonej
wartości pola Length) obecny jest w pakietach Access-Accept, Access-Reject lub Access-
Challenge, pakiety te powinny zostać potraktowane również jako Access-Reject lub
odrzucone bez poinformowania klienta.
Pole Value o długości zero i więcej bajtów zawiera informacje specyficzne dla
konkretnego atrybutu. Format i długość tego pola określone jest przez pole Type. [5]

4.1 User-Name.
Ten atrybut zawiera nazwę/login użytkownika, który prosi o uwierzytlenienie. Atrybut
wysyłany jest w pakiecie Access-Reaquest.
Może także być przesyłany w pakiecie Access-Accept. W takim przypadku klient
powinien używać atrybutu User-Name także we wszystkich pakietach Accounting-Request
aktualnej sesji. [5]

26
4.2. User-Password
Jest to hasło użytkownika, którego będziemy uwierzytleniać lub jego dane wejściowe
w pakiecie Access-Challenge. Ten atrybut używany jest tylko w pakietach Access-Request.
Podczas przesyłania, hasło jest ukryte. Hasło początkowo dopełniane jest znakami
pustymi do końca w celu uzyskania 128 bitowej długości. Następnie dokonywane jest
haszowanie hasła oraz shared secret (hasło klienta) poprzedzonego wartością Request
Authenticator. Haszowanie odbywa się przy użyciu funkcji asymetrycznej MD5 poprzez
wykonanie na tych dwóch strumieniach bitów funkcji XOR [13]. Otrzymana wartość
umieszczana jest w pierwszych 128 bitach pola String atrybutu User-Password.
Jeżeli hasło jest dłuższe niż 16 znaków, wówczas dokonywane jest ponowne
haszowanie przy użyciu funcji MD5. Mieszane jest shared secret (hasło klienta) poprzedzone
rezultatem poprzedniego haszowania z kolejnymi 16 bajtami hasła. Wynik umieszczany jest
w kolejnych 128 bajtach pola String atrybutu User-Password.
Jeżeli zajdzie potrzeba, operacja jak powyżej jest powtarzana. Hasła nie mogą być
jednak dłuższe niż 128 znaków.
Poniżej znajduje się bardziej szczegółowy wyjaśnienie powyższej metody.
Niech S oznacza shared secret, natomiast pseudo losowa 128 bitowa wartość Request
Authenticator oznaczona zostanie jako RA. Niech każde 16 bajtów hasła oznaczone zostanie
przez p1, p2, itd. Ostatni bajt zostaje dopełniony wartościami pustymi do pełnej wartości.
Bloki cyfrowo-tekstowe oznaczone zostaną poprzez: c(1), c(2), itd. Oraz pewne wartości
pomocnicze oznaczone zostaną jako b1, b2, itd. Poniżej przedstawiony został proces
haszowania.

b1 = MD5(S + RA) to c(1) = p1 xor b1

b2 = MD5(S + c(1)) to c(2) = p2 xor b2
.
.
.
bi = MD5(S + c(i-1)) to c(i) = pi xor bi

Pole String będzie ostatecznie zawierało sklejone ze sobą wartości:

c(1)+c(2)+...+c(i)

Aby otrzymać wartość oryginalną hasła, proces jest odwracany. [5]

4.3. CHAP-Password
Atrybut używany tylko w pakietach Access-Request. Zawiera on wykorzystywaną
przez protokół PPP metodę autentykacji - Challenge-Handshake Authentication Protocol
(CHAP). [5]

4.4. NAS-IP-Address
Jest to adres IP urządzenia dostępowego NAS, które odpytuje RADIUS serwer w celu
dokonania autentykacji użytkowników. Adres powinien być unikalny dla serwera RADIUS.
Atrybut konieczny jest w pakiecie Access-Request.

27
 Adres IP urządzenia dostępowego nie jest konieczny do wydobycia z pakietu hasła
shared secret, konieczny jest natomiast adres źródłowy, z którego pochodzi pakiet Access-
Request. [5]

4.5. NAS-Port
Atrybut określający fizyczny numer portu urządzenia NAS, do którego dostęp chce
uzyskać użytkownik. Zarówno atrybut NAS-Port lub NAS-Port-Type lub jednocześnie oba
powinny być obecne w pakiecie Access-Request. [5]

4.6. Service-Type
Atrybut dostarcza informacji o usługach do jakich dostęp chce uzyskać użytkownik
lub o usługach jakie zostaną dostarczone użytkownikowi. Może być użyty w pakietach
Access-Request i Access-Accept. W przypadku, gdy NAS nie rozpoznaje danej usługi o jaką
prosi użytkownik, wówczas użytkownik otrzyma odpowiedź Access-Reject.
Pole Value atrybutu Service-Type określa jakie usługi możemy wykorzystać. Poniższa
tabela przedstawia możliwe wartości pola Value. [5]

Wartość Usługa
1 Login
2 Framed
3 Callback Login
4 Callback Framed
5 Outbound
6 Administrative
7 NAS Prompt
8 Authenticate Only
9 Callback NAS Prompt
10 Call Check
11 Callback Administrative

Objaśnienie powyższych usług.

Login Użytkownik chce uzyskać połączenie do hosta.
Framed Użytkownik chce skorzystać z protokołu typu Framed Protocol, takiego
jak np. PPP or SLIP.
Callback Login Użytkownik powinien zostać rozłączony, następnie otrzymać połączenie
zwrotne od hosta.
Callback Użytkownik powinien zostać rozłączony, następnie otrzymać połączenie
Framed zwrotne od hosta. Wykorzystywane są w połączeniu protokoły takie jak
PPP czy SLIP.
Outbound Użytkownik powinien uzyskać dostęp do urządzeń zewnętrznych.
Administrative Użytkownik powinien uzyskać dostęp do interfejsu urządzenia NAS, z
którego będzie mógł wykonywać polecenia administracyjne.
NAS Prompt Użytkownik otrzyma dostęp do konsoli. Nie ma możliwości wykonywania
poleceń administracyjnych.
Authenticate Prośba użytkownika tylko o autentykację, dane autoryzacyjne nie będą
Only przesyłane w pakiecie Access-Accept. Usługa ta wykorzystywana jest w
przypadku serwera proxy.

28
Callback NAS Użytkownik powinien zostać rozłączony, następnie otrzymać połączenie
zwrotne od hosta, uzyskując dostęp do konsoli, skąd nie będzie mógł
wykonywać poleceń administracyjnych.
Call Check Używane przez NAS w celu sprawdzenia czy połączenie z RADIUS
serewerem zostało nawiązane. RADIUS powinien przesłać Access-Accept
w przypadku nawiązania połączenia lub Access-Reject jeśli połączenie
zostało odrzucone. Usługa ta opiera się o atrybuty Called-Station-ID oraz
Calling-Station-Id. W zapytaniach Access-Request, w których występuje ta
usługa, zamiast User-Name powinien zostać użyty atrybut Calling-Station-
Id.
Callback Użytkownik powinien zostać rozłączony, następnie otrzymać połączenie
Administrative zwrotne od hosta, uzyskując dostęp do interfejsu NAS, skąd będzie mógł
wykonywać polecenia administracyjne.

4.7. Framed-Protocol
Ten atrybut określa protokół jaki ma zostać użyty podczas połączenia
wykorzystującego rodzinę protokołów Framed-Protocol. Może być użyty w pakietach
Access-Request i Access-Accept.
Wartości jakich możemy użyć w przypadku tego atrybutu porzedstawione są poniżej.

Wartość Odpowiadający protokół Framed Protocol

1 PPP
2 SLIP
3 AppleTalk Remote Access Protocol (ARAP)
4 Gandalf proprietary SingleLink/MultiLink protocol
5 Xylogics proprietary IPX/SLIP
6 X.75 Synchronous

4.8. Framed-IP-Address
Ten atrybut określa adres IP jaki uzyska użytkownik po udanej autentykacji. Może
wystąpić on w pakietach Access-Accept. Może zostać użyty jako wskazówka dla RADIUS
serwera w pakiecie Access-Request, która mówiłaby RADIUS serwerowi, który adres byłby
najlepszy dla danego NAS. RADIUS może jednak pominąć tę wskazówkę. [5]

4.9. Framed-IP-Netmask
Atrybut określający adres IP maski sieciowej przydzielany użytkownikowi, który
może być np. routerem w naszej sieci. Atrybut ten może zostać użyty w pkietach Access-
Accept. Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-
Request, która mówiłaby RADIUS serwerowi, który adres sieci byłby najlepszy dla danego
NAS. RADIUS może jednak pominąć tę wskazówkę. [5]

4.10. Framed-Routing
Atrybut określa metodę trasowania dla użytkownika, w przypadku gdy użytkownik
jest routerem w naszej sieci. Używany tylko w pakietach Access-Accept.

29
 Wartości jakie mogą wystąpić w tym atrybucie są następujące. [5]

Wartość Opis wartości

0 Bez routingu
1 Wysyłanie pakietów routingu
2 Nasłuchiwanie pakietów routingu
3 Wysyłanie i nasłuchiwanie pakietów routingu

4.11. Filter-Id
Atrybut identyfikujący filtr dla użytkownika. Zero lub więcej atrybutów Filter-Id
może zostać przesłanych w pakiecie Access-Accept.
Identyfikacja filtrów przy użyciu nazwy pozwala na przenoszenie różnych filtrów
pomiędzy różnymi urządzeniami NAS bez potrzeby dodatkowej konfiguracji. [5]

4.12. Framed-MTU
Atrybut określa rozmiar MTU (Maximum Transmission Unit) dla użytkownika, jeśli
nie jest on określany przez inny mechanizm np. PPP [14]. Używany w pakietach Access-
Accept. Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-
Request, która mówiłaby RADIUS serwerowi, jaka wartość byłby najlepszy dla danego NAS.
RADIUS może jednak zignorować tę wskazówkę. [5]

4.13. Framed-Compression
Atrybut określa protokół kompresji jaki zostanie użyty w połączeniu. Atrybut może
zostać użyty w pakietach Access-Accept.
Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-Request,
która mówi RADIUS serwerowi, jaka kompresja byłaby najlepsza dla danego NAS. RADIUS
może jednak pominąć tę wskazówkę.
Można zadeklarować więcej niż jeden protokół kompresji. Zadaniem NAS jest
natomiast dobór odpowiedniego protokołu kompresji w zależności od ruchu w sieci.
Następujące wartości mogą zostać użyte w tym atrybucie. [5]

Wartość Kompresja
0 Bez kompresji
1 VJ TCP/IP header compression [10]
2 IPX header compression
3 Stac-LZS compression

4.14. Login-IP-Host
W przypadku gdy atrybut Login-Service jest obecny w zapytaniu atrybut określa
system, do którego użytkownik próbuje uzyskać połączenie. Może być używany w pakietach
Access-Accept.
Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-Request,
która mówi RADIUS serwerowi jaki system jest preferowany przez dany NAS. RADIUS
może jednak pominąć tę wskazówkę. [5]

30
4.15. Login-Service
Atrybut określający serwis, z którego będzie musiał skorzystać użytkownik chcący
uzyskać połączenie. Używany tylko w pakietach Access-Accept.
Wartości jakie mogą wystąpić w tym atrybucie przedstawione zostały poniżej.

Wartość Rodzaj usługi

0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster
4 LAT
5 X25-PAD
6 X25-T3POS
8 TCP Clear Quiet

4.16. Login-TCP-Port
W przypadku, gdy wykorzystywany jest atrybut Login-Service, możemy przy użyciu
atrybutu Login-TCP-Port ustalić port TCP dla wykorzystywanej przy połączeniu usługi.
Atrybut wykorzystywany dylko w pakietach Access-Accept. [5]

4.17. Nieprzypisany
Typ 17 nie ma przypisanego atrybutu. [5]

4.18. Reply-Message
Atrybut w którym zawarta jest wiadomość, którą możemy przesłać do użytkownika.
Użyta w pakiecie Access-Accept, informuje o udanej autentykacji. Użyta w pakiecie Access-
Reject, informuje o nieudanej autentykacji. Może także zostać wywołany znak zachęty dla
użytkownika, w celu poprawienia danych autentykacyjnych, zanim klient wystosuje kolejne
zapytanie Access-Request do RADIUS serwera.
Użyty w pakiecie Access-Challenge, może oznaczać zachętę dla użytkownika do
odpowiedzi na zapytanie.
Można użyć wielokrotnej odpowiedzi. Muszą one pojawiać się w tej samej kolejności
w jakiej pojawiają się w pakiecie. [5]

4.19. Callback-Number
Określa numer połączenia telefonicznego, który zostanie użyty w celu nawiązania
połączenia zwrotnego.
Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-Request
o wymaganym połączeniu zwrotnym. RADIUS może jednak zignorować tę wskazówkę. [5]

31
4.20. Callback-Id
Identyfikuje punkt, do którego ma zostać wykonane połączenie zwrotne.
Wykorzystywany jest przez NAS. Może być użyty w pakietach Access-Accept. [5]

4.21. Nieprzypisany.
Typ 17 nie ma przypisanego atrybutu. [5]

4.22. Framed-Route
Atrybut wprowadza informacje o routingu dla NAS, aby mogło ono skonfigurować
routing dla użytkownika. Używany w pakietach Access-Accept może być używany
wielokrotnie. [5]

4.23. Framed-IPX-Network
Identyfikuje on numer sieci IPX. Używany w pakietach Access-Accept w celu
konfiguracji interfejsu siciowego użytkownika. [5]

4.24. State
Atrybut ten przesyłany jest przez serwer do klienta w pakiecie Access-Challenge. Nie
może ulec modyfikacji podczas przesyłania go przez klienta do serwera w nowym pakiecie
Access-Request w odpowiedzi na pakiet Access-Challenge.
Przesyłany jest on także klientowi przez serwer w pakiecie Access-Accept, który
zawiera także atrybut Termination-Action z wartością RADIUS-Request. Jeśli NAS wykona
Termination-Action wysyłając nowy Access-Request przed zerwaniem aktualnej sesji, musi
zachować atrybut State w niezmienionej formie.
Klient nie musi interpretować atrybutu lokalnie. Pakiet może zawierać tylko jeden
atrybut State lub żadnego. [5]

4.25. Class
Ten atrybut przesyłany jest do klienta w pakiecie Access-Accept, wykorzystywany
jest w pakietach Accounting-Request oraz w procesie logowania. [5]

4.26. Vendor-Specific
Atrybut ten pozwala na wykorzystanie dodatkowych atrybutów dostarcznych przez
dostawcę (np. dostawcę urządzeń NAS). Atrybuty te nie mogą mieć wpływu na działanie
protokołu RADIUS.
Serwery nieobsługujące tego typu atrybutu będą ignorowały dodatkowe atrybuty
dostawców. [5]

32
4.27. Session-Timeout
Określa maksymalny czas w sekundach potrzebny na dostarczenie serwisu
użytkownikowi, przed zakończeniem sesji żądania połączenia. Atrybut ten może być obecny
w pakietach Access-Accept lub Access-Challenge. [5]

4.28. Idle-Timeout
Maksymalna liczba sekund, w czasie której użytkownik powinien wpisać swój login i
hasło, w przeciwnym wypadku kolejne zapytanie Access-Request zostanie wysłane, a sesja
żądania połączenia przerwana. Atrybut ten wysyłany jest przez serwer w pakietach Access-
Accept lub Access-Challenge. [5]

4.29. Termination-Action
Ten atrybut określa jaką akcję powinien przeprowadzić NAS, gdy użytkownik uzyska
połączenie. Używany tylko w pakietach Access-Accept.
Dopuszczalne wartości tego atrybutu znajdują się poniżej.

Wartość Akcja
0 Default
1 RADIUS-Request

Jeśli Value ma wartość 1, NAS przed zakończeniem określonej usługi może wysłać do
serwera nowy pakiet Access-Request. Pakiet ten może zawierać atrybut State. [5]

4.30. Called-Station-Id
Atrybut pozwalający NAS wysłać w pakiecie Access-Request numer telefonu jaki
został wybrany przez użytkownika, używając Dialed Number Identification (DNIS) lub
podobnej technologii. Numer ten może być inny od numeru z którego przychodzi żądanie,
atrybut używany jest tylko w pakietach Access-Request. [5]

4.31. Calling-Station-Id
Atrybut pozwala NAS na wysłanie w pakiecie Access-Request numeru telefonu, z
którego przychodzi połączenie, używając Automatic Number Identification (ANI) lub
podobnej technologii. Używany jest tylko w pakietach Access-Request. [5]

4.32. NAS-Identifier
Atrybut identyfikuje urządzenie NAS wysyłające pakiet Access-Request. Używany
tylko w pakietach Access-Request. Zarówno NAS-IP-Address lub NAS-Identifier musi być
przesłany w pakiecie Access-Request.
Należy zauważyć iż atrybut NAS-Identifier nie jest wymagany by serwer uzyskał
shared secret NAS. By serwer mógł uzyskać shared secret z pakietu Access-Request
potrzebny jest mu adres IP z którego pochodzi pakiet Access-Request. [5]

33
4.33. Proxy-State
Atrybut ten przesyłany jest przez serwer proxy do innego serwera podczas przesyłania
pakietu Access-Request. Powinien zostać zwrócony w postaci niezemienionej w pakietach
Access-Accept, Access-Reject i Access-Challenge. Gdy serwer proxy otrzymuje odpowiedź
na swoją odpowiedź, musi usunąć swój własny Proxy-State (Proxy-State z ostatniego pakietu)
przed przesłaniem odpowiedzi do NAS.
Jeżeli atrybut Proxy-State jest dodany do pakietu podczas jego przesyłania, atrybut ten
musi zostać dodany za już istniejącym atrybutem Proxy-State. Kolejne pakiety Proxy-State
opakowują poprzednie. [5]

4.34. Login-LAT-Service.
Atrybut określa system, z którym użytkownik chce się połączyć wykorzystując LAT.
Może zostać użyty w pakietach Access-Accept, ale tylko wówczas, gdy LAT jest określony w
Login-Service.
Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-Request.
RADIUS może jednak pominąć tę wskazówkę.
W przypadku, gdy mamy do czynienia z systemami klastrowymi, gdzie użytkownicy
mogą wykorzystywać zasoby współdzielone, takie jak czas działania procesora, dyski,
drukarki, itp., każdy host informuje o usługach użytkowników wykorzystując rozgłoszenia
LAT, w celu usprawnienia i przyspieszenia działania usług. Czyli generalnie LAT pozwala na
odpowiednie zbalansowanie ruchu w sieci i równomierne wykorzystanie zasobów
sprzętowych. [5]

4.35. Login-LAT-Node
Atrybut określa węzeł do którego użytkownik zostanie automatycznie podłączony
przez LAT. Używany jest w pakietach Access-Accept, lecz tylko jeśli LAT jest określony w
Login-Service. Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-
Request. RADIUS może jednak pominąć tę wskazówkę.

4.36. Login-LAT-Group
Atrybut zawiera informacje o grupie, której prawa chce uzyskać dany użytkownik.
Może zostać użyty w pakietach Access-Accept, lecz tylko jeśli LAT jest określony w Login-
Service. Może zostać użyty jako wskazówka dla RADIUS serwera w pakiecie Access-
Request. RADIUS może jednak pominąć tę wskazówkę.
LAT obsługuje 256 różnych kodów grup, które używane są w celu nadawania praw.
Administrator może skojarzyć jedną lub więcej grup z LAT. [5]

4.37. Framed-AppleTalk-Link
Atrybut identyfikujący numer w przypadku użycia protokołu AppleTalk, który
zostanie użyty w celu połączenia z innym routerem AppleTalk. Używany tylko w pakietach
Access-Accept. Nie jest używany jeśli użytkownikiem nie jest inny router. [5]

34
4.38. Framed-AppleTalk-Network
Atrybut określający numer sieciowy protokołu AppleTalk w celu przydzielenia
użytkownikowi węzła. Używany jest on tylko w pakietach Access-Accept. Nie jest
wykorzystywany w przypadku, gdy użytkownik nie jest routerem. Wielokrotne wystąpienie
tego atrybutu daje możliwość wyboru numeru przez NAS. [5]

4.39. Framed-AppleTalk-Zone
Ten atrybut określa domyślną strefę AppleTalk (Default Zone) dla użytkownika.
Używany jest on w pakietach Access-Accept. Niedopuszczlne jest wielokrotne użycie tego
atrybutu w tym samym pakiecie. [5]

4.40. CHAP-Challenge
Atrybut zawiera CHAP Challenge wysyłane przez NAS do użytkownika
korzystającego z protokołu uwierzytelnienia PPP Challenge-Handshake Authentication
Protocol (CHAP). Używany jest tylko w pakietach Access-Accept.
Jeśli CHAP jest wartością 128 bitową, może zostać użyty jako Request-Authenticator.
[5]

4.41. NAS-Port-Type
Atrybut określający typ portu fizycznego NAS, do którego użtykownik chce uzyskać
dostęp. Może być użyty zamiast (lub dodatkowo) atrybutu NAS-Port. Używany jest tylko w
pakietach Access-Request. Zarówno NAS-Port jak i NAS-Port-Type powinny być używane w
pakietach Access-Request.
Pole wartości jest 32 bitowe. Wartość "Virtual" umożliwia stworzenia wirtualnego
połączenia przy użyciu pewnego protokołu transportowego, zamiast portu fizycznego. Np.
jeśli użytkownik chce skorzystać z telnetu, wówczas pakiet Access-Request może zawierać
NAS-Port-Type=Virtual jako wskazówkę dla RADIUS serwera, że użytkownik ten nie
korzysta z fizycznego portu switcha.
Możliwe do użycia wartości przedstawione zostały poniżej. [5]

Wartość Typ portu NAS

0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual
6 PIAFS
7 HDLC Clear Channel
8 X.25
9 X.75
10 G.3 Fax
11 SDSL - Symmetric DSL
12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation

35
 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
14 IDSL - ISDN Digital Subscriber Line
15 Ethernet
16 xDSL - Digital Subscriber Line of unknown type
17 Cable
18 Wireless - Other
19 Wireless - IEEE 802.11

PIAFS jest fomą bezprzewodowego połączenia ISDN powszechnie używanego w

Japonii i standardem dla PHS (Personal Handyphone System) Internet Access Forum. [5]

4.42. Port-Limit
Atrybut określa maksymalną liczbę portów z jakich może skorzystać dany użytkownik
podłączający się do NAS. Atrybut ten może zostać wysłany do klienta w pakiecie Access-
Accept. Używanay w połączeniach typu PPP. Może być wysłany do serwera przez NAS jako
wskazówka ile portów zostanie użytych, nie musi być jednak honorowana przez serwer. [5]

4.43. Login-LAT-Port
Definiuje port, z którym użytkownik może się połączyć przez LAT. Może być użyty w
pakietach Access-Accept, lecz tylko jeśli LAT jest użyty jako Login-Service. [5]

4.44. Tabela Atrybutów

Tabela pokazuje jakie atrybuty, w jakich ilościach mogą wystąpić w poszczególnych
pakietach.

Pakiety Lp. Atrybut

Request Accept Reject Challenge #
0-1 0-1 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
0-1 0 0 0 3 CHAP-Password [Note 1]
0-1 0 0 0 4 NAS-IP-Address [Note 2]
0-1 0 0 0 5 NAS-Port
0-1 0-1 0 0 6 Service-Type
0-1 0-1 0 0 7 Framed-Protocol
0-1 0-1 0 0 8 Framed-IP-Address
0-1 0-1 0 0 9 Framed-IP-Netmask
0 0-1 0 0 10 Framed-Routing
0 0+ 0 0 11 Filter-Id
0-1 0-1 0 0 12 Framed-MTU
0+ 0+ 0 0 13 Framed-Compression
0+ 0+ 0 0 14 Login-IP-Host
0 0-1 0 0 15 Login-Service
0 0-1 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 18 Reply-Message
0-1 0-1 0 0 19 Callback-Number

36
 0 0-1 0 0 20 Callback-Id
0 0+ 0 0 22 Framed-Route
0 0-1 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 24 State [Note 1]
0 0+ 0 0 25 Class
0+ 0+ 0 0+ 26 Vendor-Specific
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0-1 0 0 0 30 Called-Station-Id
0-1 0 0 0 31 Calling-Station-Id
0-1 0 0 0 32 NAS-Identifier [Note 2]
0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 34 Login-LAT-Service
0-1 0-1 0 0 35 Login-LAT-Node
0-1 0-1 0 0 36 Login-LAT-Group
0 0-1 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 38 Framed-AppleTalk-Network
0 0-1 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 60 CHAP-Challenge
0-1 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 62 Port-Limit
0-1 0-1 0 0 63 Login-LAT-Port
Request Accept Reject Challenge # Attribute

UWAGI
Access-Reques może zawierać atrybut User-Password lub CHAP-Password lub State.
Nie może zawierać jednocześnie obydwu pakietów User-Password i CHAP-Password.
Access-Request musi zawierać atrybut NAS-IP-Address lub NAS-Identifier,
ewentualnie jednocześnie oba.

Objaśniena do tabeli
0 Atrybut nie może wystąpić w pakiecie.
0+ Atrybut może nie wystąpić wogóle lub może wystąpić kilkakrotnie.
0-1 Atrybut może wystąpić raz lub może nie być obecny w pakiecie.
1 Atrybut musi wystąpić dokładnie raz w danym pakiecie.

37
Rozdział 5

Protokół RADIUS Accounting.

Protokół RADIUS Accounting służy do zapisywania informacji o użytkownikach,
próbujących dostać się do zasobów sieci. Protokół ten uruchamiany jest na porcie o numerze
1813. Serwer RADIUS odbiera pakiety "accounting request" i odpowiada klientom wysyłając
pakiet "accounting response", w celu poinformowania ich o poprawnym odebraniu pakietów
accounting request. [6]

5.1 Procesy wykonywane przez RADIUS Accounting serwer.

Poprawnie skonfigurowany klient, podczas rozpoczęcia sejsji, wysyła do RADIUS
serwera pakiet Accounting Start, w którym dostarczane są serwerowi informacje
identyfikujące autentykującego się użytkownika oraz informacje o rodzaju usuługi do jakiej
będzie miał on dostęp. Następnie RADIUS wysyła klientowi potwierdzenie o odebraniu
pakietu Accounting Start. Gdy sesja jest kończona klient wysyła do RADIUS serwera pakiet
Accounting Stop, w którym są zawarte informacje o usłudze z jakiej korzystał użytkownik, a
także czas trwania połączenia. RADIUS serwer odsyła klientowi potwierdzenie otrzymania
pakietu Accounting Stop.
Jeżeli klient nie otrzyma od RADIUS serwera potwierdzenia otrzymania pakietów czy
to Access Start, czy to Access Stop wówczas pakiety te są wysyłane ponownie określoną ilość
razy. Jeśli podstawowy serwer nie odpowiada, wówczas klient może przesłać pakiety do
zapasowego serwera RADIUS.
Jeżeli RADIUS nie jest w stanie poprawnie zapisać pakietów accounting, wówczas nie
wyśle on potwierdzenia Accounting Response. [6]

38
Rozdział 6

Pakiety Accounting RADIUS serwera.

6.1 Rodzaje pakietów Accounting.
Pakiet Accounting jest dokładnie raz dołączany do protokołu UDP. Do transmisji tego
rodzaju pakietów wykorzystywany jest port 1813. Podczas odpowiedzi następuje odwrócenie
portów dla nadawcy i odbiorcy.
Poniższy rysunek przedstawia pakiet Accounting:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Authenticator

Attributes ...

Pole Code jest 8 bitowe i wykorzystywane jest w celu identyfikacji typu pakietu
RADIUSA. Jeżeli nastąpiłby odbiór pakietu z błędnym polem Code, nastąpiłoby odrzucenie
tych danych bez jakichkolwiek komunikatów.
Identyfikator zawarty w polu Code określa jeden z pakietów:
• Accounting-Request - żądanie
• Accounting-Response - odpowiedź
Pole Identifier jest ośmiobitowym polem, pomaga ono w dopasowaniu żądań i
odpowiedzi.
Pole Length ma szesnastobitową długość. Określa ono rozmiar całego przesyłanego
pakietu, czyli: Code, Identifier, Length, Authenticator oraz Attribute.
Dane, które znajdą się poza rozmiarem określonym przez pole Length powinny zostać
zignorowane. Jeżeli natomiast pakiet jest mniejszy niż określony rozmiar, powinno nastąpić
jego odrzucenie bez jakichkolwiek komunikatów ostrzegawczych. Najmniejszy rozmiar
pakietu to 20 bajtów, największy 4096.
Pole Authenticator ma długość 128 bitów. Używane jest w celu autentykacji
informacji przesyłanych pomiędzy RADIUS serwerem, a klientem.
W pakietach Accounting Request, pole Authenticator jest 256 bitową sumą kontrolną i
nazywa się Request Authenticator.
Pole Authenticator w pakietach Accounting Request zawiera następujące dane
połączone ze sobą w jeden strumień bitów: Code + Identifier + Length + 128 bitów zerowych
+ request attributes + shared secret. Dane te są szyfrowane funkcją MD5.
Request Authenticator znajdujący się w Accounting–Request nie może być
zrealizowany w taki sam sposób jak Request Authenticator znajdujący się w RADIUS
Access–Request, ponieważ w Accounting–Request nie jest używane hasło użytkownika.
Pole Authenticator w pakiecie Accounting Response nazywane jest Response
Authenticator. Zawiera ono następujące dane połączone ze sobą w jeden strumień bitów:
Accounting Response Code + Identifier + Length + Request Authenticator pochodzący z
pakietu Accounting Request oraz atrybuty. Wszystkie te dane poprzedzone są shared secret.
Response Authenticator szyfrowany jest przy użyciu funkcji MD5.

39
 Atrybuty mogą mieć różną postać. Powinna zostać zachowana kolejność przesyłania
atrybutów tego samego typu. W przypadku atrybutów różnego typu kolejność ich przesyłania
nie musi być zachowana. [6]

6.2 Pakiet Accounting Request.

Pakiety Accounting-Request wysyłane są przez klienta RADIUS serwera (przeważnie
bezpośrednio po sieci lub poprzez proxy) do RADIUS serwera przenosząc ze sobą pewne
informacje. Informacje te potrzebne są w celu określenia jakie usługi mogą być dostarczone
danemu użytkownikowi. Klient przesyła RADIUSowi pakiety z wartością w polu Code
ustawioną na 4 (Accounting – Request).
W celu potwierdzenia odebrania pakietu Accounting-Request, serwer jako odpowiedź
musi wysłać Accounting-Response, ale tylko w przypadku gdy rekordy pakietu zostały
pomyślnie odebrane. W przypadku gdy rekordy były błędne serwer nie musi nic robić.
Jakikolwiek atrybut używany w pakietach RADIUS Access-Request lub Access-
Accept używany jest w pakiecie RADIUS Accounting-Request. Poza tym następujące
atrybuty nie powinny być prezentowane w Accounting-Request: hasło użytkownika (User-
Password), hasło CHAP (CHAP-Password), odpowiedź (Reply-Message), status (State).
Natomiast adres IP klienta (NAS-IP-Address) czy identyfikator klienta (NAS-Identifier)
powinny zostać zaprezentowane w pakiecie RADIUS Accountin-Request. Powinny być w
nim zawarte także atrybuty NAS-Port lub NAS-Port-Type (ewentualnie obydwa), chyba że
usługa nie wymaga portów lub NAS nie rozróżnia portów.
Budowa pakietu Accounting Request przedstawiona jest poniżej.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Authenticator

Attributes ...

Pole Code ma wartość 4 co oznacza, że wysyłany pakiet jest właśnie pakietem typu
Accounting-Request.
Pole identyfikatora powinno być zmienione zawsze, gdy następuje zmiana zawartości
w polu Attributes. Również gdy nastąpiła uzasadniona odpowiedź na wcześniej odebrane
żądanie. Dla transmisji, w których zawartość przesyłanych danych pakietu nie zmienia się,
pole Identifier nie powinno być zmieniane.
Należy zauważyć, że jeśli atrybut Acct-Delay-Time (określa on opóźnienie) jest
zawarty i ustawiony w atrybutach pakietu Accounting-Request, jego wartość zostanie
uaktualniona po retransmisji pakietu. Gdy nastąpi zmiana zawartości pola Attributes należy
uaktualnić pole Identifier oraz Request Authenticator.
W pakietach Accounting Request, pole Authenticator jest 256 bitową sumą kontrolną i
nazywa się Request Authenticator.
Pole Attributes zawira listę atrybutów pakietu Accounting Request.

40
 6.3 Pakiet Accounting Response.
Pakiety Accounting-Response wysyłane są przez RADIUS serwer do klienta w celu
potwierdzenia odbioru pakietu Accounting-Request. W przypadku zakończonego sukcesem
odczytu i zapisu pakietu Accounting-Request, RADIUS powinien wysłać pakiet o wartości w
polu Code równej 5 (Accounting-Response). Podczas odbioru Accounting-Response przez
klienta, pole Identifier pakietu Accounting-Response porównywane jest z polem aktualnego
Accounting-Request. Błędne pakiety są odrzucane. W pakietach Accounting-Response nie są
konieczne żadne atrybuty.
Budowa pakietu Accounting Response.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Code Identifier Length

Authenticator

Attributes ...

Pole Code ma wartość 5 co oznacza, że wysyłany pakiet jest właśnie pakietem typu
Accounting-Response.
Zawartość pola Identifier jest kopią pola Identifier pakietu, który spowodował
wysłanie Accounting Response czyli kopią pola Identifier z pakietu Accounting-Request.
Response Authenticator zawiera 256 bitową wartość wygenerowaną przy pomocy
funkcji haszującej MD5. Szerszy opis znajduje się w punkcie 2.2.
Pole Attributes może być puste lub zawierać pewne atrybuty. [6]

41
Rozdział 7

Atrybuty występujące w pakietach Access Request

RADIUS serwera.
Poniższa tabela przedstawia zestaw atrybutów dostępnych w pakietach Accounting.

40 Acct-Status-Type
41 Acct-Delay-Time
42 Acct-Input-Octets
43 Acct-Output-Octets
44 Acct-Session-Id
45 Acct-Authentic
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause
50 Acct-Multi-Session-Id
51 Acct-Link-Count
60+ (refer to RADIUS document [5])

Atrybut Acct-Status-Type jest odpowiedzialny za status połączenia. Sygnalizuje on

czy Accounting-Request rozpoczęło właśnie dostarczanie usług użytkownikowi (Start), czy
może właśnie je skończyło (Stop).
Może być on użyty przez klienta w celu zaznaczenia rozpoczęcia logowania sesji,
wtedy ustawiany jest Accounting-On, bądź do zaznaczenia zakończenia logowania (np. po
restarcie maszyny) i ustawienie Accounting-Off.
Budowa atrybutu Acct-Status-Type. Dane transmitowane są od lewej do prawej
strony. [6]
Wartości jakie może przyjmować ten atrybut:

1 Start – rozpoczęcie sesji

2 Stop – koniec sesji
7 Accounting-On – adnotacja o rozpoczęciu rejestracji
8 Accounting-Off – adnotacja o zakończeniu rejestracji

7.1 Acct-Delay-Time
Atrybut określający czas w sekundach, w jakim klient może próbować wysyłać
Accounting-Request. Jeśli odejmiemy ten czas od czasu przybycia pakietu, otrzymamy
przybliżony czas, w którym to zapytanie (Accounting-Request) było wygenerowane (czas
transmisj nie jest w to wliczany).
Należy przypomnieć w tym momencie, że zmiana wartości Acct-Delay-Time
powoduje potrzebę zmiany pola Identifier. [6]

42
7.2 Acct-Input-Octets
Atrybut określa ilość, bajtów jaka została odebrana z portu od czasu rozpoczęcia sesji.
Może być prezentowany tylko w pakietach Accounting-Request, jeśli Acct-Status-Type jest
ustawiony na wartość oznaczającą koniec sesji (Stop). [6]

7.3 Acct-Output-Octets
Atrybut określa ilość bajtów jaka została wysłana do portu od momentu rozpoczęcia
sesji. Może być prezentowany tylko w pakietach Accounting-Request, jeśli Acct-Status-Type
jest ustawiony na wartość oznaczającą koniec sesji (Stop). [6]

7.4 Acct-Session-Id
Atrybut ten to unikalny numer (Accounting ID) wprowadzony w celu łatwego
dopasowania wpisów startu i stopu serwisu w pliku logowania. Start i stop sesji powinny
mieć tan sam Acct-Sessoin-Id.
Zalecane jest by Acct-Session-Id był łańcuchem znakowym ASCII, składającym się z
drukowalnych znaków. [6]

7.5 Acct-Authentic
Atrybut Acct-Authentic może być dołączony w pakiet Accounting-Request, aby
określić sposób w jaki użytkownik został zautentykowany (czy przy użyciu protokołu
RADIUS, czy może tylko przy użyciu klienta NAS, lub może używając jeszcze innego
protokołu autentykacji). [6]
Wartości dostępne w tym atrybucie:

Wartość Protokół autentykacji.

1 RADIUS
2 Local
3 Remote

7.6 Acct-Session-Time
Atrybut określa przez jaki czas (w sekundach) użytkownik korzystał z dostarczonej
mu usługi. Może być prezentowany tylko we wpisach Accounting-Request, gdzie Acct-
Status-Type jest ustawiony na wartość oznaczającą koniec sesji (Stop). [6]

7.8 Acct-Input-Packets
Atrybut określa ilość pakietów jaka została odebrana z portu od momentu rozpoczęcia
sesji. Może być prezentowany tylko we wpisach Accounting-Request, gdzie Acct-Status-Type
jest ustawiony na wartość oznaczającą koniec sesji (Stop). [6]

43
7.9 Acct-Output-Packets
Atrybut określa ilość pakietów jaka została wysłana do portu od momentu rozpoczęcia
sesji dla użytkownika. Może być prezentowany tylko we wpisach Accounting-Request, gdzie
Acct-Status-Type jest ustawiony na wartość oznaczającą koniec sesji (Stop). [6]

7.10 Acct-Terminate-Cause
Atrybut określa sposób przerwania/zakończenia sesji. Może być prezentowany tylko
we wpisach Accounting-Request, gdzie Acct-Status-Type jest ustawiony na wartość
oznaczającą koniec sesji (Stop). [6]
Możliwe wartości występujące w tym atrybucie:

Wartość Sposób przerwania sesji

1 User Request
2 Lost Carrier
3 Lost Service
4 Idle Timeout
5 Session Timeout
6 Admin Reset
7 Admin Reboot
8 Port Error
9 NAS Error
10 NAS Request
11 NAS Reboot
12 Port Unneeded
13 Port Preempted
14 Port Suspended
15 Service Unavailable
16 Callback
17 User Error
18 Host Request

User Request - zakończenie sesji na życzenie użytkownika. Na przykład

wylogowanie się lub zakończenie na podstawie czasu zakończenia fazy sterowania łączem –
LCP - Link Control Phase.
Lost Carrier - sesja zostaje zakończona z powodu zagubienia nośnika informacji.
Oznacza to, że DCD (Data Carrier Detected – sygnał do wykrywania czy łącze nie jest zajęte)
został stracony na porcie.
Lost Service - usługa nie może być dostarczana ponieważ np. połączenie zostało
przerwane przez użytkownika.
Idle Timeout - przekroczenie czasu bezczynności.
Session Timeout - zakończenie czasu przeznaczonego na daną sesję.
Admin Reset - administrator serwera zresetował naszą sesję.
Admin Reboot - administrator serwera kończy dostarczaną usługę np. poprzez reboot
klienta NAS.
Port Terror - NAS wykrył błąd na porcie, który wymaga zakończenia sesji.
NAS Terror - NAS wykrył jakiś błąd (inny niż błąd związany z portem), który
wymaga zakończenia sesji.

44
 NAS Request - NAS kończy sesję z innych przyczyn niż błąd.
NAS Reboot - NAS kończy sesję ponieważ nastąpił jego reboot. Nie jest to reboot
wykonany przez administratora, wynika on z przyczyn technicznych.
Port Unneeded - NAS kończy sesję ponieważ zużycie zasobów spadło poniżej
pewnego progu (np. jeżeli algorytm szerokości 'pasma na żądanie' zdecyduje, że port nie jest
już dłużej potrzebny).
Port Preempted - NAS kończy sesję, gdyż zaszła potrzeba alokacji portu dla usługi o
wyższym priorytecie.
Port Suspended - NAS kończy sesję poprzez jej zawieszenie
Service Unavailable - NAS nie jest zdolny dostarczyć żądanej usługi
Callback - NAS kończy aktualną sesję na rzecz rozpoczęcia nowej sesji
User Error - Dane wejściowe użytkownika są błędne, co powoduje zakończenie sesji
Host Request - Sesja kończy się na życzenie hosta. [6]

7.11 Acct-Multi-Session-Id
Atrybut Acct-Multi-Session-Id jest unikalnym identyfikatorem (Accounting ID).
Wprowadzany jest w celu łatwego połączenia powiązanych w pewien sposób wielu sesji w
pliku logowania. Wszystkie sesje połączone ze sobą mają unikalny (każda swój) identyfikator
Acct-Session-Id, ale ten sam identyfikator Acct-Multi-Session-Id. Zalecane jest by Acct-
Multi-Session-Id był łańcuchem drukowalnych znaków ASCII. [6]

7.12 Acct-Link-Count
Podczas generowania wpisów o rozpoczęciu sesji, znane są pewne powiązania
pomiędzy sesjami – linki. Służyć one będą w celu stworzenia wielu sesji połączonych ze
sobą.
Atrybut Acct-Link-Count dostarcza liczbę tych linków które będą służyć w celu
stworzenia multisesji połączonych ze sobą.
Rozmiar pola Value tego atrybutu jest 32 bitowy, zawiera liczbę linków
wykorzystywanych w aktualnej Multilink Sessions.
Dzięki temu atrybutowi serwer RADIUS wie kiedy ma dostarczyć wszystkie
wymagane linki dla sesji Multilink Session. Gdy liczba odebranych pokietów Accounting-
Requests, które mają ustawiony atrybut Acct-Status-Type = Stop i tych samych
identyfikatorów Acct-Multi-Session-Id oraz unikalnych identyfikatorów Acct-Session-Id jest
równa największej liczbie Acct-Link-Count otrzymanej w Accounting-Requests, wówczas
wszystkie zatrzymane (Stop) Accounting-Requests dla danej Multilink Session zostają
odebrane.
Poniższy przykład przedstawia 8 Accounting-Requests.
Dla lepszej przejrzystości przykładu przedstawiono tylko istotne atrybuty, ale
oczywiście dodatkowe potrzebne atrybuty niosące ze sobą informacje potrzebne do
rozpoczęcia sesji również są prezentowane w Accounting-Request. [6]

Multi-Session-Id Session-Id Session-Type Link-Count

10 10 Start 1
10 11 Start 2
10 11 Stop 2
10 12 Start 3
10 13 Start 4

45
 10 12 Stop 4
10 13 Stop 4
10 10 Stop 4

7.13 Tabela atrybutów

Następująca tabela pokazuje, które atrybuty mogą się znaleźć w pakiecie Accounting-
Request. W pakiecie Accounting Response nie powinno być żadnych atrybutów oprócz
Proxy-Stat. [6]

Ilość Atrybuty
0-1 User-Name
0 User-Password
0 CHAP-Password
0-1 NAS-IP-Address
0-1 NAS-Port
0-1 Service-Type
0-1 Framed-Protocol
0-1 Framed-IP-Address
0-1 Framed-IP-Netmask
0-1 Framed-Routing
0+ Filter-Id
0-1 Framed-MTU
0+ Framed-Compression
0+ Login-IP-Host
0-1 Login-Service
0-1 Login-TCP-Port
0 Reply-Message
0-1 Callback-Number
0-1 Callback-Id
0+ Framed-Route
0-1 Framed-IPX-Network
0 State
0+ Class
0+ Vendor-Specific
0-1 Session-Timeout
0-1 Idle-Timeout
0-1 Termination-Action
0-1 Called-Station-Id
0-1 Calling-Station-Id
0-1 NAS-Identifier [4]
0+ Proxy-State
0-1 Login-LAT-Service
0-1 Login-LAT-Node
0-1 Login-LAT-Group
0-1 Framed-AppleTalk-Link
0-1 Framed-AppleTalk-
Network

46
 0-1 Framed-AppleTalk-Zone
1 Acct-Status-Type
0-1 Acct-Delay-Time
0-1 Acct-Input-Octets
0-1 Acct-Output-Octets
1 Acct-Session-Id
0-1 Acct-Authentic
0-1 Acct-Session-Time
0-1 Acct-Input-Packets
0-1 Acct-Output-Packets
0-1 Acct-Terminate-Cause
0+ Acct-Multi-Session-Id
0+ Acct-Link-Count
0 CHAP-Challenge
0-1 NAS-Port-Type
0-1 Port-Limit
0-1 Login-LAT-Port

Accounting-Request powinien zawierać jakikolwiek NAS-IP-Address,

lub NAS-Identifier. Dozwolone jest by zawierał oba te atrybuty. [6]
Objaśnienia wartości występujących w powyższej tabeli:

0 atrybut nie powinien wystąpić

0+ może wystąpić zero lub więcej instancji atrybutu
0-1 może wystąpić zero lub jedna instancja atrybutu
1 musi wystąpić dokładnie jeden taki atrybut

47
Rozdział 8

Architektura serwera RADIUS.

Implementację serwera RADIUS oparłem o darmowe oprogramowanie FreeRADIUS,
które można pobrać na stronie www.freeradius.org, dlatego ten rozdział będzie
przewodnikiem po strukturze katalogów serwera FreeRADIUS. Należy tutaj zaznaczyć, że
budowa innych implementacji serwera RADIUS jest bardzo podobna. W przypadku
jakichkolwiek różnic należy odwołać się do dokumentacji implementacji jaką instalujemy.

8.1 Serwer RADIUS, struktura katalogów.

Katalogiem instalacyjnym serwera jest katalog "path/radius", gdzie path oznacza
ścieżkę prowadzącą do katalogu docelowego radius. Poniższe drzewo katalogowe
przedstawia strukturę serwera RADIUS.

48
 Katalog bin zawiera pliki wykonywalne. Są to narzędzia wspomagające
administrowanie RADIUS serwerem.

8.1.1 radclient
Narzędzie radclient jest programem pozwalającym wysłać do RADIUS serwera pakiet
testowy. Następnie wyświetla odpowiedź serwera. Używany jest w celu testowania zmian
jakie wykonaliśmy w konfiguracji serwera lub by sprawdzić czy serwer jest uruchomiony.
Przy użyciu tego narzędzia możemy przesyłać do serwera atrybuty jakie przesyłane są
podczas normalnej komunikacji klienta z serwerem. Atrybuty te można umieścić w pliku lub
podać z linii poleceń. Skrypt używając słownika koduje pary atrybut/wartość i przesyła je do
serwera.
Składnia polecenia jest następująca:

radclient [opcje] serwer[:port] <polecenie> [<secret>]

Dostępne opcje:

Opcja Opis
-c count Każdy pakiet zostaje wysłany count ilość
razy.
-d raddb_directory Katalog zawierający pliki konfiguracyjne
RADIUS serwera. Domyślnie jest to
etc/raddb.
-f file Plik z atrybutami i ich wartościami. Jeśli nie
podamy tego pliku wówczas atrybuty
czytane są z linii poleceń.
-i id Wymuszenie identyfikatora ID sesji.
-n num_request_per_second Pozwala określić ile zapytań w ciągu
sekundy zostanie wysłane do serwera.
Domyślnie pakiety są wysyłane tak szybko
jak to możliwe. Opcja pozwala spowolnić
wysyłanie pakietów przez radclient.
-p num_requests_in_parallel Pakiety wysyłane są równolegle. radclient
nie czeka na odpowiedź serwera na każdy
pakiet. Domyślnie radclient wysyła pakiet,
następnie czeka na odpowiedź od serwera na
dany pakiet.
-q Tryb pracy cichej.
-r num_retries Opcja określająca ile razy dany pakiet ma
zostać wysłany do serwera. Domyślnie jest to
10 razy.
-s Wyświetlenie podsumowania o pakietach
wysłanych i odebranych.
-S shared_secret_file Określenie pliku, z którego ma zostać
odczytane hasło shared secret.
-t timeout Ilość czasu w sekundach jaką dajemy
klientowi NAS na odpowiedź, następnie
ponowione zostaje przesłanie pakietu.
Domyślnie jest to 3 sekundy.

49
-v Wyświetla informacje o wersji
-x Tryb debug.

serwer[:port]
Jest to nazwa zdalnego hosta lub jego adres IP, na którym uruchomiony jest RADIUS
serwer. Opcjonalnie możemy podać port UDP. Jeśli nie podamy numeru portu, wówczas w
/etc/services szukana jest usługa radacct oraz radius. Jeśli usługa nie została dodana do
/etc/services wówczas zostaną użyte porty 1813 oraz 1812
polecenie
Do wyboru mamy następujące polecenia: acct, auth, status, disconnect. Polecenie acct
wysyła pakiet Access-Request, auth wysyła pakiet Accounting-Request, status wysyła pakiet
Status-Server, disconnect wysyła pakiet rozłączenia.
secret
Jest to shared secret klienta.
Przykłady użycia polecenia radclient:

radius# echo "User-Name = user" | ./radclient -s 192.168.30.66 12

testing123

radclient: no response from server for ID 141

Total approved auths: 0

Total denied auths: 0
Total lost auths: 1

radius# echo "User-Name = user" | ./radclient -s -x 192.168.30.66 12

testing123
Sending Status-Server of id 188 to 192.168.30.66:1812
User-Name = "user"
Re-sending Status-Server of id 188 to 192.168.30.66:1812
User-Name = "user"
Re-sending Status-Server of id 188 to 192.168.30.66:1812
User-Name = "user"
radclient: no response from server for ID 188

Total approved auths: 0

Total denied auths: 0
Total lost auths: 1

8.1.2 radeapclient
Kolejnym pożytecznym narzędziem jest radeapclient. Służy ono do wysyłania
pakietów EAP do RADIUS serwera. Jest to prawie identyczne narzędzie jak radclient.
Różnica polega na obsłudze pakietu EAP-MD5. Dostępne atrybuty to EAP-Identity (pozwala
tworzyć wiadomość EAP Identity) oraz EAP-MD5-Password (używany w celu odpowiedzi na
MD5 challenge).
Składnia tego polecenia jest następująca

radeapclient [-d raddb_directory] [-f file] [-i source_ip]

[-xy] server {acct|auth} secret

50
 Narzędzie radclient jest programem pozwalającym wysłać do RADIUS serwera pakiet
testowy. Następnie wyświetla odpowiedź serwera. Używany jest w celu testowania zmian
jakie wykonaliśmy w konfiguracji serwera lub by sprawdzić czy serwer jest uruchomiony.

Przykład użycia polecenia:

lila# radeapclient -x localhost auth testing123 < file

Gdzie file może zawierać przykładowe informacjie:

User-Name = "user"
EAP-MD5-Password = "haslo"
NAS-IP-Address = adres.przyklad.domena
EAP-Code = Response
EAP-Id = 210
EAP-Type-Identity = "user"
Message-Authenticator = 0x00
NAS-Port = 0

8.1.3 radlast
To polecenie z kolei pozwala wyświetlić informacje skąd odbyło się ostatnie
logowanie do RADIUS serwera. Informacje odczytuje z pliku radwtmp.
Składnia polecenia:

radlast [options]

Opcje jakich możemy tu użyć są takiej jak w przypadku unixowego polecenia last.

8.1.4 radrelay
Polecenie służy do skopiowania logów na inny serwer RADIUS. Narzędzie radrelay
odczytuje plik logów, rekonstruuje na jego podstawie pakiety i przesyła je do zdalengo serwra
RADIUS. W przypadku napotkania końca pliku radrelay czeka, aż kolejna porcja danych
zostanie dopisana do pliku. Następnie przesyła te nowe dane do zdalnego serwera RADIUS.
Składnia polecenia:

radrelay [-a accounting_dir] [-d radius_dir] [-f] [-i source_ip]

[-n shortname] [-r remote-server[:port]] [-s secret]
[-S secret_file] [-x] detailfile

Opcja Opis
-a accounting_directory Pozwala określić katalog, w którym
przechowywane są pliki logowań.
-d radius_directory Podstawowy katalog konfiguracyjny
RADIUS serwera (raddb)
-f Uruchomienie radrelay jako demona
-i source_ip Adres IP serwera, z którego będziemy
przesyłać logi (serwer źródłowy).
-n shortname Pozwala na podanie nazwy skrótowej klienta
RADIUS serwera. Opcji nie należy używać

51
 razem z opcjami –r, -s, -S.
-r remote_server Pozwala określić adres serwera docelowego.
Opcjonalnie możemy podać numer portu
protokołu UDP.
-s secret Hasło serwera zdalnego.
-S secret_file Pozwala odczytać hasło serwera zdalnego z
pliku.
-x Tryb debug.
detailfile Plik logów, który będzie przesyłany do
serwera zdalnego.

8.1.5 radsqlrelay.
Narzędzie to pozwala umieścić plik logów SQL na serwerze bazy danych. Używane w
celu skopiowania logów do bazy danych.
Aby móc używać tego narzędzia należy skonfigurować RADIUS serwer by mógł
tworzyć pliki logów w odpowiednim dla SQL formacie.
Składnia polecenia:

radsqlrelay [-d sql_driver] [-b database] [-h host] [-u user]

[-p password] [-1] file_path

Opcja Opis
-d sql_driver Sterownik bazy danych, np. mysql.
-b database Nazwa bazy danych.
-h host Nazwa serwera bazy danych.
-u user Właściciel bazy danych.
-p password Hasło w celu połączenia z bazą danych.
-i Przesłanie pliku do bazy danych i wyjście.
file_path Lokalizacja pliku logów SQL.

8.1.6 radclient radtest.

Przy użyciu tego narzędzia możemy wysłać pakiet testowy do RADIUS. Jest prostym
i szybkim sposobem testowania RADIUS serwera.
Skłania polecenia:
radtest [-d raddb_directory] user password radius-server
nas-port-number secret [ppphint] [nasname]

Opcja Opis
-d raddb_directory Katalog przechowujący słownik RADIUS
serwera.
user Login użytkownika.
password Hasło użytkownika.
radius-server Adres IP lub nazwa serwera RADIUS.
nas-port-number NAS-Port. Może przyjmować wartości od 0
do 2^31. W rzeczywistości nie ma znaczenia
co tu umieścimy.
secret Shared secret (hasło klienta).

52
ppphint Umieszczając tu wartość większą od 0
spowodujemy dołączenie atrybutu Framed-
Protocol = PPP do pakietu testowego.
nasname Umieszczenie tej opcji powoduje rozwinięcie
jej na adres IP i dodanie go do pakietu
request jako atrybutu NAS-IP-ADDRESS.

8.1.7 radclient radwho.

Polecenie radwho wyświetla zalogowanych właśnie użytkowników. Informacje o
aktualnej sesji przechowywane są w pliku radius_path/var/log/radius/radutmp.
Składnia polecenia:

radwho [-c] [-d raddb_directory] [-f] [-i] [-n]

[-N nas_ip_address] [-p] [-P nas_port]
[-r] [-R] [-s] [-S] [-u user] [-U user] [-Z]

Opcja Opis
-c Zamiast nazwy klienta wyświetlony zostanie
jego ID.
-d raddb_directory Katalog zawierający pliki konfiguracyjne
serwera. Domyślnie jest to /etc/raddb.
-f Powoduje, że radwho będzie się zachowywał
jak demon fingerd. Tzn. na bieżąco będą
wyświetlane logowania klientów.
-i Wyświetlony zostanie ID sesji zamiast jej
nazwy.
-n Domyślnie radwho pobiera informacje o
użytkowniku z pliku systemowego passwd.
Opcja –n zapobiega tej operacji.
-N nas_ip_address Wyświetlenie tylko tych klientów, którzy
mają adres IP taki jak nas_ip_address.
-p Dodanie dodatkowej kolumny do typu portu.
-P nas_port Wyświetlenie tylko tych klientów, których
mają NAS port taki jak nas_port.
-r Wyświetla dane bez formatowania,
oddzielając poszczególne pola przecinkami.
-R Wyświetla szczegółowe informacje.
-s Wyświetla pełną nazwę użytkownika.
-S Wyświetla informacje tylko o użytkownikach
używających protokołów PPP lub SLIP.
-u user Wyświetla tylko informacje dotyczące
użytkownika user.
-Z W połączeniu z opcją –R pozwala na
wybranie zawartości pakietów Accounting-
Request

53
Przykład użycia:

radius# ./radwho
Login Name What TTY When From Location
a3Com a3Com shell S0 Mon 17:09 192.168.3

8.1.8 radzap
Narzędzie to używane jest w celu usuwania z pliku radutmp, w którym
przechowywane są informacje o zalogowanych użytkownikach, błędnych wpisów.

Składnia polecenia.

radzap [-d raddb_directory] [-N nas_ip_address]

[-P nas_port] [-u user] [-U user] server[:port] secret

Opcja Opis
-d raddb_directory Katalog, w którym znajduje się plik
konfiguracyjny RADIUS serwera. radzap
odczytuje lokalizację pliku radutmp z pliku
radiusd.conf.
-N nas_ip_address Usunięcie wpisów zawierających adres IP
klienta nas_ip_address.
-P nas_port Usunięcie wpisów zawierających port klienta
nas_port.
-u user Usunięcie wpisów zawierających
użytkowników o loginie user. Wielkość
znaków nie ma znaczenia.
-U user Usunięcie wpisów zawierających
użytkowników o loginie user. Wielkość
znaków ma znaczenie.
server[:port] Nazwa lub adres IP serwera zdalnego.
Opcjonalnie można podać także port UDP.
Domyślne porty to 1812 i 1813, jeżeli nie
zdefiniowaliśmy innych w /etc/services
secret Hasło klienta RADIUS serwera.

8.1.9 radiusd
Katalog sbin zawiera pliki wykonywalne związane z uruchomieniem samego serwera
radius. Znajduje się tu demon RADIUS serwera, narzędzia sprawdzające poprawność
konfiguracji serwera oraz skrypt startowy serwera.
radiusd jest demonem RADIUS serwera.
Składnia uruchomienia demona jest następująca:

radiusd [-A] [-S] [-a accounting_directory] [-b] [-c]

[-d config_directory] [-f] [-i ip-address]
[-l log_directory] [-g facility] [-p port] [-s]
[-v] [-x] [-X] [-y] [-z]

54
Opcja Opis
-A Pozwala na zapisywanie szczegółowych
informacji pochodzących z zapytania
Authentication-Request.
Informacje zapisywane są w pliku detail.auth.
Opcja przydatna jest w celu testowania serwera.
W czasie normalnej pracy nie jest zalecana.
-S W pliku logów zapisywany jest login
użytkownika.
-a accounting_directory Opcja pozwala na zdefiniowanie lokalizacji
szczegółowych plików logów. Domyślnie pliki te
znajdują się w katalogu
radius_path/var/log/radacct/terminal_server/detail.
-l login_directory Lokalizacja pliku logów. W pliku tym zapisywana
jest krótka informacja o użytkowniku, który
zalogował się do sieci. Domyślnie plik ten
znajduje się w radius_path/var/log/radius.log.
Zamiast pliku można podać urządzenie
standardowego wyjścia lub błędów.
-g Definiuje obiekt możliwy do użycia w przypadku
użycia opcji –l z argumentem syslog. Domyślnie
jest to deamon.
-d config_directory Lokalizacja plików konfiguracyjnych RADIUS-a.
Domyślnie jest to radius_path/etc/raddb.
-i ip-address Pozwala zdefiniować adres IP, na który serwer
będzie odbierał zapytania, i z którego serwer
będzie wysyłał odpowiedzi. Opcja przydatna w
przypadku, gdy jednemu interfejsowi sieciowymi
przyporządkowano kilka adresów IP.
-b Jeśli RADIUS został skompilowany z
rozszerzeniem dbm, opcja ta mówi mu, by w celu
uzyskania informacji o użytkownikach, zamiast
pliku users wykorzystywał bazę danych.
-c Opcja pozwala na przechowywanie loginów i
haseł użytkowników w pamięci pod postacią
tabeli. Opcja ta sprawia, że RADIUS
wykorzystuje trochę więcej pamięci, lecz dostęp
do informacji o użytkownikach jest szybszy.
-f Uruchomienie RADIUS-a jako procesu
pierwszoplanowego.
-p port Opcja pozwala na zdefiniowanie portów
RADIUS-a innych niż domyślne.
-s Uruchomienie serwera w trybie single server.
Domyślnie serwer uruchamiany jest w trybie
wielowątkowym co powoduje trochę wolniejsze
odpowiadanie na zapytania.
-v Wyświetla wersję serwera.
-x Tryb debuggera. Opcja często używana w
połączeniu z opcją –s. Opcję można użyć
dwukrotnie by dbugowanie było dokładniejsze.

55
-X Rozszerzony tryb debuggera. Podobny tryb
można uzyskać używając opcji – sfxx.
-y Wypisuje szeczgóły o wszystkich autentykacjach
z pliku radius.log.
-z Zapisywanie haseł użytkowników w pliku
radius.log.

Demon radiusd korzysta z wielu plików konfiguracyjnych. Poniżej przedstawiam

krótki opis tych plików.
Plik radiusd.conf jest głównym plikiem konfiguracyjnym.
Plik dictionary zawiera definicje wszystkich możliwych do użycia atrybutów. Pliku
tego nie należy modyfikować. Można także dodawać własne definicje atrybutów.
Plik clients zawiera adresy IP oraz hasła wszystkich klientów mogących wysyłać
zapytania do RADIUS serwera.
Plik naslist zawiera listę NAS (Network Access Server). Plik ten nie jest już używany,
podobnie jak plik clients. Oba pliki zostały zastąpione przez plik clients.conf.
Plik clients.conf zawiera informację o klientach. Ich adresy IP, hasła, nazwy skrótowe.
W pliku hints można zdefiniować pewne reguły opierające się tylko na loginie
użytkownika lub innych atrybutach przesyłanych przez access server. Zapytanie jest
odczytywane, a następnie dodawane są atrybuty w zależności od tego co znalazło się w
zapytaniu. Przykładowo użytkownikowi o loginie "kowalski.ppp" zostaje przyporządkowane
połączenie oparte o protokół PPP, pomimo że NAS nie prosił serwera o takie połączenie. Plik
hints użyty został właśnie w tym celu, by dodać do zapytania atrybut odpowiadający za
połączenie PPP. Do loginu użytkownika możemy dodawać zarówno przedrostki jak i
przyrostki, definiujące połączenie o jakie będzie prosił użytkownik.
Plik users zawiera wpisy dotyczące użytkowników i ich haseł. Zawiera także definicje
DEFAULT oznaczające, że użytkownicy zostaną odczytani z pliku /etc/passwd. Dodatkowe
informacje dla sesji użytkowników DEFAULT czytane są z pliku hints.
Inne pliki znajdujące się w katalogu radius_path/sbin to check-radiusd-config. Jest to
narzędzie, które sprawdza poprawność plików konfiguracyjnych servera. Po dokonaniu zmian
w jakimkolwiek pliku serwera, warto przetestować dokonane zmiany właśnie tym
narzędziem.
Plik radwatch jest skryptem startującym serwer i czuwającym nad jego pracą. W
przypadku, gdy praca serwera zostanie przerwana wysyła on informację o tym do
administratora, a następnie restartuje serwer. Skrypt ten jednak nie jest już używany. Lepszym
rozwiązaniem jest skorzystanie z narzędzi deamontools lub z usługi initd.
Plik rc.radiusd jest skryptem startowym serwera RADIUS. Aby zautomatyzować
proces uruchamiania serwera należy umieścić ten skrypt razem z innymi skryptami
startowymi.
Plik checkrad to narzędzie testujące czy użytkownik ciągle jest podłączony do danego
portu określonego NAS. Jest to skrypt, w skład którego wchodzą skrypty uruchamiane w
zależności od typu urządzenia NAS. Przykładowo jeśli urządzeniem NAS jest urządzenie
cisco wówczas wywoływana jest procedura cisco_snmp. Jeśli używamy tylko jednego typu
urządzenia wówczas możemy wyrzucić procedury dotyczące pozostałych urządzeń. W celu
przeprowadzania testów używany jest jeden ze znanych protokołów: SNMP, FINGER,
TELNET, RUSERS.
Składnia polecenia:

checkrad nas_type nas_ip nas_port login session_id

56
 Poszczególne argumenty oznaczają:
1. nas_type – możliwe wartości: "livingston", "cisco", "multitech", "computone",
"max40xx", "max40xx_snmp", "ascend", "portslave", "tc", "pathras", "pr3000", "pr4000",
"patton", "digitro", "usrhiper", "netserver", "versanet", "other". Jeśli użyjemy wartości "other"
checkrad nie uruchamia żadnej podprocedury, lecz zwraca 1.
2. nas_ip – adres IP urządzenia dostępowego.
3. nas_port – sprawdzany port urządzenia dostępowego.
4. login – login użytkownika.
5. session_id – ID sesji.
Jako wyniki testów polecenie zwraca 1 jeśli użytkownik jest ciągle online lub 0 jeśli
sesja jest już zakończona.
Katalog etc/raddb zawiera pliki konfiguracyjne serwera. Tu możemy znaleźć pliki
odpowiadające za startowanie demona radiusd, za wybór metody autentykacji, dotyczące
użytkowników, klientów, połączenia z dodatkową bazą danych i wiele innych. Jest to baza
konfiguracji RADIUS serwera.
W katalogu certs przechowywane są certyfikaty wykorzystywane przez moduł
rlm_eap_tls. Przykładowe certyfikaty znajdujące się w tym katalogu powinny być używane
tylko w celach testowych. Jeśli chcemy wykorzystywać certyfikaty w normalnej pracy
serwera należy wygenerować sobie własne certyfikaty. Jeśli nie używamy jednej z metod
autentykacji: EAP-TLS, EAP-TTLS, EAP-PEAP możemy usunąć cały katalog.
Istnieją trzy pliki, w których możemy konfigurować klientów naszego serwera clients,
naslist oraz clients.conf. Nie należy jednak używać pliku clients czy naslist. W celu
konfiguracji informacji o klientach należy używać pliku clients.conf.
W pliku naspasswd możemy przechowywać hasła klientów RADIUS-a skojarzone z
ich adresami IP. Wykorzystywany jest on w przypadku korzystania z narzędzia checkrad.
Pozwala on na nie wpisywanie hasła w linii poleceń.
Lokalizacja wszystkich wbudowanych, możliwych do użycia atrybutów zdefiniowana
jest w pliku directory. W tym pliku możemy także dodawać nowe atrybuty jak i modyfikować
już istniejące.
W pliku eap.conf mamy możliwość wyboru metody autentykacji. Nie należy zmieniać
kolejności wpisów w tym pliku. Wszystkie możliwe do wyboru metody autentykacji
umieszczone są w tym pliku, w celu uruchomienia jednej z nich należy odkomentować
fragment kodu definiujący daną metodę autentykacji. Możliwe do wyboru metody
autentykacji to: MD5, LEAP, EAP-TLS, EAP-TTLS, PEAP, MS-CHAPv2.
Chcąc dodać pewne eksperymentalne moduły należy zajrzeć do pliku
experimental.conf.
Na podstawie pliku hints dokonana zostaje analiza zapytania wysłanego do serwera, a
następnie na podstawie informacji w nim zawartych dodawane są atrybuty. Plik ten został
bardziej szczegółowo opisany przy okazji omówienia demona radiusd.
Plik hountgroups pozwala zdefiniować grupy użytkowników na podstawie adresu IP
oraz portów urządzenia NAS. Porty możemy podać pojedynczo lub jako zakres. Numery
portów należy oddzielać przecinkami. Plik ten jest wykorzystywany jeśli w pliku
konfiguracyjnym users (zawierającym reguły dotyczące użytkowników) znajdzie się reguła
postaci: "Huntgroup-Name = nazwa_grupy". Jeśli jakiś użytkownik ma przyporządkowaną
jakąś regułę huntgroup wówczas plik hountgroups jest analizowany. Jeśli w pliku tym
znajdzie się więcej niż jeden wpis o tej samej nazwie, wówczas pod uwagę brany jest ten,
który jest wpisany jako pierwszy.
Plik ldap.attrmap wykorzystywany jest w celu mapowania atrybutów RADIUS-a na
atrybuty LDAP-a.

57
 Plik mssql.conf jest wykorzystywany w przypadku, gdy korzystamy z bazy danych
MSSQL. Tu możemy dokonać potrzebnych zmian w celu współpracy z bazą danych.
W pliku oraclesql.conf możemy skonfigurować podłączenie do bazy danych oracle.
W celu konfiguracji połączenia z bazą danych postgre należy wyedytować plik
postgre.sql.
Plik proxy.conf odpowiedzialny jest za konfigurację usługi proxy, dawniej plikiem, w
którym dokonywano konfiguracji związanych z proxy był plik realms. Obecnie nie należy go
używać.
Głównym plikiem konfiguracyjnym RADIUS-a jest radiusd.conf. To tu określona jest
lokalizacja innych plików konfiguracyjnych. Ponadto możemy określić tu z jakich modułów
będzie korzystał nasz serwer. Możemy tu także zdefiniować własne zmienne, których później
możemy używać podczas pracy serwera. Modyfikując ten plik należy wykomentować
wszystkie elementy, z których nie będziemy korzystać. W dalszej części tej pracy pokazane
zostaną opcje jakich ja użyłem.
Plik snmp.conf odpowiada za konfigurację usługi SNMP. Domyślnie jest ona
wyłączona. By ją włączyć należ odkomentować w pliku radiusd.conf sekcję odpowiedzialną
za usługę SNMP.
Jeżeli chcemy korzystać z bazy mysql, musimy wyedytować i skonfigurować
odpowiednio plik sql.conf.
Plik users odpowiada za autoryzację użytkowników. To w tym pliku możemy określić
w jaki sposób dany użytkownik, czy też dana grupa użytkowników będzie autentykowana i
autoryzowana.
Każdy wpis w tym pliku rozpoczyna się od nazwy użytkownika, po której następują
atrybuty i ich wartości. W jednej linii może znajdować się jedna para atrybut/wartość lub
kilka takich par oddzielonych od siebie przecinkami. Kolejne linie muszą rozpoczynać się od
znaku tabulatora. Ostatnia linia dotycząca konfiguracji danego użytkownika nie może
kończyć się przecinkiem.
Zamiast nazwy użytkownika możemy użyć specjalnego użytkownika zwanego
DEFAULT. Kwalifiaktor ten akceptuje wszystkich użytkowników.
Plik users czytany jest od góry linia po linii. Jeżeli po bloku atrybutów związanych z
danym użytkownikiem nie znajdzie się specjalny atrybut Fall-Through, lub atrybut ten będzie
miał przypisaną wartość "No", wówczas analiza pliku zostaje zakończona. Jeżeli w pliku
znajdują się jeszcze jakieś inne atrybuty dotyczące innych użytkowników, nie zostaną one
jednak odczytane.
Edytując plik users należy zachować szczególną ostrożność.
Funkcjonalność pliku acct_users jest taka jak pliku users, lecz wykorzystywany jest on
tylko w przypadku pakietów accounting.
Plik attrs jest plikiem konfiguracyjnym modułu odpowiedzialnego za odczytywanie
atrybutów – rlm_attr_filter. W tym pliku zawarte są informacje dotyczące bezpieczeństwa i
konfiguracji każdej reguły przetwarzanej przez RADIUS serwer.
Plik preproxy_users ma zbliżoną funkcjonalność do pliku users. Różnicą jest to, że
atrybuty tego pliku wykorzystywane są w celu aktualizacji pakietów przesyłanych do
dalszych serwerów, a nie dla klientów NAS.
Katalog radius_path/include zawiera plik nagłówkowy ltdl.h.
Katalogr radius_path/lib zawiera pliki bibliteczne.
W katalogu radius_path/lib znajdują się pliki pomocy.
Ktalog radius_path/share zawiera dokumentację FreeRADIUS-a. Znajdują się tam
wszelkie dokumenty rfc wyjaśniające zasadę współpracy serwera RADIUS z innymi
technologiami, jak również dokumenty wyjaśniające instalację serwera pod różnymi
platformami. Możemy tu znaleźć także wszelkie dodatkowe atrybuty używane przez różnych

58
dostawców sprzętu typu NAS. W przypadku jakichkolwiek problemów z RADIUS serwerem
należy zajrzeć do tego katalogu, a napewno rozwiążemy problem.
W katalogu radius_path/var przechowywane są dane dotyczące sesji użytkowników
jak również dane dotyczące demona radiusd. W katalogu run/radiusd znajduje się plik
radiusd.d, w którym przechowywany jest PID aktualnie uruchomionego RADIUS serwera.
Dane dotyczące sesji użytkowników znajdują się w log/radius. I tak w pliku radius.log
znajdziemy wpisy informujące jaki użytkownik, z jakiej metody uwierzytelniania korzystając,
kiedy, próbował się zalogować. Jeżeli logowanie użytkownika nie powiodło się wówczas
otrzymamy także informację dlaczego dany użytkownik nie mógł się zalogować. Poniżej
przedstawiam przykładowy wpis z pliku radius.log:

Fri Feb 17 17:46:04 2006 : Info: rlm_eap_tls: Length Included

Fri Feb 17 17:46:04 2006 : Auth: Login OK: [user/password]
(from client localhost port 305 cli 00-0C-F1-97-A2-04)

W pliku radutmp możemy znaleźć informacje dotyczące aktualnej sesji. Zawartość

tego pliku możemy wyświetlić przy użyciu polecenia radwho, które zostało opisane
wcześniej:

Login Name What TTY When From Location

a3Com a3Com shell S0 Mon 17:09 192.168.3

W pliku radwtmp znajdują się informacje o tym skąd odbywały się logwania.
Przykładowy wpis z pliku radwtmp (który możemy odczytać korzystając z polecenia radlast.

anonymou 305:switch44 Mon Mar 13 19:21 still logged in

anonymou 305:switch44 Mon Mar 13 18:50 - 19:21 (00:30)
anonymou 305:switch44 Mon Mar 13 18:21 - 18:50 (00:28)

W katalogu radius_path/var/log/radius/radacct, tworzone są katalogi odpowiadające

nazwą adresowi IP klienta, z którego odbywało się logowanie do sieci. Następnie w tych
katalogach tworzone są pliki o nazwach auth-detail-data, gdzie data oznacza datę logowania.
W tych plikach znajdują się szczegółowe informacje o logujących się użytkownikach. Poniżej
przedstawiam przykładowy plik auth-detail-data:

Packet-Type = Access-Request
Wed Mar 1 20:09:08 2006
User-Name = "user"
User-Password = "haslo"
FreeRADIUS-Proxied-To = 127.0.0.1
NAS-Port = 305
NAS-Port-Type = Ethernet
NAS-IP-Address = 192.168.30.155
Service-Type = Framed-User
Framed-MTU = 1024
Calling-Station-Id = "00-0C-F1-97-A2-04"
Client-IP-Address = 127.0.0.1

59
Rozdział 9

Instalacja i konfiguracja serwera RADIUS.

RADIUS serwer oparłem o darmowe oprogramowanie FreeRADIUS. Najnowsza
wersja oprogramowania dostępna jest pod adresem www.freeradius.org. Wykorzystywana
przeze mnie wersja to najnowsza w obecnej chwili wersja 1.1.1 z dnia 20.03.2006.
Wybrałem właśnie tę dystrybucję, gdyż obecnie jest to najprężniej rozwijająca się
wersja serwera RADIUS, najbardziej elastyczna w konfiguracji, a także najlepiej
udokumentowana.

9.1 Serwer RADIUS - instalacja.

W celu kompilacji i instalacji serwera RADIUS niezbędne jest także oprogramowanie:
1. Kompilator języka c. W moim przypadku był to kompilator gcc w wersji 3.4.3.
2. Oprogramowanie make, pozwalające nam zautomatywać kompilację oraz instalację
serwera. Ja używałem oprogramowania dostarczonego przez firmę SUN w postaci
pakietu. Jest to SUNWgmake w wersji 11.10.0, z dnia 08.01.2005.
3. Narzędzie ar pozwalające zbudować bibliotekę używaną przez serwer RADIUS.
4. Oprogramowanie ssl dostarczające niezbędne biblioteki i pliki nagłówkowe.
Wybrałem darmową dystrybucję oprogramowania - openssl. Można ją pobrać w
postaci pakietu prekompilowanego ze strony www.sunfreeware.com, ewentualnie
można pobrać w postaci źródeł na oficjalnej stronie projektu openssl:
http://www.openssl.org/source/openssl-0.9.8a.tar.gz. Ja korzystałem z
oprogramowanie w formie źródeł. Po skompilowaniu i zainstalowaniu możemy
korzystać z niezbędny bibliotek i plików nagłówkowych.
5. Oprogramowanie FreeRADIUS dostępne w postaci źródeł na oficjalnej stronie
projektu www.freeradius.org. Wybrałem oczywiście najnowsze wydanie serwera w
wersji 1.1.1 z dnia 20.03.2006.
6. Należy także ustawić ścieżkę dostępu do binariów. Przykładowo:

PATH=/usr/sbin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin/

Posiadając już odpowiednio skonfigurowane środowisko możemy przystąpić do

instalacji serwera RADIUS.
Instalując RADIUS serwer należy pobrać źródła oprogramowania. FreeRADIUS w
wersji źródłowej dostępny jest na stronie www.freeradius.org. Źródła oprogramowania są
skompresowane, ściągnięty na dysk plik ma następującą postać:
freeradius-1.1.1.tar.gz
W celu rozpakowania źródeł należy wydać następujące polecenie:

radius# gunzip freeradius-1.1.1.tar.gz

Otrzymamy plik freeradius-1.1.1.tar. Teraz należy zdearchiwizować źródła:

radius# tar –xvf freeradius-1.1.1.tar

Opcja –v spowoduje, że będziemy mogli podglądać proces dearchiwizacji źródeł.

60
 Po przeprowadzeniu powyższych działań otrzymamy katalog zawierający źródła
serwera RADIUS: freeradius-1.1.1. Przechodzimy zatem do katalogu ze źródłami.

radius# cd freeradius-1.1.1

W katalogu tym znajdują się pliki niezbędne do przeprowadzenia kompilacji, a także

pliki takie jak INSATALL, RAEDME, z których możemy dowiedzieć się w jaki sposób
dostosować instalację do środowiska w jakim mamy zamiar ją uruchomić. Pliki te należy
przeczytać zanim dokonamy kompilacji, a następnie instalacji serwera.
Przeczytawszy wskazówki i zalecenia znajdujące się we wspomnianych powyżej
plikach należy sprawdzić konfigurację naszego systemu przy użyciu dołączonego z instalacją
skryptu konfiguracyjnego configure. Skrypt ten możemy uruchomić z szeregiem opcji, które
umożliwiają nam modyfikację i personalizację instalacji serwera. Aby podejrzeć wszystkie
dostępne opcje należy wydać polecenie:

radius# ./configure –help

Wszystkie opcje, które pojawią się na ekranie opisane są szerzej w pliku INSTALL.
W moim przepadku konfiguracja wyglądała w następujący sposób:

radius# ./configure --prefix=/usr/local/radius/

--with-openssl-includes=/usr/local/ssl/include
--with-openssl-libraries=/usr/local/ssl/lib

Poszczególne opcje występujące po nazwie skryptu to: prefix – opcja wskazująca

katalog instalcyjny, --with-openssl-includes – opcja wsakazująca lokalizację niezbędnych
plików nagłówkowych oprogramowania ssl, --with-openssl-libraries – opcja wzkazująca
lokalizację bibliotek oprogramowanie ssl.
Po skonfigurowaniu możemy skompilować FreeRADIUS-a wydając polecenie:

radius# make

Jeżeli kompilacja przebiegnie poprawnie wówczas możemy wydać polecenie:

radiu# make install

które dokona instalacji skompilowanych plików.

Po wykonaniu instalacji należy utworzyć zmienną środowiskową

LD_LIBRARY_PATH, której wartość wskazuje lokalizację bibliotek dynamicznie
łączonych:

radius# LD_LIBRARY_PATH=/usr/local/ssl/lib:/opt/sfw/lib:
/usr/local/radius/lib

Aby przetestować czy instalacja się powiodła i RADIUS serwer działa należy
uruchomić serwer w trybie debugowania wydając polecenie:

radius# radiusd –X
a następnie przetestować serwer:

radius# radtest test test localhost 0 testing123

61
9.2 Serwer RADIUS - konfiguracja.
Wcześniej zostały przedstawione wszystkie informacje, gdzie można dokonać
konfiguracji serwera RADIUS. W tym rozdziale zostaną przedstawione zmiany
konfiguracyjne dokonane przeze mnie.

9.2.1 clients.conf
Plik radius_path/etc/raddb/clients.conf zawiera wpisy dotyczące klientów RADIUS
serwera. Jako klienta użyłem switch-a 4400 firmy 3com. Poniżej przedstawiam zawartość
pliku clients.conf:

client 192.168.30.155 {
secret = password
shortname = switch4400
}

By skonfigurować klienta należy podać jego adres IP, hasło "secret" wymieniane
pomiędzy klientem, a radius serwerem, oraz shortname czyli nazwę skrótową klienta.

9.2.2 eap.conf
Plik eap.conf odpowiedzialny jest za konfigurację metody autentykcji. Poniżej
przedstawiam zawartość pliku: [8, 9]
eap {

Określam domyślną metodę autentykacji.

#
default_eap_type = ttls

Każdy pakiet EAP-Request musi otrzymać odpowiedź w postaci pakietu EAP-

Response. Poniższa zmienna pozwala ustawić maksymalny czas oczekiwania na odpowiedź.
Jeśli w tym czasie nie nadejdzie odpowiedź wówczas pakiet EAP-Request zostanie
odrzucony.
#
timer_expire = 60

Istnieje wiele typów autentykcji EAP, serwer jednak obsługuje tylko wybrane typy.
Chcąc by obsługiwał także nieznane, należy poniższą zmienną ustawić na wartość "yes".
#
ignore_unknown_eap_types = no

Moduł autentykacji EAP-TLS.

#
tls {
Część odpowiadająca za crtyfikaty. Tu określamy hasło klucza prywatnego,
lokalizację klucza, oraz lokalizacjię cetyfkiatów.
#
private_key_password = radpass01
private_key_file = ${raddbdir}/certs/radkey.pem
certificate_file = ${raddbdir}/certs/radcert.pem

62
 Zaufany główny certyfikat Certifcat Authority:
#
CA_file = ${raddbdir}/certs/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random

Określenie wielkości fragmentu pakietu RADIUS:

#
fragment_size = 1024
}

Chcąc wykorzystywać metodę autentykacji EAP-TTLS musimy uruchomić także

protokół EAP-TLS. Protokół EAP TTLS pracuje wewnątrz protokołu EAP-TLS, który
pracuje wewnątrz protokołu RADIUS. Dlatego potrzebne są certyfikaty klienta, gdyż
korzystamy z protokołu EAP-TLS. Sam protokół EAP-TTLS nie wymaga by klient posiadał
certyfikaty.
#
ttls {
Tunelowana sesja EAP wymaga określenia domyślnego typu EAP, który jest
wykorzystywany jako metoda autentykacji w tunelu. Poniższa zmienna odpowiada za
ustawienie domyślnego typu EAP. Ja wybrałem EAP-MD5.
#
default_eap_type = md5

Wewnątrz tunelowanego zapytanie zazwyczaj nie są przesyłane atrybuty takie jak

Calling-Station-Id, itp. Takie atrybuty obecne są na zewnątrz tunelu. Ustawiając poniższą
zmienną na wartość "yes" sprawimy, że atrybuty zwykle nieobecne wewnątrz tunelu zostaną
tam skopiowane i następnie będą mogły zostać odczytane.
#
copy_request_to_tunnel = yes

Atrybuty przesyłane przez serwer do NAS oparte są zazwyczaj o nazwę użytkownika,

która przesyłana jest na zewnątrz tunelu (zwykle jest to anonymous). Ustawiając poniższą
zmienną na "yes" sprawimy, że odpowiedzi serwera będą oparte o nazwę użytkownika
zawartą wewnątrz tunelu.
#
use_tunneled_reply = yes

}
}

9.2.1 radiusd.conf
Plik radiusd.conf jest głównym plikiem konfiguracyjny demona radiusd. Zmienne
deklarowany w tym pliku mają postać ${foo}. Są to zmienne o zasięgu lokalnym.
# radiusd.conf

Delkaracja położenia pozostałych plików RADIUS serwera.

#
prefix = /usr/local/radius
exec_prefix = ${prefix}
sysconfdir = ${prefix}/etc
localstatedir = ${prefix}/var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius

63
 raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct

Lokalizacja plików konfiguracyjnych oraz plików logów.

#
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/radiusd

Logi serwera będą dopisywane na końcu poniżej zdefiniowanego pliku.

#
log_file = ${logdir}/radius.log

Katalog bibliotek serwera.

#
libdir = ${exec_prefix}/lib

Podczas uruchomienia serwera jego PID będzie zapisywany w poniższym pliku. W

celu rebootu serwera możemy wydać np. takie polecenie: "kill -HUP `cat
/var/run/radiusd/radiusd.pid`"
#
pidfile = ${run_dir}/radiusd.pid

Przy pomocy poniższych zmiennych możemy określić z uprawnieniami jakiej

grupy/użytkownika RADIUS zostanie uruchominy. Wykomentowując te zmienne sprawimy,
że RADIUS zostanie uruchomiony z takimi prawami jakie ma użytkownik/grupa właśnie go
uruchamiający. Jeśli zdecydujemy się używać tych zmiennych powinniśmy używać grupy
nobody i użytkownika nobody.
#
#user = nobody
#group = nobody

Poniższa zmienna określa czas w sekundach na wykonanie zapytania. Zapytania,

których wykonanie będzie dłuższe zostaną odrzucone.
#
max_request_time = 30

Poniższa zmienna związana jest z poprzednią. Jeśli przetwarzanie zapytania będzie

trwało dłużej niż określa to max_request_time, wówczas może zostać ono usunięte.
#
delete_blocked_requests = no

Odpowiedzi wysyłane do klienta przez serwer przechowywane są w pamięci cache

przez krótki okres czasu. Pakiet wysyłany do NAS może do niego nie dotrzeć z różnych
powodów. Wówczas NAS upomina się u RADIUS-a o odpowiedź powtarzając zapytanie,
serwer może wtedy szybko odpowiedzieć korzystając z zapytania przechowywanego w cache.
Poniższa zmienna pozwala nam określić przez jaki czas odpowiedzi serwera będą
przechowywane w cache. Jeśli ustawimy tę wartość na zbyt niską, wówczas powtórne żądania
klienta nie zostaną odczytane jako powtórzenia lecz jako oddzielne zapytania. Natomiast zbyt
duża wartość tej zmiennej spowoduje, że serwer będzie przechowywał zbyt dużo informacji w
cache, co może spowodować że pewne zapytania zostaną zablokowane. Zalecane wartości to
od dwóch do pięciu sekund.
#
cleanup_delay = 5

64
 Poniższa zmienna to maxymalna liczba odpowiedzi śledzonych przez serwer. Powinna
być ona równa liczbie klientów pomnożonej przez 256. W przypadku ustawienia zbyt małej
wartości, wówczas gdy serwer będzie w stanie operacyjnym, nie będzie w stanie
odpowiedzieć na żadne nowe zapytanie dopóki nie upłynie czas określony przec
cleanup_delay i wszystkie stare zapytania nie zostaną usunięte. Ustawienie zbyt dużej
wartości spowoduje, że serwer będzie zużywał więcej pamięci, ale nie przyniesie nam to
żadnej korzyści.
#
max_requests = 1024

Poniższa zmienna pozwala na określenie adresu IP, na którym serwer będzie

nasłuchiwał zapytań oraz z którego będzie odpowiadał. Opcja ta jest przydatna, gdy
dysponujemy maszyną z wieloma interfejsami sieciowymi.
Wartości możliwe do przypisania tej zmiennej to "*", adres IP lub pełna nazwa
domenowa.
#
bind_address = *

Poniższa zmienna pozwala na ustawienie portu, na którym będzie nasłuchiwał

RADIUS serwer. Ustawiając tę zmienną na 0 spowodujemy, że RADIUS będzie nasłuchiwał
na domyślnych portach 1812 i 1813.
#
port = 0

Domyślnie radius serwer używa zmiennej bind_address by określić adres na

jakim ma nasłuchiwać zapytań oraz port by określić port nasłuchiwania. Zmienna port
określa port dla pakietów autentykacji.
Chcąc by serwer nasłuchiwał na innych adresach, lub innych portach można użyć
sekcji "listen", która pozowli nam na określenie adresu IP serwera RADIUS, portu
nasłuchiwania oraz pozwala na selektywne nasłuchiwanie tylko dla pakietów autentykacji lub
accounting. W mojej konfiguracji nie używam tej sekcji, gdyż nie była ona potrzebna.
#
#listen {

Adres IP i jego możliwe wartości:

#
# IP (1.2.3.4)
# nazwa hosta (radius.example.com)
# wildcard (*)
# ipaddr = *

Port nasłuchiwania, możliwe wartości.

#
# numer portu (1812)
Zero oznacza użycie wartości z "/etc/services".
#
# port = 0

Typ pakietów, dla których będzie nasłuchiwał RADIUS serwer. Możliwe wartości:
a) auth - nasłuchiwanie pakietów autentykacji.
b) acct - nasłuchiwanie pakietów accounting.
#
# type = auth
#}

65
 Dzięki poniższej zmiennej możemy logować nazwy klientów (wartość "yes") lub
tylko ich adresy IP (wartość "no").
#
hostname_lookups = no

Tę zmienną ustawiamy na "yes" tylko podczas testowania serwera.

#
allow_core_dumps = no

Wspieranie wyrażeń regularnych.

#
regular_expressions = yes
extended_expressions = yes

Logowanie pełnej nazwy użytkowniak User-Name.

#
log_stripped_names = yes

Logowanie autentykcji do pliku logów.

#
log_auth = yes

Poniższe zmienne pozwalają określić czy będą logowane hasła użytkowników.

Zmienna log_auth_badpass – logowanie, jeśli hasło jest prawidłowe, zmienna
log_auth_goodpass – logowanie, jeśli hasło jest prawidłowe.
#
log_auth_badpass = no
log_auth_goodpass = no

Poniższa zmienna pozwala na włączenie/wyłączenie kontroli kolizji użytkowników.

Nie zaleca się stosować tego mechanizmu. Dlatego ustawiłem tę zmienną na "no"
#
usercollide = no

Poniższe dwie zmienne odpowiedzialne są za modyfikację atrybutów User-Name oraz

User-Password. Możliwe wartości to "before", "after" lub "no". Wartość "before" oznacza, że
zapytanie zostanie zmodyfikowane przez serwer przed autentykacją. Wartość "after" oznacza,
że serwer będzie próbowała autentykować używając oryginalnych danych użytkownika, jeśli
autentykacja nie powiedzie się, wówczas jego dane zostaną zmodyfikowane i ponownie
dokonana zostanie próba autentykacji. Wartość "no" oznacza, że serwer nie będzie używał
tego mechanizmu.
#
lower_user = no
lower_pass = no

Poniższe zmienne pozwalają określić czy z atrybutów User-Name oraz User-Password

mają zostać usunięte znaki puste. Wartości możliwe do wykorzystania: "before", "after", "no".
Użycie tych wartości zostało wyjaśnione powyżej.
#
nospace_user = no
nospace_pass = no

Narzędzie służące do sprawdzenia poprawności pliku radiusd.conf.

#
checkrad = ${sbindir}/checkrad

66
 Konfiguracja bezpieczeństwa.
#
security {

Zmienna max_attributes pozwala określić ile atrybutów może być obecnych w jednym
pakiecie RADIUS-a. Zbyt niska wartość tej zmiennej spowoduje, że wszystkie pakiety
zostaną odrzucone. Zbyt duża wartość natomiast spowoduje, że nawet mała ilość pakietów
będzie bardzo obciążała pamięć serwera. Wartość zero oznacza dowolną ilość atrybutów w
jednym pakiecie.
#
max_attributes = 200

Zmienna delayed_reject odpowiada za opóźnienie odpowiedzi Access-Reject. Może to

spowolnić atak typu DoS, a także wydłuży proces brutalnego łamania hasła. Wartość zero
oznacza wysyłanie pakietu Access-Reject bezzwłocznie. Jeśli wartość ta będzie większa niż
cleanup_delay, wówczas Access-Reject zostanie wysłany po upływie czasu czasu
cleanup_delay. Zalecane wartości: 1-5.
#
reject_delay = 1

Poniższa zmienna mówi serwerowi czy może odpowiadać na zapytania Status-Server.

#
status_server = no
}

Konfiguracja proxy.
Poniższa zmienna włącza/wyłącza usługę proxy dla zapytań serwera RADIUS. W celu
wyłączenia proxy należy ustawić poniższą zmienną na wartość "no", a następnie
zakomentować linię $INCLUDE.
#
proxy_requests = yes
$INCLUDE ${confdir}/proxy.conf

Konfiguracja klientów.
Konfiguracja klientów znajduje się w pliku clients.conf, który należy dołączyć w pliku
konfiguracyjnym radiusd.conf.
#
$INCLUDE ${confdir}/clients.conf

Konfiguracja SNMP.
Konfiguracja SNMP ma sens tylko, jeśli skompilowaliśmy serwer by używał SNMP.
#
snmp = no
$INCLUDE ${confdir}/snmp.conf

Konfiguracja THREAD POOL.

Thread pool, czyli pula wątków, jest to grupa wątków, które uruchomine działają w
celu nasłuchiwania wszystkich zapytań do RADIUS serwera.
Przydatne jest zastoswanie kilku wątków zapasowych, które zostaną wykorzystane
natychmiast, gdy do RADIUS-a zostanie wygenerowany jakiś większy ruch. Aczkolwiek nie
powinniśmy przesadzić z ilością zapasowych wątków, gdyż będą one tylko niepotrzebnie
zajmować zasoby procesora i pamięci.
#
thread pool {

67
 Ilość wątków uruchamianych początkowo.
#
start_servers = 5

Maxymalna ilość wątków.

#
max_servers = 32

Zmienna określająca minimalną i maxymalną ilość wątków zapasowych.

#
min_spare_servers = 3
max_spare_servers = 10

Poniższa zmienna pozwala ustalić maksymalną ilość zapytań obsługiwanych przez

jeden wątek. Wartość zero oznacza nieskończenie wiele zapytań na wątek.
#
max_requests_per_server = 0
}

Konfiguracja modułów dodatkowych.

Poniższa sekcja odpowiada za definicję oraz konfigurację modułów
wykorzystywanych przez serwer RADIUS.
#
modules {

Moduł PAP odpowiedzialny za autentykację użytkowników na podstawie ich nazwy

oraz hasła.
pap {
encryption_scheme = crypt
}

Moduł CHAP – autentykacja przy wykorzystaniu CHAP-Password.

#
chap {
authtype = CHAP
}

PAM – Plugable Authentication Module.

#
pam {
pam_auth = radiusd
}

Unix – autentykacja przy użyciu /etc/passwd

#
unix {

Zmienna odpowiedzialna za możliwość kieszeniowania danych pochodzących z

/etc/passwd, /etc/shadow, and /etc/group.
#
cache = no

Zmienna określająca co ile sekund pamięć cache zostanie przeładowana.

#
cache_reload = 600

68
 Poniżej możemy określić, gdzi mają być poszukiwane pliki passwd, shadow oraz
group. Określenie lokalizacji tych plików konieczne jest tylko w przypadku niektórych
systemów. Takich jak np. FreeBSD lub Mac OSX. W przeciwnym wypadku możemy
pozostawić je wykomentowane.
#
# passwd = /etc/passwd
# shadow = /etc/shadow
# group = /etc/group

Lokalizacja pliku radwtmp. Jeśli nie używamy narzędzia radlast możemy

wykomentować poniższą zmienną.
#
radwtmp = ${logdir}/radwtmp
}

Określenie lokalizacji pliku konfiguracyjnego dla protokołu autentykacji EAP

(Extensible Authentication Protocol).
#
$INCLUDE ${confdir}/eap.conf

Autentykacja Microsoft CHAP.

Ten moduł wspomaga autentykację MS-CHAP oraz MS-CHAPv2. Wprowadza on
także atrybut SMB-Account-Ctrl.
#
mschap {
authtype = MS-CHAP

Ustawienie poniższej wartości na "yes" sprawi, że mschap doda

MS-CHAP-MPPE-Keys do MS-CHAPv1 oraz MS-MPPE-Recv-Key/MS-MPPE-Send-Key
do MS-CHAPv2
#
#use_mppe = no
#require_encryption = yes
#require_strong = yes
#with_ntdomain_hack = no

Poniższy moduł może dokonać autntykacji lub odwołać się do kontrolera domeny
Windows w celu autentykacji. Poniższa dyrektywa wywołuje ntlm_auth, który dokona
autentykacji, a następnie zwróci NT-Key. Jeżeli chcemy używać modułu ntlm_auth musimy
mieć uruchomione demony winbindd oraz nmbd
#
#ntlm_auth = "/path/to/ntlm_auth --request-nt-key --
username=%{Stripped-User-Name:-%{User-Name:-None}} --
challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
}

Lightweight Directory Access Protocol (LDAP)

#
Poniższy fragment konfiguracji odpowiada za użycie protokołu LDAP w celu
autentykacji oraz autoryzacji użytkowników.
#
ldap {
server = "ldap.your.domain"
# identity = "cn=admin,o=My Org,c=UA"
# password = mypass
basedn = "o=My Org,c=UA"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"

69
 # base_filter = "(objectclass=radiusprofile)"

Jeśli chcemy by połącznie pomiędzy bazą LDAP i RADIUS serwerem było

szyfrowane należy ustawić poniższą wartość na "yes", a następnie określić lokalizację
certyfikatów niezbędnych podczas korzystania z protokołu autentykacji tls.
start_tls = no
# tls_cacertfile = /path/to/cacert.pem
# tls_cacertdir = /path/to/ca/dir/
# tls_certfile = /path/to/radius.crt
# tls_keyfile = /path/to/radius.key
# tls_randfile = /path/to/rnd
# tls_require_cert = "demand"
# default_profile = "cn=radprofile,ou=dialup,o=My
Org,c=UA"
# profile_attribute = "radiusProfileDn"
access_attr = "dialupAccess"

Mapowanie atrybutów RADIUS-a na atrybuty LDAP-a.

#
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
# password_header = "{clear}"

Chcąc pobierać hasło z Novell eDirectory należy ustawić poniższy parametr.

#
#password_attribute = nspmPassword

Chcąc wyłączyć Novell eDirectory należy odkomentować poniższą opcję.

#
#edir_account_policy_check=no
#
# groupname_attribute = cn
# groupmembership_filter =
"(|(&(objectClass=GroupOfNames)(member=%{Ldap-
UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))"
# groupmembership_attribute = radiusGroupName
timeout = 4
timelimit = 3
net_timeout = 1
# compare_check_items = yes
# do_xlat = yes
# access_attr_used_for_allow = yes
}

Moduł passwd pozwala dokonywać autoryzacji korzystając z dowolnego pliku, w

którym przechowujemy dane podobne do danych przechowywanych w pliku passwd. Dane
przechowywane w takim pliku podczas autoryzacji są z niego wydobywane.
Możemy tu użyć następujących parametrów:
a) filename – ścieżka do pliku z danymi o użytkownikach.
b) format – określenie formatu pliku. Pola oznaczone przez "*" to pola klucze.
Jest to parametr, z którym name pochodzące z zapytania używane jest by
odnaleźć rekord w pliku passwd. Atrybut oznaczony przez "=" dodawany jest
w odpowiedziach zamiast domyślnie skonfiugrowanych odpowiedzi. Atrybut
oznaczony przez "~" dodawany jest do request_items. Pola oznaczone ","
mogą zawierać listę atrybutów oddzielonych przecinkami.

70
 c) authtype – jeśli ten parametr jest obecny wówczas, Auth-Type jest używany w
celu dokonania autentykacji.
d) shsize – parametr określa wielkość tabeli hashsize. Jeśli zostanie ustawione na
"0", lub wogóle nie zostanie określony wówczas plik czytany jest przy każdej
prośbie o autentykację.
e) allowmultiplekeys – dla każdego klucza dozowolone jest kilka rekordów
f) ignorenislike – ignorowanie rekordów związanych z NIS.
g) delimiter – symbol jakiego będziemy używać jako separatora danych w pliku.
Poniżej mamy przykładową konfigurację dla pliku /etc/smbpasswd.
passwd etc_smbpasswd {
filename = /etc/smbpasswd
format = "*User-Name::LM-Password:NT-Password:SMB-
Account-CTRL-TEXT::"
authtype = MS-CHAP
hashsize = 100
ignorenislike = no
allowmultiplekeys = no
}

Przykład dla pliku /etc/group file.

#
passwd etc_group {
filename = /etc/group
format = "=Group-Name:::*,User-Name"
hashsize = 50
ignorenislike = yes
allowmultiplekeys = yes
delimiter = ":"
}

Moduł dla proxy.

Można konfigurować wiele instancji reguł w celu obsłużenia jednocześnie reguł o
różnej składni. Kolejność interpretacji określona jest w sekcji authorize oraz preacct. Opcje
konfiguracyjne:
a) format – jedyne dopuszczalne wartości 'prefix' or 'suffix'.
b) delimiter – pojedynczy znak.
c) ignore_default - wartości 'yes' lub 'no'
d) ignore_null - wartości 'yes' lub 'no'
Ustawienie opcji ignore_default oraz ignore_null na "yes" zapobiega odczytywaniu
reguł DEFAULT oraz NULL. Użyteczne jeśli mamy wiele różnych reguł. Przykładowe
reguły.
# 'realm/username'
#
Użytkownicy IPASS mają ustawione reguły na "IPASS".
realm IPASS {
format = prefix
delimiter = "/"
ignore_default = no
ignore_null = no
}

# 'username@realm'
#
realm suffix {
format = suffix
delimiter = "@"

71
 ignore_default = no
ignore_null = no
}

# 'username%realm'
#
realm realmpercent {
format = suffix
delimiter = "%"
ignore_default = no
ignore_null = no
}

#
# 'domain\user'
#
realm ntdomain {
format = prefix
delimiter = "\\"
ignore_default = no
ignore_null = no
}

Moduł sprawdzający wartości atrybutów. Pozwala na sprawdzenie czy wartości

atrybutów występujące w zapytaniach są prawidłowe.
#
checkval {

Atrybut z zapytania, który będzie sprawdzany.

#
item-name = Calling-Station-Id

Atrybut, z którym sprawdzany atrybut będzie porównywany.

#
check-name = Calling-Station-Id

Typ danych. Możliwe wartości to string, integer, ipaddr, date, binary, octets.
#
data-type = string

Ustawienie poniższej zmiennej na "yes" spowoduje odrzucenie zapytania w

przypadku, gdy item-name nie wystąpi w nim.
#
#notfound-reject = no
}

Ponowane przerabianie przypadkowych pakietów.

#
Możemy użyć reguły Rewrite-Rule.
#
#attr_rewrite sanecallerid {
# attribute = Called-Station-Id
# searchin = packet
# searchfor = "[+ ]"
# replacewith = ""
# ignore_case = no
# new_attribute = no
# max_matches = 10

72
 Ustawiając poniższą zmienną na "yes" sprawimy, że oryginalny łańcuch zostanie
podmieniony.
#
# append = no
#}

Poniższy moduł odpowiedzialny jest za odczytanie plików huntgroups oraz hints.

Atrybuty w nich zawarte mogą być czasem modyfikowane w celu ustandaryzowania ich.
#
preprocess {
huntgroups = ${confdir}/huntgroups
hints = ${confdir}/hints

Fragment odpowiedzialny za numerację portów.

#
with_ascend_hack = no
ascend_channels_per_line = 23

Maszyny Windows NT często dokonują autentykacji podając

NT_DOMAIN\username. Ustawiając poniższą zmienną na "yes" sprawimy, że część
NT_DOMAIN zostanie odrzucona.
#
with_ntdomain_hack = no

Poniższa zmienna ustawiona na "yes" powoduje, że w przypadku nazw użytkowników

dłuższych niż 10 znaków po 10 znaku zostanie dodany znak "/" oraz pozostałe znaki.
#
with_specialix_jetstream_hack = no

Poniższa zmienna przydatna jest w przypadku, gdy Cisco (lub Quintum pracujący w
trybie Cisco) przesyła atrybut VSA. Jeśli nie używamy tego atrybutu, nie powinniśmy używać
poniższej zmiennej.
#
with_cisco_vsa_hack = no
}

Moduł odpowiedzialny za plik użytkowników Livingston-style.

#
# 'users'.
#
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
preproxy_usersfile = ${confdir}/preproxy_users
compat = no
}

Szczegółowy zapis wszystkich rekordów logowania.

#
detail {
Plik zawierający szczegóły logowania tworzony jest dla każdego klienta. Jego nazwa
odpowiada adresowi IP, lub nazwie klienta. Każdego dnia tworzone są nowe pliki. Dodając
na końcu nazwy symbol ":%H" sprawimy, że plik logowania będzie tworzony co godzinę.
#
# ..../detail-%Y%m%d:%H
detailfile = ${radacctdir}/%{Client-IP-
Address}/detail-%Y%m%d

73
 Poniższa zmienna odpowiada za prawa dostępu do plików detail. Prawa te powinny
być bardzo ograniczone ze względu na dane przechowywane w tych plikach.
#
detailperm = 0600
}

detail auth_log {
detailfile = ${radacctdir}/%{Client-IP-
Address}/auth-detail-%Y%m%d
detailperm = 0600
}

Ten moduł odpowiedzialny jest za logowanie pakietów Access-Accept oraz Access-

Reject.
#
detail reply_log {
detailfile = ${radacctdir}/%{Client-IP-
Address}/reply-detail-%Y%m%d
detailperm = 0600
}

Moduł logujący pakiety przekazywane za pomocą proxy.

# detail pre_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-
Address}/pre-proxy-detail-%Y%m%d
# detailperm = 0600
# }

Ten moduł loguje informacje o pakietach Respond.

#
# detail post_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-
Address}/post-proxy-detail-%Y%m%d
#
# detailperm = 0600
# }

Tworzenie unikalnego ID sesji.

acct_unique {
key = "User-Name, Acct-Session-Id, NAS-IP-Address,
Client-IP-Address, NAS-Port"
}

Włączenie pliku zawierającego konfigurację dla sql:

a. Postgresql: ${confdir}/postgresql.conf
b. MS-SQL: ${confdir}/mssql.conf
c. Oracle: ${confdir}/oraclesql.conf
#
$INCLUDE ${confdir}/sql.conf

Używając dla Cisco VoIP logowania wykorzystując Postgresql, należy użyć:

#
# ${confdir}/pgsql-voip.conf

Definicja pliku 'utmp'. Przechowywane są w nim informacje o tym kto i skąd aktualnie
jest zalogowany. Z pliku tego korzysta skrypt radwho.

74
 #
radutmp {
filename = ${logdir}/radutmp

W pliku radutmp będziemy zapisywać nazwę użytkownika. Możemy tu dołączyć

także inne atrybuty.
#
username = %{Stripped-User-Name:-%{User-Name}}

Ustawienie wrażliwości na wielkość liter.

#
case_sensitive = yes

Ustawienie odpowiednich praw dla pliku.

#
perm = 0600
callerid = "yes"
}

Moduł "Safe" radutmp jest to inna instancja pliku radutmp. Nie zawiera informacji o
adresie IP iużytkownika, zatem prawa do tego pliku mogą być mało restrykcyjne.
#
radutmp sradutmp {
filename = ${logdir}/sradutmp
perm = 0644
callerid = "no"
}

Zmienna attr_filter służy do filtrowania atrybutów odbieranych od serwara proxy, by

zapewnieć przesyłanie naszemu klientowi RADIUS-a tylko dozwolonych atrybutów.
#
attr_filter {
attrsfile = ${confdir}/attrs
}

Poniższy moduł pozwala zliczać atrybuty przychodzące w zapytaniach. Dzięki temu

możemy przykładowo ustalić maxymalną liczbę logowań przypadającą na danego
użytkownika, po przekroczeniu której użytkownik nie będzie mógł się zalogować. Licznik
atrybutów jest resetowany automatycznie. Możemy ustalić co jaki okres ma się odbywać reset
licznika. Przykładowo:
#
# DEFAULT Max-Daily-Session := 36000
# Fall-Through = 1
# DEFAULT Daily-Session-Time > 3600, Auth-Type = Reject
# Reply-Message = "You've used up more than one hour
today"
#
counter daily {
filename = ${raddbdir}/db.daily
key = User-Name
count-attribute = Acct-Session-Time
reset = daily
counter-name = Daily-Session-Time
check-name = Max-Daily-Session
allowed-servicetype = Framed-User
cache-size = 5000
}

75
 Poniższy moduł wprowadzony został w celach debugowania.
#
always fail {
rcode = fail
}
always reject {
rcode = reject
}
always ok {
rcode = ok
simulcount = 0
mpp = no
}

Poniższy moduł pozwala przydzielać użytkownikom lub grupom użytkowników pule

adresowe.
#
ippool main_pool {

Definicja puli adresów.

#
range-start = 192.168.1.1
range-stop = 192.168.3.254

Maska sieci używana dla adresów z puli.

#
netmask = 255.255.255.0

Rozmiar cache przeznaczony dla plików db. Wartość powinna wynosić tyle ile jest
adresów w puli.
#
cache-size = 800

Główny plik służący do alokacji adresów dla klientów.

#
ip-index = ${raddbdir}/db.ipindex

Zmienna określająca czy Framed-IP-Address ma zostać nadpisany przez adresy z puli.

#
override = no

Maksymalny czas, gdy wejście będzie aktywne. Wartość należy podać w sekundach.
#
maximum-timeout = 0
}
}

Poniższa sekcja określa kolejność ładowani poszczególnych modułów. Moduły

zadeklarowane tu zostaną załadowane wcześniej niż sekcje występujące później takie jak
authorize, authenticate lub exmined, itd. Sekcja ta nie jest konieczna, gdyż jeśli jakiś moduł
jest wymagany przez np. autoryzację wówczas zostanie on w odpowienim czasie wywołany.
Istenieją jednak moduły, które nie są inicjowane przez inne i właśnie te moduły
możemy umieścić tutaj. Umieszczenie modułów w tej sekcji daje nam także pewność w jakiej
kolejności będą one wywoływane.
#
instantiate {

76
 Wywoływanie skryptów zewnętrznych.
#
exec

Moduł odpowiedzilny za dynamiczną translację wyrażeń typu:

#
# Session-Timeout = `%{expr:2 + 3}`
#
expr
}

Autoryzacja.
W tym przypadku w pierwszej kolejności przetwarzane są pliki hints oraz
huntgoroups, następnie realms i ostatecznie users.
#
authorize {

Moduł preprocess używany jest w celu ustandaryzowania atrybutów. Przetwarza on

pliki hints oraz huntgroups. Dodaje także atrybut Client-IP-Address do zapytania.
#
preprocess

Chcąc logować zapytania autentykacji należy użyć poniższego modułu auth_log.

#
auth_log

Moduł odpowiedzialny za autentykację CHAP.

#
chap

Moduł odpowiedzilany za autentykację z wykorzystaniem protokołu MS-CHAP.

#
mschap

Moduł odpowiedzialny za autentykację EAP-MD5, EAP-TLS, EAP-LEAP.

#
eap

Moduł odpowiedzilany za odczytanie pliku users.

#
files

Moduł odpowiedzilny za komunikację z bazą sql

#
sql

Moduł odpowiedzilny za komunikację z sambą.

#
etc_smbpasswd

Moduł odpowiedzilny za autentykację LDAP.

#
ldap
daily

Autentykacja.

77
 W tej sekcji wylistowane są moduły, które możemy wykorzystać w celu autentykacji.
Metody autentykacji wypisane tutaj mogą zostać użyte jako warotość atrybutu Auth-Type.
Nie zalecane jest jednak ręczne ustawianie atrybutu Auth-Type, jest to przyczyną częstych
błędów i problemów związanych z autentykacją.
#
authenticate {

Auth-Type PAP {
pap
}

Auth-Type CHAP {
chap
}

Auth-Type MS-CHAP {
mschap
}

Pluggable Authentication Modules.

#
# pam

Autentykacja na podstawie kont użytkowników systemu UNIX.

#
unix

Autentykacja przy użyciu protokołu LDAP.

#Auth-Type LDAP {
# ldap
#}

Protokół EAP.
eap
}

Określenie sposobu zapisywania logów.

#
preacct {
preprocess
acct_unique
IPASS
suffix
ntdomain
files
}

Sekcja odpowiedzialna za szczegółowe logowanie zapytań.

#
accounting {

Stworzenie szczegółowego pliku logów 'detail'

#
detail

Aktualizacja pliku wtmp, poniższą linię można ususnąć jeśli nie używamy radlast.
#
# daily

78
 unix
radutmp
# sradutmp

Zwrot adresu do puli adresów w przypadku napotkania rekordu stop.

#
main_pool

Logowanie ruchu do bazy SQL.

#
# sql

Baza używana w celu sprawdzania równoczesnego logowania (Simaultaneous-Use).

#
session {
radutmp
# sql
}

Specyfikacja zadań jakie możemy wykonać po autentykacji użytkownika.

post-auth {
Pobranie adresu z puli adresów.
#
# main_pool

Logowanie odpowiedzi na autentykację

#
reply_log

Logowanie autentykacji w bazie sql.

#
# sql
# }
}

Ustawienia proxy. Jeśli przesyłamy zapytanie do serwera wówczas początkowo

zostaje ono przepuszczone przez sekcję pre-proxy. Tu zostaje podjęta decyzja o przesłaniu
pakietu dalej lub o jego odrzuceniu.
#
pre-proxy {
# attr_rewrite

Możemy zmienić atrybut według definicji podanej w pliku preproxy_users.

#
# files

Chcąc logować informacje o pakietach przechodzących przez sekcję pre-proxy, należy

odkomentować poniższą linię.
#
# pre_proxy_log
}

Poniższa sekcja odnosi się do odpowiedzi na zapytania. Jeżlie odpowiedź na zapytanie

przesyłana jest przy użyciu mechanizmu proxy, wówczas wstępnie przechodzi przez moduł
preproxy.

79
 #
post-proxy {

Logowanie odpowiedzi post-proxy.

#
# post_proxy_log
# attr_rewrite

Chcąc używać metody autentykacji LEAP w przypadku połączenia proxy, należy

umieścić w tym miejscu poniższy wpis.
#
eap
}

9.2.3 users
Poniżej przedstawiam fragment pliku konfiguracyjnego users.
Ustawiając dla danego użytkownika Auth-Type :=Reject sprawimy, że jego
połączenie zostanie odrzucone.
#
iuser Auth-Type := Reject
Reply-Message = "Twoje konto jest nieaktywne."

Poniżej przedstawiam sposób zablokowania dostępu dla grupy użytkowników. W

przykładzie poniżej jest to grupa "disabled".
#
DEFAULT Group == "disabled", Auth-Type := Reject
Reply-Message = "Twoje konto jest nieaktywne."

Poniżej zdefiniowane zostało konto testowe użytkownika. Podczas autentykacji

poniższego użytkownika jego dane identyfikacyjne zostaną przeczytane z tego pliku.
#
test User-Password == "test"

Przykładowe dane wejściowe dla użytkownika.

#
user1 Auth-Type := Local, User-Password == "test"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.16.10.10,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = "std.ppp",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP

Chcąc używać danych użytkownika rozdzielonych znakiem pustym, należy oba

człony nazwy użytkownika umieścić w podwójnym apostrofie.
#
"Jan Kowalski" Auth-Type := Local, User-Password == "haslo"
Reply-Message = "Hello, %u"

Konfiguracja użytkownika, który będzie musiał nawiązać ponowne połączenie z

serwerem.
#
user2 Auth-Type := Local, User-Password == "haslo"
Service-Type = Callback-Login-User,

80
 Login-IP-Host = 0.0.0.0,
Callback-Number = "9,5551212",
Login-Service = Telnet,
Login-TCP-Port = Telnet

Konfiguracja użytkownika, który po nawiązaniu ponownego połączenia zostanie

zalogowany do hosta host1.
#
userdbk Auth-Type := Local, User-Password == "haslo"
Service-Type = Callback-Login-User,
Login-IP-Host = host1,
Login-Service = PortMaster,
Callback-Number = "9,0-100-222-3322"

Poniższy użytkownik otrzyma stały adres IP.

#
user3 Service-Type == Framed-User, Huntgroup-Name == "warsaw"
Framed-IP-Address = 192.168.1.5,
Fall-Through = Yes

Wszyscy użytkownicy, których nazwa kończy się na ".shell" otrzymają dostęp do

zasobów sieci.
#
DEFAULT Suffix == ".shell", Auth-Type := System
Service-Type = Login-User,
Login-Service = Telnet,
Login-IP-Host = host.shell

Poniższa konfiguracja daje możliwość stworzenia grup użytkowników na podstawie

których użytkownicy zostaną przydzieleni do określonego vlanu. Dynamiczny przydział
vlanów odbywa się na podstawie atrybutów takich jak: Tunnel-Type, Tunnel-Medium-Type
oraz Tunnel-Private. Atrybut Fall-Through ustawiony na wartość 1 sprawia, że kolejne wpisy
DEFAULT zostaną odczytane.
DEFAULT Auth-Type := System, Group == "vlan3"
Tunnel-Type = "VLAN",
Tunnel-Medium-Type = "IEEE-802",
Tunnel-Private-Group-Id = 3,
Fall-Through = 1

DEFAULT Auth-Type := System, Group == "isep"

Tunnel-Type = "VLAN",
Tunnel-Medium-Type = "IEEE-802",
Tunnel-Private-Group-Id = 2,
Fall-Through = 1

DEFAULT Auth-Type := System, Group == "stud"

Tunnel-Type = "VLAN",
Tunnel-Medium-Type = "IEEE-802",
Tunnel-Private-Group-Id = 4000,
Fall-Through = 1

DEFAULT Auth-Type := System, Group == "vlan4"

Tunnel-Type = "VLAN",
Tunnel-Medium-Type = "IEEE-802",
Tunnel-Private-Group-Id = 4000,
Fall-Through = 1

81
 Poniższy wpis zapewnia możliwość autentykacji wszystkim użytkownikom
posiadającym konta systemowe.
#
DEFAULT Auth-Type = System
Fall-Through = 1

Poniżej zawarłem dodatkowe przykłady konfiguracji dla użytkowników.

Domyślne reguły dla użytkowników chcących korzystać z protokołu Framed-User.
#
DEFAULT Service-Type == Framed-User
Framed-IP-Address = 255.255.255.254,
Framed-MTU = 576,
Service-Type = Framed-User,
Fall-Through = Yes

Domyślne reguły dla użytkowników chcących korzystać z protokołu PPP.

#
DEFAULT Framed-Protocol == PPP
Framed-Protocol = PPP,
Framed-Compression = Van-Jacobson-TCP-IP

Domyślne reguły dla użytkowników chcących korzystać z protokołu SLIP.

#
#DEFAULT Hint == "SLIP"
# Framed-Protocol = SLIP

Domyślne reguły dla użytkowników chcących korzystać z usługi Rlogin.

#
DEFAULT
Service-Type = Login-User,
Login-Service = Rlogin,
Login-IP-Host = host.domena

Domyślne reguły dla użytkowników chcących korzystać z usługi Rlogin.

#
DEFAULT
Service-Type = Shell-User

Ostatnim ważnym plikiem konfiguracyjnym jest plik przechowujący dane o klientach

mogących korzystać z RADIUS serwera w celu dokonania autentykacji użytkowników. Jest
to plik clients.conf. Jego postać przedstawiam poniżej. Konfiguracja zapisana w tym pliku
nadpisuje wszystkie zmiany wprowadzone w plikach "clients" lub "naslist".
#
# clients.conf

Struktura wpisów w pliku clients.conf jest następująca.

#
client adres_IP {
secret = haslo
shortname = identyfikator
nastype = typ
login = root
password = adminpass
}

Gdzie client jest nazwą naszego klienta, adres_IP to jego adres sieciowy lub nazwa
domenowa, secret jest hasłem klienta (do 32 znaków długości), shortname jest nazwą

82
skrótową klineta. Kolejne trzy pola czyli nastype, login oraz password są opcjonalne.
Wykorzystywane są przez skrypt checkrad.pl. Pole nastype oznacz typ urządzenia NAS.
Dopuszczalne wartości:
a) cisco
b) computone
c) livingston
d) max40xx
e) multitech
f) netserver
g) pathras
h) patton
i) portslave
j) tc
k) usrhiper
l) other - wszystkie pozostałe urządzenia.

Poniżej znajduje się wpis dla localhost. Wpis ten używany jest do testów serwara
RADIUS. Po wykonaniu testów zaleca się wykomentować konfigurację dotyczącą localhosta.
#
client 127.0.0.1 {
secret = password
shortname = localhost

Dla localhosta nastype będzie miało wartość other.

#
nastype = other
}

Poniżej zdefiniowane zostały wpisy dla switcha.

#
client 192.168.30.155 {
secret = password
shortname = switch4400
}

Można także definiować podsieć do jakiej należą klienty RADIUS serwera.

Przykładowy wpis znajduje się poniżej.
#
client 192.168.0.0/24 {
secret = password1
shortname = podsiec
}

#}
client 194.29.144.17 {
secret = 8105220005181
shortname = AP1100
}

client 192.168.30.155 {
secret = testtest
shortname = switch4400
}

83
client 192.168.30.156 {
secret = testtest
shortname = switch4400
}

client 192.168.30.159 {
secret = testtest
shortname = switch4400
}

client 192.168.30.160 {
secret = testtest
shortname = switch4400
}

84
Rozdział 10

Protokół autentykacji EAP.

W celu dokonania autentykacji w bezpieczny sposób należ posłużyć się protokołem
autentykacji, który nam to umożliwi. musimy przenieść hasło użytkownika w bezpieczny
sposób. W przypadku RADIUS serwera wykorzystany został protokół EAP (Extensible
Authentication Protocol) [8]. Protokół EAP wykorzystywany jest głównie w sieciach gdzie
pracuje protokół PPP (Point to Point Protocol)[14], lub sieciach bezprzewodowych z
protokłem IEEE 802. Protokół EAP został jednak rozszerzony na sieci wykorzystujące
protokół Ethernet i nazwany EAPOE (Extensible Authentication Protocol Over Ethernet).
Protokół EAP jest protokołem transportowym zoptymalizowanym na autentykację.
Jest to swoistego rodzaju platforma umożliwiająca nam wykorzystanie wielu metod
autentykacji. Protokół EAP pozwala na przeniesienie tylko danych autentykacyjnych
użytkownika. Gdy dane użytkownika zostaną zweryfikowane i okaże się, że może on uzyskać
dostęp do sieci wówczas port zostaje otwarty.
Metody autentykacji, obsługiwane przez serwer RADIUS[3]:
1. EAP-MD5-Challenge (Message Digest Algorithm 5) – prosta metoda autentykacji
oparta na loginie i haśle.
2. EAP-LEAP (Lightweight EAP). Prosty protokół autentykacji oparty o hasło i login
użytkownika. Rozwijany przez firmę Cisco. Nie jest to bezpieczna metoda autentykajci.
3. EAP-TLS (EAP-Tunneled Layer Secure). Autentykacjia odbywa się dzięki
tunelowanemu połączniu pomiędzy użytkownikiem i serwerem, wewnątrz którego strony
wymieniają się certyfikatami.
4. EAP-TTLS (EAP-Tunneled Transport Layer Secure). Jest protokołem
bezpiecznym. Sesja jest tunelowana. Wewnątrz tunelu możemy użyć dowolnej metody
autentykcji.
5. EAP-PEAP (Protected EAP). Protokół podobnie jak EAP-TTLS wykorzystuje
tunelowane połączenie, wewnątrz którego przesyłane jest hasło przy użyciu innej metody
autentykacji.
6. EAP-MSCHAPv2 (EAP-Microfost Challenge Handshake Authentication Protocol)
jest prostym protokołem autentykacyjnym. Często wykorzystywany wewnątrz protokołu
PEAP.
Zdecydowałem się na wybór protokołu EAP-TTLS, gdyż jest on najbezpieczniejszy.
Niestety nie jest on domyślnie obsługiwana przez system Microsoft Windows®. Należy
zatem odpowiednio przygotować maszynę użytkownika by mogła współpracować z RADIUS
serwerem, wykorzystując protokuł autentykacji EAP-TTLS.

85
Rozdział 11

Oprogramowanie użytkownika.
Chcąc używać protokołu autentykacji EAP-TTLS niezbędnym jest użycie po stronie
użytkownika oprogramowania które umożliwi nam zastosowanie tej metody autentykacji.
System Windows ® niestety nie oferuje domyślnie możliwości autentykacji przy użycji
protokołu EAP-TTLS. Dlatego jako oprogramowania użytkownika użyłem aplikacji
SecureW2 firmy ALFA&ARISS.
Oprogramowanie to jest bezpłatne i dostępne na stronie www.securew2.com/uk/.
Szczegółowy opis konfiguracji instalacji oraz konfiguracji oprogramowania secureW2
umożliwiającego bezpiczną autentykację użytkownikom systemów Windows® umieściłem na
stronie internetowej:
www.isep.pw.edu.pl/radius/
Znajduje się tam zarówno szczegółowy jak i szybki przewodnik po oprogramowaniu
secureW2.

11.1 Certyfikaty.
Wybierając protokół autentykacyjny EAP-TTLS musimy mieć także wygenerowane
certyfikaty zarówno dla użytkonika jak i dla serwera. W poniższym rozdziale zaprezentuję jak
wygenerować takie certyfikaty.
W celu wygenerowania certyfikatów niezbędnym będzie nam oprogramowanie
OpenSSL, dostępne na stronie domowej projektu OpenSSL: www.openssl.org.
Generacja certyfikatów.
Pierwszym krokiem jaki należy wykonać podczas generacji certyfikatów to
wyedytować plik openss.cnf znajdujący się w /usr/local/ssl/ w celu wprowadzenia
niezbędnych zmien.
Poniżej przedstawiam linie, które należy wyedytować i wprowadzić następujące
zmiany.
Liczba dni ważności certyfikatów.
default_days = 3650
Domyślna nazwa kraju.
countryName_default = PL
Domyślna nazwa województwa.
stateOrProvinceName_default = mazowieckie
Domyślna nazwa lokalizacji.
localityName_default = Warsaw
Domyślna nazwa instytucji.
0.organizationName_default = Warsaw University of Technology
Domyślne dane instytutu.
organizationalUnitName_default = Electrical Engineering -
Control Division
Domyślna nazwa certyfikatu.
commonName_default = ElectricalEngineeringCA
Adres kontaktowy osoby odpowiedzialnej za certyfikat.
emailAddress_default = cichockm@ee.pw.edu.pl

86
 Generacji certyfikatów można dokonać ręcznie, ewentualnie uruchamiając skrypt
CA.sh znajdujący się w /usr/local/ssl/misc/. Przed uruchomieniem skryptu należy dokonać w
nim następujących zmian.
Wykomentowujemy poniższą linię.
if [ -z "$OPENSSL" ]; then OPENSSL=openssl; fi
Następnie dodajemy po wykomentowanej wcześniej linii dwie poniższe.
Lokalizacja pliku z binariami oprogramowania openssl.
OPENSSL="/usr/local/ssl/bin/openssl"
Lokalizacja pliku konfiguracyjnego.
SSLEAY_CONFIG="-config /usr/local/ssl/openssl.cnf"
Można tu także ustawić przez ile dni będą ważne generowane przez nas certyfikaty.
DAYS="-days 1825"

Po wstępnych przygotowaniach możemy przystąpić do tworzenia certyfikatów

Tworzenie Certificate Authority (CA):
Bedąc w katalogu /usr/local/ssl/misc/ wydajemy polecenie:
#./CA.sh –newca
Powinniśmy otrzymać następujące dane wyjściowe:

CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
...............................................................
++++++
....................................++++++
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
State or Province Name (full name) [mazowieckie]:
Locality Name (eg, city) [Warsaw]:
Organization Name (eg, company) [Warsaw University of
Technology]:
Organizational Unit Name (eg, section) [Electrical Engineering
- Control Division]:
Common Name (eg, YOUR name) [ElectricalEngineeringCA]:
Email Address [cichockm@ee.pw.edu.pl]:

Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password [haslo]:
An optional company name []:
Using configuration from /usr/local/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/./cakey.pem:

87
 Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 0 (0x0)
Validity
Not Before: May 28 21:35:14 2006 GMT
Not After : May 25 21:35:14 2016 GMT
Subject:
countryName = PL
stateOrProvinceName = mazowieckie
organizationName = Warsaw University of
Technology
organizationalUnitName = Electrical Engineering
- Control Division
commonName = ElectricalEngineeringCA
emailAddress = cichockm@ee.pw.edu.pl
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:

EB:29:60:B3:21:28:65:B1:86:5A:50:0F:19:7A:5B:47:AE:DC:77:31
X509v3 Authority Key Identifier:

keyid:EB:29:60:B3:21:28:65:B1:86:5A:50:0F:19:7A:5B:47:AE:DC:77:31

Certificate is to be certified until May 25 21:35:14 2016 GMT

(3650 days)

Write out database with 1 new entries

Data Base Updated

Następnie tworzymy Root Certification Authority Certificate, wydając polecenie:

# ./CA.sh –newcert

Oto wyjście po wydaniu polecenia:

Generating a 1024 bit RSA private key

.++++++
.................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----

88
 Country Name (2 letter code) [PL]:
State or Province Name (full name) [mazowieckie]:
Locality Name (eg, city) [Warsaw]:
Organization Name (eg, company) [Warsaw University of
Technology]:
Organizational Unit Name (eg, section) [Electrical Engineering
- Control Division]:
Common Name (eg, YOUR name) [ElectricalEngineeringCA]:
Email Address [cichockm@ee.pw.edu.pl]:
Certificate is in cacert.pem, private key is in cakey.pem

W ten sposób wygenerowaliśmy pliki cacert.pem, oraz cakey.pem. Znajdują się one w
/usr/local/ssl/misc/demoCA/
Kolejnym krokiem jest prośba o podpisanie certyfikatu. Realizujemy ją poprzez
wydanie polecenia:

# ./CA.sh -newreq

Oto wyjście:

Generating a 1024 bit RSA private key

...................++++++
...++++++
writing new private key to '/newkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PL]:
State or Province Name (full name) [mazowieckie]:
Locality Name (eg, city) [Warsaw]:
Organization Name (eg, company) [Warsaw University of
Technology]:
Organizational Unit Name (eg, section) [Electrical Engineering
- Control Division]:
Common Name (eg, YOUR name) [ElectricalEngineeringCA]:
Email Address [cichockm@ee.pw.edu.pl]:

Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password [qaz123]:
An optional company name []:
Request is in newcerts/newreq.pem, private key is in
newcerts/newkey.pem

89
 Wygenerowany plik newreq.pem znajduje się w
/usr/local/ssl/misc/demoCA/newcerts/newreq.pem natomiast klucz prywatny w
/usr/local/ssl/misc/demoCA/newcerts/newkey.pem
Ostatnim krokiem jest podpisanie wygenerowanego certyfikatu. Podpisujemy
wcześniej wygenerowanym Certificate Authority (CA).
Czynności tej dokonujem przy użyciu polecenia:
# ./CA.sh -sign
Using configuration from /usr/local/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Signed certificate is in newcert.pem
Po wygenerowaniu certyfikatów należy pliki cacert.pem, newcert.pem, newkey.pem
umieścić w katalogu /usr/local/radius/raddb/certs/.

11.2 Dostosowanie maszyny użytkownika.

Oprogramowanie secureW2 możena pobrać bezpłatnie ze strony domowej programu
www.securew2.com/uk. Ponieważ konfiguracja opgrogramowania wraz z instalacją
certyfikatów mogłaby okazać się dość kłopotliwa, zbudowałem specjalny pakiet instalacyjny,
dzięki któremu użytkownik w prosty sposób dostosuje swój komputer do współpracy z
serwerem RADIUS.
Pakiet instalacyjny zawierający potrzebne certyfikaty, program secureW2 oraz jego
konfigurację stworzyłem dzięki innemu darmowemu oprogramowaniu "Nullsoft Scriptable
Install System" w skrócie NSIS. Oprogramowanie to można pobrać na stronie:
http://nsis.sourceforge.net/Main_Page.
Oprogramowanie NSIS jest profesjonalnym narzędziem pozwalającym na tworzenie
instalatorów dla środowiska operacyjnego Windows®. NSIS jest narzędziem umożliwiającym
tworzenie bardzo skomplikowanych instalatorów, jednocześnie jego niewielkie rozmiary
pozwalają na swobodną dystrybucję i łatwe rozpowszechnianie za pośrednictwem internetu.
NSIS pozwala na tworzenie instalatorów umożliwiających nam instalację,
deinstalację, dokonywanie ustawień systemowych, oraz wiele innych rozwiązań. Używając
oprogramowania NSIS możemy w prosty sposób zaimplememtować dowolną strukturę
logiczną naszego instalatora.
Na stronie domowej oprogramowania w zakładce Developer Center
(http://nsis.sourceforge.net/Developer_Center) mamy dostęp do przykładów skryptów,
wtyczek oraz rozwiązań implementowanych podczas tworzenia instalatorów dla środowiska
Windows®.
Szczgółowy przewodnik po oprogramowaniu NSIS dostarczony jest wraz z
oprogramowaniem. Po instalacji NSIS-a mamy dostęp do bardzo szczegółowej pomocy.
Możemy przeczytać o możliwościach NSIS-a, a także przeczytać o składni jakiej będziemy
używać podczas pisania skryptów naszych kompilatorów.
Skrypt tworzący instalator oprogramowania SecureW2.

Nazwa pliku wyjściowego.

OutFile "instal.exe"

Włączenie trybu cichego instalacji.

SilentInstall silent

Deklaracja zmiennej lokalnej.

Var ServiceName

90
 Główna sekcja skryptu.
Section "MainSection"

Definicja tymczasowego folderu, gdzie składniki naszego instalatora zostaną

wypakowane, a następnie uruchomione.
SetOutPath $TEMP

Definicja składnieków naszego instalatora.

File SecureW2_312.exe
File cacert.der
File default.reg
StrCpy $0 0

Definicja pętli, która sprawdzi wszystkie zainstalowane karty sieciowe w naszym

komputerze.
loopNICs:
EnumRegKey $1 HKLM "SOFTWARE\Microsoft\Windows
NT\CurrentVersion\NetworkCards\" $0
StrCmp $1 "" doneNICs
IntOp $0 $0 + 1

Zapis nazwy karty sieciowej do zmiennej lokalnej.

ReadRegStr $serviceName HKLM "SOFTWARE\Microsoft\Windows
NT\CurrentVersion\NetworkCards\$1" ServiceName
DeleteRegValue HKLM
"SOFTWARE\Microsoft\EAPOL\Parameters\Interfaces\$serviceName" "1"
ClearErrors

Zapis wartości rejestru

WriteRegBin HKLM
"SOFTWARE\Microsoft\EAPOL\Parameters\Interfaces\$serviceName" "1"
0500000…00000
IfErrors 0 +2
MessageBox MB_OK "Error writing to registry"

StrCmp "" "" loopNICs

doneNICs:

Uruchomienie instalatora programu SecureW2

Exec '"$TEMP\SecureW2_312.exe"'

Uruchomienie pliku rejestru, w którym zapisana jest poprawna konfiguracja

oprogramowani SecureW2.
ExecShell "open" "$TEMP\default.reg"

SectionEnd

91
Rozdział 12

Bibliografia
[1] W. Richard Stevens:
"Biblia TCP/IP tom 1" Warszawa 1998.
[2] Scott Mueller:
"Rozbudowa i naprawa sieci" wydanie 2 Gliwice, Helion 2004.
[3] Freeradius:
http://www.freeradius.org/
[4] Authentication, Authorization and Accounting (aaa):
http://www.ietf.org/html.charters/aaa-charter.html
[5] Remote Authentication Dial In User Service (RADIUS) – RFC2865:
http://www.ietf.org/rfc/rfc2865.txt
[6] RADIUS Accounting - RFC2866:
http://rfc.net/rfc2866.html
[7] RADIUS Attributes for Tunnel Protocol Support RFC2868:
http://rfc.net/rfc2868.html
[8] Extensible Authentication Protocol (EAP) - RFC3748:
http://www.ietf.org/rfc/rfc3748.txt
[9] 802.1X Port-Based Authentication HOWTO:
http://www.tldp.org/HOWTO/8021X-HOWTO/
[10] PPP EAP TLS Authentication Protocol – RFC2716:
http://www.ietf.org/rfc/rfc2716.txt
[11] Internet X.509 Public Key Infrastructure Certificate and CRL Profile – RFC2459:
http://www.ietf.org/rfc/rfc2459.txt
[12] SSL Certificates HOWTO:
http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/
[13] The MD5 Message-Digest Algorithm:
http://rfc.net/rfc1321.html
[14] The Point-to-Point Protocol (PPP)
http://rfc.net/rfc1661.html
[15] Serial Line IP
http://rfc.net/rfc1055.html
[16] PPP Authentication Protocols
http://rfc.net/rfc1334.html
[17] PPP Challenge Handshake Authentication Protocol (CHAP)
http://rfc.net/rfc1994.html
[18] User Datagram Protocol
http://rfc.net/rfc0768.html
[19] Simple Network Management Protocol (SNMP)
http://rfc.net/rfc1157.html
[20] ASSIGNED NUMBERS
http://rfc.net/rfc1700.html

92