Usar correctamente FQDN hosts y wildcard FQDNs en Sophos Firewall

Los hosts FQDN son útiles cuando un destino no se puede describir de manera confiable con una dirección IP fija. Ejemplos típicos son los servicios en la nube, servidores de actualización, puntos finales de autenticación o servicios de proveedores cuyas direcciones IP pueden cambiar.

Un host FQDN no reemplaza una política web, ni un control total de URL ni una garantía de que todas las aplicaciones coincidan limpiamente. La pregunta importante es cómo Sophos Firewall resuelve el nombre o, en el caso de los comodines, lo aprende del tráfico DNS.

Cuándo tienen sentido los FQDN hosts

Los hosts FQDN se ajustan a reglas en las que un destino técnico se describe mejor mediante un nombre DNS que mediante direcciones IP individuales. Esto es especialmente útil para el tráfico saliente.

Ejemplos útiles:

• Un servidor interno solo puede conectarse a updates.vendor.example.
• Una aplicación necesita acceso a algunos FQDN de proveedores conocidos.
• Se debe utilizar un punto final de nube específico en una regla de firewall, regla NAT, ruta SD-WAN o configuración de VPN.
• Un caso de solución de problemas debe mostrar si una regla coincide con el nombre esperado o con una dirección IP inesperada.

Los hosts FQDN son menos adecuados para un acceso web amplio, como “todo bajo un servicio SaaS”, cuando la aplicación utiliza muchos dominios, CDN, API, telemetría y puntos finales de inicio de sesión. Para el tráfico web, las políticas web, los grupos de URL, la protección DNS, el control de aplicaciones o la inspección TLS suelen ser la mejor capa de control.

Sophos Firewall puede usar hosts FQDN no solo en reglas de firewall, sino también en configuraciones como SD-WAN policy routes, VPN settings y objetos técnicos para servidores de correo, proxy, DNS, autenticación, remote access, web o syslog. Aun así, conviene comprobar en cada uso si un nombre DNS es realmente más estable que un objeto IP o una capa de política dedicada.

Para la regla de firewall en sí, comience con entender y configurar reglas de Sophos Firewall de forma segura. Si una regla no coincide, utilice Sophos Firewall rule no coincide: comprobar las causas.

Host FQDN normal o FQDN comodín

Sophos Firewall maneja los hosts FQDN normales y los FQDN comodín de forma diferente. Este es el detalle operativo más importante.

Host FQDN normal

Para un host FQDN normal, como updates.vendor.example, el firewall resuelve el nombre a través de DNS. Las direcciones IP devueltas se utilizan para el objeto. Si el registro DNS tiene un TTL, el firewall actualiza la resolución después de que expire ese TTL.

SFOS 22 tiene un límite IPv6 importante: los objetos host FQDN no resuelven direcciones IPv6. Esto no impide que DNS Lookup o clientes normales reciban respuestas AAAA, pero el propio objeto no mantiene estos destinos IPv6. Compatibilidad y límites de IPv6 en Sophos Firewall con SFOS 22 lo diferencia de las demás funciones compatibles y no compatibles.

Esto funciona bien cuando:

• el FQDN apunta directamente a las direcciones IP requeridas,
• la aplicación usa exactamente ese nombre,
• las respuestas DNS no cambian constantemente entre muchos destinos CDN,
• la prueba utiliza la misma resolución de nombre que ve el firewall.

FQDN comodín

Para un FQDN comodín, como *.example.com, el firewall no resuelve simplemente “todos los subdominios posibles”. DNS no proporciona una lista completa de todos los subdominios.

En cambio, el firewall aprende direcciones IP coincidentes a partir de respuestas DNS. Para ello, debe ver las respuestas coincidentes; en el caso de DNS en tránsito, además debe estar activado learn-subdomains. El tráfico DNS visible por sí solo no garantiza que el aprendizaje se realice correctamente. Las vías de aprendizaje documentadas son:

• Sophos Firewall es el servidor DNS de los clientes.
• O el tráfico DNS pasa a través del firewall y es detectado por DPI.
• Según Sophos, este aprendizaje se aplica al tráfico DNS UDP en el puerto 53 hacia servidores DNS externos.

Si los clientes utilizan DNS sobre HTTPS, DNS sobre TLS, otra ruta DNS o un solucionador local, es posible que el firewall no vea las respuestas DNS relevantes. Un FQDN comodín puede permanecer vacío o incompleto aunque el dominio funcione en el navegador.

Crear un host FQDN

La ruta del menú es:

Hosts and services > FQDN host > Add

Sólo unos pocos campos importan para un objeto limpio:

• Name: descriptivo y técnicamente estable, por ejemplo fqdn_vendor_updates o wfqdn_example_subdomains .
• FQDN: el nombre completo, por ejemplo updates.vendor.example o *.example.com.
• FQDN host group: opcionalmente seleccionar un grupo existente o crear un nuevo grupo. Un host FQDN puede pertenecer a varios FQDN host groups.
• Ortografía: escribe los FQDN en minúsculas. Sophos afirma que no se admiten letras mayúsculas en hosts FQDN.

Después de introducir los campos, guardar el objeto con Save.

Después de guardar, no coloque inmediatamente el objeto a ciegas en las reglas de producción. Primero ejecute una breve prueba: ¿el firewall resuelve el nombre, el Log Viewer muestra más tarde la IP de destino esperada y esta IP coincide con la respuesta DNS del cliente?

Agrupar varios hosts FQDN

Un FQDN host group reúne varios hosts FQDN existentes en un único objeto reutilizable. Los grupos pueden seleccionarse, entre otros lugares, en reglas de firewall y SD-WAN policy routes.

Vaya a Hosts and services > FQDN host group > Add. Introduzca una etiqueta única en Name, seleccione los hosts necesarios y haga clic en Save. Para una aplicación con endpoints separados, el grupo grp_vendor_service podría contener login.vendor.example, api.vendor.example y updates.vendor.example. Un host puede pertenecer a varios grupos. Incluya solo los nombres necesarios, ya que cada host adicional amplía todas las reglas que utilizan el grupo.

Las listas FQDN host y FQDN host group permiten buscar por cualquiera de los atributos mostrados. Antes de modificar o eliminar un objeto, compruebe por separado qué reglas de firewall, SD-WAN policy routes u otras configuraciones lo utilizan. Un cambio en un grupo compartido afecta a todos esos usos.

Uso en reglas de firewall

En la mayoría de los diseños, un host FQDN pertenece a las reglas de salida bajo Destination networks. Luego, la regla describe qué fuentes internas pueden conectarse a qué destino dinámico.

Flujo típico:

1. Cree el objeto FQDN en Hosts and services > FQDN host.
2. Abra o cree la regla coincidente en Rules and policies > Firewall rules.
3. Defina Source zones y Source networks and devices de manera estricta.
4. Elija Destination zones deliberadamente, generalmente WAN.
5. Seleccione el objeto FQDN en Destination networks.
6. Permita solo los puertos requeridos en Services, por ejemplo HTTPS.
7. Habilitar el registro.
8. Ejecute una prueba real y verifique el ID de la regla, la IP de destino, el ID de la regla NAT y el servicio en Log Viewer.

Un host FQDN no hace que una regla sea segura por sí solo. Si el Origen es Any, el Servicio es Any y el Destino es un objeto comodín amplio, el resultado puede volverse muy abierto rápidamente. Es mejor una regla pequeña con fuente clara, servicio claro, registro activo y propósito documentado.

Caso especial: grupos preconfigurados para reglas Web Proxy

Los grupos preconfigurados SafeSearch enforcement, YouTube restrictions enforcement y Google app enforcement están destinados exclusivamente a reglas que aplican SafeSearch, restricciones de YouTube o inicios de sesión de Google Workspace mediante Web Proxy. No sustituyen a una lista personalizada de destinos SaaS generales.

Antes de activar una regla de este tipo, asegúrese de que los dispositivos del grupo piloto confíen en la CA, defina las exclusiones de descifrado adecuadas y prepare pruebas de aceptación HTTP y HTTPS concretas. El procedimiento se explica en implantar gradualmente la inspección TLS en Sophos Firewall.

En la regla de firewall dedicada, establezca Action en Allow y Destination zones en WAN. Seleccione los grupos preconfigurados necesarios en Destination networks y HTTP y HTTPS en Services. Active también Scan HTTP and decrypted HTTPS, Block QUIC protocol, Use web proxy instead of DPI engine y Decrypt HTTPS during web proxy filtering. Coloque la regla por encima de las reglas que procesan el mismo tráfico con el motor DPI.

Después de la prueba, utilice el Log Viewer y un navegador para confirmar que solo el grupo piloto previsto usa esta regla y que se aplica la restricción esperada. Para revertir el cambio, desactive la nueva regla proxy y compruebe que el tráfico vuelva a procesarse mediante la regla DPI inferior. Elimine la regla proxy solo después de confirmar este estado.

