Controllare la Firewall Task Queue in Sophos Central

Se una modifica proveniente da Sophos Central non arriva al firewall, aprire innanzitutto:

My Products > Firewall Management > Tasks Queue

La pagina offre due viste separate: Task Queue per le policy di gruppo dei firewall e Firewall Task Queue per le operazioni MDR e API. Un task riuscito conferma che l’operazione è stata elaborata, ma non che abbia prodotto l’effetto previsto sul firewall. Il controllo della coda deve quindi essere sempre accompagnato dalla verifica locale.

Se il task deriva da una policy di gruppo condivisa, Usare Sophos Central Firewall Groups in modo sicuro spiega anche Full Sync, Skip full sync, sottogruppi e preparazione del rollback. Le connessioni tra sedi generate automaticamente sono verificate in Configurare e verificare un gruppo di connessioni SD-WAN in Sophos Central.

Controllare in sicurezza un task non riuscito

1. Aprire la scheda appropriata ed espandere il task.
2. Annotare numero del task, gruppo o firewall, Status, Modified by, Entity, Sub-entity, Time e il messaggio di errore visibile.
3. Stabilire se si tratta di una policy di gruppo o di un’operazione MDR/API. Le azioni disponibili sono diverse.
4. Per una policy di gruppo, controllare appartenenza al gruppo e Sync & Management in My Products > Firewall Management > Firewalls.
5. Per un task MDR/API, associare Credential ID, Entity e Action al sistema o al client API che ha avviato l’operazione.
6. Sul firewall, determinare se la modifica è assente, completa o presente solo in parte.
7. Decidere tra Retry, Skip, una modifica correttiva o un caso di supporto solo dopo aver individuato la causa.
8. Verificare l’effetto tecnico con un test positivo definito e, se sicuro, con un test negativo.

La procedura separa due domande: Central ha elaborato l’operazione e la modifica funziona davvero sul firewall?

Distinguere Task Queue e Firewall Task Queue

Task Queue per le policy di gruppo

Sophos Central crea automaticamente un task quando un amministratore modifica una policy di gruppo dei firewall. La vista mostra Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity e Time. Lo stato complessivo include il numero di firewall sui quali la policy è stata applicata correttamente. Espandere il task per vedere ogni firewall di destinazione.

Inizialmente, il timestamp mostra quando la policy è stata creata o aggiornata, non necessariamente l’inizio della distribuzione. Viene aggiornato durante l’applicazione e infine indica quando l’ultimo firewall l’ha ricevuta. Show History visualizza i task completati o ignorati relativi a firewall o gruppi successivamente eliminati.

Sophos Central elimina i task che rimangono Pending per tre settimane. Se può essere necessaria un’escalation, salvare per tempo numero del task, errore, firewall di destinazione e ora.

Firewall Task Queue per le operazioni MDR e API

La Firewall Task Queue mostra MDR Settings e MDR IOCs avviati tramite la Firewall Configuration API. La panoramica li raggruppa in Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful e Successful.

Un task espanso mostra firewall, stato, Credential ID sotto Modified by, entità, azione e ora. Sophos cita Add, Update e Delete come esempi di azioni. Il Credential ID identifica le credenziali API usate per l’operazione; non è l’indicazione di un amministratore come in una policy di gruppo.

I singoli stati sono Pending, In Progress, Success, Failed e Partial Success. Partial Success significa che è stata applicata solo una parte dell’operazione. Sophos porta l’esempio di tre indicatori MDR Threat Feed, due riusciti e uno fallito. Non registrare questo stato come successo complessivo: documentare separatamente elementi o firewall riusciti e falliti e confrontare lo stato locale.

Per le operazioni MDR IOC, l’audit_ID collega il task Central all’azione dell’analista e al log Active Threat Response locale. Attivare e verificare gli MDR Threat Feeds su Sophos Firewall descrive la verifica completa.

Gli aggiornamenti del firmware vengono invece pianificati e monitorati in My Products > Firewall Management > Firewalls. Non fanno parte delle due viste della coda descritte qui.

Definire i limiti di Retry, Skip e Force sync

La guida aggiornata di Sophos Central a Tasks Queue documenta Retry e Skip per i task di policy di gruppo non riusciti. Non documenta azioni equivalenti per Firewall Task Queue.

• Retry: usarlo solo dopo aver corretto la causa visibile e confermato che la stessa modifica di gruppo sia ancora desiderata. Controllare quindi il nuovo stato per ogni firewall e ripetere la verifica locale.
• Skip: usarlo solo quando è chiaro quale modifica di gruppo verrà omessa. Skip non sostituisce il controllo locale né una successiva modifica correttiva.
• Attendere: per Pending o In Progress, finché l’elaborazione procede in modo plausibile e non compare un errore. Conservare le prove prima del limite di eliminazione di tre settimane.
• Caso di supporto: quando l’errore rimane riproducibile, interessa più firewall di produzione o il messaggio visibile non consente una correzione sicura.

⚠️ Non ignorare un task soltanto per svuotare la coda. La modifica omessa rimane irrisolta e deve essere esplicitamente accettata, corretta o implementata separatamente.

La guida della coda non documenta azioni Cancel o Rollback. Skip non annulla una modifica di gruppo già distribuita e nemmeno la rimozione del firewall dal gruppo. Per tornare allo stato precedente, correggere intenzionalmente la policy di gruppo, seguire il task risultante e verificare nuovamente in locale lo stato previsto definito in precedenza.

Anche Force sync non è un Retry. Se un firewall è stato aggiunto con Skip full sync, la sua configurazione locale può essere diversa dalla policy di gruppo. In My Products > Firewall Management > Firewalls, aprire il suo stato in Sync & Management; Force sync applica quindi tutte le configurazioni del gruppo. Prima è necessario conoscere differenze e stato previsto. Per una coppia HA, il link è disponibile solo sul firewall attivo.

