Probar correctamente una regla de Sophos Firewall

No solo se debe guardar una regla de firewall, sino también probarla de manera específica. Especialmente en casos de filtrado web, inspección TLS, NAT, IPS o coincidencia de usuarios, una regla puede parecer correcta visualmente y aún así no funcionar como se espera.

Para la prueba se pueden utilizar varias herramientas:

• Log viewer para eventos reales y decisiones de reglas
• Policy tester para la lógica de políticas web, de firewall y SSL/TLS
• Packet capture para el flujo real de paquetes
• tcpdump para capturas más largas, archivos PCAP y casos de soporte

Es importante el orden correcto: primero se verifica si la prueba está bien definida y si la regla genera registros. Luego, el Log Viewer muestra qué decisión registró realmente el firewall. El Policy tester ayuda con la lógica de políticas esperada, pero no prueba el flujo real de paquetes. Packet Capture es la mejor evidencia cuando podrían estar involucrados el enrutamiento, NAT, VLAN, VPN, el proveedor o un sistema de destino. Si la prueba debe ejecutarse por más tiempo, se necesita un archivo PCAP o el soporte de Sophos debe evaluar la captura, tcpdump en Sophos Firewall es la mejor herramienta.

Una buena prueba de reglas no responde solo si una regla “funciona”. Muestra qué Rule ID hizo match realmente, qué NAT ID participó, si intervinieron funciones de seguridad y si ida y vuelta toman el mismo camino esperado.

¿Qué artículo es adecuado?

Este artículo es la introducción correcta si se debe probar un intento de conexión específico con IP de origen, destino, servicio y hora. Para problemas relacionados, un artículo más específico suele ser más rápido:

• Una regla no coincide o gana otra regla: La regla de Sophos Firewall no coincide: revisar causas.
• DNAT, SNAT, MASQ o el orden de NAT están involucrados: Entender NAT en Sophos Firewall.
• Un servidor interno se publica desde Internet: Publicar servidor mediante DNAT.
• Packet Capture muestra caídas, Violation o razones inesperadas de Drop: Analizar paquetes descartados en Sophos Firewall.
• SSL VPN está conectado, pero los destinos internos no funcionan: Configurar acceso remoto SSL VPN en Sophos Firewall.
• Site-to-Site-IPsec o Remote-Access-IPsec tienen problemas: Solución de problemas de IPsec VPN en Sophos Firewall.
• Las herramientas de WebAdmin no son suficientes y se necesitan registros locales: Asignar correctamente los logs de servicio de Sophos Firewall.
• Un caso de soporte necesita archivo de registro, datos de IPsec o archivos PCAP: Guardar registros de Sophos Firewall para soporte y análisis.

Esta delimitación evita que se investigue un problema específico de NAT, VPN, enrutamiento o servicio de manera demasiado amplia con una prueba de regla general.

Clasificación correcta de las herramientas

• Log viewer: muestra Rule ID, NAT ID, Action, usuario y decisiones de funciones de seguridad. No demuestra paquetes que no llegan al firewall.
• Policy tester: muestra la política de firewall, web y SSL/TLS esperada para entradas definidas. No demuestra camino de retorno real, SD-WAN, pérdida de paquetes ni comportamiento del proveedor.
• Packet capture: muestra si los paquetes llegan, se reenvían y si las respuestas regresan. No explica automáticamente la intención funcional detrás de una regla o Web Policy.
• tcpdump: sirve para capturas más largas, filtros BPF muy precisos, archivos PCAP y análisis en Wireshark. Rule ID, NAT ID o decisiones de Web Policy no se ven directamente en WebAdmin.
• Central Reporting o Syslog: ayuda para histórico, informes, correlación SIEM y evaluación posterior. Para flujo de paquetes en vivo y detalles de servicios locales, las herramientas locales suelen ser más rápidas.

Si una regla supuestamente “no funciona”, no se debe cambiar inmediatamente la regla en sí. A menudo, la causa está en NAT, enrutamiento, una regla superior, falta de registro o una característica de seguridad. Para una búsqueda de fallos sistemática, también es adecuado La regla de Sophos Firewall no coincide: revisar causas.

