Um servidor DNS que responde a todas as solicitações sem distinção, com portas abertas por padrão que ninguém revisou desde a implementação: encontramos esse padrão na maioria das redes corporativas. A segurança da rede muitas vezes se concentra nesses dois eixos negligenciados, a gestão de DNS e o controle das portas TCP, muito antes da compra de um firewall de nova geração.
Controle dos resolvedores DNS: a primeira barreira a ser imposta na rede
No campo, o problema começa quase sempre no mesmo lugar. Os postos de trabalho e os objetos conectados enviam suas solicitações DNS para qualquer resolvedor, incluindo resolvedores públicos que o administrador não supervisiona. Enquanto não restringirmos os resolvedores autorizados, deixamos um canal de saída invisível.
A primeira ação consiste em forçar todo o tráfego DNS para um resolvedor interno controlado. Bloqueamos as solicitações de saída nas portas UDP e TCP 53 para qualquer destino que não seja esse resolvedor. Isso permite registrar cada solicitação, detectar domínios suspeitos e cortar as comunicações com servidores de comando e controle (C2).
A criptografia DNS complica essa abordagem. DNS over HTTPS (DoH) utiliza a porta TCP 443, a mesma do tráfego web clássico, o que a torna difícil de filtrar com regras de rede tradicionais. DNS over TLS (DoT) passa pela porta TCP 853, mais facilmente identificável.
Para manter o controle, podemos aprender o funcionamento do Open Syd e escolher uma estratégia adequada: permitir DoT na porta 853 para o resolvedor interno enquanto bloqueamos DoH nos postos para evitar que os navegadores contornem a política DNS da organização.
Portas TCP abertas: auditar antes de filtrar
Regularmente vemos servidores com dezenas de portas em escuta, algumas das quais correspondem a serviços instalados por padrão e nunca utilizados. Cada porta aberta é uma superfície de ataque potencial. O reflexo é escanear seu próprio perímetro antes que um atacante o faça.
Uma auditoria das portas TCP e UDP ativas, realizada a partir do exterior da rede, frequentemente revela serviços esquecidos: uma interface de administração em uma porta não padrão, um serviço de banco de dados exposto, um antigo servidor de e-mail ainda acessível. Fechar uma porta desnecessária reduz o risco de forma mais eficaz do que uma regra de detecção.
Priorizar o fechamento por nível de risco
Nem todas as portas abertas apresentam o mesmo perigo. Aqui está uma abordagem de triagem pragmática:
- As portas relacionadas à administração remota (SSH na 22, RDP na 3389, interfaces web na 8080 ou 8443) devem ser restritas a intervalos de IP internos ou acessíveis apenas via VPN. Deixá-las expostas na Internet continua sendo a principal causa de comprometimento por força bruta.
- As portas de serviços de e-mail (25, 465, 587, 993) merecem um filtragem geográfica rigorosa se a atividade for local, e uma verificação de que os protocolos de criptografia TLS estão ativados para proteger os dados em trânsito.
- As portas utilizadas por protocolos não criptografados (Telnet na 23, FTP na 21, HTTP na 80) devem ser desativadas em favor de seus equivalentes seguros. Se um serviço legado exigir sua manutenção, isolamos esse serviço em um segmento de rede dedicado.
Registro DNS e correlação com os fluxos TCP
Bloquear e filtrar não é suficiente se nunca olharmos o que está acontecendo. O registro das solicitações DNS, cruzado com os logs de conexão nas portas TCP, constitui uma ferramenta de detecção formidável e subutilizada.
Um posto que resolve um nome de domínio incomum e, em seguida, abre uma conexão TCP de saída para um endereço IP desconhecido em uma porta alta, produz um sinal fraco. Tomados isoladamente, cada evento parece inócuo. É a correlação entre a solicitação DNS e o fluxo TCP que revela a exfiltração.
O guia NIST SP 800-81 Revisão 3, publicado em 19 de março de 2026, enfatiza essa noção de visibilidade operacional. Ele agrupa DoH, DoT e DoQ sob a categoria “DNS criptografado” e recomenda tratar o DNS não mais como uma simples infraestrutura de fundo, mas como um ponto de controle de segurança por si só.
O que o registro deve capturar
Para ser utilizável, um registro DNS deve registrar no mínimo o nome de domínio solicitado, o endereço IP de origem, o timestamp e a resposta retornada. Do lado das portas TCP, mantemos as conexões estabelecidas, recusadas e as tentativas de conexão abortadas. Os retornos variam sobre a duração de retenção ideal, mas o regulamento de execução europeu 2024/2690, aplicável desde 7 de novembro de 2024, impõe a alguns provedores de serviços DNS e de infraestrutura um registro contínuo com prova de eficácia dos controles.
DNSSEC e criptografia: proteger a integridade das respostas DNS
Um resolvedor que responde corretamente não garante que a resposta não foi alterada no caminho. O envenenamento de cache DNS redireciona os usuários para servidores fraudulentos sem que nenhum alerta seja acionado do lado da rede. O DNSSEC adiciona uma assinatura criptográfica aos registros de zona para validar sua autenticidade.
O DNSSEC valida a origem das respostas, a criptografia DNS protege sua confidencialidade em trânsito: os dois mecanismos se complementam, nenhum substitui o outro.
Na prática, implantar DNSSEC em suas zonas internas exige gerenciar a renovação das chaves criptográficas. Uma chave expirada sem rotação programada provoca uma falha de resolução tão brusca quanto um ataque. Automatizamos a rotação ou não implantamos.
Política de segurança da rede: conectar DNS e portas em uma abordagem unificada
Tratar os DNS de um lado e as portas do outro cria pontos cegos. Um serviço autorizado pelo firewall, mas que resolve domínios maliciosos, passará despercebido. Inversamente, um bloqueio DNS sem controle das portas deixa a porta aberta para conexões diretas por endereço IP.
A abordagem coerente conecta as três camadas:
- O resolvedor DNS interno filtra os domínios e registra as solicitações.
- O firewall restringe as portas TCP e UDP apenas aos serviços declarados e mantidos.
- Uma ferramenta de correlação (SIEM ou um simples script de análise de logs) cruza os eventos DNS e as conexões de rede para identificar comportamentos anômalos.
Essa articulação não exige um orçamento considerável. Um resolvedor filtrante, regras de firewall revisadas trimestralmente e uma pilha de logs consultada toda semana cobrem a maioria das vulnerabilidades relacionadas aos DNS e às portas. O elo mais frágil não é a ferramenta, é a regularidade da revisão.
