Entender y configurar reglas Sophos Firewall

Las Firewall Rules son el núcleo de Sophos Firewall. Deciden qué tráfico entre zonas, redes, usuarios y servicios se permite o se bloquea, y qué funciones de protección se aplican.

Este artículo explica una Sophos Firewall Rule de arriba abajo: orden, grupos, Action, logging, Source, Destination, Services, User Matching, Exclusions, NAT, Web Filtering, TLS Inspection, Security Heartbeat, Application Control, IPS, Traffic Shaping, DSCP, NDR y escaneo de correo.

La ruta de menú es:

Rules and policies > Firewall rules > Add firewall rule > New firewall rule

Navegación rápida

• Principio básico y orden
• Ejemplo práctico
• Cabecera: estado, nombre, acción y logging
• Source
• Destination and services
• Match known users
• Add exclusion
• Create linked NAT rule
• Web filtering
• Synchronized Security Heartbeat
• Other security features
• Scan email content
• Comprobar después de guardar
• Errores comunes

Principio básico y orden

Las Firewall Rules controlan el tráfico entre zonas y redes. Pueden permitir, descartar o bloquear tráfico y aplicar Security Features adicionales.

Sophos Firewall comprueba las Firewall Rules de arriba abajo. En cuanto una regla coincide, las reglas siguientes ya no se comprueban. Por eso no solo importa qué contiene una regla, sino también dónde está colocada en la lista.

Una regla solo coincide si todos los criterios relevantes coinciden al mismo tiempo:

La primera regla que coincide gana. Si una regla general LAN_to_WAN_Any está por encima de una regla más específica LAN_to_WAN_Restricted, la regla específica nunca se alcanza.

Ejemplo práctico

En este ejemplo se crea una regla de clientes limpia:

Objetivo: los clientes del LAN interno pueden acceder a Internet. Web Filtering, Application Control, IPS y logging deben estar activos. Servidores, invitados y redes de management tienen sus propias reglas y no se mezclan con esta regla de clientes.

Este ejemplo no es deliberadamente un pase libre Any. En la práctica conviene tratar por separado redes de clientes, servidores, Wi-Fi de invitados, VoIP y management.

Cabecera: estado, nombre, acción y logging

Rule status

Rule status activa o desactiva la regla.

Una regla nueva normalmente está activa. Para reglas preparadas se puede desactivar el estado y activarlas más tarde. Las reglas desactivadas deben revisarse regularmente para que no queden reglas antiguas de prueba o migración en la configuración.

Ejemplo práctico: una nueva regla para un servidor se prepara, pero solo se activa durante una ventana de mantenimiento.

Rule name

El nombre debe dejar claro inmediatamente qué hace la regla.

Buenos nombres:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

Nombres como Rule1, Test, Allow o Internet son menos útiles porque más tarde ya no se reconoce la función de la regla.

Description

La descripción es importante para operación, soporte y auditorías. Debe indicar:

• por qué existe la regla
• quién solicitó la regla
• qué restricciones se definieron conscientemente
• si hay un ticket, proyecto o fecha de caducidad

Ejemplo:

Internet Access for client network 10.10.10.0/24. Web filtering and IPS enabled. Requested by IT, reviewed on 10 June 2026.

El artículo Cómo documentar fácilmente una regla Sophos Firewall explica con más detalle cómo usar este campo correctamente y documentar Firewall Rules de forma trazable.

Rule position

Rule position define dónde se inserta la nueva regla.

Regla básica: lo específico antes de lo general. Una regla para un servidor individual o una aplicación concreta suele estar por encima de una regla general de Internet.

Rule group

Rule group es una agrupación organizativa. El grupo no es un límite de seguridad ni un motor de policy separado. La firewall sigue comprobando las reglas individuales de arriba abajo.

Grupos útiles:

• Internet Access
• Server Rules
• DNAT
• VPN
• Guest
• Management
• Block Rules

En entornos pequeños, None puede ser suficiente. En entornos más grandes, conviene agrupar desde el principio porque la base de reglas se vuelve rápidamente difícil de leer.

