Ir al contenido
Avanet

Configurar Sophos DNS Protection con Sophos Firewall

Sophos Firewall

Sophos DNS Protection comprueba las consultas DNS mediante un servicio en la nube y gestiona políticas e informes en Sophos Fusion (antes Sophos Central). Permite bloquear dominios maliciosos, phishing, objetivos de comando y control y categorías no deseadas antes de que un cliente establezca la conexión real.

Con Sophos Firewall, la configuración estándar más limpia suele ser la siguiente: los clientes utilizan el firewall como resolver DNS, el firewall reenvía las consultas públicas a DNS Protection y los dominios internos se envían a servidores DNS internos mediante DNS Request Routes.

DNS Protection no sustituye a Web Protection, Threat Feeds ni NDR y Active Threat Response. Complementa estos controles en la capa DNS.

Esta guía se mantiene deliberadamente centrada en Sophos Firewall: valores de Fusion, reenvío DNS, Request Routes, DHCP, NAT, validación y rollback. La guía de configuración de red explica la arquitectura independiente del fabricante y las autorizaciones; la guía de Locations cubre su ciclo de vida completo.

Decisión y arquitectura objetivo

DNS es un servicio básico. Si el resolver es lento, inestable o demasiado restrictivo, los usuarios lo perciben rápidamente como una interrupción general de la red. Por eso DNS Protection solo debe utilizarse cuando las ventajas de las políticas, categorías y registros de Fusion o la protección de clientes itinerantes justifican el esfuerzo operativo adicional.

Desde la perspectiva de Avanet, para muchas instalaciones de firewall tradicionales, los resolvers rápidos y redundantes junto con Threat Feeds bien mantenidos son la solución más pragmática. DNS Protection es especialmente adecuado cuando:

  • las consultas DNS deben ser visibles en Sophos Fusion.
  • las ubicaciones necesitan políticas DNS diferentes.
  • las categorías deben bloquearse durante la resolución de nombres.
  • los clientes no deben utilizar resolvers públicos arbitrarios.
  • los endpoints Windows administrados también necesitan protección fuera de la red corporativa.

Elegir primero la versión: a partir de SFOS 23.0, utilizar la ruta DoH integrada con asignación del firewall descrita más abajo. Las referencias a la IP pública de origen, DDNS, dos forwarders estáticos y asignación de Location describen la ruta Traditional DNS de SFOS 22 y anteriores, no los requisitos de la nueva ruta del firewall. Endpoint Secure DNS sigue siendo independiente.

La ruta Traditional DNS en SFOS 22 y anteriores es:

  1. Sophos Fusion conoce el sitio como Location.
  2. Sophos Fusion proporciona dos direcciones IP de DNS Protection.
  3. Sophos Firewall utiliza ambas direcciones como DNS forwarders.
  4. DNS Request Routes envía las zonas internas a servidores DNS internos.
  5. DHCP distribuye el firewall como resolver a los clientes.
  6. Una regla NAT opcional obliga al tráfico DNS clásico a utilizar esta ruta.
  7. Sophos Fusion registra y evalúa las consultas DNS públicas.

Se deben distinguir dos métodos:

  • Traditional DNS over IPv4: para firewalls, routers y resolvers locales. Sophos asigna las consultas a la Location mediante la IP pública de origen o un FQDN DDNS.
  • Secure DNS: DNS over HTTPS (DoH) para dispositivos compatibles. Sophos Endpoint puede administrar esta ruta en endpoints Windows compatibles; Windows y macOS también pueden configurarse manualmente para Secure DNS.

Una Location personalizada puede admitir ambos métodos. Para el reenvío del firewall, Traditional DNS debe estar activado y se debe registrar la IP pública o el FQDN.

No mezclar las cuatro rutas DNS

Para diagnosticar problemas hay que saber dónde se procesa cada consulta:

  • Servicio DNS Protection: el resolver en la nube evalúa las consultas públicas con la Filtering Policy de la Location detectada. Sus informes están en Sophos Fusion, no en el Log Viewer del firewall.
  • Firewall como resolver: el cliente consulta una IP de interfaz del firewall por UDP o TCP 53. El servicio DNS local elige entre una DNS Request Route y los forwarders de Network > DNS. En Administration > Device access, DNS debe estar permitido para la zona de origen. Una regla de firewall no puede habilitar este servicio local.
  • DNS en tránsito: si el cliente consulta directamente una IP de resolver público, el firewall solo reenvía tráfico. Se aplica una regla de firewall, pero no las DNS Request Routes. Por tanto, el registro de la regla demuestra transporte, no el procesamiento por DNS Protection.
  • Endpoint DNS Protection: Sophos Endpoint intercepta las consultas Windows compatibles y las envía por HTTPS a la Secure DNS Location. Una regla NAT para el puerto 53 y las Request Routes del firewall no forman parte de esta ruta. Solo los dominios excluidos, o el reintento NXDOMAIN opcional, utilizan la resolución DNS local.

