DNS Over HTTPS (DoH): implicaciones para el filtrado de WiFi público

Bienvenido al Informe Técnico de Purple. Soy su anfitrión para la sesión de hoy y vamos a dedicar los próximos diez minutos a un tema que actualmente está socavando silenciosamente las políticas de filtrado de contenido en miles de despliegues de WiFi público: DNS sobre HTTPS, o DoH. Si gestiona el WiFi para invitados en un hotel, un comercio, un estadio o una instalación del sector público, y no ha abordado específicamente el DoH en la arquitectura de su red, es bastante probable que su política de filtrado tenga un vacío importante. Veamos exactamente en qué consiste ese vacío, por qué es importante y qué puede hacer al respecto. Sección uno - Contexto y planteamiento del problema. Comencemos con un breve repaso de cómo funciona el filtrado DNS tradicional, ya que para comprender el mecanismo de evasión es necesario entender qué se está esquivando. Cuando el dispositivo de un invitado se conecta a su WiFi e intenta visitar un sitio web, lo primero que hace es enviar una consulta DNS, básicamente preguntando cuál es la dirección IP de ese dominio. Esa consulta viaja a través de UDP o TCP por el puerto 53. Su infraestructura de red intercepta esa consulta, la redirige al resolver DNS de su elección y dicho resolver contrasta el dominio con su política de filtrado. Si el dominio está en una lista de bloqueo (malware, contenido para adultos, apuestas o lo que especifique su política de uso aceptable), el resolver se niega a devolver la dirección IP y la conexión nunca se produce. Esta es la base de todo despliegue de filtrado de contenido basado en DNS. Es rentable, no afecta al rendimiento y ha sido el enfoque estándar para los operadores de recintos durante casi una década. El DNS sobre HTTPS rompe este modelo. Así es como funciona. El DoH envuelve las consultas DNS dentro del tráfico HTTPS estándar en el puerto 443. Desde la perspectiva de su red, parece idéntico a cualquier otro tráfico web cifrado. No hay forma de distinguir una consulta DoH de un usuario que carga una página web, transmite un vídeo o accede a una aplicación bancaria. La consulta va directamente a un resolver DoH externo (el 8.8.8.8 de Google, el 1.1.1.1 de Cloudflare o cualquier otro) a través de un canal cifrado que su filtro DNS no puede inspeccionar. ¿El resultado? Su política de filtrado DNS meticulosamente configurada se esquiva por completo. El dispositivo resuelve el dominio directamente, sin que su resolver llegue a ver la consulta. Ahora bien, esto no es un ataque deliberado por parte de sus invitados. En la mayoría de los casos, es algo totalmente pasivo. Firefox tiene el DoH activado por defecto desde 2020. Chrome actualiza automáticamente las consultas DNS a DoH si el resolver configurado lo admite. Android 9 y versiones superiores admiten DNS privado con DNS sobre TLS de forma predeterminada. iOS admite perfiles de configuración DoH desde iOS 14. Se trata de dispositivos de consumo generalistas que hacen lo que sus fabricantes diseñaron. Sus invitados no intentan saltarse el filtrado. Sus dispositivos simplemente lo hacen de forma automática. Sección dos - Análisis técnico detallado. Entremos en los detalles técnicos. Existen dos patrones principales de implementación de DoH que encontrará en la práctica. El primero es el DoH a nivel de aplicación, donde la aplicación - normalmente un navegador - mantiene su propia configuración de DoH de forma independiente de la configuración DNS del sistema operativo. Firefox es el ejemplo canónico. Cuando Firefox está instalado y el DoH está habilitado, ignora por completo el resolvedor DNS del sistema y envía todas sus consultas DNS a su proveedor de DoH configurado, que por defecto es Cloudflare. Su servidor DNS asignado por DHCP es irrelevante. Sus reglas de interceptación del puerto 53 son irrelevantes. Firefox está manteniendo una conversación DNS completamente separada a través del puerto 443 que usted no puede ver. El segundo patrón es el DoH a nivel de sistema operativo, donde el propio sistema operativo se encarga de la actualización. Chrome y Windows 10 y 11 adoptan este enfoque. Comprueban si el resolvedor DNS configurado en el sistema - el asignado por su servidor DHCP - tiene un endpoint DoH correspondiente. Si es así, se actualizan automáticamente a DoH. Esto se denomina DoH oportunista. Si está asignando 8.8.8.8 como su servidor DNS de invitados, Chrome utilizará automáticamente el endpoint DoH de Google. Si está asignando 1.1.1.1, utilizará el endpoint DoH de Cloudflare. La distinción es importante para su estrategia de mitigación, que abordaremos en breve. Hay un tercer vector que vale la pena mencionar: DNS over TLS, o DoT. Este funciona en el puerto 853 y cifra las consultas DNS utilizando TLS en lugar de envolverlas en HTTPS. Es más fácil de bloquear que el DoH porque utiliza un puerto dedicado, pero es cada vez más común en dispositivos Android con Private DNS habilitado. Su estrategia de mitigación debe abordar ambos. Ahora hablemos de por qué esto representa un riesgo operativo y de cumplimiento, y no solo una curiosidad técnica. Bajo el GDPR, si su política de uso aceptable establece que filtra ciertas categorías de contenido, y sus controles técnicos no aplican realmente esa política, existe una brecha entre sus compromisos declarados de protección de datos y gobernanza de contenidos y su implementación técnica real. Eso es un problema de defensa si alguna vez se enfrenta a una investigación regulatoria o a un incidente. Bajo la Online Safety Act del Reino Unido, los operadores de establecimientos que ofrecen acceso público a internet tienen obligaciones relacionadas con la protección de los usuarios - especialmente los menores - frente a contenidos nocivos. Si el DoH está omitiendo silenciosamente su filtrado de contenido, es posible que no esté cumpliendo con esas obligaciones. Para los establecimientos que entran dentro del alcance de PCI-DSS - en particular aquellos donde los datos de tarjetas de pago fluyen por redes adyacentes al WiFi de invitados - la versión 4.0 de PCI-DSS exige que supervise y controle el tráfico DNS como parte de sus controles de seguridad de red. El tráfico DoH no supervisado representa una brecha en ese marco de control. Y desde el punto de vista de la seguridad pura, el DoH ha sido explotado activamente por malware. Los actores de amenazas han utilizado DoH como canal de comando y control porque se camufla con el tráfico HTTPS normal. La puerta trasera GodLua utilizó DoH para las comunicaciones de comando y control. El malware PsiXBot utilizó el servicio DoH de Google. Si su supervisión de seguridad depende de la visibilidad de DNS para detectar actividades maliciosas, los puntos ciegos de DoH son una amenaza real. Sección tres - recomendaciones de implementación. Bien, pasemos a la práctica. Existen tres estrategias de mitigación principales, y en la mayoría de los despliegues en establecimientos, lo ideal es implementar las tres de forma combinada. Estrategia uno: bloquear endpoints de resolución DoH conocidos en el firewall. Esta es su primera línea de defensa y la opción más rápida de desplegar. Mantenga una lista de bloqueo de direcciones IP y dominios de servidores de resolución DoH conocidos (Google, Cloudflare, Quad9, NextDNS, AdGuard, entre otros) y deniegue el tráfico HTTPS saliente hacia esos endpoints desde su VLAN de invitados. El IETF y varios proveedores de seguridad publican y mantienen estas listas. El proyecto curl en GitHub mantiene una lista exhaustiva de servidores de resolución DoH conocidos que constituye un buen punto de partida. Este enfoque gestiona la mayor parte del tráfico DoH ya que, como ha demostrado la investigación del Software Engineering Institute de Carnegie Mellon, la mayor parte del tráfico DoH se dirige a un pequeño número de servidores de resolución conocidos. Los usuarios que saben lo suficiente sobre DNS como para configurar un servidor de resolución DoH personalizado son una minoría muy pequeña. La limitación de este enfoque es que se trata de una lista de bloqueo, y las listas de bloqueo requieren mantenimiento. Constantemente aparecen nuevos servidores de resolución DoH. Sin embargo, combinada con las otras estrategias, ofrece una cobertura sólida. Estrategia dos: inspección TLS en su firewall de próxima generación. Los firewalls de próxima generación de proveedores como Palo Alto Networks, Fortinet, Check Point y Cisco Firepower admiten la inspección TLS (también llamada inspección SSL o inspección profunda de paquetes). Cuando está habilitada, el firewall actúa como intermediario (man-in-the-middle) para el tráfico HTTPS, descifrándolo, inspeccionando la carga útil y volviéndolo a cifrar antes de reenviarlo. Esto permite al firewall identificar el tráfico DoH incluso cuando se dirige a un servidor de resolución desconocido. App-ID de Palo Alto puede identificar específicamente el tráfico DoH y aplicarle políticas. FortiGate de Fortinet tiene una capacidad similar. El paso de configuración clave es asegurarse de que el tráfico de su VLAN de invitados se enrute a través de la política de inspección. La consideración operativa aquí es la confianza en los certificados. Para que la inspección TLS funcione en los dispositivos de los invitados, estos dispositivos deben confiar en su certificado de inspección. En dispositivos corporativos gestionados, esto es sencillo: se distribuye el certificado a través de un MDM. En dispositivos de invitados no gestionados, es más complejo. El enfoque práctico para el WiFi de invitados es utilizar el flujo de aceptación del Captive Portal para informar a los usuarios de que el tráfico puede ser inspeccionado con fines de filtrado de contenidos, y confiar en la combinación del bloqueo del servidor de resolución DoH y la interceptación de DNS como controles principales, utilizando la inspección TLS como una capa secundaria para entornos de mayor riesgo. Estrategia tres: forzar la interceptación y el redireccionamiento de DNS. Configure su firewall o controlador inalámbrico para interceptar todo el tráfico DNS saliente en los puertos UDP y TCP 53 y redirigirlo a su servidor de resolución DNS compatible. Esto no detiene el DoH, pero garantiza que cualquier tráfico DNS que recurra al puerto 53 (porque el DoH falló o no estaba disponible) sea capturado y filtrado. Combine esto con el bloqueo del puerto 853 saliente desde la VLAN de invitados para evitar que DNS over TLS eluda sus controles. Para terminales gestionados (dispositivos corporativos, dispositivos del personal) dispone de una opción adicional: la configuración de políticas de grupo o MDM para desactivar DoH a nivel de navegador y de sistema operativo. En Firefox, la preferencia network.trr.mode establecida en 5 desactiva DoH por completo. En Chrome, la marca disable-features equals DnsOverHttps consigue lo mismo. Windows 10 y 11 disponen de configuraciones de directiva de grupo para controlar el comportamiento de DoH. Este es el control más fiable para dispositivos gestionados, pero no es aplicable a dispositivos de invitados no gestionados. Sección cuatro - errores comunes de implementación. Algunas cosas que suelen fallar sobre el terreno. El modo de fallo más frecuente es la interceptación incompleta del puerto 53. Los equipos configuran correctamente su servicio de filtrado DNS pero olvidan añadir la regla de cortafuegos que redirige todo el tráfico saliente del puerto 53. Los dispositivos con configuraciones DNS codificadas de forma fija (8.8.8.8, 1.1.1.1) eluden el filtro por completo. Verifique siempre que esta regla está activa y pruébela configurando un dispositivo de prueba con un servidor DNS codificado de forma fija para confirmar que los dominios filtrados siguen estando bloqueados. El segundo fallo común es no tener en cuenta IPv6. Las consultas DNS a través de IPv6 son cada vez más frecuentes, y muchas reglas de cortafuegos están escritas únicamente para IPv4. Asegúrese de que su interceptación del puerto 53 y las listas de bloqueo de resolutores DoH cubren tanto las direcciones IPv4 como las IPv6. Tercero: listas de bloqueo de resolutores DoH desactualizadas. Si mantiene una lista de bloqueo estática de direcciones IP de resolutores DoH, esta quedará obsoleta. Automatice el proceso de actualización o utilice un servicio de filtrado DNS que mantenga esta lista por usted. Cloudflare Gateway, Cisco Umbrella y servicios DNS corporativos similares incluyen la detección de elusión de DoH como una función gestionada. Cuarto: dependencia excesiva de una única capa de mitigación. La mitigación de DoH es un problema de defensa en profundidad. Ningún control por sí solo es suficiente. El bloqueo de resolutores conocidos gestiona la mayoría de los casos. La inspección TLS gestiona los casos límite. La interceptación DNS proporciona una red de seguridad. Aplique las tres capas. Sección cinco - preguntas rápidas. ¿La mitigación de DoH interrumpe el funcionamiento de herramientas de privacidad legítimas? Potencialmente, sí. Si un usuario tiene una configuración de navegador legítima centrada en la privacidad, el bloqueo de DoH le obligará a utilizar su resolutor DNS. Su política de uso aceptable debe dejar claro que el resolutor DNS del establecimiento se utiliza con fines de filtrado de contenidos. Esta es una práctica habitual y legalmente defendible. ¿Se puede utilizar DoH para exfiltrar datos de mi red? Sí, y este es un vector de amenaza real. Se ha demostrado la existencia de túneles DNS sobre DoH en entornos reales. La función de detección de DoH de su cortafuegos de próxima generación debería incluir la detección de anomalías para volúmenes de consultas inusualmente altos o patrones de consulta coherentes con la tunelización. ¿Qué ocurre con las aplicaciones móviles que utilizan DoH? Este es el caso más complejo. Las aplicaciones móviles que implementan su propio stack de DoH —en lugar de utilizar la configuración de DNS del sistema operativo— son difíciles de controlar sin inspección TLS. Su mejor mitigación es la combinación del bloqueo de resolvedores conocidos y la inspección TLS. ¿Es relevante WPA3 en este caso? WPA3 mejora el cifrado inalámbrico y proporciona confidencialidad directa perfecta, lo cual es excelente para la privacidad de los invitados. Sin embargo, WPA3 no soluciona el problema de DoH; se trata de un problema del protocolo de aplicación de capa 7, no de un problema de seguridad inalámbrica de capa 2. Son controles complementarios que abordan vectores de amenaza diferentes. Sección seis: ROI e impacto empresarial. Permítame concluir con el caso de negocio para abordar esto adecuadamente. El coste de no abordar el DoH es asimétrico. Un solo incidente —un invitado que accede a contenidos ilegales en su red, una comunicación de malware que pasa desapercibida porque su monitorización de DNS tenía un punto ciego, o una consulta regulatoria sobre su conformidad con el filtrado de contenidos— puede costar significativamente más que la inversión en una mitigación adecuada. Para un grupo hotelero que opera en 20 propiedades, implementar la mitigación de DoH suele implicar un esfuerzo de configuración único de dos a cuatro horas por propiedad para las reglas del cortafuegos y la configuración de interceptación de DNS, además de un gasto operativo continuo para mantener las listas de bloqueo de resolvedores, algo que está muy automatizado si se utiliza un servicio gestionado de filtrado de DNS. La inversión total es modesta en relación con la reducción del riesgo. Para las cadenas de tiendas que operan bajo PCI-DSS, el beneficio de cumplimiento es directamente cuantificable. Demostrar que los controles de seguridad de su red incluyen la mitigación de DoH reduce el riesgo de un hallazgo en la auditoría de PCI-DSS y los costes de remediación asociados. Para los recintos del sector público y aquellos que operan bajo la ley de seguridad en línea (Online Safety Act), la mitigación documentada de DoH forma parte de sus pruebas de que han tomado medidas técnicas razonables para aplicar su política de filtrado de contenidos. En conclusión: DoH no es un problema del futuro. Es un problema del presente. Firefox, Chrome, Android e iOS ya están ofreciendo configuraciones compatibles con DoH en los dispositivos de sus invitados en este mismo momento. Si no ha auditado su arquitectura de filtrado de DNS para detectar vectores de elusión de DoH en los últimos 12 meses, esa auditoría debería estar en su hoja de ruta a corto plazo. Para resumir los puntos clave de la sesión de hoy. Primero: DoH cifra las consultas DNS dentro de HTTPS en el puerto 443, haciéndolas invisibles para el filtrado de DNS tradicional del puerto 53. Esto está ocurriendo de forma predeterminada en los navegadores y sistemas operativos principales. Segundo: La estrategia de mitigación de tres capas —bloquear las IP de resolvedores DoH conocidos, implementar la inspección TLS en su cortafuegos de próxima generación y aplicar la interceptación del puerto 53— proporciona una cobertura de defensa en profundidad tanto para los dispositivos de invitados gestionados como para los no gestionados. Tercero: Este es un problema de cumplimiento, no solo técnico. El GDPR, la ley de seguridad en línea (Online Safety Act) y PCI-DSS tienen implicaciones para los recintos donde el DoH está eludiendo silenciosamente las políticas de filtrado de contenidos. Cuatro: El fallo de implementación más común es la interceptación incompleta del puerto 53. Pruébelo. Verifíquelo. No asuma que está funcionando. Cinco: Los servicios gestionados de filtrado DNS - Cloudflare Gateway, Cisco Umbrella y similares - incluyen cada vez más la detección de evasión de DoH como una capacidad gestionada, lo que reduce la sobrecarga operativa de mantener listas de bloqueo estáticas. Eso es todo por hoy en este Purple Technical Briefing. Si desea auditar su arquitectura de filtrado DNS actual o implementar la mitigación de DoH en todo su patrimonio de sedes, la plataforma Purple proporciona la inteligencia de red y la capa de gestión de WiFi para invitados necesaria para dar soporte a ese despliegue. Gracias por escucharnos y nos vemos en la próxima sesión.