Ir al contenido
Avanet

Sophos Firewall Log Viewer no muestra logs nuevos

Sophos Firewall

Si Log Viewer no muestra eventos nuevos en SFOS 22, no se debe reiniciar un servicio basándose solo en una sospecha. 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. En Diagnostics > Packet capture > Configure, establecer un filtro BPF preciso, activar la captura y comprobar si el tráfico llega al firewall y qué Rule ID se procesa.
  5. Desactivar la captura después de la prueba. 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. En SFOS 22 no usar workarounds de Garner o de la base de datos procedentes de versiones anteriores. Revisar la maintenance release actual y entregar los datos de diagnóstico a Sophos Support si todos los logs locales están detenidos.
  7. El workaround de Garner conservado más abajo pertenece exclusivamente a SFOS 21.5.1 MR1 Build 261 y al patrón exacto documentado.

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.
  • La sesión termina sin un evento Destroy: Si, por ejemplo, se pierde la conexión a Internet, la sesión puede cerrarse sin generar ninguna entrada de log. En ese caso, la entrada no está simplemente retrasada: nunca se crea.
  • 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, abrir Diagnostics > Packet capture, hacer clic en Configure, introducir el filtro preciso host 10.20.30.25 en Enter BPF string y guardar. Sustituir la IP por la dirección real del cliente de prueba.
  5. Activar Packet capture, repetir la prueba una vez y desactivar después la captura. Así queda limitada al cliente conocido y a un intervalo corto.

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. Si el búfer está lleno y Wrap capture buffer once full no está seleccionado, SFOS detiene automáticamente la captura; Clear libera el búfer para otra prueba. Packet Capture en el WebAdmin de Sophos Firewall explica el uso y los valores de estado.

Clasificar el fallo en SFOS 22

La Sophos Known Issues List limita NC-175936 a SFOS 21.5.1 MR1 Build 261 e indica expresamente que el problema está resuelto en la versión 22. Por tanto, el reinicio de Garner asociado no es una vía de reparación para SFOS 22.

Las notas de versión de SFOS 22 enumeran otros cambios del Logging Framework. SFOS 22.0 GA Build 411 corrigió NC-169237, por el que la corrupción de la base de datos hacía que Log Viewer perdiera eventos. SFOS 22.0 MR1 Build 490 corrigió NC-152553, un fallo del mecanismo de recuperación de active.db. La versión más reciente allí indicada, SFOS 22.0 MR2 Build 546, mejora el rendimiento de Log Viewer con NC-181520.

Estas entradas confirman errores corregidos, pero no identifican la causa de un fallo actual. En SFOS 22 se registran la versión y la build exactas, se revisa una ruta de actualización compatible hacia la maintenance release actual y no se modifican archivos de base de datos ni se reinicia un servicio de logging desde la shell si siguen faltando eventos.

Comprobar NC-175936 en SFOS 21.5.1 MR1 Build 261

Sophos documenta el error NC-175936 para SFOS 21.5.1 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.

Sophos también indica expresamente que el problema está resuelto en la versión 22. Por tanto, el siguiente workaround heredado no debe aplicarse en SFOS 22 ni en otra build 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.1 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. El reinicio de un servicio no se puede deshacer; si el archivo sigue ausente o los eventos continúan sin aparecer, se detiene aquí la intervención y se entrega a Sophos Support el estado guardado antes del cambio. 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.

Si SFOS 22 sigue sin mostrar eventos nuevos

Si Packet Capture muestra el flujo de prueba controlado en SFOS 22, Rule Logging y Local reporting son correctos y siguen faltando eventos nuevos en todos los módulos, primero se planifica una ruta de actualización de firmware SFOS compatible hacia la maintenance release actual. Si el problema persiste en la build actual, no se interviene en la base de datos ni en 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;
  • para el patrón exacto de 21.5.1 MR1, 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 de reparación repetidos oculten la causa original.