Creare e gestire utenti locali su Sophos Firewall

Un utente locale viene memorizzato direttamente su Sophos Firewall e autenticato tramite il database utenti locale. È adatto a piccoli ambienti, account pilota e singoli collaboratori esterni. Un account locale può fungere da fallback per un servizio di directory solo se sono stati verificati, per il servizio interessato, l’ordine dei server, uno username distinto, l’accesso al portale e il comportamento in caso di indisponibilità della fonte esterna. La guida di SFOS documenta l’ordine dei server, ma non garantisce il failover per ogni tipo di errore.

Questo articolo si applica all’interfaccia WebAdmin di SFOS 22. La sola creazione di un utente non concede alcun accesso. Il gruppo, il metodo di autenticazione, il portale o il client e la policy firewall o VPN devono essere configurati in modo coerente.

Flusso di lavoro rapido:

1. Definire il caso d’uso, gli utenti destinatari e il servizio necessario.
2. Preparare un gruppo restrittivo di tipo Normal in Authentication > Groups.
3. In Authentication > Users > Add, inserire uno username permanente e selezionare User type: User.
4. Assegnare una password individuale robusta e il gruppo corretto.
5. Lasciare invariati i campi delle policy nell’utente se devono essere applicati i valori del gruppo.
6. Limitare consapevolmente Simultaneous sign-ins e Sign-in restriction.
7. In Authentication > Services, verificare che Local sia selezionato per il servizio utilizzato.
8. Configurare separatamente e nel modo più restrittivo possibile il portale, la regola utente o la policy di accesso remoto.
9. Con un account pilota, eseguire un accesso positivo, uno negativo e una prova con traffico reale.
10. Solo in seguito attivare MFA, creare altri utenti e documentare l’offboarding.

⚠️ Lo username non può essere modificato in seguito. Prima di salvare, definire lo schema dei nomi, il tipo di account e il responsabile. SFOS converte in minuscolo le lettere maiuscole presenti nello username. Un account sostitutivo ha una nuova identità: verificare quindi nuovamente regole, quote, assegnazioni VPN e tracce di audit.

Quando è adatto un utente locale

Gli utenti locali non richiedono Active Directory né un server RADIUS o LDAP esterno. Questo li rende semplici, ma trasferisce interamente sul firewall la gestione di password, MFA, gruppi, disattivazione e revisioni. È una soluzione pratica per pochi account gestiti con attenzione. Con molti collaboratori o frequenti ingressi e uscite, una directory centrale è generalmente più facile da mantenere.

Un normale utente locale è adatto, ad esempio, per:

• un account pilota per Captive Portal, User Portal o Remote Access;
• un piccolo ambiente senza servizio di directory;
• un singolo fornitore esterno con durata e responsabilità chiare;
• un fallback testato, con uno username distinto, quando una fonte di autenticazione esterna è temporaneamente indisponibile.

Non utilizzare un account locale per più persone. Le credenziali condivise complicano le modifiche delle password, l’uso della MFA, la gestione delle quote, gli audit e un offboarding ordinato.

Non confondere i tipi di utente

SFOS offre diversi tipi di utente simili che risolvono esigenze differenti:

• Un normale utente locale accede con username e password e riceve le policy tramite un gruppo normale o override utente intenzionali.
• Un utente guest ha durata limitata, usa le impostazioni Guest User e viene normalmente utilizzato tramite Captive Portal.
• Un Clientless User viene riconosciuto tramite un indirizzo IP e non effettua un accesso interattivo.
• Un amministratore locale riceve User type: Administrator e un profilo Device Access per i diritti WebAdmin.
• Un utente AD, LDAP, RADIUS o Entra viene autenticato da una fonte esterna. A seconda del metodo, il relativo record locale viene creato solo al primo accesso riuscito.

Per una persona che deve accedere a Captive Portal o a un servizio VPN si usa User type: User. Questo non concede all’account accesso WebAdmin o SSH.

Esempio e requisiti

L’esempio seguente utilizza:

• username pilotuser01;
• nome visualizzato Local Pilot User;
• indirizzo e-mail pilotuser01@example.com;
• gruppo Local_Pilot_Users;
• regola firewall Local-Pilot-to-WAN;
• fonte di accesso consentita da 10.20.30.10 a 10.20.30.50.

