Configurare Client Authentication Agent su Sophos Firewall

Il Client Authentication Agent, o CAA, è adatto a singoli endpoint Windows, macOS o Linux sui quali l’utente effettua consapevolmente l’accesso al firewall. Dopo un login riuscito, l’identità appare come Authentication agent in Current activities > Live users. Le regole firewall e web basate su utenti o gruppi possono quindi associare il traffico a questa identità.

L’agente non sostituisce ogni architettura SSO. Un terminal server con più utenti simultanei richiede SATC, mentre STAS può gestire l’accesso senza un agente endpoint in un dominio Windows. CAA è destinato soprattutto a un numero gestibile di singoli dispositivi in cui l’accesso manuale dell’utente è accettabile.

Importante: L’agente deve raggiungere il percorso di autenticazione documentato da Sophos. In Administration > Device access, il servizio locale Clients deve quindi essere consentito per la zona sorgente. CAA usa TCP 9922; una VPN, una default route diversa o un router a monte possono deviare dal firewall il percorso verso 1.2.3.4. Prima di un rollout esteso, testare Local Service ACL, route, CA TLS, login pilota e corrispondenza effettiva della regola su un dispositivo.

CAA in dieci passaggi

1. Verificare che l’endpoint rappresenti un solo utente attivo; usare SATC per RDS, Citrix o altri host multiutente.
2. Documentare server di autenticazione, gruppo utenti, policy firewall e un metodo locale di ripristino.
3. In Administration > Device access, consentire Clients per la zona sorgente. Su TCP 9922, verificare il percorso verso 1.2.3.4 per Windows e macOS oppure verso l’IP del firewall impostato in caa.conf per Linux.
4. Scaricare l’agente adatto e la relativa Server CA in Authentication > Client downloads.
5. Per la distribuzione Windows su larga scala, pianificare insieme Download MSI e Download CA for MSI; gli installer singoli includono agente e CA.
6. Installare l’agente su un dispositivo pilota senza distribuirlo ancora in modo esteso.
7. In Authentication > Services > Firewall authentication methods, controllare il server di autenticazione previsto e il relativo ordine.
8. Accedere con un utente pilota e confermare il tipo di client Authentication agent in Current activities > Live users.
9. Eseguire un flusso consentito e uno bloccato, quindi controllare utente, policy e Firewall Rule ID nel Log Viewer.
10. Solo a quel punto documentare deployment, comportamento MFA, test HA, processo di supporto e rollback.

Quando è adatto Client Authentication Agent

CAA invia al firewall l’accesso dell’utente dall’endpoint. È particolarmente adatto per:

• singoli endpoint gestiti ma non appartenenti al dominio;
• piccoli ambienti senza infrastruttura STAS;
• dispositivi in cui un cambio di utente deve provocare deliberatamente un nuovo login dell’agente;
• policy che richiedono un vero nome utente e non solo un IP sorgente.

L’agente non è una soluzione generale per più utenti simultanei dietro lo stesso IP host. SATC sui sistemi Remote Desktop spiega l’approccio basato sulle sessioni per Citrix, RDS e terminal server. In un ambiente AD, STAS su Sophos Firewall è l’alternativa senza client.

CAA autentica l’utente, ma non crea un’autorizzazione di rete. Regole firewall, Web Policies, gruppi, quote e Access-Time-Policies restano livelli separati. Un Live User visibile non dimostra quindi che il traffico desiderato corrisponda alla regola corretta.

Esempio e prerequisiti

Il pilota utilizza:

• IP LAN del firewall: 10.20.30.1
• Dispositivo pilota: 10.20.30.50
• Utente pilota: fw-user-pilot
• Gruppo utenti: CAA-Pilot
• Destinazione agente: 1.2.3.4
• Porta TCP: 9922

10.20.30.1 e 10.20.30.50 sono valori privati di documentazione da sostituire con gli indirizzi reali. 1.2.3.4 e TCP 9922 costituiscono invece il percorso dell’agente documentato da Sophos per Windows e macOS e non vengono sostituiti come normali valori ambientali. Per Linux, le istruzioni dello User Portal usano un file di configurazione dedicato e richiedono l’IP reale del firewall.

