Configurare e testare i Clientless Users su Sophos Firewall

Una stampante, un server o un altro dispositivo fisso spesso non può accedere al firewall. Clientless Users assegna comunque un’identità comprensibile a questo traffico: Sophos Firewall associa un nome utente configurato all’IP sorgente visibile e può usare tale identità nelle regole, in Live Users e nei log.

Non si tratta di autenticazione. Chiunque acquisisca l’IP configurato o compaia dietro lo stesso indirizzo NAT può ricevere la medesima associazione. Clientless Users è quindi adatto solo a dispositivi con indirizzo stabile e sotto controllo. Per dispositivi personali variabili, IP condivisi o accessi privilegiati, è preferibile un vero metodo di login.

⚠️ Clientless Users non è Clientless SSL VPN. Clientless Users associa internamente un IP a un’identità. Clientless SSL VPN, invece, pubblica bookmark RDP, SSH o di file server nel VPN Portal.

Clientless User in otto passaggi

Pianificare in anticipo l’interruzione: Prima di Change status, documentare lo stato attuale, le regole interessate e la procedura di ripristino prevista. Eseguire il test negativo solo su un dispositivo pilota sotto controllo e in una finestra concordata: la disattivazione può interrompere le connessioni necessarie al dispositivo. Per il test, generare una nuova connessione e non limitarsi a osservare una sessione già in corso. In caso di effetti inattesi, ripristinare lo stato documentato in precedenza e verificare nuovamente la connessione originale.

1. Definire il dispositivo, il responsabile, le destinazioni necessarie e l’IP sorgente visibile al firewall.
2. Configurare l’indirizzo in modo statico o associarlo senza ambiguità tramite una prenotazione DHCP.
3. In Authentication > Groups, creare un piccolo gruppo di tipo Clientless.
4. In Authentication > Clientless users > Add, creare esattamente un utente pilota con questo IP.
5. Creare una regola firewall separata e con logging, con la sorgente esatta, Match known users e il gruppo clientless.
6. Controllare l’utente in Current activities > Live users e il flusso reale in Log Viewer.
7. Impostare brevemente l’utente su Inactive e confermare che la regola basata sull’identità non corrisponda più.
8. Riattivare l’utente, validare nuovamente la regola e documentare l’associazione, il responsabile e la data di revisione.

Quando Clientless Users è adatto

Clientless Users è utile quando una regola firewall o un report richiede un’identità stabile del dispositivo, ma questo non può eseguire un login utente. I candidati tipici sono stampanti, appliance di monitoraggio, dispositivi di laboratorio o server di infrastruttura fortemente limitati.

La funzione è adatta solo se sono soddisfatti tutti i punti seguenti:

• Il firewall vede sempre lo stesso IP sorgente univoco per il traffico.
• L’indirizzo è statico o associato tramite una prenotazione DHCP controllata.
• L’indirizzo non rappresenta più dispositivi dietro NAT o proxy.
• L’identità accede solo alle destinazioni e ai servizi realmente necessari al dispositivo.
• Un altro dispositivo non può acquisire l’indirizzo senza che ciò venga rilevato.
• È possibile eseguire un test positivo e uno negativo con un flusso di dati reale.

Per i normali client di dominio, STAS è generalmente più adatto. Se l’accesso di rete genera già RADIUS Accounting, RADIUS SSO Accounting può creare dinamicamente l’associazione utente-IP. Il Captive Portal offre un login interattivo.

Clientless Users non è una scorciatoia per sostituire una segmentazione mancante. Una stampante deve comunque trovarsi in una zona appropriata o in una rete separata e avere una regola ristretta. L’identità basata su IP integra questo controllo, ma non lo sostituisce.

Funzionamento e limite di sicurezza

Sophos Firewall mostra un Clientless User attivo come Live User senza login interattivo. Quando un pacchetto corrisponde all’IP configurato, il nome utente associato è disponibile per regole basate sull’utente e reporting.

Questo non fornisce alcuna prova crittografica del dispositivo o della persona:

• Non esistono password né secondo fattore.
• L’associazione non verifica una sessione personale Windows o Entra.
• Una modifica dell’IP non viene interpretata automaticamente come cambio di dispositivo.
• Un IP NAT o proxy condiviso non permette di distinguere i singoli endpoint.
• Un Clientless User non è un utente VPN di accesso remoto.

Se servono regole personali, Clientless Users dovrebbe essere usato solo in casi eccezionali ben controllati. Per una persona con postazione fissa, l’associazione DHCP deve essere stabile, ma l’identità continua a descrivere l’IP e non la persona davanti allo schermo.

Esempio e valori da sostituire

La procedura utilizza una stampante che può raggiungere solo DNS, NTP e un print server interno:

• Username: Printer-Accounting
• indirizzo IP visibile: 192.0.2.50
• gruppo clientless: Clientless-Devices
• regola firewall: Printer-Accounting_to_Services
• Source network: oggetto host Printer-Accounting_192.0.2.50
• destinazione: servizio DNS/NTP interno e print server previsto
• revisione: responsabile e prossima data di controllo nella descrizione della regola

192.0.2.50 appartiene all’intervallo ufficiale di documentazione IPv4 e non è un indirizzo di produzione. Deve essere sostituito con l’IP fisso che il firewall vede come sorgente del flusso reale. Questo esempio viene validato con IPv4. Prima di utilizzare IPv6, verificare esplicitamente l’associazione Clientless e la configurazione delle regole appropriata per la versione di SFOS installata; una validazione riuscita con IPv4 non dimostra il funzionamento con IPv6.

I nomi dell’esempio mostrano lo scopo, ma non sono requisiti del prodotto. In un ambiente reale, utente, gruppo, oggetto host e regola dovrebbero seguire uno schema di denominazione coerente.

Preparare indirizzo e gruppo

Confermare l’IP sorgente visibile

Prima di configurare l’identità, generare esattamente un flusso di dati controllato dal dispositivo. In Log Viewer o Packet Capture, registrare almeno Source IP, In interface, destinazione, servizio e Firewall Rule ID precedente.

Se la sorgente visibile è un indirizzo NAT, proxy o gateway condiviso, fermarsi qui. Questo indirizzo non deve essere assegnato a un singolo Clientless User. In caso contrario, tutti i dispositivi dietro tale indirizzo riceverebbero la stessa identità.

Con DHCP, creare una prenotazione per questo dispositivo specifico. Inserire nel firewall un indirizzo libero del pool non è sufficiente: se il server DHCP lo assegna in seguito a un altro client, quest’ultimo eredita l’identità e potenzialmente le autorizzazioni della regola.

Creare un gruppo clientless

In Authentication > Groups > Add, creare un gruppo separato:

1. Inserire Clientless-Devices come Name.
2. Selezionare Clientless come Group type.
3. Impostare solo le policy di gruppo necessarie.
4. Salvare con Save.

Le policy specifiche dell’utente hanno priorità rispetto a quelle del gruppo assegnato. Il gruppo dovrebbe quindi avere uno scopo di base comune e comprensibile. Le eccezioni per il singolo utente vengono documentate e testate separatamente.

I Clientless Users non supportano Surfing quota, Access time o Network traffic policy. Se un dispositivo fisso deve comunicare solo in determinati orari, si utilizza uno Schedule nella regola firewall con ambito ristretto. Access Time per utenti e gruppi si applica invece a utenti normali, gruppi e utenti guest. Surfing Quota e Network Traffic Quota richiedono anch’esse un’assegnazione utente o gruppo supportata.

Anche MAC binding, User type and profile e le policy VPN di accesso remoto non sono disponibili per i Clientless Users. L’identità clientless basata sull’IP non consente quindi né di vincolare un’identità a un dispositivo né di autenticare un utente VPN.

Gestire correttamente i gruppi utenti e il gruppo principale su Sophos Firewall spiega perché i gruppi Normal, importati e Clientless rappresentano modelli di identità diversi. Questo articolo resta dedicato alla procedura Clientless completa basata sull’IP.

Aggiungere un singolo Clientless User

