Melhor filtragem de DNS: um guia completo para empresas
Este guia de referência técnica explica como a filtragem de DNS corporativa protege redes públicas bloqueando domínios maliciosos na camada de resolução - antes mesmo que uma conexão seja estabelecida. Ele oferece aos diretores de TI, arquitetos de rede e equipes de operações de locais a arquitetura de implantação, a configuração do firewall e o contexto de conformidade necessários para proteger o WiFi de convidados em ambientes de hotelaria, varejo e setor público. O Purple Shield bloqueia malware, botnets e conteúdo inadequado no nível de DNS em mais de 80.000 locais ativos.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança de WiFi Corporativo →
Enterprise DNS Filtering Sizing & Security Policy Advisor
Model real-world DNS query throughput, QPS spikes, malicious domain blocking rates, and CIPA compliance posture for guest and enterprise WiFi fleets with Purple Shield.
DNS Query Sizing & Edge Threat Mitigation Breakdown
Monthly WAN Bandwidth Savings
By sinkholing malware, malicious advertisements, and unauthorized streaming domains at the UDP resolution phase, the network prevents full TCP handshakes and payload downloads.
IT Administration Hours Saved
Managed threat intelligence feeds, no manual blocklist maintenance, and audit exports take repetitive resolver and firewall work off the service desk. The figure tracks the volume actually blocked, and is capped at 120 hours a month.
| Metric / Parameter | Current Model | Industry Benchmark | Status |
|---|---|---|---|
| Active Endpoint Concurrency | 3,825 devices | Peak concurrency 75%–90% | Sized |
| Resolver Response Latency | 12 ms | Target < 20 ms | Optimal |
| Total Monthly Queries Processed | 252,450,000 queries | High-density venue scale | Protected |
| DoH / DoT Bypass Containment | Active (Port 853 + ACL) | RFC 8484 / RFC 7858 block | Enforced |
Resumo executivo
Para líderes de TI que gerenciam redes públicas de grande escala, garantir a segurança do ambiente de navegação é um mandato operacional, não um luxo. O Guest WiFi em hotelaria, varejo e locais públicos é, por natureza, um ambiente não confiável. Sem controles robustos, ele se torna um vetor para distribuição de malware, atividade de botnets e acesso a conteúdo inadequado que prejudica a reputação da marca e cria riscos de conformidade.
O filtro DNS é o mecanismo mais eficiente para aplicar políticas de conteúdo e bloquear ameaças na borda da rede. Ao contrário do Deep Packet Inspection (DPI), que consome muitos recursos, o filtro DNS intercepta a solicitação de resolução de domínio antes que qualquer payload seja trocado. Ele avalia um pacote UDP leve em relação à inteligência de ameaças em tempo real e retorna um endereço IP válido ou um sinkhole, adicionando menos de dois milissegundos de latência. Isso o torna o único método prático de controle de conteúdo para ambientes de alta densidade que atendem a milhares de dispositivos não gerenciados simultâneos.
Este guia aborda a arquitetura técnica necessária para implantar o filtro DNS em locais corporativos distribuídos, incluindo segmentação de VLAN, aplicação da porta 53, integração de Captive Portal e prevenção de evasão de DNS over HTTPS (DoH). Ele também aborda a conformidade com PCI-DSS e GDPR, e explica como o Purple Shield se integra aos pacotes de hardware existentes da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet sem a necessidade de substituição de hardware.
Detalhamento técnico: como funciona o filtro DNS
O Domain Name System (DNS) traduz domínios legíveis por humanos em endereços IP legíveis por máquinas. Cada conexão de internet começa com uma solicitação de resolução de DNS. Em uma rede padrão, os dispositivos consultam um resolvedor padrão atribuído pelo provedor de internet. Em uma arquitetura segura, o servidor DHCP atribui um resolvedor DNS com aplicação de política aos dispositivos na VLAN de visitantes.
Quando um dispositivo consulta esse resolvedor seguro, o mecanismo de filtragem avalia o domínio em relação a várias fontes de dados simultaneamente: feeds de inteligência de ameaças em tempo real, listas de bloqueio de categorias (conteúdo adulto, jogos de azar, pirataria) e registros de domínios de comando e controle de botnets. A decisão acontece em milissegundos.
Se o domínio for seguro, o mecanismo retorna o endereço IP correto e a conexão prossegue normalmente. Se o domínio for sinalizado como malicioso ou violar sua política de uso aceitável, o mecanismo retornará um endereço IP não roteável (sinkholing) ou redirecionará o usuário para uma página de bloqueio personalizada. O ponto principal: essa intervenção ocorre antes que qualquer payload de dados seja trocado entre o dispositivo e o servidor de destino.
### Vantagens de desempenho e escala
O filtro DNS é arquitetonicamente superior ao DPI para ambientes públicos de alta densidade. O DPI exige que o hardware de rede inspecione a carga útil de cada pacote. Em um local com 50.000 usuários simultâneos - um estádio, centro de convenções ou grande propriedade de varejo - o DPI introduz uma latência significativa e exige hardware caro e dedicado em cada ponto de inspeção.
O filtro DNS opera no início do ciclo de vida da conexão. Ele avalia um único pacote UDP leve. Assim que a resolução é concluída, os dados são transferidos diretamente entre o cliente e o servidor de destino. O mecanismo de filtragem nunca processa a carga útil de dados. O impacto na latência é consistentemente inferior a dois milissegundos, independentemente do número de usuários simultâneos.
Como o filtro DNS funciona antes do estabelecimento da conexão, ele é independente de protocolo. Ele bloqueia conexões quer o aplicativo use HTTP, HTTPS, FTP ou uma porta personalizada. Esta é uma vantagem significativa sobre a filtragem baseada em URL, que inspeciona apenas o tráfego HTTP/HTTPS.
A vantagem de 10 dias na detecção de ameaças
A segurança de DNS legada depende de listas de bloqueio reativas: um domínio é identificado como malicioso, relatado a uma autoridade central, adicionado a um banco de dados e, eventualmente, distribuído ao seu filtro - um processo que pode levar dias. Campanhas de malware modernas exploram esse atraso. Os invasores registram novos domínios, executam uma campanha em uma janela de 24 horas e abandonam o domínio antes que ele chegue a qualquer lista de bloqueio padrão.
O Purple Shield usa detecção de ameaças baseada em IA para analisar padrões de registro de domínio, reputação de IP e assinaturas criptográficas em tempo real. Essa abordagem identifica e bloqueia ameaças emergentes de zero-day até 10 dias mais rápido do que os provedores reativos tradicionais (dados internos da Purple, 2026). Em um ambiente onde um único link malicioso em um dispositivo de convidado pode levar a um ransomware, essa janela de detecção é operacionalmente significativa.
Guia de implementação: arquitetura e implantação
A implantação correta do filtro DNS requer uma configuração de rede precisa em três camadas: DHCP, firewall e Captive Portal.
Passo 1: Segmentação de VLAN
Segmente sua rede para que o tráfego de convidados seja isolado dos sistemas operacionais. Coloque os dispositivos dos convidados em uma VLAN dedicada (por exemplo, VLAN 20) e mantenha os terminais de PDV, sistemas de gestão de propriedade e dispositivos de funcionários em VLANs separadas com servidores DNS internos. Isso garante que sua política de filtro DNS se aplique exclusivamente ao tráfego de convidados não confiável e não interrompa os sistemas operacionais.
Essa segmentação também atende ao Requisito 1.3 do PCI-DSS, que exige que os ambientes de dados de portadores de cartão sejam isolados de redes não confiáveis. O WiFi de convidados nunca deve compartilhar uma VLAN com a infraestrutura de pagamento.
Passo 2: Configuração do escopo DHCP
Configure o escopo DHCP para a VLAN de convidados para atribuir os endereços IP do seu serviço de filtragem DNS na nuvem como os servidores DNS primário e secundário. Isso garante que cada dispositivo que se conecta à rede de convidados receba o resolvedor correto automaticamente.
Passo 3: Aplicação da porta 53 no firewall
A atribuição de DHCP por si só é insuficiente. Um usuário pode substituir as configurações de DNS fornecidas pelo DHCP configurando manualmente seu dispositivo para usar um resolvedor público, como o Google (8.8.8.8) ou o Cloudflare (1.1.1.1). Os malwares frequentemente codificam as configurações de DNS de forma rígida para burlar completamente os controles de rede.
Você deve implementar uma regra de firewall que descarte todo o tráfego de saída na porta 53 (tanto UDP quanto TCP) da VLAN de convidados para qualquer endereço IP que não seja o dos seus servidores de filtragem designados. Isso converte o filtro de DNS de um controle consultivo em um controle obrigatório.
Passo 4: Mitigação de DNS over HTTPS (DoH)
Navegadores e aplicativos modernos utilizam cada vez mais o DoH, que criptografa as consultas DNS dentro do tráfego HTTPS padrão na porta 443. Isso ignora completamente a interceptação da porta 53. Para manter a cobertura, configure seu firewall para bloquear as faixas de endereços IP conhecidas dos principais provedores de DoH. Isso força os dispositivos clientes a recorrerem ao DNS padrão não criptografado, que seu mecanismo de filtragem pode inspecionar. O NIST SP 800-81r3 (publicado em março de 2026) aborda especificamente o DoH como uma consideração de segurança de DNS empresarial.
Passo 5: Configuração de Walled Garden do Captive Portal
Se você opera um Captive Portal para autenticação de convidados, deve configurar um Walled Garden antes de aplicar qualquer política de bloqueio. O Walled Garden é uma lista de domínios que os dispositivos podem acessar antes de serem autenticados. Ele deve incluir todos os domínios necessários para o funcionamento do Captive Portal: o próprio domínio do seu portal, quaisquer provedores de identidade (Microsoft Entra ID, Okta, Google Workspace) e quaisquer endpoints OAuth de login social.
Se esses domínios forem bloqueados antes da autenticação, os usuários não conseguirão concluir o fluxo de login. O resultado é uma experiência de integração interrompida e convidados frustrados. Configure primeiro o Walled Garden e, em seguida, aplique sua política de filtragem de conteúdo apenas para sessões autenticadas.
Para saber mais sobre a arquitetura de SSID e como o WiFi de convidados, WiFi de funcionários e redes IoT devem ser estruturados, consulte Três SSIDs para governar todos: convidados, Passpoint e WiFi IoT.
-
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.
Melhores práticas: design de políticas e gerenciamento contínuo
Bloqueio baseado em categorias
Organize sua política de filtragem DNS em torno de categorias de conteúdo, em vez de listas de bloqueio de domínios individuais. As categorias normalmente incluem: malware e phishing, comando e controle de botnets, conteúdo adulto, jogos de azar, streaming ilegal e compartilhamento de arquivos peer-to-peer. As políticas baseadas em categorias são mais fáceis de manter e capturam automaticamente novos domínios à medida que as inteligências de ameaças são atualizadas.
Frequência de atualização de inteligência de ameaças
Selecione um provedor de filtragem DNS que atualize a inteligência de ameaças em tempo real ou quase real. Listas de bloqueio estáticas atualizadas diariamente são insuficientes contra campanhas modernas de malware fast-flux. O Purple Shield atualiza sua inteligência de ameaças continuamente, refletindo a mesma detecção baseada em IA que oferece a vantagem de 10 dias sobre provedores reativos.
Implantação independente de hardware
O Purple Shield opera como uma sobreposição em nuvem, o que significa que ele se integra à sua infraestrutura de ponto de acesso existente sem a necessidade de substituir o hardware. Ele é compatível com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A política de filtragem é aplicada na camada de DNS, de modo que o hardware do ponto de acesso só precisa encaminhar as consultas de DNS para o resolvedor correto.
Análise e relatórios
A filtragem DNS gera logs de consultas detalhados que fornecem visibilidade sobre o comportamento da rede. Use esses logs para identificar tendências: um pico em tentativas de phishing bloqueadas a partir de um ponto de acesso específico pode indicar um ataque direcionado. A revisão regular dos relatórios de categorias bloqueadas também apoia auditorias de conformidade, demonstrando aos avaliadores PCI-DSS e auditores GDPR que você possui controles ativos implementados.
A plataforma de WiFi Analytics da Purple se integra ao Shield para fornecer visibilidade unificada de eventos de segurança e desempenho de rede.
Resolução de problemas e mitigação de riscos
Desvio de filtro via DNS personalizado
Sintoma: Os usuários relatam que conseguem acessar conteúdo que deveria estar bloqueado. Os logs do firewall mostram consultas de DNS para 8.8.8.8 ou 1.1.1.1 a partir da VLAN de convidados.
Causa: A porta 53 não está bloqueada no firewall. Os usuários estão substituindo as configurações de DNS atribuídas via DHCP.
Solução: Implemente uma regra de firewall descartando todo o tráfego de saída da porta UDP/TCP 53 da VLAN de convidados para qualquer IP que não seja o seu mecanismo de filtragem.
Falha de autenticação no Captive Portal
Sintoma: Os convidados não conseguem concluir o fluxo de login. A página do Captive Portal não carrega ou os botões de login social não respondem.
Causa: O filtro DNS está bloqueando os domínios do provedor de identidade antes da autenticação. O Microsoft Entra ID, o Google Workspace ou o próprio domínio do seu portal está em uma lista de categorias bloqueadas.
Solução: Audite sua configuração de Walled Garden. Adicione todos os domínios de autenticação necessários à lista de permissões de pré-autenticação. Teste o fluxo completo de login em um ambiente de homologação antes de implantar alterações de política.
Desvio de DoH
Sintoma: Os logs do filtro DNS mostram baixo volume de consultas, apesar da alta utilização da rede. Alguns dispositivos parecem ignorar completamente a filtragem.
Causa: Navegadores ou aplicativos estão usando DoH, roteando consultas de DNS criptografadas pela porta 443 para resolvedores externos.
Solução: Bloqueie as faixas de IP conhecidas dos principais provedores de DoH no firewall. Verifique a cobertura monitorando conexões HTTPS para IPs de resolvedores DoH conhecidos.
Interrupção da VLAN operacional
Sintoma: Terminais de PDV ou sistemas de gestão de propriedade perdem conectividade após a implantação do filtro DNS.
Causa: A política de filtragem de DNS foi aplicada à VLAN incorreta, ou o DHCP está atribuindo o resolvedor de DNS em nuvem a dispositivos operacionais.
Correção: Verifique a marcação de VLAN em todas as portas de switch e pontos de acesso. Confirme se as VLANs dos dispositivos operacionais estão configuradas para usar apenas resolvedores de DNS internos.
ROI e impacto nos negócios
A filtragem de DNS entrega retornos mensuráveis em três dimensões.
Recuperação de largura de banda: Bloquear streaming ilegal, compartilhamento peer-to-peer e tráfego automatizado de botnets recupera uma largura de banda significativa. Em um ambiente hoteleiro, isso pode reduzir a utilização da VLAN de convidados de 20% a 40%, melhorando o desempenho para usuários legítimos sem a necessidade de atualizações de circuito.
Redução de custos de conformidade: Demonstrar controles ativos em nível de DNS reduz o escopo e o custo das avaliações do PCI-DSS. Também fornece evidências documentadas para o Artigo 32 do GDPR (medidas técnicas para garantir a segurança dos dados) e apoia os requisitos de certificação do Cyber Essentials para proteção contra malware.
Proteção de marca e de responsabilidade: Aplicar políticas de navegação adequadas para famílias em ambientes de varejo e hotelaria evita a exibição pública de conteúdo inadequado. Em locais que atendem crianças - shoppings, hotéis familiares, estádios - isso é tanto um requisito de marca quanto uma consideração legal em muitas jurisdições.
Para obter orientações de implantação específicas para cada setor, consulte nossas páginas de setor para Hotelaria, Varejo, Saúde e Transporte.
Definições principais
filtragem de DNS
Uma técnica de segurança que intercepta requisições de resolução de domínio e as avalia em relação a feeds de inteligência de ameaças e políticas de conteúdo antes de permitir ou bloquear uma conexão.
O principal método de controle de conteúdo para dispositivos de convidados não gerenciados em redes públicas. Nenhum agente de endpoint é necessário.
Sinkholing
Retornar um endereço IP não roteável (como 0.0.0.0) em resposta a uma consulta DNS para um domínio malicioso, impedindo que o dispositivo estabeleça uma conexão.
Utilizado para bloquear silenciosamente o tráfego de comando e controle de botnets sem alertar o malware de que ele foi detectado.
Walled Garden
Um ambiente de rede pré-autenticação restrito que permite o acesso a um conjunto específico de domínios aprovados antes que o usuário conclua o fluxo de login do captive portal.
Deve incluir todos os domínios de provedores de identidade (Microsoft Entra ID, Google Workspace, Okta) e recursos do captive portal para evitar falhas de autenticação.
DNS over HTTPS (DoH)
Um protocolo que criptografa consultas DNS dentro do tráfego HTTPS padrão na porta 443, ocultando o domínio de destino da inspeção em nível de rede.
Cada vez mais utilizado por padrão nos navegadores modernos. Requer bloqueio em nível de firewall dos intervalos de IP dos provedores de DoH para manter a cobertura de filtragem de DNS.
Segmentação de VLAN
Divisão de uma única rede física em várias redes lógicas isoladas usando marcação 802.1Q.
Crítico para isolar o tráfego de convidados dos sistemas operacionais. O Requisito 1.3 do PCI DSS exige que os ambientes de dados de portadores de cartão sejam separados de redes não confiáveis, incluindo WiFi de convidados.
Captive portal
Uma página web com a qual os dispositivos devem interagir antes de obter acesso total à rede, utilizada para autenticação, aceitação de termos de serviço e captura de dados primários (first-party data).
Exige uma configuração cuidadosa do Walled Garden para funcionar corretamente em conjunto com a filtragem de DNS.
Deep Packet Inspection (DPI)
Um método de filtragem de rede que examina o conteúdo completo dos pacotes em um ponto de inspeção, permitindo filtragem sensível ao conteúdo, mas introduzindo um consumo significativo de processamento.
Inviável para redes de convidados de alta densidade devido à latência e custo de hardware. A filtragem de DNS é a alternativa preferencial para ambientes de dispositivos não gerenciados.
Feed de inteligência de ameaças
Um banco de dados atualizado continuamente com endereços IP, domínios e padrões de URL maliciosos conhecidos, usado para alimentar decisões de filtragem de DNS em tempo real.
A qualidade e a frequência de atualização do feed de inteligência de ameaças determinam a rapidez com que um filtro de DNS responde a novas ameaças de dia zero.
Domínio de dia zero
Um domínio recém-registrado usado em uma campanha de malware ou phishing antes de aparecer em qualquer lista de bloqueio padrão.
Campanhas de ataque modernas utilizam domínios descartáveis que ficam ativos por menos de 24 horas. A detecção de ameaças baseada em IA identifica esses domínios analisando padrões de registro em vez de esperar por relatórios.
Exemplos práticos
Uma rede de hotéis de 400 quartos está implantando WiFi para convidados em 12 propriedades. Eles usam o Microsoft Entra ID para autenticação no Captive Portal e seu sistema de gerenciamento de propriedades (PMS) roda na mesma infraestrutura física de switch. Após ativar a filtragem de DNS, os hóspedes de três propriedades relatam que não conseguem concluir o fluxo de login. Qual é a causa raiz e como a equipe deve resolver isso?
A causa raiz é uma configuração incompleta de Walled Garden. O filtro de DNS está bloqueando os domínios de autenticação do Microsoft Entra ID antes que os hóspedes se autentiquem, criando um ciclo vicioso onde os hóspedes não conseguem carregar a página de login. Passos para resolução: 1. No painel de filtragem de DNS, crie uma política de pré-autenticação que inclua explicitamente na lista de permissões todos os domínios do Microsoft Entra ID, incluindo login.microsoftonline.com, login.live.com e quaisquer domínios específicos do locatário. 2. Verifique se o próprio domínio do Captive Portal e quaisquer ativos de CDN que ele carrega também estão na lista de permissões. 3. Confirme se a VLAN do PMS (VLAN 10) está configurada para usar servidores de DNS internos, e não o mecanismo de filtragem em nuvem. 4. Aplique a política restritiva de bloqueio de conteúdo apenas às sessões pós-autenticação na VLAN de convidados (VLAN 20). 5. Teste o fluxo de login completo em cada propriedade afetada antes de encerrar o incidente.
Uma grande rede de varejo opera 200 lojas, cada uma com uma rede WiFi de convidados. Sua equipe de segurança de TI implanta um filtro de DNS em nuvem e atualiza o escopo DHCP em todas as VLANs de convidados. Duas semanas depois, um teste de invasão revela que 18% dos dispositivos de convidados estão resolvendo com sucesso domínios maliciosos conhecidos. Os logs do filtro de DNS não mostram consultas bloqueadas desses dispositivos. Qual é a falha arquitetônica e qual é a correção?
A falha é que a porta 53 não está bloqueada no firewall. Os 18% de dispositivos estão ignorando os servidores DNS atribuídos pelo DHCP ao usar resolvedores codificados no próprio sistema (8.8.8.8, 1.1.1.1) ou usando DNS sobre HTTPS. Como suas consultas de DNS nunca chegam ao mecanismo de filtragem, nenhuma consulta bloqueada aparece nos logs. Correção: 1. Implemente uma regra de firewall no gateway da VLAN de convidados que descarte todo o tráfego de saída UDP e TCP na porta 53 para qualquer IP que não seja os IPs aprovados do mecanismo de filtragem. 2. Identifique e bloqueie as faixas de IP dos principais provedores de DoH (Cloudflare, Google, NextDNS) no firewall para evitar desvios criptografados. 3. Execute novamente o teste de invasão para confirmar a cobertura. 4. Monitore os logs de descarte do firewall para tráfego na porta 53 para verificar se a regra está ativa.
Questões práticas
Q1. Uma rede de varejo implanta um filtro de DNS em nuvem em 150 lojas. Eles atualizam o escopo do DHCP em todas as VLANs de convidados para atribuir os IPs do mecanismo de filtragem. Uma semana depois, os gerentes das lojas relatam que os clientes ainda conseguem acessar categorias de conteúdo bloqueadas. O painel do filtro de DNS mostra um volume de consultas muito baixo vindo dessas lojas. Qual é a causa mais provável e qual é a solução?
Dica: Considere como um dispositivo pode resolver DNS sem usar o servidor atribuído pelo DHCP.
Ver resposta modelo
A causa mais provável é que a porta de saída 53 não está bloqueada no firewall. Os dispositivos estão substituindo os servidores DNS atribuídos pelo DHCP por resolvedores públicos codificados diretamente (hardcoded). O baixo volume de consultas no painel confirma que as consultas não estão chegando ao mecanismo de filtragem. A solução é implementar uma regra de firewall descartando todo o tráfego de saída UDP e TCP na porta 53 da VLAN de convidados para qualquer IP que não sejam os IPs aprovados do mecanismo de filtragem. Além disso, bloqueie as faixas de IP de provedores de DoH conhecidos para evitar o desvio de DNS criptografado.
Q2. Um centro de convenções está implantando a filtragem de DNS pela primeira vez. Eles usam o Google Workspace para autenticação de participantes em seu Captive Portal. Durante os testes, os participantes não conseguem concluir o fluxo de login - a página de login do Google não carrega. Qual etapa de configuração foi esquecida e como ela deve ser corrigida?
Dica: A autenticação ocorre antes que o dispositivo tenha acesso total à internet. Quais domínios devem estar acessíveis antes que a autenticação seja concluída?
Ver resposta modelo
O Walled Garden não foi configurado antes que a política de filtragem de DNS fosse aplicada. O filtro de DNS está bloqueando os domínios de autenticação do Google Workspace (accounts.google.com, oauth2.googleapis.com) antes que os participantes possam se autenticar. A correção consiste em adicionar todos os domínios de autenticação e OAuth do Google Workspace necessários à lista de permissões de pré-autenticação na política de filtragem de DNS. O próprio domínio do Captive Portal e quaisquer recursos de CDN também devem ser incluídos na lista de permissões. Aplique a política de conteúdo restritiva apenas às sessões pós-autenticação.
Q3. Uma equipe de TI de um estádio está avaliando a filtragem de DNS versus Deep Packet Inspection para o seu local com capacidade para 60.000 pessoas. A equipe de rede está preocupada com a latência durante os horários de pico dos eventos. Qual abordagem é mais apropriada e por quê?
Dica: Considere a sobrecarga de processamento de cada método na escala de 60.000 usuários simultâneos.
Ver resposta modelo
A filtragem de DNS é a escolha apropriada. Ela opera na camada de resolução, avaliando um único pacote UDP leve antes que qualquer conexão seja estabelecida, adicionando menos de dois milissegundos de latência, independentemente do número de usuários simultâneos. O DPI exige a inspeção de todo o conteúdo de cada pacote, o que, com 60.000 usuários simultâneos, introduziria uma latência significativa e exigiria hardware proibitivamente caro em cada ponto de inspeção. A filtragem de DNS também é agnóstica em relação ao protocolo, bloqueando conexões em qualquer porta, enquanto o DPI geralmente é limitado ao tráfego HTTP e HTTPS.
Q4. Um diretor de TI de um grupo de hotéis quer confirmar se a implantação da filtragem de DNS atende aos requisitos do PCI DSS. Seus terminais de pagamento estão na VLAN 10 e o WiFi de convidados está na VLAN 20. O filtro de DNS é aplicado apenas à VLAN 20. Quais evidências adicionais eles devem documentar para o avaliador do PCI DSS?
Dica: O Requisito 1.3 do PCI DSS aborda os controles de acesso à rede entre redes confiáveis e não confiáveis.
Ver resposta modelo
O diretor de TI deve documentar: 1. Regras de firewall confirmando que a VLAN 10 (ambiente de dados de portadores de cartão) não pode ser acessada a partir da VLAN 20 (rede de convidados), atendendo ao Requisito 1.3 do PCI DSS. 2. Configuração de DHCP mostrando que os dispositivos da VLAN 10 usam servidores de resolução DNS internos, não o mecanismo de filtragem em nuvem. 3. Regras de firewall bloqueando a porta de saída 53 da VLAN 20 para IPs não aprovados, demonstrando a aplicação forçada da filtragem de DNS. 4. Documentação da política do filtro de DNS mostrando categorias ativas de bloqueio de malware e botnets na VLAN 20. 5. Logs do filtro de DNS mostrando eventos de consultas bloqueadas, demonstrando que o controle está ativo e sendo monitorado.
Perguntas frequentes
How does enterprise DNS filtering protect guest and corporate WiFi networks?
Enterprise DNS filtering secures networks at the resolution layer before an HTTP or TCP connection is established. When a user or background application requests an IP address for a domain, the recursive resolver evaluates the query against real-time threat intelligence. Malicious domains associated with malware, ransomware command-and-control (C2), or phishing are instantly sinkholed, protecting unmanaged guest devices and corporate assets with negligible latency.
How does DNS filtering prevent DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) security bypasses?
Modern mobile devices and browsers often default to encrypted DoH or DoT, which bypasses local network DNS forwarders. Enterprise venues counter this by blocking outbound TCP port 853 (DoT) and enforcing Layer 7 firewall rules or Access Control Lists (ACLs) that drop traffic to known public DoH resolver IPs (such as Cloudflare 1.1.1.1 and Google 8.8.8.8), forcing client devices to use the venue protective DNS resolver.
What is the difference between recursive DNS resolution and Anycast protective DNS filtering?
Standard recursive DNS queries travel through multi-tier root and authoritative nameservers without security evaluation, exposing networks to poisoned cache entries and malicious destinations. Anycast protective DNS routes queries to globally distributed Anycast data center nodes that cross-reference domains against real-time threat feeds, returning cached results in under 15ms while neutralizing cyber threats and policy violations at the edge.
How does DNS filtering enforce CIPA (Children's Internet Protection Act) compliance across venues?
Under CIPA and educational safe-browsing mandates, venues providing public access must block visual depictions of obscenity, child sexual abuse material (CSAM), and harmful content. Protective DNS enforces these requirements network-wide without installing device certificates or endpoint software, categorizing billions of domains and enforcing Google and YouTube SafeSearch restrictions across all connected devices.
Can DNS filtering reduce venue internet bandwidth consumption and firewall compute load?
Yes. By blocking malicious payload downloads, high-bandwidth streaming domains, and intrusive ad-tracking networks at the initial DNS lookup phase, the network prevents large TCP payload transfers before they start. Venues deploying protective DNS typically observe a 6% to 12% reduction in overall WAN traffic and substantially reduced deep-packet inspection (DPI) processing load on edge firewalls.
How does Purple Shield integrate with existing enterprise routers, access points, and captive portals?
Purple Shield operates independently of access point hardware, integrating directly via DHCP nameserver assignment or DNS forwarders on Cisco Meraki, HPE Aruba, Fortinet, Ruckus, and Ubiquiti systems. For guest WiFi, it pairs with Purple Captive Portals to enforce strict pre-authentication walled gardens, allowing authentication traffic while shielding the venue from unauthorized outbound browsing.
Continue a ler esta série
Conformidade com a CIPA: checklist de conformidade para operadores de locais
Você será capaz de decidir se a CIPA se aplica ao seu WiFi, depois segmentar redes, rotear o DNS através do Purple Shield e fechar rotas de desvio. Você também saberá quais evidências guardar para a certificação do Formulário 486 ou Formulário 479. O checklist atribui cada requisito a um responsável, para que sua certificação do próximo ano de financiamento não tenha nenhuma pendência.
Falhas de conexão no modo de transição WPA3: um checklist de implantação para Cisco Meraki, HPE Aruba e Ruckus
Use este checklist para diagnosticar por que os dispositivos falham em um SSID de modo de transição WPA3 SAE e corrija o problema no Cisco Meraki, HPE Aruba ou Ruckus. Você associará códigos de status 802.11 às causas, isolará problemas de PMF, 802.11r e 6GHz, e decidirá quando migrar para um SSID exclusivo WPA3.
O Guia Corporativo de SCEP: Implantando o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi de Campus
Este guia de referência técnica fornece um modelo de arquitetura definitivo e uma estratégia de implementação passo a passo para a implantação de certificados de WiFi corporativos usando SCEP. Ele aborda as diferenças críticas entre SCEP e PKCS, a sequência exata de implantação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.