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

Antes de Add firewall rule, se selecciona expresamente IPv4 o IPv6 en la página de reglas. Los siguientes ejemplos no constituyen una autorización conjunta para ambas familias de protocolos.

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 coinciden todos los criterios positivos de una regla y no se aplica una exclusión, 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 para el tráfico coincidente que no quede excluido.

Una regla puede comprobar, entre otros criterios positivos, Source zone, Source network, horario, Destination zone, Destination network, Service y usuario. Todos los criterios positivos configurados deben coincidir con la conexión. Las Exclusions no son criterios positivos: si coinciden conjuntamente todos los criterios configurados de una exclusión, se omite la regla y se continúa evaluando las reglas posteriores.

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 abarcar tráfico interno dirigido a servicios locales. Los detalles se explican en Analizar paquetes descartados en Sophos Firewall.

Para una regla de registro aprobada, se selecciona Add firewall rule > New firewall rule en el conjunto de reglas IPv4/IPv6 correspondiente, un nombre inequívoco, Rule position Bottom, Action Drop y Log firewall traffic. Seleccionar Source zones y Destination zones por separado; establecer Source networks and devices, Destination networks y Services según el alcance aprobado y, después, pulsar Save. Antes, documentar el orden existente y la configuración de registro. Las nuevas conexiones de prueba permitidas y las deliberadamente no permitidas deben coincidir con los Rule IDs esperados, sin afectar a los servicios locales. Si hay desviaciones, desactivar la nueva regla y restaurar el estado anterior. La aclaración sobre el tráfico web en Action y registro sigue siendo un requisito previo, no una prueba completada mediante estos pasos.

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.

En la tabla de SFOS-22, los filtros se muestran u ocultan con Enable filter / Disable filter; en Add filter se seleccionan el campo y el valor, y con Reset filter se restablecen. Con el filtrado activo se pueden seleccionar reglas individuales, pero no grupos de reglas. Las reglas o los grupos se pueden activar o desactivar con Enable / Disable; una selección mixta de reglas activas e inactivas impide esta acción. More options ofrece opciones para editar, clonar, añadir, eliminar, Detach, Reset data transfer count y acciones de grupo. Para una regla que aún no pertenece a un grupo, se selecciona Add to group > New group, se asigna el nombre del grupo y se definen el tipo de regla y las zonas de origen y destino; como alternativa, se selecciona un grupo existente. Los grupos se pueden editar o eliminar. La columna # muestra la posición; con Rule handle se arrastra la regla o el grupo, o se introduce la posición de destino en Move To y se confirma con Enter. Antes de cada cambio de posición, anotar el estado anterior y, después, comprobar que los nuevos flujos de prueba coincidan con el Rule ID esperado. Un clon no es una autorización automáticamente segura: comprobar los criterios, el estado y la posición antes de activarlo.

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.

Los iconos son indicaciones de configuración, no resultados de pruebas: En SFOS 23 se comprueba en Features, y en SFOS 22 en Feature and service, si el análisis de Web/FTP/correo y Traffic Logging están activados o desactivados, si se ha seleccionado el filtrado mediante proxy y si hay políticas asignadas. Un proxy activado afecta a 80/443; los demás puertos HTTP/TLS siguen usando DPI. Web policy, App control, IPS y Shape traffic pueden mostrar None; los iconos de IPS y de control del tráfico muestran una política asignada, y los de Web y App muestran además su acción. En Heartbeat hay que distinguir el estado mínimo Green o Yellow de No restriction y comprobar por separado el estado de Block clients with no heartbeat. No restriction por sí solo no demuestra que este interruptor adicional esté desactivado. También deben tenerse en cuenta las Exclusions activadas al comprobar las coincidencias.

