Configurar Sophos DNS Protection con Sophos Firewall

Sophos DNS Protection comprueba las consultas DNS mediante un servicio en la nube y gestiona políticas e informes en 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.

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 Central 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 Central.
• 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.

La ruta de firewall recomendada es:

1. Sophos Central conoce el sitio como Location.
2. Sophos Central 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 Central 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.

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 las políticas y excepciones. Xstream Protection cubre DNS Protection independiente. Endpoint DNS Protection requiere Workspace Protection y además una licencia adecuada de Sophos Endpoint.

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.

Configurar DNS Protection

1. Crear una Location en Sophos Central

My Products > DNS Protection > Locations

1. Seleccionar Add e introducir un nombre de sitio único.
2. Activar Traditional DNS over IPv4.
3. Introducir la IP WAN pública o un FQDN DDNS estable.
4. Con Multi-WAN, incluir todas las direcciones de salida que se utilicen realmente.
5. Guardar la Location.

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.

2. Copiar las direcciones IP de DNS Protection

My Products > DNS Protection > Installers

En Installers aparecen dos direcciones IP de DNS Protection. Estos valores deben copiarse siempre desde el propio tenant de Central y utilizarse 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.

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 Central.
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. Guardar la configuración.

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.

4. Reenviar dominios internos

Network > DNS
DNS request route section > Add

DNS Protection no resuelve zonas internas. Por tanto, DNS Request Routes es necesario 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

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. Editar el servidor DHCP de la red afectada.
2. Distribuir la IP de la interfaz interna del firewall como servidor DNS.
3. Renovar la concesión en un cliente de prueba.
4. Comprobar el resolver que utiliza realmente el cliente.

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

Una regla DNAT opcional puede redirigir al firewall el tráfico DNS clásico de los clientes internos:

• Original source: redes internas afectadas
• Original destination: grupo de hosts de salida o Internet IPv4
• Original service: DNS
• Translated destination: IP interna del firewall
• Inbound interfaces: solo interfaces que correspondan a los orígenes internos, nunca WAN
• Position: muy arriba, antes de reglas NAT más generales

Las excepciones para servidores DNS internos y dispositivos especiales deben estar documentadas. La regla solo captura DNS en UDP/TCP 53. DoH y DoT requieren controles independientes mediante navegador, MDM, endpoint o Web Policy. Antes de activarla se deben probar la resolución de nombres internos, VPN, red de invitados y registros. La mecánica de la regla se explica con más detalle 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 categorías, se pueden definir Domain Lists y opciones como Safe Search.

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.

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á pensada para endpoints Windows administrados que también necesitan protección fuera de la red corporativa. Sophos Endpoint intercepta las consultas DNS y las envía por HTTPS a la Secure DNS Location. La Filtering Policy asociada determina el filtrado real.

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 Central, 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.

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

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 las siguientes pruebas:

• 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.
• los registros aparecen en Sophos Central tras el retraso de reporting previsto.
• 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

La Location no aparece en Sophos Central

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.

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 respecto al tiempo real. 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.

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 el DNS Protection Root Certificate, la ruta DNS y la accesibilidad de blockpage.dnsprotection.sophos.com. En Web Proxy Mode, comprobar además 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.

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.

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.