Sophos Central Controlla la coda delle attività di gestione del firewall

Se una modifica è stata salvata in Sophos Central ma non arriva su Sophos Firewall, il firewall locale non è sempre la prima fonte di errore. Per i firewall gestiti centralmente dovresti anche controllare la Coda delle attività in Sophos Central. Qui puoi vedere se Central ha ancora elaborato una policy di gruppo, un’attività firewall basata su API o un’altra modifica centrale, se l’ha applicata parzialmente, l’ha saltata o l’ha terminata con un errore.

Ciò è particolarmente importante quando più firewall vengono gestiti in un gruppo. Una singola attività non riuscita può ritardare le modifiche successive o confondere la risoluzione dei problemi perché la configurazione su Sophos Central appare diversa da quella sul firewall interessato.

La Task Queue quindi non sostituisce log, Packet Capture o verifica locale. Risponde prima alla domanda di trasporto: Sophos Central ha accettato, elaborato e applicato il task al firewall o al gruppo interessato? Solo dopo ha senso la vera analisi del firewall.

Quando la coda delle attività è rilevante

La coda delle attività è rilevante non appena le modifiche non vengono eseguite direttamente localmente sul firewall, ma tramite Sophos Central. Ciò riguarda in particolare gli ambienti in cui i firewall sono connessi a Sophos Central e viene utilizzata attivamente la gestione centralizzata del firewall.

Situazioni tipiche:

• una politica di gruppo è stata modificata in Sophos Central
• è arrivata una modifica su alcuni firewall, ma non su altri
• è stato programmato o avviato un aggiornamento del firmware tramite Sophos Central
• MDR o le attività firewall basate su API sembrano non completamente implementate
• un’attività è su Pending o In Progress da molto tempo
• un’attività è Failed, Skipped, Invalid license o è riuscita solo parzialmente
• dopo un errore, le modifiche successive non vengono elaborate come previsto

Il firewall Log Viewer rimane importante per la risoluzione dei problemi locali in tempo reale. Ma la coda delle attività risponde a un’altra domanda: Sophos Central è riuscito a far passare la modifica al firewall?

Dove trovare la coda delle attività

Il percorso Sophos Central è:

My Products > Firewall Management > Tasks Queue

Sophos distingue tra due schede. Questa separazione è importante per non mescolare policy di gruppo e task API/MDR.

• Task Queue: stato delle policy di gruppo firewall applicate ai firewall tramite Sophos Central.
• Firewall Task Queue: task firewall da MDR Settings, MDR IOCs e Firewall Configuration API. La vista raggruppa i task, tra gli altri stati, per Pending, In Progress, Failed, Partial Successful e Successful.

Per i classici problemi di Central Firewall Management, la Task Queue è solitamente il primo punto da controllare. La Firewall Task Queue diventa più importante quando le modifiche vengono attivate tramite Firewall Configuration API o funzioni firewall correlate a MDR.

Nella visualizzazione della coda delle attività, anche la cronologia è importante. Utilizzare Show History per visualizzare le attività completate o saltate per firewall o gruppi che sono stati eliminati. Per le revisioni delle modifiche o i casi di supporto, è comunque necessario documentare tempestivamente i dettagli rilevanti delle attività, poiché le attività Pending non rimangono permanentemente nell’interfaccia dopo un lungo periodo di tempo.

Quali informazioni sono importanti

Una singola attività è utile solo se organizzata correttamente. Prima di apportare una modifica o uno Retry dovresti annotare almeno questi campi:

• Numero dell’attività
• gruppo o firewall interessato
• Stato
• tempistica
• ID amministratore o credenziale
• Entità e sottoentità
• viene visualizzato il messaggio di errore
• Numero di firewall riusciti e falliti

La tempistica non è sempre sinonimo dell’inizio dell’elaborazione su ciascun firewall. Per i criteri di gruppo, Sophos Central mostra innanzitutto l’ora di creazione o modifica e successivamente la aggiorna quando il criterio viene applicato ai firewall. Ecco perché non dovresti limitarti a guardare la prima volta per implementazioni più lunghe.

L’origine dell’attività è importante per la risoluzione dei problemi. È più probabile che un nome utente indichi una modifica nel portale di Sophos Central. Un ID credenziale indica un ordine correlato all’API o allo MDR. In questo caso dovresti anche verificare quale sistema o processo ha attivato la modifica.