En el diseño recomendado, los clientes usan el resolver del firewall. El tránsito directo a las IP de DNS Protection no es equivalente cuando las zonas internas necesitan Request Routes.

Antes del despliegue se deben aclarar la licencia, las direcciones públicas de salida, las zonas DNS internas, los servidores DHCP y los responsables de políticas y excepciones. Xstream Protection cubre DNS Protection independiente para el firewall. Workspace Protection cubre DNS Protection para endpoints; Sophos Endpoint debe estar instalado en los dispositivos. Ambas licencias incluyen DoH.

Para que DNS Protection aparezca como producto en Sophos Fusion, el firewall con licencia Xstream debe estar vinculado a la misma cuenta de Fusion. Comprueba la licencia en Administration > Licensing en el firewall o en la página Firewall Licensing de Sophos Fusion. Sophos documenta tres métodos: registro durante la instalación, reclamación del número de serie en Firewall Licensing o activación de la administración mediante Sophos Fusion en WebAdmin.

Las decisiones de licencia y los permisos de Fusion pertenecen a los procesos existentes de licencias de Sophos Fusion y roles administrativos. El responsable del firewall necesita acceso a DNS Protection y a los valores aprobados del tenant, pero no debe ampliar roles como parte de este cambio.

La Location predefinida Default se puede utilizar para Secure DNS y asignar a políticas; simplemente no se puede editar ni eliminar. Se admiten como máximo 50 Locations y 100 entradas públicas IPv4/FQDN por Location. Por tanto, las Locations deben organizarse por sitio y salida a Internet, no por cada VLAN.

El vídeo muestra Sophos DNS Protection en Sophos Fusion y complementa las indicaciones sobre Locations, políticas y despliegue.

SFOS 23.0: configurar y migrar DNS Protection mediante DoH

A partir de SFOS 23.0, la opción integrada DNS Protection utiliza DNS over HTTPS (DoH). La Filtering Policy se asigna al objeto firewall, no a la antigua Location IP/FQDN. Se requiere Xstream Protection y el registro del firewall en Sophos Fusion; en HA deben estar registrados ambos firewalls. Antes del cambio, documentar la configuración DNS anterior, la asignación de la política y los valores de la Location para la reversión.

Antes de la migración: Comprobar si la Location existente corresponde exclusivamente a la ruta DNS de este firewall o si también la utilizan otros resolvers o Endpoint Secure DNS. Si se comparte, no retirar la Location de su Filtering Policy actual ni eliminarla. Realizar la sustitución descrita a continuación solo cuando la asignación de políticas de los demás consumidores se haya aclarado por separado y se haya preservado; hasta entonces, detener la migración.

Activar la protección y asignar una política

  1. En el firewall, activar DNS Protection en Network > DNS.
  2. Decidir conscientemente si utilizar Fall back to DNS server: si se activa, hay que configurar un servidor DNS en DNS server settings. Sin esta opción, no se pueden configurar servidores DNS allí mientras DNS Protection esté activado. Un resolver externo de respaldo mejora la disponibilidad, pero puede eludir el filtrado y la visibilidad de DNS Protection cuando el servicio no es accesible. Documentar la decisión y el resolver de respaldo; DoH hacia cualquier proveedor no equivale automáticamente a DNS Protection.
  3. En Sophos Fusion, abrir My Products > DNS Protection > Policies > Filtering policies. Para una configuración nueva, seleccionar Add policy, elegir el firewall en Locations and firewalls > Available y moverlo a Assigned to this policy. Type debe indicar Firewall; el nombre contiene la etiqueta del firewall y su número de serie. Definir los filtros previstos en Settings y guardar la política.

Sustituir una asignación Traditional DNS existente

