Filtragem DNS com fail open vs. fail closed: o que acontece quando o filtro fica fora do ar

O comportamento da filtragem DNS em caso de falha - fail open versus fail closed - é a escolha do que uma rede faz quando seu resolvedor de filtragem deixa de responder. No modo fail open, a rede recorre a um resolvedor sem filtragem, permitindo que a navegação continue sem proteção. No modo fail closed, a rede não envia consultas a nenhum outro lugar, em conformidade com o controle SC-24 da norma NIST SP 800-53 (falha em estado conhecido), garantindo que nada seja resolvido sem filtragem.

O que é o comportamento de filtragem DNS fail open vs fail closed?

A filtragem DNS atua na primeira etapa de cada conexão. Um telefone solicita a um resolvedor que converta um nome de domínio em um endereço IP antes de abrir qualquer sessão (RFC 1035). Um resolvedor DNS de proteção compara esse nome com informações de inteligência de ameaças e com a sua política de conteúdo. Em seguida, ele retorna o endereço real, o endereço de uma página de bloqueio ou uma recusa.

Esse posicionamento é o motivo pelo qual a filtragem DNS funciona. A verificação ocorre antes que um único pacote atinja o destino. Isso pode interromper um link 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.

Esse posicionamento também é o ponto fraco. Se todas as consultas dependem do resolvedor de filtragem, você precisa de um plano para quando ele não puder ser alcançado. Existem apenas dois planos.

• Fail open. A rede ou dispositivo envia a consulta a outro resolvedor que não aplica nenhuma política. A navegação continua, mas a proteção, o registro de logs e as regras de conteúdo são interrompidos até que o filtro retorne.
• Fail closed. Não existe um caminho sem filtragem. Novas consultas aguardam a resposta de um resolvedor de filtragem, e nada é resolvido sem uma decisão de política.

A escolha é um equilíbrio entre disponibilidade e garantia. O fail open favorece o visitante que deseja carregar uma página imediatamente. O fail closed favorece sua equipe de segurança, o responsável pela conformidade e o auditor, que precisam comprovar que a rede permaneceu filtrada a cada minuto do ano.

A norma NIST SP 800-53 Rev. 5 estrutura a mesma ideia em dois controles. 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 determina o comportamento de falha do filtro, não o filtro em si. Três locais o definem: o DHCP, qualquer encaminhador DNS local e o próprio dispositivo.

Os campos de DNS do DHCP

O DHCP é o protocolo que fornece a cada dispositivo seu endereço IP e suas configurações de rede quando ele se conecta. A maioria das redes de convidados e de funcionários o utiliza para fornecer a cada dispositivo dois ou mais endereços de servidores DNS. Se todos eles apontarem para resolvedores de filtragem, a arquitetura é fail closed. Se o segundo apontar para um provedor de internet ou para um resolvedor público, a arquitetura é fail open, independentemente do que o provedor de filtragem prometa.

O encaminhador local

Muitos firewalls e gateways executam um encaminhador DNS. Os dispositivos consultam o gateway, e o gateway encaminha para os resolvedores upstream. Aqui o fallback reside na lista upstream do encaminhador. Um encaminhador que lista um resolvedor público abaixo do filtro opera em fail open, mesmo que o DHCP pareça correto.

O próprio comportamento do dispositivo

A seleção do resolvedor varia de acordo com o sistema operacional. Alguns dispositivos tratam o segundo servidor como um standby estrito. Outros o consultam sempre que o primeiro está lento, ou enviam consultas para ambos. Em um design fail open, respostas não filtradas podem, portanto, vazar enquanto o filtro está perfeitamente saudável.

Como é o comportamento em fail closed

Em um design fail closed, cada endereço DNS que um dispositivo ou encaminhador pode usar aponta para um resolvedor de filtragem com a mesma política. Se um parar de responder, o dispositivo tenta novamente no próximo. A busca falha apenas quando todos os resolvedores de filtragem estão inacessíveis. O dispositivo então recebe um tempo limite esgotado ou SERVFAIL, a resposta padrão de "falha no servidor" DNS, em vez de uma resposta não filtrada.

Feito corretamente, a falha fechada não é frágil. A resiliência vem de resolvedores de filtragem redundantes, não de uma saída sem filtro.

Falha aberta, falha fechada, falha segura: quais termos são confundidos?

Quatro termos correlatos aparecem em documentos de fornecedores, relatórios de auditoria e chamados de mudança. Eles descrevem coisas diferentes, e misturá-los leva a um projeto incorreto.

Fail closed não é default deny

O default deny é uma escolha de política em relação a domínios não categorizados. Ele é executado enquanto o filtro está funcional. O fail closed diz respeito ao que acontece quando o filtro está ausente. Você pode executar o fail closed com uma política permissiva ou o fail open com uma política rigorosa.

Serve-stale fica entre os dois

A RFC 8767 permite que um resolvedor responda a partir do cache expirado quando não consegue alcançar os servidores upstream. Isso mantém os nomes populares funcionando durante curtas interrupções. Ele reexibe a última decisão, portanto, um domínio que se tornou malicioso desde então não é capturado.