example.com è un dominio riservato alla documentazione; l’intervallo di indirizzi appartiene a una rete privata utilizzata come esempio. Sostituire username, indirizzo e-mail, gruppo, regola e indirizzi con i valori del proprio ambiente. Lo username, volutamente neutro rispetto alla funzione, non contiene un indirizzo e-mail e rimane quindi valido anche se quest’ultimo cambia. Lo schema di denominazione deve essere coerente con i processi di helpdesk e offboarding e con i nomi già presenti nella directory.

Prima di creare l’account occorre chiarire:

• Quale servizio autentica l’utente: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec o un altro accesso supportato?
• Quale gruppo normale contiene la baseline comune?
• Quale policy firewall o Remote Access consente l’accesso successivo?
• Da quali indirizzi IPv4 può accedere l’account?
• Quanti accessi simultanei sono realmente necessari?
• È richiesta la MFA locale e tramite quale portale avviene la registrazione iniziale?
• Chi disattiva l’account e controlla le sessioni esistenti durante l’offboarding?

Gestire gruppi utenti e Main Group su Sophos Firewall spiega la logica comune dei gruppi. Per i normali utenti locali si utilizza un gruppo di tipo Normal. Un gruppo di tipo Clientless appartiene al modello basato su IP e non è la baseline corretta per questo flusso di accesso.

Creare l’utente locale

L’account viene creato in Authentication > Users > Add:

1. Inserire pilotuser01 in Username. SFOS memorizza il valore in minuscolo e questo non può essere modificato in seguito.
2. Inserire Local Pilot User in Name.
3. Impostare User type su User.
4. Inserire e confermare una password lunga e individuale definita secondo la procedura adottata per le password.
5. In Email, inserire pilotuser01@example.com o la casella di posta della persona. Per un account tecnico, utilizzare un indirizzo monitorato affidato a un responsabile chiaramente identificato.
6. In Group, selezionare Local_Pilot_Users.
7. Modificare Quarantine digest, i campi delle policy e i campi Remote Access solo quando è necessaria la funzione corrispondente o un’eccezione utente documentata.
8. Impostare in modo adeguato Simultaneous sign-ins e Sign-in restriction.
9. Salvare con Save.

SFOS rifiuta le password di uso comune e le parole rilevate dal controllo del dizionario. Per ogni account, utilizzare una password lunga e univoca generata secondo il proprio processo di gestione delle password. Una password di esempio direttamente copiabile diventerebbe immediatamente un segreto noto e non costituirebbe quindi un modello sicuro.

Valori del gruppo o override utente

Nel record utente si possono impostare Surfing quota, Access time, Network traffic e Traffic shaping, oltre a diversi campi Remote Access. I valori specifici dell’utente hanno la precedenza sui valori del gruppo. Se il gruppo deve rimanere la baseline gestibile, questi campi non vanno sovrascritti preventivamente.

Un override utente è adatto a un’eccezione chiaramente documentata, ad esempio un Access Time più restrittivo durante un incarico temporaneo. Occorre documentare:

• quale campo differisce dal valore del gruppo;
• perché l’eccezione è necessaria;
• quando verrà verificata o rimossa;
• come tornerà effettivo il valore originario del gruppo.

Access Time per gli utenti e quote Surfing e Network Traffic spiegano integralmente ciascuna policy. Nel record utente va assegnata solo una policy di cui sia già noto il funzionamento.

Limitare il numero e l’origine degli accessi

Simultaneous sign-ins limita le sessioni contemporanee. Global setting adotta il valore applicabile ai nuovi utenti in Authentication > Services. In alternativa, si può impostare un valore personalizzato o scegliere Unlimited. Sessioni illimitate sono raramente necessarie per un normale account personale e rendono più difficile individuare credenziali condivise.

Sign-in restriction limita gli indirizzi IPv4 dai quali l’utente può accedere:

• Any node: consentire l’accesso da qualsiasi origine raggiungibile;
• User group nodes: ereditare il valore del gruppo;
• Selected nodes: indicare singoli indirizzi IPv4 previsti;
• Node range: consentire un intervallo IPv4 contiguo.