Para live troubleshooting, el Log Viewer local suele ser más rápido que Central Reporting o un SIEM. Los logs centralizados son importantes cuando los eventos deben reconstruirse más tarde, correlacionarse o conservarse durante más tiempo. Para la configuración encajan Central Firewall Reporting y enviar Syslog a SIEM.

Procedimiento breve para la prueba de reglas

Para la mayoría de los casos de soporte, un procedimiento claro es suficiente:

1. Definir el caso de prueba con IP de origen, destino, servicio, usuario y hora.
2. Activar Log firewall traffic en la regla afectada.
3. Verificar la posición de la regla y el contador de uso.
4. Reproducir la prueba exactamente una vez.
5. Filtrar en Log Viewer por IP de origen, IP de destino y servicio.
6. Anotar Rule ID y NAT ID del registro real.
7. Usar Policy tester solo para la lógica de políticas.
8. Iniciar Packet Capture si Log Viewer y Policy tester no coinciden.
9. Documentar el resultado antes de mover o cambiar una regla.

Es importante cambiar solo un caso de prueba por pasada. Si al mismo tiempo se cambian posición de regla, NAT, DNS, routing y cliente, el éxito posterior ya no puede atribuirse limpiamente.

Este procedimiento evita que se modifique innecesariamente una regla que funciona, aunque el problema real esté en NAT, enrutamiento, DNS, inspección TLS o un sistema de destino.

Antes de la prueba

Primero se debe anotar exactamente qué se va a probar:

• IP de origen: 172.16.10.25
• Usuario: user@domain.local
• Zona de origen: LAN
• Destino: https://www.example.com
• Servicio: HTTPS
• Regla esperada: LAN_to_WAN_Clients
• Acción esperada: permitido, bloqueado, descifrado, no descifrado

Luego, activar Log firewall traffic en la regla de firewall afectada. Sin registro, el Log Viewer es solo de ayuda limitada.

Paso 1: Verificar la posición de la regla

Abrir Rules and policies > Firewall rules y verificar:

• ¿Está la regla por encima de reglas más generales?
• ¿Está activa?
• ¿Está seleccionada la vista correcta de IPv4 o IPv6?
• ¿Está en un grupo de reglas lógico?
• ¿Existen exclusiones?
• ¿Hay una regla creada automáticamente por encima?

Si se está probando una nueva regla, se debe restablecer el contador de uso de la regla. Luego, es más fácil ver si la regla realmente se activó durante la prueba.

Paso 2: Abrir Log Viewer

Abrir el Log viewer en la esquina superior derecha de la consola WebAdmin.

Filtros útiles:

• Módulo: Firewall
• IP de origen
• IP de destino
• Puerto de destino
• Rule ID
• Nombre de la regla
• Acción
• Usuario

Para tráfico web, verificar adicionalmente:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

El Log Viewer se actualiza automáticamente. Para un análisis tranquilo, se puede pausar la vista en vivo, filtrar y luego continuar.

Paso 3: Reproducir la prueba

La prueba debe ser ejecutada desde un cliente definido:

• Abrir sitio web
• Enviar ping
• Probar puerto
• Iniciar aplicación
• Establecer conexión VPN
• Descargar archivo

Si es posible, siempre debe ejecutarse solo una prueba a la vez. De lo contrario, los registros y los contadores de reglas se mezclan.

Luego verificar:

• ¿Aumenta el contador de reglas?
• ¿Se ve un registro en el Log Viewer?
• ¿Qué Rule ID se muestra?
• ¿Qué NAT Rule ID se muestra?
• ¿El tráfico está permitido o bloqueado?
• ¿Se activa una característica de seguridad?

Si el Log Viewer queda vacío, eso aún no demuestra nada contra la regla. Primero deben comprobarse logging, filtro de tiempo, filtro de módulo y flujo real de paquetes. A menudo el tráfico ni siquiera llega al firewall, la regla no registra, el tipo de log incorrecto está desactivado o la prueba usa otra IP de destino de la esperada.

