Konfiguracja serwera RADIUS w Sophos Firewall

RADIUS jest ważnym łącznikiem między Sophos Firewall a istniejącymi usługami uwierzytelniania. Typowe przykłady to Microsoft NPS, brama MFA, Identity Provider z interfejsem RADIUS albo centralna platforma uwierzytelniania używana już dla VPN, Wi-Fi lub innych usług sieciowych.

Ten artykuł wyjaśnia, jak dodać serwer RADIUS w Authentication > Servers, które pola są ważne, jak przygotować Microsoft NPS jako drugą stronę i jak potem przetestować konfigurację. Dla klasycznych zapytań o użytkowników i grupy z domeny Windows często lepsze jest połączenie Active Directory z Sophos Firewall. Dla nowoczesnych scenariuszy Remote Access lepiej może pasować Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

Kiedy RADIUS ma sens

RADIUS jest przydatny, gdy Sophos Firewall nie ma samodzielnie obsługiwać całej logiki tożsamości. Firewall wysyła zapytanie do serwera RADIUS. Serwer RADIUS decyduje, czy nazwa użytkownika, hasło, warunek grupy, MFA lub policy pasują.

Typowe zastosowania:

• Remote Access VPN z Microsoft NPS.
• Zewnętrzne MFA przez RADIUS.
• Centralne uwierzytelnianie dla VPN Portal, SSL VPN, IPsec Remote Access lub Captive Portal.
• Rozwiązanie przejściowe, gdy AD/LDAP nie ma być podłączone bezpośrednio do firewalla.
• Środowiska mieszane z kilkoma urządzeniami sieciowymi korzystającymi z tej samej usługi RADIUS.

RADIUS nie zastępuje czystych reguł dostępu. Po udanym uwierzytelnieniu nadal muszą pasować reguły firewall, strefy VPN, grupy, pule IP i logowanie. Dla Remote Access pasuje konfiguracja Sophos Firewall SSL VPN Remote Access, a dla projektów MFA aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Zaplanować przed konfiguracją

Przed kliknięciem Add musi być jasne, jaką rolę pełni RADIUS. Inaczej test połączenia może się udać, ale produkcyjne logowanie później zawiedzie przez złą usługę, grupę albo timeout.

Źródło tożsamości i druga strona

W środowiskach Microsoft RADIUS to często serwer Microsoft NPS. NPS może sprawdzać użytkowników w Active Directory, oceniać Network Policies i zapisywać accounting. W praktyce Sophos Firewall jest RADIUS client, a serwer NPS jest RADIUS server.

Role:

• Sophos Firewall: wysyła żądanie uwierzytelnienia.
• Serwer RADIUS: sprawdza użytkownika, hasło, policy i opcjonalnie MFA.
• Active Directory lub Identity Provider: dostarcza użytkowników i grupy w tle.
• Reguła firewall lub konfiguracja VPN: decyduje, dokąd użytkownik może wejść po logowaniu.

Ścieżka sieciowa i porty

Serwer RADIUS musi być osiągalny z firewalla.

Starsze środowiska lub pojedyncze produkty mogą używać 1645/UDP i 1646/UDP. Należy je przejąć tylko wtedy, gdy druga strona naprawdę tego oczekuje.

Shared secret i timeouty

Shared secret to techniczny wspólny sekret między firewallem a serwerem RADIUS. Nie jest to hasło użytkownika. Sophos podaje dla tego pola limit 48 znaków.

Timeout musi pasować do zastosowania. Przy samej kontroli hasła często wystarcza krótka wartość. Przy Push-MFA, telefonie lub zewnętrznym challenge zbyt krótki timeout może przerwać logowanie mimo poprawnych danych. Sophos dopuszcza wartości Time-out od 1 do 60 sekund.

Dodać serwer RADIUS w Sophos Firewall

Ścieżka menu:

Authentication > Servers

Kroki:

1. Otworzyć Add.
2. Jako Server type wybrać RADIUS server.
3. Nadać jednoznaczny Server name, na przykład NPS-HQ-RADIUS albo MFA-RADIUS.
4. W Server IP wpisać adres IP serwera RADIUS.
5. Sprawdzić Authentication port, zwykle 1812.
6. Ustawić Time-out. Dla prostych loginów 3 do 5 sekund może wystarczyć; dla MFA zwykle więcej, zależnie od dostawcy.
7. Enable accounting aktywować tylko wtedy, gdy serwer RADIUS ma przetwarzać accounting.
8. Jeśli accounting jest aktywny, sprawdzić Accounting port, zwykle 1813.
9. Wpisać Shared secret dokładnie tak jak na serwerze RADIUS.
10. Opcjonalnie ustawić Domain name, zwłaszcza gdy AD i RADIUS działają równolegle.
11. Opcjonalnie wpisać Group name attribute, jeśli serwer RADIUS zwraca użyteczne informacje o grupach.
12. W razie potrzeby otworzyć Enable additional settings i ustawić NAS-identifier lub NAS-port-type.
13. Uruchomić Test connection z realnym użytkownikiem testowym.
14. Zapisać.

Test połączenia potwierdza podstawową komunikację. Nie dowodzi jednak, że VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal lub WebAdmin działają w produkcyjnym przepływie. Te usługi trzeba testować osobno.

Świadomie ustawić Domain name

Pole Domain name jest ważne w środowiskach mieszanych. Jeśli RADIUS działa bez domeny, a Active Directory tworzy użytkowników z domeną, na firewallu mogą pojawić się podwójne lokalne wpisy użytkowników.

Gdy AD i RADIUS działają równolegle, warto ustawić właściwy Domain name i potem sprawdzić w Authentication > Users, jak pojawiają się nowi użytkownicy.

Nie zgadywać Group name attribute

Group name attribute musi pasować do drugiej strony. Przy NPS lub integracjach MFA zależy to od atrybutów, które serwer RADIUS rzeczywiście zwraca, i od tego, jak firewall ma je oceniać.

Jeśli grupa jest ważna, należy przetestować cały przepływ:

1. Zalogować użytkownika do docelowego portalu lub VPN.
2. Sprawdzić w Authentication > Users, czy użytkownik pojawia się z oczekiwaną grupą.
3. W Log Viewer sprawdzić, jaka reguła firewall i jaki użytkownik są widoczne dla ruchu.
4. Przy NPS sprawdzić także Event Viewer i Network Policy.

Przygotować Microsoft NPS jako drugą stronę

Jeśli używany jest Microsoft NPS, Sophos Firewall musi zostać wpisany na serwerze NPS jako RADIUS client. W konsoli NPS służy do tego RADIUS Clients and Servers > RADIUS Clients.

Minimalny przebieg:

1. Otworzyć Network Policy Server.
2. Otworzyć RADIUS Clients and Servers > RADIUS Clients.
3. Utworzyć New RADIUS Client.
4. Wpisać Friendly name, na przykład Sophos-Firewall-HQ.
5. W Address (IP or DNS) wpisać IP Sophos Firewall, z którego przychodzą żądania RADIUS.
6. Jako Vendor zwykle użyć RADIUS standard.
7. Wpisać ten sam Shared secret co na Sophos Firewall.
8. Utworzyć lub sprawdzić Connection Request Policy i Network Policy.
9. Przygotować Event Viewer i logi NPS do testów.

Przy klastrach HA lub wielu firewallach trzeba sprawdzić, jaki adres źródłowy widzi NPS. Jeśli NPS widzi inny adres niż skonfigurowany RADIUS client, żądanie zostanie odrzucone albo nie trafi do oczekiwanej policy.

Aktywować RADIUS dla usług firewalla

Po zapisaniu serwer RADIUS nie jest automatycznie aktywny dla wszystkich logowań. Przypisanie odbywa się w:

Authentication > Services

Dla każdej usługi zdecydować, czy używa RADIUS:

• Firewall authentication methods: ogólne uwierzytelnianie firewalla.
• VPN portal authentication methods: logowanie do VPN Portal.
• SSL VPN authentication methods: logowanie SSL VPN.
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: właściwe metody Remote Access VPN.
• Captive portal authentication methods: logowanie przez Captive Portal.

Kolejność serwerów jest ważna. Jeśli wybrano kilka serwerów, firewall odpytuje je w skonfigurowanej kolejności. Może to być celowe, ale może też spowodować, że użytkownicy uwierzytelniają się przez AD zamiast RADIUS i MFA nie zadziała.

