POR QUE SEGURANÇA PROTEÇÃO DO DNS

POR QUE A SEGURANÇA DO DNS É IMPORTANTE

Tome-se uma usuária consciente dos problemas relacionados com segurança. Ela utiliza um dispositivo desafio/resposta com codificação triplo-DES quando estabelece conexões a partir de máquinas remotas para sua rede local, mas, quando faz conexões locais, ela acha seguro enviar a sua senha em texto puro, já que sabe não existirem escutas clandestinas na sua rede privada (local).

Assuma-se, ainda, que a instalação dela é uma dessas que não restringe conexões de saída de TCP, supondo que firewalls só são necessários para manter o pessoal fora. Se o servidor de nomes de tal instalação é capaz de receber pacotes UDP, na porta 53, vindos do exterior da rede local, então esta usuária consciente de problemas de segurança corre riscos potenciais.

DESTINAÇÃO ERRADA

Uma pessoa pede a esta usuária que abra uma seção de Telnet com um host1. O cliente de Telnet por ela utilizado pede ao servidor de nomes o endereço do host pretendido, recebe uma resposta corrompida e inicia uma conexão TCP com o servidor de Telnet acessado a partir deste endereço falso. Embora este endereço não corresponda aquele do host1 pretendido, o servidor mostra a mesma mensagem de saudação habitual e ela faz o login costumeiro, informando, inclusive, a sua senha. Em seguida, a conexão cai, ela tenta de novo, tudo dá certo, ela culpa um "grimlin" na rede e esquece o assunto. Entretanto, há, efetivamente, um "grimlin" na rede e este acaba de colher a sua senha.

FONTE ERRADA

Se esta mesma usuária depende de autenticação baseada em nomes, então ela está pronta para outra descida ao inferno. Autenticação baseada em nomes é, essencialmente, o que fazem os comandos remotos, rsh, rlogin e rcp, além de ferramentas que são baseadas nestes protocolos, tais como: tar da GNU, rdist, rsync e outros.

Nos velhos tempos, bastava controlar um domínio reverso para enganar este tipo de autenticação. Com a descoberta deste furo de segurança, estes programas passaram a fazer a dupla checagem para verificar se uma máquina é quem ela diz ser (isto é, existe uma tradução reversa para verificar o nome da máquina e uma checagem na resolução de nomes de domínio para ver se este nome, efetivamente, está ligado ao endereço). De novo, este esquema pode ser furado se for possível poluir o servidor de nomes local.

Para uma explicação de como isto pode acontecer, deve-se ver o artigo do Vixie. Para ter certeza de que isto pode, efetivamente, acontecer, basta lembrar-se do caso do ataque da Alternic aos servidores de nomes da raiz que fizeram o endereço internic.net apontar para uma máquina da Alternic durante um certo tempo. Além do caso em que crackers mudaram o endereço de www.microsoft.com para uma página de contra-propaganda.

O FUNCIONAMENTO DA RESOLUÇÃO DE NOMES

Os casos dos ataques citados acima foram resolvidos com os novos BINDs (4.9.6 ou 8.1.1). Mas, nas palavras do atual responsável pelo BIND, Paul Vixie, o próprio protocolo do DNS é inseguro. A seguir, é apresentada uma rápida explicação de como funciona o mecanismo de resolução de nomes, bem como de alguns de seus problemas.

O FORMATO DOS DATAGRAMAS DE DNS

Consultas e respostas de DNS usam um formato comum, embora nem todos os elementos do protocolo estejam presentes todo o tempo. O caso mais simples, descrito aqui, usa UDP/IP, onde cada datagrama contém uma consulta ou resposta de DNS. O uso de TCP/IP está fora do contexto deste artigo.

• Seção de cabeçalho: Descreve as outras seções, possui diversos flags, inclusive o RD (recursion desired) e o AA (authoritative answer), e, o mais importante neste contexto de segurança, os 16 bits identificadores da consulta, o query ID.

• Seção de consulta: Contém o nome, a classe e o tipo do conjunto de registros de recursos (RRset) buscados. Alguns podem não estar familiarizados com o termo RRset, mas imaginem uma consulta ao nome de um repositório muito popular e que pode ser atendido por diversas máquinas com diferentes endereços. O conjunto destes endereços deve formar a resposta à consulta. Observem que, embora a maioria dos softwares ainda não tenham se adaptado a esta nova realidade da resolução de nomes, é perfeitamente válido um endereço ter diversas traduções reversas, isto é, um conjunto de RRs do tipo PTR. O protocolo do DNS permite mais de uma consulta nesta seção, mas nenhuma das implementações atualmente em uso utiliza esta facilidade.

• Seção de resposta: É sempre vazia nas consultas. Contém o RRset que casa com a consulta ou está vazia se o nome não existe, se foi feita uma consulta não recursiva ou se a consulta resulta numa referência (referral).

• Seção de certifição (authority): É sempre vazia nas consultas. Pode estar vazia em respostas. Se não estiver vazia, contém os RRs, NS e SOA da zona consultada. Isto é chamado, geralmente, de referral data.

• Seção de dados adicionais: Também é sempre vazia em consultas e pode estar vazia em respostas. Se as seções de resposta ou certifição possuem RRs cujos campos de dados possuem outros nomes de RR, os RRsets destes nomes aparecem nesta seção.

SERVIDORES E RESOLVEDORES

O cliente do DNS é chamado de resolvedor de nomes e, normalmente, é constituído por uma biblioteca de funções que são compiladas e ligadas às aplicações que as utilizam. O servidor, como o próprio nome diz, é o servidor de nomes. O resolvedor tem uma configuração estática que lhe fornece uma lista de domínios de consulta e uma lista de endereços de servidores de nomes. Quando uma aplicação precisa resolver um nome, ela usa umas das funções da biblioteca. A função acionada conecta com o primeiro servidor da sua lista e inicia a procura ao nome, completando-o com o primeiro nome da lista de domínios de consulta caso não exista um ponto no nome inicial.

O servidor de nomes, usado para dar prosseguimento à consulta, é dito encaminhá-la. Caso o mesmo não esteja configurado para fazer recursão, ele somente poderá responder ao resolvedor com os nomes que possui na sua base de dados. Caso ele esteja configurado para fazer recursão, a consulta esteja com o flag RD em um e o nome não for local, ele encaminha a consulta, perguntando para os servidores de nome da raíz, que por serem não recursivos, respondem com um referral para um dos servidores de nomes dos domínios do topo.

A consulta prossegue para o primeiro servidor de nomes referenciado pelo servidor raiz e continua descendo a árvore de nomes do DNS até