Tras actualizar y activar DNS Protection, abrir la Filtering Policy existente. En Locations and firewalls, mover la Location creada para ese firewall de Assigned to this policy a Available. Después, mover el firewall de Available a Assigned to this policy y seleccionar Save. La Location antigua solo puede eliminarse después de guardar. Avanet recomienda conservarla hasta validar el piloto; no eliminarla si otros resolvers o dispositivos siguen necesitándola. Esta migración no se aplica a resolvers de terceros ni a Endpoint Secure DNS.

Validar el piloto y revertir

Los clientes siguen utilizando el firewall como resolver. Los pasos siguientes de DNS Request Routes, DHCP y redirección NAT opcional del puerto 53 también se aplican aquí; no ejecutar además los antiguos pasos de Location y forwarders estáticos. En Network > DNS > Test name resolution, introducir un nombre público en Hostname or IP address y seleccionar Test connection. Comprobar servidor, protocolo utilizado, resultado y tiempo de respuesta. Desde el cliente piloto, probar también nombres internos, búsquedas inversas y un dominio inofensivo bloqueado deliberadamente por la política. Revisar la asignación del firewall en Fusion y los informes DNS Protection; una resolución correcta no demuestra por sí sola que la Filtering Policy sea efectiva. No ampliar el despliegue hasta superar el piloto. Esta guía no se ha probado en laboratorio en un firewall SFOS 23.

Para revertir, reasignar primero la Location Traditional DNS conservada a la política anterior, retirar la asignación del firewall y seleccionar Save. Después, desactivar DNS Protection en el firewall y restaurar la configuración DNS anterior documentada en DNS server settings. Son campos de SFOS 23, no los nombres de campos SFOS 22 mostrados más abajo. Mantener las Request Routes y los valores DNS de cliente que no hayan cambiado, y volver a comprobar la resolución pública e interna y el filtrado. Si la Location ya se eliminó, recrearla con los valores documentados antes de esta reversión.

API XML: cambios documentados, pero sin una receta segura para copiar

La documentación de la API XML de SFOS 23 para DNS List incorpora DNSProtection con Enabled y Fallback, DNSProtocol, DNSOverHTTPS con DNSServer1 a DNSServer3 y con URL, IPv4Address e IPv6Address, además de FallbackToUnencryptedDns y DNSSecProtection. Los comentarios condicionales del ejemplo vinculan los ajustes IPv4/IPv6 a UnencryptedDNS y el bloque DoH a DNSOverHTTPS; para DoH se exige DNSServer1 y se indica una dirección IPv4 o una dirección IPv6 por servidor. Estas condiciones documentadas en los comentarios no constituyen una receta de API completamente aclarada ni probada aquí.

Quedan dos conflictos pendientes: SFOS 22 denomina al selector DNSQueryConfiguration y utiliza valores de texto. En cambio, la tabla de SFOS 23 indica DNS Query Configuration y 0, 1, 2, 3, sin mostrar en el ejemplo la etiqueta XML ni la correspondencia de esos valores. El comentario de DNSProtocol indica a la vez que el campo es obligatorio y que UnencryptedDNS es el valor cuando se omite. De ello no se puede deducir una etiqueta con espacios, una correspondencia numérica, una omisión segura, compatibilidad automática ni un valor predeterminado seguro.

Ruta actual segura: aquí se excluye expresamente la receta ambigua del selector y de omisión del campo. Para SFOS 23, utilizar la ruta de WebAdmin descrita más arriba en Network > DNS, decidir conscientemente el protocolo y el fallback, y comprobar en el piloto los ajustes guardados, el protocolo realmente utilizado, la asignación de la política al firewall, la resolución interna y el efecto del filtrado. Si es necesario automatizar, detenerse hasta que el fabricante aclare estos campos para la versión correspondiente; una interfaz que funciona no confirma ningún esquema XML ni REST.

DNSProtection/Fallback y DNSOverHTTPS/FallbackToUnencryptedDns son ajustes distintos: el primero se refiere a la resolución alternativa cuando DNS Protection no está disponible; el segundo, al fallback de DoH a DNS sin cifrar. La pérdida de protección o visibilidad y la pérdida del cifrado de transporte son riesgos diferentes. No equipararlos ni adoptar valores booleanos predeterminados sin evidencia; comprobar expresamente ambas decisiones. DoH hacia cualquier proveedor no equivale a Sophos DNS Protection, y DNSSecProtection no es DoH ni una asignación de Filtering Policy. No se genera XML ejecutable de DNS global a partir de estas ambigüedades.

XML API: SFOS 22 — DNS List; SFOS 23 — DNS List.

Configurar DNS Protection

