Podstawowa konfiguracja RADIUS w IOS

Zapewnienie pełnej kontroli nad tym kto i w jaki sposób uzyskuje dostęp do systemów i zasobów jest istotnym element bezpieczeństwa sieci komputerowych. Warto w takim przypadku skorzystać z framework’a AAA. Jednym ze sposobów na jego wdrożenie jest zastosowanie serwera opartego o protokół RADIUS.  Sprawdźmy, jak możemy wykorzystać go na urządzeniach Cisco.

Dlaczego RADIUS?

AAA to akronim pochodzący od trzech angielskich słów: authentication, authorization, accounting. Pod tymi wyrazami kryją się funkcje istotne z punktu bezpieczeństwa sieci. Ich znaczenie opisaliśmy dokładnie w tym artykule. W skrócie natomiast można powiedzieć, że AAA to mechanizmy, które pozwalają kontrolować kto i w jaki sposób może korzystać z zasobów naszej sieci oraz umożliwiają monitorowanie tego dostępu.

Dwoma najczęściej wykorzystywanymi protokołami do implementacji AAA w sieciach są RADIUS i TACACS+. W tym materiale zajmiemy się pierwszym z nich.

Serwer AAA może pełnić różne funkcje. Jedną z funkcji serwera opartego o protokół RADIUS jest kontrola dostępu użytkowników, którzy chcą korzystać z naszej sieci. Rozwiązanie to może być wdrażane zarówno w sieciach przewodowych jak i WLAN. Nieco odmienną funkcją jest z kolei kontrolowanie dostępu administracyjnego na urządzeniach sieciowych. Właśnie tej drugiej funkcji przyjrzymy się bliżej i skonfigurujemy ją na urządzeniach.

Główną zaletą serwera AAA jest to, że posiada on centralną bazę, w której przechowywane są nazwy użytkowników oraz przypisane im hasła. Dzięki temu mamy zapewnioną scentralizowaną kontrolę nad tym kto uzyskuje dostęp do zasobów w sieci.

Lokalna konfiguracja kont użytkownika i haseł w przypadku dużych sieci korporacyjnych może okazać się koszmarem. Gdy ilość urządzeń sieciowych w firmie liczymy w setkach, to każdorazowa zmiana hasła lub dodanie nowego użytkownika paraliżowałaby pracę administratorów.

RADIUS stanowi rozwiązanie tego problemu. Nie tylko ułatwia pracę administratora, ale również sprawia, że zwiększa się poziom bezpieczeństwa w danej sieci.

Istotnym aspektem protokołu RADIUS może być również to, że jest on otwartym standardem, wspieranym na wszystkich dostępnych systemach operacyjnych. Dzięki temu istnieje wiele rozwiązań RADIUS, zarówno płatnych jak i darmowych, różniących się między sobą interfejsem i funkcjonalnością. Szeroki wybór pozwala na znalezienie rozwiązania dostosowanego do potrzeb firmy. Najpopularniejszą implementacją opensource jest FreeRADIUS i na jego bazie zbudujemy dziś nasz serwer AAA.

Działanie RADIUS’A

Jak wygląda logowanie się użytkownika do urządzenia sieciowego za pomocą serwera AAA?

Z poziomu użytkownika nie ma różnicy pomiędzy logowaniem lokalnym, a za pomocą serwera AAA. Użytkownik podaje login i hasło. Jeśli są prawidłowe to uzyskuje on dostęp.

Patrząc na cały proces to jest on oczywiście nieco bardziej rozbudowany.

Architektura AAA wymaga trzech komponentów:

1. Supplicant – suplikant to po prostu klient, czyli użytkownik, który próbuje uzyskać dostęp do systemu, w naszym przypadku urządzenia sieciowego Cisco.

2. Authenticator – to urządzenie pośredniczące w komunikacji między suplikantem, a serwerem. Możesz również spotkać się z terminem NAS (Network Access Server) co można przetłumaczyć jako serwer dostępowy.

3. Authentication server – Serwer uwierzytelniający. Ma on za zadanie kontrolować wszystkie funkcje związane z AAA. W artykule posługuję się wymiennie również pojęciami serwer AAA oraz serwer RADIUS.

Na schemacie przedstawia się to następująco:

Zwróć uwagę, że Klient komunikuje się ze switchem tradycyjnie za pomocą Telnetu lub SSH. Dla klienta działanie RADIUSA jest więc niewidoczne i nie wymaga po stronie klienta żadnej dodatkowej konfiguracji. Żądanie suplikanta jest przesyłane do serwera dostępowego NAS, w naszym przykładzie switcha Cisco. Dane te są następnie przekazywane przez NAS do serwera AAA. Na tym etapie do komunikacji wykorzystywany jest już protokół RADIUS. Serwer weryfikuje zapytanie z centralną bazą użytkowników. Po weryfikacji danych logowania przesyła on informację zwrotną do switcha.

Konfiguracja switcha

Konfiguracja będzie mieć na celu uzyskanie dostępu administracyjnego do switcha dla użytkownika, którego konto jest skonfigurowane na serwerze AAA.

Konfigurację przeprowadzimy na prostej topologii. Do switcha mamy podłączone dwa urządzenia. Pierwsze z nich to serwer RADIUS, który w przykładzie będzie postawiony na systemie Ubuntu Server 22.04 oraz oparty o darmowy serwer FreeRADIUS. Drugie to host, w tym przypadku pecet z systemem Windows 10 i klientem SSH PuTTY.

Przejdźmy do konfiguracji przełącznika. W pierwszej części zajmiemy się ustawieniami związanymi z komunikacją z serwerem RADIUS.

Zaczynamy od włączenia framework’a AAA:

Switch>
Switch>enable
Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#aaa new-model
Code language: plaintext (plaintext)

Następnie musimy wskazać, że uwierzytelnianie logowania do urządzenia będzie odbywać się w profilu domyślnym (default) oraz za pomocą grupy RADIUS:

Switch(config)#aaa authentication login default group radius
Switch(config)#aaa authorization exec default group radiusCode language: plaintext (plaintext)

Teraz możemy przejść do ustawień związanych z serwerem. Za pomocą polecenia radius server wskazujemy nazwę serwera, a w kolejnym kroku podajemy jego adres IP. Polecenie warto uzupełnić o numery portów używanych do zestawienia połączenia. Na niektórych urządzeniach może być wykorzystywana stara implementacja protokołu, która używa portów 1645 oraz 1646.

Dalej musimy wskazać klucz, który będzie służył do połączenia z serwerem – taki sam trzeba będzie skonfigurować również po stronie serwera. Zalecane jest oczywiście stosowanie najsilniejszego, dostępnego na urządzeniu mechanizmu szyfrowania haseł – ale na potrzeby prezentacji zastosujemy proste i przejrzyste hasło TYPE 7 (nieszyfrowane).

Switch(config)#radius server radius_srv1
Switch(config-radius-server)#address ipv4 10.1.1.2 auth-port 1812 acct-port 1813
Switch(config-radius-server)#key radius@nastykusieci
Switch(config-radius-server)#exit
Code language: plaintext (plaintext)

Tak jak wspomniałem wcześniej host będzie się łączyć z authenticatorem, czyli naszym switchem, za pomocą protokołu SSH. Musimy więc przygotować urządzenie do nawiązania połączenia zdalnego. W tym celu trzeba zmienić domyślną nazwę urządzenia, ustawić nazwę domeny, wygenerować klucze RSA oraz włączyć wersję drugą protokołu SSH:

Switch(config)#hostname SW1
SW1(config)#ip domain-name nastykusieci.pl
SW1(config)#crypto key generate rsa
The name for the keys will be: SW1.nastykusieci.pl
Choose the size of the key modulus in the range of 360 to 4096 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)

SW1(config)#
*Aug 23 20:37:41.090: %SSH-5-ENABLED: SSH 1.99 has been enabled
SW1(config)#ip ssh version 2
Code language: plaintext (plaintext)

Kolejną czynnością jest włączenie linii wirtualnych. W tym miejscu musimy wskazać, że do logowania będziemy używać stworzonego wcześniej profilu default:

SW1(config)#line vty 0 15
SW1(config-line)#transport input ssh
SW1(config-line)#login authentication default
SW1(config-line)#exit
Code language: plaintext (plaintext)

Pozostało nam jeszcze przydzielenie adresu IP, które w przypadku switcha wykonujemy na interfejsie wirtualnym (VLAN), a nie fizycznym:

SW1(config)#interface vlan 1
*Aug 23 20:48:07.794: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
SW1(config-if)#ip address 10.1.1.1 255.255.255.0
SW1(config-if)#no shutdown
SW1(config-if)#
*Aug 23 20:48:38.717: %LINK-3-UPDOWN: Interface Vlan1, changed state to up
*Aug 23 20:48:39.726: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Code language: plaintext (plaintext)

Konfiguracja serwera FreeRADIUS

Wszystkie ustawienia po stronie switcha zostały wykonane. Możemy teraz przejść do konfiguracji serwera uwierzytelniającego.

W systemie zostały już przypisane ustawienia sieciowe zgodnie z topologią, więc konfigurację zaczynamy od instalacji FreeRADIUS:

sudo apt-get install freeradiusCode language: plaintext (plaintext)

Sprawdźmy czy serwer zainstalował się poprawnie i jest aktywny. Możemy to wykonać za pomocą polecenia:

systemctl status freeradius.serviceCode language: plaintext (plaintext)

Widzimy, że serwer ma status active (running), więc wszystko jest ok.

Konfiguracja będzie polegać na edycji plików clients.conf oraz users. W naszej wersji RADIUSA znajdują się one w folderze /etc/freeradius/3.0/:

Plik client.conf odpowiada za wszystkie ustawienia związane z serwerem dostępowym NAS. Zobaczmy za pomocą edytora nano jak wygląda zawartość pliku:

sudo nano /etc/freeradius/3.0/clients.confCode language: plaintext (plaintext)

Jak widzisz plik nie jest pusty. Zawiera on instrukcję konfiguracji klienta. Mamy również już wstępnie zdefiniowane konto localhost, które możemy wykorzystać do weryfikacji funkcjonowania serwera. Wiersze zaczynające się od symbolu hash są wyróżnione niebieską czcionką. Są to komentarze, które nie mają wpływu na konfigurację. Właściwa część związana z konfiguracją wyróżniona jest czcionką w kolorze białym. Ustawienia związane z naszym switchem obejmują adres IP, klucz (ten sam, który został skonfigurowany na urządzeniu) oraz ustawienia rodzaju NAS, w tym przypadku Cisco. W pozostałych polach zostawiamy wartości domyślne:

client SW1 {
ipaddr = 10.1.1.1
secret = radius@nastykusieci
proto = *
require_message_authenticator = 0
nas_type = cisco
}Code language: plaintext (plaintext)

Teraz możemy przejść do pliku users i konfiguracji użytkowników, którym nadamy dostęp administracyjny do naszego urządzenia. Sprawdźmy co jest zapisane w pliku:

sudo nano /etc/freeradius/3.0/usersCode language: plaintext (plaintext)

Tutaj również plik zawiera instrukcję odnośnie konfiguracji kont użytkowników. Skonfigurujemy więc konto własnego użytkownika o nazwie raduser1 z hasłem rad1@nss.

raduser1 Cleartext-password := "rad1@nss"Code language: plaintext (plaintext)

Konto zostało zapisane – czas na testowanie.

Testowanie konfiguracji

Sprawdźmy czy wszystko działa.

Na naszym testowym kliencie uruchamiamy PuTTY. Dla przypomnienia – oto topologia, na której się tu opieramy:

W polu Host Name wpisujemy adres IP switcha, z którym chcemy się połączyć i zaznaczamy Connection Type jako SSH.

Następnie przechodzimy do uwierzytelniania:

Po podaniu nazwy użytkownika i hasła udało się zalogować do switcha SW1. Użytkownik ma jednak dostęp jedynie do trybu EXEC mode. Poziom uprawnień dla użytkownika wynosi 1, więc nie ma możliwości przejścia do trybu uprzywilejowanego.

RADIUS – privileged level 15

Aby user mógł zalogować się do trybu privileged musimy dodatkowo wskazać, że ma mieć on przydzielone wyższe uprawnienia. Utwórzmy więc nowego użytkownika raduser2, który będzie miał pełny dostęp administracyjny:

raduser2 Cleartext-password := "rad2@nss"
Service-Type = NAS-Prompt-User,
Cisco-AVPair := "shell:priv-lvl=15"Code language: plaintext (plaintext)

Widzimy, że użytkownik automatycznie zalogował się do trybu uprzywilejowanego. Polecenie show privilege potwierdza, że uprawnienia zostały przypisane prawidłowo.