Configurare e testare un server RADIUS su Sophos Firewall

RADIUS collega Sophos Firewall a Microsoft NPS, a un gateway MFA o a un altro servizio di autenticazione centralizzato. Per prima cosa si preparano il sistema remoto e il percorso di rete. Si crea quindi il server in Authentication > Servers e lo si assegna in Authentication > Services esclusivamente ai servizi di accesso necessari. Il collaudo avviene con un accesso reale, verificando utente, gruppo e regole.

Per le tradizionali query di utenti e gruppi da un dominio Windows, spesso è indicata l’integrazione di Active Directory con Sophos Firewall. Negli scenari moderni di accesso remoto, Microsoft Entra ID SSO per Sophos Connect e VPN Portal può rappresentare l’architettura più adatta. Se invece il firewall deve riconoscere utenti Wi-Fi già autenticati tramite pacchetti di accounting in ingresso, si segue una procedura diversa: Configurare RADIUS SSO con accounting su Sophos Firewall.

Quando è opportuno usare RADIUS

Il firewall invia il nome utente e le credenziali al server RADIUS. Sul server, l’origine degli utenti, la Network Policy ed eventualmente l’MFA determinano una risposta Access-Accept o Access-Reject. Solo in seguito il gruppo utenti locale, la policy VPN e le regole firewall stabiliscono quali risorse siano raggiungibili.

Nel modello RADIUS, i dati di autenticazione e autorizzazione sono contenuti nei profili utente. L’autorizzazione a utilizzare un servizio richiede che la richiesta corrisponda agli attributi previsti, ad esempio all’indirizzo IP del client RADIUS che la invia. Lo Shared Secret protegge le password degli utenti; ciò non implica la cifratura dell’intero trasporto RADIUS.

I casi d’uso tipici sono:

• Remote Access VPN con Microsoft NPS o un servizio MFA;
• autenticazione centralizzata per User Portal, VPN Portal o Captive Portal;
• una soluzione transitoria quando non si desidera collegare AD o LDAP direttamente al firewall;
• più dispositivi di rete che utilizzano lo stesso servizio RADIUS.

Una rete Wi-Fi Enterprise gestita dal firewall utilizza inoltre la selezione del server in Wireless > Wireless settings. La procedura 802.1X completa è quindi descritta in Configurare una rete Wi-Fi direttamente su Sophos Firewall.

Nella rete Wi-Fi Enterprise gestita da SFOS, Accounting Request e Accounting Response contengono informazioni sulla sessione e sull’accounting. Sono distinti dalle richieste, dalle risposte e dalle challenge di accesso utilizzate per l’autenticazione. Per questo percorso wireless, Sophos documenta il supporto dell’accounting su tutti i dispositivi dotati di Wi-Fi; il Wireless Network deve utilizzare 802.1X e l’accounting deve essere abilitato sul server RADIUS. La guida Wi-Fi collegata spiega le porte separate e l’assenza di Interim Accounting Updates. Il supporto dell’accounting non costituisce una garanzia di supporto per un server RADIUS secondario.

Documentare lo stato iniziale e la procedura di ripristino

Prima di modificare un servizio in produzione, per ogni sezione interessata in Authentication > Services si annotano:

• i server selezionati e il relativo ordine;
• lo stato di Set authentication methods same as firewall, Same as VPN o Same as firewall;
• il valore attuale di Default group per l’autenticazione firewall;
• un utente per il quale il metodo precedente funziona in modo comprovato.

Durante la modifica degli accessi amministrativi si mantiene aperta una sessione WebAdmin esistente. Si verifica inoltre un super amministratore locale tramite un percorso di gestione già consentito. La selezione dei server per gli amministratori non si applica a questo super amministratore; ciò nonostante, un accesso amministrativo esterno non deve mai essere modificato senza aver prima confermato un percorso di ripristino locale.

Pianificare la connessione RADIUS

Ruoli, percorso di rete e protocolli