Para instalaciones nuevas, las ayudas de SFOS-22/23 mencionan una regla LAN-to-WAN y la regla MTA con Linked NAT que se genera automáticamente cuando el modo MTA está activado; en esas instalaciones, MTA está activo de forma predeterminada. Esto no sustituye la comprobación de la instalación propia. La regla implícita #0 no se puede editar, eliminar ni mover y queda excluida de los filtros. Debe distinguirse de un Factory Reset: ambas ayudas describen la eliminación de todas las reglas de firewall y, a continuación, la existencia únicamente de la regla Auto added firewall policy for MTA. De ello no se debe deducir que la autorización LAN-to-WAN se restaure automáticamente. Un restablecimiento no es un procedimiento para depurar reglas individuales; la copia de seguridad, el acceso administrativo independiente y el plan de recuperación forman parte del procedimiento separado Restablecer Sophos Firewall.

La descripción general de inicio Access rules and policies para SFOS 22/23 también describe grupos de reglas creados de forma predeterminada con una regla de firewall para descartar tráfico hacia WAN, DMZ y las zonas internas (LAN, Wi-Fi, VPN y DMZ). Se trata de reglas de firewall visibles y agrupadas, no de la regla implícita #0. Sin embargo, esta descripción general y los valores predeterminados detallados de instalación y restablecimiento mencionados anteriormente no acreditan un conjunto inicial de reglas uniforme para todas las instalaciones. Por tanto, compruebe, en su versión, compilación e instalación concretas de SFOS, en Rules and policies > Firewall rules, qué reglas y grupos están realmente presentes y activados, qué zonas de origen/destino y otros criterios de coincidencia utilizan y en qué posición se encuentran. La mera presencia de un grupo no demuestra aislamiento: una autorización anterior que coincida puede permitir ya el tráfico. Compruebe la separación de zonas deseada mediante nuevas conexiones de prueba expresamente autorizadas y los Rule IDs esperados; para el tráfico web, sigue siendo aplicable el conflicto de documentación sobre Drop descrito anteriormente. No deduzca de la descripción general de inicio nombres de grupos garantizados, condiciones de creación ni un efecto de bloqueo general.

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: descarta la conexión y, en el caso de TCP, envía un TCP Reset; para UDP e ICMP, la ayuda indica expresamente que se envía un mensaje ICMP de puerto inalcanzable al origen.
• 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.

Al seleccionar Protect with web server protection, aparece Preconfigured template. None significa que los detalles de WAF se deben definir manualmente. Las plantillas documentadas son Exchange Autodiscover, Exchange Outlook Anywhere, Exchange General, Microsoft Lync, Microsoft Remote Desktop Gateway 2008 and R2, Microsoft Remote Desktop Web 2008 and R2 y Microsoft Sharepoint 2010 and 2013. Estos nombres históricos no indican que las respectivas versiones de servidor sigan siendo compatibles o seguras actualmente. Antes de utilizar una plantilla, debe comprobarse que corresponda al servicio realmente en funcionamiento; la configuración posterior de WAF y su validación siguen siendo necesarias.

⚠️ 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 el 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 quedar sin un registro final 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.

Regla basada en MAC: aclarar las limitaciones antes del intento de bloqueo

Un host MAC puede permitir una identificación adicional del dispositivo cuando los clientes son directamente visibles, por ejemplo, si cambia su dirección DHCP. Sin embargo, una dirección MAC no es una identidad sólida: se puede modificar o suplantar. La guía original califica MAC-Filtering como más seguro y muestra Block_MAC para IPv4 de LAN a WAN con Drop, registro, posición Top, grupo None, horario All the time, destino y Services Any. Esta combinación no garantiza aquí un bloqueo completo de Internet: el conflicto HTTP/HTTPS/Web Exceptions documentado anteriormente sigue sin resolverse.

La guía limita el filtrado de Internet basado en MAC a los dispositivos conectados directamente al firewall. Si hay un router, otro firewall o un conmutador de capa 3 entre ambos, la MAC original del cliente no es visible automáticamente. La guía menciona para este caso MAC binding para usuarios locales; sin aclarar la asignación de identidad y la ruta real de los paquetes, esto no garantiza el filtrado MAC en tráfico enrutado ni sustituye la autenticación. Antes de una prueba, la MAC visible en la entrada del firewall debe pertenecer realmente al cliente de prueba.

