Revisar Firewall Task Queue en Sophos Fusion (antes Sophos Central)

Cuando un cambio de Sophos Fusion no llega al firewall, se debe abrir primero:

My Products > Firewall Management > Tasks Queue

Esta página contiene dos vistas independientes: Task Queue para políticas de grupo de firewalls y Firewall Task Queue para operaciones de MDR y API. Una tarea completada correctamente confirma que se ha procesado la operación, pero no que haya tenido el efecto previsto en el firewall. Por eso, la revisión de la cola y la validación local deben realizarse juntas.

Si la tarea procede de una política de grupo compartida, Usar Sophos Fusion Firewall Groups de forma segura explica además Full Sync, Skip full sync, los subgrupos y la preparación de la reversión. Las conexiones entre sedes generadas automáticamente se validan en Configurar y comprobar un grupo de conexiones SD-WAN en Sophos Fusion.

Revisar de forma segura una tarea fallida

1. Abrir la pestaña correspondiente y desplegar la tarea.
2. Documentar el número de tarea, el grupo o firewall, Status, Modified by, Entity, Sub-entity, Time y el mensaje de error visible.
3. Determinar si se trata de una política de grupo o de una operación MDR/API. Las acciones disponibles son diferentes.
4. Para una política de grupo, comprobar la pertenencia al grupo y Sync & Management en My Products > Firewall Management > Firewalls.
5. Para una tarea de MDR/API, asociar Credential ID, Entity y Action al sistema o cliente API que inició la operación.
6. Determinar en el firewall si el cambio está ausente, completo o presente solo en parte.
7. Decidir entre Retry, Skip, un cambio correctivo o un caso de soporte únicamente después de identificar la causa.
8. Validar el efecto técnico con una prueba positiva definida y, cuando sea seguro, una prueba negativa.

Este procedimiento separa dos preguntas: ¿Sophos Fusion ha procesado la operación y funciona realmente el cambio en el firewall?

Distinguir Task Queue de Firewall Task Queue

Task Queue para políticas de grupo

Sophos Fusion crea automáticamente una tarea cuando un administrador modifica una política de grupo de firewalls. La vista muestra Task, Group, Firewalls, Status, Modified by, Entity, Sub-entity y Time. El estado general también incluye el número de firewalls en los que la política se ha aplicado correctamente. Al desplegar la tarea se muestra cada firewall de destino.

Al principio, la marca de tiempo indica cuándo se creó o actualizó la política, no necesariamente cuándo comenzó la distribución. Se actualiza durante la aplicación y finalmente muestra cuándo la recibió el último firewall. Show History muestra tareas completadas u omitidas de firewalls o grupos que se hayan eliminado posteriormente.

Sophos Fusion elimina las tareas que permanecen en Pending durante tres semanas. Si puede ser necesario escalar el caso, se deben guardar con antelación el número de tarea, el error, los firewalls de destino y la hora.

Firewall Task Queue para operaciones de MDR y API

Firewall Task Queue muestra MDR Settings y MDR IOCs iniciados mediante Firewall Configuration API. La vista general los agrupa en Total Firewall Tasks, Pending, In Progress, Failed, Partial Successful y Successful.

Una tarea desplegada muestra el firewall, el estado, Credential ID en Modified by, la entidad, la acción y la hora. Sophos cita Add, Update y Delete como ejemplos de acciones. Credential ID identifica las credenciales de API usadas para la operación; no representa a un administrador como en una política de grupo.

Los estados individuales son Pending, In Progress, Success, Failed y Partial Success. Partial Success significa que solo se ha aplicado una parte de la operación. Sophos ofrece el ejemplo de tres indicadores de MDR Threat Feed, dos correctos y uno fallido. Este estado no debe registrarse como un éxito general: hay que documentar por separado los elementos o firewalls correctos y fallidos y comparar el estado local.

