DNS Over HTTPS (DoH): Implicações para a Filtragem de WiFi Público

Bem-vindo ao Purple Technical Briefing. Sou o seu anfitrião na sessão de hoje e vamos passar os próximos dez minutos discutindo um assunto que está, silenciosamente, enfraquecendo as políticas de filtragem de conteúdo em milhares de implantações de WiFi público neste exato momento — o DNS over HTTPS, ou DoH. Se você gerencia o WiFi de visitantes em um hotel, rede de varejo, estádio ou instalação do setor público e não abordou especificamente o DoH na arquitetura da sua rede, há uma chance razoável de que sua política de filtragem tenha uma lacuna significativa. Vamos analisar detalhadamente o que é essa lacuna, por que ela importa e o que você pode fazer a respeito. Seção um — contexto e definição do problema. Vamos começar com uma rápida recapitulação de como funciona a filtragem de DNS tradicional, porque entender o mecanismo de desvio exige compreender o que está sendo desviado. Quando o dispositivo de um visitante se conecta ao seu WiFi e tenta acessar um site, a primeira coisa que ele faz é enviar uma consulta DNS — basicamente perguntando qual é o endereço IP daquele domínio. Essa consulta trafega via UDP ou TCP na porta 53. A infraestrutura da sua rede intercepta essa consulta, a direciona para o resolvedor de DNS de sua escolha e esse resolvedor verifica o domínio em relação à sua política de filtragem. Se o domínio estiver em uma lista de bloqueio — malware, conteúdo adulto, apostas ou qualquer outra regra definida na sua política de uso aceitável —, o resolvedor se recusa a retornar o endereço IP e a conexão nunca acontece. Essa é a base de toda implantação de filtragem de conteúdo baseada em DNS. É econômica, não afeta a taxa de transferência e tem sido a abordagem padrão para operadores de locais públicos há quase uma década. O DNS over HTTPS quebra esse modelo. Veja como. O DoH encapsula as consultas DNS dentro do tráfego HTTPS padrão na porta 443. Do ponto de vista da sua rede, ele parece idêntico a qualquer outro tráfego web criptografado. Não há como distinguir uma consulta DoH de um usuário carregando uma página da web, transmitindo um vídeo ou acessando um aplicativo de banco. A consulta vai diretamente para um resolvedor DoH externo — o 8.8.8.8 do Google, o 1.1.1.1 da Cloudflare ou vários outros — por meio de um canal criptografado que seu filtro de DNS não consegue inspecionar. O resultado? Sua política de filtragem de DNS cuidadosamente configurada é completamente burlada. O dispositivo resolve o domínio diretamente, sem que o seu resolvedor sequer veja a consulta. Agora, isso não é um ataque deliberado dos seus visitantes. Na maioria dos casos, é algo totalmente passivo. O Firefox tem o DoH ativado por padrão desde 2020. O Chrome atualiza automaticamente as consultas DNS para DoH se o resolvedor configurado for compatível. O Android 9 e superior suporta Private DNS com DNS over TLS por padrão. O iOS oferece suporte a perfis de configuração DoH desde o iOS 14. Esses são dispositivos de consumo comuns fazendo o que seus fabricantes planejaram. Seus visitantes não estão tentando burlar sua filtragem. Os dispositivos deles estão apenas fazendo isso de forma automática. Seção dois — o aprofundamento técnico. Vamos entrar na mecânica. Existem dois padrões principais de implementação de DoH que você encontrará na prática. O primeiro é o DoH em nível de aplicativo, onde o aplicativo — normalmente um navegador — mantém sua própria configuração de DoH independentemente das configurações de DNS do sistema operacional. O Firefox é o exemplo canônico. Quando o Firefox está instalado e o DoH está ativado, ele ignora completamente o resolvedor de DNS do sistema e envia todas as suas consultas de DNS para o provedor de DoH configurado, que por padrão é a Cloudflare. O seu servidor DNS atribuído por DHCP torna-se irrelevante. Suas regras de interceptação da porta 53 tornam-se irrelevantes. O Firefox realiza uma conversa de DNS completamente separada pela porta 443 que você não consegue ver. O segundo padrão é o DoH em nível de SO, onde o próprio sistema operacional lida com o upgrade. O Chrome e o Windows 10 e 11 adotam essa abordagem. Eles verificam se o resolvedor de DNS configurado no sistema — aquele atribuído pelo seu servidor DHCP — possui um endpoint DoH correspondente. Se possuir, eles fazem o upgrade automaticamente para DoH. Isso é chamado de DoH oportunista. Se você estiver atribuindo 8.8.8.8 como seu servidor DNS de visitantes, o Chrome usará automaticamente o endpoint DoH do Google. Se estiver atribuindo 1.1.1.1, ele usará o endpoint DoH da Cloudflare. A distinção é importante para a sua estratégia de mitigação, a qual abordaremos em breve. Há um terceiro vetor que vale a pena mencionar: DNS over TLS, ou DoT. Este opera na porta 853 e criptografa as consultas de DNS usando TLS, em vez de envolvê-las em HTTPS. É mais fácil de bloquear do que o DoH porque usa uma porta dedicada, mas é cada vez mais comum em dispositivos Android com o Private DNS ativado. Sua estratégia de mitigação precisa abordar ambos. Agora vamos falar sobre por que isso é um risco operacional e de conformidade, e não apenas uma curiosidade técnica. Sob a GDPR, se a sua política de uso aceitável afirma que você filtra certas categorias de conteúdo, e seus controles técnicos não aplicam de fato essa política, você tem uma lacuna entre os seus compromissos declarados de proteção de dados e governança de conteúdo e a sua implementação técnica real. Isso é um problema de defensabilidade caso você enfrente uma investigação regulatória ou um incidente. Sob a Lei de Segurança Online do Reino Unido (Online Safety Act), os operadores de locais que oferecem acesso público à internet têm obrigações relacionadas à proteção dos usuários — especialmente menores de idade — contra conteúdos nocivos. Se o DoH estiver ignorando silenciosamente o seu filtro de conteúdo, você pode não estar cumprindo essas obrigações. Para locais que entram no escopo do PCI DSS — particularmente aqueles onde os dados de cartões de pagamento trafegam em redes adjacentes ao WiFi de visitantes —, a versão 4.0 do PCI DSS exige que você monitore e controle o tráfego de DNS como parte dos seus controles de segurança de rede. O tráfego DoH não monitorado representa uma lacuna nesse framework de controle. E, do ponto de vista de segurança pura, o DoH tem sido ativamente explorado por malwares. Agentes de ameaças têm usado o DoH como um canal de comando e controle porque ele se mistura ao tráfego HTTPS normal. O backdoor GodLua usou DoH para comunicações de comando e controle. O malware PsiXBot usou o serviço DoH do Google. Se o seu monitoramento de segurança depende da visibilidade do DNS para detectar atividades maliciosas, os pontos cegos do DoH são uma ameaça real. Seção três — recomendações de implementação. Certo, vamos à prática. Existem três estratégias principais de mitigação e, na maioria das implantações em locais físicos, você desejará implementar as três em conjunto. Estratégia um: bloquear endpoints de resolvedores DoH conhecidos no firewall. Esta é sua primeira linha de defesa e a opção de implantação mais imediata. Mantenha uma lista de bloqueio de endereços IP e domínios de resolvedores DoH conhecidos — Google, Cloudflare, Quad9, NextDNS, AdGuard e outros — e negue o tráfego HTTPS de saída para esses endpoints a partir da sua VLAN de visitantes. O IETF e vários fornecedores de segurança publicam e mantêm essas listas. O projeto curl no GitHub mantém uma lista abrangente de resolvedores DoH conhecidos que serve como um bom ponto de partida. Essa abordagem lida com a maior parte do tráfego DoH porque, como mostram as pesquisas do Software Engineering Institute da Carnegie Mellon, a maior parte do tráfego DoH vai para um pequeno número de resolvedores conhecidos. Usuários que entendem de DNS o suficiente para configurar um resolvedor DoH personalizado são uma minoria muito pequena. A limitação dessa abordagem é que se trata de uma lista de bloqueio, e listas de bloqueio exigem manutenção. Novos resolvedores DoH surgem regularmente. Mas, combinada com as outras estratégias, ela oferece uma cobertura sólida. Estratégia dois: inspeção TLS em seu firewall de próxima geração. Firewalls de próxima geração de fornecedores como Palo Alto Networks, Fortinet, Check Point e Cisco Firepower oferecem suporte à inspeção TLS — também chamada de inspeção SSL ou inspeção profunda de pacotes (DPI). Quando ativado, o firewall atua como um intermediário (man-in-the-middle) para o tráfego HTTPS, descriptografando-o, inspecionando o conteúdo e criptografando-o novamente antes do envio. Isso permite que o firewall identifique o tráfego DoH mesmo quando ele é direcionado a um resolvedor desconhecido. O App-ID da Palo Alto pode identificar especificamente o tráfego DoH e aplicar políticas a ele. O FortiGate da Fortinet possui capacidade semelhante. A etapa de configuração fundamental é garantir que o tráfego da sua VLAN de visitantes seja roteado por meio da política de inspeção. A consideração operacional aqui é a confiança no certificado. Para que a inspeção TLS funcione em dispositivos de visitantes, esses dispositivos precisam confiar no seu certificado de inspeção. Em dispositivos corporativos gerenciados, isso é simples — você distribui o certificado via MDM. Em dispositivos de visitantes não gerenciados, é mais complexo. A abordagem prática para WiFi de visitantes é usar o fluxo de aceitação do Captive Portal para informar aos usuários que o tráfego pode ser inspecionado para fins de filtragem de conteúdo, e contar com a combinação de bloqueio de resolvedores DoH e interceptação de DNS como seus controles primários, com a inspeção TLS como uma camada secundária para ambientes de maior risco. Estratégia três: forçar a interceptação e o redirecionamento de DNS. Configure seu firewall ou controladora sem fio para interceptar todo o tráfego de saída de DNS nas portas UDP e TCP 53 e redirecioná-lo para o seu resolvedor de DNS em conformidade. Isso não impede o DoH, mas garante que qualquer tráfego de DNS que retorne para a porta 53 — porque o DoH falhou ou não estava disponível — seja capturado e filtrado. Combine isso com o bloqueio da porta 853 de saída da VLAN de convidados para evitar que o DNS over TLS ignore seus controles. Para endpoints gerenciados — dispositivos corporativos, dispositivos de funcionários — você tem uma opção adicional: Política de Grupo ou configuração de MDM para desativar o DoH no nível do navegador e do sistema operacional. No Firefox, a preferência network.trr.mode definida como 5 desativa o DoH completamente. No Chrome, o sinalizador disable-features igual a DnsOverHttps alcança o mesmo resultado. O Windows 10 e 11 possuem configurações de Política de Grupo para controlar o comportamento do DoH. Este é o controle mais confiável para dispositivos gerenciados, mas não se aplica a dispositivos de convidados não gerenciados. Seção quatro — armadilhas de implementação. Algumas coisas que comumente dão errado em campo. O modo de falha mais frequente é a interceptação incompleta da porta 53. As equipes configuram seu serviço de filtragem de DNS corretamente, mas esquecem de adicionar a regra de firewall que redireciona todo o tráfego de saída da porta 53. Dispositivos com configurações de DNS codificadas rigidamente — 8.8.8.8, 1.1.1.1 — ignoram o filtro completamente. Sempre verifique se essa regra está ativa e teste-a configurando um dispositivo de teste com um servidor DNS codificado rigidamente e confirmando que os domínios filtrados ainda estão bloqueados. A segunda falha comum é não considerar o IPv6. Consultas de DNS sobre IPv6 são cada vez mais comuns, e muitas regras de firewall são escritas apenas para IPv4. Certifique-se de que sua interceptação de porta 53 e as listas de bloqueio de resolvedores DoH cubram endereços IPv4 e IPv6. Terceiro: listas de bloqueio de resolvedores DoH desatualizadas. Se você estiver mantendo uma lista de bloqueio estática de IPs de resolvedores DoH, ela ficará obsoleta. Automatize o processo de atualização ou use um serviço de filtragem de DNS que mantenha essa lista para você. Cloudflare Gateway, Cisco Umbrella e serviços de DNS corporativos semelhantes incluem detecção de desvio de DoH como um recurso gerenciado. Quarto: dependência excessiva de uma única camada de mitigação. A mitigação de DoH é um problema de defesa em profundidade. Nenhum controle único é suficiente. Bloquear resolvedores conhecidos resolve a maioria dos casos. A inspeção de TLS lida com casos extremos. A interceptação de DNS fornece uma rede de segurança. Aplique as três camadas. Seção cinco — perguntas rápidas. A mitigação de DoH quebra ferramentas legítimas de privacidade? Potencialmente, sim. Se um usuário estiver executando uma configuração de navegador legítima focada em privacidade, seu bloqueio de DoH o forçará a usar seu resolvedor de DNS. Sua política de uso aceitável deve deixar claro que o resolvedor de DNS do local é usado para fins de filtragem de conteúdo. Essa é uma prática padrão e legalmente defensável. O DoH pode ser usado para exfiltrar dados da minha rede? Sim, e este é um vetor de ameaça real. O tunelamento de DNS sobre DoH já foi demonstrado na prática. O recurso de detecção de DoH do seu firewall de próxima geração deve incluir detecção de anomalias para volumes de consulta excepcionalmente altos ou padrões de consulta consistentes com tunelamento. E quanto aos aplicativos móveis que usam DoH? Este é o caso mais difícil. Aplicativos móveis que implementam sua própria pilha DoH — em vez de usar as configurações de DNS do sistema operacional — são difíceis de controlar sem a inspeção TLS. Sua melhor mitigação é a combinação do bloqueio de resolvedores conhecidos e da inspeção TLS. O WPA3 é relevante aqui? O WPA3 melhora a criptografia over-the-air e fornece forward secrecy, o que é excelente para a privacidade dos visitantes. Mas o WPA3 não aborda o DoH — isso é um problema de protocolo de aplicação da camada 7, não um problema de segurança sem fio da camada 2. São controles complementares que abordam diferentes vetores de ameaça. Seção seis — ROI e impacto nos negócios. Deixe-me encerrar com o caso de negócios para abordar isso adequadamente. O custo de não abordar o DoH é assimétrico. Um único incidente — um visitante acessando conteúdo ilegal em sua rede, um callback de malware passando despercebido porque seu monitoramento de DNS tinha um ponto cego, uma investigação regulatória sobre sua conformidade de filtragem de conteúdo — pode custar significativamente mais do que o investimento em uma mitigação adequada. Para um grupo hoteleiro que opera em 20 propriedades, a implantação da mitigação de DoH normalmente envolve um esforço de configuração único de duas a quatro horas por propriedade para as regras de firewall e configuração de interceptação de DNS, além de uma sobrecarga operacional contínua de manutenção de listas de bloqueio de resolvedores — o que é amplamente automatizado se você estiver usando um serviço gerenciado de filtragem de DNS. O investimento total é modesto em relação à redução de riscos. Para redes de varejo que operam sob o PCI DSS, o benefício de conformidade é diretamente quantificável. Demonstrar que seus controles de segurança de rede incluem a mitigação de DoH reduz o risco de uma constatação de auditoria do PCI DSS e os custos de remediação associados. Para locais do setor público e aqueles que operam sob a Lei de Segurança Online (Online Safety Act), a mitigação de DoH documentada faz parte da sua base de evidências de que você tomou medidas técnicas razoáveis para aplicar sua política de filtragem de conteúdo. O ponto principal: o DoH não é um problema futuro. É um problema presente. Firefox, Chrome, Android e iOS já estão enviando configurações compatíveis com DoH para os dispositivos dos seus visitantes agora mesmo. Se você não auditou sua arquitetura de filtragem de DNS para vetores de desvio de DoH nos últimos 12 meses, essa auditoria deve estar no seu roteiro de curto prazo. Para resumir os principais pontos da apresentação de hoje. Um: o DoH criptografa consultas DNS dentro de HTTPS na porta 443, tornando-as invisíveis para a filtragem de DNS tradicional na porta 53. Isso está acontecendo por padrão nos principais navegadores e sistemas operacionais. Dois: a estratégia de mitigação em três camadas — bloquear IPs de resolvedores DoH conhecidos, implementar inspeção TLS em seu firewall de próxima geração e aplicar a interceptação da porta 53 — oferece cobertura de defesa em profundidade para dispositivos de visitantes gerenciados e não gerenciados. Três: esta é uma questão de conformidade, não apenas técnica. O GDPR, a Lei de Segurança Online e o PCI DSS têm implicações para locais onde o DoH está ignorando silenciosamente as políticas de filtragem de conteúdo.Quatro: O erro de implementação mais comum é a interceptação incompleta da porta 53. Teste. Verifique. Não presuma que está funcionando. Cinco: Serviços gerenciados de filtragem de DNS — Cloudflare Gateway, Cisco Umbrella e similares — incluem cada vez mais a detecção de bypass de DoH como uma capacidade gerenciada, o que reduz a sobrecarga operacional de manutenção de listas de bloqueio estáticas. Isso é tudo para o Purple Technical Briefing de hoje. Se você deseja auditar sua arquitetura atual de filtragem de DNS ou implementar a mitigação de DoH em todo o seu patrimônio de locais, a plataforma Purple fornece a inteligência de rede e a camada de gerenciamento de guest WiFi para apoiar essa implantação. Obrigado por ouvir e nos vemos na próxima sessão.