Para una prueba piloto aislada y expresamente aprobada, solo se bloquea un nuevo flujo TCP IPv4 no web hacia un servidor de prueba WAN controlado:

1. Comparar la MAC del cliente de prueba con la visible en la entrada del firewall. En Hosts and services > MAC host > Add, introducir el nombre MAC_Host, Type MAC address y la MAC realmente verificada y, después, pulsar Save. 37:97:0E:AB:56:46 es el valor de ejemplo sin modificar de la guía y no debe adoptarse sin comprobarlo.
2. En Rules and policies > Firewall rules, seleccionar IPv4 y Add firewall rule > New firewall rule. Para Block_MAC, establecer Action Drop, Log firewall traffic, Rule position Top, Rule group None, Source zones LAN, Source networks and devices MAC_Host, During scheduled time All the time y Destination zones WAN. Limitar el destino al servidor de prueba controlado y Services al servicio de prueba TCP no web aprobado, en lugar de adoptar los valores Any originales. Documentar previamente el orden y el estado de la configuración y, después, pulsar Save.
3. Generar un flujo de prueba nuevo, por ejemplo, un flujo TCP de iPerf3 aprobado, y comprobar Block_MAC junto con el Rule ID en Log Viewer, así como el flujo de paquetes descartado. Otro cliente de control no bloqueado debe seguir pudiendo acceder al destino de prueba. Un tiempo de espera agotado por sí solo no es suficiente.
4. Tras la prueba piloto, desactivar o eliminar la regla de prueba, restaurar el orden anterior y verificar desde el cliente original un nuevo flujo de prueba permitido mediante el Rule ID esperado. Eliminar el host MAC de prueba solo si ninguna otra configuración lo necesita.

Si no hay coincidencia, comprobar la visibilidad de la MAC, la selección de IPv4, Source, Schedule y el orden; no ampliar la regla a todos los dispositivos. Ante un acceso inesperado o un fallo del cliente de control, revertir la prueba y aclarar las evidencias con la versión y el build exactos. HTTP, HTTPS, Web Exceptions, otras zonas/destinos/servicios e IPv6 no están cubiertos por esta prueba piloto. Solo se puede garantizar un bloqueo completo de Internet basado en MAC tras aclarar y comprobar estos casos por separado.

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.

Desconocido significa aquí que el usuario ha iniciado sesión en el dispositivo, pero aún no se ha autenticado en el firewall. AD SSO con Kerberos/NTLM o Captive Portal se configuran en Authentication > Web authentication, y el acceso desde las zonas necesarias, en Administration > Device access. De forma predeterminada, el tráfico que coincide se contabiliza en el consumo de datos individual. Exclude this user activity from data accounting lo excluye de ese cómputo, por ejemplo, si no se desea aplicar un límite de datos a estos usuarios; no constituye una autorización adicional ni una autenticación.

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.

El ejemplo de países documentado permite HTTPS desde países africanos hacia 172.16.16.0 y utiliza una Exclusion con únicamente Source zone WAN y un objeto de país seleccionado como Source network. Esta regla solo se omite si coinciden ambos criterios; el tráfico puede ser permitido por una regla posterior o llegar a #0. La dirección es un ejemplo sin modificar, no una definición completa de red con prefijo. Para una prueba propia, seleccionar un objeto de destino que exista realmente, documentar el orden de las reglas y comprobar un flujo de prueba excluido y otro no excluido mediante los Rule IDs. Una Exclusion no es un bloqueo global.

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.

Para el tráfico saliente de los clientes, se pueden crear conjuntamente la autorización del firewall y Source NAT:

1. En Rules and policies > Firewall rules, seleccionar la familia de protocolos y abrir Add firewall rule > New firewall rule. Definir el nombre y la posición; en el ejemplo, utilizar Source zones LAN, Source networks and devices Network_LAN, Destination zones WAN y Destination networks Any. Network_LAN debe contener la red de clientes propia y verificada. La guía muestra Services Any; en producción, seleccionar en su lugar únicamente los servicios aprobados.
2. Seleccionar Create linked NAT rule, definir el nombre y la posición de NAT y establecer Translated source (SNAT) en MASQ. Guardar primero la Linked NAT Rule con Save y, después, la regla de firewall con Save.
3. Comprobar la regla de firewall en la tabla de firewall y la regla SNAT vinculada en la tabla de NAT mediante Firewall Rule ID y el nombre. Primero se evalúa la regla de firewall y, después, Source NAT. En Linked NAT solo se pueden modificar el origen traducido y la traducción de origen específica de la interfaz de salida; los demás criterios, incluidos los usuarios/grupos, proceden de la regla de firewall.

La representación del origen 10.145.16.10/24 es el valor de ejemplo sin modificar de la guía, no un valor que deba copiarse como dirección de red sin comprobarlo. MASQ utiliza la dirección IP de la interfaz de salida realmente seleccionada. Comprobar previamente la ruta y la interfaz correspondientes, así como las reglas NAT situadas en posiciones superiores. Un nuevo flujo de prueba debe mostrar el Firewall Rule ID, el NAT Rule ID y el origen traducido esperados. Si la traducción es incorrecta, comprobar el orden y la salida; si la prueba falla, revertir la nueva configuración de firewall y Linked NAT y restaurar el estado anterior, incluido el orden, sin modificar otras reglas NAT necesarias.

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 el tráfico HTTP y el tráfico HTTPS ya descifrado en busca de malware, pero no activa el descifrado. En el modo DPI, se necesita una regla de inspección SSL/TLS adecuada en Rules and policies > SSL/TLS inspection rules; en el modo de proxy web, se utiliza Decrypt HTTPS during web proxy filtering. Antes del despliegue, compruebe la ruta de procesamiento que se utiliza realmente y que los clientes confían en la CA de descifrado.

Use Zero-day protection requiere Scan HTTP and decrypted HTTPS y envía los archivos descargados mediante HTTP/HTTPS para un análisis adicional en busca de amenazas desconocidas o aún no divulgadas. Esta función requiere Zero-Day Protection y puede causar un retraso según el tipo de archivo y la política; no activa por sí misma el descifrado HTTPS.

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.

Incluso con Use web proxy instead of DPI engine activado, el motor DPI sigue filtrando HTTP y SSL/TLS en otros puertos; esta opción afecta al proxy para 80/443, no a todo el tráfico. La ayuda describe el filtrado mediante proxy web en un puente sin dirección IP como un caso en el que se descarta el tráfico, por lo que no debe activarse sin comprobarlo. Decrypt HTTPS during web proxy filtering también descifra en el modo Direct-Proxy configurado expresamente en el cliente. En el modo DPI, las Web Policies, incluidas las Web Exceptions, solo se aplican si se ha establecido una Web Policy, está activo el análisis de malware/contenido o está activo ATP. Estas condiciones deben distinguirse de la detección de Micro-App basada en URL descrita en la sección Application Control, IPS y Traffic Shaping.

Procesar solo determinados destinos mediante el proxy web

Si se desea limitar SafeSearch, las restricciones de YouTube o los inicios de sesión de Google Workspace a determinados dominios, mientras el resto del tráfico utiliza el descifrado DPI, se crea una regla independiente situada en una posición superior. Comprobar previamente la licencia de Web Protection, los ajustes web globales correspondientes, la confianza de los clientes en la CA de descifrado y la Web Policy deseada. Los grupos FQDN determinan los destinos; no configuran por sí mismos los dominios de cuentas permitidos ni las acciones de filtrado.