Bypass não é falha

Um dispositivo que usa DNS over HTTPS (DoH, RFC 8484) ou DNS over TLS (DoT, RFC 7858) para um resolvedor público nunca toca o seu filtro. As configurações de fail closed não interferem nisso. Você lida com o bypass usando regras de saída (egress).

Onde você encontra uma interrupção da filtragem de DNS na prática?

Uma interrupção da filtragem de DNS só importa quando o link de internet está ativo, mas o filtro está inacessível. Se todo o uplink cair, ambos os modos parecerão iguais. Na prática, a lacuna se abre por meio de eventos operacionais comuns:

• uma alteração no firewall que bloqueia a porta de saída 53 para os endereços do filtro;
• um encaminhador local que trava ou para de encaminhar para o upstream;
• uma alteração de roteamento em uma WAN de filial que envia o DNS para o caminho errado;
• um prestador de serviços editando um escopo DHCP e adicionando um resolvedor público "para fins de resiliência";
• um incidente no próprio provedor de filtragem.

Cada uma dessas situações parece inofensiva em uma rede fail closed. Cada uma delas remove a proteção silenciosamente em uma rede fail open.

Redes Wi-Fi para convidados no setor de hospitalidade

Hotéis e grupos de pubs aplicam políticas de conteúdo para manter o Wi-Fi para convidados adequado para famílias e seguro contra malware. Uma rede de convidados fail open descarta essa política sem avisar ninguém. Para grandes operadoras do setor de hospitalidade, uma falha de política no Wi-Fi público traz riscos à marca, além de riscos de segurança.

Setor da saúde

O Shield bloqueia cerca de 241.000 ameaças por semana no St George's Healthcare NHS Trust. Pelos nossos cálculos, isso dá uma média de cerca de 1.400 por hora. Uma janela de fail open de uma hora permitiria que essas pesquisas fossem resolvidas sem verificação, em dispositivos de pacientes, visitantes e funcionários.

Centros de transporte

Os aeroportos conectam milhares de dispositivos de passageiros em redes públicas, muitos deles não gerenciados. Em um terminal, uma brecha de fail open significa uma rede pública não filtrada no volume máximo de tráfego.

Redes corporativas e de funcionários

As redes de funcionários aumentam as exigências de disponibilidade. Os aplicativos de negócios precisam continuar funcionando, por isso o fail closed precisa de redundância real por trás dele. Nomes internos geralmente são resolvidos em servidores DNS internos, que encaminham consultas externas para o filtro. Certifique-se de que essa camada de encaminhamento também não tenha um upstream não filtrado.

Quais são os limites e casos especiais do DNS fail closed?

O fail closed é o padrão correto para a maioria das redes Wi-Fi de convidados e funcionários. Ele ainda tem limites, e você deve conhecê-los antes de projetar sua estrutura em torno dele.

Fail closed com um único resolvedor é um plano de interrupção total

Se a rede lista um único endereço de filtragem, o fail closed significa que qualquer queda desse endereço derruba o DNS. A redundância em múltiplos resolvedores de filtragem é o que torna o fail closed viável. Pergunte ao seu provedor quantos endereços de resolvedores você pode configurar e teste cada um deles.

O cache mantém alguns nomes ativos

Toda resposta DNS possui um TTL (time to live), o número de segundos que um dispositivo ou resolvedor pode mantê-la em cache. Durante uma interrupção curta, os nomes em cache continuam funcionando e os novos nomes falham. Os visitantes percebem isso como "alguns sites funcionam, outros não", o que pode induzir a sua equipe de suporte ao erro.

Portais cativos precisam de DNS antes do login

Um Captive Portal é a página de boas-vindas que um convidado vê antes de ficar online. O dispositivo precisa resolver o portal e quaisquer domínios de walled garden antes de se autenticar. Se a rede pré-login usar um resolvedor não filtrado, o portal se torna a brecha. Se ela falhar em fail closed sem redundância, os convidados não conseguirão fazer login de forma alguma.

Uma falha é diferente de um bloqueio

Um domínio bloqueado deve retornar uma página de bloqueio ou uma recusa clara. Uma consulta com falha retorna um tempo limite (timeout) ou SERVFAIL. O RFC 8914 (Extended DNS Errors) adiciona códigos que os diferenciam, como Bloqueado (15) e Filtrado (17) em vez de Nenhuma Autoridade Alcancável (22). Oriente sua equipe de suporte (helpdesk) 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

Falhar fechado garante uma decisão de política em cada consulta, não uma cobertura total. Conexões para endereços IP brutos ignoram o DNS completamente. Conexões já abertas antes da interrupção continuam ativas. O DNS também enxerga apenas o domínio, nunca o caminho, o que é explicado em por que o filtro DNS não consegue ver URLs completas.

Para entender onde esses limites se encaixam em uma arquitetura mais ampla, consulte o filtro DNS é suficiente? e a visão geral dos limites da filtragem DNS.

Como o DNS que falha fechado se relaciona com o Purple Shield?