Per le policy di gruppo conta anche la vista del gruppo: il firewall si trova davvero nel gruppo o sottogruppo previsto, una policy è stata ereditata oppure il firewall è stato aggiunto al gruppo con Skip full sync? Un full sync saltato può essere voluto, ma può facilmente creare una differenza tra Central e il firewall locale.

Se un firewall è stato aggiunto intenzionalmente con Skip full sync, non bisogna presumere automaticamente una base di gruppo pulita. In Sophos Central è possibile avviare un Force sync dallo stato di sincronizzazione del firewall. Nelle coppie HA, questo full sync deve essere avviato sul firewall attivo, perché Sophos non mostra il link per i firewall passivi.

Interpreta lo stato correttamente

• Pending: L’attività è ancora in attesa di essere elaborata. Se la durata è più lunga verifica connettività, licenza e connessione centrale.
• In Progress: La centrale sta ancora elaborando l’attività. Non avviare più correzioni in parallelo se l’attività è attualmente in esecuzione.
• Success: La centrale segnala l’attività come riuscita. Quindi verificare ancora sul firewall se l’effetto previsto è visibile.
• Partial Success: Alcuni sono stati applicati, altri no. Ciò è particolarmente importante per gruppi o più oggetti.
• Failed: La modifica non è stata completata con successo. Documentare il messaggio di errore e il firewall interessato.
• Skipped: Il compito è stato deliberatamente saltato. È quindi necessaria un’ispezione di follow-up professionale.
• Invalid license: La licenza o l’autorizzazione non corrisponde all’azione pianificata. Non cercare di risolvere il problema ripetendo Retry.

Sophos Central può rimuovere automaticamente le attività con stato Pending dopo tre settimane. È pertanto opportuno eseguire tempestivamente il backup degli errori rilevanti per la documentazione operativa, i casi di supporto o le revisioni delle modifiche.

Success significa solo che Sophos Central ha elaborato l’ordine con successo. Non dimostra automaticamente che il traffico desiderato funzioni, che una regola corrisponda effettivamente o che un utente possa funzionare di nuovo. Per modifiche produttive sono sempre necessari tre livelli: verifica dell’attività centrale, verifica della configurazione del firewall locale e verifica dell’effetto tecnico.

La policy Central non è automaticamente la verità locale

Per regole firewall e NAT gestite tramite Sophos Central esiste una differenza operativa importante: la posizione Top o Bottom descrive prima l’ordine all’interno della policy Central. Sul firewall, le regole inviate da Central vengono inserite in alto nella lista regole locale. Se esistono anche regole locali, l’ordine effettivo può risultare diverso da quanto ci si aspetta nell’editor Central.

Avanet consiglia quindi una decisione operativa chiara per firewall gestiti centralmente: gestire le regole in modo coerente tramite Sophos Central oppure documentare consapevolmente le eccezioni locali e verificarle dopo ogni modifica Central. Il funzionamento misto è tecnicamente possibile, ma più soggetto a errori, perché Task Queue, Rule ID locale, NAT Rule ID locale e Audit Trail devono essere letti insieme.

Per il troubleshooting significa che un task Central riuscito spiega solo che la policy è stata distribuita. Se la regola agisce nel punto giusto va verificato localmente nel set di regole e poi nel Log Viewer.

Processo di test pulito

Quando una modifica Central è bloccata, un processo ordinato aiuta più di clic ripetuti su Retry.

1. Aprire in Sophos Central My Products > Firewall Management > Tasks Queue.
2. Limitare periodo e firewall o gruppo di firewall interessato.
3. Espandere il task e controllare i firewall interessati.
4. Documentare stato, messaggio di errore, entity, sub-entity e ora.
5. Per firewall o gruppi eliminati, attivare Show History se necessario.
6. Per policy di gruppo, verificare se il firewall si trova nel gruppo o sottogruppo corretto.
7. In caso di sospetta deviazione di gruppo, controllare lo stato di sincronizzazione e decidere consapevolmente se Force sync ha senso.
8. Sul firewall, verificare se la modifica è visibile o solo salvata in Central.
9. Per regole firewall o NAT, controllare posizione locale, Rule ID e NAT Rule ID.
10. Per modifiche di configurazione, verificare anche Audit Trail Logs.
11. Per problemi di traffico, analizzare Log Viewer, Policy Test e log di servizio rilevanti.
12. Solo dopo decidere se Retry, Skip o un caso di supporto ha senso.

Se non è chiaro quale log locale sia rilevante, Sophos Firewall troubleshooting: servizi e log aiuta a orientarsi. Per l’analisi di regole e traffico è utile anche testare regole firewall con Log Viewer, Policy Test e Packet Capture.