1. En Rules and policies > Firewall rules, seleccionar IPv4 o IPv6, abrir Add firewall rule > New firewall rule y definir el nombre y la posición. Seleccionar Action Accept, la zona de origen realmente necesaria y la red de clientes aprobada. La guía original utiliza Any en ese punto; este origen amplio no es un requisito necesario para producción.
2. Establecer Destination zones WAN, Destination networks con los grupos predefinidos SafeSearch enforcement, YouTube restrictions enforcement y Google app enforcement, y Services HTTP, HTTPS. Seleccionar únicamente los grupos necesarios para el caso de uso deseado.
3. Activar Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine y Decrypt HTTPS during web proxy filtering. La Web Policy propiamente dicha debe corresponder a la restricción deseada. Activar Log firewall traffic para la prueba piloto y guardar con Save.
4. Situar la regla por encima de las reglas DPI. Con nuevas conexiones, comprobar la restricción de SafeSearch/YouTube/cuentas deseada, el Rule ID y los registros web/TLS; probar también otro destino que deba seguir coincidiendo con la regla DPI prevista y la SSL/TLS inspection rule.

Si la restricción no se aplica, comprobar la posición de la regla, la asignación FQDN, la Web Policy y QUIC; si hay errores de certificado, comprobar la confianza en la CA y la configuración de descifrado. Ante un comportamiento inesperado, desactivar la nueva regla de proxy o restaurar los valores y la posición anteriores y, después, volver a comprobar la ruta DPI original. No desactivar de forma general la protección TLS ni la verificación de certificados.

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 tanto el análisis de malware como 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.

La selección de DSCP debe corresponder al diseño de QoS de todo el trayecto: EF describe Expedited Forwarding para una latencia baja y pocas pérdidas en servicios en tiempo real; AF describe Assured Forwarding con descarte en caso de congestión; CS sirve para la compatibilidad con IP-Precedence. Son conceptos de clases, no una calidad de servicio garantizada únicamente por el marcado. Los valores documentados son:

El ejemplo ICMP original utiliza 8.8.8.8, Source zone LAN, Destination zone WAN, origen y destino Any, así como AF31. Para una comprobación propia, sustituir estos elementos por objetos concretos de cliente y destino aprobados; no son necesarios ni esta dirección pública ni una autorización amplia. Antes de la prueba, anotar el valor DSCP anterior, restaurarlo después de la prueba y comprobarlo con nuevos paquetes. Si no se obtiene la priorización esperada, se deben investigar por separado la coincidencia con la regla, el marcado real de salida y el tratamiento QoS de los dispositivos posteriores.

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.

Preparar reglas de firewall mediante la API XML

Los objetos XML FirewallRule y FirewallRuleGroup permiten realizar cambios de reglas y mantener grupos de forma trazable. No sustituyen ni la planificación de los accesos ni la prueba de aceptación con nuevas conexiones de prueba. El acceso protegido, el uso de HTTP POST a APIController, las operaciones XML explícitas, la verificación TLS, el almacenamiento de secretos y la evaluación del estado XML en lugar del éxito HTTP se explican en Proteger el acceso a la API XML. Primero debe funcionar una consulta de lectura inocua desde el host de automatización previsto, con una cuenta de permisos estrictamente limitados.

Mantener el tipo de regla, la estructura de elementos padre y el orden

En la referencia de SFOS-22/23, Name, Position y PolicyType son obligatorios para Add/Edit. Name es una cadena UTF-8 de un máximo de 60 caracteres, sin comas. Dentro de FirewallRule, PolicyType selecciona, con el valor Network, el bloque NetworkPolicy o, con el valor User, el bloque UserPolicy. No se deben mezclar estas ramas ni enviar ambas sin verificarlas. HTTPBased y HTTPBasedPolicy corresponden a la configuración de WAF, y la vinculación de autenticación, a la autenticación de WAF. Las acciones de ruta de WAF no son una traducción numérica de las acciones de red.

IPFamily admite IPv4 o IPv6; la tabla indica IPv4 como valor predeterminado. Status admite Enable o Disable, pero indica ON como valor predeterminado. Para las reglas preparadas, establecer deliberadamente el estado en Disable y comprobar la familia de protocolos guardada, en lugar de adoptar los valores predeterminados de la documentación como valores seguros para la carga útil. Según la tabla de parámetros, Position admite Bottom, Top, After o Before; el ejemplo escribe estos valores en minúsculas. Por tanto, confirmar la grafía y la operación completa en API help del build instalado. After/Name y Before/Name identifican la regla existente que sirve de referencia; la referencia limita estas etiquetas a solicitudes Set. Section distingue entre Central_TOP, Local y Central_Bottom: aclarar la titularidad y la vía de administración antes de intentar una escritura local, sin eludir una restricción central mediante otra sección.

