Konfiguracja RADIUS SSO z accountingiem na Sophos Firewall

RADIUS SSO loguje użytkownika do Sophos Firewall bez dodatkowego captive portalu. Użytkownik uwierzytelnił się już w sieci bezprzewodowej, na serwerze dostępu do sieci lub w innym systemie RADIUS. Następnie firewall otrzymuje pakiet accountingu RADIUS z nazwą użytkownika i adresem IP klienta i może wykorzystać to mapowanie w regułach opartych na użytkownikach.

Decydujące znaczenie ma nie tylko udane logowanie 802.1X. Firewall musi otrzymać użyteczny Accounting-Start dokładnie od skonfigurowanego nadawcy. W przypadku Wi-Fi SSO Sophos używa Framed-IP-Address z tego pakietu startowego. Jeżeli brakuje adresu IP klienta, firewall może znać nazwę użytkownika, ale nie potrafi przypisać jej do ruchu.

⚠️ RADIUS SSO nie jest tym samym co Enable accounting w obiekcie serwera RADIUS. W Authentication > Servers opcja Enable accounting oznacza, że firewall wysyła accounting do serwera RADIUS. W Authentication > Services > SSO using RADIUS accounting request firewall odbiera accounting od klienta RADIUS i tworzy z niego mapowanie użytkownik-IP.

Aktualna procedura Sophos potwierdza ten przebieg dla punktów dostępowych APX zarządzanych przez SFOS. Nie stanowi ogólnego potwierdzenia dla AP6 ani dowolnych kontrolerów innych producentów. Dla innej platformy przed wdrożeniem produkcyjnym należy potwierdzić u producenta i w razie potrzeby w Sophos Support obsługę tej samej ścieżki proxy i atrybutów. Technicznie poprawny pakiet testowy sam nie rozszerza udokumentowanego zakresu wsparcia.

Szybka procedura

1. W oficjalnie opisanym wariancie użyć APX z 802.1X i skonfigurować serwer accountingu RADIUS jako proxy do firewalla.
2. Określić rzeczywistego nadawcę, adres docelowy firewalla, port UDP 1813 i silny shared secret.
3. W Authentication > Services > SSO using RADIUS accounting request wprowadzić adres IP nadawcy i shared secret.
4. W Administration > Device access zezwolić na usługę RADIUS SSO tylko temu nadawcy i na właściwy adres firewalla.
5. Przygotować ściśle ograniczoną regułę użytkownika z Match known users i logowaniem.
6. Połączyć rzeczywistego klienta i sprawdzić pakiet accountingu na firewallu.
7. W Current activities > Live users sprawdzić typ klienta RADIUS SSO, użytkownika i prawidłowy adres IP klienta.
8. Dopiero potem przetestować dozwolony i celowo niedozwolony ruch z oczekiwanym Firewall Rule ID.

Kiedy RADIUS SSO jest odpowiedni

RADIUS SSO szczególnie dobrze pasuje do sieci Wi-Fi 802.1X lub systemów dostępu do sieci, w których uwierzytelnianie odbywa się już poza firewallem. Firewall może wtedy rozpoznać użytkownika bez drugiego logowania w przeglądarce.

Procedura wymaga jednoznacznej zależności między użytkownikiem i adresem IPv4. Typowe warunki to:

• Klient otrzymuje adres IPv4, który Sophos Firewall widzi również jako źródło ruchu.
• Nadawca accountingu zna nazwę użytkownika i ten adres IP klienta.
• Accounting start dociera bezpośrednio do adresu firewalla bez nieoczekiwanej zmiany źródłowego NAT.
• Nadawca RADIUS potrafi dostarczyć Framed-IP-Address w pakiecie startowym.
• Obiekty użytkowników lub grup oraz odpowiednia reguła firewalla zostały już zaplanowane.

RADIUS SSO nie zastępuje STAS na Sophos Firewall, gdy źródłem tożsamości są zdarzenia logowania Windows z Active Directory. Nie rozróżnia też wielu użytkowników za tym samym adresem IP RDS lub Citrix. Zależnie od ruchu lepiej sprawdzi się SATC dla Remote Desktop Services albo AD SSO per connection przez direct web proxy.

Kiedy przerwać procedurę

Nie aktywować produkcyjnie, dopóki którykolwiek z tych punktów pozostaje niewyjaśniony:

