Sophos Firewall Log Viewer no muestra logs nuevos

Si Log Viewer no muestra eventos nuevos, no se debe reiniciar inmediatamente un servicio. Primero hay que determinar si solo falta una entrada esperada o si toda la vista local de logs se ha detenido. Para el uso normal, los filtros y la interpretación de campos, primero se aplica Utilizar correctamente el Log Viewer de Sophos Firewall. El procedimiento rápido y seguro para una vista detenida es:

1. En Log Viewer, revisar Pause, el módulo, el intervalo de tiempo y los filtros activos; después ejecutar Reset y Refresh.
2. En la regla de firewall afectada, comprobar Log firewall traffic y, en System services > Log settings, verificar el tipo de log Firewall para Local reporting.
3. Generar una conexión breve desde un cliente de prueba conocido y anotar la hora.
4. Usar Packet capture para comprobar si el tráfico llega al firewall y qué Rule ID se procesa.
5. Solo si también faltan otros eventos esperados, guardar la versión de SFOS, la build completa y la hora del último log visible.
6. Usar el workaround de Garner únicamente en SFOS 21.5 MR1 Build 261 y solo con el patrón de error descrito más abajo.

Así el diagnóstico sigue siendo trazable: un filtro incorrecto o una regla que no genera logs no se confunde con un error de la base de datos de logging.

Por qué puede faltar una sola entrada de log

Log Viewer se actualiza normalmente de forma automática. Sin embargo, solo muestra los eventos que el módulo seleccionado guarda localmente y que la vista actual no oculta.

Las causas habituales que no implican un fallo técnico de Log Viewer son:

• Pause está activo: Los eventos nuevos solo aparecen al reanudar la vista o actualizarla manualmente.
• El módulo, el intervalo de tiempo o los filtros no coinciden: Reset elimina todos los filtros; después se vuelve a seleccionar el módulo adecuado para el caso.
• Rule Logging está desactivado: Las sesiones del firewall solo aparecen si Log firewall traffic está activo en la regla que realmente coincide.
• Local reporting está desactivado: En System services > Log settings, el tipo de log necesario debe estar seleccionado en la columna Local reporting.
• La conexión sigue abierta: Las sesiones del firewall se registran normalmente con el evento Destroy, cuando termina la conexión. Por eso, una entrada puede aparecer después del primer establecimiento de conexión.
• El tráfico no llega al firewall: La ausencia de una entrada no demuestra que el firewall haya descartado el paquete. El cliente, un router anterior, DNS u otra ruta pueden impedir la conexión antes.
• Firewall Log suppression agrupa repeticiones: Los eventos posteriores del firewall que se suprimen pueden agruparse en Log occurrence en lugar de aparecer como muchas filas individuales.

Si Log Viewer sigue mostrando nuevos eventos de sistema o firewall procedentes de otras pruebas, la vista funciona en principio. En ese caso, la causa suele estar en el logging de la regla, la selección del módulo, los filtros, el final de la sesión o el recorrido real de los paquetes. Para distinguirlo, conviene probar la regla con Log Viewer, Policy Tester y Packet Capture.

Generar un flujo de prueba controlado

Una prueba reproducible es más fiable que esperar tráfico aleatorio de usuarios. En el ejemplo siguiente, el cliente de prueba usa la dirección IP adaptable 10.20.30.25. En el cliente, no en la shell del firewall, se establece una conexión HTTPS breve:

curl -I https://example.com/

example.com es un dominio reservado para ejemplos. Para la prueba también se puede usar un servicio HTTPS propio, conocido y permitido. Lo importante es que el proceso cierre de nuevo la conexión y que se conozcan la hora, la IP del cliente y el destino.

Después se comprueba en este orden:

1. En Rules and policies > Firewall rules, verificar que la regla esperada tenga activado Log firewall traffic.
2. En Log Viewer, ejecutar Reset, seleccionar el módulo Firewall y un intervalo adecuado, y filtrar por 10.20.30.25.
3. Esperar unos segundos y actualizar manualmente una vez, porque el evento del firewall puede aparecer solo al finalizar la sesión.
4. Si falta la entrada, usar un filtro preciso como host 10.20.30.25 en Diagnostics > Packet capture y repetir la misma prueba.

La observación determina el paso siguiente:

• Packet Capture no ve el tráfico de prueba: Buscar la causa antes del firewall o en el cliente.
• Packet Capture muestra otra Rule ID: Revisar la regla que realmente coincide y su logging.
• Aparecen otros eventos nuevos en Log Viewer: Log Viewer no está detenido por completo; seguir revisando filtros, tipo de log y la regla concreta.
• Packet Capture confirma el flujo, Rule Logging y Local reporting son correctos, pero no aparece ningún evento nuevo: Revisar la build y el procesamiento local de logs.