En el bloque de policy seleccionado, el origen y el destino permanecen separados: SourceZones/Zone, SourceNetworks/Network, DestinationZones/Zone, DestinationNetworks/Network y Services/Service contienen referencias que pueden repetirse. Schedule hace referencia a un horario existente. Las tablas limitan las referencias de redes y servicios a 60 caracteres; no documentan un número máximo conjunto para todos los criterios. Los mismos elementos padre pueden aparecer bajo Exclusions, donde representan excepciones a esta regla, no autorizaciones adicionales. Antes de escribir, leer las zonas, hosts, servicios y horarios que existen realmente y comprobar la coincidencia prevista, teniendo en cuenta también las reglas posteriores.

En UserPolicy, MatchIdentity, ShowCaptivePortal e Identity/Member añaden los criterios relativos a usuarios. Para Member se documentan varias referencias de usuarios/grupos, con un máximo de 256 caracteres. La asignación de identidad y la autenticación web deben funcionar por separado. DataAccounting solo se describe cuando la coincidencia de identidad está activada y excluye el tráfico de los usuarios del cómputo de datos; no autentica. Aquí el ejemplo y la tabla se contradicen: el ejemplo muestra Include/Exclude, y la tabla, Enable/Disable. También WebCategoryBaseQoSPolicy y ApplicationBaseQoSPolicy muestran Apply/Revoke en el ejemplo, mientras que la tabla describe una cadena. No traducir automáticamente estos valores ni tratarlos como intercambiables. Si el valor concreto para el objeto y el build sigue sin aclararse, detener la solicitud de escritura y consultarlo con Sophos.

Action en la rama Network/User admite Accept, Drop o Reject; la tabla indica Drop como valor predeterminado. Sigue siendo necesaria una acción explícita, y el conflicto explicado anteriormente sobre el tratamiento de HTTP/HTTPS con Drop también se aplica a los cambios mediante la API. LogTraffic admite Enable/Disable, con Disable como valor predeterminado documentado; elegir deliberadamente el registro para la prueba de aceptación. SkipLocalDestined afecta al tráfico dirigido a la IP del appliance y no sustituye a Device Access. Las referencias de policy, como WebFilter, ApplicationControl, IntrusionPrevention y TrafficShapingPolicy, deben corresponder a la protección planificada previamente. El análisis, el proxy, el descifrado, Zero-Day y Heartbeat siguen siendo controles distintos con los requisitos explicados anteriormente. En particular, algunos valores predeterminados como OFF, NULL o NoRestriction contradicen parcialmente los valores de entrada indicados; ni esos valores ni los elementos vacíos de los ejemplos demuestran qué efecto tienen la omisión, el vaciado o la actualización en el build concreto.

Al transferir las opciones de protección existentes, se debe comprobar el dominio de valores de cada campo: ProxyMode indica, además de Enable/Disable, también true/false; NDRActiveThreatIntelligence indica únicamente true/false. Los umbrales MinimumSourceHBPermitted y MinimumDestinationHBPermitted admiten GREEN, YELLOW y No Restriction, mientras que la columna de valores predeterminados escribe NoRestriction. Estas entradas son distintas de las de los interruptores independientes de Heartbeat; no constituyen una traducción automática de las etiquetas de la GUI. Los selectores relativos a usuarios WebFilterInternetScheme y ApplicationControlInternetScheme indican Enable/Disable, pero tienen como valor predeterminado 0; no deben confundirse con un nombre de política. Los comentarios XML vinculan WebCategoryBaseQoSPolicy a un WebFilter seleccionado y ApplicationBaseQoSPolicy a un Application Filter seleccionado. Para Traffic Shaping, la tabla indica TrafficShappingPolicy/TrafficShapingPolicy, pero el ejemplo XML utiliza TrafficShapingPolicy: no se debe deducir que ambas etiquetas sean intercambiables ni que se acepten ambas. DSCPMarking está documentado como una cadena; la serialización del valor de la GUI debe corresponder al build. Comparar cada opción de protección afectada antes y después del cambio; no normalizar entradas desconocidas ni perder silenciosamente ninguna opción de protección.