Traditional DNS en SFOS 22 y versiones anteriores: los pasos 1–3 describen la antigua ruta IP/FQDN. Los pasos 4–6 siguen siendo relevantes para la ruta integrada de SFOS 23.

1. Crear una Location en Sophos Fusion

My Products > DNS Protection > Locations
  1. Seleccionar Add e introducir un nombre único en Name; conviene usar Description para identificar la salida a Internet y el responsable.
  2. En Connection method, activar Traditional DNS over IPv4.
  3. En IPv4 addresses or FQDNs, introducir la IP WAN pública o un FQDN DDNS estable. Confirmar cada valor con Enter o Tab.
  4. Con Multi-WAN, incluir todas las direcciones de salida utilizadas. Las IP detectadas automáticamente no se actualizan solas tras un cambio posterior.
  5. Seleccionar Save.

Las direcciones IP privadas no son válidas. Sophos debe reconocer la IP pública de origen mediante la que la consulta llega al servicio. Para las direcciones dinámicas, Sophos comprueba periódicamente el nombre DDNS, pero un cambio puede causar una breve interrupción. Con Cloudflare, el registro DDNS debe estar en DNS only y no debe utilizar el proxy.

Con CGNAT o una IP compartida del proveedor, la dirección se asigna a la cuenta de cliente que la haya registrado primero. Un FQDN no resuelve este problema si apunta a la misma IP compartida; se necesita una IP pública única.

Sophos Fusion DNS Protection Locations con el diálogo Add location
En Sophos Fusion se crea una Location por sitio con una IP pública de origen o un FQDN.

2. Copiar las direcciones IP de DNS Protection

My Products > DNS Protection > Installers

En Installers, junto a IP addresses, aparecen dos direcciones IP de DNS Protection. Con Copy se copian ambos valores desde el propio tenant de Fusion para utilizarlos después como DNS 1 y DNS 2. Un resolver externo como fallback adicional puede eludir la protección y la visibilidad.

Las direcciones IP también están disponibles cuando Secure DNS está activado. Lo importante es que, para la ruta del firewall, Traditional DNS también esté configurado en la Location con la dirección pública de salida.

En la misma página, Copy, junto a URL, permite copiar la dirección de prueba. Si al abrirla en el navegador aparece el mensaje de bienvenida de DNS Protection, la ruta del resolver está configurada correctamente. Para el diagnóstico posterior es especialmente relevante https://dns.access.sophos.com: si solo este nombre no se resuelve o el navegador muestra un error en lugar del mensaje de bienvenida, es indicio de una fuga DNS o de una redirección del proveedor.

Sophos Fusion DNS Protection Installers con direcciones IP de DNS Protection, certificado y URL de prueba
DNS Protection > Installers proporciona los servidores DNS, el certificado para Block Pages y la prueba de configuración.

3. Configurar el firewall como DNS forwarder

Network > DNS
  1. Seleccionar Static DNS.
  2. Establecer DNS 1 y DNS 2 con las dos direcciones de Fusion.
  3. Dejar DNS 3 vacío, salvo que exista una excepción documentada de forma consciente.
  4. En IPv6, seleccionar también Static DNS y no introducir servidores DNS IPv6.
  5. Activar Choose IPv4 DNS server over IPv6.
  6. Seleccionar Apply.

El servicio funciona mediante IPv4, pero también puede resolver registros AAAA y, por tanto, destinos IPv6. Con SD-WAN, failover o Policy Routing, la ruta de salida real debe utilizar una dirección pública registrada en la Location.

A partir de SFOS 21.5, el DNS Protection status widget del Control center muestra el estado de la conexión. También está disponible Sophos Assistant para la configuración guiada y el diagnóstico. El widget es un indicador operativo rápido; para validar la ruta completa son más concluyentes el acceso correcto a la dirección de prueba y los informes de DNS Protection. La guía Usar Sophos Assistant de forma segura muestra cómo verificar las páginas de ayuda y distinguir los recorridos explicativos de los procedimientos en los que se realiza realmente la configuración.

4. Reenviar dominios internos

Network > DNS
DNS request route > Add

DNS Protection no resuelve zonas internas. Por tanto, las DNS Request Routes son necesarias para Active Directory, aplicaciones internas y búsquedas inversas.

Ejemplo:

  • Host/domain name: firma.local o corp.example.com
  • Target servers: controladores de dominio o servidores DNS internos, en el orden de consulta deseado; cada ruta admite hasta ocho direcciones IP

