Verificar a Firewall Task Queue no Sophos Fusion

Quando uma alteração do Sophos Fusion (anteriormente Sophos Central) não chega à firewall, deve abrir-se primeiro:

My Products > Firewall Management > Tasks Queue

Esta página tem duas vistas separadas: Task Queue para políticas de grupo de firewalls e Firewall Task Queue para operações MDR e API. Uma tarefa bem-sucedida confirma que a operação foi processada, mas não que teve o efeito pretendido na firewall. Por isso, a verificação da fila e a validação local devem ser feitas em conjunto.

Se a tarefa resultar de uma política de grupo partilhada, Utilizar Sophos Fusion Firewall Groups em segurança explica também Full Sync, Skip full sync, subgrupos e a preparação do retorno. As ligações entre locais geradas automaticamente são validadas em Configurar e verificar um grupo de ligações SD-WAN no Sophos Fusion.

Verificar uma tarefa falhada em segurança

1. Abrir o separador adequado e expandir a tarefa.
2. Registar número da tarefa, grupo ou firewall, Status, Modified by, Entity, Sub-entity, Time e a mensagem de erro visível.
3. Determinar se se trata de uma política de grupo ou de uma operação MDR/API. As ações disponíveis são diferentes.
4. Para uma política de grupo, verificar a pertença ao grupo e Sync & Management em My Products > Firewall Management > Firewalls.
5. Para uma tarefa MDR/API, associar Credential ID, Entity e Action ao sistema ou cliente API que iniciou a operação.
6. Determinar na firewall se a alteração está ausente, completa ou presente apenas parcialmente.
7. Só depois de identificar a causa se deve decidir entre Retry, Skip, uma alteração corretiva ou um caso de suporte.
8. Validar o efeito técnico com um teste positivo definido e, quando for seguro, um teste negativo.

Este procedimento separa duas questões: o Sophos Fusion processou a operação e a alteração funciona realmente na firewall?

Distinguir Task Queue de Firewall Task Queue

Task Queue para políticas de grupo

O Sophos Fusion cria automaticamente uma tarefa quando um administrador altera uma política de grupo de firewalls. A vista mostra Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity e Time. O estado geral inclui também o número de firewalls nas quais a política foi aplicada com êxito. Ao expandir a tarefa, veem-se todas as firewalls de destino.

Inicialmente, o carimbo de data e hora indica quando a política foi criada ou atualizada, não necessariamente o início da distribuição. É atualizado durante a aplicação e, por fim, mostra quando a última firewall a recebeu. Show History apresenta tarefas concluídas ou ignoradas de firewalls ou grupos que tenham sido entretanto eliminados.

O Sophos Fusion elimina tarefas que permaneçam em Pending durante três semanas. Se for possível uma escalada, devem guardar-se antecipadamente o número da tarefa, o erro, as firewalls de destino e a hora.

Firewall Task Queue para operações MDR e API

A Firewall Task Queue mostra MDR Settings e MDR IOCs iniciados através da Firewall Configuration API. A vista geral agrupa-os em Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful e Successful.

Uma tarefa expandida mostra a firewall, o estado, a Credential ID em Modified by, a entidade, a ação e a hora. A Sophos apresenta Add, Update e Delete como exemplos de ações. A Credential ID identifica as credenciais de API utilizadas na operação; não representa um administrador como numa política de grupo.

Os estados individuais são Pending, In Progress, Success, Failed e Partial Success. Partial Success significa que apenas uma parte da operação foi aplicada. A Sophos dá o exemplo de três indicadores MDR Threat Feed, dos quais dois tiveram êxito e um falhou. Este estado não deve ser registado como um sucesso geral: devem documentar-se separadamente os elementos ou firewalls bem-sucedidos e falhados e comparar-se o estado local.

Nas operações de IOC MDR, a audit_ID liga a tarefa Sophos Fusion à ação do analista e ao log Active Threat Response local. Ativar e verificar MDR Threat Feeds na Sophos Firewall descreve a validação completa.

