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. El Server Access Assistant también crea una regla de firewall junto con DNAT, reflexive SNAT y Loopback. 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; la guía de DNAT para servidores publicados explica el Server Access Assistant.

⚠️ Antes de crear la regla Drop con registro: No se debe asumir que conserva el bloqueo existente de HTTP/HTTPS: la documentación sobre Drop, autenticación, Web Exceptions y páginas de bloqueo es contradictoria. Para cualquier tráfico web, antes del despliegue en producción se requiere una aclaración escrita de Sophos para la versión, el build y la ruta de procesamiento exactos de SFOS, o una verificación aislada y expresamente autorizada. Seguir las indicaciones de verificación, reversión y escalamiento de Action y registro, más abajo.

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 ni genera una entrada normal en el registro de tráfico del firewall. Para que estos descartes aparezcan en Log Viewer, Central Reporting o syslog, se crea al final de la base de reglas una regla Drop de alcance limitado con Log firewall traffic activado. Para ello, se seleccionan por separado las Source zones y Destination zones realmente necesarias en lugar de la zona Any; de lo contrario, la regla también puede registrar tráfico interno dirigido a servicios locales. Los detalles se explican en Analizar paquetes descartados en Sophos Firewall.

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. Un grupo no puede quedar vacío. La ayuda de SFOS 22 indica que primero hay que separar una regla con Detach para moverla fuera del grupo; como alternativa, se mueve el grupo completo. Al eliminar la última regla también se elimina el grupo.

La ayuda de SFOS 23 describe otro procedimiento: para una búsqueda filtrada, hacer clic en el campo de búsqueda, seleccionar un criterio sugerido y completar la búsqueda con las sugerencias adicionales. Pulsar Enter para filtrar la tabla de reglas. Para buscar por nombre de regla, escribirlo directamente en el campo de búsqueda y pulsar Enter; quitar filtros individuales con x. Con Show/Hide columns se seleccionan las columnas visibles, se cambia su orden haciendo clic y arrastrando y se fijan hasta tres columnas para que siempre aparezcan primero. Activar o desactivar mediante Status o en bloque con Turn on / Turn off; una selección que mezcla reglas activadas y desactivadas impide esa acción en bloque. Las reglas desactivadas aparecen atenuadas y con el nombre tachado. Arrastrar una regla al menos una posición fuera de su grupo elimina su pertenencia; colocarla entre dos reglas de otro grupo la incorpora a este. View menu ofrece Clone rule above/below, Add rule above/below, Move To y Edit group. Pasar el cursor sobre Features permite distinguir el tipo User/Network y la acción de la regla de las acciones de policy y los umbrales de Heartbeat. En la tabla de SFOS 23, User significa Match known users seleccionado y Network, no seleccionado; los iconos de policy distinguen None, Accept, Drop y Reject, y los de Heartbeat, Green, Yellow y No restriction. Esta presentación no demuestra cambios en el motor de tráfico.

Para instalaciones nuevas, las ayudas de SFOS 22/23 enumeran una regla LAN-to-WAN y la regla MTA con Linked NAT creada automáticamente al activar MTA, que figura como activado por defecto. Hay que comprobar la instalación concreta. La regla implícita #0 no se puede editar, eliminar ni mover y queda excluida de los filtros. Restablecer Sophos Firewall explica el estado diferente tras un Factory Reset en SFOS 22.

Action y registro

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

• Accept: permite la conexión.
• Drop: está documentado como descarte sin notificación para el tráfico no web. El comportamiento de HTTP/HTTPS no se garantiza de forma general debido al conflicto documental descrito a continuación.
• 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.

