Comprender y configurar de forma segura las reglas Sophos Firewall

Una regla de Sophos Firewall determina qué tráfico se permite o se bloquea entre zonas, redes, usuarios y servicios. Lo importante no es activar el mayor número posible de opciones, sino definir criterios de coincidencia adecuados, colocarlos en el orden correcto, aplicar las funciones de protección necesarias y realizar una prueba reproducible.

La ruta del menú es:

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

Este artículo explica el formulario de la regla de arriba abajo y utiliza en todo momento el ejemplo LAN_to_WAN_Clients. Los temas específicos, como NAT, TLS Inspection o IPS, se explican hasta donde resultan necesarios para la regla de firewall; las guías detalladas están enlazadas directamente en el punto correspondiente.

Planificar antes de crear la regla

Delimitar correctamente su función

Las reglas de firewall normales controlan el tráfico reenviado que atraviesa el firewall. Otras tareas se configuran en otros lugares:

• Servicios locales del firewall: WebAdmin, User Portal, VPN Portal, SSH, DNS y SNMP se controlan mediante Administration > Device access, Local Service ACL y la configuración del servicio correspondiente. Para ello se utiliza Device Access y Local Service ACL.
• Tráfico generado por el sistema: las conexiones que genera el propio firewall no necesitan una regla de firewall normal. Son determinantes la configuración del servicio, el enrutamiento, WAN Link Manager y, si corresponde, SD-WAN para System Traffic.
• Traducción de direcciones y puertos: NAT traduce el tráfico, pero no lo permite. La regla de firewall y la regla NAT deben coincidir.
• Enrutamiento y ruta de retorno: una regla de firewall coincidente no demuestra que el enrutamiento, SD-WAN, VPN o la ruta de retorno sean correctos.
• Lógica web: las categorías web, los grupos de URL y las acciones se definen en Web Policy. La regla de firewall vincula esa policy.
• Descifrado HTTPS: una SSL/TLS inspection rule descifra el tráfico. Scan HTTP and decrypted HTTPS solo analiza HTTPS que ya se ha descifrado.
• Identidad de usuario: AD SSO, STAS, Captive Portal, Entra ID SSO o RADIUS deben asignar primero el usuario al tráfico de forma fiable. Los dispositivos sin login pueden configurarse como Clientless Users si tienen una IP fija e inequívoca; esta asignación no es autenticación.

Los accesos de administración que pasan a través del firewall hacia servidores, switches o hipervisores sí pertenecen a reglas de firewall normales. El acceso al propio firewall, en cambio, se configura en Device Access.

Orden, IPv4 e IPv6

Sophos Firewall comprueba las reglas de arriba abajo. En cuanto todos los criterios de una regla coinciden, las reglas siguientes dejan de evaluarse. Por ello, una regla general LAN_to_WAN_Any situada encima de LAN_to_WAN_Restricted anula en la práctica la regla específica.

Una regla puede comprobar, entre otros criterios, Source zone, Source network, horario, Destination zone, Destination network, Service, usuario y Exclusions. Todos los criterios configurados deben coincidir con la conexión.

Las reglas MTA, IPsec o Hotspot creadas automáticamente pueden aparecer en la parte superior de la lista. Por eso, después de ejecutar asistentes, migraciones o cambios de VPN, se debe volver a comprobar el orden. En un hotspot de Sophos Firewall, esta comprobación forma expresamente parte del procedimiento de configuración. Si SFOS no encuentra ninguna regla coincidente, se aplica al final la regla implícita Drop-all con Firewall Rule ID #0. No muestra Usage Count; el tráfico descartado se registra como evento.

Las reglas IPv4 e IPv6 se administran por separado. Una regla IPv4 funcional no protege automáticamente el mismo servicio a través de IPv6. En entornos Dual Stack se deben planificar y probar de forma consciente ambos conjuntos de reglas.

Separar claramente las bases de reglas

Antes de crear una regla deben estar definidos Source, Destination, Services, Owner y el caso de prueba. Los riesgos diferentes no deben agruparse en una regla genérica:

• Internet para clientes: redes de clientes hacia la zona WAN, con una Web Policy adecuada, Application Control, IPS y registro.
• Internet para servidores: solo los destinos de actualización, copia de seguridad o cloud necesarios; normalmente sin relación con usuarios.
• Wi-Fi para invitados: zona Guest hacia Internet, sin destinos internos y, si es necesario, con límite de ancho de banda.
• Administración: redes de administración definidas hacia servidores e infraestructura, separadas del tráfico normal de clientes.
• Remote Access VPN: zona VPN hacia los destinos y servicios internos realmente necesarios.
• Site-to-Site: redes locales y remotas con enrutamiento, NAT y ruta de retorno adecuados.
• Sistemas publicados: WAN hacia DMZ o zona de servidores con un origen limitado, DNAT o WAF, IPS, registro y parches al día.
• Accesos temporales: regla propia con ticket, Owner, fecha de caducidad y retirada planificada.

Para estructurar las redes resulta útil Configurar zonas e interfaces de Sophos Firewall.

⚠️ Any puede ser útil para una prueba breve, pero rara vez constituye una buena configuración final. Después se debe limitar la regla a los orígenes, destinos y Services realmente necesarios o volver a eliminarla.

Ejemplo práctico LAN_to_WAN_Clients

En el ejemplo, los clientes de una LAN definida pueden acceder a Internet. Los servidores, invitados, VoIP y equipos de administración reciben reglas propias.

• Rule name: LAN_to_WAN_Clients
• Description: Acceso a Internet para la red de clientes. Webfilter, App Control e IPS activos. Owner IT, Review 2026-12-01.
• Rule position: Bottom; después, colocarla debajo de las reglas específicas de bloqueo y excepción
• Rule group: Internet Access
• Action: Accept
• Log firewall traffic: activado
• Source zones: LAN
• Source networks and devices: net_LAN_Clients
• During scheduled time: All the time
• Destination zones: WAN
• Destination networks: Any
• Services: HTTP, HTTPS y únicamente los servicios básicos que realmente se utilicen de forma directa en Internet
• Web policy: Default Workplace Policy
• Block QUIC protocol: activado
• IPS: policy de cliente adecuada
• App control: Application Policy de cliente adecuada
• Shape traffic: solo si existe un objetivo concreto de ancho de banda
• DSCP marking: solo si los dispositivos posteriores procesan el marcado

DNS y NTP solo deben formar parte de esta regla LAN-to-WAN si los clientes consultan directamente resolvers o servidores horarios externos. Si utilizan el firewall como servicio DNS o de hora, se trata de tráfico local.

La prueba de aceptación incluye un cliente definido, un destino concreto, la Firewall Rule ID esperada, la NAT Rule ID esperada y una comprobación en Log Viewer. Así no solo se verifica que la aplicación funciona, sino también que la procesan las reglas previstas.

Configurar la regla de firewall

Sección de cabecera

Rule status, Rule name y Description

Rule status está activado de forma predeterminada en las reglas nuevas. Las reglas preparadas pueden permanecer desactivadas hasta la ventana de mantenimiento. Las reglas de prueba o migración desactivadas de forma permanente se deben revisar periódicamente.

El nombre debe identificar Source, Destination y la finalidad, por ejemplo:

• LAN_to_WAN_Clients
• Guest_to_WAN_WebOnly
• Server_to_WAN_Updates
• VoIP_to_WAN_SIP_RTP
• WAN_to_DMZ_HTTPS_Webserver

La Description documenta la finalidad, el Owner, el ticket, las restricciones y, si corresponde, la fecha de caducidad. Nombres como Rule1, Allow o Internet apenas ayudan durante el funcionamiento posterior. El procedimiento específico se describe en Documentar correctamente las reglas de Sophos Firewall.

Rule position y Rule group

Al crear una regla, Rule position ofrece en SFOS 22 las opciones Top y Bottom. Después, la regla se puede mover en la tabla o colocar de forma precisa con Move To. Solo se debe elegir Top cuando una regla específica deba aplicarse deliberadamente antes que las existentes.

Rule group mejora la visibilidad, pero no modifica la lógica de coincidencia. None es el valor predeterminado. Con Automatic, SFOS asigna la regla a un grupo existente según el primer tipo de regla coincidente y las zonas Source/Destination. El firewall sigue evaluando cada regla de arriba abajo.