As atualizações de firmware são, pelo contrário, planeadas e monitorizadas em My Products > Firewall Management > Firewalls. Não fazem parte das duas vistas de fila descritas aqui.

Definir limites para Retry, Skip e Force sync

A ajuda atual do Sophos Fusion sobre Tasks Queue documenta Retry e Skip para tarefas falhadas de políticas de grupo. Não documenta ações equivalentes para Firewall Task Queue.

• Retry: utilizar apenas depois de corrigir a causa visível e confirmar que a mesma alteração de grupo continua a ser necessária. Depois, verificar o novo estado de cada firewall e voltar a validar localmente.
• Skip: utilizar apenas quando for conhecida a alteração de grupo que será omitida. Skip não substitui a verificação local nem uma alteração corretiva posterior.
• Aguardar: para Pending ou In Progress, enquanto o processamento estiver plausivelmente a avançar e não for apresentado um erro. Guardar as provas antes do limite de eliminação de três semanas.
• Caso de suporte: quando a falha continuar a ser reproduzível, afetar várias firewalls de produção ou a mensagem visível não permitir uma correção segura.

⚠️ Não se deve ignorar uma tarefa apenas para esvaziar a fila. A alteração omitida continua por resolver e tem de ser explicitamente aceite, corrigida ou implementada separadamente.

A ajuda da fila não documenta uma ação Cancel ou Rollback. Skip não reverte uma alteração de grupo já distribuída; remover a firewall do grupo também não. Para regressar ao estado anterior, deve corrigir-se deliberadamente a política de grupo, acompanhar a tarefa resultante e validar novamente, de forma local, o estado pretendido definido anteriormente.

Force sync também não é um Retry. Se uma firewall tiver sido adicionada com Skip full sync, a sua configuração local pode diferir da política de grupo. Em My Products > Firewall Management > Firewalls, deve abrir-se o seu estado em Sync & Management; Force sync aplica então todas as configurações do grupo. Primeiro, é necessário conhecer as diferenças e o estado pretendido. Num par HA, a ligação só está disponível para a firewall ativa.

Delimitar sintomas comuns

A política de grupo permanece em Pending

Primeiro, deve verificar-se se o carimbo de data e hora da tarefa continua a mudar e quais as firewalls em falta na tarefa expandida. Depois, verificam-se a pertença ao grupo e Sync & Management em My Products > Firewall Management > Firewalls. Na firewall afetada, System > Sophos Fusion deve mostrar o estado de gestão Managed. Se a operação não avançar, devem guardar-se as provas antes da eliminação automática e escalar com o número da tarefa, a hora e as firewalls afetadas.

Em instalações SFOS 22.0 mais antigas, deve verificar-se também a versão do firmware. NC-181175 nas notas de versão oficiais do SFOS 22.0 descreve um Group Policy Push que permanecia em Pending no Sophos Fusion e não era aplicado. A Sophos indica-o entre os problemas resolvidos no SFOS 22.0 MR2 Build 546. Esta entrada não explica todas as tarefas Pending: primeiro devem verificar-se o estado e as firewalls de destino.

A política de grupo falha

Expandir a tarefa e registar a firewall afetada, Entity e Sub-entity. Não colocar várias alterações em fila simultaneamente. Se for possível corrigir a causa, utilizar Retry para essa tarefa falhada de política de grupo e validar depois localmente. Se a omissão da alteração tiver sido explicitamente aceite, documentar Skip; caso contrário, escalar com a mensagem de erro.

Firewall Task Queue mostra Partial Success ou Failed

Registar Credential ID, Entity, Action, hora e resultados por firewall ou elemento. A ajuda do Sophos Fusion não documenta um processo de Retry, Skip ou Cancel para esta fila. Não se devem transpor os controlos da fila de políticas de grupo: deve investigar-se a operação no processo MDR/API que a iniciou e verificar o estado local atual antes de fazer outra alteração.

O Sophos Fusion guarda, mas não aparece uma tarefa