⚠️ Conflicto documental no resuelto sobre tráfico web: La ayuda del formulario de reglas de SFOS 22/23 describe que Drop acepta y examina HTTP/HTTPS, autentica a los usuarios desconocidos si Use web authentication for unknown users está activado, permite las solicitudes autorizadas por una Web Exception coincidente y muestra una página de bloqueo HTML para las demás. En cambio, la guía de registro de tráfico descartado describe el descarte silencioso de forma general y vincula la página de bloqueo web a esa opción de autenticación. Estas descripciones contradictorias no se han resuelto aquí como comportamiento verificado de un build SFOS concreto. No permiten concluir que todas las conexiones web se descarten silenciosamente, que la página de bloqueo dependa únicamente de la opción de autenticación ni que todos los servicios se bloqueen de forma general.

Si se necesita un bloqueo garantizado o una respuesta concreta, obtener una aclaración escrita de Sophos para la versión, el build y la ruta de procesamiento exactos, o verificarlo en un entorno de prueba aislado y expresamente autorizado. Probar por separado el tráfico no web, HTTP y HTTPS; para el tráfico web, incluir usuarios conocidos/desconocidos, autenticación activada/desactivada y presencia/ausencia de una Web Exception coincidente. Utilizar solo clientes, destinos y servicios de prueba definidos, activar Log firewall traffic y generar conexiones nuevas. Documentar build, posición de la regla, Firewall Rule ID, usuario, Action, ajustes web/TLS y resultados de logs, Packet Capture y navegador. Un timeout, una página de bloqueo o Policy Tester por sí solos no demuestran el bloqueo previsto. Ante un acceso inesperado o un resultado incierto, no desplegar en producción; revertir los cambios de prueba y escalar las pruebas a Sophos Support. Reject proporciona la respuesta de protocolo descrita arriba; aquí no se recomienda como sustituto no verificado del control web.

Log firewall traffic debe estar activado en las reglas importantes. Los logs se guardan por defecto en la firewall; revisar los ajustes locales y los destinos Syslog en System services > Log settings. El envío al servicio cloud requiere además activar Sophos Central services en la página Sophos Central. La ayuda de SFOS 22 denomina al destino Sophos Fusion (antes Sophos Central), y la de SFOS 23, Sophos Central; el nombre no sustituye este requisito independiente. 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

Desvincular una Linked NAT Rule en la tabla NAT permite editarla y hace que se evalúe según sus propios criterios, independientemente de la regla firewall original. Antes se documentan el alcance y el orden NAT; después se comprueba un flujo nuevo. No es un simple cambio de nombre.

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.

En muchas instalaciones ya existe una regla Default SNAT con MASQ. Sin embargo, esto depende del estado de configuración y migración y debe comprobarse en la tabla de reglas NAT concreta. Antes de añadir una Linked NAT Rule, se debe comprobar si una regla existente 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 Fusion 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 Fusion > 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.

Para ambos umbrales, Green admite solo Green; Yellow, Green o Yellow; No restriction también admite Red y dispositivos sin Heartbeat. Comprobar además las opciones independientes de bloqueo sin Heartbeat. La guía de Heartbeat ausente distingue entre perdido y nunca enviado; Synchronized User ID explica el cierre de sesión al perderlo o tras suspensión/reactivación y la validación de un nuevo inicio de sesión.

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.

El escaneo de malware y contenido utiliza Web > General settings. Para seleccionar filtrado web proxy primero se necesita una Web Policy o Scan HTTP and decrypted HTTPS. Una Application Filter Policy para Micro Apps basadas en URL sigue aplicándose en DPI con descifrado aunque Web policy sea None y estén desactivados malware scanning y ATP. Esto no elimina las condiciones propias de Web Exceptions en DPI. Las guías detalladas explican proxy en un bridge sin IP y descifrado HTTPS con Direct Web Proxy.

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. La ayuda actual del formulario de reglas no describe la prioridad entre una Application Policy y una 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. En cambio, si Match known users está activado, se aplica la Traffic Shaping Policy del usuario; si el usuario no tiene una policy, se aplica la de su grupo.

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 únicamente los paquetes IPv4 e IPv6 salientes que coinciden con esta regla. Al hacerlo, sobrescribe una marca DSCP ya presente en el tráfico entrante. La regla de firewall no marca los paquetes de respuesta ni el tráfico generado por el sistema. El marcado por sí solo no prioriza ni clasifica nada; todos los switches, routers y dispositivos WAN implicados deben procesar de forma coherente los valores DSCP elegidos.