Límites y trampas

Muchos problemas de FQDN no provienen de la lista de reglas, sino del comportamiento DNS de los clientes o aplicaciones.

El firewall ve diferentes respuestas de DNS

Si el cliente y el firewall utilizan diferentes solucionadores de DNS, pueden recibir diferentes direcciones IP para el mismo nombre. Esto es normal con las CDN. Luego, una regla puede coincidir con una IP mientras el cliente usa otra.

Al solucionar problemas, compare:

• ¿Qué IP devuelve nslookup o dig al cliente?
• ¿Qué IP de destino aparece en el Log Viewer?
• ¿Qué servidores DNS utilizan el cliente y el firewall?
• ¿DNS utiliza el puerto 53, DNS sobre HTTPS o DNS sobre TLS?

El FQDN comodín no aprende nada

Un FQDN comodín solo funciona si el firewall ve las respuestas DNS coincidentes. Si un cliente usa DoH en el navegador o una ruta DNS que no pasa por el firewall, el firewall no puede aprender los subdominios. Para el tráfico DNS que solo atraviesa el firewall, comprueba además si learn-subdomains está activado. Es un requisito adicional, no una garantía de éxito.

En estos casos, mover la regla del firewall no es la solución. En su lugar, decida el diseño de DNS: use el firewall como reenviador de DNS, enrute el tráfico DNS a través del firewall de manera controlada o use otra capa de control para el tráfico web.

El FQDN es demasiado amplio

Un comodín como *.example.com puede incluir mucho más de lo previsto. Los servicios SaaS modernos utilizan dominios de inicio de sesión, dominios API, CDN multimedia, telemetría, servicios de soporte y terceros. A veces, un único objeto comodín es demasiado tosco.

Si el acceso debe ser amplio por diseño, una política web, un grupo de URL o un control de aplicaciones suelen ser más fáciles de entender y revisar que una regla de firewall FQDN muy grande.

Varios dominios apuntan a la misma IP

Sophos documenta expresamente que los hosts FQDN no admiten varios dominios que se resuelvan en la misma dirección IP. Un objeto FQDN trabaja con las direcciones IP resueltas y no puede distinguir esos dominios entre sí en la capa IP. Por tanto, no debe esperarse una separación fiable de los dominios mediante este objeto.

Por lo tanto, para decisiones web basadas en dominios, la capa web es más adecuada que una regla de firewall puramente basada en IP con un objeto FQDN.

Solución de problemas

Si una regla FQDN no se comporta como se esperaba, primero verifique la conexión real. El nombre del objeto no es decisivo; es la dirección IP utilizada en el momento de la prueba.

La regla no coincide

Compruebe:

• ¿Coincide la zona de origen?
• ¿Coincide la IP de origen o la red de origen?
• ¿Coincide el servicio, por ejemplo TCP 443 en lugar de solo HTTP?
• ¿El Log Viewer muestra otra Rule ID?
• ¿El Log Viewer muestra una IP de destino que no coincide con la respuesta DNS actual?
• ¿Hay una regla más general activa por encima de la regla FQDN?

Si el Log Viewer muestra otra regla, el orden de las reglas importa más que el objeto FQDN. Si el Log Viewer no muestra nada, la ausencia de tráfico en el firewall o el registro inactivo son posibles causas, pero no las únicas. Comprueba también el módulo seleccionado y los filtros de tiempo, campo y búsqueda. Las sesiones de las reglas del firewall solo se registran al cerrarse la conexión con un evento Destroy recibido; si la conexión se cierra sin ese evento, puede faltar el registro de la sesión. Por tanto, también debe tenerse en cuenta que la conexión podría seguir abierta. Comprueba mediante un Packet Capture específico si los paquetes de prueba llegan al firewall; un Log Viewer vacío por sí solo no demuestra lo contrario.

El FQDN comodín permanece vacío

Compruebe:

• ¿El cliente utiliza el firewall como servidor DNS?
• ¿El DNS es visible a través del firewall?
• ¿El cliente utiliza DoH o DoT?
• ¿Se utiliza UDP 53?
• ¿Está activado learn-subdomains para DNS en tránsito? Las respuestas DNS visibles por sí solas no garantizan un binding aprendido.
• ¿Existe una ruta de solicitud de DNS o un solucionador interno que oculta la respuesta antes de que la vea el firewall?

Si el DNS se enruta intencionalmente internamente, configurar DNS request routes en Sophos Firewall ayuda con el diseño del DNS.

DNS cambió, la regla reacciona más tarde