Action y registro

Action determina cómo se trata el tráfico coincidente:

• Accept: permite la conexión.
• Drop: normalmente la descarta sin responder. Si está activado Use web authentication for unknown users, SFOS puede mostrar una página de bloqueo para el tráfico web.
• Reject: la descarta y envía un Reset para TCP o una respuesta ICMP adecuada para UDP e ICMP.
• Protect with web server protection: crea una regla WAF. Esta opción solo está disponible para IPv4 y requiere Webserver Protection. La configuración corresponde funcionalmente a Sophos Firewall WAF.

Drop resulta adecuado para un descarte silencioso; Reject proporciona una respuesta reconocible con mayor rapidez durante pruebas internas o troubleshooting.

Log firewall traffic debe estar activado en las reglas importantes. Además, se deben activar los destinos locales, Sophos Central o Syslog correspondientes en System services > Log settings. Sin un evento Destroy, una sesión puede finalizar sin un registro de sesión, por ejemplo si la conexión se interrumpe bruscamente.

Para una conservación más prolongada se pueden utilizar Central Firewall Reporting o un servidor Syslog/SIEM. El registro no solo sirve para troubleshooting, sino también para la revisión: ¿qué orígenes alcanzan la regla, qué destinos se utilizan y sigue siendo apropiado el acceso?

La misma casilla es la fuente de datos para NetFlow v5 en Sophos Firewall: sin Log firewall traffic, NetFlow no exporta las conexiones de esta regla.

Source, Destination y Services

En el área Source se define de dónde procede el tráfico:

• Source zones: por ejemplo LAN, VPN, DMZ, Guest o WAN.
• Source networks and devices: hosts individuales, redes, rangos IP, grupos, FQDN Hosts u objetos de país.
• During scheduled time: All the time, horario laboral o una ventana de mantenimiento.

La zona por sí sola suele ser demasiado amplia. Por eso, en el ejemplo de clientes se combina LAN con net_LAN_Clients. En las reglas controladas por horario, la hora del firewall, la zona horaria y el Schedule deben coincidir.

Configurar horarios para reglas y políticas en Sophos Firewall muestra cómo crear y asignar franjas recurrentes o únicas y cómo probar sus límites de conmutación.

En Destination and services se encuentran:

• Destination zones: por ejemplo WAN, DMZ, LAN o VPN.
• Destination networks: Any, un host, una red, un grupo, un objeto de país o un FQDN Host.
• Services: definiciones de protocolo y puerto como HTTP, HTTPS, DNS, NTP o un Service propio.

La guía Utilizar correctamente hosts y servicios de Sophos Firewall explica cómo crear IP hosts, redes, rangos, listas, Services y grupos y cómo comprobarlos antes de modificarlos.

Any puede ser aceptable en una regla general de Internet para clientes. Las reglas de servidores, administración y VPN deben utilizar destinos y Services mucho más limitados. Para destinos cloud dinámicos pueden resultar útiles los FQDN Hosts y Wildcard FQDN.

Usuarios, Exclusions y Linked NAT

Match known users

Con Match known users, los usuarios o grupos pasan a ser criterios de coincidencia. Después, según la configuración, aparecen otros campos:

• Use web authentication for unknown users: redirige a los usuarios web desconocidos a AD SSO o Captive Portal. La autenticación y el acceso desde la zona afectada deben estar configurados previamente. Configurar y probar Captive Portal en Sophos Firewall muestra cómo interactúan la autenticación, Device Access, el requisito DNS y la regla de usuario.
• Users or groups: limita la regla a las identidades seleccionadas.
• Exclude this user activity from data accounting: excluye el tráfico de estos usuarios del registro individual de consumo de datos.

Una regla de usuario solo funciona con una asignación de usuarios fiable. Por debajo no debe existir una regla de fallback amplia que permita el mismo tráfico sin relación con usuarios. Durante la prueba de aceptación, el usuario, el grupo y la Rule ID deben coincidir en Log Viewer.

Add exclusion

Add exclusion excluye tráfico de esta regla. SFOS solo omite la regla si coinciden conjuntamente todos los criterios de Exclusion configurados y después comprueba la regla siguiente.