Una prueba QoS acotada usa un cliente definido, un destino de prueba autorizado e ICMP con AF31 = 26. Confirmar el match y comprobar el marcado con Packet Capture en la salida WAN y la respuesta por separado. CS0 = 0 es la respuesta del ejemplo documentado, no una garantía sobre el marcado de cualquier destino. No crear una autorización amplia con Any; retirar después la regla de prueba. Probar una regla Sophos Firewall explica la captura.

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 XGS Appliances, 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 Fusion son opcionales para el análisis avanzado.

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.

Para un servidor SMTP existente publicado mediante DNAT, Configurar Mail Protection en Legacy mode conecta las reglas de entrada y salida con NAT, política de análisis, TLS y los logs del proxy heredado.

Para recuperar correo, la casilla por sí sola no basta: confianza de la CA, límites globales de análisis, política POP-IMAP opcional y coincidencia real de la regla deben encajar. Analizar y probar POP3 e IMAP en Sophos Firewall ofrece el procedimiento completo de piloto y validación.

Probar y operar la regla

Prueba de aceptación después de guardar

Después de configurar la regla, se guarda con Save. 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.

Policy Tester simula la selección de reglas, pero no genera un flujo de paquetes real ni confirma el enrutamiento o la ruta de retorno. Por eso, para Policy Test, Log Viewer y Packet Capture existe el procedimiento completo 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.

Revertir un cambio en una regla

Antes de realizar un cambio, se anotan la posición actual y todos los campos afectados, o se exporta un estado de configuración reproducible. No se debe transformar una regla existente para otro propósito: una regla nueva, inicialmente desactivada, ofrece una vía de reversión más clara y deja intacto el acceso existente.

Si la prueba de aceptación falla, se desactiva la regla nueva o, en el caso de una regla editada, se restauran los valores anteriores y su posición previa. Después, se vuelven a generar tanto el flujo de prueba permitido como otro deliberadamente no permitido y se comprueba la Firewall Rule ID esperada en Log Viewer. Al modificar la ruta de administración, se debe mantener un acceso administrativo independiente durante todo el proceso.

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. En la ayuda de SFOS 22, Sophos documenta Unused de forma diferente en dos lugares: la ayuda de la tabla de reglas indica 24 horas sin tráfico coincidente, mientras que el widget Active firewall rules del Control Center indica 12 horas y una comprobación diaria. Por eso, el estado no constituye un criterio fiable para eliminar una regla. New y Changed permanecen durante 24 horas desde la creación o modificación, y una regla puede tener varios estados al mismo tiempo. En la ayuda de SFOS 23, tabla y widget coinciden en 12 horas para Unused. Es una comparación documental, no una medición probada en un build de la appliance.

Active firewall rules muestra el número de reglas activas y el tráfico coincidente en bytes de las últimas 24 horas. Distingue WAF (Webserver Protection), User (con usuarios o grupos) y Network (sin esos criterios). Scanned es el total de reglas del gráfico, no el número de reglas con escaneo de malware. Disabled significa configurada pero desactivada; puede coincidir con Changed. Pasar el cursor muestra el volumen; pulsar un número o estado abre la tabla con el filtro correspondiente.

El widget del Control Center es visible para todos los administradores, con independencia de sus permisos. Su visibilidad no demuestra que exista permiso de escritura en la página de reglas. Estos 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. Si una regla esperada no aparece en la tabla, primero se restablece el filtro activo; la ayuda de SFOS 22 también limita las acciones de grupo en una vista filtrada.

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 Sophos Fusion, 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.