En las operaciones de IOC de MDR, audit_ID vincula la tarea de Sophos Fusion con la acción del analista y el registro local de Active Threat Response. Activar y verificar MDR Threat Feeds en Sophos Firewall explica la validación completa.

Las actualizaciones de firmware se programan y supervisan en My Products > Firewall Management > Firewalls. No forman parte de las dos vistas de cola descritas aquí.

Delimitar Retry, Skip y Force sync

La ayuda actual de Sophos Fusion sobre Tasks Queue documenta Retry y Skip para tareas fallidas de políticas de grupo. No documenta acciones equivalentes para Firewall Task Queue.

• Retry: utilizarlo solo después de corregir la causa visible y confirmar que se sigue deseando el mismo cambio de grupo. Después, comprobar el nuevo estado de cada firewall y volver a validar localmente.
• Skip: utilizarlo solo cuando se sepa qué cambio de grupo se va a omitir. Skip no sustituye la revisión local ni un cambio correctivo posterior.
• Esperar: para Pending o In Progress, mientras el procesamiento avance de forma plausible y no se muestre un error. Conservar las evidencias antes del límite de eliminación de tres semanas.
• Caso de soporte: cuando el fallo siga siendo reproducible, afecte a varios firewalls de producción o el mensaje visible no permita una corrección segura.

⚠️ No se debe omitir una tarea solo para vaciar la cola. El cambio omitido queda sin resolver y debe aceptarse explícitamente, corregirse o implementarse por separado.

La ayuda de la cola no documenta ninguna acción Cancel o Rollback. Skip no revierte un cambio de grupo ya distribuido, ni tampoco lo hace eliminar el firewall de su grupo. Para volver al estado anterior, se debe corregir deliberadamente la política de grupo, seguir la tarea resultante y validar de nuevo localmente el estado previsto definido anteriormente.

Force sync tampoco es un Retry. Si se añadió un firewall con Skip full sync, su configuración local puede ser distinta de la política de grupo. En My Products > Firewall Management > Firewalls, se abre su estado en Sync & Management; Force sync aplica entonces todas las configuraciones del grupo. Antes deben conocerse las diferencias y el estado previsto. En un par HA, el enlace solo está disponible para el firewall activo.

Acotar los síntomas habituales

La política de grupo permanece en Pending

Primero se comprueba si la marca de tiempo de la tarea sigue cambiando y qué firewalls faltan en la tarea desplegada. Después se revisan la pertenencia al grupo y Sync & Management en My Products > Firewall Management > Firewalls. En el firewall afectado, System > Sophos Fusion debe mostrar el estado de administración Managed. Si la operación no avanza, hay que conservar las evidencias antes de su eliminación automática y escalar con el número de tarea, la hora y los firewalls afectados.

En instalaciones antiguas de SFOS 22.0, también se debe revisar la versión del firmware. NC-181175 en las notas de la versión oficiales de SFOS 22.0 describe un Group Policy Push que permanecía en Pending en Sophos Fusion y no se aplicaba. Sophos lo incluye entre los problemas resueltos en SFOS 22.0 MR2 Build 546. Esta entrada no explica todas las tareas Pending: primero hay que revisar el estado y los firewalls de destino.

La política de grupo falla

Desplegar la tarea y registrar el firewall afectado, Entity y Sub-entity. No poner en cola varios cambios al mismo tiempo. Si se puede corregir la causa, usar Retry para esa tarea fallida de política de grupo y después validar localmente. Si se acepta expresamente omitir el cambio, documentar Skip; de lo contrario, escalar con el mensaje de error.

Firewall Task Queue muestra Partial Success o Failed

Registrar Credential ID, Entity, Action, la hora y los resultados de cada firewall o elemento. La ayuda de Sophos Fusion no documenta un flujo de Retry, Skip o Cancel para esta cola. No se deben trasladar los controles de la cola de políticas de grupo: hay que investigar la operación en el proceso MDR/API que la inició y revisar el estado local actual antes de hacer otro cambio.

Sophos Fusion guarda, pero no aparece ninguna tarea