In Authentication > Clientless users > Add, impostare i campi come segue:

1. Username: Printer-Accounting
2. IP address: l’indirizzo fisso del dispositivo confermato in precedenza
3. Group: Clientless-Devices
4. Name: un nome visualizzato comprensibile per il dispositivo
5. Email: inserire un indirizzo reale del responsabile solo se necessario per funzioni come Quarantine Digest
6. Quarantine digest: attivare solo consapevolmente; per una normale stampante la funzione resta generalmente disattivata
7. Salvare con Save.

In seguito è possibile riaprire l’utente e aggiungere le impostazioni specifiche supportate. Una modifica viene considerata riuscita solo quando Live Users, il match della regola e il traffico reale risultano nuovamente corretti.

Dopo Save, in Authentication > Clientless users aprire Edit per l’utente. In Traffic shaping (quality of service) è possibile selezionare una policy esistente o crearne una nuova. Quarantine digest invia alla casella dell’utente un elenco delle e-mail trattenute in quarantena; per un dispositivo senza una casella di riferimento, questa funzione resta disattivata. Dopo il salvataggio, verificare nuovamente le policy effettive dell’utente e del gruppo e il flusso previsto.

Usare Add range solo con una motivazione chiara

Authentication > Clientless users > Add range crea Clientless Users individuali per tutti gli indirizzi tra From IP e To IP. Sophos assegna il gruppo selezionato; ogni utente generato può poi essere modificato singolarmente.

Un normale pool DHCP non è adatto. Un intervallo tratterebbe in anticipo come identità nota ogni indirizzo assegnato successivamente. Add range è indicato solo per un blocco di indirizzi interamente riservato e documentato, con uno scopo uniforme, assegnazione controllata e successiva verifica individuale. Per il primo rollout, Add con un solo IP rimane l’opzione sicura.

Per un blocco approvato, in Add range inserire il primo indirizzo del dispositivo in From IP, l’ultimo in To IP e selezionare il gruppo clientless preparato in Group. Esempio: da 192.0.2.50 a 192.0.2.52 indica tre indirizzi di dispositivi sotto controllo; entrambi gli estremi devono essere sostituiti con quelli del proprio blocco riservato. Salvare con Save, quindi aprire ogni utente generato in Authentication > Clientless users tramite Edit e controllare l’IP, il gruppo e le policy individuali necessarie. Per ogni dispositivo, verificare l’associazione prevista in Live Users e i flussi consentiti e non consentiti; un test riuscito sul pilota non sostituisce la validazione delle altre voci.

Per controllare l’elenco in Authentication > Clientless users, fare clic su Show additional properties e selezionare i campi necessari. È possibile modificare l’ordine nell’elenco a discesa tramite drag-and-drop; confermare con Ok. Questa vista facilita il confronto delle voci, ma non sostituisce l’apertura e la verifica delle singole configurazioni.

API XML: distinguere Add, Add range e Update

La procedura GUI descritta sopra non è una ricetta XML. I riferimenti API per SFOS 22.0 e 23.0 lasciano aperte importanti questioni sulla rappresentazione di Add e Update:

• Add: La tabella indica Username, Group, Name ed Email come obbligatori e li definisce, insieme a IP Address e Spam Digest, come ARRAY. L’esempio mostra invece un solo ClientlessUser con valori singoli, tra cui UserName e ClientLessGroup. Questo non dimostra né un’associazione sicura tra utenti, IP, gruppi e indirizzi e-mail né un batch eseguibile. L’indicazione che i duplicati non vengono ignorati non spiega come siano elaborati. Inserire Email solo quando necessario nella GUI sopra non annulla il requisito API; Add range è una procedura GUI distinta, non la prova di un serializzatore di array. Nell’esempio compare espressamente <!--only for Edit --> prima di QoSPolicy e Status; non dedurne campi di Add o uno stato predefinito.
• Update: Username, Name, Group e IP Address diventano SCALAR, mentre Email resta un ARRAY obbligatorio. La tabella richiede anche Web Filter, App Filter e QOS; l’esempio non mostra tag dei filtri e non dimostra la corrispondenza di QOS con QoSPolicy. Copiare l’esempio di Add non fornisce quindi un Update di cui sia dimostrata la completezza.
• Digest: L’esempio include anche ApplyGroupSettings per QuarantineDigest, ma la tabella di Update indica solo Disable ed Enable per Spam Digest. Il suo valore predefinito è letteralmente Disbale: un valore incoerente nel riferimento, non un valore predefinito confermato durante l’esecuzione. Non dedurne l’ereditarietà del gruppo né il comportamento dei campi omessi; neanche Add specifica un valore predefinito per il digest.

