Escolar Documentos
Profissional Documentos
Cultura Documentos
OUTROSTRABALHOSEM:
www.projetoderedes.com.br
Joo Pessoa
2006
Joo Pessoa
2006
__________________________________________
PROF.DR. DNIO MARIZ TIMTEO DE SOUSA
Orientador
____________________________________________________
___________________________________________________
Joo Pessoa
2006
Dedicatria
Agradecimentos
Resumo
O Sistema de Nomes de Domnios (Domain Name System - DNS) um dos principais
mecanismos que compe a Internet. Funciona como um repositrio distribudo que permite o
mapeamento entre nomes de servios e sua correspondente localizao na rede. O DNS tem
algumas vulnerabilidades conhecidas e se exploradas, podem trazer srias conseqncias para os
servios da Internet, tais como negao de servio e roubo de informaes. O DNSSec, um
conjunto de extenses de segurana proposto pelo IETF para o DNS, utiliza criptografia de
chaves pblicas e assinaturas digitais, disponibiliza autenticao e integridade dos dados, alm de
distribuio de chaves e certificao de transaes e requisies. Este trabalho tem como objetivo
discutir o funcionamento, os problemas e as vulnerabilidades conhecidas do DNS, bem como
discutir como o DNSSec se prope a minimizar esses problemas. Uma anlise crtica sobre os
potenciais problemas do DNSSec e sobre as dificuldades da sua adoo em escala na Internet
tambm sero discutidos.
Palavras chave: DNS, DNSSec, Internet, vulnerabilidade, ataques, criptografia, assinatura
digital, chaves pblicas.
Abstract
The Domain Name System (DNS) is one of the main components of the Internet infrastructure. It
works as a distributed repository and query system that allows applications mapping between
service names and their correspondent network address. However, DNS has some well known
vulnerabilities which, if fully exploited, can bring serious problems to the Internet services and
applications, such as denial of service attacks, eavesdropping and thief of information. DNSSec is
a new proposed standard from IETF, which extends DNS to use public key cryptography, key
distribution and digital certificates, enabling it to offer authentication, confidentiality, data
integrity and non-repudiation. This work is aim at presenting how DNS works, its main problems
and vulnerabilities. We also present a discussion about what solutions DNSSec is offering to
DNS problems, what are the main difficulties for deploying it in large scale over the Internet ,
and a critical analysis of its potential problems.
Keywords: DNS, DNSSec, Internet, vulnerabilities, attacks, cryptography, public key
infrastructure.
Lista de ilustraes
Figura 1: Exemplo da hierarquia de domnios ....................................................................... 17
Figura 2: Resoluo Recursiva ................................................................................................ 22
Figura 3: resoluo interativa.................................................................................................... 25
Figura 4: Ataque do tipo DNS Spoofing. ................................................................................. 33
Figura 5: Algoritmo de criptografia assimtrica (chave pblica) ......................................... 35
Figura 6: Assinatura Digital Gerao do hash.................................................................... 37
Figura 7: Assinatura Digital verificao do hash. ............................................................... 37
Figura 8: Formato da seo RDATA do registro DNSKEY.................................................. 38
Figura 9: Formato do campo flags do registro DNSKEY...................................................... 38
Figura 10: Formato da seo RDATA do registro RRSIG ................................................... 41
Figura 11: Formato da seo RDATA do registro NSEC..................................................... 43
Figura 12: Formato da seo RDATA do registro DS .......................................................... 44
Figura 13: Vulnerabilidades do DNS .................................................................................... 45
Lista de tabelas
Tabela 1 Top Level Domains (TLD) ..................................................................................... 16
Tabela 2 - Sees de uma mensagem DNS.......................................................................... 19
Tabela 3 - Principais registros de recursos ............................................................................ 20
Tabela 4 Localizao dos servidores raiz do DNS ............................................................ 21
10
Sumrio
1. Introduo....................................................................................................................... 12
2. O Sistema de Nomes de Domnios (DNS) ..................................................................... 14
2.1. Funcionamento e Estrutura do DNS......................................................................... 15
2.2. Componentes da resoluo DNS .............................................................................. 18
2.2.1. Os clientes DNS ........................................................................................... 18
2.2.2. Registros de Recursos................................................................................... 18
2.2.3. Servidores DNS ............................................................................................ 20
2.2.4. Pesquisa reversa............................................................................................ 25
3. Os problemas do DNS .................................................................................................... 27
3.1. O problema do protocolo UDP................................................................................. 27
3.2. Interceptao de pacotes........................................................................................... 28
3.3. Transferncia de zonas e atualizaes dinmicas..................................................... 28
3.4. Cache Poisoning ....................................................................................................... 29
3.5. Comprometimento do Servidor ................................................................................ 31
3.6. DNS Spoofing .......................................................................................................... 31
4. DNSSec: Extenses de segurana para o DNS .............................................................. 34
4.1. Criptografia de Chave Pblica e Assinaturas Digitais.............................................. 35
4.2. Registro DNSKEY ................................................................................................... 38
4.3. Registro RRSIG........................................................................................................ 40
4.4. Registro NSEC ......................................................................................................... 42
4.5. Registro DS .............................................................................................................. 44
4.6. Cadeia de confiana.................................................................................................. 44
4.7. Como o DNSSEC tenta resolver os problemas do DNS .......................................... 45
4.8. Os problemas do DNSSEC....................................................................................... 47
5. Concluso ....................................................................................................................... 50
11
6. Referncias ..................................................................................................................... 51
12
1. Introduo
Um estudante quer fazer uma pesquisa na Internet. A maneira mais fcil acessar algum
site de buscas e realizar sua pesquisa. Ento, o estudante digita o nome do site em seu navegador,
por exemplo www.google.com.br, e assim chega at o site de buscas. Este mesmo estudante est
acessando a Internet atravs de uma rede de uma universidade, e deseja trocar arquivos com seu
colega que est em um outro PC. Basta digitar o nome do PC com o qual ele deseja se conectar,
atravs de um servio de FTP (File Transfer Protocol), por exemplo, e iniciar a transferncia do
arquivo.
bem simples assim acessar algum site ou mquina remota a partir de uma mquina local. Basta
digitar o nome do destino, como algum site da Web ou um host em alguma rede para realizar
conexes entre dois computadores. Mas o que acontece por trs dessa facilidade um processo
bem mais complexo, que ser explicado ao longo deste trabalho.
Em uma rede baseada no protocolo TCP/IP, cada host identificado por um endereo numrico
de 32 bits, que so separados em quatro octetos e cada octeto representado normalmente em
nmeros decimais. Os quatro nmeros so separados por um caractere ponto (.). Quatro
nmeros decimais so bem mais fceis de lembrar do que trinta e dois zeros e uns, como nmeros
de telefones, e fica muito difcil para uma pessoa lembrar de muitos endereos IPs sem precisar
de algum diretrio de assistncia. Esse diretrio nomeia nomes de hosts em endereos IP [1].
Na verdade, ao acessar uma pgina na Internet ou um sistema remoto,a aplicao que fez a
conexo inicial precisa conhecer o endereo IP da pgina na Internet ou do sistema de destino,
pois as informaes sero enviadas em pacotes IP, que tem um campo de origem e destino que
devem ser nmeros IP e no "nomes". Acontece que a aplicao que faz essa requisio utiliza
um sistema que associa o endereo IP a um nome, tornando o acesso pgina na Internet possvel
atravs do nome dela e no do endereo IP. Este processo chama-se resoluo de nomes, e
realizado por um sistema chamado Domain Name System (Sistema de Nomes de Domnio), ou
DNS.
O DNS, ou Sistema de Nomes de Domnio, uma das bases de sustentao da teia que compe
a Internet moderna. Ele realiza uma funo simples e direta: mapear nomes para endereos IP e
vice-versa. Quando o sistema no est funcionando, as conseqncias so graves e generalizadas
[2].
13
Alguns dos problemas causados pelas falhas do DNS podem levar poluio do cache do
servidor DNS, redirecionando as consultas feitas ao servidor DNS (cache poisoning),
indisponibilidade do servidor DNS, causadas por vrias consultas recursivas (server
compromising) e falsificao do IP na resoluo de nomes DNS (DNS spoofing) [9]. Estas
vulnerabilidades sero discutidas neste trabalho.
Estes problemas podem ser causados por intrusos, que se aproveitam das falhas e
vulnerabilidades do sistema para enganar as pessoas ou para parar o funcionamento do sistema. O
objetivo deste trabalho explicar o funcionamento do DNS, seus componentes, suas falhas e
vulnerabilidades, e apresentar uma soluo que est atualmente em desenvolvimento, o que ela
pode e o que ela no pode resolver, bem como seus componentes e seu funcionamento: o
DNSSEC.
DNSSEC o nome dado s extenses de segurana que esto sendo propostas para o protocolo
DNS definidas pelas RFCs (Request for Comments) 4033, 4034 e 4035, que estabelecem os
detalhes das alteraes propostas, para a implantao de um DNS seguro. A caracterstica
principal deste novo modelo do DNS prover a autenticao da origem dos dados das zonas
(partes do espao de nomes, que ser explicado mais adiante) e a integridade destes dados usando
criptografia de chave pblica [1].
14
15
O responsvel pelo projeto de arquitetura do novo sistema foi Paul Mockapetris,do Instituto de
Cincia da Informao da Universidade da Califrnia. Ele liberou em 1984 o Domain Name
Server, descrito pelas RFCs 882 e 883, que foram suplantadas pelas RFCs 1034 e 1035, que so
as especificaes atuais do sistema.
16
Tabela 1 Top Level Domains (TLD)
TLD
Data de
introduo
Propsito
Responsvel
.aero
2001
Societe Internationale de
Telecommunications
Aeronautiques SC, (SITA)
.biz
2001
Negcios
NeuLevel
.cat
2005
.com
1995
.coop
2001
Cooperativas
DotCooperation, LLC
.edu
1995
Organizaes educacionais
EDUCAUSE, USA
.gov
1995
Organizaes governamentais
US General Services
Administration
.info
1998
Uso irrestrito
.int
1998
Organizaes estabelecidas em
tratados governamentais
.jobs
2005
Comunidade Internacional de
gerncia de recursos humanos.
.mil
1995
Organizaes militares
.museum
2001
Museus
.name
2001
.net
1995
.org
1995
Organizaes no-governamentais e
sem fins lucrativos
.pro
2002
Profissionais liberais
.travel
2005
Tralliance CorporationTralliance
Corporation, USA
Cada nome de domnio um caminho em uma grande rvore invertida, denominada espao de
nomes de domnio. Os nomes de domnio obedecem hierarquia dessa rvore, que possui uma
17
nica raiz no topo, chamada raiz, que pode se ramificar de vrias maneiras em cada ponto de
interseo ou n.
Cada n da hierarquia na rvore possui um nome. O caminho completo desses nomes desde um
n at a raiz chama-se nome de domnio. Eles so sempre lidos do n para a raiz, com pontos
separando os nomes no caminho. Ao n raiz reservado um nome vazio, representado por um
ponto (.). Alguns softwares interpretam um ponto subseqente em um nome de domnio para
indicar que o nome do domnio absoluto. O nome de domnio absoluto escrito em relao
raiz e especifica sem ambigidade a localizao do n na hierarquia [3] , tambm conhecido
como nome de domnio totalmente qualificado (FQDN Fully Qualified Domain Name).
Para garantir que cada n seja identificado de forma nica dentro de um domnio, o DNS requer
que os ns filhos do mesmo pai tenham nomes diferentes. Essa restrio apenas para ns filhos,
e no para todos os ns da rvore. O nmero de segmentos em um nome de domnio
corresponde hierarquia de nomes. No existe nenhum padro universal porque cada
organizao pode escolher a forma como estruturar nomes em sua hierarquia. Alm disso, nomes
dentro de uma organizao no precisam seguir um padro uniforme porque grupos individuais
dentro da organizao podem escolher uma estrutura hierrquica que apropriada ao grupo [4].
Um domnio uma parte do espao de nome de DNS que inclui um nome de domnio e todos os
nomes abaixo dele. Um domnio pode ter diversas sub-rvores prprias, denominadas sub-
18
domnios. Um domnio um sub-domnio dentro de outro domnio se a raiz do sub-domnio
estiver dentro do domnio.
19
sofisticados para a localizao de DCs (controladores de domnio do Windows 2000 ou Windows
Server 2003) e servidores de e-mail do domnio.
Os registros de recursos definem os tipos de dados no DNS, e so armazenados em formato
binrio, chamado mensagem, mas so enviados pela rede em formato texto, enquanto executam a
transferncia de zonas. Esta mensagem dividida em 5 sees, onde cada seo define os nomes
do domnio dentro do espao do de nomes de domnios.
A seo cabealho est sempre presente, inclui campos que especificam quais das sees
restantes esto presentes e se o pacote DNS uma pesquisa ou uma resposta. Os nomes das
sees depois do cabealho so derivados do seu uso em uma pesquisa bsica. A seo question
contm campos que descrevem a pesquisa para o nome do servidor. Estes campos so do tipo
pesquisa (QTYPE), tipo classe (QCLASS) e tipo nome de domnio (QNAME). A seo answer
contm RRs com a resposta da pesquisa; a seo authority contm RRs que apontam para o
servidor de nomes autoritativo e a seo additional records contm RRs que so relacionados
com a pesquisa, mas no so estritamente respostas para a pesquisa [4]. Abaixo segue o
esquema das sees da mensagem DNS:
Tabela 2 - Sees de uma mensagem DNS
Cabealho
Pergunta
Resposta
RRs com a resposta da pesquisa. Sempre vazia ns consultas, contm o RRset que
casa com a consulta, ou est vazia se o nome no existe, se foi feita uma consulta
no recursiva ou se a consulta resulta numa referncia (referral).
Autoridade
RRs apontador para servidor de nomes autoritativo. sempre vazia nas consultas.
Pode estar vazia em respostas. Se no estiver vazia, contm os RRs, NS e SOA da
zona consultada. Isto chamado, geralmente, de referral data.
Adicional
De acordo com a RFC 1035, registro de recursos do DNS tem 6 (seis) campos, a seguir:
NAME: contm o nome DNS, e tambm uma referncia ao seu prprio nome, para
o qual o RR pertence.
20
TYPE: o tipo do RR. Este campo necessrio, pois no comum para um nome
DNS ter mais de um tipo de RR. Os tipos mais comuns de RRs so os seguintes:
Descrio
Uso
PTR
SOA
CNAME
MX
NS
RDATA: o formato desse campo varia de acordo com o tipo e a classe do RR.
21
Um servidor de nomes tem autoridade sobre uma zona quando este servidor possui informaes
completas sobre uma parte do espao de nomes de domnio (zona), que carregam a partir de um
arquivo no prprio servidor ou de outro servidor de nomes.
Uma organizao que administra um domnio pode subdividir este domnio em subdomnios e
atribuir a uma outra organizao a responsabilidade pela administrao deste subdomnio. Por
exemplo, a organizao administradora do domnio .br atribui a responsabilidade de administrar
o subdomnio sitecnet empresa SitecNet Informtica1, que solicitou organizao a criao
deste subdomnio. Este processo chama-se delegao de zonas. Ento, um servidor de nomes
que contm informaes completas sobre esta zona tem autoridade sobre esta zona. Um servidor
de nomes pode ter autoridade sobre uma ou mais zonas.
Atualmente existem 13 servidores de nomes raiz espalhados pelo mundo, que contm as
informaes dos servidores de nomes autorizados para cada uma das zonas de nvel mais alto, e
gerenciam mais de 9 bilhes de consultas todos os dias [2]. Estes servidores so responsveis
pela zona raiz, que est hierarquicamente acima do espao de nomes DNS. Os servidores raiz
esto descritos na Tabela 4.
Tabela 4 Localizao dos servidores raiz do DNS
Letra
Operador
Localizao
VeriSign
ISI
Cogent
University of Maryland
NASA
ISC
Autonomica
VeriSign
RIPE NCC
ICANN
WIDE Project
Tokyo, Japan
na verdade, o domnio br atribui a responsabilidade ao domnio "com", "org", "edu", etc. S que existe a
coincidncia de que quem gerencia "br" tambm gerencia os demais (com, org...) que a Fapesp-SP.
22
Existem dois tipos de servidores de nomes autoritativos (que tem autoridade sobre a zona): o
servidor de nomes mestre primrio, que armazena dados de uma zona em um arquivo de zona,
que define os hosts/servidores existentes na zona, e o servidor de nomes mestre secundrio, que
tambm armazena informaes sobre a zona, mas recupera estas informaes a partir do servidor
mestre primrio ou de outro secundrio. Quando um servidor mestre secundrio carrega
informaes de zona de um servidor primrio ou de outro secundrio, acontece a transferncia de
zona.
Os servidores de nomes buscam informaes em suas zonas e respondem a consultas de outros
servidores de nomes. Uma consulta enviada ao servidor de nomes pode ser resolvida de duas
maneiras: de modo recursivo ou de moto iterativo.
Quando o servidor de nomes tem autoridade sobre a zona pesquisada (o servidor primrio para
a zona), diz-se que o servidor respondeu com autoridade (resposta do tipo authoritative)
requisio.
Quando o servidor de nomes no possui autoridade sobre a zona pesquisada, ento ele vai
pesquisar a resposta em seu cache, pois medida que as requisies so resolvidas, o servidor
DNS armazena o nome do endereo IP mapeado, para poder resolver o nome de forma mais
rpida da prxima vez que houver uma requisio para este mesmo nome. Estas informaes so
mantidas no servidor por um tempo, chamado TTL (Time to Live), configurado no arquivo de
zona pelo administrador do DNS.
Caso o servidor de nomes no resolva a requisio com autoridade, o servidor far consultas a
outros servidores de nomes para resolver a consulta enviada pelo cliente. Este processo
chamado recurso.
Outros
Servidores DNS
Servidor DNS
Preferencial
Cliente DNS
Servidor DNS
.
Servidor DNS
com
Servidor DNS
microsoft.com
Servidor DNS
exemplo.microsoft.com
23
Por exemplo, uma aplicao deseja acessar o site exemplo.microsoft.com, e est utilizando um
computador da rede sitecnet.com.br, utilizando o servidor DNS com autoridade apenas para a
zona sitecnet.com.br, e no para exemplo.microsoft.com. Assim, o servidor sitecnet.com.br ir
consultar outros servidores de nomes em busca da resoluo da solicitao a ele enviada, da
seguinte maneira:
1. O servidor de nomes retira apenas a parte do nome do domnio (microsoft.com), e
utilizando a lista de servidores raiz, localiza um servidor de nomes com autoridade para o
domnio root da Internet, representado pelo ponto ( . );
2. Localizado o servidor responsvel pelo domnio root, o servidor DNS da empresa Sitecnet
envia uma consulta iterativa para o servidor DNS do domnio root solicitando
informaes sobre o servidor responsvel pelo domnio .com;
3. O servidor DNS do domnio Sitecnet recebe a resposta informando qual o servidor DNS
responsvel pelo domnio .com.
4. O servidor DNS do domnio Sitecnet envia uma consulta para o servidor DNS
responsvel pelo .com (informado no passo 3), solicitando informaes sobre o servidor
responsvel pelo domnio microsoft.com;
5. O servidor DNS responsvel pelo .com no a autoridade por microsoft.com, mas sabe
informar quem a autoridade deste domnio. O servidor DNS responsvel pelo .com
retorna para o servidor DNS do domnio Sitecnet, o nmero IP do servidor DNS
responsvel pelo domnio microsoft.com;
6. O servidor DNS do domnio Sitecnet recebe a resposta informando o nmero IP do
servidor responsvel pelo domnio microsoft.com;
7. O servidor DNS do domnio Sitecnet envia uma consulta para o servidor DNS
responsvel pelo microsoft.com (informado no passo 6) solicitando informaes sobre o
servidor responsvel pelo domnio exemplo.microsoft.com;
8. O
servidor
DNS
responsvel
pelo
Sitecnet
no
autoridade
para
nmero
exemplo.microsoft.com;
IP
do
servidor
DNS
responsvel
pelo
domnio
24
9. O servidor DNS do domnio Sitecnet recebe a resposta informando o nmero IP do
servidor responsvel pelo domnio exemplo.microsoft.com.
10. O servidor DNS do domnio Sitecnet recebe a resposta da consulta, faz uma cpia desta
resposta no cache do servidor DNS e retorna o resultado para o cliente que originou a
consulta.
11. . No cliente, o resolver recebe o resultado da consulta, repassa este resultado para o
programa que gerou a consulta e grava uma cpia dos dados no cache local do DNS.
O processo descrito anteriormente termina com o servidor DNS (aps ter consultado vrios
outros servidores) retornando uma resposta positiva para o cliente, isto , conseguindo resolver o
nome e retornando a informao associada (normalmente o nmero IP associado ao nome) para o
cliente. Mas nem sempre a resposta positiva; muitos outros tipos de resultados podem ocorrer
em resposta a uma consulta, tais como:
An authoritative answer (resposta com autoridade): Este tipo de resposta obtido quando o
nome resolvido diretamente pelo servidor DNS que a autoridade para o domnio pesquisado.
Por exemplo, um usurio da intranet da empresa (sitecnet.com.br), tenta acessar uma pgina da
intranet da empresa, por exemplo: exemplo.microsoft.com. Neste caso a consulta ser enviada
para o servidor DNS da empresa, o qual a autoridade para a zona sitecnet.com.br e responde
diretamente consulta, informando o nmero IP do servidor exemplo.microsoft.com. tambm
uma resposta positiva s que com autoridade, ou seja, respondida diretamente pelo servidor DNS
que a autoridade para o domnio pesquisado.
A positive answer (resposta positiva): uma resposta com o resultado para o nome pesquisado,
isto , o nome pode ser resolvido e uma ou mais informaes associadas ao nome so retornadas
para o cliente.
A referral answer (uma referncia): Este tipo de resposta no contm a resoluo do nome
pesquisado, mas sim informaes e referncia a recursos ou outros servidores DNS que podem
ser utilizados para a resoluo do nome. Este tipo de resposta ser retornado para o cliente, se o
servidor DNS no suportar o mtodo de recurso, descrito anteriormente. As informaes
retornadas por uma resposta deste tipo so utilizadas pelo cliente para continuar a pesquisa,
usando um processo conhecido como iterao (o qual ser descrito mais adiante). O cliente faz a
pesquisa em um servidor DNS e recebe, como resposta, uma referncia a outro recurso ou
25
servidor DNS. Agora o cliente ir interagir com o novo recurso ou servidor, tentando resolver o
nome. Este processo pode continuar at que o nome seja resolvido ou at que uma resposta
negativa seja retornada, indicando que o nome no pode ser resolvido.
A negative answer (uma resposta negativa): Esta resposta pode indicar que um dos seguintes
resultados foi obtido em resposta consulta: um servidor DNS que autoridade para o domnio
pesquisado informou que o nome pesquisado no existe neste domnio, ou um servidor DNS que
autoridade para o domnio pesquisado informou que o nome pesquisado existe, mas o tipo de
registro no confere.
Em uma pesquisa no modo iterativo, o servidor de nomes retorna a melhor resposta que j
conhece, podendo ser uma resposta solicitao ou uma indicao de um outro servidor de
nomes. O servidor de nomes consultado pesquisa a resposta em seus dados locais (incluindo o
cache), e caso no encontre a resposta, retorna como referncia os nomes e endereos dos
servidores de nomes mais prximos do nome de domnio consultado.
26
exemplo, se o endereo IP de sitecnet.com.br 201.30.147.2, a entrada correspondente no
domnio IN-ADDR.ARPA 147.30.201.IN-ADDR.ARPA, o qual mapeia de volta para o nome
de domnio sitecnet.com.br.
A consulta inversa uma pesquisa de nome de domnio que indexa um determinado dado.
processada somente pelo servidor de nomes que recebeu a consulta. Esse servidor de nomes
pesquisa todos os dados locais em busca do item solicitado e, se possvel, retorna o nome do
domnio que o indexa. Como qualquer servidor de nomes conhece apenas parte do espao geral
de nomes de domnio, nunca garantido que a consulta inversa devolva uma resposta. [3].
27
3. Os problemas do DNS
O sistema de nomes de domnio responsvel por traduzir diversos nomes de domnios
existentes para seus respectivos endereos IP, atendendo a requisies de clientes DNS
(resolvers) na porta 53, utilizando, para estas comunicaes, tanto o protocolo UDP (User
Datagram Protocol) quanto o TCP (Transmission Control Protocol). As pesquisas DNS so
manipuladas sobre o protocolo UDP, enquanto as transferncias de zonas utilizam o protocolo
TCP, ambos na porta 53[6].
Por seu uso ser amplamente utilizado e necessrio na Internet, os administradores de rede no
podem bloquear, em seus mecanismos de defesa, como Firewalls, a passagem de pacotes com
destino a porta 53.
A classificao dos problemas do DNS no uniforme, pois divergente entre vrios autores
quanto classificao e terminologia. A seguir ser feita uma compilao da literatura,
abordando alguns dos principais problemas do DNS.
no prov meios para controlar a taxa com que as informaes fluem entre as mquinas.
28
Todas estas caractersticas do protocolo UDP na pesquisa DNS significam que o cliente no pode
garantir que a resposta enviada pelo servidor sua consulta seja necessariamente respondida pelo
servidor ao qual foi enviada a consulta.
29
tipo CNAME), mquinas responsveis por receber e-mails do domnio (registros do tipo MX),
entre outros dados que podem revelar informaes sobre a rede ou domnio para qual o servidor
autoridade. Esta tabela chamada de arquivo de zona.
A transferncia de zonas entre servidores ocorre quando um servidor consultado no tem
autoridade para responder a esta consulta e a encaminha para outro servidor DNS, e tem por
objetivo a replicao das informaes de um servidor DNS primrio para um ou mais servidores
DNS secundrios.
Em uma transferncia de zonas, um invasor pode ter acesso no autorizado s informaes
contidas na troca dos dados entre os servidores, e at seqestrar uma zona inteira, redirecionando
todo o trfego enviado ao servidor do domnio seqestrado e respondendo ao cliente com
respostas falsas. Este ataque conhecido como DNS Hijacking, e a vulnerabilidade acontece na
atualizao entre servidores.
Uma atualizao dinmica permite que clientes DNS registrem e atualizem dinamicamente seus
registros de recursos em um servidor DNS sempre que ocorrerem alteraes. Isso reduz a
necessidade de administrao manual de registros de zona, especialmente para clientes que se
movem ou alteram suas localizaes com freqncia e usam DHCP para obter um endereo
IP.[13]
O protocolo de atualizao dinmica do DNS prov mecanismos para controlar quais sistemas
so permitidos para atualizar dinamicamente o servidor primrio. Segundo a RFC 2136, um
ataque do tipo DoS pode ser enviado por um remetente de uma atualizao com o envio de sees
TCP simultneas contendo atualizaes que o servidor master primrio ir recusar devido a
problemas de permisses. Os mecanismos de gerenciamento de conexes podem prevenir danos
maiores devido ao ataque, mas no previnem que algumas consultas sejam enviadas sem resposta
durante o ataque.
Significa fazer com que um servidor armazene em cache uma informao falsa sobre a resoluo de um
determinado nome de domnio.
30
O envenenamento do cache envolve o envio de uma informao de mapeamento incorreto por um
servidor DNS com um TTL alto. Quando o servidor DNS for solicitado novamente, ele ir
responder com a informao errada. A informao errada armazenada em cache por outro
servidor DNS, que torna a informao errada disponvel para programas que requisitam a
informao do servidor DNS atravs de uma interface de um cliente.
O servidor DNS com o cache poludo responde pesquisa, mas no necessariamente com a
resposta correta; ele preenche a seo registros adicionais da mensagem de resposta do DNS
com uma informao que no necessariamente se relaciona com a resposta. O servidor que
realizou a requisio aceita a resposta e no realiza nenhum tipo de checagem para assegurar-se
de que a resposta est correta ou se relaciona com a pesquisa. O servidor aceita a informao e a
adiciona em seu cache.
Com as informaes armazenadas em cache alteradas de acordo com sua vontade, um atacante
pode redirecionar o trfego intencionalmente de um site verdadeiro para um que esteja sob seu
controle. Dois mtodos so mais conhecidos para este tipo de ataque:
O objetivo do redirecionamento do trfego encaminhar a vtima para um local falso sem que a
mesma desconfie da falsidade do destino para onde foi indicado. Este ataque geralmente
utilizado para redirecionar sites de bancos para ganhar acesso s contas dos usurios ou
redirecionar sites de notcias para manipular as informaes e publicar falsas histrias.
O envenenamento do cache tambm pode ter como objetivo lanar um ataque do tipo DoS
Denial of Service. Um dos mais perigosos ataques consiste em negar a disponibilidade do servio
de DNS congestionando um ou mais servidores de DNS com consultas recursivas. medida que
o servidor sobrecarregado com consultas, a CPU atingir o nvel mximo de processamento e o
servidor DNS ficar indisponvel. Assim, quando um usurio solicitar uma pesquisa verdadeira
ao servidor, o servio de resoluo de nomes estar indisponvel.
Uma maneira de realizar o DoS em um servidor inserir um registro do tipo CNAME no cache
do servidor referindo-se a ele mesmo no nome cannico.
exemplo.sitecnet.com.br
IN
CNAME
exemplo.sitecnet.com.br
Aps inserir este registro de recurso no cache do servidor, o atacante pode causar uma falha no
DNS por uma simples transferncia de zona.
31
Se o campo ID e o campo nome a ser resolvido do pacote DNS so iguais aos enviados
na consulta;
32
poludo. Quando o cliente consultar este servidor, ter como resposta uma informao falsa e
poder ser direcionado para outro local que no o verdadeiro destino desejado pelo cliente em sua
consulta original.
Este ataque visa enviar uma resposta falsa ao servidor DNS vtima antes que a resposta
verdadeira enviada pelo servidor DNS questionado chegue vtima. Esta resposta verdadeira ir
chegar at o servidor vtima, mas ser descartada, pois este j recebeu uma resposta, mesmo que
falsa, com as informaes desejadas.
O dnsspoofing pode ser realizado atravs de interceptao de pacotes e predio de transactions
ID, por exemplo. Quando bem sucedido, o cache do servidor vtima permanece poludo por um
determinado tempo, armazenando informaes falsas sobre um determinado nome de domnio,
podendo levar a srias conseqncias, tais como:
Redirecionar de trfego;
Ataques DoS;
33
34
Autenticao da origem dos dados, atravs das assinaturas criptogrficas associadas aos
registros de recursos;
Com estes servios, ser possvel para o protocolo checar se os dados publicados por uma
entidade so realmente de sua autoridade (autenticidade), se os dados recebidos so da mesma
forma como foram publicados (integridade) e a garantia de que a resposta esperada de uma
consulta est na resposta da consulta original e que esta resposta vem do servidor para o qual a
consulta foi enviada.
35
Canal Pblico
KPblica
Remetente
Mensagem
(abcdef...z)
Chave
KSecreta
Destinatrio
Criptograma
(...)
Cifrar
Decifrar
Mensagem
(abcdef...z)
Canal Inseguro
36
Alm de criptografar as mensagens, o DNSSec tambm precisa certificar-se de que quem
responde s consultas realmente quem foi consultado. Esta verificao realizada utilizando o
conceito de Assinaturas Digitais.
A assinatura digital um item que acompanha uma informao, confirmando a origem desta
informao, certificando que esta informao no foi modificada e impedindo a negao da
origem desta informao. Com isto, o receptor pode verificar a identidade alegada pelo
transmissor da informao, no pode repudiar o contedo da mensagem nem tentar ele mesmo
forjar a mensagem. A assinatura digital apenas no garante o sigilo da mensagem, pois o
remetente da mensagem a codifica com sua chave privada a envia junto com a mensagem para o
destinatrio. Este, por sua vez, decodifica a mensagem com a chave pblica do remetente,
garantindo assim a autenticidade do envio da mensagem pelo remetente. Estas assinaturas digitais
so geradas a partir de algoritmos criptogrficos de chave pblica.
Porm, a assinatura digital, como dito anteriormente, no garante a confidencialidade da
mensagem. Para isto, deve-se combinar os dois mtodos de criptografia, ou seja, criptografar a
mensagem duas vezes, uma vez com a chave privada e outra com a chave pblica do destinatrio.
Ao enviar uma mensagem, por exemplo, o remetente a codifica com sua chave privada, e depois
a codifica novamente, desta vez incluindo sua assinatura, com a chave pblica do destinatrio.
Este, por sua vez, ao receber a mensagem, deve decodific-la com sua chave privada, e depois
decodific-la novamente, desta vez com a chave pblica do remetente, verificando sua assinatura
e garantindo sua autenticidade.
Este mtodo torna-se invivel, quando se trata de grandes mensagens, pois podem levar horas
para que estas sejam totalmente cifradas. Um mecanismo foi adicionado a este mtodo para
oferecer agilidade nas assinaturas digitais, alm de integridade confivel.
O uso de uma funo hashing unidirecional, que extrai um trecho qualquer do texto simples, e a
partir deste, gera um valor pequeno, de tamanho fixo, chamado hash (geralmente de 128 a 256
bits), independentemente do tamanho da entrada, para autenticar apenas uma parte da mensagem,
em vez da mensagem inteira. Assim, torna-se difcil encontrar duas mensagens produzindo o
mesmo resultado hash.
Seguem abaixo duas figuras ilustrando o mecanismo de gerao e verificao do hash.
37
38
onde 256 o campo flag, o nmero 3 especifica o protocolo e o nmero 1 especifica o algoritmo.
Entre parnteses encontra-se a chave pblica propriamente dita, e ao final mostrado o ID do
registro.
O campo flag do registro DNSKEY mostrado na figura 9:
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
|
|
|
|
|
|
|Z K|
|
|
|
|
|
|
|SEP|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figura 9: Formato do campo flags do registro DNSKEY
O bit 7 deste campo o sinalizador da chave da zona (Zone Key), e comporta-se de maneiras
diferentes, dependendo do valor que assumir:
39
1:o registro DNSKEY guarda a chave da zona DNS e seu prprio nome deve ser o nome
da zona;
0: o registro DNSKEY guarda algum outro tipo de chave pblica e no deve ser usado
para verificar RRSIGs que cobre este RRset;
O bit 15 o mecanismo usado pelo DNSKEY para comunicar-se com outras chaves em
outros RRsets, chamado SEP (Securty Entry Point). Se este bit tiver valor 1, ele ser
usado como chave SEP. Se tiver valor 0, no deve ser atribudo a este bit nenhum
significado.
Os bits de 0 a 6 e de 8 a 14 so reservados e deves ser iguais a 0. Estes bits devem ter valor 0 na
criao do registro e deve ser ignorado pelo destinatrio.
O prximo campo da seo RDATA do registro DNSKEY o chamado octeto de protocolos, e
especifica qual a finalidade de uma determinada chave. Na RFC 2535, poderia assumir os
seguintes valores:
0: reservada;
4: reservada para referir-se ao protocolo IPSEC e indica que esta chave vlida para uso
em conjunto com este padro de segurana.
5-254: disponvel para atribuies futuras pelo IANA Internet Assigned Numbers
Authority.
255: utilizada com qualquer protocolo que possa utilizar o registro DNSKEY.
Com a atualizao da RFC 2535, este campo apenas pode assumir o valor 3. Se este valor for
diferente de 3, este campo deve ser tratado como invlido durante a verificao da assinatura.
Aps o octeto de protocolos, o campo a seguir define o nmero do algoritmo utilizado pela
zona. Os valores definidos so:
0: Reservado
40
3: DAS/SHA-1 [RFC 2536]. A RFC 2535 torna obrigatrio o suporte ao DSA, mas a RFC
2536 a torna opcional;
252: Indireto.
255: Reservado
O ltimo campo do registro DNSKEY a prpria chave pblica, codificada em base 64. O
DNSSEC suporta chaves de diversos tamanhos, porm quanto maior chave, mais difcil torna-se
descobrir a chave privada correspondente e mais tempo ser necessrio para assinar os dados da
zona com a chave privada e verific-los com a chave pblica.[3]
41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
type covered
| algorithm
|
labels
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
original TTL
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
signature expiration
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
signature inception
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
key tag
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
signer's name
+
|
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/
/
/
signature
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 10: Formato da seo RDATA do registro RRSIG
O campo type covered, ou tipo contido, representado no exemplo acima pelo campo DNSKEY,
indica o tipo do registro a ser assinado. Deve haver um registro RRSIG para tipo de registro
contido na zona. O segundo campo, algorithm, que possui valor 1, indica o nmero do algoritmo
utilizado, j descrito na seo 4.1.1. O terceiro campo, labels, indica quantos rtulos tem no nome
do proprietrio dos registros assinados. Por exemplo, para o nome metron.sitecnet.com.br, o
nmero do rtulo seria 4. No exemplo acima, o campo tem valor 1. Atualmente, este campo
permite at 127 rtulos.
O quarto campo, TTL original, indica o tempo de vida original dos registros do RRset que foi
assinado. Isto serve para evitar problemas de autenticao em servidores que armazenam em
cache o RRset contido nesse registro SIG, por decrementarem tos TTLs nos registros
armazenados em cache, alm de tambm evitar problemas de segurana causados pela
manipulao de TTLs. No exemplo acima, representado pelo valor 259200.
Os campos seguintes representam, respectivamente, o trmino e o incio da validade da
assinatura. So representados no formato YYYYMMDDHHMMSS, ou seja, no exemplo acima, a
hora do trmino da validade da assinatura aps s 12:57:27 do dia 03/05/2003
(20030503125727), e tem incio s 12:57:27 do dia 03/04/2003 (2003040325727). Geralmente, a
hora do incio e de trmino da validade da assinatura a hora em que o programa foi executado
42
para assinar a zona. Aps o trmino da validade, preciso reassinar todas as assinaturas para
mant-las vlidas.
O stimo campo, key tag, ou identificador da chave, um identificador de 16 bits gerado a partir
da chave pblica que corresponde chave privada que assina a zona. No nosso exemplo tem o
valor 32882.
O oitavo campo representa o nome do signatrio (signers name), ou seja, o nome de domnio da
chave pblica que o destinatrio deve utilizar para verificar a assinatura. No exemplo, contm o
valor net. O transmissor no deve usar padres de compresso de nomes do DNS quando so
transmitidos pela rede.
O ltimo campo, signature, a assinatura digital. Este campo composto pela seo RDATA,
(formada por todos os campos RDATA, no prprio registro RRSIG, exceto o campo assinatura) e
pelo conjunto de registro de recursos (RRset) dos registros (RRs) do campo type covered.
43
sitecnet.com.br
ns.sitecnet.com.br
metron.sitecnet.com.br
control.sitecnet.com.br
central.sitecnet.com.br
Com a zona ordenada de forma cannica, o formato do registro NSEC mostrado na figura 11:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
Next Domain Name
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
List of Type Bit Map(s)
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 11: Formato da seo RDATA do registro NSEC
IN NSEC
A seo RDATA do registro NSEC contm apenas o nome do prximo nome de domnio (Next
Domain Name). Nomes prprios de RRsets que no so autoritativos para uma dada zona no
deve ser listado no registro NSEC a menos que exista no mnimo 1 (um) RRset autoritativo em
algum nome. O transmissor no deve usar compresso de nomes do DNS neste campo quando
transmitir o registro NSEC.
O campo List of type bit map(s) indica a existncia dos tipos indicados para o prximo registro
informado. No exemplo acima, o nome ns.sitecnet.com.br o prximo nome de domnio aps o
nome sitecnet.com.br, e este nome existe para os tipos NS, SOA, MX, RRSIG e DNSKEY.
O ltimo registro NSEC de uma zona deve apontar para o primeiro registro da zona, j que no
existe nenhum nome de domnio depois do ltimo nome, assim:
central.sitecnet.com.br
IN NSEC
Assim, se uma consulta buscar por um nome de domnio que no existe na zona, um registro
RRSIG que abrange todo o registro NSEC acompanha a resposta, autenticando a no-existncia
do nome de domnio ou do tipo de dados solicitado[3].
Uma conseqncia do uso deste registro que um atacante pode pesquisar pelos registros NXT
anexado a um nome de domnio da zona para localizar o em ordem alfabtica o nome do prximo
nome de domnio da zona e assim mapear todos os nomes de domnios da zona.
44
4.5. Registro DS
O registro DS (Delegation Signer) envolvido na autenticao de delegaes de zonas
entre zonas pai e filhas. Ele refere-se a um RR DNSKEY pelo armazenamento dos caracteres da
chave, do nmero do algoritmo e do digest do RR DNSKEY, e usado no processo de
autenticao do RR DNSKEY, para indicar que a delegao da zona assinada digitalmente. Este
registro aparece apenas no lado superior da delegao (zona pai).
A parte de dados especfica do registro DS (RDATA) mostrada na figura 12:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Tag
| Algorithm
| Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/
/
/
Digest
/
/
/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 12: Formato da seo RDATA do registro DS
O primeiro campo (Key Tag) lista os sinalizadores chave do registro DNSKEY referenciado pelo
registro DS. Este campo idntico ao mesmo campo do registro RRSIG. O campo Algorithm
refere-se ao nmero do algoritmo do RR DNSKET referenciado pelo registro DS, e pode conter
os mesmos valores que o campo algorithm dos registros DNSKEY e RRSIG podem conter.
O RR DS consulta a um registro DNSKEY incluindo um sumrio daquele registro DNSKEY RR.
e identifica o algoritmo usado para construir o digest. O valor 1 representa o algoritmo SHA-1 e a
RFC 4034 torna seu uso obrigatrio.
O campo digest calculado pela concatenao da forma cannica do FQDN do registro
DNSKEY com o RDATA deste registro. O tamanho do digest depende do algoritmo e do
tamanho do registro DNSKEY.
45
como uma zona pode certificar-se que esta chave pblica realmente pertence zona da qual ela se
diz ser, ou seja, sendo alterada por um atacante?
Esta chave pblica deve ser certificada por alguma entidade superior, a zona pai, que confirme
que esta chave realmente pertence ao seu domnio, e no a outro. Quando o par de chaves
gerado, a zona envia sua chave pblica zona pai para que este a certifique. A zona pai assina o
registro DNSKEY da zona filha com sua chave privada e o envia de volta para que seja includo
na zona.
Assim, cada zona realiza o mesmo processo, at que atinja os servidores raiz, ou seja, a chave
pblica da zona raiz ser configurada em todos os servidores de nomes, e cada servidor poder
certificar-se que as assinaturas a eles enviadas so realmente de quem as enviou. Este processo
chamado de cadeia de confiana, estabelecida pela verificao do RRset DNSKEY, do RRset
DS da zona pai e do RRset DNSKEY no filho. Isto criptograficamente equivalente ao uso de
apenas registros DNSKEY [34].
Dados corrompidos
Administrador da zona
Arquivo
de zona
Mestre
Falsificao do cache
4
Cache Forwarder
5
2
Atualizaes
Dinmicas
Escravo
Atualizaes no
autorizaadas
Proteo do Servidor
Envenenamento do
cache por falsificao
de dados
Resolver
Atualizaes de
dados de zonas
46
O protocolo UDP substitudo pelo TCP, j que todos os pacotes do DNS precisaro de recursos
que o UDP no dispe. O TCP orientado a conexo, ou seja, trata de perda de pacotes,
retransmisses e reordenao dos pacotes, alm do uso de mecanismos prprios para controle de
fluxo. Assim, os ataques que visam s vulnerabilidades inerentes ao protocolo UDP no sero
mais realizados.
O DNSSEC dispe da checagem da integridade dos dados fim-a-fim, ou seja, desde sua origem
at seu destino, sendo a melhor soluo para problemas de interceptao de pacotes durante uma
operao de pesquisa DNS, pois executa todas as checagens de assinaturas previstas no
DNSSEC, pode re-assinar os pacotes em caso de ataques de interceptao de pacotes e ainda
pode utilizar o TSIG para assegurar-se da integridade da comunicao entre um cliente e o
servidor.
As transferncias de zonas e atualizaes dinmicas, onde ocorrem as transaes das mensagens
DNS, so protegidas por um mecanismo de autenticao destas transaes, chamado TSIG
(Transaction Signature), que utilizado para a verificao da autenticidade das mensagens DNS,
especialmente as respostas e as atualizaes.
O TSIG utiliza criptografia simtrica, ou seja, a mesma chave que usada para criptografar a
mesma usada para descriptografar. Esta chave chamada de chave secreta compartilhada. As
assinaturas TSIG so verificadas no momento do recebimento dos pacotes e depois so
descartados, servindo apenas para verificar que o remetente da mensagem tem uma chave
compartilhada e que esta mensagem no foi modificada aps seu envio. O processo de
autenticao realizado atravs do hash-based message authentication codes (HMAC), que
utiliza como parmetros a mensagem de entrada e a chave secreta. Por ser um meta-registro que
nunca aparece nos dados da zona e nunca armazenado, sendo includo apenas na mensagem do
DNS, ele no utilizado pelo DNSSEC, e por esta razo mais utilizado nas transferncias de
zona e atualizaes dinmicas.
O DNSSEC em si no oferece proteo contra o ataque server compromising, pois ele no tem
como proteger um servidor de nomes de ser atacado. Porm, se isto acontecer e um atacante
conseguir alterar dados da zona, gerar seu prprio par de chaves e re-assinar a zona, o DNSSEC
oferece a proteo da chamada cadeia de confiana, onde uma zona superior quela contida no
servidor invadido certifica a chave pblica de sua zona filha. Atravs do registro DS, contido no
47
DNSSEC e ausente na definio padro do DNS, a divulgao destas alteraes podem ser
inibidas.
O DNS vulnervel ao spoofing e ao cache poisoning porque no utiliza autenticao dos dados.
Com a utilizao do DNSSEC, autenticando a origem dos dados informados a um cliente, este
poder certificar-se de que o nome do domnio referente a um determinado endereo IP realmente
pertence quele endereo IP, atravs da assinatura digital e da chave pblica daquela zona.
48
O mecanismo do DNSSEC tambm no oferece segurana contra as vulnerabilidades referente a
transaes tipo transferncia de zonas e atualizaes dinmicas. Estas transaes contam com
uma proteo especial, descrita na RFC 2137. A autenticao de mensagens DNS descrita na
RFC 2845.
O conjunto de documentos que formam o ncleo das extenses de segurana do DNS formado
pelas RFCs 4033, 4034 e 4035. Devido a estas mudanas, o DNSSEC no fornece
confidencialidade.
Mais alguns problemas do DNSSEC so listados a seguir [27]:
Assinatura de grandes zonas: as TLDs, por exemplo, contm um banco de dados com
milhes de delegaes. Para assinar toda esta zona,so necessrios vrias horas e dias,
dependendo do hardware e software disponvel, sem contar que assinar uma zona aumenta
em cerca de sete vezes seu tamanho.
Um estudo publicado pelo RIPE NCC / NLnet Labs [38], em Outubro de 2005, mede quais os
recursos necessrios, em termos de mquinas, para a implementao do DNSSec. Foram medidos
recursos como uso de CPU, memria e banda consumida. O resultado do estudo mostra que a
medio do impacto da implementao do DNSSec depende de muitas variveis, e que a
implementao em larga escala torna-se difcil, pois, segundo os resultados obtidos, muitos
49
servidores de nomes teriam que atender aos recursos de mquinas demandados pela
implementao do DNSSec.
Outro fator que dificulta a implementao do DNSSec so os softwares que o suportam. O mais
utilizado o BIND (Berkeley Internet Name Domain). Sua popularidade deve-se principalmente
por ser um software gratuito, originado de um projeto da Universidade da Califrnia e ser
includo em sistemas operacionais como Solaris, Mac OS X, Linux e BSD, por exemplo, alm de
possuir verso para Windows. As verses mais novas do BIND suportam a implementao do
DNSSec, com a habilidade de assinar zonas, gerar diferentes tipos de chaves e manipular zonas
assinadas e RRs. Suporta tambm transaes seguras utilizando o TSIG.
Porm, o BIND possui algumas vulnerabilidades, mostradas a seguir:
Cache Poisoning: quando atacado desta forma, o servidor BIND forado a realizar suas
consultas de DNS em um servidor de DNS especificado pelo intruso. Assim, o intruso
consegue passar resultados falsos para as consultas do servidor atacado, que por sua vez,
passar esses resultados para seus clientes. Ento, os clientes estaro acessando sites
falsos (por conta do redirecionamento do mapeamento IP no servidor remoto) o que pode
acarretar em srios problemas;
Pesquisa reversa: neste tipo de ataque, o intruso pode conseguir acesso de root no servidor
atacado ou at causar a parada total do sistema. Por padro, os servidores no respondem
a pesquisas falsas, porm, se estiverem configurados para responder a essas pesquisas,
podem sofrer este tipo de ataque;
DoS: as verses mais atuais do BIND conseguem trabalhar muito bem com a questo do
DoS, porm verses mais antigas podem cair facilmente nesta armadilha e se tornarem
inoperantes. Este seria um dos vrios motivos para utilizar as ltimas verses estveis do
software;
Existem vrios outros softwares que implementam o DNS som suporte ao DNSSec, como o NSD
(Name Server Daemon), por exemplo, no to complexo quanto o BIND, mas tambm open
source, tem suporte ao DNSSec e pode ser utilizado em cenrios simples. O Microsoft Server
2003 apenas suporta armazenamento e carga de zonas assinadas, mas no capaz de validar e
assinar RRSIGs. Pode-se citar tambm como exemplos de softwares que implementam o DNS, o
DNSJava, NET::DNS::SEC, Dents (http://www.dents.org), Djbdns (http://cr.yp.to/djbdns.html),
MaraDNS (http://www.maradns.org), CustomDNS (http://customdns.sourceforge.net/), Ibnamed
(http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html/) e Ibdns [40][41].
50
5. Concluso
Segundo dados da ICANN de novembro de 2004, so realizadas cerca de 20 bilhes de
resolues DNS por dia, mais de 700 milhes de usurios utilizam a Internet todo dia e 313
milhes de endereos IPV4 (endereos IP verso 4, atualmente utilizado) foram alocados desde
1999 [36].
Com estes dados, podemos observar que o sistema de nomes de domnio um dos principais
mecanismos do funcionamento da Internet. Porm, suas definies e funcionamento contm
falhas que podem levar a srias conseqncias, como a falsificao da informao,
redirecionamento do trfego e roubo de dados de usurios.
As extenses de segurana do DNS, chamada de DNSSEC tentam minimizar estas falhas,
utilizando-se da criptografia para codificar as informaes e garantir sua autenticidade. Mas este
novo mecanismo tambm apresenta falhas e motivos que dificultam sua implantao.
Os custos da adoo do DNSSEC passam por diversos fatores, como o aumento da performance
dos atuais servidores DNS, incluindo aumento da memria, CPU e banda destes. Custos
adicionais como software, treinamento de pessoal especializado, gerenciamento de chaves,
interao com entidades certificadoras e mantenedoras dos servidores root do DNS devem ser
analisados.
Atualmente, existem grupos de parceiros que desenvolvem e divulgam o uso do DNS, como o
DNSSEC Deployment Initiative Coordination Partners, que incluem empresas e rgos como o
NIST (EUA), Sparta, INC, Shinkuro, INC (EUA), SRI (EUA), NLnetLabs (Holanda). Outros
rgos, como PIR (EUA), RIPE (Europa - Londres), TLD.se (Sucia), o TLD experimental.nl.nl
(Holanda) e Verisign j adotaram e ainda desenvolvem projetos para o DNSSEC.
A adoo do DNSSEC em larga escala um processo lento e poder levar alguns anos at ser
totalmente implantado, pois ainda necessita de muitas melhorias e pesquisa para minimizar seus
custos. Sua adoo em larga escala enfrentaria grandes dificuldades, pois o processo de resoluo
de validao de nomes tornaria-se muito mais lento, mas futuramente ser um recurso mais
seguro, necessrio e confivel de se utilizar.
51
6. Referncias
[1]
[2]
[3]
ALBITZ, Paul, LIU, Cricket. DNS e BIND, 4 ed., Rio de Janeiro, Campus 2001.
[4]
COMER, Douglas E. Interligao em rede com TCP/IP, Rio de Janeiro, Campus, 1998.
[5]
[6]
[7]
PFLEGER, Jurgen. DNSSEC Resolver Algorithm, Master Thesis, Wien, Austria, 2003.
Disponvel em: (http://mitglied.lycos.de/pflegerjuergen/download/DNSSEC_Resolver.pdf)
[8]
[9]
[10] STEWART Joe, DNS Cache Poisoning The Next Generation, LURHQ Threat
Intelligence Group. Disponvel em (http://www.lurhq.com/cachepoisoning.html).
[11] SCHUBA, Christoph, Addressing Weakness in the Domain Name System Protocol,
Thecnical Report, Department of Computer Sciences, Pardue University, 1993. Disponvel
em (http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf).
[12] SAX, Doug., DNS Spoofing (Malicious Cache Poisoning). 12 Nov. 2000. 15 Dec 2002
Disponvel em: (http://rr.sans.org/firewall/DNS_spoof.php).
[13] Microsoft Technet, Microsoft Windows Server 2003 Tech Center, Atualizao Dinmica,
2001. Disponvel em
(http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ptbr/library/ServerHelp/e760737e-9e55-458d-b5ed-a1ae9e04819e.mspx)
[14] MARIZ, Dnio, "Ataques & Ferramentas Algumas ferramentas e tcnicas de ataque".
Notas de Aula, 2005
[15] RFC 2535 - Eastlake 3rd, D., "Domain Name System Security Extensions, Maro 1999.
[16] RFC 2536 - Eastlake 3rd, D., "DSA Keys and SIGs in the Domain Name System (DNS),
Maro 1999.
[17] RFC 1034 - Mockapetris, P., "Domain Names - Concepts and Facilities", Novembro de
1987.
[18] RFC 1035 - Mockapetris, P., "Domain names - Implementation and Specification",
Novembro de 1987.
[19] RFC 3225 Conrad, D., Indicating Resolver Support of DNSSEC, Dezembro de 2001.
[20] RFC 3833- Atkins, D., Threat Analysis of the Domain Name System, Agosto de 2004.
52
[21] RFC 2136 Vixie, P. Dynamic Updates in the Domain Name System (DNS UPDATE,
Abril de 1997.
[22] RFC 2137 - Eastlake 3rd, D., Secure Domain Name System Dynamic Update, Abril de
1997
[23] RFC 2671 - Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, Agosto de
1999.
[24] JUNIOR, Jos. H. T., MOURA, Jos A. B., SAUV, Jcques P., Disponibilizao de
Nomes de Diretrios Distribudos atravs do DNS, DSC/UFPB. Disponvel em
(http://www.las.ic.unicamp.br/paulo/wais96/papers-tech/helvecio-dns-rev.pdf).
[25] LIMA, Marcelo B., Proviso de Servios Inseguros Usando Filtros de Pacotes com
Estados, Dissertao de Mestrado, Instituto de Computao, Universidade Estadual de
Campinas, 2000. Disponvel em: (http://www.kcmelo.com/Files/Dissertacao_MBL.pdf).
[26] POUW, Kessje D., Segurana na Arquitetura TCP/IP: de Firewalls a canais seguros,
Dissertao de Mestrado, Instituto de Computao, Universidade Estadual de Campinas,
1999. Disponvel em: (http://www.las.ic.unicamp.br/paulo/teses/19990208-MScKeesje.Duarte.Pouw-Seguranca.na.arquitetura.TCPIP-De.firewalls.a.canais.seguros.pdf).
[27] NEMETH, Evi. Securing the DNS. ;login: The Magazine of Usenix & Sage, Nov. 2000.
Disponvel em: (http://www.usenix.org/publications/login/2000-11/pdfs/dns.pdf)
[28] RFC 3110 - Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)",.Maio de 2001.
[29] RFC 3757 KOLMAN, O., "Domain Name System KEY (DNSKEY) Resource Record (RR)
Secure Entry Point (SEP) Flag ", Abril de 2004.
[30] RFC 4033 ARENDS, A., DNS Security Introduction and Requirements. Maro de 2005.
[31] RFC 4034 ARENDS, A., Resource Records for the DNS Security Extensions. Maro de
2005.
[32] RFC 4035 ARENDS, A., Protocol Modifications for the DNS Security Extensions. Maro
de 2005.
[33] RFC 3845 SCHLYTER, J., DNS Security (DNSSEC) NextSECure (NSEC) RDATA
Format, Agosto de 2005.
[34] RFC 3658 GUDMUNDSSON, O., Delegation Signer (DS) Resource Record (RR),
Dezembro de 2003.
[35] EVERS, J., DNS Servers do hackers dirty work. CNET News.com, Maro de 2006.
Disponvel em: (http://news.com.com/DNS+servers+do+hackers+dirty+work/2100-7349_36053468.html).
[36] ICANN Internet Corporation for Assigned Names and Numbers, Plano Estratgico para
ICANN 2003-2004 a 2006-2007, Novembro de 2004. Disponvel em:
(http://www.icann.org/strategic-plan/strategic-plan-16nov04.pdf)
[37] FECHINE, Joseana. Criptografia, protocolos seguros e suas aplicaes, Notas de aula,
partes I,II,III e IV, 2005.
[38] OLSEN, Camila. Security issues relating to the use of UDP, Research on Topics in
Information Security, Option 1, GSEC Certification Practical Assignment Version 1.4 b,
SANS Institute, 2004.
[39] KOLMAN, O. Measuring the resource requirements of DNSSEC, RIPE NCC / NLnet
Labs, RIPE-352, Outubro de 2005.
53
[40] HOMBLAD, J. The Evolving Threats to the Availability and Security of the Domain Name
Service, SANS GIAC/GSEC Practical, Outubro de 2003.
[41] KARLOV, A. DNSSEC: DNS Security Extensions, cole Polytechnique Fdrale de
Lausanne, Maio de 2004.