Paso 4: Usar Policy tester

El Policy tester es útil si se desea verificar qué regla de firewall, regla de inspección SSL/TLS o política web se aplicaría teóricamente al tráfico web.

Ruta de menú:

Diagnostics > Tools > Policy tester

Entradas típicas:

• URL
• Usuario
• Hora y día
• IP de origen
• Zona de origen
• Método de prueba

Como método de prueba, se elige por ejemplo Firewall, SSL/TLS, and web, si se desea verificar la combinación de regla de firewall, regla de inspección SSL/TLS y política web.

El Policy tester no solo muestra Accepted o Blocked, sino también la regla de firewall coincidente, el destino reconocido, la zona de origen y, según el método de prueba, más información web o SSL/TLS. Esto permite ver rápidamente si el tráfico cae fundamentalmente en la regla esperada.

Importante:

⚠️ El Policy tester no reemplaza una prueba de flujo de paquetes real. Los resultados de la prueba de políticas no reflejan de manera confiable las rutas SD-WAN. Por lo tanto, el comportamiento real puede diferir si están involucrados SD-WAN, enrutamiento o gateways.

SFOS 22: El Policy tester puede mostrar resultados incorrectos

En SFOS 22.0 GA y SFOS 22.0 MR1, se deben evaluar los resultados de la prueba de políticas con especial precaución. Policy Test y Policy Route Test pueden mostrar el tráfico como bloqueado o asignarlo a una regla incorrecta en ciertos casos, aunque el tráfico productivo fluya correctamente a través del firewall.

Para los administradores, es importante la consecuencia: si el Policy tester muestra un resultado inesperado, pero Log Viewer, el contador de reglas y Packet Capture confirman el flujo real de paquetes, no se deben cambiar inmediatamente las reglas de firewall o NAT. Primero se debe verificar si solo afecta a la visualización de diagnóstico.

Procedimiento práctico ante resultados contradictorios:

1. Documentar claramente la prueba con IP de origen, destino, servicio y usuario.
2. Filtrar en Log Viewer por IP de origen, IP de destino y servicio.
3. Verificar Rule ID y NAT Rule ID del registro real.
4. Iniciar Packet Capture con un filtro estrecho.
5. Comparar tráfico entrante, reenviado y de retorno.
6. Tratar el resultado del Policy tester solo como una indicación, no como prueba única.
7. Verificar la versión de firmware y los problemas conocidos de Sophos antes de cambiar reglas productivas.

Esta precaución es especialmente importante en ventanas de mantenimiento. Un resultado de diagnóstico incorrecto no debería llevar a reordenar reglas productivas que funcionan o a ajustar reglas NAT sin evidencia.

El Policy tester es especialmente bueno para:

• Política web
• Categorización de URL
• Contexto de usuario
• Programación
• Regla de inspección SSL/TLS
• Coincidencia de reglas de firewall para tráfico web

Es menos bueno para:

• decisiones de enrutamiento reales
• camino de retorno NAT
• pérdidas de paquetes
• problemas de proveedor o switch
• aplicaciones con múltiples conexiones y puertos

Paso 5: Usar Packet Capture

Si Log Viewer y Policy tester no son suficientes, se utiliza Diagnostics > Packet capture.

El filtro debe ser estrecho, por ejemplo:

• IP de origen del cliente
• IP de destino del servidor
• Puerto de destino
• Protocolo

Luego:

1. Iniciar Packet Capture.
2. Reproducir la prueba.
3. Detener Packet Capture.
4. Comparar eventos entrantes y reenviados.
5. Comparar Rule ID y NAT ID con Log Viewer.

Interpretación:

• No llega ningún paquete: verificar cliente, VLAN, switch, gateway, proveedor o Cloud Security Group.
• El paquete entra, pero no sale: verificar regla de firewall, NAT, routing o función de seguridad.
• El paquete sale, pero falta la respuesta: verificar ruta de retorno, sistema de destino, NAT o firewall externo.
• El paquete tiene estado Violation: verificar Policy, IPS, filtro web o Application Control.
• NAT ID es inesperado: verificar orden de NAT y reglas NAT genéricas.

