DNS Sinkhole Explicado: Como Bloqueia Chamadas Maliciosas
Um DNS sinkhole redireciona as consultas de malware para um recetáculo falso, bloqueando chamadas e revelando dispositivos infetados. Saiba como funciona e onde o implementar.
Published 2 de novembro de 2026
Um cliente liga um portátil à WiFiWiFi do seu café, abre um navegador e prossegue com o seu dia. Em segundo plano, o malware nesse portátil tenta contactar o seu controlador. Não pode instalar software de segurança no dispositivo de cada visitante, mas pode controlar a forma como a sua rede responde aos pedidos desse dispositivo para destinos da internet.
Um DNS sinkhole oferece uma forma de interromper essa chamada de retorno (callback) e registar provas valiosas para investigação. A questão útil não é apenas o que ele bloqueia. É se consegue identificar o dispositivo afetado, provar que a sua política se aplica e restaurar o acesso legítimo quando uma regra comete um erro.
Índice
- 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
- Transformar acessos ao Sinkhole em pistas de dispositivos infetados
- Modelos de implementação para redes partilhadas e de visitantes
- Falsos positivos e como recuperar rapidamente
- Decida se um Sinkhole se adequa à sua rede
O que é um DNS Sinkhole em termos simples
O portátil infetado precisa de encontrar o seu controlador antes de poder solicitar instruções. Se o malware utilizar um nome de domínio, o portátil pede primeiro a um resolvedor de DNS para traduzir esse nome num endereço IP.
Pense no DNS como uma lista telefónica. O domínio é o nome que pesquisa e o endereço IP é o número para o qual precisa de ligar. Um resolvedor de proteção verifica se deve fornecer esse número.
Um DNS sinkhole substitui a resposta de um domínio sabidamente malicioso por um destino controlado, ou bloqueia a resposta, impedindo que o dispositivo utilize essa pesquisa para alcançar o atacante.
Em sentido estrito, o sinkholing significa redirecionar o tráfego para um ponto de extremidade controlado. Os administradores também utilizam 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 pesquisa do nome da ligação que se lhe segue.
O bloqueio de DNS não é o mesmo que o bloqueio de IP
Um DNS sinkhole atua sobre o nome solicitado antes de o dispositivo utilizar a resposta para contactar esse destino. Uma regra de firewall comum avalia os pacotes, frequentemente utilizando o respetivo endereço IP de destino, podendo rejeitar a tentativa de ligação inicial. Uma firewall não tem de esperar por uma ligação estabelecida.
Essa distinção é importante quando serviços legítimos e maliciosos partilham a mesma infraestrutura de alojamento. Bloquear um endereço IP inteiro pode afetar serviços não relacionados, ao passo que uma política de DNS pode ter como alvo um nome de anfitrião específico. Nenhuma das abordagens substitui a outra.
Em WiFi partilhados, o resolutor é útil porque o operador não precisa de acesso administrativo ao portátil. No entanto, interromper uma chamada de retorno não remove a infeção. Dá ao operador uma oportunidade de contenção e, com os registos adequados, uma pista para a investigação.
Como um sinkhole responde a uma pesquisa maliciosa
Uma pesquisa de DNS é um pedido de informação, não uma ligação ao website solicitado. A resposta do resolvedor determina o que o dispositivo pode tentar a seguir.
O caminho básico separa o dispositivo, a verificação da política e o destino controlado.
- O dispositivo solicita o seu domínio de callback. Envia uma consulta para o resolvedor configurado.
- O resolvedor identifica que política se aplica à rede de origem, como uma SSID de convidados ou VLAN de funcionários.
- O nome é verificado em relação a informações sobre ameaças e regras locais, incluindo categorias de comando e controlo, phishing e malware.
- Numa correspondência de bloqueio, o resolvedor fornece um endereço controlado, devolve uma resposta de nome inexistente, ou recusa ou suprime a resposta.
- O dispositivo tenta uma ligação ao engodo ou não consegue obter um destino útil. Os nomes permitidos são resolvidos normalmente.
Antes de um dispositivo abrir um site ou aplicação, pergunta ao DNS onde o encontrar, e o Shield responde utilizando a política definida para essa rede. Se um domínio estiver bloqueado, a ligação a esse destino nunca se inicia e o dispositivo apresenta a página de bloqueio personalizada do cliente. Essa experiência do utilizador não deve ser confundida com malware a tentar novamente uma chamada de retorno com falha.
Escolha a resposta adequada às evidências de que necessita
Opções de resposta do sinkhole e o que cada uma revela
| Resposta | O que o dispositivo experiencia | O que os defensores aprendem | Principal compromisso |
|---|---|---|---|
| Nome inexistente (NXDOMAIN) | A pesquisa falha e a ligação nunca é iniciada | Que uma pesquisa foi tentada e bloqueada | Interrompe o callback, mas não fornece comportamento de ligação subsequente |
| Endereço de sinkhole | A pesquisa devolve o endereço de um servidor controlado | IP de origem, temporização do callback, padrão de nova tentativa e protocolo observável | Requer um ponto final monitorizado e um armazenamento cuidadoso dos registos |
| Resposta recusada ou suprimida | O resolvedor recusa a consulta ou deixa-a sem resposta | Pouco além da própria tentativa, a menos que o registo do resolvedor esteja ativo | Rápido de aplicar, mas alguns clientes tentam novamente de forma agressiva |
O NXDOMAIN não apaga as informações de origem ou de carimbo de data/hora. Um resolvedor pode registar ambas. O que não consegue recolher dessa pesquisa com falha é a ligação que o malware teria feito a seguir.
Uma avaliação de captura de pacotes sinkhole revista por pares registou uma melhoria de cinco vezes na captura de pacotes maliciosos com uma conceção de recolha avançada em comparação com uma implementação convencional. Trata-se de uma evidência sobre a arquitetura de recolha, não de uma promessa de que todos os sinkholes proporcionarão a mesma melhoria.
Este vídeo oferece outra forma de acompanhar o mecanismo.
A resposta que escolher determina o comportamento subsequente que pode observar. Mantenha os recolhedores isolados e não assuma que o redirecionamento produzirá uma página de aviso limpa para todas as aplicações encriptadas.
O surto do Conficker que tornou os sinkholes num padrão
O Conficker demonstrou como os defensores podiam transformar a pesquisa de instruções por parte de malware numa fonte de inteligência. Em vez de inspecionarem cada computador infetado, os investigadores intercetaram os destinos que o worm estava programado para contactar.
O arquivo Conficker da CAIDA descreve o surto detetado pela primeira vez em novembro de 2008, com as primeiras variantes a gerarem aproximadamente 250 nomes de domínio pseudoaleatórios por dia. O worm contactava os nomes gerados via HTTP para obter instruções ou malware adicional.
Investigadores e operadores de rede registaram domínios selecionados antes que os criminosos os pudessem utilizar, apontando depois esses nomes para servidores controlados. Consequentemente, os computadores infetados contactavam a infraestrutura gerida pelos defensores.
A pesquisa tornou-se um ponto de medição
Essas chamadas de retorno ajudaram os equipas de resposta a identificar sistemas infetados, a estimar a propagação do worm e a acompanhar o progresso da limpeza sem comunicar diretamente com a rede de comando criminosa. Assim, uma interceção bem-sucedida fez mais do que negar uma atualização: registou um computador que ainda tentava obter uma.
- Para efeitos de contenção, as equipas de resposta impediram que determinados nomes conduzissem a infraestruturas controladas por atacantes.
- Para efeitos de investigação, os registos de callback identificaram os sistemas que necessitavam de atenção.
- Para o acompanhamento da resolução, a continuidade dos callbacks indicava que a limpeza permanecia incompleta.
As variantes posteriores do Conficker expandiram o conjunto de nomes gerados e adicionaram atualizações peer-to-peer. As equipas de resposta tiveram de coordenar o registo e o bloqueio, em vez de dependerem de uma lista pequena e estática.
A implementação histórica também diferia da política de filtragem local de uma organização. Os investigadores alteravam os destinos dos domínios que controlavam, afetando computadores infetados que resolviam esses nomes através de DNS comum. Em contrapartida, um operador de espaço aplica geralmente a política no seu próprio resolutor recursivo.
A cobertura foi a limitação em ambos os casos. Os defensores podiam intercetar callbacks para nomes sob o seu controlo, mas isso não significava que todas as rotas de atualização possíveis tivessem desaparecido. O Conficker estabeleceu o sinkholing quer como uma técnica de contenção quer como uma ferramenta de medição, não como um substituto para a reparação de computadores infetados.
Converter ocorrências no sinkhole em pistas de dispositivos infetados
Um cliente que consulte repetidamente um domínio de comando e controlo (C2) bloqueado merece atenção. O padrão pode fornecer uma pista útil mesmo quando não dispõe de um agente de endpoint, inspeção de payload ou registos detalhados de firewall.
A dependência é importante: o artigo da Universidade do Arizona sobre defesa contra botnets explica que um redirecionamento de DNS eficaz requer a identificação da infraestrutura de C2 da botnet e a cooperação do operador de DNS que a botnet utiliza. Uma ocorrência mostra que um pedido específico encontrou a sua política, não que descobriu todos os caminhos de comunicação.
Mantenha contexto suficiente para localizar o cliente
Registe estes campos em conjunto, em vez de os dispersar por painéis de controlo desligados entre si:
- Carimbo de data/hora: Correlacione o evento com os registos de concessão e autenticação de rede.
- SSID ou VLAN: Identifique a rede e o limite de política envolvidos.
- Identificador de cliente: Preserve uma referência de dispositivo útil, e não apenas o endereço público do local.
- Domínio consultado: Conserve o nome de anfitrião 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: Registe 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 do endpoint com os registos do resolvedor e da rede. Não rotule todo o local como infetado apenas porque um coletor deteta o seu endereço partilhado.
Regra de investigação: Trate uma ocorrência num sinkhole como uma pista com contexto de suporte, e não como um veredito automático contra o proprietário do dispositivo.
Valide o sinal e mantenha a cobertura
Compare os acessos repetidos com o comportamento normal nessa rede e verifique a classificação face a feeds de inteligência de ameaças atualizados. Domínios gerados, alojamento com alterações rápidas, endereços codificados no código-fonte e canais de recurso podem deixar lacunas. A ausência de acessos não é prova de que um dispositivo esteja limpo.
O estado do domínio também necessita de uma revisão contínua. Um estudo académico de 2019 sobre a desativação de domínios maliciosos revelou que mais de 14% dos domínios desativados durante os dez meses anteriores tinham regressado posteriormente ao mercado comercial de domínios.
Reveja a proveniência, a titularidade e a classificação das regras de forma programada. Se opera domínios de sinkhole registados, proteja a sua configuração de DNS e as respetivas renovações. Restrinja o acesso aos registos ao nível do cliente e defina períodos de retenção coerentes com a legislação local e as suas necessidades de investigação.
Modelos de implementação para redes partilhadas e de convidados
Um sinkhole protege o caminho de DNS que controla. O navegador ou a aplicação de um convidado pode selecionar, em alternativa, um resolvedor encriptado externo, deixando a sua política local sem nada para avaliar.
Uma análise técnica do DNS encriptado explica a razão pela qual o DNS-over-HTTPS externo pode contornar a monitorização convencional de DNS. A decisão de implementação prende-se, portanto, com a aplicação do resolver e o comportamento do cliente, e não meramente com a qualidade de uma lista de bloqueio.
Modelos de implementação de sinkholes para redes partilhadas
| Modelo | Onde reside o controlo | Melhor aplicação | Principal limitação |
|---|---|---|---|
| Resolvedor de rede no WiFi | Resolvedor fornecido pela rede a cada cliente | Hotéis, pubs, WiFi público | Clientes com o seu próprio resolvedor encriptado ou predefinido podem contorná-lo |
| Inspeção de DNS na firewall | Dentro de uma firewall ou gateway existente | Escritórios com uma infraestrutura de firewall estabelecida | A inspeção tradicional de DNS não deteta DoH externo transportado como HTTPS |
| Política de dispositivos ou navegador gerido | O navegador ou SO define o resolvedor e desativa o DoH alternativo | Dispositivos corporativos ou escolares geridos | Não abrange dispositivos pessoais não geridos |
| DNS de proteção na nuvem | Resolvedor alojado pelo fornecedor para o qual o DNS da rede aponta | Espaços e infraestruturas com múltiplos locais | Depende da disponibilidade do fornecedor e do acesso à telemetria |
A encriptação e a aplicação de políticas são escolhas distintas
O DNS encriptado melhora a confidencialidade entre o cliente e o resolver. Não enfraquece necessariamente a filtragem: um resolver de proteção aprovado pode aceitar consultas encriptadas e continuar a aplicar a política. O problema de visibilidade surge quando o cliente escolhe um resolver externo que não aplica as suas regras.
Para dispositivos geridos, as políticas do navegador e do sistema operativo podem especificar o serviço aprovado. Em redes de convidados, precisa de uma posição documentada sobre DNS encriptado alternativo, privacidade do utilizador e exceções permitidas. Bloquear todo o tráfego web encriptado para parar o DoH não é uma estratégia geral viável.
Coloque o controlo num limite que possa testar
Distribua o resolutor aprovado através da configuração de rede. Restrinja o DNS convencional de saída direta a resolutores aprovados, abrangendo ambos os protocolos de transporte e ambas as famílias de IP. O redirecionamento transparente pode capturar o DNS convencional enviado para outro local, mas não resolve de forma transparente o DNS encriptado arbitrário.
Utilize a segmentação de rede para separar as políticas de funcionários, de convidados e de dispositivos especializados. Uma regra restritiva para convidados não deve interromper equipamentos clínicos ou aplicações do pessoal.
- Testar a resolução regular: Confirme se as aplicações permitidas continuam a funcionar.
- Testar caminhos de bypass: Verifique os resolutores selecionados pelo navegador e outros túneis permitidos.
- Testar a atribuição: Confirme se uma correspondência de política controlada aparece para a rede e o cliente corretos.
Uma alteração de DNS ao nível da rede pode aplicar filtragem em todos os dispositivos participantes sem a necessidade de instalar software em cada um. Comprove a cobertura com testes, em vez de presumir que a distribuição de um endereço de resolvedor obriga todas as aplicações a utilizá-lo.
Falsos positivos e como recuperar rapidamente
Uma lista de bloqueio mais longa não é automaticamente mais segura. Uma regra abrangente contra infraestruturas de nuvem partilhadas pode interromper portais de fornecedores, fluxos de trabalho de pagamento ou aplicações de aprendizagem sem melhorar a proteção contra a ameaça pretendida.
Um estudo de implementação de sinkholing de 2025 reportou falsos positivos que exigiram a gestão manual de listas de permissões e pessoal qualificado. A responsabilidade operacional pertence ao plano de implementação, e não apenas à fila de incidentes.
O processo de recuperação deve ter em conta serviços partilhados e exceções de âmbito restrito.
Restabelecer o acesso sem remover a proteção
Inicie novas políticas no modo de registo exclusivo durante um período de observação acordado. Registe o cliente, a categoria e a regra correspondente para que as decisões posteriores disponham de 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 aceder ao site de um fornecedor | Domínio de nuvem partilhado bloqueado por categoria | Verifique a categoria registada e, em seguida, adicione à lista de permissões o anfitrião exato, e não todo o domínio |
| Um dispositivo de convidado aciona registos de sinkhole a cada minuto | Dispositivo infetado ou aplicação agressiva a tentar novamente | Identifique e isole o cliente e, em seguida, agende a inspeção do dispositivo |
| Pico de consultas bloqueadas após uma alteração de política | Entrada abrangente na lista de bloqueio ou regra com caráter universal (wildcard) | Reverta a última alteração e reveja o seu âmbito de SSID ou VLAN |
| As aplicações funcionam, mas um SSID não mostra bloqueios | Os clientes podem estar a utilizar DNS encriptado 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 confirma um desvio. É possível que a rede simplesmente não tenha gerado pedidos correspondentes.
Meça as ligações nocivas evitadas, a taxa de falsos positivos, o tempo de resolução de recursos e as exceções por local. O volume de consultas bloqueadas pode aumentar isoladamente apenas porque uma aplicação faz tentativas repetidas.
Antes de ativar uma regra, confirme:
- Classificação: A categoria de ameaça do domínio é suportada.
- Uso partilhado: As aplicações empresariais não dependem do mesmo anfitrião ou domínio pai.
- Reversão: A política anterior e o procedimento de restauração estão registados.
- Âmbito: O SSID ou VLAN pretendido é explícito.
- Titularidade: Uma pessoa nomeada gere os pedidos de exceção e revê a sua expiração.
Decida se um sinkhole se adequa à sua rede
Para um pequeno escritório com pontos de extremidade geridos, comece com o registo de DNS e a política de pontos de extremidade. É possível que já disponha dos controlos de dispositivo necessários para investigar diretamente pedidos suspeitos, pelo que deve evitar adicionar um recolhedor que não consiga manter.
Para redes de convidados, públicas ou de estudantes, priorize a aplicação de limites e a atribuição de clientes. Os dispositivos não geridos tornam os controlos ao nível do resolvedor úteis, mas um operador continua a precisar de uma forma segura de investigar ou conter um dispositivo sem acusar prematuramente o seu proprietário.
Ajuste o modelo de operação à infraestrutura
Uma organização com múltiplos locais beneficia de uma política de resolução gerida centralmente, exceções específicas por rede e relatórios consolidados. Compare os serviços com base nas evidências que expõem e nos controlos que pode testar, e não apenas nas respetivas contagens de categorias.
Escolha um sinkhole quando puder assumir a totalidade do processo: política, cobertura, investigação, exceções e recuperação.
Comece com uma implementação limitada:
- Mapeie o caminho do resolvedor. Identifique que resolvedor cada rede utiliza e onde DNS alternativos ou túneis poderiam escapar à política.
- Execute um período de observação documentado apenas para registo. Registe os pedidos correspondentes com o respetivo cliente, categoria e rede e, em seguida, reveja as dependências legítimas das aplicações.
- Ative primeiro os bloqueios de elevada 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 de rede. Um callback bloqueado é uma intervenção bem-sucedida, mas o dispositivo ainda necessita de investigação. A sua implementação está pronta quando a equipa conseguir demonstrar um bloqueio controlado e uma restauração segura do acesso legítimo.
Purple Shield oferece DNS de proteção com políticas e relatórios específicos por rede, para que possa avaliar o bloqueio de domínios maliciosos juntamente com as evidências necessárias para o gerir. Visite Purple Shield para agendar um teste gratuito de 30 dias, aponte o DNS da sua rede para o Shield e teste a filtragem na sua rede em tempo real sem novo hardware ou agentes de dispositivo.