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.

Szybka procedura

1. Sprawdzić, czy punkt dostępowy, kontroler lub proxy RADIUS potrafi wygenerować accounting start z nazwą użytkownika i Framed-IP-Address.
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 punkcie dostępowym, kontrolerze Wi-Fi lub na serwerze dostępu do sieci.
2. Po przydzieleniu adresu infrastruktura generuje accounting start albo przekazuje go przez proxy RADIUS.
3. Sophos Firewall odbiera pakiet w swojej 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.

To, czy kontroler Wi-Fi wysyła bezpośrednio do firewalla, czy serwer RADIUS, taki jak NPS, przekazuje accounting, zależy od produktu. Konfiguracja Sophos nie zawiera uniwersalnej instrukcji dla NPS lub kontrolera. Decydujący jest pakiet, który faktycznie dociera do firewalla. Informacja producenta „obsługuje RADIUS Accounting” nie wystarcza, dopóki nazwa użytkownika i adres IP klienta nie zostaną potwierdzone 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 punkcie dostępowym, kontrolerze, na serwerze dostępu do sieci lub proxy RADIUS uwierzytelnianie i accounting trzeba sprawdzić oddzielnie. Udane logowanie nie dowodzi jeszcze, że accounting jest generowany lub przekazywany do Sophos Firewall.

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

1. Włączyć accounting dla danego dostępu 802.1X lub sieciowego.
2. Ustawić planowany adres firewalla 10.10.20.1 jako cel accountingu.
3. Użyć UDP 1813 lub portu accountingu rzeczywiście uzgodnionego przez obie strony.
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 parametr radius_accounting_start_delay o zakresie od 0 do 60 sekund. Nie zmieniać tej wartości na próbę: najpierw capture musi wykazać, że accounting start powstaje przed przydzieleniem adresu IP. Ogólna konfiguracja Wi-Fi znajduje się w artykule Konfiguracja Wireless Network na Sophos Firewall.

Dla AP6 informacje o wersji 1.5.2167 MR5 zawierają poprawkę WIFIX-5189 dotyczącą przypadku, w którym framed IP brakowało w accounting start i accounting update. AP6 ze starszym lub nieznanym firmware należy najpierw zaktualizować do aktualnej obsługiwanej wersji, a następnie ponownie sprawdzić pakiet. Poprawka nie dowodzi, że każda kombinacja kontrolera, proxy lub NPS poprawnie przekazuje atrybuty.

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.

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.

Ta konfiguracja nie tworzy serwera RADIUS w Authentication > Servers i nie zastępuje ogólnej konfiguracji serwera RADIUS na Sophos Firewall. Artykuł o serwerze opisuje żądania wysyłane przez firewall do NPS, MFA lub innego serwera RADIUS. RADIUS SSO dotyczy przychodzących komunikatów accountingu.

Ś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 skonfigurowany port accountingu.
• 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.

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ąć cel accountingu z punktu dostępowego, kontrolera lub proxy RADIUS albo przywrócić udokumentowany stan poprzedni.
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