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

Bienvenidos a la sesión informativa técnica 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 over HTTPS, o DoH. Si gestiona WiFi de invitados en un hotel, un complejo comercial, un estadio o una instalación del sector público, y no ha abordado específicamente el DoH en su arquitectura de red, es muy probable 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 elusión es necesario comprender qué se está eludiendo. 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 enruta al resolvedor DNS que haya elegido, y ese resolvedor comprueba 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 resolvedor se niega a devolver la dirección IP y la conexión nunca se realiza. Esta es la base de cualquier 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 establecimientos durante casi una década. DNS over HTTPS rompe este modelo. Así es cómo lo hace. 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, reproduce un vídeo en streaming o accede a una aplicación bancaria. La consulta va directamente a un resolvedor 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 cuidadosamente configurada se elude por completo. El dispositivo resuelve el dominio directamente, sin que su resolvedor llegue a ver la consulta. Ahora bien, esto no es un ataque deliberado de sus invitados. En la mayoría de los casos, es totalmente pasivo. Firefox tiene el DoH habilitado por defecto desde 2020. Chrome actualiza automáticamente las consultas DNS a DoH si el resolvedor configurado lo admite. Android 9 y versiones posteriores admiten DNS privado con DNS over TLS por defecto. iOS admite perfiles de configuración de DoH desde iOS 14. Se trata de dispositivos de consumo generalistas que hacen lo que sus fabricantes planearon. Sus invitados no intentan eludir 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 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 a los ajustes de 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 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. Comprueban si el resolvedor DNS configurado en el sistema (el asignado por su servidor DHCP) tiene un extremo DoH correspondiente. Si es así, se actualizan automáticamente a DoH. Esto se denomina DoH oportunista. Si asigna 8.8.8.8 como su servidor DNS de invitados, Chrome utilizará automáticamente el extremo DoH de Google. Si asigna 1.1.1.1, utilizará el extremo 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 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. Hablemos ahora de por qué esto representa un riesgo operativo y de cumplimiento normativo, 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 contenido 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 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, frente a contenidos nocivos. Si el DoH está eludiendo 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, especialmente aquellos donde los datos de las 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 un punto de vista de seguridad pura, el DoH ha sido explotado activamente por el malware. Los actores de amenazas han utilizado el 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, seamos prácticos. Existen tres estrategias de mitigación principales y, en la mayoría de los despliegues en establecimientos, querrá implementar las tres de forma combinada. Estrategia uno: bloquear los extremos de los resolvedores DoH conocidos en el firewall. Esta es su primera línea de defensa y la opción de despliegue más inmediato. Mantenga una lista de bloqueo de direcciones IP y dominios de resolvedores DoH conocidos (Google, Cloudflare, Quad9, NextDNS, AdGuard, entre otros) y deniegue el tráfico HTTPS saliente hacia esos extremos 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 resolvedores DoH conocidos que constituye 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 resolvedores muy conocidos. Los usuarios que saben lo suficiente sobre DNS como para configurar un resolvedor 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 resolvedores DoH. Pero, 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 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 resolvedor 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 la 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 los dispositivos corporativos gestionados, esto es sencillo: se distribuye el certificado a través de MDM. En los 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 contenido, y confiar en la combinación del bloqueo de resolvedores 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 resolvedor 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 los extremos gestionados (dispositivos corporativos, dispositivos del personal), tiene una opción adicional: la configuración de directivas de grupo o MDM para desactivar el DoH a nivel de navegador y de sistema operativo. En Firefox, la preferencia network.trr.mode establecida en 5 desactiva el DoH por completo. En Chrome, el indicador disable-features igual a DnsOverHttps logra lo mismo. Windows 10 and 11 tienen configuraciones de directivas 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 salir mal en la práctica. El modo de fallo más frecuente es la intercepción incompleta del puerto 53. Los equipos configuran correctamente su servicio de filtrado DNS pero olvidan añadir la regla de firewall que redirecciona 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 y confirmando que los dominios filtrados siguen bloqueados. El segundo fallo común es no tener en cuenta 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 resolvedores DoH cubran tanto las direcciones IPv4 como las IPv6. Tercero: listas de bloqueo de resolvedores DoH desactualizadas. Si mantiene una lista de bloqueo estática de IP de resolvedores 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 empresariales similares incluyen la detección de elusión de DoH como una capacidad gestionada. Cuarto: confianza excesiva en una sola capa de mitigación. La mitigación de DoH es un problema de defensa en profundidad. Ningún control por sí solo es suficiente. Bloquear resolvedores 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. Superponga las tres capas. Sección cinco: preguntas rápidas. ¿La mitigación de DoH rompe herramientas de privacidad legítimas? Potencialmente, sí. Si un usuario ejecuta una configuración de navegador legítima centrada en la privacidad, su bloqueo de DoH le obligará a utilizar su resolvedor DNS. Su política de uso aceptable debe dejar claro que el resolvedor DNS del establecimiento se utiliza con fines de filtrado de contenido. Esta es una práctica estándar y legalmente defendible. ¿Se puede utilizar el DoH para exfiltrar 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é ocurre 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 DoH (en lugar de utilizar la configuración 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 el WPA3 aquí? El WPA3 mejora el cifrado inalámbrico y proporciona confidencialidad directa perfecta, lo cual es excelente para la privacidad de los invitados. Pero el WPA3 no aborda el 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 diferentes vectores de amenazas. Sección seis: ROI e impacto empresarial. Cerremos con el caso de negocio para abordar esto correctamente. El coste de no abordar el DoH es asimétrico. Un solo incidente (un invitado que accede a contenido ilegal en su red, una llamada de retorno de malware que pasa desapercibida porque su monitorización DNS tenía un punto ciego, una investigación regulatoria sobre su cumplimiento del 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 suele implicar 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 coste operativo continuo para mantener las listas de bloqueo de resolvedores, lo cual está automatizado en gran medida si utiliza un servicio de filtrado DNS gestionado. 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 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 costes 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 pruebas de que ha tomado medidas técnicas razonables para aplicar su política de filtrado de contenido. En conclusión: 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 mismo momento. Si no ha auditado su arquitectura de filtrado DNS en busca de 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 informativa de hoy. Uno: el 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á ocurriendo por defecto en los principales navegadores y sistemas operativos. Dos: la estrategia de mitigación de tres capas (bloquear las IP de resolvedores 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 gestionados como no gestionados. Tres: este es un problema de cumplimiento normativo, no solo técnico. El GDPR, la Ley de Seguridad en Línea (Online Safety Act) y PCI DSS tienen implicaciones para los establecimientos donde el DoH elude 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ébelo. Verifíquelo. No asuma que está funcionando. Cinco: los servicios de filtrado DNS gestionados (Cloudflare Gateway, Cisco Umbrella y similares) incluyen cada vez más la detección de elusión de DoH como una capacidad gestionada, lo que reduce el coste operativo de mantener listas de bloqueo estáticas. Con esto concluimos la sesión informativa técnica de Purple de hoy. Si desea auditar su arquitectura de filtrado DNS actual o implementar la mitigación de DoH en todo su patrimonio de establecimientos, la plataforma Purple proporciona la inteligencia de red y la capa de gestión de WiFi de invitados para respaldar ese despliegue. Gracias por escucharnos y nos vemos en la próxima sesión.