Configurare RADIUS SSO con accounting su Sophos Firewall

RADIUS SSO autentica un utente su Sophos Firewall senza un captive portal aggiuntivo. L’utente si è già autenticato su una rete wireless, un network access server o un altro sistema RADIUS. Il firewall riceve quindi un pacchetto di accounting RADIUS contenente nome utente e IP client e può usare questa associazione nelle regole basate sugli utenti.

Il punto decisivo non è soltanto un accesso 802.1X riuscito. Il firewall deve ricevere un Accounting-Start utilizzabile esattamente dal mittente configurato. Per Wi-Fi SSO, Sophos usa la Framed-IP-Address contenuta in questo pacchetto iniziale. Se manca l’IP client, il firewall può conoscere il nome utente, ma non riesce ad associarlo al traffico.

⚠️ RADIUS SSO non equivale a Enable accounting nell’oggetto server RADIUS. In Authentication > Servers, Enable accounting significa che il firewall invia accounting a un server RADIUS. In Authentication > Services > SSO using RADIUS accounting request, il firewall riceve invece accounting da un client RADIUS e crea un’associazione utente-IP.

La procedura Sophos attuale conferma questo flusso per gli access point APX gestiti da SFOS. Non fornisce un’approvazione generale per AP6 o controller di terze parti. Per un’altra piattaforma, prima del rollout in produzione verificare con il produttore e, se necessario, con Sophos Support che siano supportati lo stesso percorso proxy e gli stessi attributi. Un pacchetto di test tecnicamente idoneo non estende da solo l’ambito del supporto documentato.

Procedura rapida

1. Per il flusso documentato ufficialmente, usare APX con 802.1X e configurare il server di accounting RADIUS come proxy verso il firewall.
2. Definire il mittente effettivo, l’indirizzo di destinazione del firewall, la porta UDP 1813 e uno shared secret robusto.
3. In Authentication > Services > SSO using RADIUS accounting request, inserire l’IP del mittente e lo shared secret.
4. In Administration > Device access, consentire il servizio RADIUS SSO soltanto a questo mittente e all’indirizzo corretto del firewall.
5. Preparare una regola utente strettamente limitata con Match known users e logging.
6. Connettere un client reale e controllare il pacchetto di accounting sul firewall.
7. In Current activities > Live users, verificare il tipo client RADIUS SSO, l’utente e l’IP client corretto.
8. Solo in seguito testare il traffico consentito e quello volutamente non consentito con il Firewall Rule ID previsto.

Quando è adatto RADIUS SSO

RADIUS SSO è particolarmente adatto alle reti Wi-Fi 802.1X o ai sistemi di accesso alla rete in cui l’autenticazione avviene già all’esterno del firewall. Il firewall può quindi riconoscere l’utente senza un secondo accesso tramite browser.

La procedura richiede una relazione univoca tra utente e indirizzo IPv4. I prerequisiti tipici sono:

• Il client riceve un indirizzo IPv4 che Sophos Firewall vede anche come origine del traffico.
• Il mittente dell’accounting conosce il nome utente e questo IP client.
• L’accounting start raggiunge direttamente un indirizzo del firewall e senza modifiche inattese del NAT di origine.
• Il mittente RADIUS può fornire Framed-IP-Address nel pacchetto iniziale.
• Gli oggetti utente o gruppo e la relativa regola firewall sono già stati pianificati.

RADIUS SSO non sostituisce STAS su Sophos Firewall quando gli eventi di accesso Windows di Active Directory sono la fonte dell’identità. Non può inoltre distinguere più utenti dietro lo stesso IP RDS o Citrix. A seconda del traffico, sono più adatti SATC per Remote Desktop Services o AD SSO per connessione tramite direct web proxy.

Quando interrompere la procedura

Non attivare in produzione finché uno di questi punti non è chiarito:

• Il pacchetto di accounting non contiene un nome utente o Framed-IP-Address.
• L’indirizzo indicato nel pacchetto è diverso dall’IP di origine che il firewall vede successivamente nel traffico utile.
• Più utenti condividono lo stesso IP client.
• Il mittente effettivo o l’indirizzo di destinazione del firewall non sono univoci a causa di NAT, HA o routing.
• Il client RADIUS può usare soltanto un’intera rete non attendibile invece di un indirizzo sorgente fisso.
• La strategia di regole per utenti sconosciuti o non più autenticati non è chiara.

Comprendere il percorso dell’accounting

Con l’autenticazione RADIUS classica, il firewall invia un Access-Request al server RADIUS. Con RADIUS SSO la direzione è opposta:

1. Un client si autentica sull’APX gestito da SFOS tramite il server RADIUS selezionato in Wireless > Wireless settings.
2. L’APX invia l’accounting a tale server attraverso il firewall. Il server è configurato anche come proxy di accounting e inoltra il messaggio al firewall.
3. Sophos Firewall riceve il pacchetto inoltrato sul servizio RADIUS SSO.
4. Se l’IP del mittente corrisponde a RADIUS client IPv4 e lo shared secret è corretto, il firewall elabora il messaggio.
5. Il nome utente e Framed-IP-Address vengono visualizzati come associazione in Live users.
6. Solo il traffico utile successivo può corrispondere a una regola con Match known users.

Nel flusso APX ufficiale, il server RADIUS è sia destinazione di autenticazione e accounting sia proxy che inoltra al firewall i pacchetti di accounting APX. NPS richiede quindi una configurazione proxy RADIUS adeguata. Per RADIUS client IPv4 conta l’IP sorgente del pacchetto inoltrato. Una generica indicazione «RADIUS Accounting supportato» non dimostra né il supporto di questa architettura né la presenza di nome utente e IP client nell’accounting start.

Esempio end-to-end

Questa guida usa i seguenti valori di esempio:

• Mittente RADIUS o accounting: 10.10.20.15
• Indirizzo firewall per RADIUS SSO: 10.10.20.1
• Client Wi-Fi: 10.30.40.50
• Porta di destinazione accounting: UDP 1813
• Utente: EXAMPLE\alex.muster
• Regola utente: RADIUS-SSO-WiFi-Out

Gli indirizzi provengono da reti private di esempio e devono essere sostituiti con le reti reali di gestione, server e client. Per RADIUS client IPv4 non si inserisce automaticamente l’IP del server di autenticazione, ma l’IP di origine realmente visibile nel packet capture sul firewall.

Preparare la controparte

Nell’architettura APX documentata ufficialmente, verificare separatamente autenticazione, accounting verso il server RADIUS e percorso di ritorno del proxy verso il firewall. Un accesso 802.1X riuscito non dimostra che il server RADIUS inoltri l’accounting a Sophos Firewall.

Preparare almeno la controparte come segue:

1. Configurare APX e rete Wi-Fi 802.1X in Wireless, quindi selezionare il server RADIUS in Wireless > Wireless settings.
2. Attivare l’accounting sul server RADIUS e configurarlo come proxy verso l’indirizzo firewall 10.10.20.1.
3. Usare UDP 1813 per l’inoltro al firewall.
4. Configurare uno shared secret dedicato e robusto per questo percorso.
5. Inviare l’accounting start solo quando è noto l’IP client.
6. Verificare che siano inclusi nome utente e Framed-IP-Address.
7. Documentare IP di origine, routing ed eventuale traduzione NAT verso l’interfaccia del firewall.

Un accounting stop o un update può migliorare la gestione della sessione su alcuni prodotti. Tuttavia, la documentazione pubblica Sophos indica esplicitamente l’IP nell’accounting start come base di autenticazione per Wi-Fi SSO. Un update successivo non deve quindi sostituire un pacchetto iniziale completo come criterio di successo.

