Crear y probar Web Exceptions de Sophos Firewall de forma segura

Una Web Exception se crea rápidamente, pero su efecto puede ser mucho mayor de lo esperado. Según la selección, Sophos Firewall no solo omite el descifrado HTTPS, sino también la validación de certificados, el análisis de malware y contenido, el análisis Zero-Day o comprobaciones completas de Web Policy.

Por tanto, el orden seguro consiste en determinar primero el flujo afectado y la comprobación que realmente causa el problema, limitar después la coincidencia y solo entonces activar la excepción mínima necesaria. Una prueba positiva no es suficiente. En la prueba negativa, un destino similar no excluido debe seguir analizándose con normalidad.

Esta guía se aplica a SFOS 22.0. Las etiquetas de WebAdmin se mantienen deliberadamente en inglés para poder localizarlas directamente en la interfaz.

Web Exception en siete pasos

1. Documentar el cliente afectado, el host de destino, la ruta URL, el protocolo y la hora.
2. Comprobar si se utiliza DPI Mode o Web Proxy Mode y qué regla de firewall y Web Policy se aplican realmente.
3. Decidir si el problema procede solo del descifrado TLS o de una comprobación concreta de Web Protection.
4. En Web > Exceptions > Add an exception, definir criterios limitados de URL, categoría, origen o destino.
5. En Skip the selected checks or actions, seleccionar únicamente la opción mínima necesaria.
6. Activar la excepción y volver a probar el mismo flujo con un nuevo proceso del navegador o de la aplicación.
7. Realizar una prueba negativa contra un destino similar no excluido y documentar la coincidencia, el efecto, el responsable y la fecha de revisión.

⚠️ HTTPS decryption no es una opción de compatibilidad inofensiva. Para el tráfico coincidente también desaparecen las comprobaciones dependientes y el firewall permite certificados de servidor no válidos. Malware and content scanning también omite automáticamente el análisis Zero-Day. Por ello, una excepción amplia no debe ser el primer paso de troubleshooting.

Comprobar los requisitos del producto antes de elegir una excepción

En algunos productos administrados, permitir determinados puertos y dominios es un requisito de la función correspondiente. Antes de elegir una regla de firewall, TLS Exclusion o Web Exception, confirmar con el responsable del producto la función, versión y ruta de conexión real. Registrar en el ticket de cambio los destinos, puertos, protocolos, direcciones y exclusiones de inspección expresamente requeridos, en lugar de conceder acceso general a todos los productos Sophos.

• Wireless: La comprobación previa de Wireless separa la red de administración, DNS, el servicio de hora y los destinos regionales de la configuración Wi-Fi posterior.
• ZTNA: Identificar primero el despliegue local o en la nube en la guía del gateway ZTNA; sus direcciones de conexión y requisitos de inspección no son intercambiables.
• Registro de switches: La incorporación de switches cubre DNS, destinos de registro y comprobaciones de la ruta proxy/TLS.
• Endpoint, XDR y MDR: Los requisitos de red y proxy distinguen plataformas, funciones con licencia y destinos específicos de la instalación. Una lista de dominios permitidos no es una lista general de exclusiones de descifrado.
• NDR y appliances de integración: La planificación del appliance cubre los requisitos de puertos y dominios de salida; el procedimiento operativo ayuda a comprobar por separado las funciones NDR y Log Collector que realmente aloja.

La guía interna es un punto de partida; el responsable del producto debe confirmar los requisitos oficiales para el despliegue concreto antes del cambio. La conectividad de red y la omisión de inspección siguen siendo decisiones separadas. Si falta un conjunto de requisitos verificado o las fuentes se contradicen, no ampliar la excepción por tanteo: conservar las pruebas y resolverlo con los responsables del producto y del firewall. Después siguen siendo aplicables el piloto, los tests positivos y negativos, la revisión y la reversión de esta guía.

Elegir entre Web Exception y TLS Exclusion

Ambas herramientas pueden impedir el descifrado del tráfico HTTPS, pero no resuelven la misma tarea.

Una SSL/TLS inspection rule con Action: Don’t decrypt es adecuada cuando en DPI Mode solo se debe excluir el descifrado para destinos claramente definidos. Un URL Group en la Local TLS exclusion list es especialmente eficiente porque el firewall compara como texto el Server Name Indication, abreviado SNI.

Crear y utilizar URL Groups de forma segura muestra cómo crear una lista de dominios de este tipo, incorporarla a una regla Don't decrypt y comprobarla con un destino negativo.

Una Web Exception es adecuada cuando, de forma adicional o alternativa, se debe omitir una comprobación de Web Protection:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

En DPI Mode, una Web Exception solo se aplica si para el flujo está activa al menos una Web Policy, Malware and content scanning o ATP. En Web Proxy Mode, la Web Exception pertenece directamente a la ruta de Web Protection basada en proxy.

La SSL/TLS exclusion list usa nombres de dominio en texto claro e incluye sus subdominios, en lugar de expresiones regulares. Las exclusiones SSL/TLS pueden omitir la aplicación de requisitos de certificados y protocolos, además del descifrado. Por tanto, no equivalen a una Web Exception limitada a HTTPS certificate validation. Los dominios confirmados pueden añadirse a la Local TLS exclusion list desde Control Center o Log Viewer; como alternativa, se edita el URL Group en Web > URL groups o la SSL/TLS inspection rule. Las categorías web también pueden ser criterios de una SSL/TLS inspection rule.

