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

Bem-vindo ao Briefing Técnico da Purple. Sou o vosso anfitrião para a sessão de hoje e vamos dedicar os próximos dez minutos a um tema que está a comprometer silenciosamente as políticas de filtragem de conteúdos em milhares de implementações de WiFi público neste momento — o DNS over HTTPS, ou DoH. Se gere o WiFi de convidados num hotel, num espaço de retalho, num estádio ou numa infraestrutura do setor público, e ainda não abordou especificamente o DoH na arquitetura da sua rede, há uma probabilidade razoável de a sua política de filtragem ter uma falha significativa. Vamos analisar detalhadamente que falha é essa, por que motivo é importante e o que pode fazer para a resolver. Secção um — contexto e definição do problema. Comecemos por uma breve recapitulação de como funciona a filtragem de DNS tradicional, porque para compreender o mecanismo de desvio é necessário perceber o que está a ser desviado. Quando o dispositivo de um convidado se liga ao seu WiFi e tenta aceder a um website, a primeira coisa que faz é enviar uma consulta DNS — perguntando, essencialmente, qual é o endereço IP para este domínio. Essa consulta viaja através de UDP ou TCP na porta 53. A infraestrutura da sua rede intercetasse essa consulta, encaminha-a para o resolvedor DNS que escolheu e esse resolvedor verifica o domínio em relação à sua política de filtragem. Se o domínio estiver numa lista de bloqueio — malware, conteúdo para adultos, jogos de azar ou o que quer que a sua política de utilização aceitável especifique — o resolvedor recusa-se a devolver o endereço IP e a ligação nunca chega a acontecer. Esta é a base de todas as implementações de filtragem de conteúdos baseadas em DNS. É económico, não afeta a largura de banda e tem sido a abordagem padrão para operadores de recintos durante a melhor parte de uma década. O DNS over HTTPS quebra este modelo. Eis como. O DoH envolve as consultas 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 resolvedor DoH externo — o 8.8.8.8 da Google, o 1.1.1.1 da Cloudflare ou muitos outros — 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 resolvedor chegue a ver a consulta. Ora, isto não é um ataque deliberado por parte dos seus convidados. Na maioria dos casos, é totalmente passivo. O Firefox tem o DoH ativado por defeito desde 2020. O Chrome atualiza automaticamente as consultas DNS para DoH se o resolvedor configurado o suportar. O Android 9 e superior suporta Private DNS com DNS over TLS por defeito. 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 de forma automática. 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 irá encontrar no terreno. O primeiro é o DoH ao nível da aplicação, onde a aplicação - tipicamente um browser - mantém a sua própria configuração DoH independentemente das definições de DNS do sistema operativo. O Firefox é o exemplo canónico. Quando o Firefox é instalado e o DoH está ativado, ignora completamente o resolver de DNS do sistema e envia todas as suas consultas de DNS para o seu fornecedor de DoH configurado, que por defeito é 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ção de DNS completamente separada através da porta 443 que não consegue ver. O segundo padrão é o DoH ao nível do OS, onde o próprio sistema operativo trata da atualização. O Chrome e o Windows 10 e 11 adotam esta abordagem. Eles verificam se o resolver de DNS configurado no sistema - aquele atribuído pelo seu servidor DHCP - tem um endpoint DoH correspondente. Se tiver, atualizam automaticamente para DoH. Isto é chamado de 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. Existe um terceiro vetor que vale a pena mencionar: DNS over TLS, ou DoT. Este funciona na porta 853 e encripta as consultas de DNS utilizando TLS em vez de as envolver 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 a razão pela qual isto é um risco operacional e de conformidade, e não apenas uma curiosidade técnica. Ao abrigo do GDPR, se a sua política de utilização aceitável estipula que filtra certas categorias de conteúdo, e os seus controlos técnicos não aplicam efetivamente essa política, existe uma lacuna entre os seus compromissos declarados de proteção de dados e governação de conteúdos e a sua implementação técnica real. Isso é um problema de capacidade de defesa se alguma vez enfrentar uma auditoria regulatória ou um incidente. Ao abrigo do Online Safety Act do Reino Unido, os operadores de espaços que fornecem acesso público à internet têm obrigações em torno da proteção dos utilizadores - particularmente menores - de conteúdos prejudiciais. Se o DoH estiver a contornar silenciosamente a sua filtragem de conteúdos, poderá não estar a cumprir essas obrigações. Para espaços que entram 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 modelo de controlo. E de um ponto de vista de segurança puro, o DoH tem sido ativamente explorado por malware. Os atacantes têm utilizado o DoH como um canal de comando e controlo porque este se mistura com o tráfego HTTPS normal. O backdoor GodLua utilizou 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 atividade maliciosa, os pontos cegos do DoH são uma ameaça real. Secção três - recomendações de implementação. Muito bem, vamos ser práticos. Existem três estratégias de mitigação principais e, na maioria das implementações em locais públicos, vai querer implementar as três em combinação. Estratégia um: bloquear os endpoints de resolução DoH conhecidos na firewall. Esta é a sua primeira linha de defesa e a opção que pode ser implementada mais imediatamente. Mantenha uma lista de bloqueio de endereços IP e domínios de resolvedores DoH conhecidos - Google, Cloudflare, Quad9, NextDNS, AdGuard, entre 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 resolvedores DoH conhecidos que serve como um bom ponto de partida. Esta abordagem lida com a maioria do tráfego DoH porque, como demonstrou a investigação do Software Engineering Institute da Carnegie Mellon, a maior parte do tráfego DoH vai para um pequeno número de resolvedores bem conhecidos. Os utilizadores que sabem o suficiente sobre DNS para configurar um resolvedor DoH personalizado são uma minoria muito reduzida. A limitação desta abordagem é ser uma lista de bloqueio, e as listas de bloqueio exigem manutenção. Surgem novos resolvedores DoH regularmente. No entanto, em combinação com as outras estratégias, oferece uma cobertura sólida. Estratégia dois: inspeção TLS na sua firewall de próxima geração. As firewalls de próxima geração de fornecedores que incluem a Palo Alto Networks, Fortinet, Check Point e Cisco Firepower suportam inspeção TLS - também designada por inspeção SSL ou inspeção profunda de pacotes. Quando ativada, a firewall funciona como um intermediário (man-in-the-middle) para o tráfego HTTPS, desencriptando-o, inspecionando o payload e voltando a encriptá-lo antes de o reencaminhar. Isto permite que a firewall identifique o tráfego DoH mesmo quando este se destina a um resolvedor desconhecido. O App-ID da Palo Alto consegue identificar o tráfego DoH especificamente 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 fidedignidade do certificado. Para que a inspeção TLS funcione nos dispositivos dos convidados, esses dispositivos precisam de confiar no seu certificado de inspeção. Em dispositivos corporativos geridos, isto é simples - envia o certificado através de MDM. Em dispositivos de convidados não geridos, é mais complexo. A abordagem prática para WiFi de convidados consiste em utilizar o fluxo de aceitação do Captive Portal para informar os utilizadores de que o tráfego pode ser inspecionado para efeitos de filtragem de conteúdos, e confiar na combinação do bloqueio de resolvedores DoH e da interceção de DNS como os seus controlos principais, 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 de rede sem fios para intercetar todo o tráfego DNS de saída nas portas UDP e TCP 53 e redirecioná-lo para o seu resolvedor DNS em conformidade. Isto não impede o DoH, mas garante que qualquer tráfego 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 853 de saída 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: Política de Grupo ou configuração de MDM para desativar o DoH ao nível do browser e do sistema operativo. 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 possuem 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 frequentemente 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 DNS sobre IPv6 são cada vez mais comuns, e muitas regras de firewall são escritas apenas para IPv4. Certifique-se de que a sua interceção da porta 53 e as listas de bloqueio de resolvedores DoH cobrem endereços IPv4 e IPv6. Terceiro: listas de bloqueio de resolvedores DoH desatualizadas. Se estiver a manter uma lista de bloqueio estática de IPs de resolvedores 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, Cisco Umbrella e serviços de DNS corporativos semelhantes incluem a deteção de desvio de DoH como uma capacidade gerida. Quarto: excesso de confiança numa única camada de mitigação. A mitigação de DoH é um problema de defesa em profundidade. Nenhum controlo individual é suficiente. Bloquear resolvedores conhecidos resolve a maioria dos casos. A inspeção TLS trata dos 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 correr uma configuração de browser legítima focada na privacidade, o seu bloqueio de DoH irá forçá-lo a usar o seu resolvedor DNS. A sua política de utilização aceitável deve deixar claro que o resolvedor DNS do local é utilizado para fins de filtragem de conteúdo. Esta é uma prática padrão e legalmente defensável. O DoH pode ser utilizado para exfiltrar dados da minha rede? Sim, e este é um vetor de ameaça real. O túnel DNS sobre DoH já foi demonstrado no mundo real. 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 sistema operativo - são difíceis de controlar sem inspeção TLS. A sua melhor mitigação é a combinação do bloqueio de resolvers conhecidos com a inspeção TLS. O WPA3 é relevante aqui? O WPA3 melhora a encriptação por rádio e fornece confidencialidade direta (forward secrecy), o que é excelente para a privacidade dos convidados. Mas o WPA3 não resolve o DoH - trata-se de um problema de protocolo de aplicação da camada 7, não de um problema de segurança sem fios da camada 2. São controlos complementares que abordam vetores de ameaça diferentes. Secção seis - ROI e impacto empresarial. Deixe-me concluir com o caso de negócio para abordar esta questão de forma adequada. 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 chamada de malware (malware callback) que passa despercebida porque a sua monitorização de DNS tinha um ponto cego, ou um inquérito regulamentar sobre a sua conformidade de filtragem de conteúdos - 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 normalmente 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 - que é amplamente automatizado se estiver a utilizar um serviço gerido de filtragem de DNS. O investimento total é modesto relativamente à redução de riscos. Para cadeias de retalho que operam sob o PCI-DSS, o benefício de conformidade é diretamente quantificável. Demonstrar que os controlos de segurança da sua rede incluem a mitigação de DoH reduz o risco de uma inconformidade em auditoria PCI-DSS e os respetivos custos de remediação. Para recintos 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 provas de que tomou medidas técnicas razoáveis para aplicar a sua política de filtragem de conteúdos. O resultado final: o DoH não é um problema do futuro. É um problema do presente. O Firefox, o Chrome, o Android e o iOS já estão a disponibilizar configurações com capacidade DoH nos dispositivos dos seus convidados neste exato 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 constar no seu roteiro a curto prazo. Para resumir as principais conclusões da sessão de hoje. Um: o DoH encripta as consultas de DNS dentro de HTTPS na porta 443, tornando-as invisíveis para a filtragem tradicional de DNS na porta 53. Isto está a acontecer por predefinição nos principais browsers 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 aplicar a interceção na porta 53 - fornece uma cobertura de defesa em profundidade tanto para dispositivos geridos como não geridos de convidados. 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 os recintos onde o DoH está a contornar silenciosamente as políticas de filtragem de conteúdos. Quatro: O erro 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 geridos de filtragem de DNS - Cloudflare Gateway, Cisco Umbrella e semelhantes - incluem cada vez mais a deteção de desvio de DoH como uma funcionalidade gerida, o que reduz a sobrecarga operacional de manutenção de listas de bloqueio estáticas. Por hoje terminamos o Purple Technical Briefing. Se procura auditar a sua arquitetura atual de filtragem de DNS ou implementar a mitigação de DoH em todo o seu património de instalações, a plataforma Purple fornece a inteligência de rede e a camada de gestão de WiFi de convidados para suportar essa implementação. Obrigado por ouvir e até à próxima sessão.