O Purple Shield é um DNS de proteção e filtragem de conteúdo para qualquer rede. O Shield falha fechado, portanto, uma interrupção nunca deixa uma rede sem filtragem. Cada consulta recebe uma decisão de política ou nenhuma resposta, nunca uma resposta sem verificação.

Você pode executar o Shield de forma independente em qualquer rede WiFi ou junto com o Purple Access. Você define uma política por rede e por VLAN (virtual LAN, uma rede logicamente separada em hardware compartilhado). Redes de convidados, funcionários e back-office em um mesmo local podem ter regras diferentes. O Shield não precisa de novos hardwares e funciona como uma sobreposição na nuvem sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

O DNSFilter e o Cisco Umbrella também filtram na resolução de DNS, portanto, o argumento de implantação se aplica aos três. A pergunta a ser feita a cada fornecedor é onde fica a alternativa de fallback. Pergunte como seus agentes de roaming se comportam quando os resolvedores estão inacessíveis e quantos endereços de filtragem você pode configurar. Em seguida, verifique se as configurações do seu próprio DHCP e encaminhador não reintroduzem um caminho sem filtragem.

O Shield opera em toda a presença da Purple de mais de 80.000 locais em 90 países. Leia como o Shield funciona para detalhes de implantação. O guia de segurança de WiFi corporativo mostra onde a filtragem DNS se posiciona ao lado da identidade e da segmentação.

Este conceito cobra seu preço na janela de mudança, não no folheto. A regra de firewall, a edição de DHCP ou o secundário público "resiliente" decidem se sua rede permanece filtrada. Audite essas três configurações neste trimestre. Em seguida, leia DNS over TLS e filtragem: o que a porta 853 altera, pois um resolvedor com falha fechada só protege os dispositivos que realmente o utilizam.

Perguntas frequentes

A falha fechada do DNS significa que uma interrupção deixará meu WiFi offline?

Não, desde que o filtro seja executado em resolvedores redundantes. A falha fechada só interrompe novas consultas quando todos os resolvedores de filtragem ficam inacessíveis ao mesmo tempo. Os dispositivos tentam novamente o próximo endereço de filtragem primeiro. As respostas em cache mantêm a resolução de sites visitados recentemente durante curtas interrupções. Projete a redundância antes de entrar em operação e, em seguida, teste-a bloqueando um resolvedor por 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 na resolução de DNS, portanto não precisa de novo hardware e roda de forma autônoma em qualquer rede WiFi. O Purple funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você aponta o DNS de cada rede ou VLAN para o Shield, remove qualquer fallback não filtrado e aplica uma política por rede. A página do produto cobre o passo a passo.

Como é precificado o Shield?

A Purple fornece cotações do Shield para sua infraestrutura em vez de publicar uma lista de preços neste guia. O Shield é um complemento de segurança que você pode executar de forma autônoma em qualquer rede WiFi ou junto com o Purple Access. Portanto, a cotação reflete suas redes e locais, não um novo hardware. Solicite um orçamento informando a quantidade de locais, a quantidade de redes e de VLAN, e se você já utiliza o Purple.

Como faço a transição do DNSFilter ou do Cisco Umbrella sem lacunas na filtragem?

Faça a transição de uma rede ou VLAN por vez. Aponte o DNS do DHCP de um VLAN de teste para o Shield, confirme os bloqueios e logs e, em seguida, migre as redes em produção durante uma janela de mudança. Remova completamente os endereços dos resolvedores antigos, em vez de deixá-los como DNS secundário. Verifique também os agentes de roaming nos dispositivos da equipe, pois suas configurações de fallback ficam fora do escopo do seu DHCP.

Existe alguma regulamentação que exija a filtragem DNS com falha fechada?

Nenhuma regulamentação exige nominalmente o DNS com falha fechada, mas os frameworks de controle esperam que os controles de segurança falhem em um estado seguro e conhecido. O controle SC-24 do NIST SP 800-53 Rev. 5 cobre a falha em um estado conhecido. O SC-7(18) cobre a proteção de perímetro que falha de forma segura. A filtragem com falha fechada fornece evidências de que a política foi aplicada a todo momento, o que ajuda quando auditores ou responsáveis por conformidade solicitarem.

Como posso testar o comportamento de falha do meu filtro atual?

Bloqueie o DNS de saída para seus resolvedores de filtragem a partir de um único VLAN de teste e observe o comportamento do dispositivo. Se os sites ainda carregarem e o filtro não registrar nada, a rede está operando com falha aberta. Verifique os campos de DNS do DHCP, as listas de encaminhadores upstream e quaisquer configurações codificadas no dispositivo. Repita o teste bloqueando um resolvedor de filtragem por vez para confirmar se 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údo para a maioria das redes de convidados e locais físicos, mas não a inspeção completa de URLs ou a prevenção contra perda de dados. Ela visualiza nomes de domínio, não caminhos ou conteúdos de arquivos. Se você precisa desses controles, adicione um secure web gateway em dispositivos gerenciados. Consulte DNS filtering vs secure web gateway para entender onde fica a divisão.