corp.example.com es un dominio de documentación que debe sustituirse por la zona realmente autoritativa en la red interna. No se debe enrutar todo example.com si solo una subzona es interna. Si falla la búsqueda en caché de una ruta coincidente, el firewall no consulta después sus forwarders públicos ni los servidores raíz. El orden y la disponibilidad de los Target Servers forman parte del diseño de continuidad.

El procedimiento completo se describe en Configurar DNS Request Routes en Sophos Firewall. Los dominios registrados públicamente que se utilicen internamente también deben permitirse en una Domain List si una categoría como Parked Domains los bloquea.

5. Dirigir los clientes al firewall mediante DHCP

Network > DHCP
  1. En Server, editar el servidor DHCP afectado y anotar la dirección de la Interface seleccionada.
  2. En DNS server, desmarcar Use device’s DNS settings.
  3. Introducir como Primary DNS la dirección de la interfaz DHCP interna del firewall.
  4. Guardar, renovar la concesión del cliente de prueba y comprobar el resolver utilizado.

En su ejemplo, Sophos muestra la IP del firewall como Primary DNS y una IP de DNS Protection como Secondary DNS. Sin embargo, los clientes no tratan necesariamente la segunda entrada solo como servidor de emergencia. Las consultas directas a DNS Protection eluden DNS Request Routes del firewall. Por tanto, en redes con Active Directory o zonas internas, la redundancia debe resolverse en la ruta del resolver y no mediante un segundo servidor DNS de cliente arbitrario.

6. Evitar la omisión directa de DNS

Primero, en Administration > Device access, comprobar que DNS esté activado para cada zona de origen afectada. Después, una regla DNAT opcional puede redirigir al firewall el tráfico DNS clásico:

Rules and policies > NAT rules > IPv4 > Add NAT rule > New NAT rule
  • Rule name: por ejemplo, redirect-client-dns-to-firewall
  • Rule position: Top
  • Original source: redes internas afectadas
  • Original destination: grupo de hosts de salida o Internet IPv4
  • Original service: DNS
  • Translated destination: IP interna del firewall
  • Translated source / Translated service: Original
  • Inbound interfaces: solo interfaces que correspondan a los orígenes internos, nunca WAN

Internet IPv4 es amplio y solo conviene si se deben redirigir todos los destinos DNS externos clásicos. Limitar al máximo las redes de origen e Inbound Interfaces. Los servidores DNS internos y dispositivos especiales necesitan excepciones documentadas antes de esta regla. Solo captura DNS en UDP/TCP 53. DoH y DoT requieren controles independientes mediante navegador, MDM, endpoint o Web Policy. Antes de activarla, probar la resolución interna, VPN y la red de invitados. La mecánica se explica en Entender NAT en Sophos Firewall.

Políticas, endpoints y Block Pages

Filtering Policy y Domain Lists

Una Filtering Policy se asigna a una o varias Locations en DNS Protection > Policies > Filtering policies. Solo puede haber una Filtering Policy activa por Location. Además de las categorías, pueden definirse listas de dominios y opciones como Safe Search.

En la ruta Traditional DNS, este artículo verifica la asignación a la Location correcta; en la ruta integrada de SFOS 23, verifica la asignación del objeto Firewall a la Filtering Policy prevista. La asignación de la Location y la captura de pantalla de esta sección muestran la ruta anterior. La creación, las excepciones, Safe Search, el piloto y el rollback de la política se tratan en Configurar Filtering Policies de Sophos DNS Protection.

Las Domain Lists deben tener un propósito, un responsable y una fecha de revisión. Una Allow List prevalece sobre las decisiones normales de categoría, pero no sobre la clasificación de SophosLabs como Threat o Security Risk. Un dominio permitido también puede seguir bloqueado si su destino CNAME pertenece a una categoría bloqueada.

Sophos Fusion DNS Protection Filtering Policy con categorías web
Filtering Policies controla qué categorías web se permiten, bloquean o definen individualmente para una Location.

En las categorías son especialmente importantes estas decisiones:

  • Infrastructure: normalmente se permiten Content delivery, CRL y OCSP, ya que las actualizaciones y la validación de certificados pueden depender de ellos.
  • Threats and liabilities: normalmente se bloquean categorías como Phishing, Malware, Newly Registered Websites o Anonymizers y se resuelven los falsos positivos de forma específica.
  • Data loss: evaluar el almacenamiento en la nube y el correo web según los requisitos de DLP y cumplimiento.
  • Uncategorized: no bloquear sin análisis; los servicios legítimos nuevos o internos pueden estar temporalmente sin categorizar.
  • Productividad, redes sociales y ancho de banda: decidir según la red y las necesidades empresariales, no como regla de seguridad general.