El tráfico cubierto también es diferente: en DPI Mode, las Web Exceptions se aplican a conexiones SSL/TLS en cualquier puerto; en Web Proxy Mode, a SSL/TLS en el puerto 443. Las SSL/TLS Exclusion Rules solo se aplican en DPI Mode, aunque también independientemente del puerto. Además de URL Groups, pueden utilizar como criterios zonas, redes, direcciones IP, servicios, usuarios y grupos. Las Web Exceptions ofrecen patrones de URL, Web categories y direcciones o rangos IP de origen y destino.

Una Web Exception activa puede omitir las comprobaciones de protección seleccionadas para los flujos web coincidentes; esto no garantiza que pueda levantarse cualquier bloqueo del sistema. Por tanto, su ámbito no puede limitarse colocando una regla de Web Policy más adelante en el orden. Los criterios de la propia excepción son decisivos; aun así, debe comprobarse por separado el orden de las reglas de firewall, Web y SSL/TLS, ya que determina qué ruta de protección procesa inicialmente el flujo.

Límite documentado y contradicción sin resolver: Sophos describe las excepciones en general como independientes de las políticas y reglas. Sin embargo, la guía de categorías de SFOS 22.0 y 23.0 identifica expresamente highly objectionable criminal activity como siempre bloqueada: ninguna política o excepción puede permitir estas páginas, y los dominios se ocultan intencionadamente en logs e informes. Estas afirmaciones divergentes no demuestran una omisión funcional del bloqueo. La opción segura sigue siendo no eludirlo y, si es necesario, aclarar la contradicción con Sophos Support. Usar solo destinos inofensivos y aprobados en los tests, nunca contenido prohibido.

La configuración planificada de DPI o Web Proxy, Decryption Rules y la distribución de la CA se explica en Introducir TLS Inspection correctamente. La lógica de filtrado se describe en Configurar Web Protection con Web Policies.

Planificar una coincidencia limitada y trazable

Una excepción no debe empezar con un dominio cualquiera del proveedor. Primero se registra la solicitud concreta en el navegador, Log Viewer o los logs de la aplicación. Después se decide si el hostname, la ruta, la categoría, la IP de origen o la IP de destino es el criterio más estable.

AND entre tipos, OR dentro de un tipo

Sophos Firewall vincula los diferentes tipos de criterios con AND. Por ejemplo, si se especifican patrones de URL y Source IP addresses, ambos tipos deben coincidir.

Varios valores dentro del mismo tipo se evalúan con OR. Por tanto, con dos patrones de URL puede ser suficiente cualquiera de los dos. Con dos Source IP addresses puede ser suficiente cualquiera de los dos orígenes.

Esta lógica es importante para el troubleshooting. Una excepción puede parecer correcta y no aplicarse porque un tipo de criterio adicional no coincide con el flujo real.

Anclar la expresión regular de forma segura

En URL pattern matches se permiten expresiones regulares. Un patrón aislado como vendor.example no es adecuado. También puede coincidir con el texto en una posición inesperada de la URL y excluir demasiadas solicitudes.

Para el dominio de ejemplo reservado updates.vendor.example, un patrón de host anclado deliberadamente puede tener este aspecto:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

El valor es solo un ejemplo. vendor.example es un dominio reservado para documentación y se sustituye por el host de destino real confirmado en el log o la solicitud. El prefijo opcional permite subdominios. Si solo debe excluirse un host exacto, no se utiliza un wildcard innecesario para subdominios.

Los caracteres no ASCII se indican en el patrón como Punycode. Después de cada cambio de regex, la prueba debe incluir una coincidencia esperada y al menos una no coincidencia deliberadamente similar.

Comprobar los puntos, el límite del host y las coincidencias no deseadas en rutas

En una regex, un punto sin escapar representa cualquier carácter. Por eso, los puntos de un nombre de host fijo se escriben como \.. El ^ ancla la coincidencia al principio; el / final delimita el host frente a nombres con un inicio similar, como updates.vendor.example.attacker.example. Sophos Firewall acepta / y \/. Para un único host exacto, el patrón más limitado es:

^updates\.vendor\.example/

Los ejemplos se refieren a la representación de host/URL a la que se aplican estos patrones de Sophos, sin https:// al principio. La herramienta de prueba debe utilizar la misma representación. Si los puertos o la representación son diferentes, no añadir .* por tanteo: aclarar el valor realmente evaluado y la ruta de protección. Sigue siendo aplicable el límite de HTTPS del apartado siguiente.

Para el patrón de host exacto se esperan los resultados siguientes. Con el patrón existente de subdominio opcional, cdn.updates.vendor.example/file también debe coincidir; los demás casos negativos siguen sin coincidir.

Los dos últimos casos son especialmente importantes: la comparación puede abarcar toda la URL, incluidos la ruta y los parámetros de consulta. Un texto de dominio sin anclar puede activar la excepción en otro host. Esta prueba solo comprueba la coincidencia; si realmente se omiten controles de protección se verifica después con una solicitud nueva y logs.

