DNSSEC: O Que É e Por Que Precisamos Dele

Paulino Ng <paulino@na-sp.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Por Que A Segurança Do Dns É Importante?
O Funcionamento Da Resolução De Nomes
O DNSSEC
Conclusão
Referências

Este artigo apresenta, rapidamente, alguns problemas de segurança relacionados a ataques que podem ser dirigidos a servidores de nomes, e o que as extensões de segurança ao protocolo, chamadas de DNSSEC, pretendem solucionar.

Introdução

O problema da segurança de redes tem preocupado muita gente nos últimos tempos. Um dos principais serviços da Internet, a resolução de nomes através do DNS, tem sido motivo de inquietação, pois muitos serviços são baseados numa correta tradução entre um nome de rede em um endereço IP. Num artigo de 1995, Paul Vixie chamava a atenção para os problemas relacionados com o DNS e o BIND. Este artigo apresenta alguns dos problemas citados e mostra a solução encontrada pelo grupo de trabalho que está especificando extensões de segurança para o DNS, conhecidas normalmente pela sigla DNSSEC.

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é encontrar o nome da consulta ou uma resposta negativa. No caminho de descida da árvore, os servidores de nomes não raízes podem ser recursivos. Se forem recursivos, eles vão dar prosseguimento à consulta, isto é, eles vão encaminhar a consulta para o próximo servidor de nomes como se a consulta houvesse partido deles.

De posse da resposta, o servidor de nomes recursivo responde ao resolvedor/servidor de nomes que lhe passou a consulta e armazena a resposta na sua cache. Assim, se uma nova consulta for feita para este nome, o servidor poderá responder diretamente com o conteúdo da sua cache. Quando a resposta vem de um servidor de nomes que efetivamente tem o dado procurado, o flag AA volta em um. Se a resposta vem da cache de um servidor no caminho da resolução, este flag aparece zerado.

Maiores detalhes do funcionamento da consulta de nomes de DNS podem ser vistos no livro DNS & BIND, P. Albitz e Cr. Liu.

REFERRALS

Uma chance de ataque acontece quando um servidor de nomes recebe uma consulta para a tupla [nome, classe, tipo] que ele sabe ter sido delegada e ele responde com um referral. Uma resposta deste tipo tem uma seção de resposta vazia, mas uma seção de certificação não vazia. A intenção desta mensagem é de contar para um outro servidor que o nome procurado talvez exista mas que este servidor não tem a resposta, tente os outros servidores indicados. Referrals defeituosos são uma boa maneira de poluir uma cache indiretamente.

Se o atacante puder "escutar" uma consulta encaminhada e injetar uma resposta referral, ele pode fazer o servidor de nomes encaminhador da consulta acreditar que o atacante possui o servidor delegado para toda a sub-árvore consultada. Esta é a maneira mais fácil de poluir uma cache já que nenhuma adivinhação está envolvida no processo: o atacante sabe o endereço fonte, a porta UDP fonte e o queryID por inspeção do pacote "escutado". Observe que não foi instalada uma escuta na rede local da usuária preocupada com segurança, mas numa rede externa sobre a qual ela não tem o menor controle.

ENCAMINHAMENTO E RECURSÃO

Quando um servidor de nomes recebe uma consulta por um nome que ele não possui, ele pode mandar de volta uma resposta de erro (se ele for o certificador/dono da zona do nome, ele sabe se o mesmo existe, ou não), mandar de volta um referral (se estiver rodando no modo não recursivo, como fazem os servidores da raiz, ou se o flag RD estiver zerado na consulta - opção de consulta não recursiva utilizada, por exemplo, no aplicativo nslookup, para determinar se um nome externo está na cache de algum servidor de nomes) ou, ainda, pode encaminhar a consulta. Esta última possibilidade interessa ao estudo de segurança pelos efeitos do seu resultado final.

