Konfiguracja i testowanie serwera RADIUS na Sophos Firewall

RADIUS łączy Sophos Firewall z Microsoft NPS, bramą MFA lub inną centralną usługą uwierzytelniania. Najpierw należy przygotować system zdalny i ścieżkę sieciową. Następnie tworzy się serwer w sekcji Authentication > Servers i przypisuje go w sekcji Authentication > Services wyłącznie do wymaganych usług logowania. Test odbiorczy obejmuje rzeczywiste logowanie oraz kontrolę użytkownika, grupy i reguły.

Do standardowego pobierania informacji o użytkownikach i grupach z domeny Windows często lepiej nadaje się bezpośrednia integracja Active Directory z Sophos Firewall. W nowoczesnych scenariuszach dostępu zdalnego właściwszą architekturą może być Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. Jeśli zapora ma rozpoznawać już uwierzytelnionych użytkowników sieci Wi-Fi na podstawie przychodzących pakietów księgowania, obowiązuje inna procedura: konfiguracja RADIUS SSO z księgowaniem na Sophos Firewall.

Kiedy warto używać RADIUS

Zapora wysyła nazwę użytkownika i dane logowania do serwera RADIUS. Tam źródło użytkowników, Network Policy oraz ewentualnie MFA decydują o odpowiedzi Access-Accept lub Access-Reject. Dopiero potem lokalna grupa użytkowników, polityka VPN i reguły zapory określają, do których zasobów użytkownik uzyska dostęp.

Typowe zastosowania to:

• Remote Access VPN z Microsoft NPS lub usługą MFA;
• centralne logowanie do User Portal, VPN Portal lub Captive Portal;
• rozwiązanie przejściowe, gdy AD lub LDAP nie ma być połączone bezpośrednio z zaporą;
• wiele urządzeń sieciowych korzystających z tej samej usługi RADIUS.

Firmowa sieć WLAN zarządzana przez zaporę wymaga dodatkowo wyboru serwera w sekcji Wireless > Wireless settings. Pełną procedurę 802.1X opisano zatem w artykule Konfiguracja sieci WLAN bezpośrednio na Sophos Firewall.

Zapisanie stanu początkowego i drogi powrotu

Przed zmianą usługi produkcyjnej należy w sekcji Authentication > Services zanotować dla każdego obszaru objętego zmianą:

• wybrane serwery i ich kolejność;
• stan opcji Set authentication methods same as firewall, Same as VPN lub Same as firewall;
• dotychczasową wartość Default group dla uwierzytelniania zapory;
• użytkownika, dla którego dotychczasowa metoda działa w sposób potwierdzony.

Podczas zmiany logowania administratorów należy pozostawić otwartą istniejącą sesję WebAdmin. Trzeba także sprawdzić lokalnego superadministratora przez dozwoloną już ścieżkę zarządzania. Wybór serwerów dla administratorów nie dotyczy tego superadministratora, jednak zewnętrznego logowania administracyjnego nigdy nie należy przełączać bez potwierdzonej lokalnej drogi powrotu.

Planowanie połączenia RADIUS

Role, ścieżka sieciowa i protokoły

W środowisku NPS zapora Sophos Firewall jest klientem RADIUS, a NPS — serwerem RADIUS. NPS sprawdza żądanie zgodnie z zasadami Connection Request Policy i Network Policy, a zazwyczaj także w Active Directory. O faktycznym dostępie nadal decyduje następnie reguła VPN lub reguła zapory.

Ogólna pomoc do SFOS 22 opisuje komunikację między zaporą a serwerem RADIUS z użyciem protokołu PAP. W sekcji Authentication > Services Sophos wymienia jednak dla połączeń L2TP i PPTP protokoły PAP, CHAP oraz MSCHAPv2. Taka macierz protokołów nie potwierdza dostępności tych samych metod dla IPsec ani innych ścieżek logowania. Dlatego usługę, klienta i metodę dozwoloną na serwerze RADIUS trzeba sprawdzić łącznie.

