Analizar paquetes descartados en Sophos Firewall

Un paquete descartado no es automáticamente un error. El firewall puede bloquear el tráfico según lo previsto, descartar de forma inesperada tráfico legítimo o no ver el flujo de datos. Con el siguiente proceso se puede determinar rápidamente si la causa es una regla, NAT, la ruta de retorno, un módulo de seguridad o un sistema situado antes del firewall.

Delimitar los drops en pocos minutos

1. Anotar el caso de prueba: Registrar IP de origen, IP de destino, puerto, protocolo, hora y dirección esperada. En errores esporádicos, anotar también el usuario, la aplicación y el último cambio de configuración.
2. Filtrar Log Viewer: Buscar en el módulo Firewall por dirección IP, puerto y hora. Según el caso, abrir también Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection o VPN.
3. Iniciar Packet Capture: En Diagnostics > Packet capture, establecer un filtro preciso, activar la captura y realizar exactamente una prueba reproducible.
4. Leer el estado del paquete: Incoming, Forwarded, Consumed, Generated o Violation indican si el paquete llega, se reenvía, se procesa localmente, lo genera el firewall o se descarta.
5. Asignar la decisión: Comparar Rule ID, NAT ID y Reason con las reglas de firewall y NAT esperadas. En coincidencias de Web, IPS o Application, comprobar también la ID de la política correspondiente.
6. Capturar la dirección de retorno: Si el trayecto de ida se reenvía, pero no se ve respuesta, comprobar la ruta de retorno, el sistema de destino, NAT, SD-WAN y el enrutamiento asimétrico.
7. Modificar solo después: No crear una regla Allow amplia ni una excepción global antes de identificar el módulo responsable y la causa real.

Para el emparejamiento general de reglas y Policy Tester existe la guía detallada Probar una regla de Sophos Firewall con Log Viewer y Packet Capture.

Interpretar juntos Log Viewer y Packet Capture

Log Viewer e Invalid traffic

El Log Viewer se abre en la parte superior derecha de WebAdmin. No solo muestra decisiones del firewall, sino también eventos de los módulos de seguridad implicados. Por ejemplo, en tráfico de Web Proxy, el módulo Firewall puede mostrar Allowed y el módulo Web, al mismo tiempo, Blocked: la regla de firewall permite la conexión con el proxy, mientras que Web Policy bloquea el contenido. Por eso hay que correlacionar siempre los módulos del mismo momento de prueba. Los filtros, Detailed view, el momento de la sesión y Log occurrence se explican en Utilizar correctamente el Log Viewer de Sophos Firewall.

Para el tráfico de firewall deben comprobarse por separado dos requisitos:

• En la regla correspondiente está activado Log firewall traffic. Las reglas SSL/TLS disponen de su propia opción Log connections.
• En System services > Log settings está activado el destino de salida necesario para Log Viewer en Local reporting, Sophos Central o Syslog.

Las sesiones del firewall suelen aparecer cuando el firewall recibe un evento Destroy al cerrar la conexión. Si una conexión termina sin este evento, puede faltar la entrada esperada. Para una conservación más prolongada se pueden usar Central Firewall Reporting o Syslog hacia un SIEM.

Invalid traffic significa que Conntrack no puede asignar un paquete a una conexión actual. Una sesión caducada o paquetes TCP RST y FIN adicionales pueden generar estos eventos y no representan automáticamente un error. Si al mismo tiempo hay problemas de conexión, hay que capturar ambas direcciones y comprobar causas posibles como una ruta de retorno ausente, un trayecto asimétrico o un cambio de rol HA. Aumentar el tiempo de Conntrack puede reducir únicamente las entradas de registro; no corrige la causa.

Si el motivo concreto del descarte es Invalid TCP reserved bit, la causa puede ser Accurate ECN y no una regla de firewall. Resolver Invalid TCP reserved bit causado por Accurate ECN explica cómo demostrarlo y valorar el efecto de seguridad del workaround global por CLI.

Status, Rule ID, NAT ID y Reason

Packet Capture muestra los paquetes que pasan por una interfaz y añade información sobre el procesamiento realizado por el firewall, NAT y los módulos de seguridad. La documentación actual de SFOS 22 define estos valores de estado:

• Incoming: El paquete llega a una interfaz. Esto aún no demuestra que se reenvíe.
• Forwarded: El firewall reenvía el paquete a una interfaz de salida. Si falta la respuesta, el siguiente foco es el sistema de destino y la ruta de retorno.
• Consumed: El paquete está destinado al propio firewall, por ejemplo, a WebAdmin, SSH, DNS o un portal VPN.
• Generated: El propio firewall genera el paquete, por ejemplo, como respuesta o tráfico del sistema.
• Violation: Una infracción de política provoca el descarte. Rule ID, Reason y el módulo responsable indican el siguiente punto de comprobación.

También son importantes Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID y Username. Un valor inesperado puede indicar que coincide una regla más general situada más arriba, que NAT modifica las direcciones visibles o que no se ha identificado al usuario.

Reason es una orientación, no un informe completo de la causa raíz. Según la versión, valores como Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION o VIRTUAL_HOST pueden dirigir al módulo responsable. Primero hay que leer el estado y las ID y, después, abrir el área correspondiente de Log Viewer. Sophos Firewall Packet Capture explica el uso y los filtros.

Firewall ID 0 y registros de drop ausentes

Cuando no coincide ninguna regla de firewall explícita, se aplica al final de la base de reglas la regla integrada Drop all con Policy o Firewall ID 0. Esta regla no genera una entrada normal de tráfico de firewall. Para poder rastrear estos drops en Log Viewer, Central Reporting o Syslog, se crea al final de la base de reglas una regla propia con Action: Drop y Log firewall traffic activado.

Hay que seleccionar por separado las zonas de origen y destino necesarias y no usar Any de forma indiscriminada para las zonas. Así, los servicios locales siguen siendo accesibles. Si la regla final recibe mucho tráfico legítimo, probablemente falta una regla Allow adecuada más arriba o una red está clasificada de forma incorrecta.

Para SFOS 22.0.1 MR1 Build 490, Sophos documenta además el problema conocido NC-178387: los drops predeterminados con ID 0 no aparecen en Dropped Packet Capture ni en drppkt; en Packet Capture normal puede aparecer únicamente Incoming sin la entrada Violation Firewall correspondiente. El tráfico se descarta de todos modos. Sophos no indica en la lista de problemas conocidos una versión con corrección confirmada, por lo que no se debe presuponer este comportamiento fuera de la compilación indicada.

Si se sospecha de un drop predeterminado:

1. Comprobar el orden de las reglas y Policy Test.
2. Comparar el resultado con un Packet Capture real.
3. Si se necesita logging, crear una regla final con zonas específicas y una Rule ID propia.
4. Repetir la prueba y confirmar la nueva Rule ID en el registro o la captura.

Policy Tester, en Diagnostics > Tools, no tiene en cuenta las rutas SD-WAN y, por tanto, nunca es una prueba suficiente por sí solo. Además, en SFOS 22.0 GA, NC-177587 podía mostrar resultados de reglas incorrectos; los registros de producción y Packet Capture siguen siendo determinantes.

Delimitar la causa según el resultado

Regla, NAT y ruta de retorno

Si la Rule ID no corresponde a la regla esperada, comprobar las zonas de origen y destino, los objetos de red, el servicio, el protocolo, el usuario, el horario y el orden de las reglas. Con DNAT, es decisivo si la prueba se realiza contra la dirección pública y qué NAT ID se aplica realmente. Las bases se explican en Entender las reglas de firewall y Publicar un servidor mediante DNAT.

Si Packet Capture muestra Forwarded, pero no hay respuesta, otra regla Allow rara vez es la solución. A menudo faltan SNAT/MASQ o la ruta de retorno, una regla NAT vinculada está desactivada, el sistema de destino bloquea localmente o SD-WAN envía la respuesta por otro trayecto. Ambas direcciones deben pasar por el mismo firewall con estado.

Sesión, enrutamiento asimétrico y HA

Mensajes como Could not associate packet to any connection significan que no se ha encontrado ninguna entrada Conntrack correspondiente. Las causas posibles son una sesión caducada, flags TCP inesperados, una ruta de retorno asimétrica o un flujo de datos que el firewall solo ve en una dirección. Después de un cambio de rol HA también puede ser relevante en qué nodo se estableció la conexión.

Un único evento RST o FIN sin un problema para el usuario no requiere un cambio inmediato. En interrupciones reproducibles, se comprueban ambas direcciones con el mismo filtro y después se revisan el enrutamiento, SD-WAN, las rutas VPN y el estado HA.

