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

Bem-vindo ao Purple Technical Briefing. Eu sou o seu apresentador para a sessão de hoje e vamos passar os próximos dez minutos em um assunto que está silenciosamente enfraquecendo as políticas de filtragem de conteúdo em milhares de implantações de WiFi público agora mesmo - o DNS over HTTPS, ou DoH. Se você gerencia um WiFi de visitantes em um hotel, uma propriedade de varejo, um estádio ou uma instalação do setor público, e não abordou especificamente o DoH na arquitetura de 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 a declaração do problema. Vamos começar com uma rápida recapitulação de como a filtragem de DNS tradicional funciona, porque entender o mecanismo de desvio exige entender o que está sendo desviado. Quando o dispositivo de um visitante se conecta ao seu WiFi e tenta visitar um site, a primeira coisa que ele faz é enviar uma consulta de DNS - essencialmente perguntando qual é o endereço IP para esse domínio. Essa consulta trafega via UDP ou TCP na porta 53. A infraestrutura da sua rede intercepta essa consulta, roteia-a 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, seja o que for que sua política de uso aceitável especifique - o resolvedor se recusa a retornar o endereço IP e a conexão nunca acontece. Esta é a base de toda implantação de filtragem de conteúdo baseada em DNS. É econômica, não afeta a largura de banda e tem sido a abordagem padrão para operadores de locais públicos por quase uma década. O DNS over HTTPS quebra esse modelo. Veja como. O DoH envolve as consultas de 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 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 qualquer outro - por meio de um canal criptografado que seu filtro de DNS não pode inspecionar. O resultado? Sua política de filtragem de DNS cuidadosamente configurada é completamente contornada. O dispositivo resolve o domínio diretamente, sem que o seu resolvedor sequer veja a consulta. Vale destacar que isso não é um ataque deliberado por parte de seus visitantes. Na maioria dos casos, é totalmente passivo. O Firefox tem o DoH ativado por padrão desde 2020. O Chrome atualiza automaticamente as consultas de DNS para DoH se o resolvedor configurado oferecer suporte. 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 convencionais fazendo o que seus fabricantes planejaram. Seus visitantes não estão tentando burlar sua filtragem. Seus dispositivos estão apenas fazendo isso de forma automática. Seção dois - o mergulho técnico profundo. Vamos entrar nos detalhes técnicos. Existem dois padrões principais de implementação de DoH que você encontrará em campo. O primeiro é o DoH em nível de aplicação, onde a aplicação - 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 clássico. 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 de 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 sistema operacional, onde o próprio sistema operacional lida com a atualização. O Chrome, o Windows 10 e o Windows 11 adotam essa abordagem. Eles verificam se o resolvedor de DNS configurado no sistema - aquele atribuído pelo seu servidor DHCP - possui um endpoint de DoH correspondente. Se possuir, eles atualizam 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, que 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 está se tornando cada vez mais comum em dispositivos Android com Private DNS ativado. Sua estratégia de mitigação precisa abordar ambos. Agora vamos falar sobre por que isso representa 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 estabelece que você filtra certas categorias de conteúdo, e seus controles técnicos não impõem realmente essa política, você tem uma lacuna entre seus compromissos declarados de governança de conteúdo e proteção de dados e sua implementação técnica real. Isso é um problema de defensibilidade caso você enfrente uma investigação regulatória ou um incidente. Sob a Lei de Segurança Online do Reino Unido, os operadores de locais que oferecem acesso público à internet têm obrigações em relação à proteção dos usuários - especialmente menores - 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 se enquadram 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 de seus controles de segurança de rede. O tráfego DoH não monitorado é uma lacuna nesse framework de controle. E de um ponto de vista puramente de segurança, o DoH tem sido ativamente explorado por malware. 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 de mitigação principais 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 é a 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 recuse 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 bem conhecidos. Os usuários que conhecem 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 que incluem 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. 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 encaminhamento. Isso permite que o firewall identifique o tráfego DoH mesmo quando ele está indo para 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 fundamental de configuração é 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ê envia 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 confiar na combinação de bloqueio de resolvedores DoH e interceptação de DNS como seus controles principais, 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 DNS de saída nas portas UDP e TCP 53 e redirecioná-lo para o seu resolvedor DNS compatível. Isso não impede o DoH, mas garante que qualquer tráfego 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 visitantes 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 SO. No Firefox, a preferência network.trr.mode definida como 5 desativa o DoH completamente. No Chrome, o sinalizador disable-features equals 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 visitantes 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 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 considerar o IPv6. Consultas de DNS sobre IPv6 estão se tornando cada vez mais comuns, e muitas regras de firewall são escritas apenas para IPv4. Certifique-se de que sua interceptação da 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á desatualizada. Automatize o processo de atualização ou use um serviço de filtragem de DNS que mantenha essa lista para você. O Cloudflare Gateway, Cisco Umbrella e serviços de DNS corporativos semelhantes incluem a detecção de desvio de DoH como um recurso gerenciado. Quarto: excesso de confiança em 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 resolve os casos de exceção. A interceptação de DNS fornece uma rede de segurança. Utilize 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, o bloqueio de DoH forçará o uso do 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. A capacidade 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 de DoH — em vez de usar as configurações de DNS do SO — são difíceis de controlar sem inspeção TLS. Sua melhor mitigação é a combinação do bloqueio de resolvedores conhecidos e a inspeção TLS. O WPA3 é relevante aqui? O WPA3 melhora a criptografia no ar e fornece confidencialidade futura, o que é excelente para a privacidade dos convidados. Mas o WPA3 não resolve 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. Permita-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 convidado acessando conteúdo ilegal em sua rede, um retorno de chamada de malware passando despercebido porque seu monitoramento de DNS tinha um ponto cego, uma investigação regulatória sobre sua conformidade com a 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 a PCI-DSS, o benefício de conformidade é diretamente quantificável. Demonstrar que os controles de segurança de sua rede incluem mitigação de DoH reduz o risco de uma constatação de auditoria 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 de 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 resultado final: 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 convidados 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 em 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 em navegadores e sistemas operacionais convencionais. Dois: a estratégia de mitigação de 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 - fornece cobertura de defesa em profundidade para dispositivos de convidados gerenciados e não gerenciados. Três: este é um problema de conformidade, não apenas técnico. O GDPR, a Lei de Segurança Online e a PCI-DSS têm implicações para locais onde o DoH está ignorando silenciosamente as políticas de filtragem de conteúdo.Quatro: A falha de implementação mais comum é a interceptação incompleta da porta 53. Teste-a. Verifique-a. Não presuma que esteja funcionando. Cinco: Serviços gerenciados de filtragem de DNS - Cloudflare Gateway, Cisco Umbrella e semelhantes - incluem cada vez mais a detecção de desvio 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 todas as suas instalações, a plataforma Purple fornece a inteligência de rede e a camada de gerenciamento de WiFi de convidados para dar suporte a essa implantação. Obrigado por ouvir, e nos vemos na próxima sessão.