Primero se debe confirmar que se ha modificado y guardado una política de grupo real mediante Manage Policy. Los cambios directos en un firewall individual abierto desde Sophos Fusion no crean la misma tarea de política de grupo. Después se comprueban la pestaña correcta, el grupo correcto y Show History. Si la entrada esperada sigue sin aparecer, se guardan la hora UTC, los nombres del grupo y del firewall, la Entity modificada y el administrador de Sophos Fusion para Sophos Support. Retry y Skip no están disponibles sin una entrada en la cola.

Si el comportamiento es reproducible, se debe repetir el guardado una sola vez mientras se captura un archivo HAR en el navegador y correlacionar la hora UTC con /log/fwcm-updaterd.log. Los archivos HAR pueden contener tokens de sesión y otros datos confidenciales: deben revisarse y sanearse antes de compartirlos. El HAR, el extracto del registro, la hora y los nombres afectados se incluyen en un caso de Sophos Support; clonar o eliminar repetidamente objetos de política no es una solución estándar fiable.

XGS 88/w: Local TLS exclusion list

Una entrada de Sophos sobre NC-177522, retirada desde entonces de la Known Issues List actual, documentaba que la edición de Local TLS exclusion list durante la sincronización de una política de Sophos Fusion podía fallar con Failed to apply a policy en modelos XGS 88/w con SFOS 21.5 MR2 Build 323 o 22.0 GA Build 411. Indicaba que no se podía actualizar un URL Group y permitía usar Skip en la tarea fallida para que continuaran las tareas posteriores.

La información oficial sobre la corrección era contradictoria: Fix versions indicaba SFOS 22.0 MR1 Build 490, mientras que el texto de la solución temporal seguía anunciando una corrección en la siguiente maintenance release. Como la lista actual ya no contiene NC-177522, no se debe inferir otra versión de corrección. Para esta combinación exacta de modelo, build y error, primero se conservan las evidencias, se comprende el efecto de Skip y se revisan la lista local de exclusiones TLS y las políticas relacionadas; el estado actual de la corrección debe confirmarse con Sophos Support.

Validar el cambio localmente

En las reglas de firewall y NAT, Top y Bottom solo controlan el orden dentro de la política de Sophos Fusion. Sophos Fusion coloca estas reglas al principio de la lista local. Por tanto, las reglas locales pueden dificultar la predicción de la evaluación efectiva; Sophos recomienda crear las reglas de forma coherente mediante Sophos Fusion en los firewalls administrados centralmente.

Tras una tarea completada o corregida, no se debe aceptar un resultado genérico «sync successful». Hay que comprobar exactamente la función modificada en el firewall de destino:

• ¿Está visible la regla, política, lista u objeto modificado en el menú de SFOS correspondiente?
• Para los objetos compatibles, ¿muestra Configuration Audit el cambio esperado? La evidencia de auditoría no sustituye una prueba funcional.
• ¿Coincide el tráfico de prueba definido con el Firewall Rule ID esperado y, para NAT, con el NAT Rule ID esperado?
• Para cambios web o TLS, ¿coinciden el cliente de prueba, el dominio de destino y los registros de Web y SSL/TLS Inspection?
• Para VPN u otros cambios, ¿funciona el caso de uso específico con las asignaciones de usuario y objeto previstas?
• Para tareas de MDR/API, ¿están presentes localmente las entidades o los indicadores previstos y coincide el evento de registro con la operación?

Para los cambios de tráfico, Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture describe el flujo de validación local. En cambios extensos, Sophos Firewall Config Studio también puede comparar la configuración prevista y la real. Si no está claro qué registro corresponde, se puede consultar Solución de problemas de Sophos Firewall: servicios y registros.

Para el registro del cambio, se deben conservar como mínimo el número y estado de la tarea, el firewall de destino, la comparación local entre lo previsto y lo real, el resultado de la prueba y una evidencia de registro o auditoría. Solo entonces se considera validado el cambio de Sophos Fusion.