ExplainerDNS filtering limits
Filtragem DNS fail-open vs fail-closed: o que acontece quando o filtro falha
Poderá decidir como a sua rede WiFi para convidados e a sua rede WiFi para colaboradores devem comportar-se quando o filtro DNS deixar de responder e verificar se a sua rede realmente falha em modo closed. Saberá onde o fallback se esconde no DHCP, nos reencaminhadores e nos dispositivos, e como testar a redundância...
O comportamento em caso de falha da filtragem de DNS (fail open vs fail closed) é a escolha do que uma rede faz quando o seu resolvedor de filtragem deixa de responder. O fail open recorre a um resolvedor sem filtragem, para que a navegação continue sem proteção. O fail closed não envia consultas para mais lado nenhum, em conformidade com o controlo SC-24 do NIST SP 800-53 (falha em estado conhecido), pelo que nada é resolvido sem filtragem.
O que é o comportamento fail open vs fail closed na filtragem de DNS?
A filtragem de DNS situa-se no primeiro passo de cada ligação. Um telemóvel pede a um resolvedor para converter um nome de domínio num endereço IP antes de abrir qualquer sessão (RFC 1035). Um resolvedor de DNS de proteção verifica esse nome em relação aos dados sobre ameaças e à sua política de conteúdos. Em seguida, devolve o endereço real, o endereço de uma página de bloqueio ou uma recusa.
Esta localização é a razão pela qual a filtragem de DNS funciona. A verificação ocorre antes de um único pacote chegar ao destino. Pode parar uma hiperligação de phishing ou uma chamada de malware que um firewall veria apenas como tráfego permitido na porta 443. O National Cyber Security Centre do Reino Unido opera um serviço de DNS de proteção para o setor público com base no mesmo princípio.
A localização é também o ponto fraco. Se cada consulta depende do resolvedor de filtragem, precisa de um plano para quando este não puder ser alcançado. Existem apenas dois planos.
- Fail open. A rede ou o dispositivo envia a consulta para outro resolvedor que não aplica qualquer política. A navegação continua, mas a proteção, a registo de dados e as regras de conteúdo param até que o filtro regresse.
- Fail closed. Não existe nenhum caminho sem filtragem. As novas consultas aguardam que um resolvedor de filtragem responda e nada é resolvido sem uma decisão de política.
A escolha é um compromisso entre disponibilidade e garantia. O fail open favorece o visitante que pretende que uma página seja carregada no momento. O fail closed favorece a sua equipa de segurança, o responsável pela salvaguarda e o auditor, que precisam de demonstrar que a rede foi filtrada a cada minuto do ano.
O NIST SP 800-53 Rev. 5 enquadra a mesma ideia em dois controlos. O SC-24 é "falha em estado conhecido" e o SC-7(18) é "falha segura" (NIST SP 800-53 Rev. 5).
Como funciona o comportamento de falha do filtro no resolvedor?
A sua configuração decide o comportamento de falha do filtro, e não o filtro em si. Três locais o definem: o DHCP, qualquer reencaminhador de DNS local e o dispositivo.
Os campos de DNS do DHCP
O DHCP é o protocolo que entrega a cada dispositivo o seu endereço IP e as definições de rede quando este se liga. A maioria das redes de convidados e de colaboradores utiliza-o para fornecer a cada dispositivo dois ou mais endereços de servidores DNS. Se todos eles apontarem para resolvedores de filtragem, a conceção falha em modo fechado (fail closed). Se o segundo apontar para um ISP ou para um resolvedor público, a conceção falha em modo aberto (fail open), independentemente do que o fornecedor de filtragem prometa.
Flow diagram showing a guest device query timing out at the filtering resolver, falling back to an unfiltered secondary resolver and connecting to a domain with no policy check.
Connections
- Guest device to Filtering resolver (1. Query on port 53)
- Filtering resolver to Guest device (2. Timeout, no reply)
- Guest device to Unfiltered fallback resolver (3. Retry to secondary)
- Unfiltered fallback resolver to Answer with no policy check (4. Resolves any domain)
- Answer with no policy check to Connection opens (5. Device connects)
O reencaminhador local
Muitas firewalls e gateways executam um reencaminhador de DNS. Os dispositivos consultam o gateway e o gateway reencaminha para resolvers a montante. Aqui, a alternativa reside na lista a montante do reencaminhador. Um reencaminhador que liste um resolver público abaixo do filtro falha como aberto (fail open), mesmo que o DHCP pareça correto.
O próprio comportamento do dispositivo
A seleção do resolver varia consoante o sistema operativo. Alguns dispositivos tratam o segundo servidor como um recurso estritamente em espera. Outros consultam-no sempre que o primeiro está lento, ou enviam consultas para ambos. Numa arquitetura fail open, as respostas não filtradas podem, portanto, escapar mesmo quando o filtro está em perfeito funcionamento.
Como é o aspeto do fail closed
Numa arquitetura fail closed, todos os endereços DNS que um dispositivo ou reencaminhador pode utilizar apontam para um resolver de filtragem com a mesma política. Se um deixar de responder, o dispositivo tenta novamente no seguinte. A pesquisa falha apenas quando todos os resolvers de filtragem estão inacessíveis. O dispositivo recebe então um tempo limite ou SERVFAIL, a resposta padrão de "falha no servidor" do DNS, em vez de uma resposta não filtrada.
Diagrama de fluxo a mostrar um dispositivo a tentar novamente um segundo resolvedor de filtragem após o primeiro falhar, a política a permitir ou bloquear o domínio, e um caminho tracejado onde todos os resolvedores falham e nenhuma ligação é aberta.
Connections
- Dispositivo to Resolvedor de filtragem 1 (1. Consulta)
- Dispositivo to Resolvedor de filtragem 2 (2. Nova tentativa no próximo filtro)
- Resolvedor de filtragem 2 to Verificação de política (3. Aplicar política de rede)
- Verificação de política to Resposta limpa (4a. Domínio permitido)
- Verificação de política to Resposta de bloqueio (4b. Ameaça ou categoria bloqueada)
- Dispositivo to Sem resposta (Se todos os filtros falharem)
Quando implementada corretamente, a falha fechada não é frágil. A resiliência provém de resolvedores de filtragem redundantes, e não de um recurso de fuga sem filtragem.
Falhar aberto, falhar fechado, falhar seguro: que termos são confundidos?
Quatro termos semelhantes surgem frequentemente em documentos de fornecedores, relatórios de auditoria e pedidos de alteração. Eles descrevem aspetos diferentes e misturá-los leva a uma arquitetura incorreta.
| Termo | O que descreve | Durante uma falha do filtro | Risco associado |
|---|---|---|---|
| Fail open | As consultas recorrem a um resolvedor não filtrado quando o filtro está inacessível | A navegação continua, não filtrada | Ameaças e categorias bloqueadas são resolvidas sem política e, frequentemente, sem registo |
| Fail closed | Apenas são configurados resolvedores com filtragem, sem recurso a não filtrados | As novas pesquisas falham até que um resolvedor com filtragem responda | A disponibilidade depende da redundância do filtro |
| Fail secure (NIST SC-7(18)) | Termo da estrutura de controlo: um dispositivo de fronteira não deve entrar num estado não seguro após uma falha | Mesmo resultado prático que o fail closed | Os auditores podem solicitar provas desse comportamento |
| Serve-stale (RFC 8767) | Um resolvedor responde a partir de uma cache expirada quando os servidores a montante estão inacessíveis | Domínios visitados recentemente continuam a ser resolvidos | As respostas refletem a última decisão e não uma nova verificação de política |
| Default deny | Política para domínios que o filtro ainda não categorizou | Não é um modo de falha; aplica-se enquanto o filtro está funcional | Bloqueio excessivo se for definido de forma muito rígida |
| Bypass | Um dispositivo ignora o resolvedor da rede através de DNS codificado, DoH ou DoT | Não é afetado, pois não é filtrado em momento algum | Requer controlos de saída e não uma configuração de falha |
Fail closed não é default deny
Default deny é uma opção de política relativamente a domínios não categorizados. É executada enquanto o filtro está operacional. Fail closed refere-se ao que acontece quando o filtro está ausente. Pode executar o modo fail closed com uma política permissiva, ou o modo fail open com uma política estrita.
Serve-stale situa-se entre os dois
A RFC 8767 permite que um resolvedor responda a partir de uma cache expirada quando não consegue contactar os servidores a montante. Isto mantém os nomes populares a funcionar durante falhas de curta duração. Reproduz a última decisão, pelo que um domínio que se tenha tornado malicioso desde então não é detetado.
Bypass não é uma falha
Um dispositivo que utilize DNS over HTTPS (DoH, RFC 8484) ou DNS over TLS (DoT, RFC 7858) para um resolvedor público nunca entra em contacto com o seu filtro. As configurações de fail closed não têm qualquer efeito sobre isso. O bypass deve ser tratado com regras de saída.
Onde se depara com uma falha na filtragem de DNS na prática?
Uma falha na filtragem de DNS só é relevante quando a ligação à Internet está ativa, mas o filtro está inacessível. Se toda a ligação ascendente cair, ambos os modos comportam-se da mesma forma. Na prática, a diferença surge em eventos operacionais comuns:
- uma alteração no firewall que bloqueia a porta 53 de saída para os endereços do filtro;
- um reencaminhador local que falha ou deixa de reencaminhar para a montante;
- uma alteração de encaminhamento numa WAN de uma filial que envia o DNS para o caminho errado;
- um prestador de serviços a editar um escopo DHCP e a adicionar um resolvedor público "para resiliência";
- um incidente no próprio fornecedor de filtragem.
Cada uma destas ações parece inofensiva numa rede fail closed. No entanto, cada uma delas remove silenciosamente a proteção numa rede fail open.
Redes de convidados no setor da hotelaria
Hotéis e grupos de restauração aplicam políticas de conteúdos para manter o WiFi para convidados adequado para famílias e protegido contra malware. Uma rede de convidados em modo fail open desativa essa política sem avisar ninguém. Para grandes operadores hoteleiros, uma falha na política do WiFi público acarreta riscos reputacionais para a marca, bem como riscos de segurança.
Cuidados de saúde
O Shield bloqueia cerca de 241 000 ameaças por semana no St George's Healthcare NHS Trust. De acordo com as nossas contas, isso dá uma média de cerca de 1 400 por hora. Uma janela de fail open de apenas uma hora permitiria que essas consultas fossem resolvidas sem qualquer controlo em dispositivos de pacientes, visitantes e funcionários.
Hubs de transporte
Os aeroportos albergam milhares de dispositivos de passageiros em redes públicas, muitos dos quais não são geridos. Num terminal, uma lacuna de fail open significa uma rede pública não filtrada em períodos de pico de tráfego.
Redes corporativas e de funcionários
As redes de funcionários aumentam a exigência ao nível da disponibilidade. As aplicações empresariais têm de continuar a funcionar, pelo que a abordagem fail closed precisa de uma redundância real como suporte. Normalmente, os nomes internos são resolvidos em servidores DNS internos, que depois reencaminham as consultas externas para o filtro. Certifique-se de que essa camada de reencaminhamento também não tem qualquer upstream sem filtragem.
Quais são os limites e casos especiais do DNS fail closed?
A opção fail closed é o padrão correto para a maioria das redes WiFi de convidados e funcionários. Ainda assim, tem limites e deve conhecê-los antes de desenhar a sua arquitetura.
Fail closed com apenas um resolvedor é um plano de interrupção de serviço
Se a rede indicar apenas um único endereço de filtragem, o modo fail closed significa que qualquer interrupção nesse endereço deita abaixo todo o serviço de DNS. A redundância através de múltiplos resolvedores de filtragem é o que torna o fail closed viável. Pergunte ao seu fornecedor quantos endereços de resolvedor pode configurar e teste cada um deles.
A cache mantém alguns nomes ativos
Todas as respostas de DNS incluem um TTL (time to live), o número de segundos durante o qual um dispositivo ou resolvedor pode guardar essa resposta em cache. Durante uma interrupção curta, os nomes em cache continuam a funcionar e os novos nomes falham. Os visitantes percecionam isto como "alguns sites funcionam, outros não", o que pode induzir a sua equipa de suporte em erro.
Os Captive Portals precisam de DNS antes do login
Um Captive Portal é a página de entrada que um convidado vê antes de aceder à internet. O dispositivo tem de resolver o portal e quaisquer domínios da walled garden antes de se autenticar. Se a rede pré-login utilizar um resolvedor não filtrado, o portal passa a ser a brecha de segurança. Se falhar em modo fail closed sem redundância, os convidados não conseguem de todo fazer login.
Uma falha é diferente de um bloqueio
Um domínio bloqueado deve retornar uma página de bloqueio ou uma recusa clara. Uma pesquisa com falha retorna um limite de tempo excedido (timeout) ou SERVFAIL. O RFC 8914 Extended DNS Errors adiciona códigos que os diferenciam, tais como Bloqueado (15) e Filtrado (17) em vez de Nenhuma Autoridade Acessível (22). Informe o seu suporte técnico sobre ambos, para que possam distinguir um bloqueio de política de uma interrupção de serviço.
O DNS não consegue ver além do nome
O modo fail closed garante uma decisão de política em cada pesquisa, não uma cobertura total. As ligações a endereços IP simples ignoram o DNS por completo. As ligações já abertas antes da interrupção continuam ativas. O DNS também vê apenas o domínio, nunca o caminho, o que é explicado em por que razão a filtragem de DNS não consegue ver URLs completos.
Para perceber onde estes limites se enquadram numa arquitetura mais ampla, consulte a filtragem de DNS é suficiente? e a visão geral dos limites da filtragem de DNS.
Como se relaciona o DNS fail closed com o Purple Shield?
O Purple Shield é um DNS de proteção e filtragem de conteúdos para qualquer rede. O Shield funciona em modo fail closed, pelo que uma interrupção nunca deixa uma rede sem filtragem. Cada pesquisa obtém uma decisão de política ou nenhuma resposta, nunca uma resposta sem verificação.
Pode executar o Shield de forma independente em qualquer rede WiFi ou em conjunto com o Purple Access. Define uma política por rede e por VLAN (virtual LAN, uma rede logicamente separada em hardware partilhado). As redes de convidados, de funcionários e de serviços internos num mesmo local podem ter regras diferentes. O Shield não requer hardware novo e funciona como uma sobreposição na nuvem sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet.
- ~241 000ameaças bloqueadas por semanaSt George's Healthcare NHS Trust
- 80 000+locais ativosDados da Purple
- 90paísesDados da Purple
O DNSFilter e o Cisco Umbrella também filtram na resolução de DNS, pelo que o argumento do posicionamento se aplica aos três. A questão a colocar a cada fornecedor é onde se encontra a alternativa de segurança (fallback). Pergunte como se comportam os seus agentes de itinerância (roaming) quando os resolvedores estão inacessíveis e quantos endereços de filtragem pode configurar. Em seguida, verifique se as suas próprias definições de DHCP e reencaminhador não reintroduzem um caminho sem filtragem.
O Shield funciona em toda a infraestrutura da Purple de mais de 80 000 locais em 90 países. Leia como funciona o Shield para obter detalhes de implementação. O guia de segurança WiFi empresarial mostra onde a filtragem de DNS se posiciona ao lado da identidade e da segmentação.
Este conceito mostra a sua eficácia na janela de alteração, não na brochura. A regra de firewall, a edição de DHCP ou a secundária pública "resiliente" decidem se a sua rede permanece filtrada. Audite essas três definições este trimestre. Em seguida, leia DNS over TLS e filtragem: o que muda com a porta 853, porque um resolvedor com falha em modo fechado (fail closed) apenas protege os dispositivos que o utilizam efetivamente.
Perguntas frequentes
O DNS com falha em modo fechado significa que uma interrupção deixa o meu WiFi offline?
Não, não quando o filtro é executado em resolvedores redundantes. A falha em modo fechado apenas interrompe novas pesquisas quando todos os resolvedores de filtragem estão inacessíveis em simultâneo. Os dispositivos tentam novamente contra o endereço de filtragem seguinte primeiro. As respostas em cache mantêm os sites visitados recentemente a resolver durante curtas interrupções. Projete a redundância antes de entrar em funcionamento e, em seguida, teste-a bloqueando um resolvedor de cada vez a partir de uma VLAN de teste.
O Shield funcionará com os pontos de acesso e firewalls que já possuo?
Sim. O Shield filtra na resolução de DNS, pelo que não necessita de novo hardware e funciona de forma independente em qualquer rede WiFi. O Purple funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Direciona o DNS de cada rede ou VLAN para o Shield, remove qualquer alternativa não filtrada e aplica uma política por rede. A página do produto cobre os passos necessários.
Como é calculado o preço do Shield?
A Purple apresenta um orçamento do Shield para a sua infraestrutura em vez de publicar uma lista de preços neste guia. O Shield é um suplemento de segurança que pode executar de forma independente em qualquer rede WiFi ou juntamente com o Purple Access. O orçamento reflete, portanto, as suas redes e locais, não novo hardware. Peça um orçamento indicando o número de locais, o número de redes e VLAN, e se já utiliza a Purple.
Como posso migrar do DNSFilter ou do Cisco Umbrella sem uma lacuna na filtragem?
Faça a transição de uma rede ou VLAN de cada vez. Direcione o DNS DHCP de uma VLAN de teste para o Shield, confirme os bloqueios e registos e, em seguida, migre as redes ativas numa janela de alteração. Remova completamente os endereços dos resolvedores antigos em vez de os deixar como DNS secundário. Verifique também os agentes de roaming nos dispositivos da equipa, pois as suas definições de alternativa estão fora do alcance do seu DHCP.
Existe alguma regulamentação que exija a filtragem DNS com falha em modo fechado?
Nenhuma regulamentação especifica o DNS com falha em modo fechado, mas os quadros de controlo preveem que os controlos de segurança falhem num estado seguro e conhecido. O controlo SC-24 do NIST SP 800-53 Rev. 5 cobre a falha num estado conhecido. O SC-7(18) cobre a proteção de perímetro que falha em modo seguro. A filtragem com falha em modo fechado fornece provas de que a política foi aplicada a cada minuto, o que ajuda quando auditores ou responsáveis pela proteção de dados solicitam informações.
Como posso testar o comportamento de falha do meu filtro atual?
Bloqueie o DNS de saída para os seus resolvedores de filtragem a partir de uma única VLAN de teste e observe o comportamento do dispositivo. Se os sites continuarem a carregar e o filtro não registar nada, a rede falha em modo aberto (fail open). Verifique os campos de DNS do DHCP, as listas de encaminhadores a montante e quaisquer definições de dispositivos codificadas rigidamente. Repita com um resolvedor de filtragem bloqueado de cada vez para confirmar que a redundância funciona.
A filtragem de DNS é suficiente por si só ou preciso de um secure web gateway?
A filtragem de DNS cobre a proteção contra ameaças e a política de conteúdos para a maioria das redes de convidados e locais físicos, mas não a inspeção completa de URL ou a prevenção de perda de dados. Identifica nomes de domínio, não caminhos ou conteúdos de ficheiros. Se precisar desses controlos, adicione um secure web gateway nos dispositivos geridos. Consulte Filtragem de DNS vs secure web gateway para perceber onde se situa a fronteira.
Key terms
- DNS de proteção
- Um resolvedor recursivo que verifica cada domínio consultado em relação às informações sobre ameaças e à política de conteúdos antes de responder, devolvendo o endereço real, o endereço de uma página de bloqueio ou uma recusa. Atua na pesquisa de nomes definida na RFC 1035, antes de qualquer sessão ser aberta. O NCSC do Reino Unido opera um serviço de DNS de proteção para o setor público com base neste princípio. É o controlo cujo modo de falha esta decisão rege.
- Fail-open
- Uma arquitetura na qual as consultas DNS recorrem a um resolvedor que não aplica qualquer política quando o resolvedor de filtragem fica inacessível. A resolução continua, mas o bloqueio de ameaças, as regras de conteúdo e os registos param. Normalmente encontra-o como um resolvedor público ou do ISP no campo secundário do DHCP ou numa lista a montante do reencaminhador. Surge frequentemente por acidente durante uma alteração.
- Fail-closed
- Uma arquitetura na qual todos os endereços DNS que um dispositivo ou reencaminhador pode utilizar apontam para um resolvedor de filtragem com a mesma política. Uma pesquisa falha com um tempo limite esgotado ou SERVFAIL apenas quando todos os resolvedores de filtragem estão inacessíveis. Este é o padrão adequado para a maioria das redes WiFi para convidados e WiFi para colaboradores, desde que existam resolvedores de filtragem redundantes por trás.
- Fail-secure (NIST SC-7(18))
- Melhoria da proteção de perímetro SC-7(18) da norma NIST SP 800-53 Rev. 5, que exige que um dispositivo de perímetro evite entrar num estado inseguro quando falha. Os auditores podem solicitar provas disto. A filtragem DNS fail-closed oferece o mesmo resultado prático.
- Falha em estado conhecido (NIST SC-24)
- Controlo SC-24 da norma NIST SP 800-53 Rev. 5, que exige que os sistemas falhem num estado definido e conhecido, em vez de um estado imprevisível. Nenhum regulamento menciona explicitamente o DNS fail-closed, mas este controlo é a linguagem da estrutura que cita ao justificar o sistema a auditores ou responsáveis de segurança.
- Serviço de dados desatualizados (Serve-stale)
- Comportamento da RFC 8767 que permite a um resolvedor responder a partir da cache expirada quando não consegue contactar os servidores a montante, mantendo o funcionamento dos nomes resolvidos recentemente. Atenua interrupções de curta duração, mas reproduz a última decisão, pelo que um domínio que se tenha tornado malicioso entretanto não é detetado.
- SERVFAIL
- O código de resposta a falhas do servidor no formato de mensagem DNS definido na RFC 1035, devolvido quando um resolutor não consegue concluir uma pesquisa. Numa rede de falha fechada (fail closed), é o que um dispositivo recebe quando todos os resolutores de filtragem estão inativos. O seu suporte técnico tem de conseguir distingui-lo de um bloqueio.
- Erros alargados de DNS (Extended DNS Errors)
- Códigos da RFC 8914 que adicionam detalhes às respostas DNS, incluindo Bloqueado (15), Filtrado (17) e Autoridade Inalcançável (22). Permitem às equipas e ferramentas de suporte separar um bloqueio por política de uma interrupção de serviço ao diagnosticar relatórios de sites que não carregam.
- TTL (tempo de vida / time to live)
- O campo em cada registo de recurso DNS, definido na RFC 1035, que indica o número de segundos que um dispositivo ou resolutor pode guardar a resposta em cache. Durante uma breve interrupção de serviço, os nomes em cache continuam a funcionar e os novos falham. Os visitantes reportam isto como se alguns sites funcionassem e outros não.
- Reencaminhador de DNS
- Um serviço de DNS num firewall, gateway ou servidor interno que recebe consultas de dispositivos e as reencaminha para uma lista configurada de resolutores upstream. A alternativa reside na sua lista de upstream. Um resolutor público aí presente resulta numa falha aberta (fail open), mesmo que o DHCP esteja correto, incluindo o nível atrás do DNS interno em redes de colaboradores.
- DoH e DoT
- DNS over HTTPS, especificado na RFC 8484, e DNS over TLS, especificado na RFC 7858. Ambos cifram o DNS para um resolutor escolhido e podem contornar o resolutor da rede. Trata-se de um desvio (bypass) e não de uma falha. As definições de falha fechada (fail closed) não têm qualquer efeito sobre eles, pelo que os deve controlar com regras de saída.
- Portal cativo
- A página de entrada que um convidado vê antes de aceder à internet. O dispositivo tem de resolver o portal e os domínios do jardim murado (walled garden) antes de se autenticar. Um resolutor de pré-autenticação sem filtragem transforma o portal numa lacuna. Uma rede com portal em falha fechada (fail closed) sem redundância impede os convidados de iniciar sessão.
- Negação por omissão (Default deny)
- Uma política de filtragem para domínios que o filtro ainda não categorizou. Aplica-se enquanto o filtro está funcional e não é um modo de falha. É frequentemente confundida com falha fechada (fail closed). Pode executar uma falha fechada com uma política permissiva ou uma falha aberta (fail open) com uma política rigorosa.
Worked examples
Um prestador de serviços adiciona um resolvedor público ao escopo DHCP de uma rede de convidados como DNS secundário para resiliência. O resolvedor de filtragem permanece primário. A rede continua protegida?
Não. Um resolvedor público no campo secundário transforma a arquitetura em fail-open. Alguns sistemas operativos consultam esse segundo servidor sempre que o primeiro está lento, pelo que as pesquisas não filtradas podem ter fugas diariamente e não apenas durante interrupções. Para confirmar, bloqueie o DNS de saída para os resolvedores de filtragem a partir de uma única VLAN de teste. Se os sites continuarem a carregar e o filtro não registar nada, a rede falha em modo open. Substitua o endereço público por um segundo resolvedor de filtragem que aplique a mesma política. Em seguida, verifique se existem a mesma falha nas listas de reencaminhadores a montante e nas definições codificadas dos dispositivos. Por fim, bloqueie um resolvedor de filtragem de cada vez para provar que a redundância funciona.
Está a migrar as redes de convidados e de colaboradores do DNSFilter ou Cisco Umbrella para a Purple Shield. Como evita uma falha na filtragem durante a transição?
Efetue a transição de uma rede ou VLAN de cada vez. Comece por apontar o DNS DHCP de uma VLAN de teste para o Shield e, em seguida, confirme se os bloqueios e os registos aparecem como esperado. Migre as redes ativas numa janela de alteração assim que o teste for bem-sucedido. Remova completamente os endereços do resolvedor antigo em vez de os deixar como DNS secundário. Um secundário remanescente reintroduz um caminho não filtrado ou inconsistente. Verifique também os agentes itinerantes nos dispositivos dos colaboradores, pois as suas definições de fallback ficam fora do escopo DHCP. Esta abordagem mantém todas as pesquisas sob uma decisão de política durante toda a migração. Também mantém o comportamento fail-closed do Shield intacto assim que o fornecedor antigo for removido.
Frequently asked questions
O DNS em falha fechada (fail closed) significa que uma interrupção de serviço desliga a minha rede WiFi?
Não, não quando o filtro é executado em resolutores redundantes. A falha fechada (fail closed) apenas interrompe novas pesquisas quando todos os resolutores de filtragem ficam inacessíveis em simultâneo. Os dispositivos tentam primeiro novamente contra o endereço de filtragem seguinte. As respostas em cache mantêm a resolução dos sites visitados recentemente durante breves interrupções. Projete a redundância antes de entrar em funcionamento e, em seguida, teste-a bloqueando um resolutor de cada vez a partir de um VLAN de teste.
O Shield funcionará com os pontos de acesso e firewalls que já possuo?
Sim. O Shield filtra ao nível da resolução DNS, pelo que não necessita de novo hardware e funciona de forma independente em qualquer rede WiFi. O Purple funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Basta apontar o DNS de cada rede ou VLAN para o Shield, remover qualquer alternativa sem filtragem e aplicar uma política por rede. A página do produto abrange os passos necessários.
Como é calculado o preço do Shield?
A Purple apresenta orçamentos do Shield para o seu património em vez de publicar um preço de tabela neste guia. O Shield é um suplemento de segurança que pode executar de forma independente em qualquer rede WiFi ou em conjunto com o Purple Access. O orçamento reflete, portanto, as suas redes e locais, e não hardware novo. Solicite um orçamento indicando o número de locais, a sua rede, o número de VLAN e se já utiliza a Purple.
Como posso mudar do DNSFilter ou do Cisco Umbrella sem interrupções na filtragem?
Faça a transição de uma rede ou VLAN de cada vez. Apronte o DNS DHCP de um VLAN de teste para o Shield, confirme os bloqueios e registos e, em seguida, migre as redes ativas numa janela de alteração. Remova completamente os endereços do resolvedor antigo em vez de os deixar como DNS secundário. Verifique também os agentes de roaming nos dispositivos da equipa, pois as respetivas definições de recurso encontram-se fora do escopo do DHCP.
Existe alguma regulamentação que exija a filtragem DNS com falha fechada (fail-closed)?
Nenhuma regulamentação exige explicitamente o DNS com falha fechada (fail-closed), mas as estruturas de controlo preveem que os controlos de segurança falhem num estado conhecido e seguro. O controlo SC-24 da norma NIST SP 800-53 Rev. 5 abrange a falha num estado conhecido. O controlo SC-7(18) abrange a proteção de perímetro que falha de forma segura. A filtragem com falha fechada fornece provas de que a política foi aplicada a cada minuto, o que é útil quando auditores ou responsáveis pela proteção de dados o solicitarem.
Como posso testar o comportamento do meu filtro atual em caso de falha?
Bloqueie o DNS de saída para os seus resolvedores de filtragem a partir de um único VLAN de teste e observe o comportamento do dispositivo. Se os sites continuarem a carregar e o filtro não registar nada, a rede tem uma falha aberta (fail-open). Verifique os campos de DNS do DHCP, as listas de encaminhadores a jusante e quaisquer definições codificadas nos dispositivos. Repita o processo bloqueando um resolvedor de filtragem de cada vez para confirmar que a redundância funciona.
A filtragem DNS é suficiente por si só ou preciso de uma secure web gateway?
A filtragem DNS abrange a proteção contra ameaças e a política de conteúdos para a maioria das redes de convidados e locais, mas não a inspeção completa de URLs ou a prevenção de perda de dados. Esta solução identifica nomes de domínio, não caminhos ou conteúdos de ficheiros. Se necessitar desses controlos, adicione uma secure web gateway nos dispositivos geridos. Consulte [Filtragem DNS vs secure web gateway](guide:dns-filtering-vs-secure-web-gateway) para compreender a diferença.