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

Bienvenidos al Purple Technical Briefing. 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 implementaciones de WiFi público: DNS over HTTPS, o DoH. Si gestiona WiFi de invitados en un hotel, una cadena de tiendas de retail, un estadio o una instalación del sector público, y no ha abordado específicamente el DoH en su arquitectura de red, existe una probabilidad razonable de que su política de filtrado tenga una brecha importante. Analicemos exactamente en qué consiste esa brecha, por qué es importante y qué puede hacer al respecto. Sección uno: contexto y planteamiento del problema. Comencemos con un breve resumen de cómo funciona el filtrado DNS tradicional, porque para entender el mecanismo de evasión es necesario comprender qué es lo que se está evadiendo. 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, pregunta cuál es la dirección IP de ese dominio. Esa consulta viaja a través de UDP o TCP en el puerto 53. Su infraestructura de red intercepta esa consulta, la enruta al resolutor DNS de su elección y ese resolutor verifica 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 resolutor se niega a devolver la dirección IP y la conexión nunca se realiza. Esta es la base de cualquier implementación de filtrado de contenido basada en DNS. Es rentable, no afecta el rendimiento y ha sido el enfoque estándar para los operadores de establecimientos durante casi una década. DNS over HTTPS rompe este modelo. Así es como lo hace. DoH envuelve las consultas DNS dentro del tráfico HTTPS estándar en el puerto 443. Desde la perspectiva de su red, se ve 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 video o accede a una aplicación bancaria. La consulta va directamente a un resolutor DoH externo (como 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 cuidadosamente configurada se evade por completo. El dispositivo resuelve el dominio directamente, sin que su resolutor llegue a ver la consulta. Ahora bien, esto no es un ataque deliberado de sus invitados. En la mayoría de los casos, es completamente pasivo. Firefox tiene DoH habilitado de forma predeterminada desde 2020. Chrome actualiza automáticamente las consultas DNS a DoH si el resolutor configurado lo admite. Android 9 y versiones posteriores admiten DNS privado con DNS over TLS de forma predeterminada. iOS admite perfiles de configuración de DoH desde iOS 14. Estos son dispositivos de consumo masivo que hacen lo que sus fabricantes planearon. Sus invitados no intentan evadir su filtrado; sus dispositivos simplemente lo hacen de forma automática. Sección dos: el análisis técnico profundo. Entremos en la mecánica. Hay dos patrones principales de implementación de DoH que encontrará en el campo. 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 los ajustes de DNS del sistema operativo. Firefox es el ejemplo canónico. Cuando Firefox está instalado y DoH está habilitado, ignora por completo el resolutor DNS del sistema y envía todas sus consultas DNS a su proveedor de DoH configurado, que de forma predeterminada es Cloudflare. Su servidor DNS asignado por DHCP es irrelevante. Sus reglas de intercepción del puerto 53 son irrelevantes. Firefox mantiene una conversación DNS completamente independiente 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 gestiona la actualización. Chrome y Windows 10 y 11 adoptan este enfoque. Verifican si el resolutor DNS configurado en el sistema (el asignado por su servidor DHCP) tiene un endpoint de DoH correspondiente. Si es así, se actualizan automáticamente a DoH. Esto se conoce como DoH oportunista. Si asigna 8.8.8.8 como su servidor DNS de invitados, Chrome utilizará automáticamente el endpoint de DoH de Google. Si asigna 1.1.1.1, utilizará el endpoint de DoH de Cloudflare. La distinción es importante para su estrategia de mitigación, la cual abordaremos en breve. Hay un tercer vector que vale la pena mencionar: DNS over TLS, o DoT. Este opera 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 DNS privado 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 realmente no aplican esa política, tiene una brecha entre sus compromisos declarados de protección de datos y gobernanza de contenido y su implementación técnica real. Eso representa un problema de defensa si alguna vez se enfrenta a una investigación regulatoria o a un incidente. Bajo la Ley de Seguridad en Línea (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 de edad, frente al contenido nocivo. Si el DoH está evadiendo silenciosamente su filtrado de contenido, es posible que no esté cumpliendo con esas obligaciones. Para los establecimientos que entran en el alcance de PCI DSS, especialmente aquellos donde los datos de tarjetas de pago fluyen por redes adyacentes al WiFi de invitados, la versión 4.0 de PCI DSS requiere que monitoree y controle el tráfico DNS como parte de sus controles de seguridad de red. El tráfico DoH no monitoreado representa una brecha en ese marco de control. Y desde un punto de vista de seguridad puro, el DoH ha sido explotado activamente por malware. Los actores de amenazas han utilizado DoH como un canal de comando y control porque se mezcla con el tráfico HTTPS normal. La puerta trasera GodLua utilizó DoH para comunicaciones de comando y control. El malware PsiXBot utilizó el servicio DoH de Google. Si su monitoreo de seguridad depende de la visibilidad de DNS para detectar actividad maliciosa, 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 las implementaciones en establecimientos, querrá implementar las tres de forma combinada. Estrategia uno: bloquear los endpoints de los resolutores DoH conocidos en el firewall. Esta es su primera línea de defensa y la opción de implementación más inmediata. Mantenga una lista de bloqueo de direcciones IP y dominios de resolutores 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 completa de resolutores DoH conocidos que es un buen punto de partida. Este enfoque gestiona la mayoría del tráfico DoH porque, como ha demostrado la investigación del Instituto de Ingeniería de Software de Carnegie Mellon, la mayor parte del tráfico DoH se dirige a un pequeño número de resolutores muy conocidos. Los usuarios que saben lo suficiente sobre DNS como para configurar un resolutor 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. Regularmente aparecen nuevos resolutores DoH. Sin embargo, combinada con las otras estrategias, proporciona 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 un intermediario (man-in-the-middle) para el tráfico HTTPS, descifrándolo, inspeccionando el contenido y volviéndolo a cifrar antes de reenviarlo. Esto permite al firewall identificar el tráfico DoH incluso cuando se dirige a un resolutor 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 clave de configuración 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 el certificado. Para que la inspección TLS funcione en los dispositivos de los invitados, estos deben confiar en su certificado de inspección. En dispositivos corporativos administrados, esto es sencillo: se distribuye el certificado a través de un MDM. En dispositivos de invitados no administrados, 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 que el tráfico puede ser inspeccionado con fines de filtrado de contenido, y depender de la combinación del bloqueo de resolutores DoH y la intercepción de DNS como sus controles principales, con la inspección TLS como una capa secundaria para entornos de mayor riesgo. Estrategia tres: forzar la intercepción y redirección de DNS. Configure su firewall o controlador inalámbrico para interceptar todo el tráfico DNS saliente en el puerto UDP y TCP 53 y redireccionarlo a su resolutor DNS compatible. Esto no detiene el DoH, pero garantiza que cualquier tráfico DNS que recurra al puerto 53 (debido a que 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 el DNS over TLS evada sus controles. Para endpoints administrados (dispositivos corporativos, dispositivos del personal), tiene una opción adicional: la configuración de Directivas de grupo o MDM para desactivar DoH a nivel de navegador y sistema operativo. En Firefox, la preferencia network.trr.mode establecida en 5 desactiva DoH por completo. En Chrome, la bandera disable-features igual a DnsOverHttps logra lo mismo. Windows 10 y 11 tienen configuraciones de Directivas de grupo para controlar el comportamiento de DoH. Este es el control más confiable para dispositivos administrados, pero no es aplicable a dispositivos de invitados no administrados. Sección cuatro: errores comunes de implementación. Algunas cosas que suelen salir mal en el campo. El modo de falla más frecuente es la intercepción incompleta del puerto 53. Los equipos configuran correctamente su servicio de filtrado DNS pero olvidan agregar la regla de firewall que redirecciona todo el tráfico saliente del puerto 53. Los dispositivos con configuraciones DNS codificadas de forma rígida (8.8.8.8, 1.1.1.1) evaden el filtro por completo. Siempre verifique que esta regla esté activa y pruébela configurando un dispositivo de prueba con un servidor DNS codificado de forma rígida y confirmando que los dominios filtrados sigan bloqueados. El segundo error común es no tener en cuenta el protocolo IPv6. Las consultas DNS sobre IPv6 son cada vez más comunes y muchas reglas de firewall están escritas solo para IPv4. Asegúrese de que sus listas de bloqueo de intercepción del puerto 53 y de resolutores DoH cubran 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 se desactualizará. 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 empresariales similares incluyen la detección de evasión de DoH como una capacidad administrada. Cuarto: dependencia excesiva de una sola capa de mitigación. La mitigación de DoH es un problema de defensa en profundidad. Ningún control único es suficiente. Bloquear resolutores conocidos gestiona la mayoría de los casos. La inspección TLS gestiona los casos límite. La intercepción de DNS proporciona una red de seguridad. Implemente las tres capas. Sección cinco: preguntas rápidas. ¿La mitigación de DoH interrumpe las herramientas de privacidad legítimas? Potencialmente, sí. Si un usuario tiene una configuración de navegador legítima centrada en la privacidad, su bloqueo de DoH lo 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 contenido. Esta es una práctica estándar y legalmente defendible. ¿Se puede utilizar DoH para la filtración de datos de mi red? Sí, y este es un vector de amenaza real. Se ha demostrado en la práctica el uso de túneles DNS sobre DoH. La capacidad de detección de DoH de su firewall de próxima generación debe incluir la detección de anomalías para volúmenes de consultas inusualmente altos o patrones de consulta consistentes con el uso de túneles. ¿Qué pasa con las aplicaciones móviles que utilizan DoH? Este es el caso más difícil. Las aplicaciones móviles que implementan su propia pila 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 resolutores conocidos y la inspección TLS. ¿Es relevante WPA3 aquí? 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 aborda el DoH; ese es un problema del protocolo de aplicación de capa 7, no un problema de seguridad inalámbrica de capa 2. Son controles complementarios que abordan diferentes vectores de amenazas. Sección seis: ROI e impacto comercial. Cerremos con el caso de negocio para abordar esto de manera adecuada. El costo de no abordar el DoH es asimétrico. Un solo incidente (un invitado que accede a contenido ilegal en su red, una comunicación de malware que pasa desapercibida porque su monitoreo de DNS tenía un punto ciego o una investigación regulatoria sobre su cumplimiento de filtrado de contenido) 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 generalmente implica un esfuerzo de configuración único de dos a cuatro horas por propiedad para las reglas de firewall y la configuración de intercepción de DNS, además de un costo operativo continuo para mantener las listas de bloqueo de resolutores, lo cual está automatizado en gran medida si utiliza un servicio administrado de filtrado DNS. La inversión total es modesta en relación con la reducción del riesgo. Para las cadenas de tiendas de retail que operan bajo PCI DSS, el beneficio de cumplimiento es directamente cuantificable. Demostrar que sus controles de seguridad de red incluyen la mitigación de DoH reduce el riesgo de un hallazgo en la auditoría de PCI DSS y los costos de remediación asociados. Para los establecimientos 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 su base de evidencia de que ha tomado medidas técnicas razonables para aplicar su política de filtrado de contenido. En resumen: el DoH no es un problema del futuro. Es un problema del presente. Firefox, Chrome, Android e iOS ya están enviando configuraciones compatibles con DoH a los dispositivos de sus invitados en este momento. Si no ha auditado su arquitectura de filtrado DNS en busca de vectores de evasión de DoH en los últimos 12 meses, esa auditoría debería estar en su plan de trabajo a corto plazo. Para resumir los puntos clave de la sesión de hoy. Uno: DoH cifra las consultas DNS dentro de HTTPS en el puerto 443, haciéndolas invisibles para el filtrado DNS tradicional del puerto 53. Esto está sucediendo de forma predeterminada en los navegadores y sistemas operativos más populares. Dos: La estrategia de mitigación de tres capas (bloquear las IP de resolutores DoH conocidos, implementar la inspección TLS en su firewall de próxima generación y aplicar la intercepción del puerto 53) proporciona una cobertura de defensa en profundidad tanto para dispositivos de invitados administrados como no administrados. Tres: Este es un problema de cumplimiento, no solo técnico. GDPR, la Ley de Seguridad en Línea (Online Safety Act) y PCI DSS tienen implicaciones para los establecimientos donde el DoH evade silenciosamente las políticas de filtrado de contenido. Cuatro: El fallo de implementación más común es la intercepción incompleta del puerto 53. Pruébela. Verifíquela. No asuma que está funcionando. Cinco: Los servicios administrados 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 administrada, lo que reduce el costo operativo de mantener listas de bloqueo estáticas. Con esto concluimos el Purple Technical Briefing de hoy. Si desea auditar su arquitectura de filtrado DNS actual o implementar la mitigación de DoH en sus establecimientos, la plataforma Purple proporciona la inteligencia de red y la capa de gestión de WiFi de invitados para respaldar esa implementación. Gracias por escuchar, y nos vemos en la próxima sesión.