Klasyczny RADIUS korzysta z UDP, a udokumentowany formularz SFOS nie zawiera pól TLS ani certyfikatów. Ruch powinien zatem przebiegać kontrolowaną ścieżką wewnętrzną lub inną odpowiednio zabezpieczoną trasą. Silny Shared Secret nie zastępuje segmentacji ani ścisłego ograniczenia komunikacji między zaporą a serwerem RADIUS.

Starsze systemy zdalne mogą oczekiwać innych portów, na przykład 1645/UDP i 1646/UDP. Decydujące są porty rzeczywiście skonfigurowane po obu stronach, a nie te historyczne wartości.

Świadomy wybór przykładowych wartości

W tej instrukcji użyto następujących wartości:

• nazwa serwera NPS-HQ-RADIUS;
• adres IP serwera 10.20.30.15;
• port Authentication 1812;
• port Accounting 1813;
• Time-out 5 sekund;
• Domain name corp.example.

Wartości 10.20.30.15 i corp.example należy zastąpić adresem wewnętrznym oraz własną konwencją nazewnictwa. Pięć sekund to wartość początkowa do bezpośredniego sprawdzania hasła, a nie wartość domyślna Sophos. W przypadku powiadomienia push, połączenia telefonicznego lub zewnętrznego wyzwania wartość musi mieścić się w dozwolonym przez SFOS zakresie od 1 do 60 sekund oraz odpowiadać dostawcy i rzeczywistemu klientowi.

Shared secret jest wspólnym sekretem technicznym klienta i serwera RADIUS, a nie hasłem użytkownika. Sophos ogranicza jego długość do 48 znaków. Wartość należy przekazać oddzielnym, chronionym kanałem, bezpiecznie przechowywać i wprowadzić identycznie po obu stronach; sam protokół RADIUS nie przesyła sekretu przez sieć.

Dodawanie serwera RADIUS w sekcji Authentication

Ścieżka menu to Authentication > Servers.

1. Otwórz Add i w polu Server type wybierz RADIUS server.
2. W polu Server name wpisz na przykład NPS-HQ-RADIUS.
3. W polu Server IP wpisz wewnętrzny adres IP serwera RADIUS, w tym przykładzie 10.20.30.15.
4. Ustaw Authentication port zgodnie z konfiguracją serwera, zwykle na 1812.
5. Ustaw Time-out. W pierwszym bezpośrednim teście w tym przykładzie użyto 5 sekund.
6. Włącz Enable accounting tylko wtedy, gdy system zdalny ma przetwarzać dane księgowania. W takim przypadku uzgodnij także Accounting port, zwykle 1813.
7. Wprowadź Shared secret dokładnie w takiej postaci jak w systemie zdalnym.
8. Opcjonalnie ustaw Domain name. Przy równoległym użyciu AD i RADIUS spójna domena zapobiega utworzeniu różnych lokalnych obiektów użytkownika dla tej samej osoby.
9. Group name attribute wprowadź tylko wtedy, gdy system zdalny w sposób potwierdzony zwraca oczekiwany atrybut. Pomoc Sophos określa go jako alias skonfigurowanej nazwy grupy, ale nie dokumentuje w tym miejscu ogólnego mapowania dowolnych atrybutów NPS na grupy lokalne.
10. Enable additional settings otwórz wyłącznie wtedy, gdy wymaga tego odpowiednia polityka. NAS-identifier identyfikuje serwer dostępu do sieci (Network Access Server), który wysyła żądanie, na przykład za pomocą nazwy FQDN. NAS-port-type określa typ portu używanego do logowania.
11. Uruchom Test connection z własnym użytkownikiem pilotażowym, a następnie wybierz Save.

Zapora obsługuje łącznie maksymalnie 20 skonfigurowanych serwerów uwierzytelniania. Dla każdej metody uwierzytelniania w sekcji Authentication > Services również można wybrać maksymalnie 20 serwerów.

Właściwa interpretacja księgowania

