A resolução DNS e a gestão das portas TCP constituem duas camadas de segurança frequentemente tratadas separadamente nas políticas de rede das empresas. O isolamento desses dois assuntos cria, no entanto, pontos cegos exploráveis: um firewall pode filtrar corretamente a porta 53 enquanto permite que requisições DNS encapsuladas em tráfego HTTPS na porta 443 passem. Compreender como esses mecanismos interagem permite endurecer a configuração da rede sem multiplicar as ferramentas.
DNS criptografado na porta 443: a falha que o filtragem clássica não vê
A filtragem DNS tradicional baseia-se na inspeção do tráfego que transita pela porta UDP/53 ou TCP/53. Essa abordagem funcionava enquanto as requisições DNS circulavam em texto claro em um canal dedicado.
O DNS-over-HTTPS (DoH), transportado pela porta TCP 443, muda o jogo. As requisições DNS são encapsuladas em tráfego HTTPS padrão, o que as torna indistinguíveis do restante da navegação web para um firewall configurado apenas com base nos números das portas. O DNS-over-TLS (DoT), que geralmente utiliza a porta TCP 853, apresenta um problema semelhante, mas é mais fácil de identificar e bloquear.
Segundo recomendações divulgadas pela CISA e Axio Networks, uma política de filtragem DNS eficaz deve agora impor os resolvedores autorizados em cada terminal, incluindo os navegadores que ativam o DoH por padrão. Não basta mais monitorar a porta 53: as saídas para as portas 443 e 853 também devem ser controladas para detectar resoluções DNS não autorizadas.
Você encontrará informações técnicas no Open Syd que detalham os mecanismos de endurecimento aplicáveis a essas configurações.
Porta TCP 53 e firewall: por que bloquear TCP provoca falhas DNS
Um erro frequente na configuração dos firewalls consiste em permitir apenas o tráfego UDP na porta 53, bloqueando TCP/53. A lógica parece razoável: a grande maioria das requisições DNS comuns utiliza UDP.
Na prática, TCP/53 continua sendo necessário para as respostas DNS volumosas. Os registros DNSSEC, que adicionam assinaturas criptográficas às respostas, frequentemente ultrapassam o limite de tamanho dos pacotes UDP. As transferências de zona entre servidores DNS autoritativos também utilizam exclusivamente TCP. Bloquear esse protocolo na porta 53 provoca falhas intermitentes difíceis de diagnosticar, pois se manifestam apenas para certos tipos de requisições ou certos domínios.
A documentação da Cisco sobre os pré-requisitos DNS para o Cisco Secure Access distingue três papéis de rede, cada um exigindo regras de firewall diferentes na porta 53:
- O posto cliente, que envia requisições ao resolvedor recursivo interno, pode se limitar a UDP/53 na maioria dos casos
- O resolvedor recursivo deve ser capaz de emitir e receber em TCP/53 e UDP/53 para os servidores autoritativos, sob pena de não resolver os registros assinados DNSSEC
- O servidor autoritativo requer TCP/53 aberto para as transferências de zona e as respostas volumosas
Aplicar uma regra uniforme a esses três papéis equivale a fragilizar a resolução de nomes ou a abrir canais desnecessários.
Política de segurança de rede: superar a filtragem por número de porta
A porta 443 não é mais um indicador confiável de um uso web clássico. O DoH transita por ela, mas também túneis VPN, fluxos de aplicativos proprietários e algumas soluções de segurança DNS. Uma estratégia baseada apenas nos números das portas permite a passagem de tráfego não identificado.
Uma abordagem mais robusta combina vários parâmetros de controle:
- A identificação dos resolvedores DNS autorizados por seu endereço IP, com bloqueio de qualquer outro resolvedor nas portas 53, 443 e 853
- A inspeção dos certificados TLS para distinguir o DoH legítimo do tráfego web padrão na porta 443
- A monitoração de aplicativos que identifica o protocolo real independentemente da porta utilizada, permitindo detectar um túnel DNS encapsulado em HTTPS
- O controle dos parâmetros de configuração dos navegadores para impedir a ativação automática do DoH para resolvedores externos
Essa lógica de defesa em profundidade exige tratar o DNS não como um serviço isolado, mas como um componente transversal do sistema de informação. As regras de roteamento, a gestão dos aplicativos instalados nos postos e a configuração dos sistemas operacionais participam todas da postura DNS da empresa.
Monitoramento DNS e detecção de fluxos anormais na rede
O endurecimento das regras de firewall cobre apenas uma parte do problema. Um resolvedor DNS interno comprometido, ou um software malicioso que utiliza o DNS como canal de exfiltração de dados, pode gerar tráfego conforme as regras de filtragem enquanto é malicioso.
O monitoramento do volume e da frequência das requisições DNS constitui um complemento necessário. Um posto que emite várias milhares de requisições para um mesmo domínio em poucos minutos apresenta um comportamento atípico que merece investigação. Da mesma forma, requisições para nomes de domínio com alta entropia (cadeias de caracteres aleatórias) frequentemente sinalizam um túnel DNS ou uma comunicação com um servidor de comando e controle.
Os retornos de campo divergem sobre o limite a partir do qual esses alertas se tornam exploráveis sem gerar muitos falsos positivos. O tamanho da rede, o número de postos e a diversidade das aplicações de negócios influenciam diretamente o calibragem. Um sistema de monitoramento DNS mal calibrado gera ruído que acaba sendo ignorado pelas equipes de segurança.
A correlação entre os logs DNS e os logs de firewall (portas TCP abertas, conexões de saída incomuns) permite reduzir esse ruído. Um pico de requisições DNS para um domínio desconhecido, combinado com uma conexão TCP de saída em uma porta não padrão a partir do mesmo posto, produz um alerta muito mais confiável do que um indicador isolado.
O endurecimento DNS e o controle das portas TCP não são dois projetos distintos. Os dados disponíveis mostram que os ataques recentes exploram precisamente a junção entre essas duas camadas, onde o DNS criptografado atravessa portas consideradas seguras. Tratar esses assuntos juntos, em uma política de segurança de rede unificada, continua sendo a única abordagem que leva em conta a realidade do tráfego atual.