• Pakiet accountingu nie zawiera nazwy użytkownika lub Framed-IP-Address.
• Adres zgłoszony w pakiecie różni się od źródłowego adresu IP widzianego później przez firewall w ruchu użytkowym.
• Wielu użytkowników współdzieli ten sam adres IP klienta.
• NAT, HA lub routing uniemożliwia jednoznaczne określenie rzeczywistego nadawcy albo adresu docelowego firewalla.
• Klient RADIUS może użyć tylko całej niezaufanej sieci zamiast stałego adresu źródłowego.
• Strategia reguł dla nieznanych lub wylogowanych użytkowników nie jest jasna.

Zrozumienie ścieżki accountingu

Przy klasycznym uwierzytelnianiu RADIUS firewall wysyła Access-Request do serwera RADIUS. W RADIUS SSO kierunek jest odwrotny:

1. Klient uwierzytelnia się w APX zarządzanym przez SFOS za pośrednictwem serwera RADIUS wybranego w Wireless > Wireless settings.
2. APX wysyła accounting przez firewall do tego serwera. Serwer działa też jako proxy accountingu i przekazuje komunikat z powrotem do firewalla.
3. Sophos Firewall odbiera przekazany pakiet w usłudze RADIUS SSO.
4. Jeżeli adres IP nadawcy odpowiada RADIUS client IPv4, a shared secret jest poprawny, firewall przetwarza komunikat.
5. Nazwa użytkownika i Framed-IP-Address pojawiają się jako mapowanie w Live users.
6. Dopiero późniejszy ruch użytkowy może trafić na regułę z Match known users.

W oficjalnym wariancie APX serwer RADIUS jest zarówno celem uwierzytelniania i accountingu, jak i proxy przekazującym pakiety accountingu APX do firewalla. NPS wymaga więc odpowiedniej konfiguracji proxy RADIUS. Dla RADIUS client IPv4 liczy się źródłowy adres IP przekazanego pakietu. Ogólna deklaracja „obsługuje RADIUS Accounting” nie dowodzi ani wsparcia tej architektury, ani obecności nazwy użytkownika i IP klienta w accounting start.

Kompletny przykład

W instrukcji użyto następujących wartości przykładowych:

• Nadawca RADIUS lub accountingu: 10.10.20.15
• Adres firewalla dla RADIUS SSO: 10.10.20.1
• Klient Wi-Fi: 10.30.40.50
• Docelowy port accountingu: UDP 1813
• Użytkownik: EXAMPLE\alex.muster
• Reguła użytkownika: RADIUS-SSO-WiFi-Out

Adresy pochodzą z prywatnych sieci przykładowych i należy je zastąpić rzeczywistymi sieciami zarządzającymi, serwerowymi i klienckimi. W polu RADIUS client IPv4 nie wpisuje się automatycznie adresu IP serwera uwierzytelniania, lecz źródłowy adres IP faktycznie widoczny w packet capture na firewallu.

Przygotowanie systemu zewnętrznego

W oficjalnie opisanej architekturze APX należy osobno sprawdzić uwierzytelnianie, accounting do serwera RADIUS i drogę powrotną proxy do firewalla. Udane logowanie 802.1X nie dowodzi, że serwer RADIUS przekazuje accounting do Sophos Firewall.

System zewnętrzny należy przygotować co najmniej następująco:

1. Skonfigurować APX i sieć Wi-Fi 802.1X w Wireless, a następnie wybrać serwer RADIUS w Wireless > Wireless settings.
2. Włączyć accounting na serwerze RADIUS i skonfigurować go jako proxy do adresu firewalla 10.10.20.1.
3. Do przekazywania do firewalla użyć UDP 1813.
4. Skonfigurować osobny silny shared secret dla tej ścieżki.
5. Wysyłać accounting start dopiero, gdy znany jest adres IP klienta.
6. Zapewnić obecność nazwy użytkownika i Framed-IP-Address.
7. Udokumentować źródłowy adres IP, routing i ewentualną translację NAT w kierunku interfejsu firewalla.

Accounting stop lub update może usprawnić utrzymanie sesji w niektórych produktach. Publiczna dokumentacja Sophos wyraźnie wskazuje jednak adres IP z accounting start jako podstawę logowania dla Wi-Fi SSO. Późniejszy update nie może więc zastępować kompletnego pakietu startowego jako kryterium sukcesu.

W instalacjach APX zarządzanych przez SFOS znaczenie może mieć czas DHCP. Sophos dokumentuje radius_accounting_start_delay w zakresie od 0 do 60 sekund. Oficjalny przykład dla Device Console ustawia 30 sekund:

system wireless-controller global radius_accounting_start_delay 30

30 to wartość przykładowa, a nie uniwersalna wartość domyślna. Przed zmianą należy uruchomić system wireless-controller global show i zapisać bieżącą wartość. Parametr zmieniać tylko wtedy, gdy capture pokazuje accounting start przed przydzieleniem IP. Podczas rollbacku uruchomić polecenie ustawiające z zapisaną wartością. Jeśli wynosiła ona 0 (brak opóźnienia), dokładne polecenie rollbacku to system wireless-controller global radius_accounting_start_delay 0. Oficjalne źródła nie podają uniwersalnej wartości domyślnej, dlatego nie wolno jej zakładać, gdy poprzednia wartość jest nieznana. Sophos wskazuje też use_tunneled_reply dla FreeRADIUS; ta opcja należy do serwera FreeRADIUS i nie powinna być bez potwierdzenia przenoszona do NPS. Ogólna konfiguracja Wi-Fi znajduje się w artykule Konfiguracja Wireless Network na Sophos Firewall.

Informacje o wersji AP6 wymieniają WIFIX-5189, naprawiony problem z framed IP w pakietach accountingu. Procedura RADIUS SSO ogranicza jednak opisany wariant do APX. Poprawka AP6 nie jest zatem dowodem wsparcia tej konfiguracji.

Konfiguracja RADIUS SSO na Sophos Firewall

Wprowadzanie nadawcy i shared secret

Ścieżka menu:

Authentication > Services > SSO using RADIUS accounting request

Procedura:

1. W RADIUS client IPv4 dodać oczekiwany w capture adres IP nadawcy 10.10.20.15.
2. Wprowadzić uzgodniony dla tej ścieżki Shared secret.
3. Dodatkowych nadawców dodawać wyłącznie jako osobne, udokumentowane wpisy.
4. Wybrać Apply.

W tej sekcji SFOS 22 udostępnia tylko RADIUS client IPv4 i Shared secret; nie ma osobnego ustawienia portu. RADIUS SSO uwzględnia wyłącznie pakiety ze skonfigurowanych adresów IPv4. Cała sieć lub dowolny adres źródłowy nie jest rozsądnym zamiennikiem brakującego planu nadawcy.

Sama konfiguracja odbiornika nie tworzy serwera RADIUS w Authentication > Servers. Oficjalny wariant APX wymaga jednak dodania tam zewnętrznego serwera RADIUS i wybrania go w Wireless > Wireless settings; ten etap opisuje ogólna konfiguracja serwera RADIUS na Sophos Firewall. Wychodzące uwierzytelnianie i accounting oraz przekazane komunikaty RADIUS SSO pozostają oddzielnymi ścieżkami.

Ścisłe zezwolenie w Device Access

RADIUS SSO jest lokalną usługą firewalla. Zwykła reguła LAN-to-WAN lub WiFi-to-WAN nie otwiera tej ścieżki odbioru.

W Administration > Device access są dwie prawidłowe możliwości:

• Jeśli strefa nadawcy jest mała i w pełni zaufana, aktywować RADIUS SSO w macierzy stref.
• Jeśli przewidziano tylko jeden stały system zewnętrzny, pozostawić dostęp strefy wyłączony i utworzyć ukierunkowaną Accept Local service ACL exception rule dla adresu IP nadawcy, używanego adresu firewalla i usługi RADIUS SSO.

Dodatkowy wyjątek accept nie ogranicza już aktywnego zezwolenia strefowego. Aby wyjątek był naprawdę wąski, RADIUS SSO musi pozostać wyłączony w danej strefie. Pełną procedurę opisuje Device Access i Local Service ACL.

Przygotowanie reguły użytkownika

Do pierwszego testu nie jest potrzebna szeroka reguła produkcyjna. Wąska reguła zapewnia bardziej jednoznaczne wyniki:

1. W Rules and policies > Firewall rules utworzyć regułę nad bardziej ogólnymi regułami WiFi lub LAN.
2. Ograniczyć Source Zone i Source Network do rzeczywistej sieci klientów.
3. Wybrać tylko użytkownika pilotażowego lub przygotowaną grupę pilotażową.
4. Włączyć Match known users.
5. Zezwolić tylko na nieszkodliwą usługę testową lub jasno określony cel.
6. Włączyć Log firewall traffic.
7. Określić drugą, celowo niedozwoloną kombinację użytkownika lub celu do testu negatywnego.