Po włączeniu Enable accounting zapora wysyła dla obsługiwanych typów klientów komunikat Accounting-Start podczas logowania, a przy zwykłym wylogowaniu — komunikat Accounting-Stop. Sophos wymienia następujące typy: Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client oraz API client.

Podczas wyłączania lub ponownego uruchamiania zapory komunikat Accounting-Stop nie jest wysyłany. Jeśli sesja na serwerze RADIUS pozostaje otwarta, należy więc porównać czas restartu z logami RADIUS. Ta funkcja wychodzącego księgowania nie jest tym samym co przychodzące księgowanie RADIUS SSO, za pomocą którego zapora poznaje sesje z innych systemów.

Przygotowanie Microsoft NPS jako systemu zdalnego

W NPS zapora Sophos Firewall musi być skonfigurowana jako klient RADIUS. Minimalna lista kontroli w konsoli Network Policy Server wygląda następująco:

1. Otwórz RADIUS Clients and Servers > RADIUS Clients.
2. Utwórz New RADIUS Client z jednoznaczną wartością Friendly name, na przykład Sophos-Firewall-HQ.
3. W polu Address (IP or DNS) wpisz adres, z którego NPS rzeczywiście otrzymuje żądanie.
4. Jako Vendor wybierz zwykle RADIUS standard.
5. Wprowadź ten sam Shared secret co na zaporze.
6. W odpowiednich zasadach Connection Request Policy i Network Policy sprawdź warunki, decyzję o dostępie i metodę uwierzytelniania dozwoloną dla użytkownika pilotażowego.
7. Przygotuj Event Viewer i logi księgowania NPS do testów odbiorczych.

W przypadku klastrów HA, połączeń routowanych lub NAT nie wolno zgadywać adresu klienta NPS na podstawie topologii. Pierwszy test pokaże w NPS, jaki źródłowy adres IP rzeczywiście dociera do serwera. Jeśli żądanie w ogóle nie dociera albo NPS nie może go zweryfikować, należy najpierw sprawdzić routing, regułę zezwalającą na UDP, adres klienta RADIUS oraz Shared Secret. Zwykła odpowiedź Access-Reject wskazuje natomiast na problem z użytkownikiem, polityką lub metodą uwierzytelniania.

Przypisywanie RADIUS do właściwych usług

Po zapisaniu obiekt serwera nie jest jeszcze aktywny dla żadnego logowania. W SFOS 22 w sekcji Authentication > Services dostępne są następujące obszary:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

Dla User Portal, VPN Portal, VPN oraz administratorów wybór serwera może być powiązany z uwierzytelnianiem zapory. SSL VPN udostępnia opcje Same as VPN i Same as firewall. Przed zmianą należy więc sprawdzić, czy dany obszar korzysta z własnej listy, czy z listy powiązanej.

W ograniczonym pilotażu dodaj NPS-HQ-RADIUS wyłącznie w wymaganym obszarze, ustaw go na zaplanowanej pozycji i wybierz Apply. Zapora odpytuje wiele serwerów w wyświetlonej kolejności. Jeśli ten sam użytkownik może już pomyślnie zalogować się za pośrednictwem wcześniejszego serwera, późniejsza polityka RADIUS MFA nie zostanie wywołana.

Captive Portal i Default Group

Captive Portal nie ma własnego obszaru w sekcji Authentication > Services. Korzysta z Firewall authentication methods. Ponadto przewidziana strefa musi mieć w sekcji Administration > Device access włączony dostęp Captive portal, a reguła zapory oparta na użytkownikach musi być odpowiednio skonfigurowana. Oficjalnym testem działania jest logowanie pod adresem https://<firewall-ip>:8090.

Wartość Default group w obszarze Firewall authentication methods ma znaczenie dla bezpieczeństwa. Po pierwszym pomyślnym zalogowaniu użytkownika zewnętrznego do usługi zapory w sekcji Authentication > Users tworzony jest jego obiekt. Jeśli nie ma odpowiedniego przypisania do grupy lokalnej, stosowana jest skonfigurowana Default Group. Przed pilotażem należy sprawdzić polityki tej grupy oraz wszystkie reguły, w których jest używana; grupa domyślna ze zbyt szerokimi uprawnieniami nie może niepostrzeżenie stać się mechanizmem zapasowym.