Action

Action determina qué ocurre con el tráfico que coincide.

Para reglas normales de clientes o servidores se usa casi siempre Accept. Para reglas de bloqueo, Drop es más silencioso; Reject suele ser más cómodo para troubleshooting.

Log firewall traffic

Log firewall traffic debería estar activado en casi todas las reglas importantes.

Sin logging faltan después datos importantes en Log viewer. Muchos casos de troubleshooting fallan no por la regla en sí, sino porque no se activó logging y no se ve qué regla coincidió realmente.

Importante: la firewall suele registrar sesiones cuando una conexión termina y se genera un evento Destroy. No todas las conexiones aparecen exactamente en el momento en que el cliente las inicia.

Para que los logs sean visibles localmente, en Sophos Central o por syslog, System services > Log settings también debe estar configurado correctamente. Para una conservación más larga, Sophos Central Firewall Reporting o un servidor syslog es recomendable. Más información: Activar Central Firewall Reporting.

Source

La sección Source define de dónde viene el tráfico.

Source zones

Source zones es la zona de origen.

Ejemplos:

• LAN para redes internas de clientes
• VPN para usuarios Remote Access
• DMZ para redes de servidores
• Guest para Wi-Fi de invitados
• WAN para tráfico entrante desde Internet

Ejemplo práctico: para una regla de clientes hacia Internet se selecciona LAN. Para una regla DNAT desde fuera hacia un servidor interno, la regla Firewall asociada suele usar WAN como Source zone.

Source networks and devices

Source networks and devices limita el origen con más precisión.

Objetos posibles:

• hosts individuales
• redes
• IP ranges
• grupos de hosts
• FQDN Hosts
• objetos de país

Al principio Any parece cómodo, pero suele ser demasiado amplio. Es mejor un segmento de clientes concreto, un grupo de hosts o un objeto de red claramente nombrado.

Ejemplo práctico: en lugar de Any como Source se usa net_LAN_Clients. Servidores, impresoras, invitados y dispositivos de management tienen sus propias reglas.

During scheduled time

During scheduled time determina cuándo se aplica la regla.

Valores típicos:

• All the time
• horario laboral
• ventanas de mantenimiento
• accesos temporales

Los schedules son útiles cuando un acceso solo debe permitirse en ciertos momentos. En troubleshooting hay que comprobar siempre si la hora de la firewall, la zona horaria y el schedule encajan realmente.

Ejemplo práctico: un acceso externo de mantenimiento a un servidor solo se permite durante una ventana definida.

Destination and services

La sección Destination and services define adónde puede ir el tráfico y qué puertos o protocolos están permitidos.

Destination zones

Destination zones es la zona de destino.

Ejemplos:

• WAN para acceso a Internet
• DMZ para servidores en una DMZ
• LAN para destinos internos
• VPN para usuarios remotos o túneles Site-to-Site

Ejemplo práctico: para tráfico de clientes a Internet se usa WAN. Para acceso de clientes a un servidor interno se puede usar Server o DMZ, si estas zonas existen.

Destination networks

Destination networks limita el destino.

Para reglas de clientes hacia Internet, Any suele ser un punto de partida práctico. Para servidores, redes de management o accesos VPN, los destinos deben limitarse mucho más.

Ejemplos:

• Any para acceso general a Internet
• FQDN Host como updates.vendor.com
• objeto host de un servidor interno
• objeto de red de una sede remota por VPN
• objeto de país para reglas Geo-IP

Ejemplo práctico: un servidor de backup solo puede acceder a los destinos cloud backup del fabricante, no a Any.

Services

Services son definiciones de protocolo y puerto.

Ejemplos:

• HTTP para TCP 80
• HTTPS para TCP 443
• DNS para TCP/UDP 53
• NTP para UDP 123
• servicios propios como Synology_5555

Los services deben elegirse lo más estrechos posible. Any solo tiene sentido si realmente deben permitirse todos los protocolos o si se trabaja conscientemente con otros controles.

