Utilizar correctamente Log Viewer en Sophos Firewall

En SFOS 22, Log Viewer suele ser el punto de partida más rápido ante una incidencia: ¿Qué regla de firewall procesó el tráfico, qué regla NAT intervino, qué usuario se identificó y qué módulo de seguridad lo bloqueó? Para que la respuesta sea correcta, deben coincidir el módulo, el periodo, los filtros y el momento en que se genera el log.

Log Viewer muestra eventos registrados. No es Packet Capture ni un historial completo de conexiones. Por eso, la ausencia de una entrada no demuestra ni un descarte ni que el paquete haya llegado al firewall.

Para un análisis fiable siempre se anotan origen, destino, servicio, hora exacta de la prueba y dirección esperada. Después se genera exactamente un flujo nuevo y se busca en los módulos adecuados.

Evaluar una prueba en siete pasos

1. Comprobar Log firewall traffic en la regla de firewall afectada o Log connections en la regla SSL/TLS.
2. En System services > Log settings, verificar que el tipo de log necesario esté activo en Local reporting.
3. Abrir Log viewer (SFOS 22) o Logs and policy test (SFOS 23) en la esquina superior derecha de WebAdmin y, a continuación, elegir el módulo de logs adecuado.
4. Definir el filtro temporal y utilizar Add filter para acotar primero por IP de origen, IP de destino y servicio.
5. Generar un flujo nuevo y breve y anotar la hora exacta.
6. En Detailed view, comprobar Rule ID, NAT ID, acción, interfaces, usuario y campos específicos del módulo.
7. Si la entrada y el comportamiento observado no coinciden, correlacionar la misma prueba con Packet Capture antes de modificar una regla.

Este orden separa tres preguntas que suelen confundirse: ¿Se generó un log? ¿Qué política tomó la decisión? ¿Los paquetes realmente entraron y volvieron a salir?

Los Event Logs registran autenticación, eventos del sistema y cambios de configuración, además del tráfico, y se almacenan localmente de forma predeterminada. Los Troubleshooting Logs son registros detallados de servicios accesibles desde WebAdmin o la CLI. El procedimiento de logs de servicios explica el acceso y la captura con debug. Debug ocupa espacio adicional y debe desactivarse tras recoger los datos necesarios; no es un interruptor para recuperar Event Logs ausentes.

Para el envío centralizado, la firewall debe estar registrada en Sophos Central Firewall Management. Después se activan los servicios de Central y Send reports and logs to Sophos Central, y se seleccionan los tipos de log necesarios en System services > Log settings. La documentación de SFOS 22 revisada denomina el destino Sophos Fusion, mientras que la de SFOS 23 lo llama Sophos Central; deben seguirse los campos de interfaz indicados. El procedimiento de Central Reporting cubre la configuración y la comprobación de recepción.

Leer correctamente los logs

Por qué los logs no siempre aparecen de inmediato

Log Viewer actualiza la vista automáticamente. Sin embargo, una sesión de firewall normalmente solo se registra cuando el firewall recibe un evento Destroy y cierra la conexión. En una sesión larga, la entrada puede aparecer más tarde que la primera solicitud.

Si una conexión termina sin que el firewall reciba un evento Destroy, por ejemplo al perderse la conectividad a internet, puede faltar por completo el log esperado de la sesión. Las conexiones SSL/TLS se registran tras completarse el handshake y al cerrarse. Para una prueba breve es mejor una conexión cerrada deliberadamente que una sesión permanente de navegador, streaming o HTTP/2.

Recargar el navegador no crea necesariamente una conexión nueva. Según la aplicación, se puede utilizar una ventana privada, reiniciar el proceso cliente o realizar una solicitud breve como:

curl -I https://example.com/

El comando se ejecuta en el cliente de prueba, no en la shell del firewall. example.com es un dominio de ejemplo reservado y puede sustituirse por un servicio conocido y permitido.

Elegir el módulo correcto

Un flujo puede afectar a varios módulos de log. El módulo Firewall puede indicar que una regla LAN-to-WAN permite la conexión, mientras que Web filter, Application filter, IPS o SSL/TLS inspection bloquea o trata posteriormente el mismo flujo de otra manera.

Por eso, una única entrada verde del firewall no basta en problemas web o de seguridad. Los módulos se correlacionan para el mismo flujo de prueba a partir del periodo de prueba y las direcciones:

• Firewall: decisión de regla, NAT, interfaces, puertos y estado básico de la conexión.
• Web filter: decisiones de URL, categoría y Web Policy.
• SSL/TLS inspection: decisiones de certificado, handshake y descifrado.
• Application filter: aplicación identificada y acción de Application Control.
• IPS: eventos de firma o anomalía.
• VPN: establecimiento y estado del componente VPN correspondiente.
• Authentication: usuario identificado e inicio de sesión correcto o fallido.
• System: eventos del sistema y provocados por administradores.
• SD-WAN: uso de perfil SD-WAN, SLA y ruta.

Los tipos de log que aparecen localmente se configuran en System services > Log settings, dentro de Local reporting. Estos Event Logs no son lo mismo que los On-box Reports. Central reporting y syslog son destinos separados y deben activarse de forma independiente. Los eventos de Web Policy también requieren Log firewall traffic en la regla de firewall asociada. Los logs Wireless no están disponibles en Log Viewer; deben enviarse a Sophos Fusion (antes Sophos Central) o a un servidor syslog.

Límite del Web Proxy: La documentación de SFOS 22/23 sobre el comportamiento de los logs describe esta ruta del proxy para HTTP/HTTPS en los puertos 80 y 443: una regla Drop coincidente entrega los paquetes entrantes al Web Proxy, que envía al usuario una página de bloqueo; sin una Web Exception coincidente, el log Firewall muestra Allowed y el log Web filter Blocked. Las Web Exceptions siguen aplicándose y pueden permitir solicitudes a pesar de Drop. La ruta documentada de Reject termina el flujo antes del procesamiento del proxy. Revisar conjuntamente la regla de firewall, la Web Policy y las Web Exceptions; es un escenario documentado, no una garantía universal de página de bloqueo para cualquier build o modo de inspección.

Conflicto documental sin resolver: La ayuda de SFOS 22/23 sobre el formulario de reglas describe la autenticación de usuarios web desconocidos con Use web authentication for unknown users activado, permite las Web Exceptions coincidentes y, en los demás casos, describe una página de bloqueo HTML. En cambio, la guía de logging del tráfico descartado describe el descarte silencioso y vincula la página de bloqueo web a esa opción de autenticación. No deducir que la opción por sí sola determina la respuesta. Antes de confiar en Drop para bloquear tráfico web, obtener una aclaración escrita de Sophos para la versión, build y ruta de procesamiento exactos, o realizar una verificación aislada y expresamente autorizada. Registrar la regla y los ajustes actuales para revertirlos; comprobar HTTP y HTTPS por separado, usuarios conocidos/desconocidos, autenticación activada/desactivada y excepciones coincidentes presentes/ausentes. Correlacionar flujos nuevos con Rule ID, logs, Packet Capture y resultados del navegador. Ni una página de bloqueo ni un timeout por sí solos prueban el bloqueo. Si el acceso es inesperado o el resultado no está claro, revertir los cambios de prueba y escalar; no desplegar en producción.

En puertos distintos de 80 y 443, una regla Drop coincidente descarta los paquetes directamente; el log Firewall muestra dropped. Con Reject, el log Firewall muestra rejected, tanto en 80/443 como en otros puertos. Estas observaciones requieren Log firewall traffic en la regla coincidente. Una Web Exception puede permitir, por ejemplo, actualizaciones de Windows de Microsoft a pesar de una regla Drop; esto no justifica ampliar la regla sin investigar.

Regla Allow y ausencia de heartbeat

Un caso distinto de Drop se produce cuando la regla de firewall que realmente coincide tiene Action Allow, está activada Block clients with no Heartbeat y el endpoint no envía heartbeat. Para observar los logs descritos, Log firewall traffic debe estar activo en esa regla. Antes de buscar, comprobar también los tipos de log necesarios en System services > Log settings > Local reporting; activar solo un destino externo no basta para la vista local.

• Puertos distintos de 80 y 443: El firewall descarta los paquetes de este endpoint. El log Firewall muestra dropped.
• Puertos 80 y 443 en la ruta documentada del Web Proxy: El firewall acepta los paquetes entrantes y los entrega al Web Proxy. Como el endpoint no envía heartbeat, el sistema de heartbeat decide bloquear; el proxy muestra una página de bloqueo al usuario. El log Firewall muestra allowed, otro log Firewall muestra Heartbeat blocked y el log Web filter muestra blocked. Por tanto, Heartbeat blocked también pertenece aquí al módulo Firewall, no a un módulo de logs de heartbeat separado.