La pertenencia a un grupo no es una decisión de seguridad

FirewallRuleGroup agrupa reglas existentes mediante SecurityPolicyList/SecurityPolicy. SourceZones/Zone y DestinationZones/Zone son elementos padre separados para la asignación al grupo, no nuevos criterios de coincidencia de las reglas individuales. El Policytype del grupo, escrito con una «t» minúscula, difiere del PolicyType de una regla. Los selectores de grupo documentados son User/network rule, Network rule, User rule, WAF rule y Any; no deducir estos valores del tipo de regla ni normalizarlos con otras grafías.

El nombre del grupo es obligatorio, debe estar en UTF-8, sin comas y tener un máximo de 150 caracteres; Description es opcional, con un máximo de 255 caracteres. Para SecurityPolicy, la referencia indica un máximo de 60 caracteres por nombre de regla, sin comas y hasta 200 valores. Es un límite de pertenencia documentado, no una promesa de capacidad comprobada mediante pruebas. Para un grupo Internet Access, leer primero los nombres de las reglas existentes, seleccionar solo los miembros aprobados y asignar el origen y el destino por separado. El ejemplo del fabricante, con dos puntos y una selección de todos los tipos separada por comas, no es una carga útil ejecutable.

Antes de actualizar un grupo, guardar la pertenencia, las posiciones de las reglas y su estado. Después, volver a cotejar esas mismas reglas en WebAdmin y mediante una consulta de lectura autorizada. La descripción «Add/Remove» de SecurityPolicy no define una modificación incremental segura de la lista ni una semántica de sustitución. Si no está claro cómo se tratan las listas omitidas o vacías, no escribir. Según la ayuda de la GUI, un grupo no puede existir vacío; quitar la última regla también puede eliminar el grupo. La agrupación mejora la organización, pero no aporta aislamiento ni prioridad: siguen siendo decisivos los criterios de coincidencia y el orden real de cada regla.

Distinguir las respuestas según la operación y volver a leer el estado

Las siguientes correspondencias coinciden en las referencias de SFOS 22/23. Los identificadores Message.* siguen siendo símbolos de documentación sin resolver, no mensajes de ejecución, traducciones ni causas inequívocas garantizados. Un mismo código puede indicar algo distinto según la operación. En particular, se trata de códigos de estado XML, no de códigos de estado HTTP.

Para crear y editar reglas Network/User, son relevantes estas diferencias:

• Add firewall rule — 200 — Message.FWRuleAddSuccess; Edit firewall rule — 200 — Message.FWRuleEditSuccess.
• Edit firewall rule — 202 — Message.FirewallRuleUpdateWithRename: comprobar el nombre antiguo y el nuevo, las referencias y el tipo de regla guardado; no asumir simplemente que la operación ha tenido un éxito completo.
• Add firewall rule — 500 — Message.FWRuleAddFail; Edit firewall rule — 500 — Message.FWRuleEditFail.
• Add firewall rule — 502 — Message.FWRuleRecordExists; Edit firewall rule — 502 — Message.FWRuleUpdateRecordExist: comparar la regla existente y la deseada a partir del estado leído; no sobrescribir automáticamente.
• Add firewall rule — 541 — Message.VHIPRangeConflict; Edit firewall rule — 541 — Message.FWRuleFailMaxUser. No deducir de ello una causa de error común ni un límite numérico de usuarios.
• Add firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected; Edit firewall rule — 551 — Message.CannotSelectDestHBIfWANSelected: comprobar conjuntamente las zonas de destino y la configuración de Destination Heartbeat.
• Edit firewall rule — 552 — Message.CannotImportDiffPolicytypeWithSameName: cotejar el nombre existente y el tipo de regla; no intentar eludir el problema cambiando el nombre o el tipo sin confirmar la causa.
• Add firewall rule — 596 — Message.CMLOCALOperationrestriction; Edit firewall rule — 596 — Message.CMLOCALOperationrestriction: aclarar la responsabilidad de administración y la vía de cambio autorizada.

