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

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. Con IPv6 servono un indirizzo IPv6 fisso, una regola IPv6 separata e una validazione distinta.

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.

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.

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.

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, perché le sessioni esistenti non vengono rivalutate automaticamente.

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. Sophos non documenta alcuna garanzia che gli stati Live Users o delle sessioni di Clientless Users sopravvivano senza interruzione a un failover. 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.

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