Nelle installazioni APX gestite da SFOS, la tempistica DHCP può avere un ruolo. Sophos documenta radius_accounting_start_delay da 0 a 60 secondi. L’esempio ufficiale per la Device Console imposta 30 secondi:

system wireless-controller global radius_accounting_start_delay 30

30 è un esempio modificabile, non un valore predefinito universale. Prima della modifica, eseguire system wireless-controller global show e registrare il valore corrente. Cambiare il parametro solo se un capture mostra che l’accounting start viene generato prima dell’assegnazione IP. Per il rollback, eseguire il comando di impostazione con il valore registrato. Se tale valore era 0 (nessun ritardo), il comando esatto è system wireless-controller global radius_accounting_start_delay 0. Le fonti ufficiali non indicano un valore predefinito universale: non dedurne uno se il valore precedente è sconosciuto. Sophos indica inoltre use_tunneled_reply per FreeRADIUS; questa opzione appartiene al server FreeRADIUS e non va applicata a NPS senza riscontri. La configurazione wireless generale è descritta in Configurare Wireless Network su Sophos Firewall.

Le note di rilascio AP6 riportano WIFIX-5189, un problema risolto relativo alla framed IP nei pacchetti di accounting. La procedura RADIUS SSO limita però il flusso descritto ad APX. Il fix AP6 non dimostra quindi che questa configurazione sia supportata.

Configurare RADIUS SSO su Sophos Firewall

Inserire mittente e shared secret

Il percorso di menu è:

Authentication > Services > SSO using RADIUS accounting request

Procedura:

1. In RADIUS client IPv4, aggiungere l’IP mittente 10.10.20.15 previsto nel capture.
2. Inserire lo Shared secret concordato per questo percorso.
3. Aggiungere altri mittenti soltanto come voci separate e documentate.
4. Selezionare Apply.

In questa sezione SFOS 22 offre solo RADIUS client IPv4 e Shared secret; non è presente un’impostazione separata della porta. Per RADIUS SSO vengono considerati solo i pacchetti provenienti dagli indirizzi IPv4 configurati. Un’intera rete o un indirizzo sorgente qualsiasi non è un’alternativa sensata a una pianificazione assente del mittente.

Questa configurazione del ricevitore, da sola, non crea un server RADIUS in Authentication > Servers. Il flusso APX ufficiale richiede comunque di aggiungere lì il server RADIUS esterno e selezionarlo in Wireless > Wireless settings; la configurazione generale del server RADIUS su Sophos Firewall descrive questa parte. Autenticazione e accounting in uscita e messaggi RADIUS SSO inoltrati restano percorsi distinti.

Consentire Device Access in modo restrittivo

RADIUS SSO è un servizio locale del firewall. Una normale regola LAN-to-WAN o WiFi-to-WAN non apre questo percorso di ricezione.

In Administration > Device access esistono due opzioni corrette:

• Se la zona del mittente è piccola e completamente attendibile, attivare RADIUS SSO nella matrice delle zone.
• Se è prevista una sola controparte fissa, lasciare disattivata l’autorizzazione di zona e creare una Accept Local service ACL exception rule mirata per l’IP del mittente, l’indirizzo firewall usato e il servizio RADIUS SSO.

Un’ulteriore eccezione accept non restringe un’autorizzazione di zona già attiva. Per un’eccezione realmente limitata, RADIUS SSO deve quindi restare disattivato nella zona interessata. La procedura completa è descritta in Device Access e Local Service ACL.

Preparare la regola utente

Per il primo test non è necessaria una regola di produzione ampia. Una regola limitata fornisce risultati più chiari:

1. In Rules and policies > Firewall rules, creare una regola sopra le regole WiFi o LAN più generali.
2. Limitare Source Zone e Source Network alla rete client effettiva.
3. Selezionare solo l’utente pilota o un gruppo pilota preparato.
4. Attivare Match known users.
5. Consentire solo un servizio di test innocuo o una destinazione chiaramente definita.
6. Attivare Log firewall traffic.
7. Definire una seconda combinazione utente o destinazione volutamente non consentita per il test negativo.

