Best DNS filtering: a comprehensive guide for businesses
Este guia de referência técnica explica como o DNS filtering empresarial protege redes públicas bloqueando domínios maliciosos na camada de resolução - antes mesmo que uma conexão seja estabelecida. Ele fornece a diretores de TI, arquitetos de rede e equipes de operações de locais a arquitetura de implantação, configuração de firewall e contexto de conformidade que precisam para proteger o Guest WiFi em ambientes de hospitalidade, 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.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Para líderes de TI que gerenciam redes públicas de grande escala, proteger o ambiente de navegação é um mandato operacional, não um recurso opcional. O Guest WiFi em hotéis, 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 da Inspeção Profunda de Pacotes (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 simultâneos não gerenciados.
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 sobre HTTPS (DoH). Ele também trata da conformidade com PCI-DSS e GDPR, e explica como o Purple Shield se integra aos conjuntos de hardware existentes da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet sem exigir a substituição do hardware.
Análise técnica detalhada: como o filtro DNS opera
O Domain Name System (DNS) traduz domínios legíveis por humanos em endereços IP legíveis por máquinas. Toda conexão de internet começa com uma solicitação de resolução DNS. Em uma rede padrão, os dispositivos consultam um resolvedor padrão atribuído pelo ISP. Em uma arquitetura segura, o servidor DHCP atribui um resolvedor DNS com aplicação de políticas 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 filtragem 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. Em um local com 50.000 usuários simultâneos - como um estádio, centro de convenções ou grande complexo varejista - o DPI introduz latência significativa e exige hardware caro e dedicado em cada ponto de inspeção.
O filtragem 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 o payload de dados. O impacto na latência é consistentemente inferior a dois milissegundos, independentemente do número de usuários simultâneos.
Como o filtragem DNS opera antes do estabelecimento da conexão, ele é agnóstico em relação ao protocolo. Ele bloqueia conexões quer o aplicativo utilize 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 modernas de malware exploram esse atraso. Os atacantes registram domínios novos, 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 utiliza detecção de ameaças orientada por IA para analisar padrões de registro de domínios, reputação de IP e assinaturas criptográficas em tempo real. Essa abordagem identifica e bloqueia ameaças de dia zero emergentes 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 visitante 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 filtragem DNS exige 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 visitantes fique isolado dos sistemas operacionais. Coloque os dispositivos de visitantes em uma VLAN dedicada (por exemplo, VLAN 20) e mantenha terminais de PDV, sistemas de gestão de propriedades e dispositivos de funcionários em VLANs separadas com resolvedores de DNS internos. Isso garante que sua política de filtragem DNS seja aplicada exclusivamente ao tráfego de visitantes 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 visitantes nunca deve compartilhar uma VLAN com a infraestrutura de pagamento.
Passo 2: Configuração de escopo DHCP
Configure o escopo DHCP para a VLAN de convidados para atribuir os endereços IP do seu serviço de filtragem DNS em 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ó não é suficiente. 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 Cloudflare (1.1.1.1). Malwares frequentemente trazem configurações de DNS codificadas 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 DNS de um controle consultivo em um controle obrigatório.
Passo 4: Mitigação de DNS sobre HTTPS (DoH)
Navegadores e aplicativos modernos usam cada vez mais DoH, que criptografa 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 corporativo.
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 o Walled Garden primeiro e, em seguida, aplique sua política de filtragem de conteúdo apenas às sessões autenticadas.
Para saber mais sobre a arquitetura de SSID e como o Guest WiFi, Staff WiFi e redes IoT devem ser estruturados, consulte Três SSIDs para governar todos: guest, Passpoint e IoT WiFi .
Melhores práticas: design de políticas e gerenciamento contínuo
Bloqueio baseado em categorias
Organize 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 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 conforme as atualizações de inteligência de ameaças ocorrem.
Frequência de atualização de inteligência de ameaças
Selecione um provedor de filtragem de DNS que atualize a inteligência de ameaças em tempo real ou quase em tempo 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 impulsionada por IA que oferece a vantagem de 10 dias sobre provedores reativos.
Implantação independente de hardware
O Purple Shield opera como uma sobreposição na nuvem, o que significa que se integra à sua infraestrutura existente de pontos de acesso sem a 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, de modo que o hardware do ponto de acesso precisa apenas encaminhar as consultas de DNS para o resolvedor correto.
Análises e relatórios
A filtragem de DNS gera logs de consulta 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 de PCI-DSS e auditores de 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.
Solução de problemas e mitigação de riscos
Desvio de filtro via DNS personalizado
Sintoma: Os usuários relatam que conseguem acessar conteúdos que deveriam estar bloqueados. 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 por DHCP.
Solução: Implemente uma regra de firewall descartando todo o tráfego de saída UDP/TCP da porta 53 da VLAN de convidados para qualquer IP que não seja o seu mecanismo de filtragem.
Falha de autenticação do 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 de 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ão 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 as alterações de política.
Desvio de DoH
Sintoma: Os logs do filtro de DNS mostram baixo volume de consultas, apesar da alta utilização da rede. Alguns dispositivos parecem ignorar a filtragem completamente.
Causa: Os 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 operacional da VLAN
Sintoma: Terminais de PDV ou sistemas de gestão de propriedades perdem conectividade após a implantação do filtro de DNS.
Causa: A política de filtragem de DNS foi aplicada à VLAN errada, 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 access points. 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 oferece retornos mensuráveis em três dimensões.
Recuperação de largura de banda: O bloqueio de 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 visitantes de 20% a 40%, melhorando o desempenho para usuários legítimos sem exigir 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: A aplicação de políticas de navegação adequadas para famílias em ambientes de varejo e hospitalidade 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 o seu setor, consulte nossas páginas do setor para Hospitality , Retail , Healthcare e Transport .
Definições principais
DNS filtering
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 restrito de pré-autenticação 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 do provedor 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 o bloqueio em nível de firewall das faixas de IP dos provedores de DoH para manter a cobertura de filtragem de DNS.
VLAN segmentation
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 dos termos de serviço e captura de dados primários.
Requer uma configuração cuidadosa do Walled Garden para funcionar corretamente junto com a filtragem de DNS.
Deep Packet Inspection (DPI)
Um método de filtragem de rede que examina a carga útil (payload) completa dos pacotes em um ponto de inspeção, permitindo a filtragem com reconhecimento de conteúdo, mas introduzindo uma sobrecarga de processamento significativa.
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 gerenciados.
Threat intelligence feed
Um banco de dados continuamente atualizado de endereços IP, domínios e padrões de URL maliciosos conhecidos, utilizado para alimentar decisões de filtragem de DNS em tempo real.
A qualidade e a frequência de atualização do threat intelligence feed determinam a rapidez com que um filtro de DNS responde a novas ameaças de dia zero.
Zero-day domain
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 com 400 quartos está implantando Guest WiFi 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 de switch físico. Após ativar o DNS filtering, os hóspedes em 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 problema sem saída onde os hóspedes não conseguem carregar a página de login. Etapas de resolução: 1. No painel de DNS filtering, 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 recursos 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 resolvedores 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 fechar 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 domínios maliciosos conhecidos com sucesso. Os logs do filtro de DNS não mostram consultas bloqueadas desses dispositivos. Qual é a falha de arquitetura e qual é a correção?
A falha é que a porta 53 não está bloqueada no firewall. Os 18% dos dispositivos estão contornando os servidores DNS atribuídos por DHCP usando resolvedores codificados rigidamente (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 diferente dos 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 o desvio criptografado. 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 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 o 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 no sistema. 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 que descarte todo o tráfego UDP e TCP de saída na porta 53 da VLAN de convidados para qualquer IP diferente dos 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 conferências está implementando 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 ser acessíveis antes que a autenticação seja 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á 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 OAuth e autenticação 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 ativos 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. A equipe de TI de um estádio está avaliando a filtragem de DNS versus a Inspeção Profunda de Pacotes (DPI) para seu local com capacidade para 60.000 pessoas. A equipe de rede está preocupada com a latência durante eventos de pico. 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 requer a inspeção de todo o payload 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 é independente de protocolo, bloqueando conexões em qualquer porta, enquanto o DPI é normalmente limitado ao tráfego HTTP e HTTPS.
Q4. Um diretor de TI de um grupo hoteleiro deseja confirmar se a implementação de 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. Que evidências adicionais eles devem documentar para o avaliador do PCI DSS?
Dica: O Requisito 1.3 do PCI DSS cobre 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 resolvedores de 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 de filtragem de DNS. 4. Documentação da política de 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 monitorado.
Continue a ler esta série
Como Segregar com Segurança Redes WiFi de Funcionários e Convidados
Este guia técnico de autoridade fornece aos líderes de TI estratégias acionáveis para segregar com segurança redes WiFi de funcionários, convidados e IoT usando VLANs e 802.1X. Detalha como proteger a infraestrutura corporativa, manter a conformidade com o PCI-DSS e aproveitar captive portals para capturar dados primários.
Entendendo o Cisco SUDI: Identidade Ancorada em Hardware no Controle de Acesso a Redes Seguras
Este guia explica como o Cisco SUDI fornece uma identidade criptograficamente segura e ancorada em hardware para a infraestrutura de rede corporativa. Saiba como substituir endereços MAC clonáveis por certificados 802.1AR imutáveis para proteger o controle de acesso à rede do seu local.
Como Configurar o SCEP para Registro Automatizado de Certificados de WiFi Corporativo
Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para o registro automatizado de certificados de WiFi corporativo, cobrindo toda a arquitetura, desde PKI e NDES até a implantação de perfis MDM e validação RADIUS. Destina-se a gerentes de TI, arquitetos de rede e CTOs de hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar a autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem da Purple, independente de hardware, integra-se diretamente a essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que opera em conjunto com a rede de funcionários autenticada por certificado.