Utilizar correctamente Log Viewer en Sophos Firewall
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
- Comprobar Log firewall traffic en la regla de firewall afectada o Log connections en la regla SSL/TLS.
- En System services > Log settings, verificar que el tipo de log necesario esté activo en Local reporting.
- Abrir Log viewer en la esquina superior derecha de WebAdmin y elegir el módulo adecuado.
- Definir el filtro temporal y utilizar Add filter para acotar primero por IP de origen, IP de destino y servicio.
- Generar un flujo nuevo y breve y anotar la hora exacta.
- En Detailed view, comprobar Rule ID, NAT ID, acción, interfaces, usuario y campos específicos del módulo.
- 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?
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 la misma marca temporal y las mismas 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.
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.
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.
Aplicar filtros hasta dejar solo el flujo correcto
Log Viewer ofrece cuatro niveles de filtrado:
- Module: limita la vista a Firewall, Web, IPS, VPN u otra área.
- Time: limita los eventos al periodo de prueba.
- Add filter: combina un campo concreto, una condición y un valor.
- 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.
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. La desanonimización requiere una persona autorizada y sus credenciales. Aun así, una captura o exportación solo debe contener las filas necesarias para el caso.
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 Central 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 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 procedimiento completo para descartes con Reason, Rule ID y la Firewall ID 0 especial se explica en Analizar paquetes descartados en Sophos Firewall.
Modificar reglas desde Log Viewer solo de forma controlada
Según el evento, Log Viewer puede abrir directamente Web Policies, reglas de firewall o reglas SSL/TLS. 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.
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.
Cuando faltan los logs esperados
Un resultado vacío se comprueba en este orden:
- Revisar Pause, módulo, periodo y filtros; después usar Reset y Refresh.
- Comprobar el logging de la regla y Local reporting para el tipo de log necesario.
- Crear una conexión nueva, cerrada deliberadamente y con una hora conocida.
- Confirmar con Packet Capture que el tráfico llega al firewall y qué Rule ID lo procesa.
- Revisar otros módulos para eventos del mismo flujo.
- 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.
¿Por qué una conexión permitida aparece más tarde en Log Viewer?
Destroy, cuando termina la conexión. Una sesión larga o reutilizada puede aparecer con retraso. Para la prueba se crea una conexión nueva, breve y cerrada deliberadamente.