Per questo esempio, selezionare Node range e immettere 10.20.30.10 come indirizzo iniziale e 10.20.30.50 come indirizzo finale. Sostituire entrambi i valori con l’intervallo contiguo più piccolo da cui l’utente effettua realmente l’accesso. Se servono singoli indirizzi IPv4 non contigui, utilizzare Selected nodes. Una selezione troppo restrittiva blocca gli accessi legittimi; Any node non sostituisce una regola firewall, un’ACL del portale o l’MFA.

In questo flusso di base non si attiva MAC binding. Supporta l’autenticazione basata sul client, ma non Remote Access VPN o Captive Portal. Se viene attivato senza indirizzo MAC, SFOS associa automaticamente il primo indirizzo MAC rilevato al primo accesso. Sui dispositivi mobili, dopo un cambio Wi-Fi o su client condivisi, può diventare rapidamente una dipendenza inattesa.

Collegare metodo di autenticazione e accesso

Un utente salvato può accedere solo a un servizio che interroga il database locale. In Authentication > Services, abilitare il metodo Local nell’elenco relativo al servizio utilizzato.

Le aree sono separate:

• Firewall authentication methods per il traffico firewall e Captive Portal;
• User portal authentication methods per User Portal;
• VPN portal authentication methods per VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods per questi metodi VPN;
• SSL VPN authentication methods per Remote Access SSL VPN.

Se sono presenti più fonti, vengono interrogate nell’ordine visualizzato. Una prova riuscita su User Portal non dimostra quindi automaticamente che lo stesso utente sia configurato correttamente anche per SSL VPN o IPsec.

Per ogni metodo di autenticazione è possibile selezionare al massimo 20 server. Per User Portal e VPN Portal, l’opzione di ereditarietà è Set authentication methods same as firewall. Per SSL VPN, SFOS mostra Same as VPN o Same as firewall, a seconda del riferimento selezionato. Controllare questa opzione e l’ordine risultante prima di aggiungere o spostare Local.

Configurare l’accesso separatamente

L’identità locale non apre un percorso di rete. Captive Portal richiede inoltre Device Access, Web Authentication e una regola utente adeguata. Il flusso completo è descritto in Configurare e testare Captive Portal su Sophos Firewall.

User Portal e VPN Portal sono anch’essi servizi separati. Il modello dei portali Sophos Firewall spiega porte, scopo, Device Access e limiti WAN. Le policy Remote Access vengono gestite nelle rispettive guide VPN e non si considerano complete solo perché è stato impostato un campo nel record utente.

Interpretare correttamente i campi Remote Access

Per i metodi Remote Access diversi da SSL VPN, i valori di policy specifici dell’utente hanno precedenza sul gruppo. SSL VPN segue una logica diversa: L’utente riceve le risorse di tutte le policy Full e Split Tunnel che includono direttamente l’utente o uno dei gruppi supportati a cui appartiene. Il campo SSL VPN policy non sostituisce quindi semplicemente le policy di gruppo.

SSL VPN IP address compare solo quando gli indirizzi statici sono attivati in SSL VPN global settings. L’indirizzo IPv4 o IPv6 deve essere libero e appartenere all’intervallo statico creato automaticamente in quella sezione. Se un server RADIUS assegna gli indirizzi, la sua assegnazione ha la precedenza. IPsec remote access attiva invece l’accesso con Sophos Connect e può ricevere un proprio indirizzo assegnato.

L2TP e PPTP sono metodi legacy. Dopo l’assegnazione, l’utente deve prima accedere a VPN Portal e creare una password prima di potersi connettere. La valutazione attuale e il percorso di migrazione per L2TP sono descritti in L2TP Remote Access; PPTP non va pianificato per nuovi accessi. Clientless SSL VPN policy apre solo i bookmark del browser assegnati e non è un tunnel completo. Il flusso separato è descritto in Clientless Access.

Per una regola firewall basata su utenti, origine, destinazione, servizio e utente o gruppo vanno definiti nel modo più restrittivo possibile. Log firewall traffic rimane attivo durante la verifica. I principi delle regole sono descritti in Comprendere e configurare in modo sicuro le regole Sophos Firewall.

Verificare con test positivi e negativi

Un account visibile con stato Active non è ancora una prova di successo. Il pilota viene testato tramite lo stesso servizio che verrà usato in seguito:

1. Accedere con pilotuser01 in una finestra privata del browser o da un client di test pulito.
2. In Current activities > Live users, verificare username, IP di origine e Client Type.
3. In Log Viewer > Authentication, controllare l’accesso riuscito, l’autenticazione locale e l’orario.
4. Generare il traffico previsto e verificare nel log firewall o VPN che Local-Pilot-to-WAN, o il relativo Firewall Rule ID, corrisponda alla regola applicata.
5. Usare come test negativo un’origine o una funzione espressamente non consentita.
6. Se è attiva una quota o un Access Time, provarne separatamente l’effetto entro e oltre il limite.
7. Documentare risultato, gruppo utilizzato, override utente e metodo di autenticazione.

Un test di accesso negativo non dovrebbe fallire soltanto perché è stata usata intenzionalmente una password errata. Occorre anche verificare che un’origine non autorizzata, un utente senza il gruppo adeguato o una funzione non prevista non ottengano davvero accesso. In questo modo si separa la verifica della password dall’effetto di policy e regole.

Se non è chiaro se l’errore sia causato dallo stato dell’utente, dal metodo di autenticazione, dal gruppo o dalla regola di accesso, Risolvere sistematicamente gli errori di autenticazione di Sophos Firewall descrive la sequenza di controlli. Per un’analisi dettagliata, /log/access_server.log contiene eventi di autenticazione, autorizzazione e accounting; Log Viewer rimane il primo passo.

Gestione delle password, MFA e utilizzo

Per modificare come amministratore la password di un account locale esistente in SFOS 22 e 23, si apre l’utente interessato in Authentication > Users e si fa clic su Change password. Prima si verificano l’account e il relativo responsabile e si prepara una nuova password lunga e univoca secondo il processo approvato di gestione delle password. Si inserisce la nuova password, si salva la modifica e si consegna il segreto in modo sicuro alla persona autorizzata. Si verifica quindi un nuovo accesso con la nuova password al servizio effettivamente utilizzato. Questa operazione in WebAdmin è distinta dal self-service in User Portal; gli account autenticati esternamente rimangono gestiti dalla rispettiva fonte di utenti. Questo non garantisce che le sessioni esistenti vengano terminate automaticamente.

Un utente locale può modificare la propria password in User Portal > Personal > Change Password. Questo vale per il database locale, non per account AD, LDAP o RADIUS autenticati esternamente. In Personal > Personal Details, l’utente può anche modificare il nome visualizzato. Username e indirizzo e-mail rimangono di sola lettura e vengono gestiti dall’amministratore nell’oggetto utente. User Portal viene reso raggiungibile solo dalle zone necessarie e non viene aperto indiscriminatamente alla WAN solo per questa manutenzione.

Per una protezione aggiuntiva, selezionare l’account in Authentication > Multi-factor authentication. Con Generate OTP token with next sign-in, l’utente registra il token tramite User Portal o VPN Portal. MFA per Sophos Firewall spiega l’algoritmo di hash, l’accesso al portale, il ripristino e il rollout pilota. Abilitare la MFA solo dopo aver testato l’accesso normale e la procedura di ripristino.

In Authentication > Users > > View usage si vedono le quote assegnate, il tempo di Surfing e il consumo di dati. Per visualizzarli, il traffico deve corrispondere a una regola firewall basata su utenti con Log firewall traffic. Reset user accounting azzera i contatori Surfing e Network Traffic e non viene quindi usato come rimedio generico per problemi di accesso.

Annullare la modifica e rimuovere l’account

Prima della fase pilota, documentare l’ordine esistente in Authentication > Services e tutte le impostazioni modificate relative a gruppi, portali, regole e VPN. In questo modo, il rollback non dipenderà da valori predefiniti presunti. In caso di partenza di una persona, fallimento del progetto pilota o venir meno della necessità dell’account, procedere nell’ordine inverso:

1. Verificare le dipendenze in regole, gruppi, policy Remote Access, quote, MFA e documentazione.
2. In Authentication > Users, selezionare l’utente e impostare Change status su Inactive.
3. Tentare un nuovo accesso come test negativo.
4. In Current activities > Live users, verificare le sessioni esistenti e usare Disconnect per un utente normale quando necessario.
5. Rimuovere l’utente da regole firewall e politiche di accesso remoto, o ripristinare la selezione precedente documentata.
6. Ripristinare esattamente lo stato precedente documentato per le impostazioni modificate dei gruppi, dei portali e dei servizi di autenticazione.
7. Controllare i log del firewall, della VPN e della configurazione per individuare ulteriori tentativi, traffico residuo e le modifiche effettuate.
8. Eliminare l’account solo dopo aver risolto le dipendenze oppure mantenerlo inattivo secondo il processo di conservazione.