RADIUS SSO fornisce un’identità, non un’autorizzazione generale di rete. Creare regole firewall su Sophos Firewall spiega come interagiscono utenti, gruppi, servizi e logging.

Collaudare RADIUS SSO in modo controllato

1. Verificare il pacchetto di accounting sul firewall

In Diagnostics > Packet capture, impostare un filtro per l’IP mittente 10.10.20.15, l’indirizzo firewall 10.10.20.1 e UDP 1813. Quindi riconnettere esattamente un client pilota.

Il capture deve confermare almeno quanto segue:

• L’IP di origine è il RADIUS client IPv4 configurato.
• La destinazione è l’indirizzo firewall previsto.
• La porta di destinazione è UDP 1813.
• Viene visualizzato un accounting start per l’utente pilota.
• Framed-IP-Address corrisponde all’IP client attuale 10.30.40.50.

RADIUS accounting contiene dati di identità e sessione che possono essere visibili nel pacchetto. Trattare i file capture come log di autenticazione, conservarli solo per breve tempo e non condividerli senza protezione. Il funzionamento generale è descritto in Packet Capture su Sophos Firewall.

2. Verificare Live User

In Current activities > Live users, utente, IP client e tipo client devono corrispondere. Per questa procedura è previsto RADIUS SSO come tipo client.

Un utente visibile con l’IP errato non è un successo parziale. Le regole utente corrispondono in seguito all’origine reale del traffico, non all’associazione Wi-Fi desiderata.

3. Correlare il log di autenticazione

In Log Viewer, cercare l’utente pilota e l’ora dell’incidente. Per l’analisi approfondita è rilevante access_server.log, perché Sophos elabora lì autenticazione, autorizzazione e accounting degli utenti.

In HA, ogni nodo memorizza solo i log del traffico elaborato da quel nodo. Verificare il nodo che ha ricevuto l’accounting al momento del test. Verificare servizi e log di Sophos Firewall tramite CLI spiega come leggere e salvare access_server.log senza riavviare il servizio in modo incontrollato.

4. Eseguire test positivo e negativo

Con il client pilota verificare separatamente quattro aspetti:

1. Una destinazione consentita corrisponde al Firewall Rule ID previsto e mostra l’utente corretto.
2. Una destinazione volutamente non consentita resta bloccata.
3. Un utente non assegnato non ottiene l’autorizzazione pilota.
4. Dopo una nuova connessione o un roaming controllato, l’associazione tra utente, IP e regola resta corretta.

Il test deve usare traffico utile reale. Una voce Live User da sola non dimostra la corrispondenza della regola, il routing o il percorso di ritorno. Testare in modo affidabile le regole firewall descrive la procedura ripetibile.

Circoscrivere gli errori in base al sintomo

Nessun pacchetto di accounting raggiunge il firewall

Verificare prima IP di destinazione, porta UDP, routing e configurazione della controparte. Controllare poi Device Access o la Local Service ACL Exception Rule. Un accesso RADIUS riuscito su NPS o sulla rete Wi-Fi non dimostra l’esistenza del percorso di accounting separato verso il firewall.

Se il pacchetto arriva con un altro IP di origine, indagare esattamente tale causa. Non consentire frettolosamente un’intera rete come client RADIUS. Con NAT o HA, documentare e consentire in modo mirato l’indirizzo stabile del mittente realmente visibile.

L’accounting arriva, ma Live Users resta vuoto

Verificare insieme shared secret, IP del mittente e contenuto del pacchetto. Sono particolarmente importanti accounting start, nome utente e Framed-IP-Address. Se manca l’IP client, correggere prima access point, controller o proxy RADIUS. Il riavvio di un servizio firewall non crea un attributo mancante.

Solo quando il pacchetto è completo e access_server.log continua a non elaborare l’evento, salvare ora, capture, CTR e log del nodo per Sophos Support. Non eliminare il database di autenticazione e non ripulire Live Users per tentativi.