RADIUS SSO dostarcza tożsamość, ale nie ogólne zezwolenie na dostęp do sieci. Tworzenie reguł firewalla na Sophos Firewall wyjaśnia współdziałanie użytkowników, grup, usług i logowania.

Kontrolowany odbiór RADIUS SSO

1. Potwierdzenie pakietu accountingu na firewallu

W Diagnostics > Packet capture ustawić filtr dla adresu IP nadawcy 10.10.20.15, adresu firewalla 10.10.20.1 i UDP 1813. Następnie ponownie połączyć dokładnie jednego klienta pilotażowego.

Capture musi co najmniej potwierdzić:

• Źródłowy adres IP to skonfigurowany RADIUS client IPv4.
• Miejscem docelowym jest planowany adres firewalla.
• Port docelowy to UDP 1813.
• Pojawia się accounting start dla użytkownika pilotażowego.
• Framed-IP-Address odpowiada aktualnemu adresowi IP klienta 10.30.40.50.

RADIUS accounting zawiera dane o tożsamości i sesji, które mogą być widoczne w pakiecie. Pliki capture należy traktować jak logi uwierzytelniania, przechowywać krótko i nie udostępniać bez zabezpieczenia. Ogólną obsługę opisuje Packet Capture na Sophos Firewall.

2. Kontrola Live User

W Current activities > Live users użytkownik, adres IP klienta i typ klienta muszą się zgadzać. W tej procedurze oczekiwanym typem klienta jest RADIUS SSO.

Widoczny użytkownik z błędnym adresem IP nie oznacza częściowego sukcesu. Reguły użytkowników dopasowują później rzeczywiste źródło ruchu, a nie oczekiwane mapowanie Wi-Fi.

3. Korelacja logu uwierzytelniania

W Log Viewer wyszukać użytkownika pilotażowego i czas zdarzenia. Do głębszej analizy służy access_server.log, ponieważ Sophos przetwarza w nim uwierzytelnianie, autoryzację i accounting użytkowników.

W HA każdy węzeł przechowuje tylko logi ruchu, który sam przetworzył. Należy sprawdzić węzeł, który odebrał accounting podczas testu. Kontrola usług i logów Sophos Firewall przez CLI wyjaśnia, jak odczytać i zabezpieczyć access_server.log bez niekontrolowanego restartu usługi.

4. Test pozytywny i negatywny

Za pomocą klienta pilotażowego należy osobno sprawdzić cztery elementy:

1. Dozwolony cel trafia na oczekiwany Firewall Rule ID i pokazuje prawidłowego użytkownika.
2. Cel celowo niedozwolony pozostaje zablokowany.
3. Nieprzypisany użytkownik nie otrzymuje dostępu pilotażowego.
4. Po nowym połączeniu lub kontrolowanym roamingu mapowanie użytkownika, IP i reguły pozostaje prawidłowe.

Test musi używać rzeczywistego ruchu użytkowego. Sam wpis Live User nie dowodzi dopasowania reguły, routingu ani drogi powrotnej. Powtarzalną procedurę opisuje Niezawodne testowanie reguł firewalla.

Rozwiązywanie problemów według objawu

Żaden pakiet accountingu nie dociera do firewalla

Najpierw sprawdzić docelowy adres IP, port UDP, routing i konfigurację systemu zewnętrznego. Następnie sprawdzić Device Access lub Local Service ACL Exception Rule. Udane logowanie RADIUS na NPS lub w sieci Wi-Fi nie dowodzi, że istnieje oddzielna ścieżka accountingu do firewalla.

Jeżeli pakiet dociera z innym adresem źródłowym, zbadać dokładnie tę przyczynę. Nie zezwalać pochopnie na całą sieć jako klienta RADIUS. W przypadku NAT lub HA trzeba udokumentować i precyzyjnie dopuścić stabilny adres nadawcy, który jest faktycznie widoczny.

Accounting dociera, ale Live Users pozostaje pusty

Wspólnie sprawdzić shared secret, adres IP nadawcy i zawartość pakietu. Szczególnie ważne są accounting start, nazwa użytkownika i Framed-IP-Address. Jeśli brakuje IP klienta, najpierw poprawić punkt dostępowy, kontroler lub proxy RADIUS. Restart usługi firewalla nie tworzy brakującego atrybutu.

Dopiero gdy pakiet jest kompletny, a access_server.log nadal nie przetwarza zdarzenia, zabezpieczyć czas, capture, CTR i logi węzła dla Sophos Support. Nie usuwać bazy uwierzytelniania ani nie czyścić Live Users na próbę.