Probar localmente entradas largas que no deben coincidir

Muchos patrones sin anclar pueden exigir más trabajo de búsqueda, especialmente cuando el descifrado HTTPS permite acceder al texto completo de la URL. Esto no permite deducir un número universal de pasos ni un tiempo de ejecución siempre constante, lineal o exponencial para cualquier patrón. El anclaje tampoco sustituye la revisión de cuantificadores complejos. No utilizar un wildcard general .* para los nombres de host.

Una prueba de 1000 caracteres complementa los casos cortos. En un equipo local de administración con Python 3, este ejemplo genera un texto de URL totalmente ficticio, con una ruta larga y el dominio de destino únicamente en la consulta. Comprueba ambos patrones mostrados aquí sin contactar con un firewall:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Se esperan dos resultados sin coincidencia. Otros casos sintéticos deben incluir nombres de host largos casi coincidentes y rutas largas; comparar los patrones anteriores y posteriores con las mismas entradas. Para patrones complejos sospechosos, utilizar una herramienta local con límite de tiempo e interrumpir cualquier prueba que se quede bloqueada. Los tiempos de Python y los contadores de pasos de otros motores regex no son mediciones de SFOS ni promesas de rendimiento. No copiar URLs de producción, tokens, nombres de usuario ni datos de clientes en sitios externos de pruebas regex; para estas pruebas bastan datos ficticios.

Distinguir hostname y ruta URL

Las excepciones para HTTPS decryption y HTTPS certificate validation pueden evaluar el hostname desde el contexto TLS. Sin embargo, un patrón que solo apunta a una ruta URL únicamente funciona para HTTPS cuando la conexión ya se está descifrando. En HTTP sin cifrar, la ruta URL es visible sin descifrado TLS.

Esto marca un límite importante: una excepción no puede desactivar el descifrado y luego utilizar de forma fiable como criterio una parte que solo es visible en la ruta HTTP cifrada. Este caso requiere un ámbito basado en host o un diseño diferente.

Crear la Web Exception

El ejemplo excluye del descifrado HTTPS a un único cliente piloto para un host de proveedor confirmado. No es una regla de excepción universal.

1. Abrir Web > Exceptions.
2. Seleccionar Add an exception.
3. Definir un nombre descriptivo, por ejemplo Vendor API no decrypt.
4. Activar URL pattern matches.
5. Introducir el patrón probado y anclado en Search/Add y aceptarlo con Add.
6. Para el piloto, activar también Source IP addresses, introducir la IP concreta del cliente y confirmarla con Add.
7. En Skip the selected checks or actions, seleccionar exclusivamente HTTPS decryption.
8. Seleccionar Save.
9. Activar en la lista el interruptor de la nueva excepción.
10. Volver a comprobar el nombre, Matching URLs, los orígenes y la comprobación omitida.

La IP de origen se establece de forma deliberada en el ejemplo. Sin ella, la excepción se aplicaría inmediatamente a todos los clientes cuya solicitud coincidiera con el patrón de URL. Tras un piloto satisfactorio, el ámbito puede ampliarse de forma controlada a los orígenes que realmente lo necesiten.

Para una exclusión TLS pura en muchos destinos, un URL Group en una regla Don't decrypt suele ser más fácil de mantener y más eficiente. Muchos FQDN Host Objects en el origen o destino de una SSL/TLS inspection rule son desfavorables porque pueden provocar numerosas consultas DNS para nuevas conexiones TLS.

Preparar una nueva excepción de host en Config Studio

Config Studio puede crear una nueva Web Exception a partir de un nombre de dominio sin importar primero una excepción existente. Es un procedimiento independiente; Bad regex y Apply Fix sirven para reparar entradas existentes, como se describe más adelante. La nueva excepción se prepara inicialmente de forma local y solo se aplica al firewall mediante la importación del TAR.

Antes de empezar, guardar en una ubicación protegida una copia de seguridad completa del firewall y una exportación selectiva sin modificar de WebFilterException del mismo firewall. Exportar WebFilterException y comprobarlo con Config Studio explica la exportación de Entities.xml, el tratamiento de los archivos y la descarga posterior. Registrar en el ticket de cambio un nombre que aún no se haya utilizado, el host de destino confirmado, la opción de omisión necesaria y el alcance previsto de clientes. Usar un nombre existente no es una forma segura de añadir otra entrada: la importación actualiza las excepciones existentes que coinciden. Un nombre cambiado crea una entrada nueva y no elimina la anterior.

