Configurar Sophos DNS Protection con Sophos Firewall
Sophos DNS Protection protege las consultas DNS a través de un servicio DNS basado en la nube con políticas e informes en Sophos Central. La función puede bloquear dominios maliciosos, phishing, objetivos de comando y control y categorías no deseadas antes de que un cliente establezca una conexión con el sitio web o infraestructura real.
Con Sophos Firewall, la configuración estándar más limpia suele ser: los clientes utilizan el firewall como resolutor DNS, el firewall reenvía las consultas DNS públicas a DNS Protection, y los dominios internos se envían a través de rutas de solicitudes DNS a servidores DNS internos. De esta manera, la resolución de nombres internos se mantiene estable, mientras que las consultas DNS públicas se controlan y registran de manera centralizada.
DNS Protection no reemplaza a Web Protection, Threat Feeds ni NDR. Es un punto de protección independiente a nivel DNS. Por eso, la función debe planificarse conscientemente y no simplemente reemplazar servidores DNS públicos.
Vídeo tutorial
Clasificación de Avanet: Uso consciente de DNS Protection
DNS Protection es técnicamente interesante, pero no siempre es la mejor opción en todos los entornos. En muchos proyectos, no utilizamos DNS Protection como estándar, sino que preferimos resolutores DNS rápidos y altamente disponibles y bloqueamos objetivos maliciosos conocidos adicionalmente a través de Sophos Firewall Threat Feeds o fuentes de inteligencia de amenazas comparables en el firewall.
La razón es simple: DNS es una función básica. Si DNS es lento, no funciona de manera redundante o genera demasiados falsos positivos, los usuarios pueden sentir rápidamente que toda la red está defectuosa. La protección DNS no solo debe ser segura, sino también estable, rápida, comprensible y fácil de operar.
La decisión depende del objetivo:
| Enfoque | Fortaleza | Límite |
|---|---|---|
| Resolutores DNS rápidos y altamente disponibles | Muy buen rendimiento, resolución de nombres robusta, bajo riesgo operativo | No hay política DNS central ni informes DNS en Sophos Central |
| Threat Feeds en Sophos Firewall | Los objetivos maliciosos conocidos pueden bloquearse en el perímetro sin modificar la ruta DNS | No es lo mismo que el filtrado de categorías DNS; la calidad, el ajuste y el proceso de falsos positivos son importantes |
| Sophos DNS Protection | Políticas DNS, categorías, ubicaciones, registros y protección DNS de endpoints en Sophos Central | Dependencia adicional en la ruta DNS; el despliegue, los certificados, las excepciones y el monitoreo deben planificarse cuidadosamente |
DNS Protection es especialmente adecuado cuando se desean explícitamente registros DNS en Sophos Central, políticas DNS basadas en ubicaciones, filtrado de categorías o protección DNS de endpoints para clientes itinerantes. Si el objetivo principal es una resolución de nombres rápida y altamente disponible con bloqueo adicional de objetivos maliciosos conocidos, los buenos resolutores DNS más Threat Feeds suelen ser la solución más pragmática.
Cuándo es útil DNS Protection
DNS Protection es especialmente fuerte cuando muchos clientes acceden a Internet a través de un firewall central o un resolutor DNS local.
Casos de uso típicos:
- Los clientes no deben usar resolutores DNS públicos arbitrarios.
- Los dominios de malware, phishing y C2 deben bloquearse temprano.
- Las consultas DNS deben ser visibles en Sophos Central.
- Diferentes ubicaciones deben tener sus propias políticas DNS.
- Los nombres DNS internos deben seguir funcionando a través de servidores DNS locales.
- Web Protection debe complementarse con un control DNS previo.
Sin embargo, DNS Protection no es un reemplazo para la inspección de contenido. Si un dominio permitido entrega contenido malicioso más tarde o si el tráfico HTTPS necesita ser examinado más de cerca, Web Protection, TLS Inspection, IPS, protección de endpoints y registros siguen siendo relevantes.
DNS Protection no es ideal si solo se busca un reenviador DNS externo rápido o si ya existe una operación DNS muy estable con Threat Feeds separados, Web Protection, protección de endpoints y monitoreo limpio. En ese caso, primero se debe evaluar qué valor adicional concreto aporta DNS Protection y quién gestionará la política, las excepciones y los falsos positivos.
Arquitectura con Sophos Firewall
Para Sophos Firewall, esta configuración suele ser la más clara:
- Sophos Central reconoce la ubicación como Location.
- Sophos Central proporciona dos direcciones IP de DNS Protection.
- Sophos Firewall utiliza estas direcciones IP como reenviador DNS.
- Los dominios internos se envían a través de rutas de solicitudes DNS a servidores DNS internos.
- DHCP distribuye el firewall como resolutor DNS a los clientes.
- Opcionalmente, una regla NAT obliga a que el tráfico DNS saliente se redirija al firewall.
- Los registros y reportes de DNS Protection se evalúan en Sophos Central.
Esta configuración asegura que los clientes no necesiten ser configurados directamente en el servicio DNS de Sophos. El firewall sigue siendo el resolutor central en la LAN y puede manejar mejor los casos especiales internos.
Requisitos previos
Antes del despliegue, se deben aclarar estos puntos:
- Acceso a Sophos Central con permiso para DNS Protection.
- Licencia adecuada: Xstream Protection para DNS Protection independiente o Workspace Protection para DNS Protection de endpoints.
- IP WAN pública o un nombre FQDN/DDNS estable para la ubicación.
- Sophos Firewall se utiliza como resolutor DNS para las redes afectadas o se planea hacerlo.
- Se conocen los dominios internos, las zonas de Active Directory y las búsquedas inversas.
- Se han identificado los servidores DHCP para las redes de clientes.
- Se han planificado excepciones para dominios internos y servicios críticos.
- Se han definido responsables para la política DNS, los falsos positivos y los registros.
Si la dirección IP pública cambia con frecuencia, se debe aclarar antes del despliegue si una configuración DDNS es lo suficientemente estable. Sophos DNS Protection también puede identificar ubicaciones a través de un FQDN, pero un cambio de IP aún puede causar interrupciones temporales.
1. Crear una ubicación en Sophos Central
En Sophos Central, primero se crea la ubicación:
My Products > DNS Protection > Locations
Procedimiento práctico:
- Seleccionar
Add. - Ingresar el nombre y la descripción de la ubicación.
- Registrar la IP WAN pública del Sophos Firewall.
- En caso de múltiples interfaces WAN, ingresar todas las direcciones IP públicas relevantes o un rango adecuado.
- Usar un FQDN DDNS si el diseño se basa en una IP dinámica.
- Guardar la ubicación.
La ubicación es importante porque DNS Protection debe asignar las consultas DNS entrantes a la cuenta de cliente y política correctas. Si falta la ubicación o la IP pública no coincide, Sophos Central no verá correctamente la ubicación.
2. Copiar direcciones IP de DNS Protection
Las direcciones IP de DNS Protection se encuentran en Sophos Central bajo:
My Products > DNS Protection > Installers
Allí se proporcionan dos direcciones IP. Estas se utilizan en Sophos Firewall como servidor DNS primario y secundario. No se deben ingresar otros servidores DNS públicos como respaldo si se desea que todo el tráfico pase por DNS Protection. De lo contrario, los servidores DNS pueden ser utilizados pasando por alto DNS Protection, y se pierde protección y visibilidad.
3. Configurar el reenviador DNS en Sophos Firewall
En Sophos Firewall:
Network > DNS
Procedimiento recomendado:
- Seleccionar
Static DNS. - Configurar
DNS 1con la primera dirección IP de DNS Protection. - Configurar
DNS 2con la segunda dirección IP de DNS Protection. - Dejar
DNS 3vacío, a menos que exista un caso especial consciente. - No configurar servidores DNS IPv6 separados si la ubicación debe funcionar a través de los servidores DNS Protection basados en IPv4.
- Guardar y aplicar la configuración.
DNS Protection funciona como un servicio DNS basado en IPv4, pero también puede resolver direcciones IPv6. Por lo tanto, no se necesita automáticamente un servidor DNS IPv6 separado.
4. Proteger dominios internos con rutas de solicitudes DNS
DNS Protection no resuelve dominios internos. Si se utilizan Active Directory, aplicaciones internas, zonas locales o búsquedas inversas en la red, estas consultas deben dirigirse a servidores DNS internos.
Para ello, se utiliza en Sophos Firewall:
Network > DNS > DNS request route
Ejemplo:
| Campo | Ejemplo |
|---|---|
| Host/domain name | empresa.local o corp.example.com |
| Target servers | Controladores de dominio internos o servidores DNS |
Sin estas rutas, los nombres internos se enviarían a DNS Protection y no se resolverían correctamente allí. El procedimiento exacto se describe en Configurar rutas de solicitudes DNS en Sophos Firewall.
Para entornos productivos, se deben considerar los dominios internos en DNS Protection como una lista de dominios si el dominio podría ser bloqueado por una categoría. Ejemplos típicos son sitios o servicios internos que podrían caer en categorías problemáticas como dominios estacionados.
5. Hacer que los clientes apunten a la firewall mediante DHCP
Los clientes deben utilizar Sophos Firewall como resolutor DNS, no directamente resolutores externos arbitrarios.
Si Sophos Firewall proporciona DHCP:
Network > DHCP
Procedimiento práctico:
- Editar el servidor DHCP de la interfaz afectada.
- Distribuir la dirección IP de la interfaz del firewall como servidor DNS primario.
- No distribuir servidores DNS externos como DNS alternativos para clientes si se desea que DNS Protection se aplique de manera consistente.
- Renovar el arrendamiento DHCP o reconectar el cliente de prueba.
- Verificar con un cliente de prueba qué servidor DNS se está utilizando realmente.
Si se utiliza un servidor DNS de Windows u otro resolutor interno, este resolutor puede reenviar a DNS Protection en lugar de los clientes. Sin embargo, debe quedar claro dónde se resuelven los dominios internos y qué servidor reenvía las consultas públicas.
6. Prevenir la evasión directa de DNS
Muchos clientes utilizan el servidor DNS distribuido por DHCP. Sin embargo, algunos dispositivos, navegadores, sistemas IoT o clientes configurados intencionalmente pueden utilizar sus propios servidores DNS.
Una posible medida es una regla NAT que redirige el tráfico DNS saliente de las redes internas al firewall. En la práctica, esto significa que el tráfico DNS de las redes de origen internas se redirige mediante DNAT a la dirección interna del firewall, para que la consulta pueda ser evaluada por DNS Protection.
Importante:
- Capturar solo redes de origen internas.
- No usar interfaces WAN como interfaz de entrada.
- Colocar la regla en una posición muy alta.
- Documentar excepciones para servidores DNS internos y casos especiales.
- Luego probar si la resolución DNS interna, DNS Protection y los registros siguen siendo correctos.
Los fundamentos de NAT se describen en Entender NAT en Sophos Firewall. No se debe activar una imposición de DNS a ciegas, ya que puede afectar a resolutores internos, clientes VPN, comportamiento DoH/DoT o dispositivos especiales.
Planificar el despliegue en fases
DNS Protection no debe imponerse de inmediato para todas las redes al mismo tiempo. DNS es una función básica: si los nombres internos, las verificaciones de certificados, las actualizaciones de software o los servicios SaaS ya no se resuelven correctamente, puede parecer rápidamente como una falla general de Internet.
Un despliegue controlado se ve así en la práctica:
- Seleccionar una red piloto o un pequeño grupo de prueba.
- Documentar dominios internos, zonas inversas y dominios de búsqueda.
- Configurar rutas de solicitudes DNS para zonas internas.
- Distribuir el firewall como resolutor DNS mediante DHCP.
- Configurar direcciones IP de DNS Protection en el firewall.
- Instalar el certificado de páginas de bloqueo en clientes de prueba.
- Verificar registros en Sophos Central.
- Solo después incluir otras redes, red de invitados, redes de servidores o redes VPN.
Para redes de servidores, se debe ser especialmente cauteloso. Algunos sistemas utilizan DNS para verificación de licencias, actualizaciones, CRL/OCSP, copias de seguridad, monitoreo o comunicación de clústeres. Allí, una ventana de prueba con opción de reversión es más importante que en redes de clientes normales.
Prueba de aceptación antes del despliegue general
Antes del despliegue productivo, debe quedar claro cómo reconocer una implementación de DNS Protection funcional. Solo el enlace de prueba de Sophos no es suficiente para esto.
| Prueba | Resultado esperado |
|---|---|
| Resolver un dominio público | El cliente consulta al firewall o al resolutor interno previsto |
| Resolver un dominio AD interno | La consulta se dirige a través de la ruta de solicitudes DNS a servidores DNS internos |
| Probar búsqueda inversa | Las zonas PTR internas siguen funcionando |
| Abrir un dominio de prueba bloqueado | DNS Protection bloquea y registra el acierto |
| Verificar registros en Sophos Central | Los aciertos aparecen en la ubicación correcta |
| Probar red de invitados | Los invitados utilizan la ruta DNS planificada y no servidores DNS internos |
| Probar cliente VPN | Split-DNS, dominios internos y dominios públicos se comportan como se planeó |
| Verificar DoH del navegador | El navegador o el sistema operativo no evitan el control inesperadamente |
Si alguna de estas pruebas falla, no se debe abrir inmediatamente la política. Primero debe quedar claro si el problema está en DHCP, rutas de solicitudes DNS, asignación de ubicación, perfil de cliente, DoH del navegador, túnel dividido de VPN o categorización de dominios.
7. Planificar políticas y listas de dominios
DNS Protection puede bloquear dominios relevantes para la seguridad incluso sin una política propia, si SophosLabs los clasifica como amenaza o riesgo de seguridad. Las políticas propias complementan esta línea base con directrices empresariales.
Preguntas típicas de política:
- ¿Qué ubicaciones reciben qué política?
- ¿Qué categorías deben bloquearse?
- ¿Qué categorías son problemáticas solo para ciertas ubicaciones?
- ¿Qué dominios deben permitirse explícitamente?
- ¿Quién decide sobre los falsos positivos?
- ¿Cuánto tiempo permanecen vigentes las excepciones?
Las listas de dominios deben gestionarse de manera estricta. Una lista de permitidos amplia puede reducir la efectividad de la protección. Una lista de bloqueados amplia puede interrumpir procesos comerciales. Cada lista necesita un propósito, un responsable y una fecha de revisión.
¿Política de filtrado o política de protección DNS de endpoints?
En Sophos Central hay dos niveles de política que no deben confundirse.
| Tipo de política | Para qué está pensada | Cuándo usar |
|---|---|---|
| Política de filtrado | Filtrado DNS basado en ubicación, firewall o red | Para oficinas, firewalls, servidores DNS, redes de servidores, invitados, IoT y dispositivos sin Sophos Endpoint |
| Política de protección DNS de endpoints | Protección DNS basada en endpoints a través de Sophos Endpoint | Para clientes gestionados, portátiles y usuarios que deben estar protegidos incluso fuera de la red corporativa |
Una política de filtrado se crea en DNS Protection > Policies > Filtering policies y se asigna a una o más ubicaciones o firewalls. Solo puede estar activa una política de filtrado por ubicación. En esta política se definen categorías, listas de dominios y opciones adicionales como Safe Search.
Una política de protección DNS de endpoints utiliza Sophos Endpoint. El endpoint intercepta el tráfico DNS en el dispositivo y lo envía de manera segura a través de HTTPS a DNS Protection. De esta manera, no es necesario configurar manualmente el cliente en las direcciones IP de DNS Protection. Los dispositivos se asignan en la política de endpoints a una ubicación de DNS Protection y luego son controlados por la política de filtrado correspondiente a esa ubicación.
En la práctica, esto significa:
- Para una oficina con Sophos Firewall, la ubicación más política de filtrado es la ruta de red normal.
- Para clientes itinerantes, la política de protección DNS de endpoints es útil, ya que la protección puede aplicarse incluso fuera de la red corporativa.
- Para entornos mixtos, se combinan ambos enfoques: ubicaciones de firewall a través de ubicaciones, endpoints gestionados adicionalmente a través de protección DNS de endpoints.
- Para dominios internos, se deben mantener exclusiones de dominios en las políticas de endpoints. Sophos recomienda excluir explícitamente las zonas internas en lugar de confiar solo en un reintento NXDOMAIN.
- Las páginas de bloqueo en endpoints requieren el certificado raíz de DNS Protection. Con Sophos Endpoint, el certificado se puede distribuir automáticamente.
¿Qué categorías se pueden bloquear?
DNS Protection ofrece categorías que en Sophos Central están organizadas en grupos. Algunas categorías están más relacionadas con la productividad, mientras que otras son claramente relevantes para la seguridad. Los nombres se mantienen en inglés aquí, ya que así se muestran en Sophos Central.
| Grupo de categorías | Categorías típicas | Recomendación |
|---|---|---|
| Categorías relacionadas con la productividad | Advertisements, Auctions & classified ads, Dynamic DNS & ISP sites, Entertainment, Fashion & beauty, Gambling, Games, Hobbies, Hunting & fishing, Kid’s sites, News, Online chat, Online shopping, Personal sites, Photo galleries, Portal sites, Religion & spirituality, Restaurants & dining, Sports, Stocks & trading, Surveillance, Travel, Society & culture, Vehicles | Permitir, bloquear o restringir solo para ciertas redes según la política de la empresa. |
| Redes sociales | Blogs & forums, Personals & dating, Social networks | Generalmente no es una cuestión de seguridad pura. Decidir conscientemente para redes productivas en lugar de bloquear de manera general. |
| Categorías para adultos y potencialmente inapropiadas | Alcohol & tobacco, Controlled substances, Criminal activity, Download freeware & shareware, Extreme, Intellectual piracy, Intolerance & hate, Legal highs, Marijuana, Militancy & extremist, Nudity, Plagiarism, Pro-suicide & self harm, Sex education, Sexually explicit, Swimwear & lingerie, Weapons | Bloquear en muchos entornos empresariales. Excepciones solo con una justificación clara. |
| Categorías que probablemente causen un uso excesivo de ancho de banda | Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting, Voice & video calls | A menudo relevante para redes de invitados y clientes. Verificar previamente con herramientas de colaboración para que las llamadas legítimas no se vean afectadas. |
| Categorías de sitios relevantes para negocios | General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Image search, Information technology, Job search, Military, NGOs & non-profits, Political organizations, Professional & workers organizations, Real estate, Reference, Search engines, Software updates, Translators | Generalmente permitir. Algunas categorías pueden restringirse en redes de alta seguridad. |
| Infraestructura | Content delivery, CRL and OCSP | Normalmente permitir. Estas categorías pueden ser importantes para actualizaciones, verificación de certificados y muchos servicios en la nube. |
| Amenazas y responsabilidades | Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware, Unauthorized software stores | Generalmente bloquear. En caso de falsos positivos, trabajar específicamente con listas de dominios, no abrir grupos completos. |
| Pérdida de datos | Business cloud apps, Personal cloud apps, Personal network storage, Web E-mail | Muy dependiente de las políticas de DLP, nube y cumplimiento. Tratar más estrictamente para redes de servidores y administradores que para usuarios normales. |
| Sin categorizar | Uncategorized | No bloquear a ciegas. Evaluar primero, ya que servicios nuevos o internos legítimos pueden estar sin categorizar temporalmente. |
Las listas de dominios tienen prioridad sobre las categorías. Un dominio permitido en una lista de dominios sigue estando permitido, incluso si la categoría estaría bloqueada. Un dominio bloqueado sigue estando bloqueado, incluso si la categoría estaría permitida. Por lo tanto, las listas de dominios deben documentarse y revisarse regularmente.
8. Páginas de bloqueo y certificados
Para dominios bloqueados, DNS Protection puede mostrar una página de bloqueo HTTPS. Para que los usuarios vean correctamente esta página de bloqueo, el certificado raíz de DNS Protection debe estar instalado de manera confiable en los dispositivos afectados.
Si además está activa la inspección TLS o el filtrado web en el firewall, la planificación de certificados y excepciones debe coincidir. Para la CA del firewall, consulte Distribuir el certificado CA de Sophos Firewall para la inspección TLS.
Si no se muestran las páginas de bloqueo, no se debe ajustar inmediatamente la política. A menudo faltan certificados, el cliente utiliza otra ruta DNS, o blockpage.dnsprotection.sophos.com está siendo interferido por otro control.
Probar DNS Protection
Sophos Central proporciona un enlace de prueba bajo DNS Protection > Installers. Si la configuración es correcta, el navegador mostrará una confirmación.
Además, se debe probar de manera práctica:
- El cliente utiliza el firewall como servidor DNS.
- Un dominio público se resuelve a través de DNS Protection.
- Un dominio interno se resuelve correctamente a través de la ruta de solicitudes DNS.
- Un dominio de prueba bloqueado es bloqueado.
- Los registros aparecen en Sophos Central.
- Las consultas DNS aparecen en la ubicación correcta.
- No se utilizan servidores DNS alternativos.
- La red VPN o de invitados se comporta como se planeó.
Para un análisis de errores real, no solo se debe probar el navegador. nslookup, dig, registros del firewall, arrendamientos DHCP y registros de Sophos Central juntos proporcionan una mejor imagen.
Comandos de prueba para clientes
En un cliente de prueba, primero se debe verificar qué servidor DNS se está utilizando realmente. Una prueba exitosa del navegador no es suficiente si el cliente utiliza paralelamente otro resolutor, DoH o un perfil VPN.
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:
resolvectl status
dig example.com
dig @<firewall-ip> example.com
En estos comandos, <firewall-ip> debe ser reemplazado por la dirección de la interfaz interna de Sophos Firewall que debe servir como resolutor DNS en la red correspondiente. Si la consulta contra el firewall funciona, pero la consulta normal utiliza otro resolutor, el problema generalmente reside en DHCP, el perfil del sistema operativo, el cliente VPN, el DoH del navegador o una configuración DNS local.
Para dominios internos, se debe realizar una prueba adicional con una zona interna:
dig @<firewall-ip> interner-host.corp.example.com
Esta prueba debe aterrizar en el servidor DNS interno adecuado a través de la ruta de solicitudes DNS. Si los dominios públicos funcionan, pero los nombres internos no, DNS Protection rara vez es la causa real. Entonces se deben verificar las rutas de solicitudes DNS, los servidores DNS internos, los dominios de búsqueda y los sufijos DNS del cliente.
Solución de problemas
La ubicación no aparece en Sophos Central
Verificar si la IP WAN pública o el FQDN DDNS en la ubicación son correctos. En caso de múltiples líneas WAN, se deben considerar todas las direcciones de salida relevantes. Con direcciones IP dinámicas, puede haber breves retrasos hasta que DNS Protection reconozca el cambio.
Los nombres internos ya no funcionan
En ese caso, generalmente faltan rutas de solicitudes DNS o los clientes no consultan al resolutor esperado. Los dominios AD internos, las zonas inversas y los dominios de aplicaciones deben dirigirse explícitamente a servidores DNS internos.
DNS Protection bloquea un dominio interno o legítimo
Primero aclarar si el dominio es interno, público, mal categorizado o realmente riesgoso. Luego revisar la lista de dominios y la política. No establecer una regla de permitidos amplia antes de conocer la causa y los usuarios afectados.
Los registros permanecen vacíos
Si no aparecen registros en Sophos Central, es posible que el cliente no esté utilizando DNS Protection. Verificar: DHCP, DNS del cliente, DNS del firewall, redirección NAT, resolutores alternativos, perfil VPN y si la ubicación se reconoce correctamente en Sophos Central.
La página de bloqueo no aparece
En ese caso, a menudo falta el certificado raíz de DNS Protection, el cliente utiliza otra ruta DNS, o un control de seguridad diferente está afectando la conexión. También se deben verificar la inspección TLS y Web Protection.
DoH o DNS privado evita el control
Los navegadores y sistemas operativos pueden utilizar DNS over HTTPS o funciones de DNS privado. Dependiendo del entorno, estas funciones deben gestionarse mediante políticas de navegador, MDM o sistema operativo. DNS Protection en la ruta de red solo ayuda si las consultas realmente pasan por el resolutor previsto.
Los clientes VPN se comportan de manera diferente a los clientes LAN
En los clientes VPN, el comportamiento depende en gran medida del perfil. El túnel completo, el túnel dividido, los sufijos DNS, los dominios de búsqueda y los resolutores locales del cliente pueden influir en la resolución de nombres. Si DNS Protection funciona en la LAN pero no a través de VPN, primero se deben verificar el perfil VPN, los servidores DNS asignados, los sufijos DNS y las reglas del firewall. Para entornos de acceso remoto, también es adecuado Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es adecuada?.
Recomendación de operación
DNS Protection debe operarse como un control de seguridad, no como un simple intercambio de servidores DNS.
Desde la perspectiva de Avanet, se debe decidir honestamente de antemano si DNS Protection es realmente la herramienta adecuada para el entorno. Para muchas instalaciones clásicas de firewall, los resolutores DNS rápidos y redundantes más Threat Feeds bien mantenidos en el firewall son la variante operativa más robusta. DNS Protection vale la pena especialmente si la operación también quiere utilizar activamente las políticas centrales, los registros, las categorías, las listas de dominios y el componente de endpoints.
Verificar regularmente:
- Las ubicaciones y las direcciones IP WAN son correctas.
- DHCP sigue distribuyendo los servidores DNS correctos.
- Las rutas de solicitudes DNS internas están actualizadas.
- Las políticas y listas de dominios tienen responsables y fecha de revisión.
- Los registros se evalúan.
- Los dominios principales bloqueados se revisan por falsos positivos.
- Se consideran nuevos sitios, redes VPN y redes de invitados en el diseño.
Para temas de detección, Operar Sophos Firewall NDR y Active Threat Response puede complementar. Para IPs, dominios y URLs maliciosos conocidos a nivel de firewall, Sophos Firewall Threat Feeds siguen siendo relevantes.
Lista de verificación
- Licencia de Sophos Central DNS Protection verificada.
- Ubicación creada como Location.
- IP WAN pública o FQDN DDNS correctamente registrado.
- Direcciones IP de DNS Protection copiadas de Central.
- Sophos Firewall utiliza DNS Protection como reenviador DNS.
- Dominios internos cubiertos con rutas de solicitudes DNS.
- DHCP distribuye el firewall como resolutor DNS.
- Evasión directa de DNS verificada y redirigida por NAT si es necesario.
- Certificado raíz de DNS Protection planificado para páginas de bloqueo.
- Enlace de prueba de Sophos Central verificado con éxito.
- Registros e informes en Sophos Central controlados.
- Proceso de falsos positivos y revisión de listas de dominios definidos.