Użytkownik pojawia się z błędnym adresem IP

Często wskazuje to na zbyt wczesny komunikat accountingu, stare mapowanie DHCP, roaming lub inną ścieżkę NAT. Odłączyć klienta, zapisać aktualną dzierżawę i przechwycić pojedyncze nowe połączenie. Decydujący jest adres IP w nowym accounting start.

W sieci bezprzewodowej zarządzanej przez SFOS zmieniać radius_accounting_start_delay dopiero po takim dowodzie i z udokumentowaną poprzednią wartością. Punkty dostępowe i kontrolery innych firm używają własnych mechanizmów accountingu i DHCP; parametr Sophos wireless nie zmienia tych urządzeń.

Live User jest poprawny, ale reguła nie pasuje

Ścieżka accountingu działa wtedy lepiej niż polityka. Sprawdzić Source Zone, Source Network, użytkownika lub grupę, Match known users, kolejność reguł, Firewall Rule ID i rzeczywisty adres IP ruchu. Jeśli pasuje reguła #0 lub ogólna, poprawić politykę zamiast zmieniać shared secret.

Użytkownik pozostaje widoczny po wylogowaniu

Najpierw sprawdzić, czy system zewnętrzny wysyła accounting stop i czy pakiet dotyczy tej samej sesji i mapowania użytkownika. Następnie skorelować Live User, bieżący ruch klienta i access_server.log. Ręczne rozłączenie może chwilowo usunąć stan, ale nie dowodzi poprawności automatycznego procesu.

Po restarcie firewalla klienci APX muszą według Sophos rozłączyć się i połączyć ponownie, aby nowy accounting start odtworzył logowanie. Jeśli w regule użytkownika włączono Show captive portal to unknown users, portal może pojawić się początkowo; w opisanym wariancie APX logowanie staje się przezroczyste po ustawionym opóźnieniu accountingu, bez ponownego podawania danych logowania.

Bezpieczeństwo, HA i eksploatacja

RADIUS accounting używa UDP i nie chroni transportu jak TLS. Shared secret uwierzytelnia ścieżkę RADIUS, ale nie szyfruje wszystkich atrybutów tożsamości i sesji. Accounting powinien więc działać w zaufanej sieci zarządzającej lub serwerowej i nie powinien przechodzić przez obce sieci bez ochrony.

W eksploatacji obowiązują następujące granice:

• Dla każdego nadawcy używać osobnego silnego shared secret i udokumentowanego właściciela.
• Zezwalać na RADIUS SSO tylko z wymaganych stref i najlepiej tylko ze stałych hostów.
• Traktować pliki capture, logi RADIUS i access_server.log jako osobowe dane operacyjne.
• Zmiany DHCP, kontrolera Wi-Fi, NPS, proxy RADIUS lub NAT kończyć nowym testem end-to-end.
• W HA nie obiecywać nieprzerwanego utrzymania mapowania użytkownika. Po planowanym failover sprawdzić nowy accounting start, Live User i rzeczywisty ruch na węźle przetwarzającym.
• Nieznanych użytkowników lub brakujące mapowania obsługiwać bezpieczną regułą domyślną, a nie szeroką regułą allow.

Rollback

Rollback odbywa się w kolejności, która nie pozostawia otwartej usługi accountingu i nie przyznaje użytkownikom niezamierzonego dostępu:

1. Przywrócić wcześniejszą strategię uwierzytelniania i reguł dla sieci pilotażowej.
2. Wyłączyć regułę pilotażową i przeprowadzić test negatywny z nieznanym użytkownikiem.
3. Usunąć z serwera RADIUS cel przekazywania proxy do firewalla albo przywrócić udokumentowany poprzedni stan proxy. Nie usuwać celu accountingu APX, jeśli serwer RADIUS jest nadal potrzebny do uwierzytelniania i accountingu Wi-Fi.
4. Usunąć nadawcę w SSO using RADIUS accounting request.
5. Wycofać wyjątek ACL RADIUS SSO lub tymczasowe zezwolenie strefowe.
6. Ponownie sprawdzić Live Users, Firewall Rule ID i zwykły ruch klienta.

W zmianie należy udokumentować pierwotną konfigurację, odpowiedzialność za shared secret i przetestowany powrót do wcześniejszej metody identyfikacji użytkowników. Samo usunięcie wpisu Live User nie jest pełnym rollbackiem.

FAQ