Circoscrivere i sintomi comuni

La policy di gruppo rimane su Pending

Controllare innanzitutto se il timestamp del task continua a cambiare e quali firewall mancano nel task espanso. Verificare quindi appartenenza al gruppo e Sync & Management in My Products > Firewall Management > Firewalls. Sul firewall interessato, System > Sophos Central deve mostrare lo stato di gestione Managed. Se l’operazione non avanza, conservare le prove prima dell’eliminazione automatica e aprire un’escalation con numero del task, ora e firewall interessati.

Per le installazioni SFOS 22.0 meno recenti, controllare anche la versione del firmware. NC-181175 nelle note di rilascio ufficiali di SFOS 22.0 descrive un Group Policy Push che rimaneva Pending in Central e non veniva applicato. Sophos lo elenca tra i problemi risolti in SFOS 22.0 MR2 Build 546. La voce non spiega ogni task Pending: controllare prima stato e firewall di destinazione.

La policy di gruppo non riesce

Espandere il task e annotare firewall interessato, Entity e Sub-entity. Non accodare più modifiche contemporaneamente. Se è possibile correggere la causa, usare Retry per quel task di policy di gruppo non riuscito e poi verificare localmente. Se l’omissione della modifica è stata accettata esplicitamente, documentare Skip; altrimenti aprire un’escalation con il messaggio di errore.

Firewall Task Queue mostra Partial Success o Failed

Annotare Credential ID, Entity, Action, ora e risultati per ogni firewall o elemento. La guida Central non documenta procedure Retry, Skip o Cancel per questa coda. Non trasferire i comandi dalla coda delle policy di gruppo: analizzare l’operazione nel processo MDR/API che l’ha avviata e controllare lo stato locale attuale prima di un’altra modifica.

Central salva, ma non compare alcun task

Verificare innanzitutto di aver modificato e salvato un’effettiva policy di gruppo tramite Manage Policy. Le modifiche dirette a un singolo firewall aperto da Central non generano lo stesso task di policy di gruppo. Controllare quindi la scheda corretta, il gruppo corretto e Show History. Se la voce prevista rimane assente, conservare ora UTC, nomi del gruppo e del firewall, Entity modificata e amministratore Central per Sophos Support. Senza una voce nella coda, Retry e Skip non sono disponibili.

Se il comportamento è riproducibile, ripetere il salvataggio una sola volta registrando un file HAR nel browser e correlare l’ora UTC con /log/fwcm-updaterd.log. I file HAR possono contenere token di sessione e altri dati riservati: esaminarli e rimuovere tali dati prima di condividerli. Includere HAR, estratto del log, ora e nomi interessati in un caso Sophos Support; clonare o eliminare ripetutamente gli oggetti della policy non è una soluzione standard affidabile.

XGS 88/w: Local TLS exclusion list

Una voce Sophos relativa a NC-177522, nel frattempo rimossa dalla Known Issues List attuale, documentava che la modifica di Local TLS exclusion list durante la sincronizzazione di una policy Central poteva non riuscire con Failed to apply a policy sui modelli XGS 88/w con SFOS 21.5 MR2 Build 323 o 22.0 GA Build 411. Indicava come causa un URL Group non aggiornabile e consentiva di usare Skip sul task non riuscito affinché quelli successivi potessero proseguire.

Le informazioni ufficiali sul fix erano allora contraddittorie: Fix versions indicava SFOS 22.0 MR1 Build 490, mentre il testo del workaround annunciava ancora un fix nella maintenance release successiva. Poiché l’elenco attuale non contiene più NC-177522, non si deve dedurre un’altra versione correttiva. Per questa combinazione esatta di modello, build ed errore, conservare prima le prove, comprendere l’effetto di Skip e controllare la lista locale delle esclusioni TLS e le policy correlate; confermare lo stato attuale del fix con Sophos Support.

Verificare localmente la modifica

Per le regole firewall e NAT, Top e Bottom controllano soltanto l’ordine all’interno della policy Central. Central inserisce queste regole all’inizio dell’elenco locale. Le regole locali possono quindi rendere più difficile prevedere la valutazione effettiva; Sophos consiglia di creare sistematicamente le regole tramite Central sui firewall gestiti centralmente.

Dopo un task riuscito o corretto, non accettare un generico risultato «sync successful». Controllare esattamente la funzione modificata sul firewall di destinazione:

• La regola, la policy, l’elenco o l’oggetto modificato è visibile nel relativo menu SFOS?
• Per gli oggetti supportati, Configuration Audit mostra la modifica prevista? La prova di audit non sostituisce un test funzionale.
• Il traffico di test definito corrisponde al Firewall Rule ID previsto e, per NAT, al NAT Rule ID previsto?
• Per le modifiche Web o TLS, client di test, dominio di destinazione e log Web e SSL/TLS Inspection coincidono?
• Per VPN o altre modifiche, il caso d’uso specifico funziona con le assegnazioni utente e oggetto previste?
• Per i task MDR/API, le entità o gli indicatori attesi sono presenti in locale e l’evento di log corrisponde all’operazione?

Per le modifiche al traffico, Verificare le regole firewall con Log Viewer, Policy Test e Packet Capture descrive il flusso di verifica locale. Per modifiche estese, Sophos Firewall Config Studio può inoltre confrontare configurazione prevista e reale. Se non è chiaro quale log usare, consultare Risoluzione dei problemi di Sophos Firewall: servizi e log.

Per il registro della modifica, conservare almeno numero e stato del task, firewall di destinazione, confronto locale previsto/reale, risultato del test e prova da log o audit. Solo allora la modifica Central è verificata.