O BIND leva a tarefa de encaminhamento um pouco além de responder à consulta original: como uma tentativa de otimização, o seu servidor de nomes coloca na sua cache todos os RRsets das respostas encaminhadas. Esta promiscuidade é a principal fonte da má reputação do BIND, tanto na área de operações, como na de segurança. Os servidores que transmitiram a resposta estão livres para colocarem o que bem quiserem nas respostas, mesmo que não tenha nenhuma relação com a consulta.

Paul Vixie cita outros problemas que podem levar à poluição da cache de um servidor de nomes. Como foi citado no início do artigo, muitos dos buracos já foram tapados, mas existem problemas de base que são provocados pelo próprio protocolo do DNS que não fornece mecanismos para verificar a autenticidade das respostas dos servidores de nomes. É neste quadro que entra o DNSSEC. Ele provê uma maneira de certificar o resultado das consultas.

O DNSSEC

DNSSEC é o nome dado às extensões de segurança que estão sendo propostas para o protocolo do DNS. Ele é definido pela RFC 2065, embora seja ainda considerado por muitos como um trabalho em progresso, pois não existe nenhuma implementação de uso corrente. Paul Vixie, num e-mail recente para a lista de usuários do BIND, disse que o desenvolvimento de um BIND com suporte de DNSSEC deve ser acelerado agora que a ISC (Internet Software Consortium) conseguiu uma pessoa para trabalhar nisto, e um acordo estava em andamento para permitir o uso/distribuição de bibliotecas de criptografia junto com o BIND.

A RFC 2065 trata de detalhes bastante complexos das alterações propostas, o texto a seguir dará apenas uma breve introdução ao uso do DNSSEC para resolver/atenuar o problema de segurança descrito.

SERVIÇOS NOVOS DO DNSSEC

As extensões propostas fornecem 3 serviços distintos: distribuição de chaves, certificação da origem dos dados e certificação da transação e requisição. Seguindo a filosofia original do DNS, os dados são de domínio público e não existe diferenciação dos clientes, isto é, todos recebem a mesma resposta (pelo menos no protocolo, o próprio BIND fornece maneiras de proteger os dados). As extensões não pretendem incluir nenhum tipo de lista de acesso ou outros meios de diferenciar os resolvedores de nomes.

As extensões introduzirão 3 novos RRs: KEY, SIG e NXT. A RFC 2065 detalha o formato destes RRs. Neste artigo, elas serão citadas no seu uso, para maiores detalhes os leitores são convidados a ler a RFC.

DISTRIBUIÇÃO DE CHAVES

Um RR chamado KEY foi especificado de forma a permitir ao DNS a distribuição de chaves públicas de criptografia. Este RR inclui campos com um identificador de algoritmo, parâmetros necessários ao uso da chave pública, além de uma série de indicadores, tais como o tipo da entidade associada à chave ou a ausência de associção da chave com entidades.

RRs KEY serão anexados à seção de dados adicionais, automaticamente, pelos servidores de nomes seguros, sempre que possível.

CERTIFICAÇÃO DA ORIGEM E DA INTEGRIDADE DOS DADOS

A certificação será obtida por assinatura criptográfica associadas aos RRs. Cada RR de uma zona terá associado um RR SIG. Geralmente, haverá uma única chave privada que assinará por toda uma zona. Se um resolvedor seguro aprender de modo confiável a chave pública da zona, ele poderá verificar se os dados assinados são certificados e razoavelmente atuais.

Esta chave de certificação da origem dos dados pertence à zona e não aos servidores que armazenam cópias dos dados. Isto significa que o comprometimento de um servidor, ou até mesmo de todos os servidores de uma zona, não necessariamente afeta o grau de garantia que um resolvedor tem de que ele pode determinar se o dado é legítimo.

