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.

Procedura rapida

1. Verificare che l’access point, il controller o il proxy RADIUS possa generare un accounting start contenente nome utente e Framed-IP-Address.
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’access point, sul controller Wi-Fi o sul network access server.
2. Dopo l’assegnazione dell’indirizzo, questa infrastruttura genera un accounting start oppure lo inoltra tramite un proxy RADIUS.
3. Sophos Firewall riceve il pacchetto sul proprio 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.

Il fatto che il controller Wi-Fi invii direttamente al firewall o che un server RADIUS come NPS inoltri l’accounting dipende dal prodotto. La configurazione Sophos non contiene una procedura universale per NPS o controller. È determinante il pacchetto che arriva realmente al firewall. Un’indicazione del produttore come «RADIUS Accounting supportato» non basta finché nome utente e IP client non sono stati verificati 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

Su access point, controller, network access server o proxy RADIUS, autenticazione e accounting devono essere verificati separatamente. Un accesso riuscito non dimostra che l’accounting venga generato o inoltrato a Sophos Firewall.

Preparare almeno la controparte come segue:

1. Attivare l’accounting per l’accesso 802.1X o di rete interessato.
2. Impostare l’indirizzo previsto del firewall 10.10.20.1 come destinazione accounting.
3. Usare UDP 1813 o la porta accounting esplicitamente concordata da entrambe le parti.
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 il parametro radius_accounting_start_delay con un intervallo da 0 a 60 secondi. Non modificare questo valore per tentativi: prima un capture deve dimostrare che l’accounting start viene generato prima dell’assegnazione IP. La configurazione wireless generale è descritta in Configurare Wireless Network su Sophos Firewall.

Per AP6, le note di rilascio di 1.5.2167 MR5 riportano il fix WIFIX-5189 per un caso in cui la framed IP mancava in accounting start e accounting update. Con un AP6 dotato di firmware più vecchio o sconosciuto, aggiornare prima a un firmware attuale supportato e poi verificare nuovamente il pacchetto. Il fix non dimostra automaticamente che ogni combinazione di controller, proxy o NPS inoltri correttamente gli attributi.

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.

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 non crea un server RADIUS in Authentication > Servers e non sostituisce la configurazione generale del server RADIUS su Sophos Firewall. L’articolo sul server descrive le richieste inviate dal firewall a NPS, MFA o a un altro server RADIUS. RADIUS SSO riguarda i messaggi di accounting in entrata.

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 è la porta accounting configurata.
• 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.

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 la destinazione accounting da access point, controller o proxy RADIUS oppure ripristinare lo stato precedente documentato.
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