Allowed por sí solo no demuestra un acceso correcto. Antes de modificar una regla, correlacionar las entradas del mismo flujo de prueba: revisar conjuntamente el periodo de prueba, origen, destino, puertos y regla coincidente. Buscar la entrada independiente Heartbeat blocked y la entrada de Web filter con blocked. No se requiere un orden fijo de eventos, marcas temporales idénticas ni un número universal de filas; si faltan entradas esperadas, comprobar primero el logging, los destinos locales y los filtros, y usar Packet Capture si es necesario.

Esta interpretación se limita a esta opción concreta de regla, un endpoint sin heartbeat y la ruta del proxy descrita. No es una afirmación general sobre todas las reglas Allow, endpoints con estado rojo o no saludable, ni otros modos de inspección. No desactivar la aplicación del requisito de heartbeat como solución genérica; primero aclarar qué regla coincide y por qué falta el heartbeat.

Diferenciar Standard view y Detailed view

Standard view resulta útil para una lectura rápida. Se pueden añadir o quitar columnas y, al hacer clic en un valor, utilizarlo directamente como filtro. Para una validación técnica es más importante Detailed view, ya que muestra los nombres de campos subyacentes y valores adicionales.

Un detalle NAT importante: si se utiliza una dirección de origen traducida distinta de la dirección MASQ predeterminada, Standard view puede seguir mostrando la dirección MASQ como dirección de salida. El origen realmente traducido aparece en Detailed view en src_trans_ip.

En Standard view, pasar el cursor sobre el icono de un módulo también muestra detalles. La función de copia permite copiar información del log al portapapeles. El visor se abre en una ventana nueva a pantalla completa; si no aparece, comprobar primero el bloqueador de ventanas emergentes del navegador.

Los campos habituales para una prueba de firewall son:

• IP de origen y destino, y puertos de origen y destino
• In interface y Out interface
• Firewall Rule ID y NAT Rule ID
• Acción o estado
• Nombre de usuario, si se reconoció una identidad
• Origen y destino traducidos
• Log component y Log subtype

Un nombre de campo o una ID no explica automáticamente la causa. La Rule ID se compara con la base de reglas actual, la NAT ID con la regla NAT correspondiente y una ID de política de seguridad con su módulo.

Si al mismo tiempo está activo un Packet Capture en Diagnostics > Packet capture, Open PCAP en la entrada de log correspondiente puede abrir la información de los paquetes asociados. Esto relaciona la decisión registrada con los detalles de los paquetes, pero no sustituye un filtro de captura bien delimitado: origen, destino, puerto y hora de la prueba deben seguir coincidiendo con el flujo investigado.

Delimitar el flujo correcto

Aplicar filtros hasta dejar solo el flujo correcto

Log Viewer ofrece cuatro niveles de filtrado:

1. Module: limita la vista a Firewall, Web, IPS, VPN u otra área.
2. Time / Timer filter: limita los eventos al periodo de prueba; hacer clic en Timer filter y elegir una opción temporal.
3. Add filter: combina un campo concreto, una condición y un valor.
4. Free text search: busca, por ejemplo, puertos, direcciones IP, usuarios o nombres de reglas y también funciona con información anonimizada.

Para una prueba normal se empieza con IP de origen, IP de destino y puerto de destino. Después se acota con Rule ID, usuario o acción. Reset elimina todos los filtros. Esto es importante porque un filtro temporal o de campo antiguo puede dar la impresión de que el visor ya no recibe eventos.

El número de entradas disponibles depende del tamaño del disco y de la retención local. Log Viewer no sustituye a un almacenamiento a largo plazo protegido contra manipulaciones. Para ello se pueden usar Central Firewall Reporting o Enviar syslog a un SIEM.

La cuota local de Event Logs depende del modelo de appliance: para modelos de gama alta, Sophos indica hasta el 15 % de toda la partición /var o el 50 % de su espacio libre, el valor que sea menor. No es un periodo de retención garantizado ni una cuota válida para todos los modelos. El análisis de almacenamiento distingue Event Logs, informes y Troubleshooting Logs; no se deben borrar archivos por intuición.

Utilizar correctamente Pause, Refresh y la exportación CSV

Pause detiene la actualización automática de la vista. Resulta útil para leer o copiar una fila sin que se mueva. No detiene el registro en el firewall. Refresh vuelve a cargar la vista manualmente y la exportación descarga los logs disponibles actualmente en formato CSV.