Endpoint DNS Protection

La Endpoint DNS Protection Policy está destinada a endpoints Windows gestionados que también necesitan protección fuera de la red corporativa. Sophos Endpoint intercepta las consultas DNS y las envía mediante HTTPS a la Secure DNS Location. La Filtering Policy asociada determina el filtrado real.

La guía Endpoint DNS Protection cubre la configuración, las Domain Exclusions internas y la asignación. El NAT, las Request Routes y DHCP del firewall no sustituyen esta ruta de endpoint.

Actualmente la política no admite Windows Server ni macOS. Para macOS existe una ruta de perfil manual de Secure DNS independiente; Linux, dispositivos móviles y equipos especiales también necesitan su propia solución de red, VPN o MDM. Antes del despliegue se deben comprobar los requisitos actuales del paquete de endpoints en Sophos Fusion, ya que pueden cambiar a corto plazo.

Las zonas internas se mantienen explícitamente como Domain Exclusions en la Endpoint Policy. Esto es más fiable que un reintento NXDOMAIN y evita consultas externas innecesarias. El DNS Protection Root Certificate puede distribuirse automáticamente a los endpoints compatibles.

Root Certificate y Block Page

Para las Block Pages HTTPS, los clientes deben confiar en el DNS Protection Root Certificate. No es el mismo certificado que la CA del firewall para TLS Inspection; su distribución se describe en Distribuir el certificado CA de Sophos Firewall para TLS Inspection.

Para verificar, distribuir, rotar y eliminar el certificado, consulte Distribuir el certificado raíz de Sophos DNS Protection.

El certificado y la prueba de configuración están disponibles en DNS Protection > Installers. Además, blockpage.dnsprotection.sophos.com debe ser accesible.

En Web Proxy Mode, Pharming Protection puede interferir con la Block Page. Antes de desactivar globalmente las funciones de protección, se debe permitir el dominio de la Block Page mediante una regla de firewall HTTP/HTTPS específica sin Web Filtering y establecer Do not decrypt en una regla TLS.

Piloto, despliegue y aceptación

La asignación de Location y los campos Location de los informes en la siguiente lista se refieren a Traditional DNS o a datos de endpoints. Para la ruta integrada de SFOS 23, utilizar en su lugar la asignación del firewall y las pruebas piloto SFOS 23 anteriores; no deducir que los nombres de campos de informes o Live Discover siguen siendo iguales.

Activar primero DNS Protection en una pequeña red piloto. Documentar zonas internas, búsquedas inversas y servicios críticos, configurar DNS Request Routes y preparar un rollback claro a los resolvers anteriores. Las redes de servidores necesitan una ventana de pruebas propia, ya que la validación de licencias, las actualizaciones, CRL/OCSP, los backups o la comunicación de clúster pueden depender de DNS.

Antes de un despliegue amplio deben superarse estas comprobaciones. Los comandos de cliente no se ejecutaron aquí en un entorno SFOS 22; son comandos de diagnóstico de solo lectura. La prueba de configuración y los informes de Fusion aportan la evidencia del producto:

  • un dominio público se resuelve mediante el resolver previsto.
  • un dominio AD interno y una búsqueda inversa funcionan mediante DNS Request Routes.
  • la prueba de configuración en Installers muestra la confirmación esperada.
  • un dominio inofensivo bloqueado deliberadamente por una política de prueba se bloquea y se asigna a la Location correcta.
  • en DNS Protection > Logs & Reports, DNS usage by source muestra la Location tras el retraso previsto y, para datos de endpoint, también el usuario y el dispositivo.
  • la red de invitados utiliza la ruta DNS planificada, pero no servidores DNS internos.
  • el cliente VPN recibe resolvers y sufijos DNS adecuados.
  • Browser DoH, Private Relay o perfiles locales no eluden el control de forma inesperada.
  • el rollback al resolver anterior está probado o claramente documentado.

Comandos de prueba para clientes

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux con systemd-resolved y dig instalado:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Sustituir <firewall-ip> por la dirección de la interfaz interna de Sophos Firewall. Si funciona la consulta explícita al firewall, pero no la consulta normal, la causa suele ser DHCP, VPN, Browser DoH o una configuración DNS local. Los comandos muestran el resolver del cliente utilizado y su respuesta, pero por sí solos no demuestran qué upstream utiliza el firewall.