A transmissão de RR SIGs assinando os RR das respostas não resolve, entretanto, o problema das respostas negativas, isto é, a resposta dada por um servidor quando um nome não existe, ou o tipo procurado não existe. Isto é resolvido com a introdução do RR NXT (non-existent). Este RR carrega a informação de que o nome procurado não existe, o nome mais próximo imediatamente anterior (talvez o próprio) e os tipos (A, MX, LOC, ...) a ele associados. Como os outros RRs, o RR NXT será assinado e terá um RR SIG associado. Estes RRs (NXT e SIG) deverão ser gerados a partir dos arquivos de zonas utilizados no DNS atual, usando uma chave privada guardada no servidor de nomes primário (master). Eles não são gerados dinamicamente. Portanto, não significam um acréscimo significativo de processamento para o servidor de nomes.

Existem dois casos em que um RR SIG não é assinado pela chave privada da zona. O primeiro caso dá suporte à atualização dinâmica quando algumas estações têm permissão para atualizar dinamicamente (DNS dinâmico) dados de uma zona. A estação fica, então, responsável também pela assinatura dos RRs modificados. A chave pública desta estação estará presente no arquivo da zona e será assinada como os outros RRs da zona, mas os RRs atualizados/modificados devem ser assinados pela estação.

O segundo caso suporta a certificação da transação e da requisição. A assinatura dos RRs não protege os cabeçalhos das mensagens do DNS nem suas requisições. Se os bits do cabeçalho foram falsificados por um servidor, existe pouca coisa que pode ser feita. Entretanto, é possível adicionar a certificação da transação. Tal certificação significa que um resolvedor pode ao menos ter certeza que ele está recebendo a resposta do servidor para quem ele acredita ter passado a consulta e que a mensagem não foi manipulada no caminho. Isto é feito adicionando, opcionalmente, um RR SIG no final de uma resposta que assina a concatenação da resposta do servidor com a consulta do resolvedor.

Consultas também podem ser assinadas com um RR SIG. No DNS atual, tais assinaturas não são usadas mas, no futuro, elas podem ser úteis para requisições de atualização dinâmica ou consultas especiais.

O protocolo detalha diversos aspectos de implementação que não serão tratados neste artigo mas que o leitor mais interessado deve verificar na RFC 2065. Em particular, é interessante ver o tratamento da assinatura de transferência de zona para servidores escravos, dos problemas que envolvem os CNAMEs, da expiração das assinaturas, os algoritmos de criptografia considerados e o formato das mensagens.

Conclusão

No estágio atual, a certificação pelo nome usando o DNS é altamente insegura. Protocolos implementados pelos comandos rsh, rlogin, rcp e telnet devem ser usados com muito cuidado e os administradores de sistema devem vigiá-los com tcp wrappers ou filtrá-los nos seus roteadores. A principal causa desta insegurança vem da possibilidade de poluir/adulterar o conteúdo das caches dos servidores de nomes do DNS que são utilizados para a certificação por nome. Embora muitos dos problemas no passado com o BIND tenham sido creditados a erros de implementação, existem omissões de segurança no próprio protocolo do DNS atual que permitem ataques não muito complexos aos servidores de nome.

Uma solução para parte destes problemas de segurança no DNS é proposta na RFC 2065 com algumas extensões ao protocolo atual. Estas extensões procuram validar os dados através de assinaturas criptográficas digitais. Para tanto, foram criados 3 novos RRs, KEY, SIG e NXT. Dessa forma, o DNS poderá servir também como uma maneira de distribuir chaves públicas (RR KEY) para outros usos, além da validação dos seus próprios dados. Com o uso de servidores de nomes seguros, isto é, servidores que assinem os seus RRs, e resolvedores seguros é possível garantir que os dados foram emitidos por quem se espera e não por alguém tentando invadir o seu sistema.

Além disso, o DNSSEC fornece uma estrutura de validação possível para o DNS dinâmico que pode torná-lo menos perigoso do ponto de vista de segurança.

Referências

Paul Vixie, DNS and BIND Security Issues, 5th Usenix Security Symposium, 1995.
D. Eastlake & C. Kaufman, Domain Name System Security Extensions, RFC 2065, 1997.
Paul Albitz & Cricket Liu, DNS and BIND, 2nd Ed, O'Reilly, 1997.
R. Elz & R. Bush, Clarifications to the DNS Specification, RFC 2181, 1997.