Como criterios están disponibles Source zones, Source networks and devices, Destination zones, Destination networks y Services.

Una excepción razonable sería un servidor de actualizaciones que se excluye de una regla general de clientes y recibe encima una regla propia con otras funciones de protección. Si las Exclusions se vuelven numerosas o difíciles de entender, suele ser mejor crear una regla específica aparte.

Create linked NAT rule

Una Linked NAT Rule es una regla Source NAT que solo se aplica al tráfico de la regla de firewall vinculada. En la regla NAT se pueden definir principalmente la Source traducida y la Source Translation específica de la interfaz.

La configuración de fábrica suele incluir una regla Default SNAT con MASQ. Antes de añadir una Linked NAT Rule se debe comprobar si dicha regla ya cubre correctamente el tráfico. Si coincide una regla NAT independiente situada más arriba, tendrá prioridad sobre la Linked NAT Rule.

Con DNAT, SFOS determina primero el destino traducido y después utiliza su zona para la coincidencia con la regla de firewall. Por eso, un reenvío de puertos hacia un servidor en la DMZ suele necesitar Destination zone DMZ en la regla de firewall, aunque el cliente se conecte a la dirección WAN pública.

Ante una NAT Rule ID inesperada, también se debe comprobar el orden en Rules and policies > NAT rules. Después de modificar NAT hay que crear una conexión nueva, ya que las sesiones existentes no vuelven a evaluarse. NAT no permite tráfico por sí solo: la regla de firewall decide entre Allow y Drop; NAT traduce direcciones o puertos. Los detalles se explican en Comprender NAT en Sophos Firewall.

Seleccionar las funciones de protección

No todas las opciones están disponibles con la Base License. Antes del despliegue se debe comprobar en Administration > Licensing:

• Reglas de firewall normales: Base License
• IPS y Security Heartbeat: Network Protection
• Web Security, Application Control y protección web antimalware: Web Protection
• Sandboxing y análisis de archivos: Zero-Day Protection
• Protección de correo: Email Protection
• WAF: Webserver Protection
• NDR Active threat intelligence: Xstream Protection Bundle

Standard Protection y Xstream Protection incluyen Web Protection. El bundle Avanet Epic Protection también incluye Web Protection. La clasificación completa está disponible en Comparar bundles de licencias de Sophos Firewall.

Web Filtering

Web policy vincula una Web Policy con categorías, grupos de URL, usuarios y acciones. Sin una Web Policy no existe control web basado en categorías mediante este campo. La policy se crea y se prueba en Web Protection.

Apply web category-based traffic shaping utiliza los valores de ancho de banda de las categorías web. La opción solo tiene sentido si se han configurado realmente límites o garantías en ellas.

Block QUIC protocol bloquea para la regla el tráfico UDP saliente en los puertos 80 y 443. QUIC no se puede analizar como tráfico HTTP/HTTPS normal y elude Web Filtering. SFOS activa esta opción de forma predeterminada cuando se selecciona una Web Policy o el análisis antimalware. Más información en Bloquear QUIC y HTTP/3.

Scan HTTP and decrypted HTTPS analiza HTTP y HTTPS ya descifrado en busca de malware. La opción no activa el descifrado. Para ello se necesita una SSL/TLS inspection rule adecuada en Rules and policies > SSL/TLS inspection rules.

Use Zero-day protection envía las descargas sospechosas a un análisis adicional después del análisis antimalware. La función requiere Zero-Day Protection y, según el tipo de archivo y la policy, puede causar un retraso.

Scan FTP for malware solo es necesario si la regla permite FTP. En sistemas Legacy, el análisis se debe probar por separado.

Use web proxy instead of DPI engine limita el Proxy Filtering a los puertos habituales 80 y 443. Web Proxy se necesita, entre otros casos, para SafeSearch, restricciones de YouTube, restricciones de dominio de Google Workspace, Pharming Protection, Web Cache o Parent Proxy. En modo DPI, las SSL/TLS inspection rules se aplican a HTTP y TLS en todos los puertos.

Configurar un upstream proxy en Sophos Firewall describe la cadena adicional de reglas y NAT para un parent proxy. Un proxy en WAN requiere una ruta distinta de otro en LAN o DMZ.