In un ambiente NPS, Sophos Firewall è il client RADIUS e NPS è il server RADIUS. NPS verifica la richiesta in base alla propria Connection Request Policy e Network Policy e, in genere, anche rispetto ad Active Directory. Una successiva regola VPN o firewall continua a determinare l’accesso effettivo.

La guida generale di SFOS 22 descrive la comunicazione tra firewall e server RADIUS tramite PAP. In Authentication > Services, tuttavia, Sophos elenca PAP, CHAP e MSCHAPv2 per le connessioni L2TP e PPTP. Questa matrice di protocolli non dimostra che gli stessi metodi siano disponibili per IPsec o per altri percorsi di accesso. È quindi necessario verificare congiuntamente il servizio, il client e il metodo consentito sul server RADIUS.

Il RADIUS tradizionale utilizza UDP e, nell’interfaccia SFOS documentata, non offre campi TLS o per certificati. Il traffico deve quindi transitare su un percorso interno controllato o altrimenti protetto. Uno Shared Secret robusto non sostituisce né la segmentazione né una regola restrittiva tra firewall e server RADIUS.

I sistemi meno recenti possono prevedere porte diverse, come 1645/UDP e 1646/UDP. Fanno fede le porte effettivamente configurate su entrambi i lati, non questi valori storici.

Scegliere consapevolmente i valori di esempio

Questa guida utilizza:

• Server name NPS-HQ-RADIUS;
• Server IP 10.20.30.15;
• Authentication port 1812;
• Accounting port 1813;
• Time-out 5 secondi;
• Domain name corp.example.

10.20.30.15 e corp.example devono essere sostituiti con l’indirizzo interno e la convenzione di denominazione del proprio ambiente. Cinque secondi sono un valore iniziale per una verifica diretta della password, non il valore predefinito di Sophos. In caso di notifiche push, chiamate telefoniche o challenge esterne, il valore deve essere compatibile con il provider e il client effettivo, senza uscire dall’intervallo da 1 a 60 secondi consentito da SFOS.

Lo Shared secret è il segreto tecnico condiviso tra client e server RADIUS, non la password di un utente. Sophos ne limita la lunghezza a 48 caratteri. Il valore deve essere trasferito tramite un canale separato e protetto, conservato in modo sicuro e inserito in maniera perfettamente identica su entrambi i sistemi; RADIUS non trasmette il secret stesso sulla rete.

Creare il server RADIUS in Authentication

Il percorso di menu è Authentication > Servers.

1. Aprire Add e, in Server type, selezionare RADIUS server.
2. In Server name, inserire ad esempio NPS-HQ-RADIUS.
3. In Server IP, inserire l’indirizzo IP interno del server RADIUS, nell’esempio 10.20.30.15.
4. Impostare Authentication port in modo coerente con il server, normalmente su 1812.
5. Impostare Time-out. Per il primo test diretto, nell’esempio si utilizzano 5 secondi.
6. Attivare Enable accounting soltanto se il sistema remoto deve elaborare i dati di accounting. In tal caso, configurare anche Accounting port, normalmente su 1813.
7. Inserire lo Shared secret esattamente come sul sistema remoto.
8. Facoltativamente, impostare Domain name. Quando AD e RADIUS sono utilizzati in parallelo, un dominio uniforme evita che la stessa persona compaia come oggetti utente locali distinti. Con Domain name, al primo accesso viene creato automaticamente un oggetto utente locale nel formato user@domainname. Senza questo valore, RADIUS crea un utente senza dominio, mentre AD crea un oggetto utente qualificato con il dominio; possono così nascere due oggetti utente locali per la stessa persona.
9. Compilare Group name attribute solo se è stato verificato che il sistema remoto restituisca l’attributo previsto. La guida Sophos lo definisce come alias del nome del gruppo configurato, ma in questo punto non documenta una mappatura generica di qualsiasi attributo NPS sui gruppi locali.
10. Aprire Enable additional settings soltanto in presenza di una policy appropriata. NAS-identifier identifica il Network Access Server che invia la richiesta, ad esempio mediante un FQDN. NAS-port-type descrive il tipo di porta utilizzato per l’accesso.
11. Eseguire Test connection con un proprio utente pilota, quindi selezionare Save.