Las respuestas específicas de WAF que ambas referencias enumeran corresponden a la guía de WAF; no extrapolar sus conflictos de puertos, redirecciones y Protected Server a las reglas Network/User.

También para los grupos se debe dejar constancia de la operación: Add firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists; Edit firewall rule group — 200 — Message.FWGroupAddSuccess, 500 — Message.FWGroupAddFail, 502 — Message.FWGroupRecordExists. La referencia de Edit utiliza efectivamente los mismos símbolos de Add. Antes de volver a intentarlo, leer el nombre del grupo guardado, la pertenencia y ambas listas de zonas; no deducir de los nombres de los símbolos que Edit realiza una operación de creación.

Al eliminar, se aplica Delete firewall rule — 200 — Message.FWDelSuccess, 500 — Message.FWRuleDeleteFail, 596 — Message.CMLOCALOperationrestriction. La tabla de Delete marca Name como opcional y lo describe, de forma contradictoria, como referencia para Before/After. No deducir de ello que se pueda realizar una eliminación general sin nombre. Antes de Remove, comprobar el objetivo exacto, las dependencias, la pertenencia a grupos, Linked NAT, la responsabilidad de administración y la carga útil confirmada en API help. Para reglas antiguas poco claras, la desactivación controlada con una ventana de observación sigue siendo el primer paso más seguro.

Después de cada respuesta, y también tras un timeout o una interrupción de la conexión, leer primero el estado realmente guardado antes de reintentar: el nombre, el tipo, el estado, la familia de protocolos, la posición, los criterios, Exclusions, las referencias de protección y la pertenencia a grupos deben corresponder al estado deseado aprobado. En Remove, comprobar además que falte exactamente la regla objetivo y que las reglas necesarias y NAT permanezcan sin cambios. Un resultado desconocido puede haber incluido ya un cambio. No repetir a ciegas, realizar un Upsert automático ni ampliar a Any; ante desviaciones, detenerse, guardar la respuesta depurada y Audit Trail y utilizar la vía de reversión confirmada. Solo después se realizan los nuevos flujos de prueba permitidos y deliberadamente no permitidos descritos más abajo.

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.

Los intervalos de tiempo pueden solaparse: una regla creada a las 10:00 permanece como New hasta las 10:00 del día siguiente. Un cambio a las 11:00 hace que tenga el estado Changed hasta las 11:00 del día siguiente; entre las 11:00 y las siguientes 10:00, la regla tiene ambos estados. Un estado Unused detectado en la comprobación diaria de las 12:00 se mantiene hasta la siguiente comprobación. Si la regla se desactiva a las 13:00, puede tener simultáneamente los estados Changed y Disabled hasta las 13:00 del día siguiente y, después, solo Disabled. Estos ejemplos de la documentación no sustituyen la comprobación del uso real ni una decisión de eliminación. Antes de Reset data transfer count, documentar el valor actual: el restablecimiento no recupera un valor anterior del contador ni modifica los permisos de la regla.

Active firewall rules muestra las reglas por tipo y estado, así como el tráfico correspondiente en bytes de las últimas 24 horas. El panel distingue entre WAF (Webserver Protection), User (con usuarios o grupos) y Network (sin estos criterios). Scanned indica el número total de reglas del gráfico, no el número de reglas analizadas en busca de malware. Disabled significa que la regla está configurada, pero desactivada; una regla desactivada también puede tener el estado Changed. Al pasar el cursor, puede consultar el volumen de datos; al hacer clic en el número o el estado, se abre la tabla de reglas 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.