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.

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. Esto funciona de manera confiable cuando el firewall puede ver el tráfico DNS:

• 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?

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.

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.

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 señala que los hosts FQDN no están destinados a distinguir claramente varios dominios cuando se resuelven en la misma dirección IP. En la capa IP, el firewall no siempre puede saber qué dominio utilizará posteriormente una aplicación.

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, el tráfico no llega al firewall o el registro no está activo.

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?
• ¿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.

Sophos ofrece opciones CLI para hosts FQDN, como cache-ttl, idle-timeout, eviction y learn-subdomains. cache-ttl puede usar el TTL de la respuesta DNS o un valor entre 60 y 86400 segundos. idle-timeout elimina por defecto bindings no utilizados después de 3600 segundos. eviction controla cuándo se eliminan direcciones IP aprendidas de subdominios wildcard. Si se cambia cache-ttl, el nuevo valor solo se aplica a entradas resueltas de nuevo; las entradas ya en caché conservan su valor anterior hasta que expiran.

No conviene cambiar estos valores como primera reacción. Primero se debe comprobar si el diseño DNS, la ruta del resolver y la base de reglas son correctos. El ajuste pertenece a 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.

Sophos indica un límite de hasta 16.000 hosts FQDN, pero eso 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.