Chiarire il contratto del build installato prima di modifiche API che dipendono da questi dettagli; finché la rappresentazione non è chiara, usare la procedura GUI supportata con Edit o Change status. Prima di una modifica, registrare i valori precedenti effettivi di policy, digest e stato. Dopo, confrontare con precisione identità, IP, gruppo e policy salvati e verificare nuovi flussi consentiti e bloccati. In caso di effetti inattesi, ripristinare i valori originali invece di reimpostare presunti valori predefiniti, quindi verificare nuovamente. Questi limiti della documentazione non smentiscono l’ereditarietà del gruppo nella GUI.

Creare una regola firewall ristretta

Comprendere e configurare in sicurezza le regole di Sophos Firewall spiega la logica generale. Per questo esempio, creare una regola separata sopra una regola più generale per stampanti o LAN:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: attivato
• Source zone: la zona effettiva del dispositivo
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zona dei servizi previsti
• Destination networks: solo destinazione DNS/NTP e print server
• Services: solo le porte necessarie
• Match known users: attivato
• Users or groups: Clientless-Devices o il singolo utente pilota

L’IP sorgente e la condizione utente possono essere usati insieme intenzionalmente. L’IP limita l’origine tecnica, mentre l’identità rende comprensibili regola e reporting. Per un dispositivo fisso non servono una sorgente Any o una destinazione Any generiche.

Dopo il salvataggio, verificare che nessuna regola più generale posta sopra corrisponda prima. Solo la Firewall Rule ID in Log Viewer o Packet Capture mostra quale regola elabora il flusso reale. Testare una regola Sophos Firewall offre la procedura guidata.

Test positivo e negativo

Controllare identità e flusso consentito

1. In Current activities > Live users, cercare Printer-Accounting e l’IP previsto.
2. Generare esattamente un flusso previsto dal dispositivo.
3. In Log Viewer, confrontare utente, Source IP, Firewall Rule ID, nome regola, servizio e azione.
4. Verificare che la destinazione riceva la richiesta e che il percorso di ritorno funzioni.
5. Testare un servizio o una destinazione non previsti e confermare il drop atteso.

La sola voce in Live Users non è sufficiente. Conferma l’associazione attiva, ma non la posizione della regola, il servizio consentito o il percorso dati.

Usare il cambio di stato come test negativo

Un Clientless User non deve essere disconnesso con Disconnect in Live Users. In Authentication > Clientless users, selezionare l’utente pilota e usare Change status per impostarlo su Inactive.

L’utente non deve più comparire come Clientless User in Live Users. Una nuova connessione di test non deve più corrispondere alla regola pilota basata sull’utente con tale identità. Impostare quindi nuovamente l’utente su Active e ripetere il test positivo.

Questo test non deve produrre un allow inatteso tramite una regola più generale. Se la connessione deve restare consentita dopo la disattivazione, documentare e testare consapevolmente anche la regola di fallback prevista.

Eseguire il troubleshooting in modo sistematico

L’utente non compare in Live Users

• Verificare che lo stato in Authentication > Clientless users sia Active.
• Confrontare l’IP configurato con la sorgente effettivamente visibile nel pacchetto.
• Cercare un Username duplicato o un IP già utilizzato.
• Esaminare separatamente il traffico IPv4 e IPv6.
• In presenza di molti oggetti utente e gruppo, controllare la User ID interna specifica. Il limite User ID non viene diagnosticato da un conteggio approssimativo degli oggetti.