L’utente compare con un IP errato

Ciò indica spesso un messaggio di accounting inviato troppo presto, una vecchia associazione DHCP, roaming o un percorso NAT diverso. Disconnettere il client, registrare il lease corrente e acquisire un singolo nuovo collegamento. È determinante l’IP nel nuovo accounting start.

Con il wireless gestito da SFOS, modificare radius_accounting_start_delay solo dopo questa prova e documentando il valore precedente. Access point o controller di terze parti usano i propri meccanismi di accounting e DHCP; un parametro wireless Sophos non modifica questi dispositivi.

Live User è corretto, ma la regola non corrisponde

Il percorso di accounting è allora più avanzato della policy. Verificare Source Zone, Source Network, utente o gruppo, Match known users, ordine delle regole, Firewall Rule ID e IP effettivo del traffico. Se corrisponde la regola #0 o una regola generale, correggere la policy invece di cambiare lo shared secret.

L’utente resta visibile dopo la disconnessione

Verificare innanzitutto se la controparte invia un accounting stop e se questo pacchetto riguarda la stessa sessione e associazione utente. Correlare poi Live User, traffico client attuale e access_server.log. Una disconnessione manuale può ripulire temporaneamente lo stato, ma non dimostra che il processo automatico sia corretto.

Dopo un riavvio del firewall, Sophos indica che i client APX devono disconnettersi e riconnettersi affinché un nuovo accounting start ripristini l’accesso. Se nella regola utente è attivo Show captive portal to unknown users, il portale può apparire inizialmente; nel flusso APX documentato, dopo il ritardo configurato l’accesso diventa trasparente senza reinserire le credenziali.

Sicurezza, HA e operatività

RADIUS accounting usa UDP e non protegge il trasporto come TLS. Lo shared secret autentica il percorso RADIUS, ma non cifra tutti gli attributi di identità e sessione. L’accounting deve quindi trovarsi in una rete di gestione o server attendibile e non deve attraversare reti estranee senza protezione.

In esercizio si applicano questi limiti:

• Usare uno shared secret distinto e robusto e un responsabile documentato per ogni mittente.
• Consentire RADIUS SSO solo dalle zone necessarie e, se possibile, solo da host fissi.
• Trattare file capture, log RADIUS e access_server.log come dati operativi personali.
• Concludere le modifiche a DHCP, controller Wi-Fi, NPS, proxy RADIUS o NAT con un nuovo test end-to-end.
• In HA, non promettere il mantenimento senza interruzioni dell’associazione utente. Dopo un failover pianificato, verificare un nuovo accounting start, Live User e traffico reale sul nodo che lo elabora.
• Gestire utenti sconosciuti o associazioni mancanti con una regola predefinita sicura, non con un’ampia regola allow.

Rollback

Il rollback avviene in un ordine che non lasci aperto il servizio di accounting e non autorizzi involontariamente gli utenti:

1. Ripristinare la strategia precedente di autenticazione e regole per la rete pilota.
2. Disattivare la regola pilota ed eseguire un test negativo con un utente sconosciuto.
3. Rimuovere dal server RADIUS la destinazione di inoltro del proxy verso il firewall oppure ripristinare lo stato precedente documentato del proxy. Non rimuovere la destinazione accounting dell’APX se il server RADIUS è ancora necessario per l’autenticazione e l’accounting Wi-Fi.
4. Rimuovere il mittente in SSO using RADIUS accounting request.
5. Rimuovere l’eccezione ACL RADIUS SSO o l’autorizzazione temporanea di zona.
6. Verificare nuovamente Live Users, Firewall Rule ID e traffico client normale.

Documentare nella modifica la configurazione originale, la responsabilità dello shared secret e il ritorno verificato al precedente metodo di identificazione utente. La semplice eliminazione di una voce Live User non costituisce un rollback completo.

FAQ