Packet Capture muestra el flujo de paquetes, pero no repara la vista de logs. Packet Capture en el WebAdmin de Sophos Firewall explica el uso y los valores de estado.

Comprobar NC-175936 en SFOS 21.5 MR1 Build 261

Sophos documenta el error NC-175936 para SFOS 21.5 MR1 Build 261: puede faltar el archivo /tmp/eventlogs/active.db, lo que impide que Log Viewer muestre datos nuevos. Según Sophos, el firewall sigue procesando el tráfico y las funciones de seguridad siguen activas. Esta afirmación describe el error conocido y no es una confirmación general del estado de un firewall sin logs.

La lista actual de problemas conocidos de Sophos no indica un campo inequívoco de versión corregida para 21.5 MR2. Por tanto, el siguiente workaround no debe aplicarse en otras builds solo porque el síntoma sea parecido.

Comprobaciones de solo lectura en la Advanced Shell

Primero se anotan la build completa, la hora, el último evento visible y, en HA, el nodo afectado. Si WebAdmin todavía funciona, se guardan garner.log y, si es posible, un Consolidated Troubleshooting Report antes del cambio.

A continuación, se accede mediante el acceso SSH documentado a Sophos Firewall y se abre la Advanced Shell. Los comandos siguientes solo leen el estado del almacenamiento, el archivo y el log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp muestra si queda espacio libre en el sistema de archivos. ls -l confirma si existe active.db; si falta, la shell puede mostrar un mensaje como No such file or directory, según la build. En garner.log se buscan errores correspondientes a la hora de prueba documentada. Asignar correctamente los Service Logs de Sophos Firewall explica otros nombres de servicios y archivos de log.

Si /tmp está lleno, el archivo existe, la build es distinta o el síntoma no es inequívoco, no se realiza el siguiente reinicio. Los archivos de /tmp/eventlogs no se eliminan, copian ni crean manualmente.

Reiniciar Garner una vez de forma controlada

⚠️ Comando que cambia el estado: Este workaround solo se aplica al patrón de error documentado en SFOS 21.5 MR1 Build 261. Antes se guardan los logs y el estado del sistema. En un clúster HA, no se ejecuta el comando en ambos nodos sin un procedimiento verificado. Garner no debe reiniciarse repetidamente y active.db nunca debe repararse ni eliminarse manualmente.

Para NC-175936, Sophos indica exactamente este comando en la Advanced Shell:

service garner:restart -ds nosync

El comando se ha tomado para este artículo de la Sophos Known Issues List actual, pero no se ha probado en laboratorio sobre una appliance. Después del único reinicio, se vuelven a comprobar el archivo y los últimos mensajes de Garner con comandos de solo lectura:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Después se ejecutan Reset y Refresh en Log Viewer y se repite el mismo flujo de prueba breve. La medida solo se considera correcta cuando aparece un evento nuevo con la marca de tiempo correspondiente. La mera presencia de active.db no demuestra que toda la ruta de logging vuelva a funcionar.

Otras builds y fallos recurrentes

Sophos ha corregido otros errores relacionados con la base de datos de Log Viewer, pero no son idénticos. SFOS 22.0 MR1 Build 490 incluye con NC-152553 una corrección para un mecanismo de recuperación fallido de active.db; NC-169237, relativo a la pérdida de eventos de Log Viewer por corrupción de la base de datos, figura para SFOS 21.5 MR2 Build 323 y SFOS 22.0 GA Build 411. Estas Issue IDs no demuestran que NC-175936 esté corregido ni identifican automáticamente la causa de un fallo actual.

En una build antigua, primero se planifica una ruta de actualización de firmware SFOS compatible. En una build actual o después de un reinicio fallido de Garner, no se prueban otras intervenciones sobre la base de datos o los servicios.

Para un caso de soporte se recopila como mínimo:

• modelo de la appliance, versión de SFOS y build completa;
• en HA, el nodo afectado y su función;
• marca de tiempo de la última entrada visible en Log Viewer y hora del flujo de prueba;
• módulo, filtros, Rule ID, Source, Destination y Service de la prueba;
• estado de Log firewall traffic y Local reporting;
• resultado de Packet Capture;
• salida de df -kh /tmp y ls -l /tmp/eventlogs/active.db;
• garner.log, cuando sea necesario fwlog.log e iview.log, y, si es posible, un CTR antes de más cambios;
• información sobre si Garner se reinició una vez y qué cambió después.

Así Sophos puede distinguir entre errores de visualización, base de datos, almacenamiento, servicio y versión sin que los intentos repetidos de reparación oculten la causa original.