Secondo l’attuale guida SFOS, Clientless Users compare in Live Users subito dopo la configurazione. Il riavvio di un servizio, interventi sul database o ripetute eliminazioni e ricreazioni non fanno parte del normale percorso di configurazione.

L’utente è visibile, ma corrisponde la regola sbagliata

• Controllare Match known users, l’utente o il gruppo selezionato e lo stato della regola.
• Confrontare Source zone, Source network, Destination zone, destinazione e servizio con il flusso reale.
• Verificare la posizione della regola ed eventuali regole più generali poste sopra.
• In Log Viewer, non filtrare solo per nome utente; confrontare anche Firewall Rule ID e Source IP.
• Creare una nuova connessione e verificarne la Firewall Rule ID attuale; una sessione già in corso non è sufficiente per questo test.

La regola firewall non corrisponde fornisce la logica di troubleshooting dettagliata.

Il dispositivo sbagliato riceve l’identità

L’assegnazione IP non è sufficientemente controllata. Verificare lease DHCP, prenotazione, configurazione statica, IP duplicato, NAT e proxy. Disattivare la regola o impostare il Clientless User su Inactive finché non è certo quale dispositivo usi l’indirizzo sorgente.

Non creare un intervallo più ampio per catturare indirizzi variabili. Ciò amplia l’errata assunzione di fiducia e rende più difficile l’attribuzione successiva.

QoS non si applica con molti Clientless Users

Sophos documenta NC-148705 come risolto in SFOS 22.0 MR1 Build 490: una QoS Policy non veniva applicata quando erano presenti più di 3000 Clientless Users. Le note di rilascio non indicano un intervallo di versioni interessate.

Se il sintomo coincide esattamente, registrare versione e build del firmware e pianificare un aggiornamento supportato almeno a MR1 Build 490 o a una versione compatibile successiva. Un problema QoS con meno utenti o su un altro build non dimostra NC-148705; controllare normalmente assegnazione della policy, match della regola e Traffic Shaping.

Interpretare log e HA

access_server.log contiene eventi di autenticazione, autorizzazione e accounting. Per il flusso dati restano decisivi log firewall, Log Viewer e Packet Capture. Log dei servizi Sophos Firewall spiega l’associazione dei log.

In un cluster HA, configurazione e funzionamento vengono gestiti sul Primary corrente. In questo contesto, il subentro senza interruzioni per l’associazione Clientless non viene dato per garantito. Dopo un failover controllato, verificare nuovamente Clientless User, match della regola, flusso reale e log locali del nodo che ha elaborato l’evento.

Gestione e rollback

Ogni Clientless User deve avere un responsabile, uno scopo e una data di revisione. In caso di sostituzione del dispositivo, cambio di rete o cessata necessità della regola, l’associazione non deve rimanere senza controllo.

Salvare i valori di utilizzo prima di un reset: Con l’utente aperto, View usage mostra l’utilizzo Internet registrato. Reset user accounting azzera queste statistiche; l’attuale guida Sophos parla anche di riavviare la Network Traffic Quota, ma nella stessa pagina indica che Network traffic policy non è supportata per i Clientless Users. Il reset non va quindi utilizzato per riparare una quota. Prima si documentano i contatori e l’effettiva assegnazione delle policy. I valori individuali di Traffic shaping e Quarantine digest hanno la precedenza sulle impostazioni del gruppo Clientless.

Il rollback controllato:

1. Documentare la regola, il gruppo, i report e le dipendenze di Traffic Shaping interessati.
2. Impostare il Clientless User su Inactive.
3. Verificare negativamente lo stato Live Users e il flusso dati reale.
4. Modificare la regola o la condizione utente nello stato successivo previsto.
5. Eliminare il Clientless User quando non è più necessario.
6. Rimuovere il gruppo solo quando nessun altro utente o policy ne ha bisogno.
7. Ripulire separatamente prenotazione DHCP, oggetto host e documentazione.

Non eliminare un’identità di produzione durante un incidente aperto prima di aver conservato Source IP, Rule ID e log. Se l’associazione non è chiara, limitare prima l’accesso e preservare le prove.

FAQ