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, singoli collaboratori esterni o a un accesso di emergenza mantenuto intenzionalmente. Tuttavia, la sola creazione dell’account non concede alcun accesso. Gruppo, metodo di autenticazione, portale o client, policy firewall o VPN e verifica finale devono essere coerenti.

Il percorso breve e sicuro è il seguente:

1. Definire il caso d’uso, il gruppo di destinazione 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 occorre quindi definire lo schema dei nomi, il tipo di account e il responsabile. Un nuovo account con un altro nome crea una nuova identità e può separare regole, quote, assegnazioni VPN, log 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 consapevolmente. 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 accesso alternativo documentato quando una fonte utenti esterna non è temporaneamente disponibile.

Non è consigliabile usare un account locale condiviso da più persone. Credenziali condivise rendono più difficili i cambi password, MFA, le quote, l’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.

Pianificare l’esempio e i prerequisiti

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;
• origine di accesso consentita 10.20.30.0/24.

example.com è un dominio riservato alla documentazione; 10.20.30.0/24 viene usato qui solo come rete privata di esempio. Username, indirizzo e-mail, gruppo, regola e rete vanno sostituiti con i valori dell’ambiente reale. Lo username è volutamente neutro e non contiene un indirizzo e-mail, così una successiva modifica dell’e-mail non cambia l’identità di accesso. In produzione, lo schema dei nomi dovrebbe essere coerente con helpdesk, offboarding e 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.
2. Inserire Local Pilot User in Name.
3. Impostare User type su User.
4. Inserire e confermare una password lunga e individuale prevista dal processo password adottato.
5. In Email, inserire pilotuser01@example.com o l’indirizzo reale del responsabile.
6. In Group, selezionare Local_Pilot_Users.
7. Modificare i campi policy e Remote Access solo quando è prevista 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. L’articolo non mostra volutamente una password di esempio. Una password copiabile nella documentazione diventerebbe immediatamente un segreto noto e non sarebbe 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 si assegna solo una policy già compresa.

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 proprio o scegliere Unlimited. Sessioni illimitate sono raramente necessarie per un normale utente 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.

Nell’esempio si usa la rete reale di amministrazione, utenti o VPN, senza copiare alla cieca 10.20.30.0/24. Una selezione troppo restrittiva blocca accessi legittimi. Any node, invece, amplia solo le possibili origini di accesso e non sostituisce una regola firewall, una ACL del portale o 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 realmente il database locale. In Authentication > Services si seleziona quindi Local per il servizio previsto.

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.

Portale, regola o policy VPN rimangono separati

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.

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 la regola o policy attesa.
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 riguardi il database locale, la selezione del servizio, lo stato utente, il gruppo o la regola successiva, risolvere sistematicamente gli errori di autenticazione di Sophos Firewall fornisce l’intera sequenza. Per un’analisi più approfondita, /log/access_server.log contiene eventi di autenticazione, autorizzazione e accounting; Log Viewer rimane il primo passo.

Gestire password, MFA e utilizzo

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. User Portal viene reso raggiungibile solo dalle zone necessarie e non viene aperto indiscriminatamente alla WAN solo per la gestione delle password.

Per una protezione aggiuntiva, l’account può essere selezionato 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 algoritmo hash, accesso al portale, ripristino e fase pilota. MFA viene attivata solo quando l’accesso normale e il percorso di ripristino funzionano.

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 riavvia i contatori Surfing e Network Traffic e non viene quindi usato come rimedio generico per problemi di accesso.

Disattivare e rimuovere correttamente l’account

Quando una persona lascia l’organizzazione o termina lo scopo dell’account, quest’ultimo non viene eliminato subito senza controlli:

1. Verificare le dipendenze in regole, gruppi, policy Remote Access, quote, MFA e documentazione.
2. In Authentication > Users, selezionare l’utente e usare Change status per renderlo inattivo.
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. Controllare i log firewall e VPN per individuare ulteriori tentativi o traffico residuo.
6. Eliminare l’account solo dopo aver chiarito le dipendenze oppure mantenerlo inattivo secondo il processo di conservazione.

La disattivazione non viene considerata una garanzia di chiusura automatica di tutte le connessioni esistenti. Sessioni, tunnel e traffico vengono verificati separatamente. Dopo una riattivazione si ripetono i test positivi e negativi.

Utenti e gruppi condividono ID interni. Un numero elevato di oggetti da solo non dimostra un problema. Se però un utente mostra una 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 aver già intercettato il flusso.

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. Un valore viene riportato all’ereditarietà del gruppo solo dopo il confronto 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

• Il caso d’uso, il responsabile e la data di scadenza dell’account sono documentati.
• Username e tipo di utente sono stati scelti consapevolmente prima del salvataggio.
• Un gruppo di tipo Normal contiene la baseline comune.
• Gli override utente sono evitati o giustificati.
• Simultaneous sign-ins e Sign-in restriction sono adatti al caso d’uso.
• Local è selezionato per ogni servizio di autenticazione necessario.
• Portale, regola firewall o policy VPN sono stati configurati separatamente.
• Accesso positivo, accesso negativo e traffico reale sono stati verificati.
• Live Users, Authentication Log e la regola o policy attesa sono coerenti.
• MFA e ripristino sono stati testati, se si usa MFA.
• Una persona responsabile gestisce cambi password, utilizzo e offboarding.
• Disattivazione, sessioni esistenti ed eliminazione successiva sono passaggi separati.

Domande frequenti