1. Abrir Config Studio mediante el enlace de acceso que aparece más abajo, seleccionar Configuration editor e ir a Rules > Web exceptions.
2. Seleccionar Add e introducir el nuevo nombre único, por ejemplo Vendor API exact host no decrypt.
3. En Skip these checks, activar solo la opción necesaria para el caso. En el ejemplo de descifrado es Skip HTTPS decryption. Las demás opciones se llaman Skip policy check, Skip cert validation, Skip malware scan y Skip zero-day protection. Las consecuencias para la protección descritas anteriormente también se aplican al crear la entrada en el editor; no seleccionar varias opciones por precaución.
4. En Match by URL/Domain, elegir el alcance: Exact host only para únicamente el host confirmado, o Domain + all subdomains si todos sus subdominios son expresamente necesarios y están aprobados. Para updates.vendor.example, el ejemplo mantiene seleccionado Exact host only; cdn.updates.vendor.example no debe quedar incluido.
5. Introducir el nombre de dominio confirmado en el campo de texto, sin ruta URL, por ejemplo updates.vendor.example. Sustituir este valor de documentación por el host de destino real. La regex generada y la vista previa aparecen automáticamente; comprobar ambas con el alcance previsto y los casos positivos y negativos descritos anteriormente.
6. Seleccionar Add to URL Regex list. El patrón debe aparecer después en URL Regex Patterns. Un valor visible en la vista previa todavía no es una entrada añadida a la lista.
7. Opcionalmente, en URL Regex Patterns, se puede añadir directamente un patrón propio ya comprobado mediante + Add URL regex. No es necesario para la creación a partir de un dominio; los patrones adicionales amplían las posibles coincidencias debido a OR.
8. Por último, seleccionar Add en la parte inferior del formulario lateral. Solo entonces se crea la nueva excepción en el editor.

Antes de descargar, comparar en Preview el XML de importación con el estado previo guardado y el ticket de cambio. Solo debe añadirse la nueva excepción aprobada; no deben cambiarse involuntariamente nombres, criterios, estados de activación ni opciones de omisión existentes. El alcance de clientes también debe ser correcto: Exact host only limita el destino, no los orígenes. Si no se puede demostrar que la configuración generada incluye un origen piloto necesario, no importarla; utilizar en su lugar el procedimiento de WebAdmin descrito anteriormente con Source IP addresses. No añadir campos adicionales no verificados al XML.

Después, seleccionar Download > Download TAR y guardar el archivo en una ubicación protegida. Importar, comprobar el efecto y revertir cubre los mensajes de importación, la comparación antes y después en Web > Exceptions, la comprobación de la activación y las conexiones nuevas con pruebas positivas y negativas. La vista previa del XML o una importación correcta no sustituyen esta prueba del efecto sobre la protección. Ante un resultado inesperado, desactivar la nueva entrada de forma controlada y volver a comprobar la ruta normal de protección. Reimportar la exportación selectiva original no elimina automáticamente la excepción recién creada; eliminarla de forma específica solo después de aclarar las dependencias. Las excepciones existentes deben permanecer intactas.

Excluir una categoría en lugar de un único dominio

Si no se deben descifrar datos financieros confidenciales, la categoría Financial services puede ser el criterio adecuado. Sin embargo, una excepción de categoría abarca más destinos que un único host; la clasificación debe ajustarse al ámbito previsto.

1. En Web > Exceptions > Add an exception, introducir un nombre como Financial services no decrypt.
2. Activar Web site categories, seleccionar Add new item y elegir Financial services.
3. Confirmar con Apply selected items. Para el piloto, configurar también Source IP addresses con la IP del cliente y Add.
4. Seleccionar únicamente HTTPS decryption, elegir Save y activar el interruptor de la lista.
5. Probar un servicio financiero aprobado y un destino inofensivo fuera de la categoría mediante conexiones nuevas. Por la lógica AND, deben coincidir tanto el origen piloto como la categoría.

Las conexiones HTTPS coincidentes pierden el descifrado y las comprobaciones de contenido que dependen de él; también se aplica la consecuencia sobre los certificados descrita arriba. Esto no concede permiso general a la categoría ni significa que se desactiven todas las demás funciones de protección.

Excepción de malware para un host de descarga confirmado

Que un proveedor se considere de bajo riesgo no basta para desactivar el análisis. Si es necesaria una excepción justificada, utilizar el procedimiento anterior con un nombre propio, como Vendor download scan exception, el patrón del host confirmado y el origen piloto. Seleccionar Malware and content scanning en lugar de HTTPS decryption. Zero-day protection se selecciona automáticamente; las excepciones antiguas que omiten el análisis de malware también omiten el análisis Zero-Day. Después, elegir Save y activar el interruptor. Las descargas coincidentes quedan sin análisis de malware y contenido ni análisis Zero-Day, incluidos sus informes. No desmarcar además las otras comprobaciones. Verificar la ruta de protección prevista con una descarga inofensiva y controlada desde el host aprobado y un destino de comparación no excluido; una descarga correcta por sí sola no basta.

Introducir otros criterios y gestionar excepciones existentes

Introducir en Destination IP addresses la IP confirmada del sitio web y pulsar Add, no la IP del cliente. En las combinaciones permitidas del criterio de destino con URL o categoría, deben coincidir todos los tipos seleccionados. Los patrones URL usan caracteres ASCII; los nombres de dominio internacionalizados se escriben en Punycode. Matching URLs de la excepción predeterminada Apple Update puede servir de ejemplo de sintaxis, no de plantilla de autorización sin verificar.

