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

Bem-vindo ao Purple Technical Briefing. Sou o vosso anfitrião para a sessão de hoje, e vamos passar os próximos dez minutos num tema que está silenciosamente a minar as políticas de filtragem de conteúdo em milhares de implementações de WiFi público neste momento — o DNS over HTTPS, ou DoH. Se gere um WiFi de convidados num hotel, num espaço de retalho, num estádio ou numa instalação do setor público, e não abordou especificamente o DoH na sua arquitetura de rede, há uma probabilidade razoável de a sua política de filtragem ter uma lacuna significativa. Vamos analisar detalhadamente o que é essa lacuna, por que motivo é importante e o que pode fazer a esse respeito. Secção um — contexto e a definição do problema. Comecemos com um rápido resumo de como funciona a filtragem de DNS tradicional, porque compreender o mecanismo de desvio exige compreender o que está a ser contornado. Quando um dispositivo de convidado se liga ao seu WiFi e tenta visitar um website, a primeira coisa que faz é enviar uma consulta de DNS — essencialmente perguntando qual é o endereço IP para este domínio. Essa consulta viaja por UDP ou TCP na porta 53. A sua infraestrutura de rede interceta essa consulta, encaminha-a para o resolver DNS escolhido, e esse resolver verifica o domínio em relação à sua política de filtragem. Se o domínio estiver numa lista de bloqueio — malware, conteúdo adulto, jogo, o que quer que a sua política de utilização aceitável especifique — o resolver recusa-se a devolver o endereço IP, e a ligação nunca acontece. Esta é la base de todas as implementações de filtragem de conteúdo baseadas em DNS. É económica, não afeta o rendimento (throughput) e tem sido a abordagem padrão para os operadores de locais durante a maior parte de uma década. O DNS over HTTPS quebra este modelo. Eis como. O DoH encapsula as consultas de DNS dentro do tráfego HTTPS padrão na porta 443. Do ponto de vista da sua rede, parece idêntico a qualquer outro tráfego web encriptado. Não há forma de distinguir uma consulta DoH de um utilizador a carregar uma página web, a transmitir um vídeo ou a aceder a uma aplicação bancária. A consulta vai diretamente para um resolver DoH externo — o 8.8.8.8 da Google, o 1.1.1.1 da Cloudflare ou qualquer outro — através de um canal encriptado que o seu filtro DNS não consegue inspecionar. O resultado? A sua política de filtragem de DNS cuidadosamente configurada é completamente contornada. O dispositivo resolve o domínio diretamente, sem que o seu resolver veja sequer a consulta. Ora, isto não é um ataque deliberado dos seus convidados. Na maioria dos casos, é inteiramente passivo. O Firefox tem o DoH ativado por predefinição desde 2020. O Chrome atualiza automaticamente as consultas de DNS para DoH se o resolver configurado o suportar. O Android 9 e superior suporta Private DNS com DNS over TLS por predefinição. O iOS suporta perfis de configuração DoH desde o iOS 14. Trata-se de dispositivos de consumo comuns a fazer o que os seus fabricantes pretendiam. Os seus convidados não estão a tentar contornar a sua filtragem. Os seus dispositivos estão apenas a fazê-lo automaticamente. Secção dois — a análise técnica aprofundada. Vamos entrar na mecânica. Existem dois padrões principais de implementação de DoH que encontrará no terreno. O primeiro é o DoH ao nível da aplicação, onde a aplicação — tipicamente um navegador — mantém a sua própria configuração de DoH independentemente das definições de DNS do sistema operativo. O Firefox é o exemplo canónico. Quando o Firefox está instalado e o DoH está ativado, ignora completamente o resolver DNS do sistema e envia todas as suas consultas de DNS para o seu fornecedor de DoH configurado, que por predefinição é a Cloudflare. O seu servidor DNS atribuído por DHCP é irrelevante. As suas regras de interceção da porta 53 são irrelevantes. O Firefox está a ter uma conversa de DNS completamente separada através da porta 443 que não consegue ver. O segundo padrão é o DoH ao nível do SO, onde o próprio sistema operativo lida com a atualização. O Chrome e o Windows 10 e 11 adotam esta abordagem. Eles verificam se o resolver DNS configurado no sistema — aquele atribuído pelo seu servidor DHCP — tem um endpoint DoH correspondente. Se tiver, atualizam automaticamente para DoH. Isto chama-se DoH oportunista. Se estiver a atribuir o 8.8.8.8 como o seu servidor DNS de convidados, o Chrome utilizará automaticamente o endpoint DoH da Google. Se estiver a atribuir o 1.1.1.1, utilizará o endpoint DoH da Cloudflare. A distinção é importante para a sua estratégia de mitigação, à qual chegaremos em breve. Há um terceiro vetor que vale a pena mencionar: o DNS over TLS, ou DoT. Este opera na porta 853 e encripta as consultas de DNS utilizando TLS em vez de as encapsular em HTTPS. É mais fácil de bloquear do que o DoH porque utiliza uma porta dedicada, mas é cada vez mais comum em dispositivos Android com o Private DNS ativado. A sua estratégia de mitigação precisa de abordar ambos. Agora vamos falar sobre o porquê de isto ser um risco operacional e de conformidade, não apenas uma curiosidade técnica. Ao abrigo do GDPR, se a sua política de utilização aceitável indicar que filtra certas categorias de conteúdo, e os seus controlos técnicos não aplicarem efetivamente essa política, tem uma lacuna entre os seus compromissos declarados de proteção de dados e governação de conteúdo e a sua implementação técnica real. Isso é um problema de sustentabilidade jurídica se alguma vez enfrentar um inquérito regulamentar ou um incidente. Ao abrigo do Online Safety Act do Reino Unido, os operadores de locais que fornecem acesso público à Internet têm obrigações relativas à proteção dos utilizadores — particularmente menores — contra conteúdos nocivos. Se o DoH estiver a contornar silenciosamente a sua filtragem de conteúdo, poderá não estar a cumprir essas obrigações. Para os locais que se enquadram no âmbito do PCI DSS — particularmente aqueles onde os dados de cartões de pagamento fluem em redes adjacentes ao WiFi de convidados —, a versão 4.0 do PCI DSS exige que monitorize e controle o tráfego de DNS como parte dos seus controlos de segurança de rede. O tráfego DoH não monitorizado é uma lacuna nesse quadro de controlo. E de um ponto de vista de segurança puro, o DoH tem sido ativamente explorado por malware. Os agentes de ameaças têm utilizado o DoH como um canal de comando e controlo (C2) porque este se mistura com o tráfego HTTPS normal. O backdoor GodLua utilizou o DoH para comunicações de comando e controlo. O malware PsiXBot utilizou o serviço DoH da Google. Se a sua monitorização de segurança depende da visibilidade do DNS para detetar atividades maliciosas, os pontos cegos do DoH são uma ameaça real. Secção três — recomendações de implementação. Muito bem, vamos à prática. Existem três estratégias de mitigação principais e, na maioria das implementações em locais, vai querer implementar as três em combinação. Estratégia um: bloquear endpoints de resolvers DoH conhecidos na firewall. Esta é a sua primeira linha de defesa e a opção de implementação mais imediata. Mantenha uma lista de bloqueio de endereços IP e domínios de resolvers DoH conhecidos — Google, Cloudflare, Quad9, NextDNS, AdGuard e outros — e recuse o tráfego HTTPS de saída para esses endpoints a partir da sua VLAN de convidados. O IETF e vários fornecedores de segurança publicam e mantêm estas listas. O projeto curl no GitHub mantém uma lista abrangente de resolvers DoH conhecidos que é um bom ponto de partida. Esta abordagem lida com a maioria do tráfego DoH porque, como demonstrado pela investigação do Software Engineering Institute da Carnegie Mellon, a maior parte do tráfego DoH vai para um pequeno número de resolvers bem conhecidos. Os utilizadores que sabem o suficiente sobre DNS para configurar um resolver DoH personalizado são uma minoria muito reduzida. A limitação desta abordagem é que se trata de uma lista de bloqueio, e as listas de bloqueio exigem manutenção. Surgem novos resolvers DoH regularmente. Mas, combinada com as outras estratégias, fornece uma cobertura sólida. Estratégia dois: inspeção TLS na sua firewall de próxima geração (NGFW). As firewalls de próxima geração de fornecedores como a Palo Alto Networks, Fortinet, Check Point e Cisco Firepower suportam inspeção TLS — também chamada de inspeção SSL ou inspeção profunda de pacotes. Quando ativada, a firewall atua como um intermediário (man-in-the-middle) para o tráfego HTTPS, desencriptando-o, inspecionando a carga útil (payload) e voltando a encriptá-lo antes do encaminhamento. Isto permite que a firewall identifique o tráfego DoH mesmo quando este se destina a um resolver desconhecido. O App-ID da Palo Alto pode identificar especificamente o tráfego DoH e aplicar-lhe políticas. O FortiGate da Fortinet tem uma capacidade semelhante. O passo de configuração fundamental é garantir que o tráfego da sua VLAN de convidados é encaminhado através 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 convidados, esses dispositivos precisam de confiar no seu certificado de inspeção. Em dispositivos corporativos geridos, isto é simples — distribui o certificado via MDM. Em dispositivos de convidados não geridos, é mais complexo. A abordagem prática para o WiFi de convidados é utilizar o fluxo de aceitação do Captive Portal para informar os utilizadores de que o tráfego pode ser inspecionado para fins de filtragem de conteúdo, e confiar na combinação de bloqueio de resolvers DoH e interceção de DNS como os seus controlos primários, com a inspeção TLS como uma camada secundária para ambientes de maior risco. Estratégia três: forçar a interceção e o redirecionamento de DNS. Configure a sua firewall ou controlador sem fios para intercetar todo o tráfego de DNS de saída na porta UDP e TCP 53 e redirecioná-lo para o seu resolver DNS em conformidade. Isto não impede o DoH, mas garante que qualquer tráfego de DNS que reverta para a porta 53 — porque o DoH falhou ou não estava disponível — seja capturado e filtrado. Combine isto com o bloqueio da porta de saída 853 a partir da VLAN de convidados para evitar que o DNS over TLS contorne os seus controlos. Para endpoints geridos — dispositivos corporativos, dispositivos de funcionários — tem uma opção adicional: configuração de Política de Grupo (GPO) ou MDM para desativar o DoH ao nível do navegador e do SO. No Firefox, a preferência network.trr.mode definida para 5 desativa o DoH por completo. No Chrome, o sinalizador disable-features igual a DnsOverHttps alcança o mesmo. O Windows 10 e 11 têm definições de Política de Grupo para controlar o comportamento do DoH. Este é o controlo mais fiável para dispositivos geridos, mas não é aplicável a dispositivos de convidados não geridos. Secção quatro — armadilhas de implementação. Algumas coisas que correm mal habitualmente no terreno. O modo de falha mais frequente é a interceção incompleta da porta 53. As equipas configuram o seu serviço de filtragem de DNS corretamente, mas esquecem-se de adicionar a regra de firewall que redireciona todo o tráfego de saída da porta 53. Dispositivos com definições de DNS codificadas rigidamente — 8.8.8.8, 1.1.1.1 — contornam o filtro por completo. Verifique sempre se esta regra está em vigor e teste-a configurando um dispositivo de teste com um servidor DNS codificado rigidamente e confirmando que os domínios filtrados continuam bloqueados. A segunda falha comum é não contabilizar o IPv6. As consultas de DNS sobre IPv6 são cada vez mais comuns, e muitas regras de firewall são escritas apenas para IPv4. Garanta que a sua interceção da porta 53 e as listas de bloqueio de resolvers DoH cobrem endereços IPv4 e IPv6. Terceiro: listas de bloqueio de resolvers DoH desatualizadas. Se estiver a manter uma lista de bloqueio estática de IPs de resolvers DoH, esta ficará desatualizada. Automatize o processo de atualização ou utilize um serviço de filtragem de DNS que mantenha esta lista por si. O Cloudflare Gateway, o Cisco Umbrella e serviços de DNS empresariais semelhantes incluem a deteção de desvio de DoH como uma capacidade gerida. Quarto: dependência excessiva de uma única camada de mitigação. A mitigação de DoH é um problema de defesa em profundidade. Nenhum controlo isolado é suficiente. Bloquear resolvers conhecidos resolve a maioria dos casos. A inspeção TLS resolve casos limite. A interceção de DNS fornece uma rede de segurança. Aplique as três camadas. Secção cinco — perguntas rápidas. A mitigação de DoH quebra ferramentas de privacidade legítimas? Potencialmente, sim. Se um utilizador estiver a executar uma configuração de navegador legítima focada na privacidade, o seu bloqueio de DoH irá forçá-lo a utilizar o seu resolver DNS. A sua política de utilização aceitável deve deixar claro que o resolver DNS do local é utilizado para fins de filtragem de conteúdo. Esta é uma prática padrão e juridicamente sustentável. O DoH pode ser utilizado para exfiltrar dados da minha rede? Sim, e este é um vetor de ameaça real. O túnel de DNS (DNS tunnelling) sobre DoH já foi demonstrado no terreno. A capacidade de deteção de DoH da sua firewall de próxima geração deve incluir a deteção de anomalias para volumes de consulta invulgarmente elevados ou padrões de consulta consistentes com a criação de túneis. E quanto às aplicações móveis que utilizam DoH? Este é o caso mais difícil. As aplicações móveis que implementam a sua própria pilha DoH — em vez de utilizarem as definições de DNS do SO — são difíceis de controlar sem inspeção TLS. A sua melhor mitigação é a combinação de bloqueio de resolvers conhecidos e inspeção TLS. O WPA3 é relevante aqui? O WPA3 melhora a encriptação no ar e fornece confidencialidade de encaminhamento (forward secrecy), o que é excelente para a privacidade dos convidados. 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 fios da camada 2. São controlos complementares que abordam diferentes vetores de ameaça. Secção seis — ROI e impacto no negócio. Permitam-me encerrar com o caso de negócio para abordar isto adequadamente. O custo de não abordar o DoH é assimétrico. Um único incidente — um convidado a aceder a conteúdos ilegais na sua rede, uma comunicação de retorno (callback) de malware que passa despercebida porque a sua monitorização de DNS tinha um ponto cego, um inquérito regulamentar sobre a sua conformidade de filtragem de conteúdo — pode custar significativamente mais do que o investimento numa mitigação adequada. Para um grupo hoteleiro que opera em 20 propriedades, a implementação da mitigação de DoH envolve tipicamente um esforço de configuração único de duas a quatro horas por propriedade para as regras de firewall e configuração de interceção de DNS, além de um custo operacional contínuo de manutenção de listas de bloqueio de resolvers — o que é amplamente automatizado se estiver a utilizar um serviço de filtragem de DNS gerido. O investimento total é modesto em relação à redução de risco. Para cadeias de retalho que operam sob o PCI DSS, o benefício de conformidade é diretamente quantificável. Demonstrar que os seus controlos de segurança de rede incluem a mitigação de DoH reduz o risco de uma não conformidade em auditoria PCI DSS e os custos de remediação associados. Para locais do setor público e aqueles que operam sob o Online Safety Act, a mitigação documentada de DoH faz parte da sua base de evidências de que tomou medidas técnicas razoáveis para aplicar a sua política de filtragem de conteúdo. O ponto fulcral: o DoH não é um problema do futuro. É um problema do presente. O Firefox, o Chrome, o Android e o iOS estão todos a disponibilizar configurações compatíveis com DoH nos dispositivos dos seus convidados neste preciso momento. Se não auditou a sua arquitetura de filtragem de DNS para vetores de desvio de DoH nos últimos 12 meses, essa auditoria deve estar no seu roteiro a curto prazo. Para resumir as principais conclusões do briefing de hoje. Um: o DoH encripta as consultas de DNS dentro de HTTPS na porta 443, tornando-as invisíveis para a filtragem de DNS tradicional na porta 53. Isto está a acontecer por predefinição nos principais navegadores e sistemas operativos. Dois: A estratégia de mitigação em três camadas — bloquear IPs de resolvers DoH conhecidos, implementar inspeção TLS na sua firewall de próxima geração e impor a interceção da porta 53 — fornece cobertura de defesa em profundidade para dispositivos de convidados geridos e não geridos. Três: Esta é uma questão de conformidade, não apenas técnica. O GDPR, o Online Safety Act e o PCI DSS têm todos implicações para locais onde o DoH está silenciosamente a contornar as políticas de filtragem de conteúdo. Quatro: A falha de implementação mais comum é a interceção incompleta da porta 53. Teste-a. Verifique-a. Não assuma que está a funcionar. Cinco: Os serviços de filtragem de DNS geridos — Cloudflare Gateway, Cisco Umbrella e semelhantes — incluem cada vez mais a deteção de desvio de DoH como uma capacidade gerida, o que reduz o custo operacional de manutenção de listas de bloqueio estáticas. E assim terminamos o Purple Technical Briefing de hoje. Se pretende auditar a 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 gestão de WiFi de convidados para apoiar essa implementação. Obrigado por nos ouvir, e encontramo-nos na próxima sessão.