Ejemplo práctico: para clientes web normales suele bastar un grupo con HTTP, HTTPS, DNS y NTP. Para acceso a un servidor desde Internet solo se permite el servicio publicado realmente.

Match known users

Con Match known users, la identidad de usuario forma parte del matching. La regla ya no aplica solo por direcciones IP, sino por usuarios o grupos conocidos.

Esto tiene sentido cuando:

• las Web Policies deben aplicarse por grupo AD
• el reporting debe ser por usuario
• distintos grupos necesitan permisos de Internet diferentes
• MFA, Captive Portal o SSO ya están bien configurados

Problema típico: si la autenticación no funciona correctamente, la regla quizá no coincida. El tráfico cae entonces en una regla más general debajo o se descarta por la regla drop-all.

Para primeras pruebas, suele ser mejor empezar sin User Matching y añadir criterios de usuario más tarde.

Add exclusion

Con Add exclusion se puede excluir tráfico de una regla. La firewall solo salta esta regla si todos los criterios de exclusión definidos coinciden, y después comprueba la siguiente regla.

Las exclusions pueden contener Source zones, Source networks and devices, Destination zones, Destination networks y Services.

Ejemplo práctico: una regla general de Internet para clientes usa Web Filtering. Un servidor de actualización concreto debe pasar por una regla propia con otros Security Features. Entonces se puede excluir ese servidor de la regla general.

Las exclusions son potentes, pero hacen las reglas más difíciles de leer. Si una regla tiene muchas excepciones, una regla específica separada suele ser más comprensible.

Create linked NAT rule

Con Create linked NAT rule se puede crear una regla Source NAT directamente desde la Firewall Rule. Esta Linked NAT Rule aparece después en la tabla NAT.

Para principiantes parece cómodo, pero en la práctica las reglas NAT independientes suelen ser más claras. Si una regla NAT genérica ya cubre bien el mismo tráfico, no debería crearse una Linked NAT Rule adicional.

Para una regla normal de cliente a Internet suele bastar la regla SNAT por defecto con MASQ, siempre que esté activa y encaje con la base de reglas.

Importante: NAT no permite tráfico por sí solo. NAT traduce direcciones o puertos. Si el tráfico se permite lo decide siempre la Firewall Rule correspondiente.

Más información: Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Web filtering

En Web filtering se configuran Web Policy, Malware Scan y el comportamiento del filtrado web.

Web policy

Web policy controla accesos web mediante categorías, usuarios, grupos, URL groups y reglas.

Ejemplo práctico: para clientes se usa una Web Policy que bloquea malware, phishing, adult content y categorías de riesgo, pero permite aplicaciones de negocio.

Si no se define ninguna Web Policy, no se aplica filtrado web por categorías mediante esta opción.

Apply web category-based traffic shaping

Esta opción aplica Traffic Shaping en función de categorías web. Solo es útil si se usan reglas Traffic Shaping o Web Category Policies adecuadas.

Ejemplo práctico: se limitan categorías de streaming y se priorizan aplicaciones de negocio.

Block QUIC protocol

QUIC usa UDP 80 y UDP 443. Muchos navegadores usan QUIC para servicios de Google y otras aplicaciones web modernas.

Si Web Filtering o Malware Scan para tráfico web es importante, Block QUIC protocol debería quedar activado en muchos entornos. Los navegadores suelen volver a HTTPS normal sobre TCP, que es más fácil de controlar e inspeccionar.

Scan HTTP and decrypted HTTPS

Esta opción escanea HTTP y HTTPS ya descifrado en busca de malware.

Importante: esta opción no descifra HTTPS automáticamente. Para inspeccionar HTTPS realmente se necesitan SSL/TLS inspection rules adecuadas en Rules and policies > SSL/TLS inspection rules.

Ejemplo práctico: si TLS Inspection está activa para LAN_to_WAN_Clients, Scan HTTP and decrypted HTTPS puede comprobar archivos descargados dentro del tráfico HTTPS descifrado.

Más información: Desplegar TLS Inspection en Sophos Firewall paso a paso.

Use Zero-day protection