Exclusión TLS: indicaciones contradictorias sobre el alcance. Las páginas Add an exception de SFOS 22.0 y 23.0 describen la lógica general AND entre tipos de criterios, pero Exclude a website from TLS inspection indica expresamente que no se pueden combinar excepciones de origen y destino. El alcance exacto de esa restricción no está claro; la lógica general de coincidencia no demuestra que la combinación esté permitida. Combinar Source IP addresses y Destination IP addresses no es, por tanto, un procedimiento permitido verificado. Antes de activar una exclusión TLS, confirmar la compilación real de SFOS, la ruta DPI/proxy, la omisión necesaria y el alcance limitado de host/categoría. Mantener el origen piloto junto con el nombre de host o la categoría confirmados del procedimiento anterior, sin añadir un criterio de IP de destino. Destino más nombre de host/categoría confirmados solo es una opción separada si el alcance de clientes está limitado de forma independiente y aprobado. No sustituir la restricción prevista por una excepción solo de origen ni eliminar un criterio simplemente para lograr una coincidencia: eso amplía la omisión de protecciones. Si son necesarias restricciones tanto de IP de origen como de destino, detenerse sin activar ni ampliar la exclusión y solicitar a Sophos Support una aclaración para la compilación concreta junto con el responsable del firewall.

Las excepciones predeterminadas permiten actualizaciones de software y otras funciones importantes de los sitios web. En Web > Exceptions, Edit abre una excepción existente y Clone crea una copia. Revisar todos los criterios y opciones de omisión heredados antes de activarla. Web > General settings controla la validación general de certificados HTTPS; una excepción de certificado individual no sustituye esa configuración básica.

Entender el efecto de las opciones de omisión

Antes de guardar debe estar claro qué protección se pierde.

HTTPS decryption

El firewall no descifra el tráfico HTTPS coincidente. Por tanto, tampoco puede realizar comprobaciones que necesiten el contenido descifrado. Sophos también documenta que para esta coincidencia se permite el tráfico con un certificado de servidor no válido.

Si el problema solo procede de una particularidad del certificado, esta opción suele ser demasiado amplia. Primero se comprueba si HTTPS certificate validation es la excepción más precisa.

HTTPS certificate validation

El firewall omite la comprobación de validez del certificado del servidor. El descifrado configurado puede continuar. Esta excepción solo es adecuada para un destino conocido con un problema de certificado aceptado conscientemente y requiere una fecha de revisión cercana.

Siempre que sea posible, un certificado caducado, con nombre incorrecto o no confiable debe repararse en el sistema de destino. La distribución de la Inspection CA correcta resuelve otro problema y se explica en Distribuir el certificado de CA para TLS Inspection.

Malware and content scanning

El firewall omite el análisis de malware y contenido para la coincidencia. Así también se omite automáticamente Zero-day protection. Por tanto, una única selección elimina dos capas de protección de la ruta de datos.

Antes de crear esta excepción se comprueban el tipo de archivo, el límite de análisis, el cifrado, la acción en caso de error y la descarga que realmente coincide. El flujo completo de pruebas está en Configurar y probar el análisis de malware.

Zero-day protection

Se omite el análisis Zero-Day. No se crean informes de análisis para los archivos coincidentes, aunque el análisis clásico de malware devuelva una detección. Esta opción es más limitada que omitir por completo Malware and content scanning.

Policy checks

Se omiten las comprobaciones de Web Policy para la solicitud coincidente. Una excepción de este tipo puede dejar sin efecto categorías, lógica de usuarios o grupos y otras decisiones de políticas. Solo debe utilizarse para un problema de política claramente demostrado, no como solución general para un sitio web bloqueado.

Esto no autoriza a usar Policy checks para levantar el bloqueo absoluto documentado de highly objectionable criminal activity descrito arriba.

Comprobar el efecto con pruebas positivas y negativas

Que una página se cargue correctamente solo demuestra que algo ha cambiado. Todavía no demuestra que la excepción sea precisa.

1. Registrar la hora, el cliente piloto, el host de destino y el resultado esperado.
2. Cerrar la sesión existente del navegador o la aplicación y crear una nueva conexión.
3. Repetir la solicitud afectada.
4. En Log Viewer, comparar la IP de origen, el host de destino, la Web Policy, el Firewall Rule ID y la acción.
5. Para una excepción de descifrado, comparar el certificado de servidor visible para el cliente con el estado anterior al cambio.
6. Abrir un destino similar que no se haya excluido.
7. Comprobar que este destino sigue cubierto por la Web Policy, la Decryption Rule y la cadena de análisis normales.
8. Desactivar brevemente la excepción y reproducir el error original si es seguro hacerlo durante la ventana de mantenimiento.
9. Volver a activar la excepción y confirmar de nuevo el resultado.

Si QUIC o HTTP/3 evita la ruta TLS sobre TCP esperada, la prueba puede resultar engañosa. La delimitación está en Bloquear QUIC y HTTP/3 correctamente. Log Viewer, Policy Tester y Packet Capture muestran qué regla y política coinciden realmente.

El Policy tester se abre en Diagnostics > Tools, en la sección Pop-out tools. El método Firewall, SSL/TLS, and web ayuda a identificar la regla de firewall, la SSL/TLS inspection rule y la Web Policy esperadas. Sin embargo, solo prueba el tráfico web en Transparent Mode, por lo que no representa un flujo direct web proxy explícito. Siempre debe confirmarse que la Web Exception se aplica mediante una solicitud nueva y logs reales.