Probar una zona interna:

dig @<firewall-ip> interner-host.corp.example.com

Esta consulta debe llegar al servidor DNS interno mediante la DNS Request Route correspondiente.

Resolución de problemas

Las comprobaciones de Location, IP de origen y upstream UDP/TCP 53 de este apartado se aplican a Traditional DNS. Para la ruta integrada de SFOS 23, comprobar primero DNS Protection, la asignación del firewall a la política y el protocolo utilizado mediante Test name resolution. Seguir las pruebas piloto de SFOS 23 anteriores; no introducir además los antiguos forwarders IPv4.

La Location no aparece en Sophos Fusion

Comprobar la IP WAN pública, el FQDN DDNS y la salida Multi-WAN real. El servicio DNS Protection puede rechazar una IP de origen no configurada. Con direcciones dinámicas, comprobar si el FQDN resuelve externamente a la IP actual; los registros de Cloudflare deben estar en DNS only.

Los FQDN no válidos y los conflictos de IP aparecen en My Environment > Alerts. Con CGNAT o salidas compartidas de proxy/VPN, prevalece la Location registrada primero. Un FQDN distinto que apunte a la misma IP no cambia esta asignación.

Falta tráfico DNS aunque la Location es correcta

Este síntoma incluye también No queries received from locations en el dashboard y DNS Protection: Connectivity Error en el Control center. Abre primero https://dns.access.sophos.com. Si no aparece el mensaje de bienvenida, prueba mediante UDP y TCP 53 las dos direcciones del tenant que aparecen en Installers y verifica la salida WAN real.

Si las consultas llegan a otro destino o responde otro resolver, el router o el ISP pueden estar redirigiendo DNS. Una prueba Standard o Extended en https://www.dnsleaktest.com/ ayuda a delimitarlo: con DNS Protection, los valores de la columna Hostname contienen el patrón gw-<Nummer><Region>.dnsprotection.sophos.com; como ISP aparece Amazon o una denominación equivalente. Si la prueba muestra exclusivamente otros resolvers, el proveedor debe comprobar si existe una redirección DNS. Si se mezclan resolvers de Sophos y de terceros, revisa la configuración DNS del firewall, del servidor DNS interno y de los clientes, así como los resolvers IPv6 paralelos. https://ipleak.net/ puede utilizarse como comprobación adicional.

Mantén solo las dos direcciones del tenant como forwarders, comprueba rutas, NAT y una captura de paquetes, y solicita al proveedor que corrija la redirección. Un tercer resolver público solo sería un bypass sin protección.

Algunos clientes usan otro resolver

Comprueba conjuntamente DHCPv4, DHCPv6, Router Advertisements, el perfil VPN y los valores estáticos del cliente. Un servidor DNS IPv6 adicional puede desviar consultas de DNS Protection. DNS Protection funciona sobre IPv4, pero resuelve registros AAAA; los destinos IPv6 no necesitan un resolver IPv6 independiente.

Los nombres internos dejan de funcionar

Comprobar DNS Request Routes, servidores DNS internos, zonas inversas, dominios de búsqueda y sufijos de cliente. Comprobar también que el cliente utiliza el firewall o el resolver interno previsto y no consulta directamente una IP de DNS Protection.

Se bloquea un dominio interno o legítimo

Comprobar la categorización, la Domain List y el destino CNAME. Una excepción limitada es mejor que abrir toda una categoría. Las clasificaciones Threat y Security Risk de SophosLabs no pueden sobrescribirse con una Allow Domain List.

Los registros permanecen vacíos

El dashboard y los informes tienen un retraso aproximado de 15 a 25 minutos. Un nombre de Location o política actualizado puede tardar entre 30 minutos y cuatro horas en aparecer. Solo después se deben comprobar DHCP, DNS del cliente, DNS del firewall, redirección NAT, resolvers alternativos, perfiles VPN y asignación de Location.

En DNS Protection > Logs & Reports, empieza por DNS usage by source y filtra por Location, Domain, Status o Source IP. Para DNS reenviado directamente, una regla con Log firewall traffic puede mostrar además si UDP/TCP 53 atravesó el firewall. Para el resolver del firewall, Administration > Device access es determinante; una regla de firewall no demuestra que este servicio local se haya permitido o denegado.

