Crear y utilizar URL Groups de forma segura en Sophos Firewall

Un URL Group agrupa dominios concretos para utilizarlos conjuntamente en una Web Policy o una SSL/TLS inspection rule. Aunque parece sencillo, tiene una consecuencia importante: cada cambio en el grupo afecta a todas las reglas y políticas que hacen referencia a este objeto.

Por eso, el procedimiento seguro no empieza con una lista del fabricante tan amplia como sea posible. Primero se identifican en una solicitud, un registro o la documentación del fabricante los dominios que se utilizan realmente. Después se crea un grupo pequeño con finalidad, responsable y plan de pruebas claros.

URL Group en siete pasos

1. Documentar el cliente afectado, los hosts de destino reales y la decisión deseada: permitir, bloquear o no descifrar.
2. Comprobar que un URL Group sea realmente adecuado. Procesa dominios, pero no rutas URL, cadenas de consulta ni expresiones regulares.
3. En Web > URL groups > Add, definir un nombre descriptivo y aceptar cada nombre de dominio válido con Add.
4. Seleccionar el grupo como Activity en una Web Policy o en Categories and websites de una SSL/TLS inspection rule.
5. Comprobar el orden de las reglas, el estado, el ámbito de origen y el registro. Un grupo por sí solo todavía no permite ni bloquea nada.
6. Probar con una conexión nueva una coincidencia esperada y una no coincidencia deliberadamente similar.
7. Documentar la lista de dominios, los consumidores, el responsable, el motivo, la fecha de prueba y el rollback.

⚠️ Varios dominios dentro de un URL Group se evalúan con OR. Basta una sola coincidencia. En las exclusiones TLS, una entrada de dominio también incluye sus subdominios. Por tanto, un dominio raíz demasiado amplio o una regla Allow situada muy arriba pueden abarcar mucho más tráfico del previsto.

Qué controla un URL Group y qué no

Un URL Group es un objeto de dominio reutilizable. Describe qué dominios deben agruparse. Después, la regla que lo consume decide qué ocurre con la coincidencia.

Usos habituales:

• una pequeña allowlist empresarial en una Web Policy
• una blocklist explícita para dominios conocidos
• una lista de dominios en una regla Don't decrypt
• la lista local de exclusiones TLS para problemas de descifrado confirmados

Sin embargo, un URL Group no es la herramienta adecuada para todos los casos web:

• Web category: clasificación general de contenido o categoría propia con rutas URL o palabras clave
• Web Exception: coincidencia basada en regex y omisión selectiva de comprobaciones web, de análisis o de certificados
• FQDN Host: objeto de red basado en DNS para reglas de firewall, NAT o routing
• Threat Feed: listas de IOC o dominios mantenidas dinámicamente

Configurar Web Protection con Web Policies explica la lógica completa de las políticas. La elección entre una categoría propia y una lista de dominios se trata en Utilizar web categories e Instant Alerts. Para listas de seguridad dinámicas, se recomiendan los Threat Feeds de Sophos Firewall.

Dominio en lugar de URL completa

En Search/Add, SFOS espera un nombre de dominio válido. El protocolo, la ruta y la consulta no deben introducirse en este campo.

Valores de ejemplo válidos:

updates.vendor.example
cdn.vendor.example

Valores inadecuados:

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

La terminación .example está reservada para documentación. En la configuración real, los ejemplos se sustituyen por los dominios confirmados en el registro, la solicitud o la documentación del fabricante.

Si se necesita una ruta URL concreta, un parámetro de consulta o una expresión regular, según el objetivo resulta adecuada una web category propia o una Web Exception limitada de forma segura. La lista de dominios no se amplía con un patrón comodín aparentemente práctico.

Planificar el ámbito de dominios

El ejemplo utiliza el grupo Vendor update domains con dos hosts separados:

• updates.vendor.example para la descarga de actualizaciones
• cdn.vendor.example para el endpoint de contenido asociado

El dominio raíz vendor.example no se utiliza deliberadamente como abreviatura. Sophos documenta expresamente que los subdominios se incluyen al hacer coincidir URL Groups en exclusiones TLS. Por tanto, una entrada vendor.example también incluiría en este flujo login.vendor.example, telemetry.vendor.example y otros subdominios.

Incluso una entrada más limitada puede incluir subdominios. En una coincidencia TLS, updates.vendor.example puede abarcar también api.updates.vendor.example. Si solo se espera un host concreto, además del destino positivo siempre se prueba como destino negativo un host deliberadamente similar.

Varias entradas en el mismo grupo no constituyen una lista obligatoria. Debido a la lógica OR, basta con que coincida un dominio. Si un servicio solo funciona cuando dos hosts son accesibles a la vez, cada host debe probarse por separado. El URL Group no demuestra ninguna dependencia funcional entre ellos.

Crear un URL Group

1. Abrir Web > URL groups.
2. Seleccionar Add.
3. Definir un nombre como Vendor update domains.
4. Introducir updates.vendor.example en Search/Add.
5. Seleccionar Add y comprobar que el valor aparece en la lista.
6. Añadir cdn.vendor.example del mismo modo.
7. Seleccionar Save.
8. Volver a abrir el grupo guardado y comprobar el nombre y ambos dominios.