Ograniczenia challenge MFA zależnie od usługi

Zgodnie z pomocą SFOS 22 VPN Portal nie obsługuje uwierzytelniania RADIUS z MFA opartym na wyzwaniu. Pomyślny wynik Test connection nie potwierdza więc działania tej ścieżki portalowej. Mechanizmy push, połączenie telefoniczne, OTP i challenge również nie są zamienne: każdy przewidziany klient i każdą usługę trzeba testować oddzielnie. Dla lokalnego MFA na Sophos Firewall obowiązuje osobna procedura: Włączanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Testy odbiorcze konfiguracji

1. Połączenie i system zdalny

W sekcji Authentication > Servers otwórz NPS-HQ-RADIUS i uruchom Test connection z użytkownikiem pilotażowym. Jednocześnie sprawdź w NPS lub logach innego systemu zdalnego, czy:

• żądanie pochodzi z oczekiwanego adresu zapory;
• przetwarza je właściwa polityka;
• wynikiem jest Access-Accept;
• zwrócone zostały oczekiwane atrybuty.

Test potwierdza dane logowania i komunikację z serwerem. Nie potwierdza jeszcze kolejności usług, polityki VPN, grupy lokalnej ani reguły zapory.

2. Test rzeczywistej usługi

Następnie zaloguj tego samego użytkownika dokładnie przez docelową usługę. Dla Captive Portal, SSL VPN, IPsec, User Portal i WebAdmin obowiązują różne wymagania. W przypadku WebAdmin użytkownik zewnętrzny musi dodatkowo otrzymać przewidziany profil administratora; samo pomyślne uwierzytelnienie RADIUS nie nadaje uprawnień administracyjnych. Niewymagane ścieżki należy pozostawić bez zmian. W przypadku SSL VPN artykuł Konfiguracja Sophos Firewall SSL VPN Remote Access omawia politykę, Device Access i regułę zapory.

Po pomyślnym zalogowaniu sprawdź:

1. W sekcji Authentication > Users lokalnego użytkownika, domenę i faktyczną wartość Main Group.
2. W sekcji Current activities > Live users aktywną sesję; w razie potrzeby można ją zakończyć opcją Disconnect.
3. W prawym górnym rogu WebAdmin otwórz Log viewer, wybierz moduł Authentication i zastosuj filtr według użytkownika, źródłowego adresu IP oraz wąskiego przedziału czasu testu.
4. W logu ruchu sprawdź rzeczywisty identyfikator Firewall Rule ID oraz dostęp wyłącznie do dozwolonego zasobu docelowego.
5. Sprawdź przypadek negatywny z użytkownikiem spoza dozwolonej polityki NPS.

Jeśli logowanie działa, ale aplikacja jest nieosiągalna, należy sprawdzić strefę, pulę adresów IP VPN, grupę, pozycję reguły, NAT i routing. Artykuł Reguła Sophos Firewall nie jest stosowana: sprawdzanie przyczyn prowadzi przez diagnostykę tej ścieżki danych. Jeśli niejasne są już tożsamość, wybór usługi lub Main Group, pomocna będzie instrukcja Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall.

Zawężanie przyczyn błędów na podstawie objawów

System zdalny nie otrzymuje żadnego żądania

Najpierw sprawdź wartości skonfigurowane w polach Server IP i Authentication port. Następnie skontroluj routing i zezwolenie na ruch UDP 1812 między adresem źródłowym używanym przez zaporę a adresem 10.20.30.15. Obiekt serwera RADIUS nie tworzy automatycznie reguły zapory dla ruchu tranzytowego.