Il firewall supporta complessivamente non più di 20 server di autenticazione configurati. Anche per ciascun metodo di autenticazione in Authentication > Services è possibile selezionare al massimo 20 server.

Nota API per SFOS 23: Il riferimento API per l’aggiunta e la modifica dei server RADIUS aggiunge il parametro facoltativo EmailAddressAttribute (stringa, massimo 50 caratteri) e lo include nell’esempio XML di RADIUSServer. Non è indicato alcun valore predefinito. Questa nota riguarda la documentazione API, non un campo WebAdmin aggiuntivo.

Inquadrare correttamente l’accounting

Con Enable accounting, per i tipi di client supportati il firewall invia un messaggio Accounting-Start all’accesso e un messaggio Accounting-Stop in caso di disconnessione regolare. Sophos elenca Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client e API client. Le richieste Start e Stop contengono anche, rispettivamente, l’ora dell’accesso e della disconnessione.

Quando il firewall viene arrestato o riavviato, non viene inviato alcun Accounting-Stop. Se una sessione rimane aperta sul server RADIUS, occorre quindi confrontare l’ora del riavvio con i log RADIUS. Questa funzione di accounting in uscita è distinta dal RADIUS SSO Accounting in ingresso, attraverso il quale il firewall apprende sessioni esterne.

Preparare Microsoft NPS come sistema remoto

In NPS, Sophos Firewall deve essere configurato come client RADIUS. La verifica minima nella console Network Policy Server prevede quanto segue:

1. Aprire RADIUS Clients and Servers > RADIUS Clients.
2. Creare un New RADIUS Client con un Friendly name univoco, ad esempio Sophos-Firewall-HQ.
3. In Address (IP or DNS), inserire l’indirizzo dal quale NPS riceve effettivamente la richiesta.
4. In Vendor, selezionare normalmente RADIUS standard.
5. Inserire lo stesso Shared secret configurato sul firewall.
6. Nelle Connection Request Policy e Network Policy pertinenti, verificare le condizioni, la decisione di accesso e il metodo di autenticazione consentito per l’utente pilota.
7. Predisporre Event Viewer e i log di accounting NPS per il collaudo.

Nei cluster HA, nelle connessioni instradate o in presenza di NAT, l’indirizzo del client NPS non deve essere dedotto dalla topologia. Un primo test mostra in NPS quale indirizzo IP sorgente arrivi realmente. Se la richiesta non arriva affatto o NPS non riesce a convalidarla, si verificano innanzitutto il routing, l’autorizzazione UDP, l’indirizzo del client RADIUS e lo Shared Secret. Un normale Access-Reject indica invece un problema relativo all’utente, alla policy o al metodo di autenticazione.

Assegnare RADIUS ai servizi corretti

Dopo il salvataggio, l’oggetto server non è ancora attivo per alcun accesso. In SFOS 22, Authentication > Services contiene le sezioni seguenti:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

Per User Portal, VPN Portal, VPN e amministratori, la selezione dei server può essere collegata all’autenticazione firewall. SSL VPN offre Same as VPN e Same as firewall. Prima di apportare modifiche, occorre quindi verificare se la sezione interessata utilizzi un elenco autonomo o collegato.

Per un progetto pilota limitato, si aggiunge NPS-HQ-RADIUS soltanto alla sezione necessaria, lo si colloca nella posizione prevista e si seleziona Apply. Il firewall interroga più server nell’ordine visualizzato. Se lo stesso utente riesce già ad autenticarsi tramite un server precedente, un’eventuale policy RADIUS MFA collocata successivamente non viene applicata.

Captive Portal e Default Group

Captive Portal non dispone di una sezione dedicata in Authentication > Services, ma utilizza Firewall authentication methods. È inoltre necessario consentire Captive portal per la zona prevista in Administration > Device access e configurare adeguatamente una regola firewall basata sugli utenti. Per un test funzionale ufficiale, accedere a https://<firewall-ip>:8090.