Prima dell’installazione occorre chiarire questi punti:

• Il dispositivo pilota usa Sophos Firewall come gateway o dispone di un percorso verificato verso la destinazione dell’agente.
• Nessuna VPN full-tunnel né route esterna devia 1.2.3.4 dal gateway SFOS previsto.
• In Administration > Device access, Clients è consentito nella colonna della zona sorgente effettiva. Una regola firewall non può sostituire questa Local Service ACL.
• L’utente esiste localmente o su un server selezionato in Firewall authentication methods.
• Gruppo e policy sono pronti; al pilota non vengono assegnati preventivamente diritti più ampi.
• La Authentication Server CA associata all’installer proviene esclusivamente dal proprio firewall.
• Durante il pilota rimane disponibile un metodo di autenticazione alternativo funzionante.
• Se MFA è attivo, il token è registrato e il comportamento dell’agente viene testato separatamente.

Per SFOS 22, il limite dei sistemi operativi supportati da Client Authentication Agent comprende Windows 10 e versioni successive, Ubuntu 16.4 e versioni successive e macOS Catalina 10.15 e versioni successive. Questo limite di prodotto, legato a una versione specifica, non garantisce il supporto di ogni futura versione dei sistemi operativi; occorre quindi testare la versione esatta dell’endpoint prima del rollout.

Avanet consiglia di testare prima su un dispositivo la combinazione esatta di build SFOS, pacchetto agente, versione endpoint e protezione endpoint. Anche il successivo test negativo e il comportamento HA sono raccomandazioni operative; Sophos non documenta così una sessione ininterrotta durante un failover.

Preparare l’autenticazione sul firewall

In Authentication > Services > Firewall authentication methods viene selezionato almeno un server adatto o il database locale. Con più server, SFOS inoltra la richiesta nell’ordine visualizzato. Default Group, gruppo importato e stato utente devono quindi essere definiti prima del test dell’agente.

CAA è un servizio di autenticazione locale del firewall. In Administration > Device access, attivare Clients nella colonna della zona sorgente. Secondo Sophos, questa voce comprende CAA su TCP 9922 e STAS e SATC su UDP 6060. Le normali regole firewall non consentono i Local Services. Per una Custom Zone, l’accesso può essere controllato anche in Network > Zones.

Per gli account pilota locali, consultare creare e testare utenti locali in sicurezza. Per AD, LDAP o RADIUS, testare prima il rispettivo server con la normale finestra di servizio. Un Test connection riuscito non dimostra tuttavia il successivo percorso CAA dall’endpoint.

Se MFA è attivo per lo User portal, Sophos specifica che il requisito si applica anche ai Client Authentication Agents. Registrazione e inserimento del token vengono quindi testati con lo stesso utente pilota. MFA non viene attivato a sorpresa solo dopo il rollout.

Scaricare agente e Server CA

Gli amministratori scaricano i pacchetti qui:

Authentication > Client downloads

Sophos fornisce queste varianti:

• Download MSI: agente Windows per la distribuzione automatizzata;
• Download CA for MSI: Authentication Server CA separata per il deployment MSI;
• Download for Windows: installer singolo con agente e CA;
• Download for macOS: installer singolo con agente e CA;
• Download for Linux 32 o Download for Linux 64: archivio con agente, configurazione e CA.

In alternativa, gli utenti autorizzati possono scaricare autonomamente i pacchetti da Download client > Authentication clients nello User Portal. Per questo percorso, selezionare almeno il server adatto in Authentication > Services > User portal authentication methods, quindi attivare User portal in Administration > Device access solo per la zona sorgente prevista. La porta predefinita è TCP 4443. Sophos sconsiglia di consentire lo User Portal dalla zona WAN; non serve un’ampia apertura WAN solo per il download.

Dopo un factory reset, il firewall rigenera la CA. Gli utenti devono quindi reinstallare la Authentication Server CA. Un vecchio agente con una vecchia CA non si ripara disattivando la verifica dei certificati o introducendo una CA estranea; il pacchetto corrente viene scaricato di nuovo dal firewall corretto.

