O DNS associa um nome de domínio legível a um endereço IP utilizável pelos equipamentos de rede. As portas TCP, por sua vez, determinam quais serviços aceitam ou rejeitam uma conexão de entrada. Esses dois mecanismos, muitas vezes configurados uma vez e depois esquecidos, constituem, no entanto, vetores de ataque privilegiados quando mal geridos.
Resolução DNS e superfície de ataque: o que muda com a criptografia
Por padrão, as requisições DNS circulam em texto claro na porta UDP 53. Um atacante posicionado na rede pode interceptar essas requisições, modificá-las ou redirecionar o tráfego para um servidor malicioso. O filtragem DNS clássica baseia-se justamente nessa visibilidade: o administrador inspeciona as requisições para bloquear os domínios perigosos.
A chegada do DNS over HTTPS (DoH) altera esse equilíbrio. O DoH encapsula as requisições DNS em tráfego HTTPS padrão, na porta TCP 443. O conteúdo das requisições torna-se invisível para as ferramentas de supervisão de rede. Um dispositivo configurado para usar um resolvedor DoH externo pode, assim, contornar toda a filtragem DNS da empresa sem acionar um alerta.
A solução não consiste em bloquear o DoH cegamente. A abordagem recomendada é definir um resolvedor DNS autorizado internamente, compatível com DoH ou DoT (DNS over TLS, porta 853), e forçar seu uso nos dispositivos por meio de políticas de grupo ou um MDM.
As requisições para resolvedores externos não aprovados são então bloqueadas no nível do firewall. Essa configuração preserva a confidencialidade das trocas DNS enquanto mantém a capacidade de filtragem, como detalha o guia de segurança no Open Syd em sua seção dedicada ao endurecimento das políticas de rede.
Portas TCP abertas: reduzir a superfície exposta da rede
Cada porta TCP aberta em um servidor representa um ponto de entrada potencial. Um serviço que escuta em uma porta não utilizada ou não monitorada oferece uma oportunidade direta a um atacante para tentar uma conexão, explorar uma vulnerabilidade ou estabelecer um canal de comando.
Identificar as portas realmente necessárias
A primeira etapa é um inventário. Muitos ambientes mantêm portas abertas herdadas de configurações antigas: serviços de teste, interfaces de administração temporárias, protocolos obsoletos. Uma varredura regular das portas expostas, a partir do exterior da rede, frequentemente revela serviços cuja existência ninguém suspeitava.
As portas a serem monitoradas prioritariamente:
- A porta 53 (DNS) deve ser restrita apenas aos servidores DNS internos autorizados, e o tráfego DNS de saída para resolvedores externos não aprovados bloqueado no firewall
- A porta 443 (HTTPS) merece uma inspeção especial, uma vez que o DoH transita por ela, tornando possível a exfiltração de dados ou o contorno de políticas de segurança
- As portas de administração remota (22 para SSH, 3389 para RDP) nunca devem ser expostas diretamente na internet sem um gateway intermediário ou VPN
- As portas associadas a serviços legados (Telnet na porta 23, FTP na porta 21) devem ser desativadas em favor de seus equivalentes criptografados
Aplicar o princípio do menor privilégio aos fluxos de rede
Cada regra de firewall deve especificar uma fonte, um destino e uma porta específica. As regras “qualquer para qualquer” em uma porta determinada equivalem a deixar uma porta aberta para qualquer um que conheça o endereço. A segmentação de rede complementa essa abordagem: colocar os servidores DNS em um segmento dedicado limita a propagação lateral em caso de comprometimento.
DNSSEC e proteção da conta DNS: duas camadas complementares
DNSSEC assina criptograficamente as respostas DNS para garantir que a informação recebida pelo cliente corresponde àquela publicada pelo servidor legítimo. Sem essa validação, um atacante pode injetar respostas falsas (envenenamento de cache) e redirecionar o tráfego para servidores maliciosos sem que o usuário perceba qualquer coisa.
A implementação do DNSSEC continua sendo um assunto operacional tanto quanto criptográfico. Erros de configuração, especialmente na rotação das chaves de assinatura, podem causar interrupções de serviço. A ativação requer, portanto, testes prévios e um procedimento de rollback documentado.
Um ângulo frequentemente negligenciado diz respeito à proteção da conta que administra os registros DNS. Tomar o controle dessa conta permite modificar diretamente as respostas DNS, redirecionar o tráfego ou gerar certificados TLS fraudulentos. A agência americana CISA recomenda proteger esses acessos por autenticação multifatorial, auditar regularmente os registros publicados e monitorar os logs de Certificate Transparency para detectar qualquer emissão de certificado não autorizada.
Diretiva NIS2 e gestão de riscos DNS na Europa
A diretiva europeia NIS2 amplia o escopo das entidades sujeitas a obrigações de cibersegurança. Os provedores de serviços DNS figuram explicitamente entre as entidades afetadas. O regulamento de execução europeu 2024/2690 especifica os requisitos técnicos esperados, especialmente em termos de gestão de riscos cibernéticos.
Para as organizações que operam sua própria infraestrutura DNS, essa evolução regulatória implica formalizar várias práticas:
- Documentar a política de gestão das zonas DNS, incluindo as transferências de zona e os mecanismos de replicação
- Implementar um registro das alterações de registros e dos acessos aos servidores DNS
- Integrar os componentes DNS no escopo das auditorias de segurança periódicas
Esses requisitos não são novos do ponto de vista técnico. O NIS2 os torna vinculativos do ponto de vista jurídico, com sanções em caso de não conformidade.
A gestão conjunta do DNS e das portas TCP forma uma base de segurança de rede que nem os firewalls de aplicativos nem os antivírus substituem. Um resolvedor DNS corretamente configurado e portas rigorosamente filtradas reduzem a superfície de ataque antes mesmo que uma ferramenta de detecção entre em ação.