Walidacja po zapisaniu

Dobry test ma kilka poziomów. Sam Test connection nie wystarcza.

Test połączenia

Otworzyć serwer RADIUS w Authentication > Servers i uruchomić Test connection z użytkownikiem testowym. Jeśli test się nie uda, najpierw sprawdzić ścieżkę sieciową, IP źródłowe, Shared Secret, klienta NPS, port i hasło użytkownika.

Test usługi

Następnie przetestować realny przepływ:

1. Otworzyć VPN Portal z użytkownikiem testowym.
2. Zalogować się przez SSL VPN lub Sophos Connect z profilem testowym.
3. Przetestować Captive Portal, jeśli jest używany.
4. Przy dostępie administracyjnym sprawdzić lokalne uprawnienia admina, rolę i uwierzytelnienie.

Przy RADIUS-MFA trzeba przetestować pełny challenge lub push z realnym klientem. Udany test serwera nie dowodzi, że Sophos Connect, VPN Portal lub WebAdmin obsługują challenge tak samo.

Sprawdzić logi

Ważne miejsca:

• Log Viewer na Sophos Firewall dla decyzji uwierzytelnienia i ruchu.
• Authentication > Users dla automatycznie tworzonych użytkowników i grup.
• NPS Event Viewer w Windows dla zaakceptowanych lub odrzuconych żądań.
• Logi dostawcy RADIUS lub MFA, jeśli bierze udział strona trzecia.
• Logi reguł firewall, jeśli login działa, ale ruch nie jest dozwolony.

Jeżeli użytkownik jest uwierzytelniony, ale nie osiąga aplikacji, RADIUS zwykle nie jest już pierwszą przyczyną. Sprawdzić strefę VPN, pulę IP, regułę firewall, warunek grupy, NAT i routing. Do tego pasuje Sophos Firewall: sprawdzanie, dlaczego reguła nie pasuje.

Typowe błędy

Test connection nie działa

Częste przyczyny to zły adres źródłowy, błędny Shared Secret, zablokowany port UDP, brak RADIUS client w NPS albo policy NPS, która nie dopuszcza użytkownika testowego. W Windows warto sprawdzić Event Viewer.

Test connection działa, ale login VPN nie

Serwer RADIUS jest osiągalny, ale dana usługa prawdopodobnie nie jest poprawnie ustawiona na RADIUS. W Authentication > Services sprawdzić serwer dla VPN Portal, SSL VPN lub IPsec Remote Access oraz jego pozycję.

Push MFA przychodzi za późno albo wcale

Przy zewnętrznym MFA timeouty są często kluczowe. Timeout Sophos Firewall, policy NPS, brama MFA i klient muszą do siebie pasować. Przy Push-MFA lub telefonie nie należy zaczynać od agresywnych trzech sekund.

Użytkownik tworzy się podwójnie

Dzieje się tak często, gdy AD i RADIUS działają równolegle, a RADIUS pracuje bez Domain name. Sprawdzić Domain name, format logowania i kolejność serwerów.

Login działa, ale reguła nie pasuje

Wtedy trzeba sprawdzić matching użytkownika i grupy: zaimportowaną grupę, lokalny wpis użytkownika, pozycję reguły, source zone, pulę IP VPN i rzeczywisty ruch w Log Viewer.

Eksploatacja i bezpieczeństwo

RADIUS należy obsługiwać jak produkcyjną usługę tożsamości. Awaria serwera RADIUS może dotknąć Remote Access lub dostęp do portali.

Ważne punkty:

• Bezpiecznie dokumentować Shared Secret i świadomie rotować po zmianach personelu lub dostawcy.
• Przechowywać logi NPS lub RADIUS wystarczająco długo.
• Monitorować serwer RADIUS, nie tylko firewall.
• Testować timeouty MFA według typu klienta i portalu.
• Zdefiniować awaryjny dostęp admina, ale nie wystawiać go szeroko.
• Po zmianach w AD, NPS, dostawcy MFA lub usługach firewalla testować realny login.

RADIUS jest dobrym elementem, jeśli jest poprawnie eksploatowany. Bez monitoringu, jasnego przypisania serwera i realnych testów usług problemy logowania są tylko przeniesione z firewalla na inny system.

FAQ