Consumed y servicios locales del firewall

Consumed no es un drop normal de tránsito. El destino es el propio firewall, por ejemplo, WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN o SNMP. Estas conexiones suelen estar controladas por Administration > Device access y Local service ACL, no por una regla de firewall normal. Proteger Device Access en Sophos Firewall explica la configuración segura.

Módulos de seguridad, VPN y MTU

Una regla de firewall puede permitir el tráfico antes de que lo bloquee un módulo posterior. Por eso, cuando las ID o Reasons lo indiquen, también hay que comprobar Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response y WAF. Ante una coincidencia de IPS, evaluar la firma y el contexto de la regla antes de crear una excepción; el proceso se describe en Probar IPS de Sophos Firewall de forma segura.

En problemas de Web y TLS, QUIC mediante UDP 443 puede modificar el procesamiento esperado. Bloquear QUIC y HTTP/3 muestra el control correspondiente.

En VPN, PPPoE, SD-WAN o túneles anidados, MTU, MSS y la fragmentación suelen provocar bloqueos o interrupciones parciales en lugar de un drop claro. Para ello existen las guías sobre MTU y MSS y resolución de problemas de VPN IPsec.

Cuando las comprobaciones estándar no bastan

Ninguna entrada en Log Viewer o Packet Capture

Si falta una entrada de registro, comprobar primero el logging de la regla, Log settings, el filtro de tiempo y el módulo responsable. Si tampoco aparece ningún paquete en Packet Capture, antes de diagnosticar la red hay que comprobar lo siguiente:

• Packet Capture está realmente activo y la prueba se ha realizado después de activarlo.
• El filtro contiene las direcciones, los puertos, la dirección del tráfico y la interfaz correctos; ampliarlo ligeramente a modo de prueba.
• El búfer de 2048 KB no está lleno. Cuando se llena, la grabación se detiene automáticamente y debe reiniciarse después de seleccionar Clear.
• En System services > Services se está ejecutando Packet capture and Live connections; si no se inicia correctamente, reiniciar este servicio de forma controlada.

Solo cuando una prueba reproducible con una captura funcional no muestra ningún paquete entrante se debe desplazar el foco antes del firewall: cliente, VLAN, switch, gateway, router anterior o un destino de prueba incorrecto.

tcpdump, Drop Capture y archivos de registro

Para capturas más largas, archivos PCAP o filtros BPF precisos, iniciar sesión por SSH y seleccionar Option 4: Device Console. Un ejemplo de captura precisa para dos hosts y HTTPS es:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Para paquetes descartados por reglas de firewall, se puede usar el mismo filtro con drop-packet-capture:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture no ayuda con problemas de la capa de aplicación. Para crear un archivo PCAP, tcpdump admite la opción filedump; el archivo se guarda temporalmente en /tmp. Mantener la captura tan breve y precisa como sea posible, ya que los paquetes pueden contener información sensible, y eliminar el archivo después del análisis. Hay más ejemplos en tcpdump en Sophos Firewall.

Si el soporte también necesita registros de servicio, primero se debe identificar el registro responsable y guardar solo el periodo necesario. Para ello sirven Servicios y registros de Sophos Firewall y Guardar registros para soporte y análisis.

Corregir y documentar de forma segura

Una excepción solo es adecuada cuando se conocen el módulo, el propósito legítimo y el ámbito mínimo. No se debe permitir una excepción TLS global, una regla Allow con Any ni redes completas solo porque así funciona el servicio. Es preferible definir hosts, servicios y usuarios concretos, además de una fecha de revisión o caducidad.

Antes de cerrar el caso, documentar:

• Origen, destino, puerto, protocolo, hora y usuario.
• Rule ID y NAT ID esperadas y realmente visibles.
• Status, Reason y módulo de seguridad implicado.
• Dirección de ida y retorno o el punto en el que termina el flujo.
• Cambio, propietario, ticket y fecha de revisión; registrar también si se ha decidido no realizar ningún cambio.

Después, repetir la misma prueba. La conexión permitida debe funcionar y una fuente de comparación no permitida debe seguir bloqueada. Así se evita que una corrección rápida se convierta en una vulnerabilidad de seguridad permanente.

Preguntas frecuentes