La guida di SFOS non conferma che la disattivazione termini tutte le connessioni esistenti. Controllare e disconnettere separatamente le sessioni e i tunnel. Dopo una riattivazione, ripetere i test positivi e negativi.

Prima di un’eliminazione rischiosa, è possibile esportare l’oggetto di configurazione User con Include dependent entity in Backup and firmware > Import export. L’esportazione contiene dati sensibili, comprese le password, e deve essere crittografata e archiviata in una posizione ad accesso controllato. Anche la Secure Storage Master Key corretta deve essere disponibile per un’importazione successiva. Un’importazione aggiorna la configurazione esistente e applica i valori importati in caso di sovrapposizione. Le dipendenze condivise esportate insieme all’oggetto possono quindi essere sovrascritte. Verificare il contenuto e gli effetti prima dell’importazione, preferibilmente in un ambiente di test adeguato.

Un backup completo non è un rollback rapido per un utente: un ripristino sostituisce l’intera configurazione, riavvia il firewall e scarta le modifiche successive. Backup e ripristino su Sophos Firewall spiega il processo.

In un cluster HA, effettuare la modifica sul nodo primario, quindi verificare lo stato della sincronizzazione. I log e i report non vengono sincronizzati tra i nodi e devono essere esaminati separatamente durante la diagnosi.

Utenti e gruppi condividono ID interni. Un numero elevato di oggetti da solo non dimostra un problema. Se però un utente mostra un User ID superiore a 65535 e non viene autenticato, si usa il flusso separato relativo al limite della User ID di Sophos Firewall, invece di modificare password o regole per tentativi.

Individuare gli errori in base al sintomo

Username e password vengono rifiutati

In Authentication > Users, verificare che l’account sia locale, attivo e presente con lo username previsto. Poi, in Authentication > Services, controllare che Local sia selezionato per il servizio specifico. Un accesso riuscito a un altro portale non dimostra questa selezione del servizio.

L’accesso funziona, ma la regola utente non corrisponde

In Current activities > Live users, verificare identità, IP di origine e Client Type. Quindi controllare in Log Viewer la posizione della regola, Source Zone, utente o gruppo e Firewall Rule ID. Una regola di rete sopra la regola utente potrebbe già corrispondere al traffico.

Una modifica al gruppo non ha effetto

Cercare nell’utente valori specifici per quota, Access Time, Traffic Shaping o Remote Access. Questi override hanno la precedenza sul gruppo. Ripristinare l’ereditarietà del gruppo solo dopo aver confrontato il valore con l’eccezione documentata.

L’utente può accedere da un’origine inattesa

Verificare Sign-in restriction sia sull’utente sia sul gruppo. Controllare inoltre il servizio effettivamente utilizzato, Device Access e la regola di rete. MFA o una regola firewall restrittiva non compensano automaticamente una configurazione Any node.

View usage rimane vuoto

Verificare che l’utente sia riconosciuto come Live User e che il traffico corrisponda a una regola basata su utenti con Log firewall traffic. Controllare poi intervallo temporale, assegnazione della quota e traffico di test reale. Reset user accounting non genera log mancanti e non corregge una regola errata.

Checklist operativa

• Live users mostra pilotuser01, l’IP sorgente previsto e il Client Type previsto.
• Il registro di autenticazione conferma il login locale; Local-Pilot-to-WAN o il relativo Firewall Rule ID corrisponde al traffico di prova.
• Una password errata, una fonte non consentita e una funzione non autorizzata forniscono le prove negative attese.
• Gli override utente, Simultaneous sign-ins, Sign-in restriction e ogni eventuale data di scadenza sono documentati.
• La registrazione MFA e la procedura di ripristino sono state testate, se si utilizza la MFA.
• Lo stato precedente, il responsabile, la disattivazione, la disconnessione delle sessioni e la successiva eliminazione sono documentati.

Domande frequenti