Para disponer de evidencias en los logs, Log firewall traffic debe estar activo en la regla de firewall; también debe activarse Log connections en la SSL/TLS inspection rule. En System services > Log settings, los tipos de log correspondientes deben estar activos para Local reporting. Después se limita Log Viewer a la hora de la prueba y a la IP de origen, y se comparan los módulos Web filter y SSL/TLS inspection con el Firewall Rule ID, la política y la Action. Utilizar correctamente Sophos Firewall Log Viewer explica los controles. Si toda la vista permanece vacía, se sigue Log Viewer no se actualiza en lugar de ampliar la excepción por conjeturas.

Delimitar los errores sistemáticamente

La excepción no se aplica

• El bloqueo absoluto documentado de una categoría no es un error de coincidencia. Un dominio ocultado intencionadamente no es aquí un fallo de logging. Las categorías web y Web Policies explican el límite; no intentar una excepción más amplia ni tests contra ese contenido.
• El interruptor de Web > Exceptions no está activado.
• Un tipo de criterio adicional no coincide debido a la lógica AND.
• La regex no está anclada al principio o no representa el hostname real.
• En una excepción de ruta HTTPS, el tráfico no se descifra y por eso la ruta no es visible.
• En DPI Mode no está activa para el flujo ninguna Web Policy, Malware and content scanning ni ATP.
• Se aplica otra regla de firewall, Web Policy o modo operativo diferente del esperado.
• No se ha creado de nuevo la sesión del navegador o la aplicación.

La excepción se aplica de forma demasiado amplia

• El patrón contiene un wildcard sin control o solo el texto de un root domain aislado.
• Faltan Source IP addresses u otro ámbito de piloto.
• Varios patrones de URL dentro del mismo tipo tienen un efecto más amplio de lo previsto debido a OR.
• Se ha excluido una Web category completa en lugar del host concreto.
• Se han activado varias opciones de omisión aunque solo una comprobación causa el problema.

El sitio web funciona, pero el efecto sobre la protección no está claro

La excepción no se amplía. Primero se comparan el certificado del navegador, los logs de Web y SSL/TLS Inspection, el Firewall Rule ID, la Web Policy y una descarga controlada. Sin estas pruebas, la excepción solo es un workaround funcional, todavía no una decisión de seguridad aceptada.

Si las herramientas de WebAdmin no permiten aislar la causa, Asignar correctamente los logs de servicio de Sophos Firewall relaciona los logs de DPI, proxy, malware y Zero-Day con la ruta de protección afectada. El debug no se activa como primer paso.

Uso elevado de CPU y acceso web lento tras cambios de regex

En Diagnostics > System graphs, comparar primero los momentos y la evolución de la carga con las solicitudes lentas y los últimos cambios de excepciones. En Web > Exceptions, revisar Selection criteria o Matching URLs de todas las excepciones activas: ¿faltan ^, puntos escapados del host o un límite claro del host? ¿Hay wildcards amplios o muchos textos de dominio sin anclar?

Con acceso autorizado a la consola, ejecutar el siguiente comando de solo lectura en Device Management > Advanced Shell. Muestra la carga actual de los procesos, pero no modifica la configuración; salir de la vista con q.

top

Si awarrenhttp o snort encabezan el uso de CPU, las regex de Web Exceptions pueden contribuir a la carga. Es un indicio, no una prueba de que sean la única causa: ambos procesos realizan otras comprobaciones. Investigar conjuntamente la carga, las solicitudes y los patrones, realizar solo un cambio limitado y volver a medir con una carga de tráfico comparable. Si la CPU sigue alta, seguir delimitando otras causas en la ruta de protección afectada; no desactivar indiscriminadamente la inspección o todas las excepciones como prueba comparativa.

Reparar selectivamente las regex existentes

Para unas pocas excepciones, Web > Exceptions > Edit es la vía más clara. Conservar primero nombres, estado de activación, criterios y opciones de omisión; después corregir únicamente el patrón URL probado. Para muchos registros, se puede exportar el módulo WebFilterException. Esta exportación incluye las configuraciones de Web Exceptions seleccionadas, no automáticamente solo la excepción defectuosa. Los registros sin cambios también deben conservarse en la comparación anterior y posterior.

Antes de cualquiera de las dos variantes de importación, guardar de forma segura un backup actual del firewall y una exportación selectiva sin modificar. Aclarar la vía de reversión, la ventana de mantenimiento y el acceso de administración antes de importar. Una exportación selectiva no sustituye un backup completo. Conservar por separado el archivo original, la copia de trabajo y el resultado aprobado; las configuraciones y los informes generados contienen detalles internos y solo deben almacenarse en un equipo de administración autorizado y con acceso protegido.

Exportar WebFilterException y comprobarlo con Config Studio