Antes de exportar se documentan el módulo, el periodo y los filtros. El CSV puede contener direcciones IP internas, nombres de usuario, URL y relaciones de comunicación, por lo que debe tratarse mediante un flujo de soporte o análisis protegido.

Si Data anonymization está activa, los valores identificativos como usuario, IP, MAC y correo electrónico se muestran protegidos. Sophos recomienda al menos dos Authorizers: si el administrador conectado es uno de ellos, al menos otra persona autorizada debe aprobar la desanonimización. Aun así, una captura o exportación solo debe contener las filas necesarias para el caso.

Para mostrar identidades mediante la función de desanonimización, se necesita autorización y se deben introducir las credenciales de autenticación. Copiar una fila no sustituye esa autorización.

Comprender Log suppression y Log occurrence

En System services > Log settings, el firewall puede suprimir eventos consecutivos e idénticos de firewall. Esto ahorra almacenamiento y procesamiento. La supresión no solo afecta a los logs locales, sino también a Sophos Fusion y a los destinos syslog configurados.

En Log Viewer, Log occurrence muestra cuántas veces se produjo un evento resumido. Por tanto, una sola fila puede representar muchas repeticiones. No debe contarse automáticamente como un solo paquete o una sola conexión.

Antes de modificar Log suppression se comprueba si el volumen actual de logs es realmente la causa del problema. Para un diagnóstico breve suele bastar con interpretar conscientemente Log occurrence. Un cambio global también afecta a los destinos externos y no debe hacerse solo para obtener una captura.

Interpretar los hallazgos con seguridad

Interpretar correctamente Invalid traffic

Invalid traffic significa que conntrack no pudo asociar un paquete a una conexión actual. Puede ocurrir por una ruta asimétrica, una sesión caducada, flags TCP inesperados o paquetes RST y FIN adicionales. No implica automáticamente un ataque ni un defecto del firewall.

Si al mismo tiempo existe un problema de conexión, se capturan ambas direcciones con Packet Capture. Origen, destino, flags TCP, interfaces y marcas temporales deben pertenecer al mismo flujo. Aumentar Tcp Connection Establishment Idle Timeout puede reducir el número de estos logs, pero no corrige la causa de ruta o sesión. El valor no debe cambiarse por intuición.

El registro de Invalid traffic está activado de forma predeterminada. Conntrack sigue sesiones TCP y determinadas sesiones UDP e ICMP; paquetes iniciales como TCP SYN o una petición ICMP Echo establecen la asociación de conexión. Los flags TCP se interpretan así:

• SYN: solicita sincronización.
• SYN-ACK: la confirma y acuerda parámetros de conexión.
• ACK: confirma el acuerdo; puede comenzar la transferencia de datos.
• PSH: solicita la entrega inmediata de datos.
• FIN: solicita un cierre ordenado; ambos extremos confirman la finalización.
• RST: termina la conexión sin esperar respuesta, por ejemplo tras un paquete inesperado.

Los paquetes RST y FIN adicionales pueden descartarse y registrarse como Invalid traffic. Una entrada aislada se correlaciona con el problema real de conexión, en lugar de considerarla un ataque independiente.

El comando de solo lectura show advanced-firewall en Device Console muestra el valor global actual; Sophos documenta 10800 segundos, es decir, tres horas, como valor predeterminado. Un cambio afecta a todas las sesiones TCP correspondientes de la firewall. Antes se correlacionan de forma inequívoca la aplicación afectada, su tiempo de inactividad real y el evento Invalid traffic. Un timeout mayor solo es un ajuste operativo justificado, no una reparación para routing asimétrico o pérdida de paquetes.

El procedimiento completo para descartes con Reason, Rule ID y la Firewall ID 0 especial se explica en Analizar paquetes descartados en Sophos Firewall.

La fuente llama al campo Tcp Connection Establishment Idle Timeout, pero describe la caducidad de entradas conntrack por inactividad y utiliza el setter tcp-est-idle-timeout. El nombre es ambiguo; no demuestra que exista un timeout de handshake separado. Se deben comprobar la salida real y la ayuda de CLI del build instalado.

La referencia CLI de SFOS 22/23 asigna expresamente tcp-est-idle-timeout a conexiones TCP ya establecidas y permite de 2700 a 432000 segundos. Por tanto, el nombre distinto del campo no se utiliza como recomendación para modificar un timeout de establecimiento de conexión.