Use Zero-day protection envía descargas sospechosas a Sophos Zero-Day Protection para análisis adicional. Es útil para reglas de clientes y servidores donde se deben analizar descargas desde Internet.

La función requiere una licencia adecuada y puede provocar retrasos según el tipo de archivo y la policy.

Scan FTP for malware

Esta opción escanea tráfico FTP en busca de malware. Solo es relevante si FTP se usa realmente y los servicios adecuados están permitidos en la regla.

FTP es menos común en entornos modernos, pero aún aparece en sistemas legacy, control de máquinas o mecanismos de actualización antiguos.

Use web proxy instead of DPI engine

Sophos Firewall puede inspeccionar tráfico web mediante DPI engine o mediante Web Proxy.

En configuraciones modernas, DPI suele ser la mejor opción por defecto porque puede procesar tráfico HTTP y SSL/TLS en todos los puertos. Web Proxy sigue siendo útil cuando se necesitan funciones proxy específicas, como SafeSearch enforcement, restricciones de YouTube, limitación de Google app domain, Pharming Protection, Web Cache o Parent Proxy.

Si Use web proxy instead of DPI engine no está activado, la regla trabaja en modo DPI.

Decrypt HTTPS during web proxy filtering

Esta opción pertenece al modo Web Proxy. Solo es relevante si Use web proxy instead of DPI engine está activado y HTTPS debe descifrarse en modo proxy.

En modo DPI, el descifrado HTTPS no se controla aquí, sino mediante SSL/TLS inspection rules.

Synchronized Security Heartbeat

Con Configure Synchronized Security Heartbeat, el estado de Sophos Endpoint puede incluirse en la Firewall Rule.

Opciones típicas:

• definir estado mínimo para dispositivos origen
• bloquear clientes sin Heartbeat
• definir estado mínimo para dispositivos destino
• bloquear solicitudes a destinos sin Heartbeat

Es potente, pero solo tiene sentido si Sophos Endpoint, Sophos Central y Security Heartbeat están bien configurados.

Ejemplo práctico: clientes con Security Heartbeat rojo ya no pueden acceder a servidores o a Internet.

Para una primera regla de clientes no conviene activar Heartbeat a ciegas; de lo contrario se pueden bloquear dispositivos que no pueden enviar Heartbeat.

Other security features

Identify and control applications (App control)

Mediante Identify and control applications (App control) se selecciona una Application Filter Policy.

Permite detectar y controlar aplicaciones como:

• TeamViewer
• Tor
• Messenger
• Streaming
• Cloud Storage
• Remote-Control-Tools

Application Control requiere una licencia adecuada. En la práctica, esta función está incluida en Sophos Firewall Bundles con Web Protection, por ejemplo Standard Protection, Xstream Protection o Epic Protection.

Para detectar aplicaciones en tráfico cifrado, TLS Inspection suele ser decisiva. Sin decryption, la firewall solo ve, según el servicio, hostnames, SNI, información de certificados o IPs, pero no el contenido completo.

Apply application-based traffic shaping policy

Esta opción aplica Traffic Shaping definido en la Application Policy o en el Application Object.

Ejemplo práctico: Microsoft Teams debe detectarse y priorizarse con una Traffic Shaping Policy concreta. Debe seleccionarse la Application Control Policy adecuada y aplicarse la application-based traffic shaping policy.

Si en Shape traffic ya se define una Traffic Shaping Policy explícita, debe documentarse claramente qué policy debe prevalecer y por qué.

Detect and prevent exploits (IPS)

En Detect and prevent exploits (IPS) se selecciona una IPS Policy.

IPS comprueba el tráfico frente a patrones de ataque y exploits conocidos. Para tráfico de clientes hacia Internet se usa una policy distinta que para tráfico de servidores o servicios publicados.

Ejemplos prácticos:

• regla de clientes LAN_to_WAN: IPS policy de clientes o LAN-to-WAN
• regla DNAT hacia servidor web: IPS policy de servidor o webserver
• regla VoIP: probar con cuidado, porque perfiles IPS agresivos pueden afectar VoIP

