Melhor filtragem DNS: um guia abrangente para empresas
Este guia de referência técnica explica como a filtragem DNS empresarial protege as redes públicas ao bloquear domínios maliciosos na camada de resolução - antes de uma ligação ser estabelecida. Oferece aos diretores de TI, arquitetos de rede e equipas de operações de locais a arquitetura de implementação, configuração de firewall e o contexto de conformidade necessários para proteger o WiFi de convidados em ambientes de hotelaria, retalho e setor público. O Purple Shield bloqueia malware, botnets e conteúdo inadequado ao nível do 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 Empresarial →
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 os líderes de TI que gerem redes públicas de grande escala, proteger o ambiente de navegação é um mandato operacional, não um extra opcional. O Guest WiFi na hotelaria, retalho e locais públicos é, por natureza, um ambiente não fidedigno. Sem controlos robustos, torna-se um vetor de distribuição de malware, atividade de redes botnet e acesso a conteúdos inadequados que prejudicam a reputação da marca e criam riscos de conformidade.
O filtro DNS é o mecanismo mais eficiente para aplicar políticas de conteúdos e bloquear ameaças na periferia da rede. Ao contrário da Inspeção Profunda de Pacotes (DPI), que consome muitos recursos, o filtro DNS intercepta o pedido de resolução de domínio antes que qualquer payload seja trocado. Este avalia um pacote UDP leve em relação a informações sobre ameaças em tempo real e devolve um endereço IP válido ou um "sinkhole", adicionando menos de dois milissegundos de latência. Isto torna-o o único método prático de controlo de conteúdos para ambientes de alta densidade que servem milhares de dispositivos não geridos em simultâneo.
Este guia aborda a arquitetura técnica necessária para implementar filtros DNS em locais empresariais 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). Também aborda a conformidade com PCI-DSS e GDPR, e explica como o Purple Shield se integra nas infraestruturas de hardware existentes de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet sem necessidade de substituição de hardware.
Análise técnica aprofundada: 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. Todas as ligações à internet começam com um pedido de resolução de DNS. Numa rede normal, os dispositivos consultam um resolvedor predefinido atribuído pelo ISP. Numa arquitetura segura, o servidor DHCP atribui um resolvedor DNS com aplicação de políticas aos dispositivos na VLAN de convidados.
Quando um dispositivo consulta este resolvedor seguro, o motor de filtragem avalia o domínio em relação a múltiplas fontes de dados em simultâneo: feeds de informações sobre ameaças em tempo real, listas de bloqueio de categorias (conteúdo para adultos, jogo, pirataria) e registos de domínios de comando e controlo de redes botnet. A decisão ocorre em milissegundos.
Se o domínio for seguro, o motor devolve o endereço IP correto e a ligação prossegue normalmente. Se o domínio for sinalizado como malicioso ou violar a sua política de utilização aceitável, o motor devolve um endereço IP não encaminhável ("sinkholing") ou redireciona o utilizador para uma página de bloqueio personalizada. O ponto crucial: esta intervenção ocorre antes de qualquer payload de dados ser 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 o payload de cada pacote. Num local com 50.000 utilizadores simultâneos - um estádio, centro de conferências ou uma grande propriedade de retalho - o DPI introduz uma latência significativa e requer hardware dispendioso e concebido especificamente para o efeito em cada ponto de inspeção.
O filtro DNS opera no início do ciclo de vida da ligação. 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 motor de filtragem nunca processa o payload de dados. O impacto na latência é consistentemente inferior a dois milissegundos, independentemente do número de utilizadores simultâneos.
Como o filtro DNS funciona antes do estabelecimento da ligação, é agnóstico em relação ao protocolo. Bloqueia ligações quer a aplicação utilize HTTP, HTTPS, FTP ou uma porta personalizada. Esta é uma vantagem significativa sobre a filtragem baseada em URL, que apenas inspeciona o tráfego HTTP/HTTPS.
A vantagem de 10 dias na deteção de ameaças
A segurança DNS legada depende de listas de bloqueio reativas: um domínio é identificado como malicioso, comunicado a uma autoridade central, adicionado a uma base de dados e, eventualmente, distribuído ao seu filtro - um processo que pode demorar dias. As campanhas modernas de malware exploram este atraso. Os atacantes registam novos domínios, executam uma campanha num período de 24 horas e abandonam o domínio antes que este chegue a qualquer lista de bloqueio padrão.
O Purple Shield utiliza a deteção de ameaças baseada em IA para analisar padrões de registo de domínios, reputação de IP e assinaturas criptográficas em tempo real. Esta abordagem identifica e bloqueia ameaças emergentes de dia zero até 10 dias mais rápido do que os fornecedores reativos tradicionais (dados internos da Purple, 2026). Num ambiente onde um único link malicioso num dispositivo convidado pode levar a ransomware, essa janela de deteção é operacionalmente significativa.
Guia de implementação: arquitetura e implementação
A implementaçã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 a sua rede de modo a que o tráfego de convidados fique isolado dos sistemas operacionais. Coloque os dispositivos dos convidados numa VLAN dedicada (por exemplo, VLAN 20) e mantenha os terminais POS, os sistemas de gestão de propriedades e os dispositivos dos funcionários em VLANs separadas com resolutores DNS internos. Isto garante que a sua política de filtro DNS se aplica exclusivamente ao tráfego de convidados não confiável e não interrompe os sistemas operacionais.
Esta segmentação também cumpre o Requisito 1.3 do PCI-DSS, que exige que os ambientes de dados dos titulares de cartões sejam isolados de redes não confiáveis. O WiFi de convidados nunca deve partilhar uma VLAN com a infraestrutura de pagamentos.
Passo 2: Configuração do âmbito do DHCP
Configure o intervalo DHCP para a VLAN de convidados para atribuir os endereços IP do seu serviço de filtragem de DNS na nuvem como os servidores DNS primário e secundário. Isto garante que cada dispositivo que se liga à rede de convidados recebe o resolver correto de forma automática.
Passo 3: Aplicação da porta 53 na firewall
A atribuição de DHCP por si só é insuficiente. Um utilizador pode anular as definições de DNS fornecidas pelo DHCP, configurando manualmente o seu dispositivo para utilizar um resolver público como o Google (8.8.8.8) ou o Cloudflare (1.1.1.1). O malware frequentemente codifica as definições de DNS de forma rígida para contornar totalmente os controlos de rede.
Deve implementar uma regra de firewall que elimine todo o tráfego de saída na porta 53 (tanto UDP como TCP) da VLAN de convidados para qualquer endereço IP que não sejam os seus servidores de filtragem designados. Isto converte o filtro de DNS de um controlo consultivo para um controlo obrigatório.
Passo 4: Mitigação de DNS over HTTPS (DoH)
Os browsers e aplicações modernos utilizam cada vez mais DoH, que encripta as consultas DNS dentro do tráfego HTTPS padrão na porta 443. Isto contorna totalmente a interceção na porta 53. Para manter a cobertura, configure a sua firewall para bloquear as gamas de endereços IP conhecidas dos principais fornecedores de DoH. Isto força os dispositivos clientes a recorrerem ao DNS não encriptado padrão, que o seu motor de filtragem consegue inspecionar. O documento 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 do Walled Garden do Captive Portal
Se 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 aceder antes de se autenticarem. Deve incluir todos os domínios necessários para que o Captive Portal funcione: o próprio domínio do seu portal, quaisquer fornecedores de identidade (Microsoft Entra ID, Okta, Google Workspace) e quaisquer endpoints OAuth de login social.
Se estes domínios forem bloqueados antes da autenticação, os utilizadores não conseguem concluir o fluxo de início de sessão. O resultado é uma experiência de integração interrompida e convidados frustrados. Configure primeiro o Walled Garden e depois aplique a sua política de filtragem de conteúdos apenas a sessões autenticadas.
Para saber mais sobre a arquitetura de SSID e como as redes de Guest WiFi, Staff WiFi e IoT devem ser estruturadas, consulte Três SSIDs para governar todos: guest, Passpoint e IoT WiFi.
-
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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.
Melhores práticas: design de políticas e gestão contínua
Bloqueio baseado em categorias
Organize a sua política de filtragem de DNS em torno de categorias de conteúdo em vez de listas de bloqueio de domínios individuais. As categorias incluem tipicamente: malware e phishing, comando e controlo de botnets, conteúdo adulto, jogos de azar, streaming ilegal e partilha de ficheiros 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 informações de ameaças são atualizadas.
Frequência de atualização de informações de ameaças
Selecione um fornecedor de filtragem de DNS que atualize a inteligência contra ameaças em tempo real ou quase em tempo real. As listas de bloqueio estáticas atualizadas diariamente são insuficientes contra as campanhas modernas de malware fast-flux. O Purple Shield atualiza a sua inteligência contra ameaças continuamente, refletindo a mesma deteção baseada em IA que proporciona a vantagem de 10 dias sobre os fornecedores reativos.
Implantação independente de hardware
O Purple Shield funciona como uma sobreposição na nuvem, o que significa que se integra com a sua infraestrutura de pontos de acesso existente sem necessidade de substituição de hardware. É 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, pelo que o hardware do ponto de acesso apenas necessita de encaminhar as consultas de DNS para o resolvedor correto.
Análise e relatórios
A filtragem de DNS gera registos de consultas detalhados que proporcionam visibilidade sobre o comportamento da rede. Utilize estes registos para identificar tendências: um pico de 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 as auditorias de conformidade, demonstrando aos avaliadores de PCI-DSS e auditores do GDPR que dispõe de controlos ativos.
A plataforma de WiFi Analytics da Purple integra-se com o Shield para fornecer uma visibilidade unificada em todos os eventos de segurança e desempenho da rede.
Resolução de problemas e mitigação de riscos
Contorno de filtro através de DNS personalizado
Sintoma: Os utilizadores relatam o acesso a conteúdos que deveriam estar bloqueados. Os registos da 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 na firewall. Os utilizadores estão a substituir as definições de DNS atribuídas por DHCP.
Solução: Implemente uma regra de firewall que rejeite 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 motor de filtragem.
Falha na autenticação do Captive Portal
Sintoma: Os convidados não conseguem concluir o fluxo de início de sessão. A página do Captive Portal não carrega ou os botões de início de sessão social não respondem.
Causa: O filtro de DNS está a bloquear os domínios do fornecedor de identidade antes da autenticação. O Microsoft Entra ID, o Google Workspace ou o próprio domínio do seu portal estão numa lista de categorias bloqueadas.
Solução: Audite a configuração do seu Walled Garden. Adicione todos os domínios de autenticação necessários à lista de permissões pré-autenticação. Teste todo o fluxo de início de sessão num ambiente de testes antes de implementar alterações de política.
Contorno de DoH
Sintoma: Os registos do filtro de DNS mostram um volume de consultas reduzido, apesar da elevada utilização da rede. Alguns dispositivos parecem contornar totalmente a filtragem.
Causa: Os navegadores ou aplicações estão a utilizar DoH, encaminhando consultas de DNS encriptadas através da porta 443 para resolvedores externos.
Solução: Bloqueie as gamas de IP conhecidas dos principais fornecedores de DoH na firewall. Verifique a cobertura monitorizando as ligações HTTPS para IPs de resolvedores de DoH conhecidos.
Interrupção da VLAN operacional
Sintoma: Os terminais POS ou sistemas de gestão de propriedades perdem a conectividade após a implementação do filtro de DNS.
Causa: A política de filtragem de DNS foi aplicada ao VLAN incorreto, ou o DHCP está a atribuir o resolvedor de DNS na nuvem a dispositivos operacionais.
Correção: Verifique a marcação de VLAN em todas as portas de comutadores e pontos de acesso. Confirme que os VLANs dos dispositivos operacionais estão configurados para utilizar apenas resolvedores de DNS internos.
ROI e impacto empresarial
A filtragem de DNS oferece retornos mensuráveis em três dimensões.
Recuperação de largura de banda: Bloquear streaming ilegal, partilha peer-to-peer e tráfego automatizado de botnets recupera uma largura de banda significativa. Num ambiente hoteleiro, isto pode reduzir a utilização do VLAN de convidados em 20-40%, melhorando o desempenho para utilizadores legítimos sem necessitar de atualizações de circuitos.
Redução de custos de conformidade: Demonstrar controlos ativos ao nível do DNS reduz o âmbito e o custo das avaliações PCI-DSS. Também fornece provas documentadas para o Artigo 32 do GDPR (medidas técnicas para garantir a segurança dos dados) e apoia os requisitos de certificação Cyber Essentials para proteção contra malware.
Proteção de marca e responsabilidade: Aplicar políticas de navegação adequadas para famílias em ambientes de retalho e hotelaria evita a exibição pública de conteúdos inadequados. Em locais frequentados por crianças - centros comerciais, hotéis familiares, estádios - este é tanto um requisito de marca como uma consideração legal em muitas jurisdições.
Para obter orientações de implementação específicas por setor, consulte as nossas páginas de indústria para Hotelaria, Retalho, Saúde e Transportes.
Definições Principais
Filtragem DNS
Uma técnica de segurança que interpeta pedidos de resolução de domínio e os avalia face a feeds de inteligência de ameaças e políticas de conteúdo antes de permitir ou bloquear uma ligação.
O método principal de controlo de conteúdos para dispositivos de convidados não geridos em redes públicas. Não requer nenhum agente de endpoint.
Sinkholing
Devolver 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 o dispositivo de estabelecer uma ligação.
Utilizado para bloquear silenciosamente o tráfego de comando e controlo de botnets sem alertar o malware de que foi detetado.
Walled Garden
Um ambiente de rede pré-autenticação restrito que permite o acesso a um conjunto específico de domínios aprovados antes de o utilizador concluir o fluxo de início de sessão 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 encripta consultas DNS dentro de tráfego HTTPS padrão na porta 443, ocultando o domínio de destino da inspeção ao nível da rede.
Cada vez mais utilizado por predefinição nos navegadores modernos. Requer o bloqueio ao nível do firewall das gamas de IP do provedor DoH para manter a cobertura de filtragem de DNS.
Segmentação de VLAN
Dividir uma única rede física em múltiplas redes lógicas isoladas através de etiquetas 802.1Q.
Crítica para isolar o tráfego de convidados dos sistemas operacionais. O Requisito 1.3 do PCI DSS exige que os ambientes de dados de titulares de cartões sejam separados de redes não fidedignas, incluindo o WiFi de convidados.
Captive portal
Uma página web com a qual os dispositivos devem interagir antes de obterem acesso total à rede, utilizada para autenticação, aceitação de termos de serviço e recolha de dados primários.
Requer 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 a totalidade da carga útil dos pacotes num ponto de inspeção, permitindo uma filtragem sensível ao conteúdo, mas introduzindo um processamento adicional significativo.
Inviável para redes de convidados de alta densidade devido à latência e ao custo de hardware. A filtragem de DNS é a alternativa preferida para ambientes de dispositivos não geridos.
Feed de inteligência de ameaças
Uma base de dados continuamente atualizada de endereços IP, domínios e padrões de URL conhecidos como maliciosos, utilizada 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 DNS responde a novas ameaças de dia zero.
Domínio de dia zero
Um domínio recém-registado utilizado numa campanha de malware ou phishing antes de aparecer em qualquer lista de bloqueio padrão.
As campanhas de ataque modernas utilizam domínios descartáveis que estão ativos por menos de 24 horas. A deteção de ameaças baseada em IA identifica estes domínios analisando padrões de registo em vez de aguardar por relatórios.
Exemplos Práticos
Uma cadeia hoteleira com 400 quartos está a implementar WiFi de convidados em 12 propriedades. Utilizam o Microsoft Entra ID para autenticação no Captive Portal e o seu sistema de gestão de propriedades (PMS) corre na mesma infraestrutura física de switches. Após ativarem a filtragem DNS, os convidados de três propriedades reportam que não conseguem concluir o fluxo de início de sessão. Qual é a causa raiz e como deve a equipa resolver o problema?
A causa raiz é uma configuração incompleta de Walled Garden. O filtro DNS está a bloquear os domínios de autenticação do Microsoft Entra ID antes de os convidados se autenticarem, criando um impasse onde os convidados não conseguem carregar a página de início de sessão. Passos para a resolução: 1. No painel de filtragem DNS, crie uma política de pré-autenticação que adicione explicitamente à 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 inquilino. 2. Verifique se o próprio domínio do Captive Portal e quaisquer recursos de CDN que este carregue também estão na lista de permissões. 3. Confirme que a VLAN do PMS (VLAN 10) está configurada para utilizar servidores de resolução DNS internos, e não o motor de filtragem na nuvem. 4. Aplique a política restritiva de bloqueio de conteúdos apenas a sessões pós-autenticação na VLAN de convidados (VLAN 20). 5. Teste o fluxo completo de início de sessão em cada propriedade afetada antes de encerrar o incidente.
Uma grande cadeia de retalho opera 200 lojas, cada uma com uma rede WiFi de convidados. A sua equipa de segurança de TI implementa um filtro DNS na nuvem e atualiza o âmbito de DHCP em todas as VLANs de convidados. Duas semanas depois, um teste de intrusão revela que 18% dos dispositivos dos convidados estão a conseguir resolver com sucesso domínios maliciosos conhecidos. Os registos do filtro DNS não mostram quaisquer consultas bloqueadas destes dispositivos. Qual é a falha arquitetural e qual é a correção?
A falha é que a porta 53 não está bloqueada na firewall. Os 18% de dispositivos estão a contornar os servidores DNS atribuídos por DHCP ao utilizarem servidores de resolução predefinidos (8.8.8.8, 1.1.1.1) ou utilizando DNS sobre HTTPS. Uma vez que as suas consultas DNS nunca chegam ao motor de filtragem, não surgem consultas bloqueadas nos registos. Correção: 1. Implemente uma regra de firewall no gateway da VLAN de convidados que rejeite todo o tráfego de saída UDP e TCP na porta 53 para qualquer IP que não sejam os IPs autorizados do motor de filtragem. 2. Identifique e bloqueie as gamas de IP dos principais fornecedores de DoH (Cloudflare, Google, NextDNS) na firewall para evitar desvios encriptados. 3. Execute novamente o teste de intrusão para confirmar a cobertura. 4. Monitorize os registos de rejeição da firewall para tráfego na porta 53 para verificar se a regra está ativa.
Perguntas de Prática
Q1. Uma cadeia de retalho implementa um filtro DNS na nuvem em 150 lojas. Atualizam o âmbito do DHCP em todas as VLAN de convidados para atribuir os IPs do motor de filtragem. Uma semana depois, os gerentes de loja relatam que os clientes ainda conseguem aceder a categorias de conteúdo bloqueado. O painel do filtro DNS mostra um volume de consultas muito baixo a partir destas lojas. Qual é a causa mais provável e qual é a solução?
Dica: Considere como um dispositivo pode resolver DNS sem utilizar 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 na firewall. Os dispositivos estão a sobrepor os servidores DNS atribuídos por DHCP por resolvedores públicos predefinidos no hardware. O baixo volume de consultas no painel confirma que as consultas não estão a chegar ao motor de filtragem. A solução é implementar uma regra de firewall que elimine todo o tráfego UDP e TCP de saída na porta 53 da VLAN de convidados para qualquer IP que não sejam os IPs aprovados do motor de filtragem. Adicionalmente, bloqueie as gamas de IP conhecidas de provedores DoH para evitar o desvio de DNS encriptado.
Q2. Um centro de conferências está a implementar a filtragem de DNS pela primeira vez. Utilizam o Google Workspace para a autenticação de participantes no seu Captive Portal. Durante os testes, os participantes não conseguem concluir o fluxo de início de sessão - a página de início de sessão do Google não carrega. Que passo de configuração foi esquecido e como deve ser corrigido?
Dica: A autenticação ocorre antes de o dispositivo ter acesso total à internet. Que domínios devem estar acessíveis antes de a autenticação ser concluída?
Ver resposta modelo
O Walled Garden não foi configurado antes de a política de filtragem de DNS ser aplicada. O filtro de DNS está a bloquear os domínios de autenticação do Google Workspace (accounts.google.com, oauth2.googleapis.com) antes que os participantes se possam autenticar. A correção consiste em adicionar todos os domínios de OAuth e autenticação do Google Workspace necessários à lista de permissões 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 adicionados à lista de permissões. Aplique a política de conteúdo restritiva apenas a sessões pós-autenticação.
Q3. A equipa de TI de um estádio está a avaliar a filtragem de DNS em comparação com a Inspeção Profunda de Pacotes (DPI) para o seu recinto com capacidade para 60.000 pessoas. A equipa de rede está preocupada com a latência durante os picos de eventos. Qual a abordagem mais adequada e porquê?
Dica: Considere a sobrecarga de processamento de cada método à escala de 60.000 utilizadores simultâneos.
Ver resposta modelo
A filtragem de DNS é a escolha adequada. Funciona na camada de resolução, avaliando um único pacote UDP leve antes de qualquer ligação ser estabelecida, adicionando menos de dois milissegundos de latência, independentemente do número de utilizadores simultâneos. A DPI requer a inspeção de todo o conteúdo de cada pacote, o que, com 60.000 utilizadores simultâneos, introduziria uma latência significativa e exigiria hardware extremamente dispendioso em cada ponto de inspeção. A filtragem de DNS é também agnóstica em relação ao protocolo, bloqueando ligações em qualquer porta, ao passo que a DPI está normalmente limitada ao tráfego HTTP e HTTPS.
Q4. Um diretor de TI de um grupo hoteleiro quer confirmar se a sua implementação de filtragem de DNS cumpre os requisitos do PCI DSS. Os seus terminais de pagamento estão na VLAN 10 e o WiFi de convidados está na VLAN 20. O filtro de DNS está aplicado apenas à VLAN 20. Que evidências adicionais devem documentar para o seu auditor do PCI DSS?
Dica: O Requisito 1.3 do PCI DSS abrange os controlos de acesso à rede entre redes fidedignas e não fidedignas.
Ver resposta modelo
O diretor de TI deve documentar: 1. Regras de firewall que confirmem que a VLAN 10 (ambiente de dados de titulares de cartões) não pode ser acedida a partir da VLAN 20 (rede de convidados), satisfazendo o Requisito 1.3 do PCI DSS. 2. Configuração de DHCP que mostre que os dispositivos da VLAN 10 utilizam resolvedores de DNS internos, e não o motor de filtragem na nuvem. 3. Regras de firewall que bloqueiem a porta de saída 53 da VLAN 20 para IPs não aprovados, demonstrando a aplicação obrigatória da filtragem de DNS. 4. Documentação da política do filtro de DNS que mostre as categorias ativas de bloqueio de malware e botnets na VLAN 20. 5. Registos do filtro de DNS que mostrem eventos de consultas bloqueadas, demonstrando que o controlo está ativo e a ser monitorizado.
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: lista de verificação de conformidade para operadores de locais públicos
Poderá decidir se a CIPA se aplica ao seu WiFi, depois segmentar redes, encaminhar o DNS através do Purple Shield e fechar caminhos de desvio. Saberá também quais as provas a conservar para a certificação do Form 486 ou Form 479. A lista de verificação atribui um proprietário a cada requisito, para que não falte nada na certificação do seu próximo ano de financiamento.
Falhas de ligação em modo de transição WPA3: uma checklist de implementação para Cisco Meraki, HPE Aruba e Ruckus
Utilize esta checklist para diagnosticar por que razão os dispositivos falham num SSID em modo de transição WPA3 SAE e resolva o problema em Cisco Meraki, HPE Aruba ou Ruckus. Irá associar códigos de estado 802.11 a causas, isolar problemas de PMF, 802.11r e 6GHz, e decidir quando mudar para um SSID exclusivo WPA3.
O Guia Empresarial para SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus
Este guia de referência técnica fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresarial usando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementaçã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 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.