Primeiro, deve confirmar-se que foi alterada e guardada uma verdadeira política de grupo através de Manage Policy. As alterações diretas a uma firewall individual aberta a partir do Sophos Fusion não criam a mesma tarefa de política de grupo. Depois, verificam-se o separador correto, o grupo correto e Show History. Se a entrada esperada continuar ausente, devem guardar-se a hora UTC, os nomes do grupo e da firewall, a Entity alterada e o administrador do Sophos Fusion para o Sophos Support. Retry e Skip não estão disponíveis sem uma entrada na fila.

Se o comportamento for reproduzível, deve repetir-se a gravação exatamente uma vez enquanto se captura um ficheiro HAR no navegador e correlacionar a hora UTC com /log/fwcm-updaterd.log. Os ficheiros HAR podem conter tokens de sessão e outros dados confidenciais: devem ser revistos e saneados antes da partilha. O HAR, o excerto do log, a hora e os nomes afetados devem ser incluídos num caso do Sophos Support; clonar ou eliminar repetidamente objetos da política não é uma solução padrão fiável.

XGS 88/w: Local TLS exclusion list

Uma entrada da Sophos relativa ao NC-177522, entretanto removida da Known Issues List atual, documentava que a edição de Local TLS exclusion list durante a sincronização de uma política do Sophos Fusion podia falhar com Failed to apply a policy em modelos XGS 88/w com SFOS 21.5 MR2 Build 323 ou 22.0 GA Build 411. Indicava que um URL Group não podia ser atualizado e permitia utilizar Skip na tarefa falhada para que as tarefas seguintes prosseguissem.

As informações oficiais sobre a correção eram então contraditórias: Fix versions indicava SFOS 22.0 MR1 Build 490, enquanto o texto da solução temporária continuava a anunciar uma correção na maintenance release seguinte. Como a lista atual já não contém NC-177522, não se deve inferir outra versão de correção. Para esta combinação exata de modelo, build e erro, devem guardar-se primeiro as provas, compreender o efeito de Skip e verificar a lista local de exclusões TLS e as políticas relacionadas; o estado atual da correção deve ser confirmado com o Sophos Support.

Validar localmente a alteração

Nas regras de firewall e NAT, Top e Bottom controlam apenas a ordem dentro da política do Sophos Fusion. O Sophos Fusion coloca estas regras no topo da lista local. Por isso, as regras locais podem tornar a avaliação efetiva mais difícil de prever; a Sophos recomenda que as regras de firewalls geridas centralmente sejam criadas de forma consistente através do Sophos Fusion.

Depois de uma tarefa bem-sucedida ou corrigida, não deve aceitar-se um resultado genérico «sync successful». É necessário verificar exatamente a função alterada na firewall de destino:

• A regra, política, lista ou objeto alterado está visível no menu SFOS correspondente?
• Para objetos suportados, o Configuration Audit mostra a alteração esperada? A prova de auditoria não substitui um teste funcional.
• O tráfego de teste definido corresponde ao Firewall Rule ID esperado e, para NAT, ao NAT Rule ID esperado?
• Para alterações Web ou TLS, o cliente de teste, o domínio de destino e os logs Web e SSL/TLS Inspection são coerentes?
• Para VPN ou outras alterações, o caso de utilização específico funciona com as atribuições de utilizador e objeto esperadas?
• Para tarefas MDR/API, as entidades ou os indicadores esperados estão presentes localmente e o evento de log corresponde à operação?

Para alterações de tráfego, Testar regras de firewall com Log Viewer, Policy Test e Packet Capture descreve o processo de validação local. Para alterações extensas, o Sophos Firewall Config Studio também pode comparar as configurações esperada e real. Se não for claro qual o log relevante, consultar Resolução de problemas da Sophos Firewall: serviços e logs.

Para o registo da alteração, devem guardar-se pelo menos o número e o estado da tarefa, a firewall de destino, a comparação local entre o estado esperado e real, o resultado do teste e a prova de log ou auditoria. Só então a alteração do Sophos Fusion está validada.