Il valore Default group in Firewall authentication methods è rilevante per la sicurezza. Al primo accesso riuscito a un servizio firewall, l’utente esterno viene creato in Authentication > Users. Se non esiste un’associazione a un gruppo locale appropriato, viene applicato il gruppo configurato come Default Group. Prima del progetto pilota, occorre verificare le policy del gruppo e tutte le regole che lo utilizzano; un gruppo predefinito con privilegi eccessivi non deve diventare inavvertitamente il fallback.

Delimitare l’MFA challenge in base al servizio

Secondo la guida di SFOS 22, VPN Portal non supporta l’autenticazione RADIUS con MFA basata su challenge. Un Test connection riuscito non fornisce quindi indicazioni sul funzionamento di questo percorso del portale. Push, chiamata, OTP e challenge non sono intercambiabili: ogni client e servizio previsto deve essere testato separatamente. Per l’MFA locale di Sophos Firewall si applica la procedura specifica descritta in Attivare l’MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access.

Collaudare la configurazione

1. Connessione e sistema remoto

In Authentication > Servers, aprire NPS-HQ-RADIUS ed eseguire Test connection con l’utente pilota. Contemporaneamente, in NPS o nei log dell’altro sistema remoto, verificare che:

• la richiesta provenga dall’indirizzo previsto del firewall;
• venga elaborata dalla policy corretta;
• il risultato sia Access-Accept;
• siano presenti gli attributi di risposta previsti.

Il test conferma le credenziali e la comunicazione con il server. Non conferma ancora l’ordine dei servizi, la policy VPN, il gruppo locale o la regola firewall.

2. Testare il servizio effettivo

Successivamente, lo stesso utente accede esattamente tramite il servizio previsto. Captive Portal, SSL VPN, IPsec, User Portal e WebAdmin hanno requisiti diversi. Per WebAdmin, l’utente esterno deve inoltre ricevere il profilo amministratore previsto; la sola autenticazione RADIUS riuscita non assegna privilegi amministrativi. I percorsi non necessari restano invariati. Per SSL VPN, Configurare Sophos Firewall SSL VPN Remote Access illustra policy, Device Access e regola firewall.

Dopo un accesso riuscito, verificare:

1. In Authentication > Users, l’utente locale, il dominio e il valore effettivo di Main Group.
2. In Current activities > Live users, la sessione attiva, che può essere terminata se necessario con Disconnect.
3. Nel Log viewer, in alto a destra in WebAdmin, aprire il modulo Authentication e filtrare per utente, IP sorgente e un intervallo temporale ristretto relativo al test.
4. Nel log del traffico, l’effettivo Firewall Rule ID e soltanto la risorsa di destinazione consentita.
5. Il caso negativo, utilizzando un utente non incluso nella policy NPS consentita.

Se l’accesso riesce ma l’applicazione rimane irraggiungibile, si verificano zona, pool IP VPN, gruppo, posizione della regola, NAT e routing. La regola di Sophos Firewall non viene applicata: verificare le cause descrive questo percorso dei dati. Se invece non sono chiari l’identità, la selezione del servizio o il Main Group, consultare Risolvere sistematicamente gli errori di autenticazione di Sophos Firewall.

Individuare gli errori in base a quanto osservato

Il sistema remoto non riceve alcuna richiesta

Verificare innanzitutto i valori configurati in Server IP e Authentication port. Controllare quindi il routing e l’autorizzazione per UDP 1812 tra l’indirizzo sorgente utilizzato dal firewall e 10.20.30.15. La creazione di un oggetto server RADIUS non genera automaticamente una regola firewall di transito.