Más información: Usar la herramienta Packet Capture en WebAdmin. Si se descartan paquetes, también es útil Analizar paquetes descartados en Sophos Firewall.

Leer Log Viewer y Packet Capture juntos

El Log Viewer muestra la decisión, Packet Capture muestra el flujo de paquetes. En la práctica a menudo se necesitan ambas vistas.

• Log Viewer muestra la Rule ID esperada, Packet Capture muestra Forwarded: la prueba de regla es plausible para el firewall. El camino de retorno y el sistema de destino se verifican por separado.
• Log Viewer muestra la Rule ID esperada, Packet Capture no muestra respuesta: revisar sistema de destino, ruta de retorno, NAT o firewall externo.
• Packet Capture muestra Incoming, pero no hay log adecuado: revisar logging, filtro de módulo, regla predeterminada, Device Access o análisis de Drop.
• Packet Capture muestra Consumed: el tráfico termina en el propio firewall. Revisar Device Access y Local Service ACL.
• Packet Capture muestra Violation: comparar Reason, Rule ID, NAT ID y módulo de seguridad con Log Viewer.

Si ambas herramientas parecen contradecirse, primero se debe estrechar el caso de prueba. Un solo cliente, un destino, un puerto y un momento de prueba corto son mejores que una captura amplia con mucho tráfico de fondo.

Usar filtros de Packet Capture estrechos

Packet Capture solo es útil si el filtro es lo suficientemente estrecho. Una captura demasiado amplia muestra rápidamente demasiado tráfico de fondo, especialmente en firewalls productivos con tráfico web, DNS, VPN o de servidor. Por lo tanto, el filtro debe derivarse del caso de prueba definido.

Ejemplos prácticos de BPF:

• Cliente único a un destino: host 172.16.10.25 and host 203.0.113.10, cuando se conocen origen y destino.
• Cliente a destino HTTPS: host 172.16.10.25 and port 443, cuando el destino puede cambiar por DNS o CDN.
• Solo tráfico saliente de un cliente: src host 172.16.10.25, cuando primero se verifica si el cliente está enviando.
• Solo tráfico de respuesta al cliente: dst host 172.16.10.25, cuando falta la ruta de retorno o los paquetes de respuesta.
• Prueba DNS: host 172.16.10.25 and port 53, cuando la resolución de nombres y la prueba de reglas deben verificarse por separado.
• Prueba ICMP: icmp and host 172.16.10.25, cuando un ping sirve como prueba simple de accesibilidad.

En pruebas de DNAT o VPN, se debe prestar especial atención a la dirección de la vista. Un filtro en la IP del servidor interno no muestra necesariamente el acceso original a la IP pública. Inversamente, un filtro en la IP pública no muestra automáticamente si el tráfico llega al servidor interno después de NAT. En tales casos, a menudo son más limpias dos capturas cortas: primero en el lado público, luego en el destino interno.

Después de la prueba, se debe detener inmediatamente la captura. Las capturas largas aumentan el riesgo de capturar datos innecesarios, nombres de host internos o conexiones ajenas.

Cuándo cambiar a tcpdump

El Packet Capture de WebAdmin es ideal para pruebas rápidas. Sin embargo, no es suficiente para todos los casos. Se debe cambiar a tcpdump si se cumple alguno de estos puntos:

• La captura debe ser evaluada como archivo PCAP en Wireshark o por soporte.
• La prueba dura más que una breve prueba de reproducción manual.
• Se necesitan filtros BPF muy precisos, por ejemplo, para VoIP, VPN, DNS o múltiples hosts.
• El búfer de WebAdmin se llena o solo muestra un fragmento.
• El tráfico relevante debe observarse en una interfaz específica durante un período prolongado.

También en tcpdump se aplica: establecer filtros estrechos, anotar el tiempo de prueba, mantener la captura corta y eliminar el archivo después de la transferencia. La guía práctica de CLI está en Sophos Firewall tcpdump: Capturar paquetes por CLI.