Partial Success elaborato in modo pulito

Partial Success è più pericoloso di un errore evidente perché parte dell’ambiente è già stata modificata. Con le politiche di gruppo dovreste quindi prima aprire e disconnettere i firewall interessati:

• Firewall con applicazione riuscita
• Firewall con errori
• Firewall offline, ingestibili o bloccati dalla licenza
• Firewall con versione o piattaforma SFOS diversa

Successivamente, non dovresti riapplicare immediatamente la stessa modifica all’intero gruppo. È meglio apportare una correzione mirata al firewall o al gruppo interessato, quindi verificare Retry e infine confrontare la configurazione del firewall locale. Per modifiche più ampie, Sophos Firewall Utilizza Config Studio aiuta a confrontare le configurazioni previste ed effettive in modo comprensibile.

Skip o Retry?

Sophos Central offre promozioni Skip e Retry a seconda dello stato. Entrambi sono utili, ma non dovrebbero essere visti come pura pulizia.

• Retry: la causa è stata risolta, ad esempio connessione, licenza, conflitto di oggetti o guasto centrale temporaneo È chiaro il motivo per cui l’attività non è riuscita?
• Skip: un’attività non riuscita o non più rilevante blocca le attività successive e l’impatto tecnico è compreso Questo non sta deliberatamente applicando un cambiamento politico pianificato?
• Aspetta: l’attività è attualmente in esecuzione oppure Central sta elaborando molti firewall C’è qualche prova di un blocco reale o semplicemente di un normale ritardo?
• Caso di supporto: l’errore si verifica ripetutamente, interessa diversi firewall produttivi oppure il messaggio non è chiaro I dettagli dell’attività, l’ora, il nome del firewall e i registri sono protetti?

⚠️ Non saltare un’attività fallita solo per far sembrare pulita la coda. Skip è una decisione operativa: la modifica che non viene applicata deve quindi essere controllata consapevolmente o implementata separatamente.

Prima di un Retry, dovresti almeno verificare se il firewall in Sophos Central è online, se Gestisci da Sophos Central è ancora attivo, se la versione della licenza e del firmware corrisponde all’azione pianificata e se il firewall locale non rifiuta il lavoro a causa di differenze di oggetto, policy o piattaforma. Retry ripetuto senza controllo della causa principale produce solo nuove voci, ma raramente chiarezza.

Tipici schemi di errore

La modifica è visibile in Central ma non sul firewall

In questo caso, controlla innanzitutto se l’attività appropriata è stata completata con successo. Se l’attività è ancora Pending, In Progress, Failed o Partial Success, il problema non è necessariamente nella regola del firewall locale. Solo quando Central segnala che l’attività ha avuto successo dovresti approfondire la politica locale, l’analisi degli oggetti o dei registri.

Se l’attività ha esito positivo ma il firewall locale appare diverso, è necessario verificare se il firewall è effettivamente membro del gruppo previsto, se una modifica locale rende difficile l’interpretazione e se si sta lavorando nel firewall giusto o nel client giusto. Questo banale controllo è sorprendentemente prezioso, soprattutto quando sono presenti più account Sophos Central o trasferimenti di account.

Dopo Success la regola si comporta diversamente dal previsto

Per regole firewall e NAT, dopo un task riuscito non basta verificare che la regola esista. È decisivo sapere se nell’ordine locale si trova prima o dopo regole esistenti rilevanti. Central può avere inviato correttamente la policy mentre una regola locale speciale, una regola Central precedente o una regola NAT modifica comunque il matching previsto.

La verifica pratica è breve: generare traffico di test, filtrare nel Log Viewer per source, destination e service e confrontare Firewall Rule ID e NAT Rule ID effettivi con la regola attesa. Se questi ID non coincidono, il task Central non è il vero problema; lo è l’ordine locale delle regole o del NAT.

Sono interessati solo i singoli firewall di un gruppo

Con Criteri di gruppo, una modifica può avere esito positivo su più firewall e fallire su un firewall. Allora non dovreste cambiare l’intero gruppo in modo generale, ma piuttosto aprire il firewall interessato e verificare le differenze: licenza, versione firmware, connessione centrale, conflitti di oggetti locali, piattaforma e problemi noti.

L’attività del firmware tramite Central non si avvia correttamente