1. En el mismo firewall, abrir Backup & firmware > Import export y seleccionar Export selective configuration.
2. Buscar WebFilterException mediante Add new item y confirmar con Apply selected items. No seleccionar Include dependent entity: no deben modificarse otras áreas de configuración junto con esta.
3. Guardar el archivo API-[timestamp].tar con Export o Download. Extraer una copia de trabajo; contiene Entities.xml.
4. Abrir Sophos Firewall Config Studio. Seleccionar Configuration editor y Rules > Web exceptions, y cargar la Entities.xml selectiva mediante Import.
5. En Config Analysis, buscar Bad regex. Abrir el registro afectado con Edit, revisar la propuesta mediante Apply Fix y confirmar con Update. No cambiar nombres; si cambia el nombre, la importación del firewall crea una excepción nueva en lugar de actualizar la existente.
6. Comprobar la propuesta con casos positivos, negativos y entradas largas que no deben coincidir. Para los patrones de host nuevos, Exact host only y Domain + all subdomains distinguen el alcance deseado; la reparación no debe permitir subdominios de forma accidental. Una corrección automática no sustituye esa decisión ni la prueba del efecto sobre la protección.
7. En Preview, revisar la configuración de importación y compararla con la original: solo deben cambiar las regex aprobadas, no los nombres, orígenes, criterios de destino, activación ni opciones de omisión. Guardar el archivo aprobado mediante Download > Download TAR.

Config Studio procesa los datos de configuración en el navegador del equipo; el análisis sintáctico, el análisis y la generación de informes no suben estos datos al exterior. Aun así, los archivos locales, descargas e informes HTML siguen siendo confidenciales. No transferir configuraciones a otras herramientas de análisis online. Editar o descargar en Config Studio todavía no modifica nada en el firewall.

Alternativa: editar Entities.xml de forma controlada

Sin Config Studio, editar la misma copia de trabajo exportada selectivamente en un editor de texto. Cambiar solo los patrones URL afectados; no sustituir todos los puntos del archivo XML de forma indiscriminada. Mantener sin cambios la estructura XML, los nombres de objetos y los demás campos. Antes de empaquetar, comprobar que el XML esté bien formado y revisar el diff completo. No importar si la sintaxis no está clara o aparecen archivos adicionales inesperados.

Mantener exactamente el nombre Entities.xml y empaquetar los archivos en un TAR nuevo con la misma estructura que el original, no en ZIP ni dentro de una carpeta adicional. Si el original contiene otros archivos, no descartarlos silenciosamente. Este procedimiento sencillo de Web Exceptions no debe aplicarse a otros módulos ni a objetos sensibles e interdependientes.

Importar, comprobar el efecto y revertir

La importación sobrescribe los ajustes existentes que coincidan. Subir correctamente un archivo no demuestra una coincidencia limitada ni una protección sin cambios. Aprobar primero el diff e importar después en la ventana de mantenimiento acordada.

En Backup & firmware > Import export > Import, seleccionar el .tar revisado con Browse y ejecutar Import. Revisar si los mensajes de importación contienen errores; después, en Web > Exceptions, comparar nombres y número de registros, activación, Matching URLs, criterios y opciones de omisión con el estado previsto. Los ajustes sin un registro de importación coincidente permanecen; la importación no elimina automáticamente excepciones adicionales no deseadas.

Después, crear conexiones nuevas, repetir los tests positivos y negativos existentes con logs y, si se ha reparado un problema de rendimiento, comparar la evolución de la CPU y la carga de procesos con la referencia inicial. Si hay errores, detener el despliegue y desactivar de forma controlada la excepción afectada, siempre que el impacto en la aplicación sea aceptable. Para una restauración selectiva, puede importarse la exportación selectiva sin modificar del mismo firewall; descartar antes cambios intermedios, pues también se sobrescribirían. No reactivar sin revisar un estado anterior que se haya demostrado demasiado amplio. La restauración de un backup completo sigue siendo una vía de emergencia planificada aparte, no el primer paso de reversión para una regex individual. Después de cada reversión, volver a comprobar la configuración y la ruta de protección.

Planificar WebFilterException mediante la XML API

La importación selectiva de Entities.xml descrita arriba no es una receta general para la XML API. Las referencias de objetos para SFOS 22.0 y 23.0 describen Add Web Filter Exception / Update Web Filter Exception con el objeto WebFilterException. Las siguientes correspondencias ayudan a revisar una automatización planificada; no constituyen una solicitud completa, lista para enviar ni probada en un firewall. El acceso, las credenciales protegidas, la operación explícita, la estructura envolvente de la solicitud específica de la versión y la evaluación segura de la respuesta forman parte del procedimiento central Utilizar la XML API de forma segura. No se realizan operaciones de escritura sin una sintaxis confirmada para la compilación concreta.

Distinguir la activación, las opciones de omisión y DomainList

Enabled activa la excepción y admite on u off. Las cinco opciones de omisión también admiten on u off, pero indican que se omite una comprobación, no que se activa: HttpsDecrypt para el descifrado HTTPS, VirusScan para el análisis de malware, PolicyCheck para las comprobaciones de Web Policy, ZeroDayProtection para la protección Zero-Day y CertValidation para la validación de certificados HTTPS. Por tanto, on en una opción de omisión significa que se elude una protección. Siguen siendo aplicables las consecuencias sobre la protección explicadas arriba, en particular la omisión automática de Zero-Day al omitir el análisis de malware. No deducir de una opción de omisión activada que una entrada ya esté activa o sea adecuada.

La referencia muestra criterios repetibles bajo DomainList e interruptores separados en el objeto:

• EnableSrcIP con SrcIp: comprobación de la IP de origen; aquí corresponde la dirección del cliente.
• EnableDstIP con DstIp: comprobación de la IP de destino; aquí corresponde la dirección del sitio web.
• EnableURLRegex con URLRegex: comprobación de patrones de URL, no una lista de dominios con subdominios incluidos automáticamente.
• EnableWebCat con WebCategory: comprobación de categorías web.