En cambio, un cliente Direct Web Proxy configurado explícitamente utiliza el listener incluso sin esta opción. Configurar Direct Web Proxy con un archivo PAC explica la configuración completa con puerto, Device Access, archivo PAC, regla y pruebas.

Decrypt HTTPS during web proxy filtering pertenece al modo Web Proxy. En modo DPI, el descifrado se controla mediante SSL/TLS inspection rules. Las Web Exceptions pueden omitir Decryption, análisis antimalware, Zero-Day Protection y Policy Checks, por lo que se deben limitar estrictamente y revisar periódicamente.

Synchronized Security Heartbeat

Las reglas Heartbeat requieren:

• un firewall registrado en la misma cuenta de Sophos Central con Security Heartbeat activado;
• un Sophos Endpoint administrado con licencia Trial o completa;
• Network Protection en el firewall.

Para detectar Heartbeats ausentes, se deben seleccionar las zonas afectadas en System > Sophos Central > Optional configurations > Missing heartbeat zones.

Con Minimum source HB permitted y Minimum destination HB permitted se exige un estado de salud mínimo. Destination Heartbeat solo resulta apropiado para destinos internos, no para la zona WAN.

Las opciones Block clients with no heartbeat y Block request to destination with no heartbeat controlan los dispositivos sin Heartbeat. Un dispositivo que nunca ha enviado un Heartbeat permanece permitido de forma predeterminada y solo se bloquea cuando ambas opciones están activadas. Esto se debe probar expresamente con dispositivos sin Sophos Endpoint.

Una Web Exception que omita Policy checks puede permitir solicitudes web a pesar de Block clients with no heartbeat. El procedimiento práctico de comprobación está en Analizar alertas de Security Heartbeat ausente.

Application Control, IPS y Traffic Shaping

Identify and control applications (App control) vincula una Application Filter Policy. Application Control requiere Web Protection. Para Micro Apps basadas en URL dentro de tráfico cifrado, como cargas y descargas de archivos en Dropbox o Gmail, se necesita una SSL/TLS inspection rule adecuada que descifre el tráfico. La configuración de filtros, registros y False Positives se explica en Configurar Application Control.

Apply application-based traffic shaping policy utiliza la policy de ancho de banda asignada a una aplicación o categoría en Applications > Traffic shaping default. En cambio, los Application Objects están destinados a las rutas SD-WAN. Una Rules Policy seleccionada mediante Shape traffic controla todo el tráfico de la regla de firewall. Sophos no documenta de forma uniforme la prioridad cuando se combinan Application Policy y Rules Policy; para mantener un diseño comprensible se debe utilizar una sola variante por caso de uso y probar cualquier combinación necesaria en el build SFOS utilizado.

Detect and prevent exploits (IPS) vincula una IPS Policy. IPS requiere Network Protection o una licencia Trial válida y debe estar activado globalmente en Intrusion prevention > IPS policies. El tráfico de clientes, servidores, webservers y VoIP necesita policies diferentes y probadas. El despliegue seguro se describe en Configurar y probar IPS.

Shape traffic asigna una Traffic Shaping Policy a toda la regla, por ejemplo para VoIP, reuniones, copias de seguridad o invitados. Las garantías y los límites deben corresponderse con el ancho de banda WAN disponible. Más información: Configurar Application Traffic Shaping.

DSCP marking marca los paquetes para switches, routers o dispositivos WAN posteriores. El marcado por sí solo no prioriza nada; todos los dispositivos implicados deben tratar de forma coherente los valores DSCP elegidos.

NDR Active threat intelligence

Scan with NDR Active threat intelligence comprueba el tráfico con firmas NDR seleccionadas. La acción está fijada en Log threats: la función detecta y registra los eventos, pero no bloquea el tráfico.

Los requisitos son:

• Xstream Protection Bundle;
• activación global de NDR Active threat intelligence;
• registro IPS activado;
• selección de la opción en cada regla de firewall pertinente.

Se admiten dispositivos XGS, despliegues virtuales, de software y habituales en el cloud, pero no XGS 87, 87w, 88 ni 88w. XDR o MDR y la transferencia a Sophos Central son opcionales para el análisis avanzado en Central.

Scan email content