Se un Aggiornamento firmware Sophos Firewall è stato pianificato tramite Sophos Central, la coda delle attività dovrebbe far parte del follow-up. Se il firewall rimane sulla versione precedente, controlla innanzitutto se Central ha attivato e completato l’attività. Per le versioni principali, anche il SFOS 22 Upgrade Check fa parte della preparazione.

La sincronizzazione dei criteri Web o TLS non riesce

Per la protezione Web, i gruppi URL o le esclusioni TLS, una sincronizzazione centrale può creare particolarmente confusione perché Central ha accettato una modifica ma il firewall non la elabora completamente. Quindi dovresti confrontare l’entità interessata dalla coda delle attività con la configurazione locale. Per la classificazione tecnica sono adatti Sophos Firewall Inserisci correttamente TLS Inspection e Sophos Firewall Crea policy di protezione web.

XGS 88/w ed elenco di esclusione TLS locale

Un problema specifico con i modelli XGS 88/w è documentato nell’elenco dei problemi noti: durante la sincronizzazione di una policy Sophos Central, l’elaborazione dell’elenco di esclusione TLS locale potrebbe non riuscire. Il messaggio di errore visualizzato riguarda un gruppo URL che non è stato possibile aggiornare. In questo caso, puoi saltare la transazione non riuscita dalla coda delle attività in modo che le attività successive continuino a essere eseguite.

In pratica, tuttavia, non dovresti semplicemente andare avanti dopo. È importante un controllo successivo:

• L’eccezione TLS desiderata è presente localmente sul firewall?
• Le policy Web e TLS sul firewall sono ancora tecnicamente corrette?
• Il problema riguarda solo un XGS 88/w o più firewall?
• Il cambiamento deve essere temporaneamente implementato a livello locale o posticipato?
• Esiste una versione di manutenzione o un avviso Sophos per la versione interessata?

Controllo successivo sul firewall

Un compito centrale riuscito è un buon segnale, ma non un test operativo completo. A seconda della modifica, dovresti controllare localmente:

• La regola, la policy, l’elenco o la versione firmware modificata sono visibili?
• Log Viewer mostra gli eventi previsti?
• La modifica è stata registrata nella traccia di controllo?
• Il collegamento centrale e il reporting sono ancora attivi?
• Gli utenti interessati, gli VPN, l’accesso al Web o le applicazioni funzionano?

Per le modifiche rilevanti per la sicurezza, dovresti definire anche un breve punto di rollback. Ciò è particolarmente vero per la protezione Web, TLS Inspection, regole firewall, VPN, cluster HA e aggiornamenti firmware.

Lista di controllo operativa

• Prima di apportare modifiche tramite Sophos Central, chiarire quali firewall o gruppi sono interessati.
• Controlla la coda delle attività dopo le modifiche centrali.
• Documenta le attività non riuscite con messaggio di errore, ora e nome del firewall.
• Non trattare Partial Success come completo.
• Per firewall o gruppi eliminati, seleziona Show History.
• Utilizzare Retry solo dopo aver verificato la causa.
• Utilizzare Skip solo se si comprende l’impatto tecnico.
• Success validato con un test locale e un’evidenza di log o audit.
• Per le attività API o MDR, assegnare l’ID credenziale e il sistema di attivazione.
• Pianificare finestre di manutenzione, backup e accesso locale per le attività del firmware.
• In caso di errori ripetuti, eseguire il backup delle informazioni di Audit Trail, Log Viewer e Sophos Support.

Validare Success con un caso di test

Un Success nella Task Queue deve sempre essere collegato a un caso di test adeguato. Altrimenti indica solo che Central ha elaborato l’attività, non che la funzione interessata lavori davvero.

Validazione pratica:

• Regola firewall modificata: generare traffico di test con source, destination, service e Rule ID attesa.
• NAT o DNAT modificato: testare l’accesso esterno o interno e verificare Firewall Rule ID e NAT Rule ID in Log Viewer.
• Policy Web o TLS modificata: confrontare client di test, dominio di destinazione, log Web e log SSL/TLS-inspection.
• Modifica VPN o Remote Access: controllare accesso, pool IP, raggiungibilità interna e associazione utente.
• Attività firmware o backup: controllare versione, stato di avvio, ruolo HA, connessione Central e ultimo backup.
• Attività MDR, ATR o API: documentare Credential ID, sistema di origine, visibilità locale ed evento di log atteso.

Per le revisioni dei change basta una prova breve: stato dell’attività, firewall interessato, test locale, evidenza log o audit e punto aperto. Così un’attività Central riuscita non viene scambiata in seguito per una validazione tecnica completa.

Domande frequenti