Los objetos FQDN funcionan con respuestas DNS y cachés. Si el destino de un proveedor cambia, puede haber un retraso hasta que el firewall utilice el nuevo estado. Para hosts FQDN normales, el TTL del registro DNS es decisivo.

En la Device Console, Sophos ofrece la familia de comandos global set fqdn-host; no modifica únicamente un objeto host seleccionado. cache-ttl utiliza dns-reply-ttl de forma predeterminada o puede establecerse entre 60 y 86400 segundos. idle-timeout elimina los bindings no utilizados después de un intervalo configurable de entre 60 y 86400 segundos; el valor predeterminado es 3600 segundos. eviction controla si se eliminan las direcciones IP aprendidas para subdominios wildcard y tras qué intervalo; este intervalo va de 60 a 86400 segundos. learn-subdomains activa o desactiva el aprendizaje de estas direcciones a partir del tráfico en tránsito que atraviesa el firewall sin originarse ni terminar en él. Si se cambia cache-ttl, el nuevo valor solo se aplica a las entradas resueltas posteriormente; las entradas ya almacenadas en caché conservan su valor anterior hasta que expiran.

No cambie estos valores como primera medida. Compruebe primero si el diseño DNS, la ruta del resolver y la base de reglas son correctos. Antes de realizar un cambio, anote todos los valores actuales, modifique un solo parámetro cada vez y pruebe su efecto con nuevas resoluciones. Para revertir el cambio, restaure el valor original anotado; en el caso del TTL predeterminado, dicho valor es dns-reply-ttl. El ajuste debe formar parte de un procedimiento documentado de operación o soporte.

Recomendación operativa

Los hosts FQDN siguen siendo manejables cuando se los trata como dependencias técnicas, no como excepciones espontáneas.

Buena práctica:

• Documente un propósito claro para cada objeto FQDN.
• Utilice comodines con moderación.
• Combine objetos FQDN con definiciones estrechas de origen y servicio.
• Habilite el registro de reglas nuevas o críticas.
• Pruebe los cambios con Log Viewer y búsqueda de DNS.
• No oculte el acceso amplio a la web en una regla FQDN grande.
• Para SaaS o servicios en la nube, verifique periódicamente si el proveedor requiere dominios adicionales.

La documentación de la CLI indica hasta 16.000 hosts FQDN. Sin embargo, para SFOS 22, Sophos documenta un límite conjunto de 16.000 hosts entre todos los tipos de host; de ello no debe deducirse una capacidad FQDN adicional e independiente ni una reserva libre. Este límite no invita a un crecimiento sin control. Muchas excepciones FQDN antiguas dificultan la revisión, el troubleshooting y el mantenimiento de reglas. Es mejor una lista de objetos más pequeña y documentada con propietario, propósito y fecha de revisión.

Si un objeto se creó sólo porque “una aplicación no funciona”, revíselo más tarde. Estos objetos de emergencia a menudo se convierten en excepciones permanentes que son difíciles de explicar.

Preguntas frecuentes

¿Cuál es la diferencia entre un host FQDN y un host IP?

Un host IP describe una dirección o red fija. Un host FQDN describe un nombre DNS cuyas direcciones IP actuales puede usar el firewall. Esto ayuda con destinos dinámicos, pero depende de la resolución de DNS y el comportamiento de la caché.

¿*.example.com funciona automáticamente para todos los subdominios?

No como una lista completa de dominios. El firewall debe ver las respuestas DNS coincidentes y aprender las direcciones IP de ellas. Si el DNS no es visible a través del firewall, un FQDN comodín puede permanecer incompleto.

¿Por qué mi regla FQDN no coincide?

Normalmente, el contexto de la regla, el orden o la IP de destino realmente utilizada no coinciden. En el Log Viewer, verifique qué Rule ID, IP de destino, Puerto de destino e Rule ID NAT aparecen durante la prueba real.

¿Los hosts FQDN funcionan con DNS sobre HTTPS o DNS sobre TLS?

Los FQDN comodín son problemáticos cuando los clientes usan DoH o DoT y el firewall no puede ver las respuestas de DNS. Entonces el cortafuegos no puede aprender de forma fiable los subdominios necesarios.

¿Deberían utilizarse hosts FQDN para el filtrado web?

Sólo de forma selectiva. Para un control web real, las políticas web, los grupos de URL, la protección DNS, el control de aplicaciones o la inspección TLS suelen ser más adecuados. Los hosts FQDN son útiles para destinos técnicos en reglas de red, pero no constituyen una política de URL completa.