Per una rete wireless gestita da SFOS, Sophos documenta un caso particolare ben circoscritto: se il server RADIUS è collegato al firewall tramite un tunnel IPsec, per le reti degli access point è necessaria un’associazione Source NAT. Questa traduce l’IP sorgente esattamente nell’indirizzo IP del firewall attraverso il quale il firewall raggiunge il server RADIUS. La guida wireless rimanda a una configurazione tramite shell con sys-traffic-nat, ma non fornisce in questo punto un comando completo ed eseguibile. Prima di apportare una modifica, occorre verificare e documentare le reti degli access point, l’indirizzo sorgente effettivamente utilizzato, l’indirizzo del firewall da usare per la traduzione della sorgente, il tunnel, il percorso di ritorno e i log RADIUS. In assenza di una sintassi confermata per questo scopo, la configurazione concreta tramite shell, comprese la verifica e la procedura di ripristino, deve essere oggetto di un’escalation tecnica mirata. Per altri percorsi RADIUS, questa guida wireless non dimostra un requisito generale di NAT. Una regola da LAN a VPN o un esempio di Forwarding-IPsec-Route non sostituisce questa procedura per il traffico generato dal sistema.

NPS risponde con Access-Reject

Un rifiuto dimostra che il percorso di rete e la porta funzionano, almeno in linea di principio. A questo punto si verificano in NPS il Reason Code, la Network Policy corretta, lo stato dell’utente e il metodo di autenticazione consentito. Uno Shared Secret errato provoca invece risposte assenti, non valide o non verificabili.

Test connection funziona, ma l’accesso al servizio no

In Authentication > Services, verificare la sezione corretta, le opzioni di collegamento, l’ordine dei server e Apply. Per Captive Portal, controllare inoltre Device access e la regola firewall basata sugli utenti. Per SSL VPN devono essere corretti i membri della policy, l’accesso SSL VPN in Device Access e la regola firewall necessaria.

L’accesso funziona, ma viene applicato il gruppo errato

In Authentication > Users, controllare Domain e Main Group. Confrontare quindi Group name attribute, gli attributi restituiti dal sistema remoto e Default group. Un’autenticazione riuscita non dimostra che l’autorizzazione prevista sia corretta. Occorre quindi verificare che l’utente usato per il test negativo venga effettivamente rifiutato dalla condizione del gruppo o di NPS.

La notifica push o la challenge scade

Utilizzare il client effettivo e confrontare gli orari nei log del firewall, di NPS e del provider MFA. Aumentare il timeout SFOS soltanto entro l’intervallo da 1 a 60 secondi e scegliere il valore minimo che consenta di completare in modo affidabile il normale processo di challenge. Una durata maggiore non può risolvere il problema dell’MFA RADIUS basata su challenge in VPN Portal, poiché Sophos non supporta questo percorso.

Eseguire un rollback sicuro

Se il progetto pilota non riesce, nella sezione interessata in Authentication > Services si ripristinano l’elenco dei server e il relativo ordine annotati in precedenza, le opzioni di collegamento e il valore Default group, quindi si seleziona Apply. In seguito si accede con l’utente di confronto tramite il metodo originale e si verifica il super amministratore locale.

Solo quando tutti i servizi interessati funzionano nuovamente, si rimuove NPS-HQ-RADIUS dalle altre assegnazioni dei servizi. L’oggetto server in Authentication > Servers viene eliminato soltanto se non ne è più previsto alcun utilizzo. In NPS si ripristinano il client, la policy e lo Shared Secret allo stato precedente documentato. Gli oggetti utente locali già creati devono essere verificati separatamente; la loro rimozione non termina automaticamente tutte le sessioni esistenti, pertanto occorre controllare anche Current activities > Live users.

Gestione operativa

RADIUS è un servizio di identità in produzione. Dopo ogni modifica a NPS, al provider MFA, ad AD o all’ordine dei servizi, il collaudo deve includere un accesso reale sia positivo sia negativo. Lo Shared Secret deve essere documentato in modo protetto e ruotato secondo una pianificazione. Per il sistema remoto è necessario configurare il monitoraggio e definire il periodo di conservazione dei log decisionali. In questo modo è possibile stabilire se un errore si sia verificato prima del firewall, durante l’autenticazione o soltanto nella fase di autorizzazione.

FAQ