Pulsar Add es un paso independiente. Un nombre de dominio que solo permanece en el campo de entrada todavía no forma parte del grupo.

La ayuda actual de SFOS 22 no especifica un número máximo fijo de dominios por URL Group. Esto no garantiza una lista ilimitada. Si se esperan cientos de entradas, cambios frecuentes del fabricante o IOC que varían continuamente, un URL Group mantenido manualmente suele ser el modelo operativo equivocado.

Utilizar un URL Group en una Web Policy

Un URL Group solo adquiere un efecto Allow, Warn, Block o Quota mediante una regla de Web Policy.

1. Abrir Web > Policies.
2. Editar la política afectada o crear una nueva.
3. Seleccionar Add rule.
4. En Users, definir el ámbito previsto de usuarios o grupos.
5. En Activities, desmarcar la selección general All web traffic y seleccionar el URL Group Vendor update domains.
6. Definir la acción deseada para HTTP y HTTPS, por ejemplo Allow o Block.
7. Comprobar la posición de la regla, activar su estado y guardar la política.
8. En Rules and policies > Firewall rules, comprobar que esta Web Policy esté seleccionada en Web filtering dentro de la regla de firewall que realmente coincide.
9. Activar Log firewall traffic para la validación.

Las reglas de una Web Policy se evalúan de arriba abajo. Una regla Allow general situada por encima de la nueva regla de URL Group puede ocultar la coincidencia. A la inversa, una regla Allow específica colocada demasiado arriba puede anular reglas Block posteriores. Por tanto, la posición forma parte de la decisión de seguridad y no es solo una cuestión de presentación.

Un URL Group en una Web Policy no sustituye una regla de firewall. La regla de firewall permite primero el flujo de datos entre las zonas y, después, la Web Policy asignada evalúa el acceso web. Probar reglas con Log Viewer, Policy Tester y Packet Capture muestra qué regla y política se aplican realmente.

Utilizar un URL Group como exclusión TLS

Para problemas confirmados de Certificate Pinning u otros problemas de descifrado, el mismo tipo de objeto puede utilizarse en una SSL/TLS inspection rule con Action: Don’t decrypt. SFOS compara el dominio de forma eficiente como texto mediante Server Name Indication, abreviado SNI.

Existen dos variantes claras.

Completar la Local TLS exclusion list

La Local TLS exclusion list es un URL Group integrado y está vacía de forma predeterminada. Pertenece a la regla de exclusión predeterminada permanente situada en la parte superior de la tabla de reglas SSL/TLS.

La ruta manual es:

Web > URL groups > Local TLS exclusion list

Esta variante es adecuada para una exclusión de dominio confirmada localmente que deba aplicarse con independencia de una regla propia más limitada por origen o usuario. También se pueden añadir dominios a esta lista mediante las funciones de resolución de problemas del Control Center o del Log Viewer. Por eso, cada dominio nuevo se documenta y se prueba como una excepción de seguridad productiva.

La Managed TLS exclusion list cumple otra función. Sophos mantiene en ella dominios incompatibles conocidos y puede actualizarla mediante actualizaciones de firmware. Los dominios operativos propios no sustituyen una regla local deliberada dentro de este objeto gestionado por el fabricante.

Crear una regla Don’t decrypt propia

Si la excepción debe limitarse a determinados orígenes, usuarios, servicios o zonas de destino, una regla propia es más fácil de auditar:

1. Abrir Rules and policies > SSL/TLS inspection rules.
2. Seleccionar Add.
3. Definir un nombre como Vendor updates no decrypt.
4. Seleccionar Action: Don’t decrypt.
5. Activar Log connections.
6. Limitar Source zones, Source networks, Users, Destination zones y Services al ámbito necesario.
7. En Categories and websites, seleccionar el URL Group Vendor update domains.
8. Situar la regla directamente debajo de las exclusiones predeterminadas y por encima de las reglas Decrypt generales.
9. Guardar y probar con una conexión nueva.

Las SSL/TLS inspection rules funcionan de forma independiente de las reglas de firewall. Por ello, una regla de firewall que coincide correctamente no demuestra que se aplique la regla TLS deseada. A la inversa, Don’t decrypt solo excluye el descifrado de este flujo. No es una autorización general para tráfico de red arbitrario.

Los URL Groups son más eficientes para esta coincidencia SNI que muchos FQDN Host Objects en el origen o destino de una regla TLS. Los FQDN Host Objects se resuelven mediante DNS y cumplen otra función. Crear y utilizar FQDN Hosts de forma segura explica las diferencias.

Si la conexión TLS no contiene un SNI utilizable, el dominio no puede reconocerse de este modo. El grupo no debe ampliarse con un dominio raíz. Primero se comprueban la IP de destino, el certificado, Packet Capture y el flujo real de la aplicación.

Comprobar la coincidencia con pruebas positivas y negativas

