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

Bienvenido al Resumen Técnico de Purple. Soy el anfitrión de la sesión de hoy y vamos a dedicar los próximos diez minutos a un tema que está debilitando silenciosamente las políticas de filtrado de contenido en miles de implementaciones de WiFi público en este momento: DNS sobre HTTPS, o DoH. Si usted opera WiFi para invitados en un hotel, un comercio minorista, un estadio o una instalación del sector público, y no ha abordado específicamente DoH en su arquitectura de red, existe una probabilidad razonable de que su política de filtrado tenga una brecha significativa. 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 repaso de cómo funciona el filtrado DNS tradicional, ya que comprender el mecanismo de evasión requiere entender 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, que básicamente pregunta cuál es la dirección IP de ese dominio. Esa consulta viaja a través de UDP o TCP por el puerto 53. La infraestructura de su red intercepta esa consulta, la redirige al resolver DNS de su elección, y ese resolver 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 sea que especifique su política de uso aceptable), el resolver se niega a devolver la dirección IP y la conexión nunca se realiza. Este es el fundamento de cada implementación de filtrado de contenido basado 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 sobre HTTPS rompe este modelo. Así es como funciona. 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 video 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 muchos otros) 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 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 completamente pasivo. Firefox tiene DoH habilitado de forma predeterminada 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 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: profundización técnica. 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 - típicamente un navegador - mantiene su propia configuración de DoH de forma independiente de la configuración de DNS del sistema operativo. Firefox es el ejemplo canónico. Cuando se instala Firefox y se habilita DoH, este 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 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, Windows 10 y 11 adoptan este enfoque. Verifican si el resolvedor 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 usted asigna 8.8.8.8 como su servidor DNS para 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, a la que llegaremos 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 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, no solo una curiosidad técnica. Bajo el GDPR, si su política de uso aceptable establece que usted 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 defensabilidad 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 brindan acceso público a internet tienen obligaciones relacionadas con la protección de los usuarios - particularmente menores de edad - frente a contenidos nocivos. Si 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 - particularmente aquellos donde los datos de tarjetas de pago fluyen a través de redes adyacentes a la red WiFi para invitados - la versión 4.0 de PCI-DSS requiere que usted monitoree y controle el tráfico DNS como parte de sus controles de seguridad de red. El tráfico DoH no monitoreado es una brecha en ese marco de control. Y desde un punto de vista de seguridad pura, 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 de establecimientos, lo ideal es implementar las tres de forma combinada. Estrategia uno: bloquear los endpoints de los resolvedores 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 resolvedores DoH conocidos - Google, Cloudflare, Quad9, NextDNS, AdGuard y 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 resolvedores DoH conocidos que constituye un buen punto de partida. Este enfoque gestiona la mayoría del tráfico DoH ya que, 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 para configurar un resolvedor DoH personalizado son una minoría muy reducida. 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 resolvedores DoH. Pero 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 se habilita, 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. El App-ID de Palo Alto puede identificar específicamente el tráfico DoH y aplicarle políticas. El 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 del certificado. Para que la inspección TLS funcione en los dispositivos de los invitados, dichos dispositivos deben confiar en su certificado de inspección. En los dispositivos corporativos administrados, esto es sencillo - se distribuye el certificado a través de MDM. En los 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 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 los puertos UDP y TCP 53 y redirigirlo a su resolvedor 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 sobre TLS evite sus controles. Para los dispositivos gestionados - dispositivos corporativos, dispositivos del personal - tiene una opción adicional: 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 gestionados, pero no se aplica a los dispositivos de invitados no gestionados. Sección cuatro - errores de implementación. Algunas cosas que suelen salir mal en el terreno. El modo de fallo más frecuente es la interceptación incompleta del puerto 53. Los equipos configuran su servicio de filtrado de DNS correctamente pero olvidan agregar la regla de firewall que redirige todo el tráfico saliente del puerto 53. Los dispositivos con configuraciones de DNS codificadas de forma fija - 8.8.8.8, 1.1.1.1 - evitan 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 fija y confirmando que los dominios filtrados sigan bloqueados. El segundo fallo común es no tener en cuenta el IPv6. Las consultas DNS a través de IPv6 son cada vez más comunes, y muchas reglas de firewall están escritas únicamente para IPv4. Asegúrese de que su interceptación del puerto 53 y las listas de bloqueo 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, se desactualizará. Automatice el proceso de actualización o utilice un servicio de filtrado de 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 función gestionada. 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 maneja la mayoría de los casos. La inspección TLS maneja los casos límite. La interceptación de DNS proporciona una red de seguridad. Aplique las tres capas. Sección cinco - preguntas rápidas. ¿La mitigación de DoH interrumpe las herramientas legítimas de privacidad? Potencialmente, sí. Si un usuario tiene una configuración de navegador legítima centrada en la privacidad, su bloqueo de DoH lo obligará a usar su resolutor DNS. Su política de uso aceptable debe dejar claro que el resolutor DNS del establecimiento se utiliza para fines de filtrado de contenido. Esta es una práctica estándar y legalmente defendible. ¿Se puede usar DoH para exfiltrar datos de mi red? Sí, y este es un vector de amenaza real. Se ha demostrado en entornos reales el túnel DNS sobre DoH. La función 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 la creación de túneles. ¿Qué pasa con las aplicaciones móviles que usan DoH? Este es el caso más difícil. Las aplicaciones móviles que implementan su propio stack de DoH, en lugar de usar la configuración de DNS del sistema operativo, son difíciles de controlar sin una inspección de TLS. Su mejor mitigación es la combinación del bloqueo de resolutores conocidos y la inspección de 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. Pero WPA3 no soluciona el problema de 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 empresarial. Permítame concluir con el caso de negocio para abordar esto adecuadamente. El costo de no abordar 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, 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 normalmente implica un esfuerzo de configuración de una sola vez de dos a cuatro horas por propiedad para las reglas de firewall y la configuración de interceptación de DNS, más un costo operativo continuo de mantener las listas de bloqueo de resolutores, lo cual está ampliamente automatizado si 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 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 espacios 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 es parte de su base de evidencia de que han tomado medidas técnicas razonables para hacer cumplir su política de filtrado de contenido. El resultado final: 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 de DNS para detectar vectores de evasió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. Uno: DoH cifra las consultas de DNS dentro de HTTPS en el puerto 443, haciéndolas invisibles para el filtrado de DNS tradicional en el 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 IPs de resolutores DoH conocidos, implementar la inspección de TLS en su firewall de próxima generación y hacer cumplir 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. Tres: Este es un problema de cumplimiento, no solo técnico. El GDPR, la Ley de Seguridad en Línea y PCI-DSS tienen implicaciones para los establecimientos donde DoH está evadiendo silenciosamente las políticas de filtrado de contenido. 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 de 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 carga operativa de mantener listas de bloqueo estáticas. Eso es todo por el Informe Técnico de Purple de hoy. Si busca auditar su arquitectura de filtrado de DNS actual o implementar la mitigación de DoH en todo el patrimonio de sus establecimientos, la plataforma Purple proporciona la inteligencia de red y la capa de gestión de WiFi para huéspedes para respaldar ese despliegue. Gracias por escuchar, nos vemos en la próxima sesión.