Solo si un caso confirmado de timeout por inactividad justifica un ajuste global, se selecciona 4. Device Console en la CLI, se anota el valor actual con show advanced-firewall y se acuerda una ventana de mantenimiento. El ejemplo documentado lo aumenta a seis horas; no es un valor recomendado de forma general:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Comprobar el nuevo valor y repetir la prueba de la misma aplicación durante el periodo de inactividad pertinente. Menos entradas Invalid traffic no demuestran por sí solas una reparación. Para revertir, usar el mismo setter con los segundos anotados previamente y comprobar de nuevo con show advanced-firewall; 10800 solo corresponde si era el valor original. Si la salida CLI no es clara o el fallo continúa, dejar de ajustar e investigar la ruta de paquetes o recurrir a soporte. Este procedimiento se ha revisado documentalmente, no se ha probado en una firewall.

Modificar reglas desde Log Viewer solo de forma controlada

Según el evento, Log Viewer puede abrir directamente Web Policies o reglas NAT, de firewall o SSL/TLS. Hacer clic en una Web Policy, regla NAT o regla de firewall ofrece un enlace a su edición en WebAdmin. Es práctico, pero no acorta la comprobación técnica. Antes de editar se verifican Rule ID, nombre, posición, zonas, objetos, servicio, relación con usuarios y sesiones existentes; además, se anotan los valores actuales de los campos que se modificarán para poder restaurarlos.

Para una excepción SSL/TLS, seleccionar SSL/TLS inspection, desplazarse hasta Manage, elegir Exclude, revisar la opción del diálogo y solo entonces confirmar con Exclude. Domain y Subdomain se añaden al grupo URL Local TLS exclusion list, visible en Categories and websites de las reglas SSL/TLS. Web category se añade a Exclusions by website or category, visible en la lista de reglas SSL/TLS. Para Other properties, seleccionar la regla SSL/TLS y objetos adecuados, como usuarios o direcciones IP. Antes de confirmar, comprobar el objeto de destino y el alcance; una exclusión de dominio no equivale a una excepción prevista para un único usuario. Log Viewer no ofrece Exclude para 19004 (tráfico permitido) ni 19005 (bloqueado por una Web Policy).

Al hacer clic en una IPS Signature ID puede aparecer Disable signature for this IPS policy. Esto modifica la IPS Policy activa, no solo la vista. Antes se documentan la regla, la política, la firma, el efecto sobre la protección y el alcance de la excepción; después se vuelve a probar exactamente el flujo confirmado.

Una regla Allow amplia, una excepción web global o desactivar TLS inspection puede ocultar el síntoma y crear a la vez una nueva brecha de seguridad. Los cambios se limitan al flujo confirmado, se prueban en una ventana de mantenimiento y se validan con un flujo nuevo en Log Viewer y, si es necesario, Packet Capture. Si la prueba falla o la excepción resulta demasiado amplia, se restaura el estado anotado previamente en el objeto de regla o política enlazado y se repite la prueba con un flujo nuevo.

Cuando faltan logs o están en el otro nodo HA

Cuando faltan los logs esperados

Un resultado vacío se comprueba en este orden:

1. Revisar Pause, módulo, periodo y filtros; después usar Reset y Refresh.
2. Comprobar el logging de la regla y Local reporting para el tipo de log necesario.
3. Crear una conexión nueva, cerrada deliberadamente y con una hora conocida.
4. Confirmar con Packet Capture que el tráfico llega al firewall y qué Rule ID lo procesa.
5. Revisar otros módulos para eventos del mismo flujo.
6. Solo si toda la vista local deja de recibir eventos nuevos, investigar la ruta del visor o del servicio de logs.

El diagnóstico específico de versión para un visor completamente detenido se describe en Log Viewer no muestra logs nuevos. Reiniciar un servicio o intervenir en la base de datos local de logs no forma parte del uso general.

Log Viewer en entornos HA

Cada nodo HA almacena únicamente los logs e informes del tráfico que ha procesado. Especialmente en active-active o después de un failover, la entrada esperada puede estar en el otro nodo. Se documentan conjuntamente la hora, el rol del nodo y Connection served by.

Central Firewall Reporting o syslog ofrecen una vista centralizada. Sin embargo, no sustituyen la revisión por nodo cuando se analiza un cambio de rol HA concreto, un fallo de servicio local o la ruta del tráfico en el momento del evento.