Paso 6: Validar características de seguridad individualmente

Si la regla correcta coincide, pero el tráfico no funciona, se deben verificar individualmente las características activadas.

• Web policy: revisar categoría, usuario, Schedule y orden de policies.
• Scan HTTP and decrypted HTTPS: HTTPS solo se escanea si ya está decrypted.
• SSL/TLS inspection: revisar regla adecuada, Decryption Profile y certificado CA en clientes.
• IPS: revisar firma, policy y posibles False Positives.
• Application Control: revisar aplicación detectada, categoría y Cloud App Detection.
• Security Heartbeat: comprobar si el endpoint envía Heartbeat y si el estado es verde, amarillo o rojo.
• Traffic Shaping: comprobar si la policy está activa y corresponde a la aplicación o regla correcta.
• NAT: revisar regla SNAT, DNAT o PAT correcta y el orden de reglas.

Para HTTPS: una regla de firewall con filtrado web no es suficiente para inspeccionar contenidos HTTPS. Se necesita además una SSL/TLS inspection rule adecuada con descifrado y certificado CA distribuido.

Más información: Implementar gradualmente la inspección TLS en Sophos Firewall. Para errores de NAT, es adecuado Entender NAT en Sophos Firewall, ya que una regla NAT no permite tráfico, solo traduce direcciones o puertos.

Paso 7: Verificar archivos de registro

Si las herramientas de WebAdmin no son suficientes, se deben verificar los archivos de registro adecuados.

Archivos típicos:

• Regla de firewall: firewall_rule.log
• NAT: nat_rule.log
• Conexiones de firewall: fwlog.log
• IPS y DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Qué archivo de log pertenece a cada módulo está resumido en Asignar correctamente los logs de servicio de Sophos Firewall.

En casos de soporte, un archivo de logs o CTR solo es realmente útil si el momento de prueba y las IDs esperadas están documentados. Un paquete de logs grande sin source, destination, puerto, usuario, Rule ID y NAT ID suele producir más preguntas.

Ejemplo: Probar regla web de LAN a WAN

1. Crear regla de firewall LAN_to_WAN_Clients.
2. Activar registro.
3. Configurar servicios en HTTP y HTTPS.
4. Seleccionar política web.
5. Dejar activado Block QUIC protocol.
6. Activar Scan HTTP and decrypted HTTPS.
7. Crear regla de inspección SSL/TLS para el grupo de prueba.
8. Instalar certificado CA en el cliente de prueba.
9. Restablecer contador de reglas.
10. Abrir sitio web.
11. Filtrar en Log Viewer por IP de origen.
12. Ejecutar Policy tester para la misma URL.
13. Iniciar Packet Capture en caso de discrepancia.

Así se puede ver si la regla coincide, si HTTPS realmente se descifra y si el filtro web, IPS o el control de aplicaciones intervienen.

Documentar el resultado de la prueba

Después de una prueba de regla, se debe documentar brevemente el resultado. Esto es especialmente importante si surge un caso de soporte, una ventana de mantenimiento o una limpieza de reglas posterior.

Es útil incluir:

• Fecha y hora de la prueba
• IP de origen, usuario, destino, servicio y URL o aplicación probada
• Rule ID esperada y realmente coincidente
• NAT Rule ID, si NAT está involucrado
• Acción en Log Viewer
• Captura de pantalla o exportación de Packet Capture, si el flujo de paquetes fue relevante
• Regla, política web, regla de inspección SSL/TLS o regla NAT modificada
• Punto abierto, si el comportamiento aún no está completamente explicado

En cambios productivos, también se debe anotar si la regla está destinada solo para un piloto, de forma permanente o como una solución temporal. Las reglas de prueba temporales deben tener una fecha de vencimiento o un propietario claro para que no queden como cargas heredadas en el conjunto de reglas.

Si la prueba de regla deriva en un caso de soporte, también se deben documentar archivo de logs, Packet Capture o PCAP de tcpdump, periodo afectado y causas ya descartadas. Para esta parte encaja Guardar registros de Sophos Firewall para soporte y análisis.

FAQ