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. I client Windows e macOS comunicano tramite 1.2.3.4 e TCP 9922; una VPN, una default route diversa o un router a monte possono deviare questo percorso dal firewall. Prima di un rollout esteso, testare 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. Dal dispositivo pilota, verificare il percorso verso 1.2.3.4 attraverso Sophos Firewall e TCP 9922.
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 attuali 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.
• 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.

La guida corrente di SFOS 22 indica come sistemi supportati Windows 10 e versioni successive, Ubuntu 16.4 e versioni successive e macOS Catalina 10.15 e versioni successive. È un limite della documentazione di prodotto attuale, non una garanzia per ogni futura versione del sistema operativo. Prima del rollout, testare come pilota la combinazione esatta di build SFOS, pacchetto agente e versione endpoint.

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.

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. L’accesso allo User Portal viene consentito solo dalle reti previste. 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. 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 e si sposta l’agente nella cartella applicazioni prevista. 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 attuale 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

Nel Log viewer, filtrare Authentication per utente, IP sorgente e orario del test. Il campo client deve mostrare Authentication Agent. Controllare inoltre il traffico firewall reale e la relativa Firewall Rule ID.

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 il percorso di routing verso la destinazione documentata dell’agente e TCP 9922. Una cattura controllata con host 1.2.3.4 and port 9922 può mostrare se il traffico Windows o macOS raggiunge Sophos Firewall. Per Linux, controllare invece l’IP del firewall configurato in caa.conf.

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. 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
• 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