IPS no debe activarse en todas partes con la policy más estricta. Una IPS Policy demasiado amplia o incorrecta puede romper tráfico legítimo o generar carga innecesaria.

Shape traffic

Con Shape traffic se puede aplicar una Traffic Shaping Policy directamente a la regla.

Es relevante para:

• VoIP
• videoconferencias
• tráfico de backup
• Wi-Fi de invitados
• enlaces WAN lentos

Ejemplo práctico: el Wi-Fi de invitados recibe una limit policy para no desplazar el tráfico de negocio.

Más información: Configurar Application Traffic Shaping en Sophos Firewall.

DSCP marking

DSCP marking marca paquetes para Quality of Service en dispositivos de red posteriores.

Solo tiene sentido si switches, routers o dispositivos WAN también evalúan esos valores DSCP. Sophos Firewall puede marcar, pero el resto de la red debe tratar esas marcas de forma consistente.

Ejemplo práctico: el tráfico VoIP recibe una marca DSCP para que switches y routers WAN lo prioricen.

Scan with NDR Active threat intelligence

Scan with NDR Active threat intelligence usa Sophos NDR Threat Intelligence para una evaluación adicional del tráfico de red.

Esta opción solo tiene sentido si el entorno utiliza los componentes necesarios de Sophos Central y NDR. En muchos entornos no es la primera opción para una regla básica, pero puede aportar valor en redes con mayor monitorización.

Scan email content

La sección Scan email content se aplica a protocolos de correo.

Opciones posibles:

• Scan IMAP
• Scan IMAPS
• Scan POP3
• Scan POP3S
• Scan SMTP
• Scan SMTPS

Si se activan protocolos aquí, los puertos estándar correspondientes también deben estar incluidos en los Services de la regla o añadirse mediante Add ports.

Para reglas web normales de clientes, esta sección no suele ser relevante. Para servidores de correo o tráfico mail de clientes, debe planificarse conscientemente.

Ejemplo práctico: un servidor de correo interno puede enviar SMTP hacia fuera. Se crea una regla de servidor separada, se activa logging y se comprueba el escaneo de correo según la arquitectura mail.

Comprobar después de guardar

Después de guardar, conviene probar la regla y no asumir que todo funciona.

Comprobar:

1. ¿Está la regla en la posición correcta?
2. ¿Está activo Log firewall traffic?
3. ¿Coincide la regla en Log viewer?
4. ¿Se muestra la Firewall Rule ID esperada?
5. ¿Se aplica la regla NAT esperada?
6. ¿Funciona DNS?
7. ¿Se aplican Web Filtering, IPS, Application Control y TLS Inspection como se esperaba?
8. ¿Hay drops o errores SSL/TLS inesperados?

Para una prueba limpia ayuda el artículo Probar Firewall Rules con Log Viewer, Policy Test y Packet Capture.

Errores comunes

La regla está demasiado abajo: una regla más general por encima coincide primero con el tráfico.

Source es demasiado amplio: Any puede funcionar, pero hace que las reglas sean poco claras y aumenta la superficie de ataque.

Destination es demasiado amplio: servidores o redes de management rara vez deberían poder salir a Internet con Any.

Services es demasiado amplio: Any permite mucho más de lo necesario. Mejor servicios concretos o grupos de servicios.

Logging no está activo: faltan entonces los datos más importantes en Log Viewer.

HTTPS no se escanea: Scan HTTP and decrypted HTTPS está activo, pero no hay SSL/TLS inspection rule adecuada o no hay decryption.

Web Filtering no aplica: no hay Web Policy, usuario incorrecto, Source zone incorrecta o QUIC no bloqueado.

User Matching no aplica: autenticación, AD SSO, Captive Portal o asignación de usuario no funcionan correctamente.

Falta NAT: la Firewall Rule permite el tráfico, pero SNAT/MASQ no coincide.

Security Feature no encaja con el tráfico: una IPS Policy, opción proxy u opción de escaneo de correo incorrecta puede romper tráfico legítimo.