Que una página se cargue correctamente solo demuestra que el servicio es accesible. No demuestra ni la regla de Web Policy correcta ni la exclusión TLS deseada.

Prueba de Web Policy

1. Anotar el cliente piloto, el usuario, la hora y la acción esperada.
2. Cerrar por completo la sesión del navegador o la aplicación y reiniciarla.
3. Abrir updates.vendor.example o el dominio positivo real.
4. En Log Viewer, comprobar Source, User, Domain, Firewall Rule ID, Web Policy y Action.
5. Probar login.vendor.example o un host real que se haya dejado fuera deliberadamente.
6. Confirmar que el host negativo sigue siendo evaluado por la regla de política posterior normal.
7. Si se necesitan dos valores del grupo, probar cada host por separado.

Si el navegador utiliza QUIC o HTTP/3, el flujo web TCP esperado puede ser diferente. Primero se distingue la prueba frente a QUIC y HTTP/3.

Prueba de exclusión TLS

1. Establecer una nueva conexión TLS con el host positivo.
2. En el registro SSL/TLS, comprobar la regla coincidente y el estado de no descifrado.
3. Comparar el certificado visible para el cliente con el estado de la regla de descifrado normal.
4. Abrir un host negativo similar que no esté en el grupo.
5. Confirmar que este host sigue siendo procesado por la regla Decrypt esperada.
6. Documentar el ámbito de origen, el SNI y la posición de la regla.

Para una prueba de rollback deliberada, durante una ventana de mantenimiento se restablece el estado anterior documentado de la regla web o TLS que consume el grupo. El host positivo debe volver a mostrar el comportamiento anterior. Solo esta contraprueba convierte un workaround funcional en una validación reproducible.

Delimitar los errores sistemáticamente

El URL Group no se aplica en la Web Policy

• El dominio se introdujo, pero no se aceptó con Add.
• El URL Group no está seleccionado en Activities de la regla de política activa.
• All web traffic u otra regla anterior coincide primero.
• La regla de política está desactivada.
• La Web Policy no está seleccionada en la regla de firewall que realmente coincide.
• La solicitud real utiliza un host de redirección, inicio de sesión, API o CDN no documentado.
• No se restableció una conexión existente del navegador o QUIC.

La exclusión TLS no se aplica

• El URL Group no está seleccionado en Categories and websites de la regla esperada.
• La regla Don't decrypt está debajo de una regla Decrypt que ya coincide.
• Source, User, Zone, Service u otro criterio de la regla no coincide.
• La conexión no envía un SNI utilizable.
• El host TLS real difiere de la URL visible en el navegador.
• La sesión TLS existente siguió utilizándose después del cambio.

El URL Group se aplica con demasiada amplitud

• Se introdujo un dominio raíz en lugar de los hosts realmente necesarios.
• Una entrada incluye subdominios adicionales en la coincidencia TLS.
• El grupo se utiliza en varias políticas o reglas TLS.
• Una regla Allow está situada demasiado arriba o se aplica a demasiados usuarios.
• La Local TLS exclusion list tiene un efecto más amplio que una regla propia limitada por origen.

En este caso no se añade otro dominio. Primero se comprueban todos los usos del grupo, el orden real de las reglas y la prueba negativa.

Operar los cambios y el rollback de forma segura

Antes de modificar un URL Group en producción se registran:

• la lista de dominios anterior
• las Web Policies y SSL/TLS inspection rules que hacen referencia al grupo
• el responsable y el motivo técnico
• los usuarios, orígenes y servicios afectados
• los casos de prueba positivos y negativos
• la fecha de revisión o caducidad

Un grupo compartido no se amplía silenciosamente por una incidencia individual. Si una web allowlist y una exclusión TLS tienen responsables o ciclos de vida diferentes, resulta más claro utilizar URL Groups separados, aunque algunos dominios sean idénticos.

Para el rollback, primero se restablece el estado de la regla o política que consume el grupo, o se elimina únicamente el dominio añadido recientemente. El grupo completo solo se elimina cuando ninguna otra política o regla depende de él. Después se vuelven a comprobar las conexiones nuevas para los hosts positivo y negativo, así como los registros.

Lista de comprobación operativa

• Se ha confirmado que un URL Group es la herramienta adecuada.
• Solo se han introducido dominios válidos, sin protocolos, rutas, comodines ni regex.
• Se ha limitado deliberadamente el efecto de dominio raíz y subdominios.
• Se ha tenido en cuenta la lógica OR entre varios dominios.
• Se han documentado el nombre del grupo, el responsable, el objetivo y la fecha de revisión.
• Se ha identificado claramente la Web Policy o SSL/TLS inspection rule consumidora.
• Se han comprobado el estado, la posición, el ámbito de origen y el registro de la regla.
• La Web Policy está seleccionada en la regla de firewall correcta.
• Para una exclusión TLS, se han confirmado el SNI y la regla Don't decrypt.
• Se han realizado pruebas positivas y negativas con conexiones nuevas.
• Se han guardado las referencias y el estado anterior para el rollback.

Preguntas frecuentes