En Scan email content se pueden seleccionar IMAP, IMAPS, POP3, POP3S, SMTP y SMTPS. La protección requiere Email Protection. Si faltan los puertos estándar en Services, se pueden añadir mediante Add ports.

El tráfico de correo no debe quedar oculto en una regla general de Internet para clientes. Una regla de correo propia deja más claros Source, Destination, protocolos, registro y funciones de protección.

Probar y operar la regla

Prueba de aceptación después de guardar

Después de guardar, la regla solo está terminada cuando el caso de prueba definido ofrece los resultados esperados:

En cada prueba solo se debe realizar un cambio para poder relacionar causa y efecto.

1. Comprobar la posición de la regla y Rule group.
2. Comprobar Log firewall traffic y los destinos en System services > Log settings.
3. Generar exactamente una conexión de prueba con un cliente, destino y Service definidos.
4. Comprobar Firewall Rule ID, Rule name, usuario y Action en Log Viewer.
5. Comprobar NAT Rule ID y las direcciones traducidas.
6. Verificar DNS y enrutamiento por separado.
7. Comprobar Web Policy, Application Control, IPS y TLS Inspection según la acción esperada.
8. Vigilar Drops inesperados, errores SSL/TLS o problemas de rendimiento.
9. Retirar la regla de prueba o limitarla a los objetos de producción.

Para Policy Test, Log Viewer y Packet Capture existe el procedimiento específico Probar una regla de Sophos Firewall.

Regla nueva, regla existente o desactivación

Una regla existente se puede ampliar si Source, Destination, finalidad, Owner y requisitos de protección permanecen iguales. Es preferible una regla propia cuando difieren el registro, la fecha de caducidad, las Security Features, los responsables o el ciclo de revisión.

El acceso temporal de soporte, servidores, invitados, VoIP, IoT y administración no deben desaparecer dentro de una regla general de clientes. En reglas antiguas poco claras suele ser más seguro desactivar de forma controlada que eliminar inmediatamente:

1. Aclarar la finalidad, el Owner y las dependencias.
2. Definir el registro y la ventana de prueba.
3. Informar a los equipos afectados.
4. Desactivar la regla y ejecutar pruebas definidas.
5. Eliminarla solo después de una observación verificable.

Una regla de emergencia de uso infrecuente puede ser importante. A la inversa, una regla general utilizada con frecuencia no es automáticamente segura.

Contador de datos, revisión y registro de cambios

Reset data transfer count restablece el contador de datos transferidos de una regla. No es un contador de sesiones ni de coincidencias. El estado Unused solo indica que no se encontró tráfico coincidente durante las últimas 24 horas. Ambos indicadores se deben evaluar junto con los registros, la descripción de la regla y el caso de uso. Para analizar los datos transferidos también se puede utilizar Reports > Dashboards > Traffic dashboard > Allowed policies.

Las revisiones periódicas comprueban como mínimo:

• Source, Destination y Services;
• objetos Any restantes;
• Owner, ticket y fecha de caducidad;
• registro y uso real;
• NAT, Web Policy, IPS, TLS Inspection y otras funciones de protección;
• reglas desactivadas, temporales y creadas automáticamente.

Antes de realizar cambios importantes debe existir una copia de seguridad. Audit Trail Logs y Config Studio muestran los cambios de configuración; en grupos administrados desde Central, Firewall Management Task Queue confirma si el cambio ha llegado al appliance correcto. Firewall Health Check complementa la revisión periódica de seguridad.

Errores típicos

• La regla esperada no se aplica o aparece Rule ID #0: comprobar el orden, IPv4/IPv6 y todos los criterios Source, Destination, Service, usuario y Exclusion.
• La Firewall Rule ID es correcta, pero NAT Rule ID o la ruta del paquete no: comprobar el orden NAT, el enrutamiento, SD-WAN y la ruta de retorno.
• La regla se aplica, pero no protege o la aplicación deja de funcionar: comprobar por separado la licencia, la activación global, el registro, Web Policy, QUIC, TLS Inspection, IPS y Traffic Shaping Policy.

Si Rule ID, NAT ID o la ruta del paquete son inesperados, La regla de Sophos Firewall no se aplica ayuda a identificar la causa de forma estructurada.