Installare l’agente sul dispositivo pilota

Windows e macOS

In Windows si esegue client_auth_agent.exe dallo User Portal. Nella procedura guidata si scelgono percorso di installazione e cartella del menu Start; Install installa il client e Finish chiude la procedura e avvia l’agente. Un deployment MSI gestito deve distribuire insieme l’agente e Download CA for MSI. Il solo agente senza la CA associata non implementa il percorso TLS documentato.

In macOS si apre Client+Authentication+Agent.dmg. Trascinare entrambe le icone nelle rispettive cartelle, uscire dall’installer e avviare Client Authentication Agent da Applications. Anche qui la CA integrata deve provenire dal firewall sul quale l’utente accederà successivamente.

Installare prima il pilota in modo interattivo. Automatizzare distribuzione del pacchetto, avvio automatico e aggiornamento solo dopo un test end-to-end riuscito. Non riutilizzare un vecchio agente proveniente dal backup di un altro firewall o da un’altra appliance.

Linux

Per Linux, Sophos indica questo percorso di estrazione, sostituendo <FILENAME> con l’archivio scaricato:

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Controllare quindi la configurazione fornita in $HOME/.caa/caa.conf. La guida dello User Portal richiede per Linux di sostituire il valore dopo Copernicus host con l’indirizzo IP reale del firewall e inserire nome utente e password. Una password reale non viene scritta in script di deployment, ticket o esempi pubblici. Sophos specifica che al primo avvio l’agente cifra la password inizialmente salvata in chiaro.

Prima dell’avvio, controllare permessi, proprietario e contenuto di $HOME/.caa/README. Eseguire quindi caa come pilota. Poiché le istruzioni Linux usano un valore di destinazione diverso dal percorso generale Windows e macOS, non mescolare le procedure delle piattaforme.

Autenticare il pilota e testare le policy

Il pilota accede all’agente con il nome utente e la password previsti per il firewall. Con autenticazione esterna, questo formato esatto deve corrispondere alla configurazione del server. Un’indicazione positiva dell’agente è solo il primo test.

Sul firewall verificare quindi:

1. fw-user-pilot appare in Current activities > Live users.
2. Il tipo di client è Authentication agent.
3. IP sorgente e gruppo utenti corrispondono al dispositivo pilota e al mapping previsto.
4. Un flusso consentito corrisponde alla regola prevista basata su utente o gruppo.
5. Una destinazione volutamente non autorizzata resta bloccata.
6. Il log firewall mostra utente, regola, azione e Firewall Rule ID.
7. Dopo Disconnect in Live users, l’agente riceve la notifica documentata e il traffico viene rivalutato.

Per la regola di test non si crea un’ampia policy Any. Le regole esistenti vengono ampliate solo in modo controllato con l’utente o gruppo pilota. Testare sistematicamente le regole Sophos Firewall illustra il processo generale end-to-end.

Controllare log e HA

Aprire Log viewer nell’angolo superiore destro della console WebAdmin. Nel modulo Authentication, usare Add filter o la ricerca a testo libero per utente, IP sorgente e orario del test. La voce deve corrispondere al login dell’agente; nel modulo Firewall verificare anche traffico reale, azione e Firewall Rule ID. Affinché il test compaia, nella regola interessata deve essere attivo Log firewall traffic. Una sessione può essere registrata solo alla chiusura: terminare quindi correttamente il flusso di test oppure aggiornare la vista dopo una breve attesa.

Per una correlazione più approfondita sono rilevanti access_server.log per autenticazione e autorizzazione, insieme al Log Viewer o alla destinazione Syslog configurata. Un singolo stato del client senza la corrispondente voce nel log firewall non è una prova completa di successo.

In HA non si presume che un login agente esistente continui senza interruzioni. Dopo un failover controllato, testare nuovamente un login fresco, Live User, corrispondenza della policy e traffico reale. I log risiedono sul node che ha elaborato l’evento; se l’orario non è chiaro, verificare entrambi i nodes o una vista consolidata.