Los cuatro interruptores son valores escalares yes/no, no on/off. Los cuatro criterios son arrays de strings que admiten varios valores; para cada entrada de SrcIp y DstIp, la referencia indica un máximo de 43 caracteres. Un array simplemente rellenado no sustituye un interruptor de activación confirmado. Según la lógica de coincidencia, los distintos tipos de criterios activados deben coincidir mediante AND, y los valores dentro de un mismo tipo mediante OR. Por tanto, los patrones de URL adicionales pueden ampliar la coincidencia. Sigue vigente la restricción TLS sin resolver documentada arriba para las excepciones que combinan IP de origen y de destino: la existencia de ambos campos de la API no demuestra que la combinación esté permitida. No generar una omisión de protecciones más amplia eliminando un criterio.

Para URLRegex siguen siendo necesarios los anclajes al principio, los puntos escapados del host, un límite claro del host, ASCII/Punycode y pruebas positivas, negativas y con entradas largas que no deben coincidir. El patrón de la referencia de la API no es una lista de permitidos aprobada y no sustituye estas pruebas ni el límite de las rutas HTTPS. La comprobación de la sintaxis XML por sí sola no demuestra una coincidencia segura.

Name es el único parámetro marcado como obligatorio: un string escalar de un máximo de 60 caracteres; se excluyen ^, ;, ', " y \. El parámetro opcional NewName sirve para cambiar el nombre y tiene los mismos límites. No equivale a crear una entrada nueva mediante un nombre cambiado en la importación selectiva. Desc es un string escalar opcional de un máximo de 250 caracteres; IsDefault identifica una excepción predeterminada mediante un valor escalar yes/no y no concede permiso para modificar objetos predeterminados. Los demás parámetros son opcionales y sus columnas de valores predeterminados están vacías. De ello no se deduce ningún valor predeterminado concreto ni una garantía de que los valores omitidos se conserven al actualizar. Guardar primero el estado almacenado y definir la comparación completa entre el estado previsto y el real.

Interpretar las respuestas según la operación, el código y el símbolo

Ambas referencias de objetos contienen exactamente estas correspondencias. Los nombres de las operaciones y los símbolos se mantienen deliberadamente sin cambios:

Estos códigos XML no son códigos de estado HTTP. Message.* sigue siendo un símbolo de documentación sin resolver, no un mensaje verificado en tiempo de ejecución ni una causa de error inequívoca. En particular, no debe deducirse ningún máximo numérico de Message.WebExceptionsLimit. Add y Update tienen símbolos de éxito y error diferentes; las correspondencias de Add para 502 y 522 no se trasladan a Update.

Guardar de forma protegida la respuesta real junto con la operación y el código XML, también en caso de timeout o de resultado incierto. Antes de cada nuevo intento de escritura, comprobar la entrada realmente almacenada mediante una consulta de lectura confirmada para la compilación concreta o en Web > Exceptions: el nombre anterior y, si procede, el nuevo, el número de entradas, la activación, todos los criterios y las opciones de omisión. Ni siquiera un éxito notificado sustituye esta comparación. Si existe una entrada, no volver a crearla, cambiarle el nombre, sobrescribirla ni eliminar criterios a ciegas. Si el estado no está claro o se ha modificado parcialmente, detenerse y aclararlo con el responsable del firewall a partir de la respuesta, el estado previo y el estado previsto. Tras un cambio confirmado, establecer conexiones nuevas y realizar las pruebas positivas y negativas existentes; solo estas comprueban el efecto sobre la protección. La guía central de la API explica además las advertencias, los éxitos parciales y el procedimiento seguro sin reintentos a ciegas.

Revisión y rollback

Cada Web Exception productiva incluye al menos:

• justificación técnica y ticket
• responsable de la aplicación y del firewall
• hosts, rutas, orígenes y grupos de usuarios afectados
• comprobaciones exactas que se omiten
• fecha de las pruebas positivas y negativas
• fecha de revisión o caducidad
• estado anterior documentado

Para el rollback, primero se desactiva la excepción en lugar de eliminarla inmediatamente. Después se vuelven a probar el error original, la ruta de protección normal y los destinos no afectados. La excepción solo se elimina cuando ya no existe ninguna dependencia.

Las excepciones predeterminadas y del fabricante no se modifican sin control. En una excepción propia debe quedar claro por qué existe y quién volverá a evaluarla más adelante.

Lista de comprobación operativa

• DPI Mode o Web Proxy Mode identificado.
• Regla de firewall y Web Policy que coinciden realmente confirmadas.
• Hostname y, cuando procede, ruta URL capturados del tráfico real.
• Regex anclada al principio y probada contra no coincidencias.
• Considerados AND entre tipos de criterios y OR dentro de un tipo.
• Seleccionada solo la opción mínima necesaria.
• Considerada la omisión automática de Zero-Day con Malware and content scanning.
• Origen piloto limitado.
• Pruebas positivas y negativas realizadas.
• Log Viewer, certificado y efecto sobre la protección comprobados conjuntamente.
• Responsable, ticket, fecha de revisión y rollback documentados.

Preguntas frecuentes