Dla sieci bezprzewodowej zarządzanej przez SFOS Sophos dokumentuje szczególny przypadek serwera RADIUS za tunelem IPsec, obejmujący ruch generowany przez system i ewentualnie System Traffic NAT. W odniesieniu do innych ścieżek RADIUS instrukcja dotycząca sieci bezprzewodowej nie potwierdza takiego ogólnego zachowania. W obu przypadkach należy sprawdzić faktycznie używany adres źródłowy i eskalować zmianę routingu lub NAT, zamiast bez weryfikacji kopiować regułę LAN-do-VPN.

NPS odpowiada Access-Reject

Odpowiedź Reject wskazuje, że ścieżka sieciowa i port zasadniczo działają. Należy teraz sprawdzić w NPS wartość Reason Code, właściwą zasadę Network Policy, stan użytkownika oraz dozwoloną metodę uwierzytelniania. Nieprawidłowy Shared Secret prowadzi natomiast do braku odpowiedzi albo odpowiedzi nieprawidłowej lub niemożliwej do zweryfikowania.

Test connection działa, ale logowanie do usługi nie

W sekcji Authentication > Services sprawdź właściwy obszar, przełącznik powiązania, kolejność serwerów oraz użycie opcji Apply. W przypadku Captive Portal sprawdź dodatkowo Device access i regułę zapory opartą na użytkownikach. Dla SSL VPN muszą być prawidłowe: Policy Member, dostęp SSL VPN w sekcji Device Access oraz wymagana reguła zapory.

Logowanie działa, ale stosowana jest niewłaściwa grupa

Sprawdź domenę i Main Group w sekcji Authentication > Users. Następnie porównaj Group name attribute, atrybuty zwracane przez system zdalny i Default group. Pomyślne uwierzytelnienie nie jest dowodem prawidłowej autoryzacji. Dlatego trzeba potwierdzić, że użytkownik użyty w teście negatywnym zostaje odrzucony przez warunek grupy lub polityki NPS.

Push lub challenge kończy się przekroczeniem limitu czasu

Użyj rzeczywistego klienta i porównaj znaczniki czasu w logach zapory, NPS oraz dostawcy MFA. Zwiększ limit czasu SFOS wyłącznie w zakresie od 1 do 60 sekund i wybierz najmniejszą wartość, która niezawodnie obejmuje zwykły przebieg wyzwania. Opartego na wyzwaniu RADIUS MFA w VPN Portal nie da się naprawić dłuższym limitem czasu, ponieważ Sophos nie obsługuje tej ścieżki.

Bezpieczne wycofanie zmian

Jeśli pilotaż się nie powiedzie, w odpowiednim obszarze sekcji Authentication > Services przywróć wcześniej zapisaną listę serwerów wraz z ich kolejnością, ustawienia przełączników powiązań oraz wartość Default group, a następnie wybierz Apply. Potem zaloguj użytkownika porównawczego przy użyciu pierwotnej metody i sprawdź lokalnego superadministratora.

Dopiero gdy wszystkie objęte zmianą usługi znów działają, usuń NPS-HQ-RADIUS z pozostałych przypisań usług. Obiekt serwera w sekcji Authentication > Servers należy usunąć tylko wtedy, gdy nie jest już planowane żadne jego użycie. W NPS przywróć klienta, politykę i Shared Secret do udokumentowanego stanu początkowego. Utworzone wcześniej lokalne obiekty użytkowników wymagają osobnej kontroli; ich usunięcie nie kończy automatycznie każdej istniejącej sesji, dlatego trzeba również sprawdzić Current activities > Live users.

Eksploatacja

RADIUS jest produkcyjną usługą tożsamości. Po zmianach w NPS, u dostawcy MFA, w AD lub kolejności usług test odbiorczy musi obejmować rzeczywiste logowanie pozytywne i negatywne. Shared Secret należy bezpiecznie udokumentować i rotować zgodnie z planem. Dla systemu zdalnego trzeba skonfigurować monitoring i określić czas przechowywania logów decyzji. Dzięki temu można ustalić, czy błąd wystąpił przed zaporą, podczas uwierzytelniania, czy dopiero na etapie autoryzacji.

FAQ