Los operadores de filtro, límites de exportación, retrasos y Live Discover se documentan en Analizar DNS Protection Reports y Live Discover. Para diagnosticar el firewall, demuestra primero la ruta del resolver y solo después inicia consultas de informes más profundas.

Con EDR, XDR o MDR, Threat Analysis Center > Live Discover también puede analizar datos de DNS Protection como dominio, Policy Action, Location e IP de origen. Los campos de usuario y dispositivo están disponibles para datos de endpoint en los informes estándar, no en el esquema DNS de firewall documentado para Live Discover.

La Block Page no aparece

Comprobar DNS Protection Root Certificate, la ruta DNS y la accesibilidad de blockpage.dnsprotection.sophos.com. En Web Proxy Mode, comprobar también Pharming Protection, la regla HTTP/HTTPS y la excepción TLS Do not decrypt. VPN, Browser DoH y Apple Private Relay también pueden desviar la prueba de DNS Protection.

Para una excepción de firewall limitada, crea un objeto FQDN para blockpage.dnsprotection.sophos.com. Una regla Allow permite HTTP/HTTPS desde las zonas y redes internas afectadas hacia la zona WAN, con este objeto como destino y sin Web Filter. Una regla TLS correspondiente usa los mismos criterios con Do not decrypt. No desactives globalmente Pharming Protection ni TLS Inspection.

DoH o Private DNS elude el control

Una redirección NAT para el puerto 53 no captura DoH ni DoT. Las políticas de navegador, sistema operativo y MDM deben controlar estos resolvers. Secure DNS en DNS Protection utiliza DoH; no hay documentado un modo específico de DNS Protection mediante DoT.

En dispositivos Apple, iCloud Private Relay también puede eludir la ruta DNS prevista. Por ejemplo, si los iPhone no tienen acceso a Internet, pero otros dispositivos del mismo sitio sí funcionan, desactiva primero Limit IP Address Tracking para la ruta de prueba afectada y vuelve a comprobarla. Solo debe aplicarse un cambio a toda la organización después de esta prueba limitada y de coordinar los requisitos de privacidad.

Los clientes VPN se comportan de forma distinta a los clientes LAN

Comprobar los servidores DNS asignados, los sufijos DNS, Split DNS, Full o Split Tunnel y los resolvers locales. DNS Protection puede funcionar en la oficina y, aun así, eludirse en Remote Access. Las opciones básicas de VPN se explican en Sophos Connect o SSL VPN: ¿qué solución de Remote Access encaja?.

Operación

DNS Protection no es una sustitución puntual del servidor DNS. Se debe comprobar periódicamente:

  • Locations, direcciones públicas de salida y resolución DDNS.
  • configuración DHCP y DNS Request Routes internas.
  • políticas, Domain Lists, responsables y fechas de revisión.
  • principales dominios bloqueados y falsos positivos documentados.
  • nuevos sitios, redes de invitados, rutas VPN y plataformas de endpoints.
  • distribución de certificados y accesibilidad del dominio de la Block Page.
  • informes después de cambios y la ruta de rollback definida.

Si estas tareas no pueden mantenerse de forma permanente, los resolvers robustos y los controles de protección específicos suelen ser la mejor opción. DNS Protection compensa allí donde las políticas, el reporting y la protección de endpoints se utilizan y supervisan realmente.

Revertir con seguridad

La reversión del sitio descrita a continuación corresponde a la antigua ruta Traditional DNS. Para una migración SFOS 23, utilizar la reversión anterior con la asignación de la política y la opción DNS Protection.

Para la ruta del sitio, desactivar primero la redirección DNS para no seguir forzando clientes al firewall durante la reversión. Después, restaurar los resolvers anteriores en Network > DHCP, renovar la concesión del cliente de prueba y verificar nombres públicos e internos. Solo cuando funcione esta ruta se debe restaurar el modo o los servidores anteriores en Network > DNS. Mantener inicialmente las Request Routes: no interfieren con la reversión y facilitan una reanudación controlada. Eliminar la Location de Fusion solo cuando ya no tenga redes ni políticas necesarias asignadas.

Revertir Endpoint DNS Protection por separado: en DNS Protection > Policies > Endpoint policies, retirar la asignación afectada o desactivar Use Sophos DNS Protection y comprobar en el dispositivo piloto que vuelven a utilizarse los resolvers configurados por el sistema o las aplicaciones. El Root Certificate no tiene que eliminarse en la misma ventana; puede retirarse después mediante el mismo canal administrado con el que se instaló.