DNS sinkhole explicado: como ele interrompe chamadas maliciosas
Um DNS sinkhole redireciona pesquisas de malware para um chamariz, interrompendo chamadas e revelando dispositivos infectados. Saiba como funciona e onde implantar.
Published 2 de novembro de 2026
Um visitante conecta um notebook ao WiFi do seu caféWiFi, abre o navegador e segue com o seu dia. Em segundo plano, um malware nesse notebook tenta contatar seu controlador. Você não pode instalar software de segurança no dispositivo de cada visitante, mas pode controlar como sua rede responde às solicitações de destinos de internet desse dispositivo.
Um DNS sinkhole oferece uma maneira de interromper esse callback e registrar evidências valiosas para investigação. A questão útil não é apenas o que ele bloqueia. É se você consegue identificar o dispositivo afetado, provar que sua política se aplica e restaurar o acesso legítimo quando uma regra cometer um engano.
Sumário
- O que é um DNS Sinkhole em termos simples
- Como um Sinkhole responde a uma consulta maliciosa
- O surto do Conficker que tornou os Sinkholes um padrão
- Como transformar alertas de Sinkhole em pistas de dispositivos infectados
- Modelos de implantação para redes compartilhadas e de visitantes
- Falsos positivos e como restaurar o acesso rapidamente
- Decida se um Sinkhole é adequado para a sua rede
O que é um DNS Sinkhole em termos simples
O laptop infectado precisa encontrar seu controlador antes de solicitar instruções. Se o malware usar um nome de domínio, o laptop primeiro solicita a um resolvedor de DNS que traduza esse nome em um endereço IP.
Pense no DNS como uma lista telefônica. O domínio é o nome que você pesquisa, e o endereço IP é o número para o qual você precisa ligar. Um resolvedor de proteção verifica se deve fornecer esse número.
Um sinkhole de DNS substitui a resposta de um domínio conhecido como malicioso por um destino controlado, ou bloqueia a resposta, para que o dispositivo não possa usar essa pesquisa para alcançar o atacante.
Stricto sensu, sinkholing significa redirecionar o tráfego para um endpoint controlado. Os administradores também usam o termo de forma mais ampla para políticas de DNS que suprimem pesquisas maliciosas sem fornecer um destino.
A analogia com a lista telefônica ajuda a separar a busca do nome da conexão que se segue.
O bloqueio de DNS não é o mesmo que bloqueio de IP
Um DNS sinkhole atua sobre o nome solicitado antes que o dispositivo use a resposta para contatar esse destino. Uma regra de firewall comum avalia os pacotes, geralmente usando o endereço IP de destino, e pode rejeitar a tentativa de conexão inicial. O firewall não precisa esperar por uma conexão estabelecida.
Essa distinção é importante quando serviços legítimos e maliciosos compartilham a mesma infraestrutura de hospedagem. Bloquear um endereço IP inteiro pode afetar serviços não relacionados, enquanto uma política de DNS pode direcionar um nome de host específico. Nenhuma das abordagens substitui a outra.
Em WiFi compartilhados, o resolutor é útil porque o operador não precisa de acesso administrativo ao notebook. No entanto, interromper um callback não remove a infecção. Isso dá ao operador uma oportunidade de contenção e, com os registros adequados, uma pista para investigação.
Como um sinkhole responde a uma consulta maliciosa
Uma pesquisa de DNS é uma solicitação de informações, não uma conexão com o site solicitado. A resposta do resolvedor determina o que o dispositivo pode tentar em seguida.
O caminho básico separa o dispositivo, a verificação da política e o destino controlado.
- O dispositivo solicita seu domínio de retorno de chamada. Ele envia uma consulta ao seu resolvedor configurado.
- O resolvedor identifica qual política se aplica à rede de origem, como uma de visitantes SSID ou de funcionários VLAN.
- O nome é verificado em relação à inteligência de ameaças e às regras locais, incluindo categorias de comando e controle, phishing e malware.
- Em caso de correspondência de bloqueio, o resolvedor fornece um endereço controlado, retorna uma resposta de nome inexistente ou recusa/suprime a resposta.
- O dispositivo tenta uma conexão com a armadilha (decoy) ou não consegue obter um destino útil. Nomes permitidos são resolvidos normalmente.
Antes de um dispositivo abrir um site ou aplicativo, ele consulta o DNS para saber onde encontrá-lo, e o Shield responde usando a política dessa rede. Se um domínio estiver bloqueado, a conexão com esse destino nunca é iniciada e o dispositivo exibe a página de bloqueio personalizada do cliente. Essa experiência voltada ao usuário não deve ser confundida com um malware tentando novamente um retorno de chamada que falhou.
Escolha a resposta de acordo com a evidência necessária
Opções de resposta de sinkhole e o que cada uma revela
| Resposta | O que o dispositivo vivencia | O que os defensores descobrem | Principal ponderação |
|---|---|---|---|
| Nome inexistente (NXDOMAIN) | A busca falha e a conexão nunca é iniciada | Que uma busca foi tentada e bloqueada | Interrompe o retorno de chamada, mas não fornece comportamento de conexão subsequente |
| Endereço de sinkhole | A busca retorna o endereço de um servidor controlado | IP de origem, tempo do retorno de chamada, padrão de nova tentativa e protocolo observável | Exige um ponto de extremidade monitorado e armazenamento cuidadoso de logs |
| Resposta recusada ou suprimida | O resolvedor recusa a consulta ou a deixa sem resposta | Pouco além da própria tentativa, a menos que o registro de logs do resolvedor esteja ativado | Rápido de aplicar, mas alguns clientes tentam novamente de forma agressiva |
O NXDOMAIN não apaga informações de origem ou carimbo de data/hora. Um resolvedor pode registrar ambos. O que ele não pode coletar dessa busca com falha é a conexão que o malware teria feito em seguida.
Uma avaliação de captura de pacotes de sinkhole revisada por pares relatou uma melhoria de cinco vezes na captura de pacotes maliciosos com um projeto de coleta avançado em comparação com uma implementação convencional. Trata-se de uma evidência sobre a arquitetura de coleta, e não de uma promessa de que todo sinkhole proporcionará a mesma melhoria.
Este vídeo oferece outra maneira de acompanhar o mecanismo.
A resposta escolhida por você determina qual comportamento subsequente poderá observar. Mantenha os coletores isolados e não presuma que o redirecionamento produzirá uma página de aviso limpa para todos os aplicativos criptografados.
O surto do Conficker que tornou os sinkholes um padrão
O Conficker mostrou como os defensores podiam transformar a busca de um malware por instruções em uma fonte de inteligência. Em vez de inspecionar cada computador infectado, os pesquisadores interceptavam os destinos que o worm estava programado para contatar.
O arquivo Conficker da CAIDA descreve o surto detectado pela primeira vez em novembro de 2008, com variantes iniciais gerando aproximadamente 250 nomes de domínio pseudo-aleatórios por dia. O worm contatava os nomes gerados via HTTP para obter instruções ou malware adicional.
Pesquisadores e operadores de rede registraram domínios selecionados antes que os criminosos pudessem usá-los e, em seguida, apontaram esses nomes para servidores controlados. Consequentemente, os computadores infectados acionavam a infraestrutura operada pelos defensores.
A consulta tornou-se um ponto de medição
Esses callbacks ajudavam as equipes de resposta a identificar sistemas infectados, estimar a propagação do worm e acompanhar o progresso da limpeza sem se comunicar diretamente com a rede de comando criminosa. Portanto, uma interceptação bem-sucedida fazia mais do que negar uma atualização. Ela registrava um computador que ainda tentava obter uma.
- Para contenção, os encarregados da resposta impediram que nomes selecionados levassem à infraestrutura controlada pelo atacante.
- Para investigação, os logs de retorno de chamada (callbacks) identificaram sistemas que precisavam de atenção.
- Para acompanhamento da remediação, retornos de chamada contínuos indicavam que a limpeza permanecia incompleta.
As variantes posteriores do Conficker expandiram o grupo de nomes gerados e adicionaram atualizações ponto a ponto (peer-to-peer). Os encarregados da resposta tiveram que coordenar o registro e o bloqueio em vez de confiar em uma lista pequena e estática.
A implantação histórica também se diferenciava da política de filtragem local de uma organização. Os pesquisadores alteravam os destinos dos domínios que controlavam, afetando os computadores infectados que resolviam esses nomes por meio do DNS comum. Em vez disso, o operador de um local geralmente aplica a política em seu próprio resolutor recursivo.
A cobertura foi a limitação em ambos os casos. Os defensores podiam interceptar retornos de chamada para nomes sob seu controle, mas isso não significava que todas as rotas de atualização possíveis tivessem desaparecido. O Conficker estabeleceu o sinkholing como uma técnica de contenção e uma ferramenta de medição, não como um substituto para a reparação de computadores infectados.
Transformando ocorrências de sinkhole em pistas de dispositivos infectados
Um cliente que consulta repetidamente um domínio de comando e controle (C2) bloqueado merece atenção. O padrão pode fornecer uma pista útil mesmo quando você não possui um agente de endpoint, inspeção de payload ou registros detalhados de firewall.
A dependência é importante: o artigo de defesa contra botnets da Universidade do Arizona explica que o redirecionamento eficaz de DNS exige a identificação da infraestrutura de C2 da botnet e a cooperação do operador de DNS que a botnet utiliza. Uma correspondência mostra que uma solicitação específica encontrou sua política, e não que você descobriu todos os caminhos de comunicação.
Mantenha contexto suficiente para localizar o cliente
Registre esses campos juntos, em vez de dispersá-los em painéis desconectados:
- Carimbo de data/hora: Correlacione o evento com concessões de rede e registros de autenticação.
- SSID ou VLAN: Identifique a rede e o limite de política envolvidos.
- Identificador do cliente: Preserve uma referência de dispositivo útil, não apenas o endereço público do local.
- Domínio consultado: Mantenha o nome de host exato que acionou a regra.
- Categoria da política: Distinga uma classificação de ameaça de uma restrição de conteúdo.
- Ação de resposta: Registre se o resolvedor redirecionou, recusou ou retornou NXDOMAIN.
Um IP de origem público pode representar muitos convidados atrás do mesmo gateway. Para identificar um dispositivo individual, correlacione as observações de endpoint com registros de rede e do resolvedor. Não rotule todo o local como infectado apenas porque um coletor vê seu endereço compartilhado.
Regra de investigação: Trate uma ocorrência de sinkhole como uma pista com contexto de suporte, não como um veredito automático contra o proprietário do dispositivo.
Valide o sinal e mantenha a cobertura
Compare acessos repetidos com o comportamento normal nessa rede e verifique a classificação com base em feeds de inteligência contra ameaças atualizados. Domínios gerados, hospedagem que muda rapidamente, endereços codificados de forma rígida (hard-coded) e canais de fallback podem deixar lacunas. A ausência de acessos não é prova de que um dispositivo esteja limpo.
O status do domínio também precisa de revisão contínua. Um estudo acadêmico de 2019 sobre desativações de domínios maliciosos descobriu que mais de 14% dos domínios desativados durante os dez meses anteriores retornaram posteriormente ao mercado comercial de domínios.
Revise a procedência, a propriedade e a classificação das regras periodicamente. Se você mesmo opera domínios de sinkhole registrados, proteja a configuração de DNS e as renovações desses domínios. Restrinja o acesso aos logs em nível de cliente e defina períodos de retenção compatíveis com a legislação local e suas necessidades de investigação.
Modelos de implantação para redes compartilhadas e de convidados
Um sinkhole protege o caminho de DNS que você controla. O navegador ou aplicativo de um convidado pode selecionar um resolvedor criptografado externo, deixando sua política local sem nada para avaliar.
Uma análise técnica do DNS criptografado explica por que o DNS-over-HTTPS externo pode ignorar o monitoramento de DNS convencional. A decisão de implantação refere-se, portanto, ao cumprimento de regras do resolvedor e ao comportamento do cliente, e não apenas à qualidade de uma lista de bloqueio.
Modelos de implantação de sinkhole para redes compartilhadas
| Modelo | Onde fica o controle | Melhor aplicação | Principal limitação |
|---|---|---|---|
| Resolvedor de rede no WiFi para visitantes WiFi | Resolvedor fornecido a cada cliente pela rede | Hotéis, bares, WiFi para visitantes público WiFi | Clientes com resolvedor próprio codificado ou criptografado podem ignorá-lo |
| Inspeção de DNS no firewall | Dentro de um firewall ou gateway existente | Escritórios com uma infraestrutura de firewall estabelecida | A inspeção de DNS convencional não detecta DoH externo trafegado como HTTPS |
| Política de dispositivos ou navegadores gerenciados | O navegador ou SO define o resolvedor e desativa o DoH alternativo | Dispositivos corporativos ou escolares gerenciados | Não alcança dispositivos pessoais não gerenciados |
| DNS de proteção em nuvem | Resolvedor hospedado pelo provedor para o qual o DNS da rede aponta | Locais e infraestruturas com múltiplos pontos | Depende da disponibilidade do provedor e do acesso à telemetria |
Criptografia e aplicação de políticas são escolhas separadas
O DNS criptografado melhora a confidencialidade entre o cliente e o resolvedor. Ele não enfraquece necessariamente a filtragem: um resolvedor de proteção aprovado pode aceitar consultas criptografadas e ainda assim aplicar a política. O problema de visibilidade surge quando o cliente escolhe um resolvedor externo que não aplica as suas regras.
Para dispositivos gerenciados, as políticas do navegador e do sistema operacional podem especificar o serviço aprovado. Em redes de convidados, você precisa de um posicionamento documentado sobre DNS criptografado alternativo, privacidade do usuário e exceções permitidas. Bloquear todo o tráfego web criptografado para interromper o DoH não é uma estratégia geral viável.
Posicione o controle em um limite que você possa testar
Distribua o resolutor aprovado por meio da configuração de rede. Restrinja o DNS convencional de saída direta aos resolutores aprovados, cobrindo ambos os protocolos de transporte e ambas as famílias de IP. O redirecionamento transparente pode capturar o DNS convencional enviado para outros locais, mas não resolve de forma transparente o DNS criptografado arbitrário.
Use a segmentação de rede para separar as políticas de funcionários, convidados e dispositivos especializados. Uma regra restritiva para convidados não deve interromper equipamentos clínicos ou aplicativos da equipe.
- Teste a resolução comum: confirme se as aplicações permitidas continuam funcionando.
- Teste os caminhos de bypass: verifique os resolutores selecionados pelo navegador e outros túneis permitidos.
- Teste a atribuição: confirme se uma correspondência de política controlada é exibida na rede e no cliente corretos.
Uma alteração de DNS no nível de rede pode aplicar filtragem em todos os dispositivos participantes sem a necessidade de instalar software em cada um deles. Comprove a cobertura com testes, em vez de presumir que a distribuição de um endereço de resolvedor força todos os aplicativos a usá-lo.
Falsos positivos e como se recuperar rapidamente
Uma lista de bloqueio mais longa não é automaticamente mais segura. Uma regra ampla contra infraestrutura em nuvem compartilhada pode interromper portais de fornecedores, fluxos de trabalho de pagamento ou aplicativos de aprendizado sem melhorar a proteção contra a ameaça pretendida.
Um estudo de implementação de sinkholing de 2025 relatou falsos positivos que exigiram gerenciamento manual de listas de permissões e equipe treinada. A responsabilidade operacional pertence ao plano de implantação, não apenas à fila de incidentes.
O processo de recuperação deve levar em consideração serviços compartilhados e exceções de escopo restrito.
Restaure o acesso sem remover a proteção
Inicie novas políticas no modo apenas de registro por um período de observação acordado. Capture o cliente, a categoria e a regra correspondente para que decisões posteriores tenham um histórico de evidências.
Sintomas de sinkhole, causas prováveis e primeiras ações
| Sintoma | Causa provável | Primeira ação |
|---|---|---|
| O dispositivo de um funcionário não consegue acessar o site de um fornecedor | Domínio em nuvem compartilhado bloqueado por categoria | Verifique a categoria registrada e, em seguida, adicione à lista de permissões o host exato, não o domínio inteiro |
| Um dispositivo de visitante gera acessos ao sinkhole a cada minuto | Dispositivo infectado ou aplicativo agressivo tentando novamente | Identifique e contenha o cliente e, em seguida, providencie a inspeção do dispositivo |
| Pico de consultas bloqueadas após uma alteração de política | Entrada ampla na lista de bloqueio ou regra com caractere curinga | Reverta a última alteração e revise seu escopo de SSID ou VLAN |
| Os aplicativos funcionam, mas um SSID não mostra bloqueios | Os clientes podem estar usando DNS criptografado fora do resolvedor | Execute um teste de política controlado e inspecione a configuração do resolvedor e os caminhos de DNS de saída |
Um relatório vazio por si só não comprova uma evasão. A rede pode simplesmente não ter gerado solicitações correspondentes.
Meça conexões prejudiciais evitadas, taxa de falsos positivos, tempo de resolução de recursos e exceções por local. O volume de consultas bloqueadas sozinho pode aumentar porque um aplicativo tenta a conexão repetidamente.
Antes de ativar uma regra, confirme:
- Classificação: A categoria de ameaça do domínio é compatível.
- Uso compartilhado: Os aplicativos corporativos não dependem do mesmo host ou domínio pai.
- Reversão: A política anterior e o procedimento de restauração estão registrados.
- Escopo: O SSID ou VLAN pretendido é explícito.
- Propriedade: Uma pessoa nomeada gerencia as solicitações de exceção e analisa sua expiração.
Decida se um sinkhole é adequado para a sua rede
Para um escritório pequeno com endpoints gerenciados, comece com o registro de logs de DNS e a política de endpoints. É possível que você já tenha os controles de dispositivo necessários para investigar solicitações suspeitas diretamente, portanto, evite adicionar um coletor que não possa manter.
Para redes de convidados, públicas ou de estudantes, priorize a aplicação de limites e a atribuição de clientes. Dispositivos não gerenciados tornam os controles em nível de resolvedor úteis, mas um operador ainda precisa de uma maneira segura de investigar ou conter um dispositivo sem acusar seu proprietário prematuramente.
Adeque o modelo operacional à infraestrutura existente
Uma organização com vários locais se beneficia de uma política de resolvedores gerenciada centralmente, exceções específicas de rede e relatórios consolidados. Compare os serviços com base nas evidências que eles apresentam e nos controles que você pode testar, e não apenas na contagem de categorias.
Escolha um sinkhole quando puder ser o proprietário de todo o processo: política, cobertura, investigação, exceções e recuperação.
Comece com uma implantação limitada:
- Mapeie o caminho do resolvedor. Identifique qual resolvedor cada rede usa e onde DNS alternativos ou túneis poderiam escapar da política.
- Execute um período de observação documentado apenas para registro de logs. Registre as solicitações correspondentes com seus respectivos clientes, categorias e redes; em seguida, revise as dependências legítimas de aplicativos.
- Ative primeiro os bloqueios de alta confiança. Comece com destinos confirmados de C2 e malware, mantenha um plano de reversão por escrito e atribua um responsável pelas exceções.
Mantenha a remediação do endpoint separada da contenção da rede. Um retorno de chamada (callback) bloqueado é uma intervenção bem-sucedida, mas o dispositivo ainda precisa de investigação. Sua implantação estará pronta quando a equipe puder demonstrar tanto um bloqueio controlado quanto uma restauração segura do acesso legítimo.
O Purple Shield oferece DNS protetivos com políticas e relatórios específicos da rede, para que você possa avaliar o bloqueio de domínios maliciosos juntamente com as evidências necessárias para gerenciá-lo. Visite Purple Shield para agendar um teste gratuito de 30 dias, aponte o DNS da sua rede para o Shield e teste a filtragem em sua rede em uso sem novos hardwares ou agentes de dispositivo.