Delimitare gli errori per sintomo

L’agente non raggiunge il firewall

Controllare prima in Administration > Device access che Clients sia attivo per la zona sorgente. Verificare quindi routing e TCP 9922. In Diagnostics > Packet capture > Configure, inserire host 1.2.3.4 and port 9922 in Enter BPF string; la cattura mostra se il traffico dell’agente raggiunge Sophos Firewall. Per Linux, usare l’IP del firewall configurato in caa.conf al posto di 1.2.3.4.

Se il problema inizia solo dopo la connessione di un altro client VPN, verificare se la sua route full-tunnel prende il controllo della destinazione dell’agente. La soluzione non è un comando host route applicato alla cieca: valutare prima split tunnel, routing e impatto di sicurezza nel design reale. Se il percorso di autenticazione resta incerto, interrompere il rollout.

Compare un errore TLS o CA

Installer e CA devono provenire dallo stesso firewall attivo. Dopo un factory reset, la vecchia CA non è più valida e viene sostituita dal pacchetto attuale. Non disattivare la verifica dei certificati, la protezione endpoint o TLS come correzione rapida.

La password funziona nel portale, ma non nell’agente

In Firewall authentication methods, controllare ordine dei server, Default Group e stato utente. Verificare quindi requisito MFA, formato del nome utente, binding di IP sorgente o MAC e messaggio del log Authentication. Un login riuscito nel portale non prova automaticamente lo stesso metodo o percorso dell’agente.

L’utente è live, ma si applica la regola sbagliata

Controllare ordine delle regole, Match known users, utente o gruppo selezionato, servizio, destinazione e Firewall Rule ID. Identificare prima la regola effettivamente corrispondente; una regola allow ampia non sostituisce la diagnosi.

Su un terminal server appare una sola identità

CAA non è l’approccio corretto per questo percorso multiutente. Più istanze parallele dell’agente non trasformano l’host in un sistema consapevole delle sessioni. Per RDS o Citrix usare SATC e validarlo separatamente.

Per la diagnosi trasversale dei metodi, consultare verificare sistematicamente l’autenticazione di Sophos Firewall.

Rollback e gestione operativa

In caso di pilota fallito, arrestare o rimuovere l’agente sul dispositivo pilota. Riportare le modifiche temporanee a utenti, gruppi, portale e regole allo stato precedente documentato. Se Clients è stato consentito appositamente per il pilota, disattivarlo solo se nessun’altra installazione CAA, STAS o SATC della zona ne ha bisogno. Quindi testare di nuovo il metodo di autenticazione precedente con un nuovo login e traffico reale.

Non eliminare globalmente la Authentication Server CA mentre altre installazioni CAA la utilizzano. Prima di factory reset, reimage o sostituzione dell’appliance, pianificare l’aggiornamento della CA appena generata su tutti gli endpoint interessati.

Documentare almeno questi dettagli operativi:

• responsabile del pacchetto agente e del deployment;
• versioni dei sistemi operativi approvate;
• origine e rinnovo della Authentication Server CA;
• percorso previsto verso la destinazione dell’agente e TCP 9922;
• procedura MFA e password;
• test pilota e negativo dopo modifiche a SFOS, endpoint o VPN;
• offboarding e rimozione delle Live Sessions esistenti.

Checklist

• endpoint monoutente confermato anziché host multiutente
• server di autenticazione e ordine documentati
• Clients attivato nella Local Service ACL solo per la zona sorgente necessaria
• percorso dell’agente attraverso Sophos Firewall verificato
• agente e Authentication Server CA scaricati dallo stesso firewall
• MSI e CA separata pianificati insieme
• limiti delle piattaforme e percorso specifico Linux considerati
• utente pilota preparato con gruppo e policy minimi
• comportamento MFA testato
• Live User mostra Authentication agent
• traffico reale consentito e bloccato testato
• utente, azione e Firewall Rule ID confermati nel log
• comportamento VPN e HA testato con un nuovo login
• effetto del factory reset sulla CA e rollback documentati

Domande frequenti