Estudo e realização de uma instalação piloto de DNSSEC para o DNS de .PT

(1)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

ESTUDO E REALIZAC

¸ ˜

AO DE UMA

INSTALAC

¸ ˜

AO PILOTO DE DNSSEC PARA O

DNS DE .PT

Sara Cristina da Silva Monteiro

Mestrado em Engenharia Inform´

atica

(2)

(3)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

ESTUDO E REALIZAC

¸ ˜

AO DE UMA

INSTALAC

¸ ˜

AO PILOTO DE DNSSEC PARA O

DNS DE .PT

Sara Cristina da Silva Monteiro

Projecto orientado pelo Prof. Dr. Miguel Pupo Correia e co-orientado por Dra _{Lu´ısa Gueif˜}_ao

Mestrado em Engenharia Inform´

atica

(4)

(5)

Declara¸

c˜

ao

Sara Cristina da Silva Monteiro, aluna no 29264 da Faculdade de Ciências da Universidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado “Estudo e realiza¸cão de uma instala¸cão piloto de DNSSEC para o DNS de .PT” , realizado no ano lectivo de 2006/2007 à Faculdade de Ciências da Universidade de Lisboa para o efeito de ar-quivo e consulta nas suas bibliotecas e publica¸cão do mesmo em formato electrónico na Internet.

FCUL, 31 de Agosto de 2007

Lu´ısa Lopes Gueifão, supervisora do projecto de Sara Cristina da Silva Mon-teiro, aluna da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a divulga¸cão do Relatório do Projecto em Engenharia Informática, intitulado “Estudo e realiza¸cão de uma instala¸cão piloto de DNSSEC para o DNS de .PT”. Lisboa, 31 de Agosto de 2007

(6)

(7)

Resumo

O DNS (Domain Name System - Sistema de Nomes de Dom´ınios) ´e uma das ferramentas fundamentais para o funcionamento da Internet que permite localizar e resolver nomes de dom´ınio em endere¸cos IP e vice-versa.

Com o crescimento da Internet e do número de utilizadores os perigos e a neces-sidade para a consciencializa¸cão da seguran¸ca aumentaram, revelando-se de extrema importância a procura de solu¸cões que garantam um ambiente mais seguro no servi¸co e na rede.

Nesse sentido desenvolveu-se internacionalmente o DNSSEC, um conjunto de extens˜oes realizadas ao protocolo DNS que permitem a verifica¸c˜ao da autenticidade e integridade dos dados e com o qual se pretende proteger a Internet e os seus utilizadores de determinado tipo de ataques.

Este projecto aborda o processo de análise e integra¸cão das extensões de segu-ran¸ca ao protocolo DNS no servi¸co de registo de dom´ınios sob a designa¸cão .PT, prestado pela FCCN, com vista a alcan¸car melhorias de seguran¸ca a n´ıvel da rede nacional e contribuindo para tornar a Internet mais segura a n´ıvel global.

(8)

(9)

Abstract

In order to access Internet resources using the user-friendly domain names rather than IP addresses, users need a system to translate domain names into IP addresses. This translation is the primary task of the Domain Name System (DNS).

The Internet is the world’s largest computing network, with hundreds of million of users. As this community grows there is a need to be aware of threats and dangers and to find solutions for secure service and network environments.

In that sense, a community of Internet developers designed DNSSEC, a set of extensions to the DNS system to prevent some types of attacks against it, performing source authentication of domain name information and maintaining data integrity.

This project focus on the process of analysis and integration of the DNSSEC extensions in the .PT domain name service, handled by FCCN, in order to reach some security improvements in the national network and to give some contribution to a more secure world wide Internet.

(10)

(11)

Conte´

udo

Lista de Figuras vii

Lista de Tabelas ix 1 Introdu¸c˜ao 1 1.1 Enquadramento Institucional . . . 1 1.2 Organiza¸c˜ao do documento . . . 3 2 Objectivos 4 2.1 Ambito do projecto . . . .ˆ 4 2.1.1 Domain Name Service . . . 4

2.1.2 Vulnerabilidades de seguran¸ca . . . 7

2.1.3 Origem do DNSSEC . . . 11

2.1.4 Trabalho Relacionado . . . 12

2.2 Defini¸c˜ao dos Objectivos . . . 14

2.3 Planeamento . . . 14

2.3.1 Metodologia utilizada . . . 15

2.3.2 Calendariza¸c˜ao . . . 15

3 Trabalho Realizado 17 3.1 An´alise Funcional . . . 17

3.1.1 Criptografia e Assinaturas . . . 17

3.1.2 Extens˜oes ao protocolo DNS . . . 20

3.1.3 Algoritmos e tipos de s´ıntese de DNSSEC . . . 25

3.2 Adop¸c˜ao do DNSSEC . . . 27

3.2.1 Requisitos . . . 27

3.2.2 Novas Vulnerabilidades . . . 28

3.3 Implementa¸c˜oes Existentes . . . 30

3.4 Concretiza¸c˜ao e Testes . . . 30

3.4.1 Hierarquia org.pt assinada . . . 30

3.4.2 Resultados Obtidos . . . 33

3.5 Integra¸c˜ao com o sistema actual . . . 37

(12)

3.5.1 Gest˜ao atrav´es da interface ‘Online’ . . . 37

3.5.2 Integra¸c˜ao no protocolo EPP . . . 38

3.5.3 Informa¸c˜ao da autenticidade da delega¸c˜ao . . . 38

3.5.4 Comandos EPP . . . 38

3.6 Prepara¸c˜ao de um Workshop . . . 41

4 Sumário e Conclusões 43 4.1 Conclusão . . . 43 4.2 Trabalho Futuro . . . 44 Acrónimos 46 Bibliografia 48 A Planeamento do Projecto i vi

(13)

Lista de Figuras

2.1 Estrutura em ´arvore do DNS . . . 5 2.2 Zona de dom´ınios . . . 6 2.3 Delega¸c˜ao de um subdom´ınio . . . 7 2.4 Vulnerabilidades do servi¸co DNS . . . 10 3.1 Criptografia . . . 18

3.2 Criptografia Assim´etrica . . . 18

3.3 Assinatura Digital . . . 20

3.4 Exemplo de um DNSKEY resource record . . . 21

3.5 Exemplo de um RRSIG resource record . . . 22

3.6 Exemplo de um NSEC resource record . . . 23

3.7 Exemplo de um DS resource record . . . 24

3.8 Segmento da zona pai assinada (zona org.pt) . . . 31

3.9 Dimens˜ao da zona vs. zona assinada . . . 33

3.10 Tempo de assinatura de uma zona . . . 34

3.11 DiG realizado a um dom´ınio assinado . . . 36

3.12 DiG realizado `a zona org.pt . . . 36

3.13 Gestor Online de dom´ınios .PT . . . 37

3.14 Comando EPP: <info> . . . 39

3.15 Comando EPP: <create> . . . 40

3.16 Comando EPP: <update> . . . 40

3.17 Convite de participa¸c˜ao no Workshop . . . 41

A.1 Calendariza¸c˜ao das tarefas (Gantt Project) . . . i

A.2 Mapa de Gantt . . . ii

(14)

(15)

Lista de Tabelas

2.1 Tipos de resource records (RRs) . . . 6

2.2 Projectos desenvolvidos e base de dados de teste . . . 12

3.1 Tipos de algoritmos . . . 26

3.2 Tipos de s´ıntese . . . 26

(16)

(17)

Cap´ıtulo 1

Introdu¸

c˜

ao

Este documento descreve o projecto realizado no ˆambito da disciplina Projecto em Engenharia Inform´atica (PEI1_{) do Mestrado em Engenharia Inform´}_{atica da}

Fac-uldade de Ciˆencias da Universidade de Lisboa.

Num mundo de comunica¸cão global e distribu´ıda, é fundamental que os sistemas informáticos utilizados ofere¸cam cada vez mais garantias de seguran¸ca.

O projecto aborda a problemática da falta de seguran¸ca na utiliza¸cão do servi¸co de nomes de dom´ınio (DNS) [1]. É apresentada uma solu¸cão a algumas das vulnera-bilidades no sistema existente, utilizando a implementa¸cão de extensões de seguran¸ca ao DNS, DNSSEC [2].

O DNS não foi originariamente desenhado com preocupa¸cões de seguran¸ca, mas perante a crescente importância da informa¸cão que este servi¸co fornece, tornou-se importante ao longo do percurso de expansão da Internet assegurar a comunica¸cão entre os sistemas informáticos.

O DNSSEC consiste num conjunto de normas internacionais que extendem a tecnologia DNS, fornecendo integridade e autentica¸c˜ao dos dados, com suporte a respostas assinadas criptograficamente.

Este trabalho tem como objectivo melhorar a seguran¸ca do DNS do servi¸co de registo de dom´ınios .PT [3] atrav´es da implementa¸c˜ao do DNSSEC.

1.1 Enquadramento Institucional

A FCCN [4] é uma institui¸cão privada sem fins lucrativos designada de utilidade pública que iniciou a sua actividade em Janeiro de 1987. Desde então, com o apoio das Universidades e diversas institui¸cões de I&D nacionais, a FCCN tem contribu´ıdo para a expansão da Internet em Portugal.

1_{http://www.di.fc.ul.pt/disciplinas/pei/pei0607/}

(18)

Cap´ıtulo 1. Introdu¸c˜ao 2

Como principal actividade a FCCN tem o planeamento, gestão e opera¸cão da Rede Ciência, Tecnologia e Sociedade (RCTS), uma rede de alto desempenho para fins de investiga¸cão e ensino nacional, constituindo-se assim uma plataforma de experimenta¸cão para aplica¸cões e servi¸cos avan¸cados de comunica¸cões.

A RCTS é uma rede informática que usa os protocolos da Internet para garantir uma plataforma de comunica¸cão e colabora¸cão entre as institui¸cões do sistema de ensino, ciência, tecnologia e cultura.

B-ON - Biblioteca Cient´ıfica Nacional, E-U - Campus Virtual, 6Net e mais recen-temente o Portal Internet Segura, s˜ao muitos dos in´umeros projectos desenvolvidos pela FCCN.

`

A FCCN, foi ainda delegada pela IANA - Internet Assigned Numbers Authority, organiza¸c˜ao depois substitu´ıda pelo ICANN - Internet Corporation for Assigned Names and Numbers, a responsabilidade pela gest˜ao do ccTLD (country code Top Level Domain) .PT, o servi¸co de registo de dom´ınios sob o dom´ınio nacional .PT.

A n´ıvel internacional, a FCCN tem vindo a participar activamente, na qualidade de membro e de interveniente, em reuniões e grupos de trabalho de organiza¸cões cre-denciadas no âmbito da Internet como o ICANN e o CENTR - Council of European National Top level domain Registries.

No ˆambito das recomenda¸c˜oes emanadas por estas entidades, a FCCN pretende desenvolver trabalho no sentido de garantir tecnicamente, entre outros aspectos:

• A gestão técnica e administrativa do espa¸co de endere¸cos Internet sob .PT; • A correcta configura¸cão e opera¸cão do servidor primário da zona DNS PT; • A manuten¸cão de uma base de dados dos dom´ınios registados, acess´ıvel via

Internet;

• A disponibiliza¸cão de dados estat´ısticos sobre o registo de dom´ınios de .PT; • A avalia¸cão do servi¸co prestado à comunidade.

O Servi¸co DNS de .PT consiste num servi¸co autónomo no âmbito das actividades da FCCN e tem no seu grupo uma área técnica de suporte ao seu trabalho de sistema de nomes de dom´ınios de .PT.

Enquadrado neste grupo, este est´agio consistiu numa primeira fase de cerca de 4 meses, no conhecimento dos diversos projectos da FCCN e no acompanhamento do trabalho do DNS de .PT, sendo posteriormente dedicado exclusivamente a este projecto.

Atento o facto do DNS ser o sistema de atribui¸cão de endere¸cos IP a nomes de dom´ınios, desde logo se tornou evidente e motivador o desenvolvimento deste trabalho quer pela sua componente técnica quer pelo impacto positivo e alargado que o funcionamento real de uma implementa¸cão de DNSSEC potencia e garante.

(19)

Cap´ıtulo 1. Introdu¸c˜ao 3

1.2 Organiza¸

c˜

ao do documento

O relat´orio encontra-se organizado da seguinte forma:

• Cap´ıtulo 2 - “Objectivos” - apresenta os objectivos do projecto, o contexto subjacente, a metodologia utilizada e o planeamento realizado para o con-cretizar.

• Cap´ıtulo 3 - “Trabalho Realizado” - apresenta concretamente o que se fez e as ferramentas utilizadas. São aqui também apresentadas as possiblidades de tra-balho futuro e os poss´ıveis métodos de integra¸cão das extensões de seguran¸ca ao sistema actual.

• Cap´ıtulo 4 - “Sumário e Conclusões” - apresenta um sumário do trabalho realizado, o que ainda está por realizar e as conclusões tiradas com a realiza¸cão do projecto.

(20)

Cap´ıtulo 2

Objectivos

Este cap´ıtulo introduz o contexto em que o projecto se enquadra, os conceitos importantes para a compreensão do trabalho realizado, os objectivos e a motiva¸cão que levou à concretiza¸cão deste trabalho. Apresenta também alguns trabalhos rela-cionados, com grande relevância no âmbito em que se insere este projecto.

Por fim, é apresentada uma seçcão com a metodologia seguida no desenvolvi-mento do projecto bem como o planeadesenvolvi-mento efectuado para o concretizar.

2.1 Ambito do projecto

ˆ

2.1.1 Domain Name Service

A Internet existe desde que o protocolo TCP/IP (Transmission Control Proto-col/Internet Protocol) foi desenvolvido no in´ıcio dos anos 70. Tornou-se rapidamente o protocolo padrão de rede no ARPANET. Desde então a rede tem crescido de cen-tenas para milhões de utilizadores.

Desde cedo que os computadores ligados entre si em rede tiveram a necessidade de sistemas que os permitissem identificarem-se rapidamente, para tal, todos os computadores passaram a ter um nome associado. Esses nomes na Internet no entanto eram inicialmente inclu´ıdos num ´unico ficheiro designado “hosts.txt”que tinha de ser instalado em todos os computadores que faziam parte da rede.

O Stanford Research Institute Network Information Center (SRI-NIC) tornou-se na autoridade responsável por gerir e distribuir esse ficheiro. Mais tarde, a necessi-dade de um único dom´ınio para cada computador e um espa¸co de nomes hierárquico preparou o lan¸camento de um novo protocolo de rede que viria preencher todos os requisitos da Internet em crescente expansão.

(21)

Cap´ıtulo 2. Objectivos 5

Em adi¸cão ao TCP/IP, dois grandes protocolos foram desenhados nos anos 80 para permitir que o crescimento da rede ocorresse com maior facilidade. Estes protocolos são o DNS (Domain Name Service) e BGP (Border Gateway Protocol). Juntos, estes três protocolos compoêm o núcleo de infrastrutura da Internet.

P. Mockpetris desenhou o sistema de servi¸co de nomes de dom´ınios (DNS) com vista à estabilidade e robustez mas sem preocupa¸cões de seguran¸ca [1]. A nova ideia surgiu por forma a não haver uma única entidade responsável pelo ficheiro de nomes mas sim uma imensidade de entidades.

O novo sistema DNS, baseado no conceito de descentraliza¸cão, tem três grandes componentes: a base de dados; o servidor; e o cliente. A base de dados é distribu´ıda e contém os resource records (RRs) dos dom´ınios que definem a zonas de dom´ınios numa árvore DNS, como a apresentada na Figura 2.1. Estes RRs são registos de recurso que delegam a autoridade de configura¸cão de uma zona a uma determinada entidade.

Figura 2.1: Estrutura em ´arvore do DNS

A tarefa de atribuir nomes a servidores e dom´ınios de rede é conseguida criando um rela¸cão hierárquica entre os dom´ınios, com os servidores como últimos descen-dentes da cadeia e uma raiz (“root”) artificial como topo desta.

Adicionando etiquetas de nomes umas a seguir às outras criando um caminho do servidor até à raiz, numa forma de árvore hierárquica, um identificador único, memorizável e de fácil utiliza¸cão é criado e designa-se de nome de dom´ınio.

O DNS providencia resolu¸cão em ambas as direçcões, isto é, dado um dom´ınio, devolve o endere¸co IP apropriado e vice versa, através da utiliza¸cão dos resource

(22)

records. Estes RRs fazem parte da configura¸cão dos dom´ınios e encontram-se ar-mazenados em ficheiros de zona que contém os dados necessários para resolver os pedidos de nomes associados ao dom´ınio da qual a zona é responsável. A Tabela 2.1 lista alguns dos principais tipos de RRs que se podem encontrar nos ficheiros de zona presentes nos servidores DNS:

SOA Autoridade para os dados do dom´ınio NS Servidor de nomes para o dom´ınio A Endere¸co IP (Internet Protocol)

PTR DNS Reverso, de endere¸cos IP para nomes CNAME Nome can´onico (Alias)

TXT Informa¸c˜oes textuais WKS Well-Known Services

HINFO Informa¸c˜ao do servidor (Host Information) MX Mail Exchanger

Tabela 2.1: Tipos de resource records (RRs)

O espa¸co de nomes de dom´ınio é uma especifica¸cão de uma árvore estruturada (ver Figura 2.2). A raiz da árvore trata-se da raiz do dom´ınio seguida pelos seus filhos, os dom´ınios de topo (TLD), que podem conter diversos n´ıveis de subdom´ınios até um total de 127, e o nome completo de dom´ınio não pode ultrapassar os 255 caracteres.

(23)

Os nomes de dom´ınios consistem na concatena¸cão das etiquetas de cada nó (dom´ınios) separadas por ponto, no caminho que vai desde a folha, que representa a máquina actual, até à raiz. Os dom´ınios são sub-árvores do espa¸co de nomes.

No exemplo da Figura 2.2, “dnssec.org.pt” é o nome de dom´ınio de um nó cujo nome é ‘dnssec’, o seu pai é ‘org’, o seu avô é ‘pt’ e o seu bisavô a raiz.

Uma zona é um conjunto de dom´ınios, subdom´ınios e máquinas, a quem foi delegada autoridade de gestão pelo n´ıvel hierarquicamente superior e também inclui todos os nomes de dom´ınio de n´ıveis inferiores que ainda não tenham sido delegados. Na Figura 2.3 é exemplificada uma delega¸cão de um subdom´ınio onde são indi-cados os RRs do servidor de nomes (NS) e o respectivo endere¸co IP.

Figura 2.3: Delega¸c˜ao de um subdom´ınio ´

E superior hierárquico de todas as zonas, o n´ıvel máximo dos dom´ınios de topo, este denomina-se de raiz e é representa-se simbolicamente com um ponto.

Uma zona pode ter vários servidores de DNS e cada servidor de DNS servir mais do que uma zona. No entanto, um mesmo servidor DNS não pode servir duas zonas hierarquicamente relacionadas. Isto é, não pode ser servidor DNS da zona A e B simultaneamente, se a zona A delegou autoridade na zona B, ou se a zona B delegou autoridade na zona A.

2.1.2 Vulnerabilidades de seguran¸

ca

´

E do conhecimento geral que o servi¸co de nomes DNS, consistindo num protocolo de comunica¸cão de elevada importância para o funcionamento de infra-estruturas globais como a Internet, apresenta inúmeras fragilidades.

A resolu¸cão de nomes é um dos aspectos mais cr´ıticos de interaçcão entre pessoas, servi¸cos e máquinas. No universo da Internet existem inúmeros servidores de nomes, com graus de abrangência muito distintos, que estão permanentemente envolvidos quando se trata de estabelecer uma interaçcão entre duas entidades, sejam elas pessoas, servi¸cos ou máquinas.

A interferência com o servi¸co DNS permite realizar ataques de personifica¸cão de máquinas ou servi¸cos. A personifica¸cão de servi¸cos, ou máquinas onde os mesmos se executam, consiste em enganar os seus clientes e levá-los a comunicar com um

(24)

servi-Cap´ıtulo 2. Objectivos 8

dor impostor. Para isso h´a que conduzir a comunica¸c˜ao do cliente para o servidor impostor sem que o cliente e o servidor leg´ıtimo se apercebam.

Uma forma de efectuar personifica¸cões de servidores é registando nomes DNS fraudulentos, aparentando representar uma entidade que efectivamente, não rep-resentam. É relativamente fácil enganar utilizadores fornecendo-lhes nomes DNS cred´ıveis mas enganadores.

Uma outra forma de promover o uso de servidores falsos é interferir com o pro-cesso de resolu¸cão de nomes DNS. Este processo é conhecido como DNS spoofing.

A especifica¸cão inicial do DNS não contemplava quaisquer pol´ıticas ou mecan-ismo de seguran¸ca para evitar ataques à resolu¸cão de nomes. Pelo contrário, o seu desenho contemplou fundamentalmente aspectos de eficácia, eficiência e escal-abilidade. Por este facto, essa especifica¸cão possu´ıa diversas vulnerabilidades de seguran¸ca que foram exploradas aos longo dos anos para induzir erros na resolu¸cão de nomes DNS. Como reaçcão, apareceram diversas pol´ıticas e mecanismos que procuram eliminar e minizar esses riscos, como é o caso das extensão de seguran¸ca DNSSEC [5].

A técnica mais frequente para efectuar DNS spoofing passa pelo envenenamento de caches DNS (DNS cache poisoning). O princ´ıpio é simples: quando um servidor DNS pede a outro que lhe resolva um nome a resposta é autenticada de forma fraca. Qualquer um pode enviar respostas falsas para um servidor DNS e, se as mesmas forem aceites, introduzir resolu¸cões de nomes erradas. Como os servidores DNS, por razões de eficiência, vão guardar essa informa¸cão em cache (memória temporária) durante algum tempo, tempo esse que depende do servidor e da informa¸cão afecta ao nome, enquanto a informa¸cão errada estiver em cache esta última está “envenenada” e permite efectuar DNS spoofing.

O envenenamento da mem´oria de cache pode ser aplicado maliciosamente para fins como:

• Indisponibilidade do servi¸co (DoS - Denial of Service); • Personifica¸c˜ao de entidades de confian¸ca;

Transferˆencia de zona

Pelo papel importante que as zonas desempenham no DNS, pretende-se que estas estejam dispon´ıveis aos clientes DNS a partir de mais de que um servidor de DNS na rede para fornecer disponibilidade e tolerância a falhas aquando da resolu¸cão de consultas de nomes. Caso contrário, se for utilizado um servidor único e este não estiver a responder, as consultas de nomes na zona poderão falhar.

(25)

Para os servidores adicionais hospedarem uma zona, é necessário que as trans-ferências de zona efectuem a replica¸cão e sincronizem todas as cópias da zona uti-lizada em cada servidor configurado para hospedar a zona.

Quando é adicionado um novo servidor de DNS à rede e é configurado como um servidor secundário para uma zona existente, este efectua uma transferência inicial total da zona para obter e replicar uma cópia completa dos resource records da zona. Mas por vezes ocorrem ataques que visam a obten¸cão da zona por meio de transferência da mesma para futuras modifica¸cões ou exposi¸cão da informa¸cão para interpreta¸cão da arquitectura do sistema. Deve-se, portanto, limitar os sistemas que podem fazer a transferência de zona dos seus servidores de nomes.

Envenenamento da mem´oria tempor´aria DNS

Seguindo o exemplo que se apresenta, vejamos como ´e que uma t´ecnica de DNS spoofing pode funcionar:

Um utilizador quer ligar-se a um servidor remoto ‘A’ com um cliente telnet. A aplica¸cão do cliente telnet questiona o cliente DNS (Resolver) para determinar o endere¸co IP do servidor ‘A’. O cliente recebe uma resposta falsa do servidor DNS que o encaminha para um servidor remoto gerido pelo atacante (que alterou previamente na memória cache do servidor DNS um endere¸co IP incorrecto). Por causa dos dados manipulados, a aplica¸cão telnet inicia uma sessão TCP com o servidor errado ‘B’. O utilizador não se apercebe e envia o seu login e password directamente para o atacante. O atacante atinge assim o seu objectivo e restaura a liga¸cão. O utilizador recebe uma mensagem de erro e repete a sua tentativa de login, desta vez com sucesso, porque desta vez o cliente DNS obteve o endere¸co de IP correcto da resposta ao servidor ‘A’ que não se encontra manipulado.

O cenário demonstrado torna claro que quando um atacante corrompe um servi-dor DNS com informa¸cão maliciosa pode redireccionar tráfego sempre que quiser, para onde quiser. Isto é poss´ıvel porque quase todas as aplica¸cões dependem da resolu¸cão de nomes para endere¸cos providenciada pelo DNS. As técnicas de redirec-cionamento do tráfego da rede por manipula¸cão da informa¸cão do DNS são conheci-das como “DNS hijacking”, “DNS spoofing” ou “DNS poisoning”.

Ao longo dos anos os atacantes registaram os seus próprios servidores de DNS e manipularam servidores DNS bem conhecidos. Um servidor DNS manipulado que está a responder a mensagens poderá incluir dados na seçcão adicional, que não estão directamente relacionados com a resposta. O servidor de DNS não desempenha nenhuma verifica¸cão para assegurar que esta seçcão adicional está correcta ou até relacionada de algum modo com a resposta.

(26)

Tipos de Ataques DNS

O servi¸co DNS tem um determinado conjunto de vulnerabilidades, existindo alguns principais pontos de ataque, tais como:

• “Cache Spoofing” - Corrup¸cão da informa¸cão em cache consiste na introdu¸cão de dados com falsa informa¸cão na memória de cache, de modo a possibili-tar que um atacante redireccione um determinado dom´ınio para um servidor próprio, recebendo assim todas as informa¸cões que os utilizadores enviarem, inclusivamente senhas de acesso.

• “Traffic diversion” - Dispersão de tráfego é um ataque que gera o consumo de largura de banda e sobrecarga na rede e dos recursos do sistema;

• “Distribuited denial-of-service (DDoS)” - Ataque distribu´ıdo de nega¸c˜ao de servi¸co nos servidores de nomes;

• “Buffer Overruns” - Consultas recursivas a um dom´ınio causando overflow do buffer provocando a paragem do sistema ou produ¸cão incorrecta de resultados; Estes problemas de seguran¸ca necessitam de solu¸cão de modo a assegurar um servi¸co mais confiado e fidedigno. A Figura 2.4 representa um fluxo de transmissão de dados DNS e ilustra como é que alguns dos ataques às vulnerabilidades mais conhecidas do DNS actuam nos diversos componentes do sistema.

(27)

O DNSSEC previne um tipo de ataque espec´ıfico, o envenenamento de cache do DNS, para tal, permite que os servidores de DNS consigam autenticar as respostas das resolu¸cões de nomes. Se um atacante conseguir falsificar um endere¸co IP de um determinado site, o servidor DNS usando o DNSSEC, poderá verificar que a resposta não é a correcta e saberá que deve descartá-la e tentar descobrir o novamente o endere¸co real do site até obter uma resposta válida.

2.1.3 Origem do DNSSEC

Em resposta `as vulnerabilidades de seguran¸ca do DNS, o IETF (Internet En-gineering Task Force) formou um grupo de trabalho para adicionar extens˜oes da seguran¸ca (DNSSEC) ao protocolo existente [6].

Estas extensões ao protocolo original consistem numa hierarquia de assinaturas criptográficas que providenciam autentica¸cão da origem dos dados e integridade nas mensagens DNS e autentica¸cão da resposta da não existência de um dom´ınio. Estas medidas protegem contra memórias cache e transmissões modificadas contribuindo para a seguran¸ca do utilizador final, e por consequência aumenta a confian¸ca deste no uso da Internet e nos sistemas (detalhes na seçcão 3.1.2).

A fim de ganhar aceita¸cão, o grupo de trabalho reconheceu que o DNSSEC deve fornecer compatibilidade e deve ter a possibilidade de coexistir com implementa¸cões de DNS não seguras. Isto permite que os dom´ınios migrem para DNSSEC quando estiverem preparados e permite menos complexidade quando forem efectuadas ac-tualiza¸cões. Significa também que o software do lado do cliente, que não tenha suporte ao DNSSEC, consiga também processar correctamente os dados recebidos de um servidor de nomes com DNSSEC.

Apesar de estar em desenvolvimento há mais de 10 anos, o DNSSEC ainda não está a ser implementado na grande maioria das organiza¸cões. Quanto maior a Internet se torna, maior é a complexidade que a implementa¸cão do DNSSEC tem e este problema incluiu questões como desempenho, gestão de chaves e aspectos organizacionais.

As razões do atraso de uma implementa¸cão de DNSSEC em clientes de DNS re-side na necessidade de bibliotecas de programa¸cão que providenciem os mecanismos definidos nos novos RFCs (Request for Comments). Infelizmente a biblioteca LWRL (Lightweight Resolver Library), que vem com a distribui¸cão do BIND (Berkeley In-ternet Name Domain) versão 9, não é suficiente para estes requisitos.

O BIND, tendo sido inicialmente designado como Berkeley Internet Name Dae-mon, ´e uma ferramenta para o protocolo DNS das mais utilizado na Internet, es-pecialmente em sistemas do tipo Unix, sendo considerado, praticamente, como uma ferramenta padr˜ao. Foi criado por quatro estudantes da Universidade de Berkeley

(28)

com o objectivo de garantir competitividade com as ofertas de servidores DNS da Microsoft e actualmente é suportado e mantido pelo Internet Systems Consortium. Para a versão 9, o BIND foi praticamente redefinido, passando a suportar, entre outras funcionalidades, a extensão DNSSEC e os protocolos TSIG [7] e IPv6. As extensões de seguran¸ca DNSSEC foram financiadas por militares que perceberam a importância da seguran¸ca nos servidores DNS. No entanto, as especifica¸cões de Olaf Kolkman’s para DNSSEC na linguagem Perl [8] são as únicas a cumprir correcta-mente as especifica¸cões do RFC.

A vers˜ao corrente do DNSSEC foi publicada em Mar¸co de 2005 e est´a dispon´ıvel nestes 3 documentos: RFC4033 [9], RFC4034 [10] e RFC4035 [11].

2.1.4 Trabalho Relacionado

Projectos piloto de concretiza¸cão do DNSSEC foram bem cedo submetidos pela Holanda e pela Suécia. A Suécia foi o primeiro TLD (Top-level domain) a assinar a sua zona. Os projectos iniciais resultaram em experiências práticas de desenvolvi-mento, prepara¸cão de material de treino e uma maior compreensão de algumas das limita¸cões da especifica¸cão e esclarecimento de questões em aberto.

Esta experiência tem sido expandida pela recente publica¸cão do Sweden’s Na-tional Post and Telecom Agency, Post-och Telestyrelsen, dos seus testes de imple-menta¸cão e administra¸cão do DNSSEC num subdom´ınio do dom´ınio .SE.

A Tabela 2.2 apresenta alguns projectos j´a desenvolvidos:

Nome URL

DNSSEC(.se) http://dnssec.nic.se/

Infrastructure DNSsec et Applications http://www.idsa.prd.fr/index.php NeuStar Pilot in .US (concluded) http://www.potaroo.net/iepg/november

2004/DNSSECtrial-in-us.pdf

NIST Advanced Network http://www.antd.nist.gov/iipp.shtml Technologies Division, http://www-x.antd.nist.gov/dnssec Internet Infrastructure Protection,

Domain Name Security Project

NLnetLabs DNSSEC HOWTO https://www.ripe.net/projects/disi Root Server Testbed Network http://www.rs.net/

Internet2 Cross-Signing Pilot http://www.dnssec-deployment.org/internet2/ DNS Security (DNSSEC) Testbed http://www.pir.org/RegistrarResources/

DNSSecurityTestbed.aspx

registro.br DNSSEC http://registro.br/info/dnssec.html Tabela 2.2: Projectos desenvolvidos e base de dados de teste

(29)

Alguns dos desenvolvimentos principais desde o lan¸camento dos RFCs em Mar¸co de 2005 incluem o seguinte:

• .SE, o Registry nacional da Su´ecia [12] que foi o primeiro ccTLD a implementar DNSSEC na sua zona, lan¸cou o servi¸co comercial de DNSSEC [13];

• RIPE NCC, o fornecedor de servi¸cos da infraestrutura da Internet Europeia, implementou o DNSSEC na ´arvore reversa;

• O segundo ccTLD a disponibilizar o servi¸co de DNSSEC na sua zona foi o Registry de Puerto Rico (.PR) com toda a zona assinada;

• O Registry da Bulg´aria (.BG) tem mais de 30 delega¸c˜oes de zonas assinadas e seguras;

• NIC México e Tecnológico de Monterrey Campus Monterrey patrocinaram o DNSSEC México experimental para permitir aos seus membros experimentar e tornar-se familiares com a tecnologia e para analisar as introdu¸cões opera-cionais e técnicas de uma distribui¸cão do futuro DNSSEC em .MX;

• Internet2, um consórcio das principais universidades dos E.U., laboratórios de pesquisa e parceiros internacionais, iniciaram um projecto piloto e orga-nizaram um grupo de trabalho que se encontra mensalmente por meio de video-conferência e nos workshops e conferências dos membros Internet2; • .ORG manteve um testbed para permitir aos seus registrars testarem sistemas

com suporte a DNSSEC;

• .AERO expressou o interesse em desenvolver o DNSSEC embora planos firmes ainda n˜ao tenham sido anunciados;

• A Microsoft anunciou planos para fornecer suporte DNSSEC nos seus servi-dores DNS no service pack 1 do Longhorn, espera-se que fique dispon´ıvel em 2008;

• O National Institute of Standards and Technology dos Estados Unidos (NIST), um dos parceiros da iniciativa de coordena¸cão do desenvolvimento, realizou o lan¸camento de uma Publica¸cão Especial 800-53, revisão 1, Controlos Re-comendados da Seguran¸ca para Sistemas de Informa¸cão Federal em Dezembro de 2006. O guia inclui um plano para uma distribui¸cão inicial da tecnolo-gia DNSSEC dentro dos sistemas informáticos federais e especifica controlos m´ınimos da seguran¸ca necessários para complementar os Padrões Federais de Processamento de Informa¸cão (FIPS) requeridos pela Informa¸cão Federal de Gestão da Seguran¸ca (FISMA). As agências federais dos Estados Unidos terão

(30)

um ano após a publica¸cão final para ficarem em conformidade com os novos padrões. (Para mais informa¸cão, ver a implementa¸cão do projecto da FISMA, http://csrc.nist.gov/sec-cert/);

• O dom´ınio de topo do Brasil .br [14] já é uma zona assinada com DNSSEC desde o in´ıcio do mês de Junho, tratando-se do terceiro ccTLD operacional com extensões de seguran¸ca ao DNS. O técnico responsável Frederico Neves reporta que o ccTLD .br, assim como 4 das suas hierarquias (zonas filhas), foram assinadas a 4 de Junho e espera-se que zonas adicionais venham a ser assinadas num futuro próximo. A chave pública (KSK) encontrar-se em https://registro.br/ksk/, e a publica¸cão de chaves DNSSEC de .br e as pol´ıticas de gestão estão dispon´ıveis em http://registro.br/info/dnssec-policy-en.html.

2.2 Defini¸

c˜

ao dos Objectivos

Uma vez apresentado o ˆambito do projecto, torna-se agora necess´ario definir qual o seu foco e o que se pretende atingir.

As vulnerabilidades de seguran¸ca do protocolo DNS base e os recentes desen-volvimentos nesta área por parte de outras entidades gestoras de dom´ınios de topo movem-nos no sentido de preparar de imediato todos os procedimentos necessários para fornecer este novo servi¸co aos detentores de dom´ınios .PT. No entanto, o DNSSEC ainda tem algumas questões por resolver e a sua adop¸cão tem implica¸cões a ter em conta para a garantia de um bom funcionamento do servi¸co e da rede nas organiza¸cões.

Com este trabalho pretende-se fazer uma análise detalhada dos efeitos da im-plementa¸cão do DNSSEC no servi¸co prestado pela entidade gestora do dom´ınio de topo .PT [3] bem como da necessidade de adop¸cão de novos processos de trabalho. Este projecto será a base de prepara¸cão para a poss´ıvel entrada em produ¸cão do novo servi¸co bem como a base de decisão em se avan¸car nesse sentido.

2.3 Planeamento

Esta seçcão explica como foi projectado, organizado e escalonado o trabalho. Vários factores foram tidos em conta na defini¸cão do projecto e o modo como este seria concretizado. Estes aspectos são fundamentais no desenvolvimento de um projecto e assentam nos fundamentos de engenharia de software.

(31)

2.3.1 Metodologia utilizada

Depois do estágio ter sido atribu´ıdo seguiu-se um per´ıodo de levantamento de in-forma¸cão e análise de solu¸cões existentes para o problema da seguran¸ca do protocolo DNS e viabilidade da implementa¸cão das extensões de seguran¸ca (DNSSEC).

O estudo comparativo das várias implementa¸cões já existentes permitiu uma maior consciencializa¸cão do desenvolvimento deste protocolo, o que desencadeou todo o processo de análise técnica e defini¸cão de requisitos funcionais e técnicos necessários à instala¸cão piloto de DNSSEC no sistema de registo de dom´ınios de .PT.

Tratando-se de uma instala¸cão piloto e em processo de estudo comportamental não foi contactada nenhuma entidade externa para a adesão a este servi¸co, mas foram criados internamente dom´ınios de teste com os quais se procedeu de forma a entender todos os requisitos necessários a ter em conta no lan¸camento oficial deste novo servi¸co.

Como já foi referido, a implementa¸cão do servi¸co foi desenvolvida internamente na FCCN e implicou um processo cuidado e moroso para que a instala¸cão piloto não interferisse de modo algum com a gestão diária do funcionamento do DNS e que não provocasse a quebra do servi¸co de registo de dom´ınios.

2.3.2 Calendariza¸

c˜

ao

Inicialmente foram definidas tarefas e prazos a cumprir no planeamento do pro-jecto mas cedo se percebeu que o planeamento original teria que ser redefinido com tarefas mais adequadas ao tempo dispon´ıvel e `a complexidade do projecto. As tare-fas realizadas, n˜ao previstas inicialmente, foram as seguintes:

• Houve uma redifini¸c˜ao das tarefas de configura¸c˜ao passando da zona .pt para a hierarquia org.pt;

• Migra¸c˜ao dos servi¸cos de um servidor DNS para uma nova m´aquina;

• Disponibiliza¸cão da zona .pt em forma hierárquica em rela¸cão à zona de org.pt • Cria¸cão de “scripts” automatizadas para assinaturas de dom´ınios massificadas; • Actualiza¸cão das versões de instala¸cão da ferramenta BIND (Berkeley Internet Name Domain) para versão 9.3.1 ou superior em algumas máquinas de modo a fornecerem suporte a DNSSEC;

(32)

Apesar das várias redefini¸cões de tarefas o planeamento em termos de calen-dariza¸cão não sofreu desvio significativo tendo este projecto sido conclu´ıdo próximo da data inicialmente prevista (planeamento rectificado e o respectivo mapa de gantt são apresentados no anexo A).

(33)

Cap´ıtulo 3

Trabalho Realizado

Este cap´ıtulo descreve o trabalho realizado ao longo do projecto, apresentando as ferramentas utilizadas e desenvolvimentos efectuados, assim como a an´alise dos resultados obtidos.

3.1 An´

alise Funcional

Como já foi referido anteriormente, as extensões de seguran¸ca ao protocolo DNS original vêm implementar uma hierarquia de assinaturas criptográficas que permitem garantir que os dados recebidos provieram de facto da origem esperada (autentica¸cão da origem dos dados), que os dados não foram alterados por outrem durante a transmissão (integridade dos dados) e a não existência de um nome ou tipo.

Antes de se entrar em mais detalhes nestas caracter´ısticas de seguran¸ca é necessário rever um conceito sempre associado à autenticidade de informa¸cão que é a utiliza¸cão de criptografia de chave pública.

3.1.1 Criptografia e Assinaturas

A criptografia é uma ciência que permite escrever de forma a ocultar conteúdos. O objectivo da criptografia é permitir que um conjunto limitado de entidades, tipica-mente duas, possam trocar informa¸cão que é inintelig´ıvel para terceiros ou que seja poss´ıvel guardar e transmitir informa¸cão privada em redes abertas (como a Internet) sem o perigo de ser lida ou modificada por alguém que não seja o destinatário final da mensagem.

A criptografia baseia-se no uso de cifras. Uma cifra é uma técnica concreta de criptografia, isto é, uma forma espec´ıfica de ocultar informa¸cão. Assim, uma cifra transforma um texto em claro num texto cifrado ou criptograma. A opera¸cão

(34)

Cap´ıtulo 3. Trabalho Realizado 18

inversa é a decifra, que transforma um criptograma no texto em claro original como ilustra a Figura 3.1. Se a decifra for mal efectuada, ou porque o criptograma está corrompido ou porque houve uma má escolha de algoritmos ou chaves de decifra, então o resultado é imprevis´ıvel.

Figura 3.1: Criptografia

A opera¸cão da maioria das cifras e decifras é definida através da especifica¸cão de um algoritmo e de uma chave. O algoritmo define o modelo de transforma¸cão de dados, a chave é um parâmetro do algoritmo que permite variar o seu comportamento de forma complexa.

Criptografia assim´etrica

A criptografia assimétrica, ou de chave pública, utiliza um par de chaves distintas mas relacionadas: uma chave pública para cifrar e uma chave privada para decifrar, e não é poss´ıvel, dada a chave pública, calcular a correspondente chave privada (ver Figura 3.2).

As cifras permitem ainda efectuar a cifra ao contrário, cifrando com a chave privada e decifrando com a pública, o que não tem grande interesse para esconder a informa¸cão, mas é importante para garantir a sua autoria.

Figura 3.2: Criptografia Assim´etrica

Os pares de chaves assimétricas são personalizados, ou seja, são associados a pessoas, servi¸cos ou servidores. A componente privada deve ser mantida em segredo,

(35)

devendo ser apenas do conhecimento e da utiliza¸c˜ao da entidade a que se encontra associada. A chave p´ublica pode (e deve) ser ampla e publicamente divulgada para poder ser utilizada por qualquer entidade.

Em termos operacionais as cifras assimétricas têm como principal vantagem o facto de exigirem menos chaves para efectuar interaçcões seguras porque permite uma rela¸cão de muitos para um.

Em termos administrativos os principais problemas subjacentes à utiliza¸cão de criptografia assimétrica são:

• Confinamento rigoroso das chaves privadas aos leg´ıtimos detentores;

• Distribui¸cão fidedigna de chaves públicas a todos os que as pretendem usar; • Gestão do tempo de vida dos pares de chaves;

Assinaturas digitais

Um dos maiores benef´ıcios da criptografia de chave pública é a possibilidade do uso de assinaturas digitais. As assinaturas digitais permitem ao destinatário de uma mensagem verificar a autenticidade da origem da informa¸cão, e verificar também se a informa¸cão não foi alterada durante o trajecto. Logo, assinaturas digitais de chave pública fornecem autentica¸cão e integridade de dados.

Como mencionado, o objectivo das assinaturas digitais é ir mais longe na garantia de origem e assegurar a autoria de uma mensagem perante terceiros. Uma mensagem assinada digitalmente fica associada a uma e uma só entidade e a assinatura deverá poder ser validada universalmente. A criptografia assimétrica é a que melhor se adequa a este fim, uma vez que os pares de chaves têm um cariz pessoal, isto é, cada par de chaves pertence apenas a uma entidade.

Tecnicamente, e de uma forma simplificada, uma assinatura digital de um doc-umento consiste na cifra do mesmo com a chave privada do autor e não serve para esconder o documento original mas sim para garantir, a quem a decifrar com a chave pública correspondente, que o documento não foi modificado.

Devido ao elevado custo computacional das cifras assimétricas, não interessa cifrar a totalidade do documento a assinar mas sim um valor de pequena dimensão que represente o mesmo, ou seja, uma s´ıntese (hash) do mesmo. Usando a s´ıntese, obtém-se uma maior eficiência na gera¸cão e valida¸cão de assinaturas digitais e obtˆ em-se assinaturas mais reduzidas.

Se, na valida¸cão da assinatura, não for poss´ıvel verificar a equivalência, significa que ou o texto e a informa¸cão adicional foram alterados ou a assinatura foi alterada. A Figura 3.3 ilustra o processo de cria¸cão de uma assinatura digital associada a um determinado documento.

(36)

Figura 3.3: Assinatura Digital

3.1.2 Extens˜

oes ao protocolo DNS

Estas extensões ao protocolo original consistem numa hierarquia de assinaturas criptográficas que providenciam autentica¸cão da origem dos dados do DNS, integri-dade e autentica¸cão da resposta da não existência de um dom´ınio. Estas medidas protegem contra corrup¸cão de memórias de cache e transmissões modificadas e con-tribuem para o aumento da confian¸ca na Internet e nos sistemas.

O DNSSEC n˜ao garante a confidencialidade dos dados nem protege contra ataques de nega¸c˜ao do servi¸co (DoS).

Cada dom´ınio, quer seja único ou seja um TLD, pode ter um conjunto de resource records (RRs) a ele associado. Para um dom´ınio isolado, o resource record mais comum é o do tipo A (address) que faz corresponder a um dom´ınio o respectivo endere¸co IP, mas existem muitos outros. Quando um cliente de DNS pergunta por um dom´ınio a um servidor de DNS, o que recebe de volta são os resource records associados a esse dom´ınio.

A fun¸cão real do DNS é fazer corresponder nomes de dom´ınios aos seus respec-tivos resource records. Estes são divididos em classes e tipos e actualmente existe uma grande variedade de tipos. Ao conjunto de resource records com o mesmo nome de dom´ınio, classe e tipo é denominado “Resource Record Set”(RRset).

(37)

• SOA - Indica onde est´a delegada a autoridade da zona • NS - Indica um servidor de nomes para a zona

• A - Atribuiu o nome a um endere¸co

O DNSSEC introduz resource records adicionais que se dividem em quatro tipos diferentes. S˜ao eles: DNSKEY, RRSIG, NSEC e DS.

DNSKEY

Todas as zonas DNS assinadas têm associado um par de chaves privada e pública. A chave privada mantém-se (muito bem guardada) em segredo com o administrador da zona. A chave pública associada à zona é publicada num ficheiro e designa-se DNSKEY.

O DNSKEY é o resource record que contém as chaves públicas (resultantes de um algoritmo de encripta¸cão assimétrico) para suporte do DNSSEC, chaves estas que permitem verificar as assinaturas dos RRs de uma zona previamente assinados recorrendo à chave privada correspondente.

A Figura 3.4 [15] ´e um exemplo deste tipo de RR e identifica os v´arios compo-nentes.

(38)

As chaves públicas utilizadas em opera¸cões de assinatura de zonas podem ser de dois tipos. Temos a chave pública ZSK (Zone Signing Key) que é utilizada para assinar os resource records numa zona e a chave pública KSK (Key Signing Key) que por sua vez é utilizada para assinar as ZSKs, refor¸cando o processo de encripta¸cão. O DNSKEY pode ser criado a partir do utilitário dnssec-keygen fornecido na ferramenta de software BIND.

RRSIG

Como foi já mencionado, um RRset é um conjunto de resource records de uma zona DNS que partilham em comum um nome, uma classe e um tipo e por esse motivo estes são agrupados.

O RRSIG, representado na Figura 3.5 [15], consiste no RR que cont´em a assi-natura digital de um RRset espec´ıfico com uma determinada chave (DNSKEY).

(39)

Cada RRset numa zona assinada terá um resource record RRSIG contento a s´ıntese do RRset criado utilizando o resource record DNSKEY de ZSK (Zone Signing Key). O RRSIG é único, possui uma validade inicial (inception) e final (expiration) e pode ser gerado automaticamento através do utilitário dnssec-singzone fornecido com o BIND versão 9 ou superior.

NSEC

O NSEC, que deriva da nomenclatura “Next Secure”, é o resource record que vem permitir autenticar a resposta da inexistência de um dom´ınio, ou seja, que o nome de dom´ınio pedido na realidade não existe.

Este RR disponibiliza duas informa¸cões distintas, a do próximo nome seguro (numa ordena¸cão canónica da zona) e os tipos de RRsets existentes para um nome. O conjunto completo de resource records NSEC de uma zona revelam quais os que RRsets que efectivamente existem na zona e formam uma cadeia de nomes de dom´ınios em que o último resource record da zona aponta para o primeiro (SOA) permitindo fechar a cadeia criando um ciclo.

A revela¸cão desta informa¸cão é utilizada para providenciar autenticidade aquando a inexistência de uma resposta, isto é, se o nome ou tipo consultados realmente não existem e a situa¸cão encontrada não se trata de um ataque ao DNS e por consequente o acesso a determinado servi¸co não foi permitido (DoS).

A Figura 3.6 [15] exemplifica um resource record NSEC onde se pode verificar que o nome pc2.xpto.pt não existe, pois estando a zona ordenada canonicamente, o nome que vem depois de pc1.xpto.pt é o pc3.xpto.pt, logo não existe nenhum nome válido entre os mencionados. Pode-se também concluir que para o nome pc1.xpto.pt não existe associado nenhum resource records do tipo MX (Mail eXchanger), por isso se for realizado um pedido de RR MX deste dom´ınio a resposta terá que ser obrigatoriamente negativa.

(40)

DS

A questão da valida¸cão da chave pública da zona ainda continua por resolver após a apresenta¸cão dos três primeiros tipos de resource records. Um atacante só necessita de fornecer um DNSKEY e os dados RRSIG que correspondam aos dados do RRset fict´ıcio de modo fazer com que a resposta pare¸ca “autêntica”.

A aproxima¸cão adoptada pelo DNSSEC é a de utilizar uma cadeia de confian¸ca dentro da delega¸cão hierárquica da estrutura do próprio DNS. À excep¸cão da zona “.” (root), todas as zonas DNS têm uma zona pai. O resource record DS (Delegation Signer) contém uma s´ıntese (hash) da chave pública das zonas dos filhos. Este resource record é assinado pela chave privada da zona pai ficando com o resource record RRSIG correspondente.

Consistindo o DS na s´ıntese referente a um resource record DNSKEY, este serve para informar que existe uma cadeia de confian¸ca entre um dom´ınio e os seus sub-dom´ınios e indica que a zona delegada ´e assinada e qual a chave p´ublica utilizada nessa zona.

Como o resource record DS é assinado pela zona pai, esta zona tem a autoridade sobre o respectivo resource record não devendo este aparecer nas zonas filhas e funcionará como um ponteiro para a cadeia de confian¸ca (chain trust). A cadeia de confian¸ca garante a autenticidade das delega¸cões de uma zona até um ponto de confian¸ca, ponto esse que se pode tratar de uma chave ancorada ou a utiliza¸cão de DLV (DNSSEC Lookaside Validation [16]), isto é, pontos de confian¸ca ancorados fora da cadeia de delega¸cão DNS.

Figura 3.7: Exemplo de um DS resource record

Como ilustrado na Figura 3.7 [15] um RR DS armazena a informa¸cão necessária para a realiza¸cão do processo de autentica¸cão do DNSKEY, tais como, a etiqueta

(41)

(tag) da chave p´ublica (KSK) do servidor filho, uma s´ıntese (resumo) do respectivo resource record DNSKEY cifrado com ZSK do servidor pai e o algoritmo utilizado na cria¸c˜ao desse resumo.

Para validar a delega¸c˜ao de uma zona, o servidor pai utiliza o resource record DS, e este RR por sua vez valida a KSK (chave p´ublica) do servidor filho.

A chave de confian¸ca ideal seria o DNSKEY na zona root, mas na ausência deste ponto de confian¸ca cada cliente DNSSEC tem de configurar o seu próprio sistema de valida¸cão com pontos de confian¸ca conhecidos, fora da valida¸cão hierárquica, como por exemplo, através de uma autoridade certificadora.

Confidencialidade

O protocolo DNS foi desenvolvido com o intuito de tornar públicos os resource records dos dom´ınios independentemente de quem lhes está a aceder. As extensões de seguran¸ca seguem essa mesma orienta¸cão e não adicionam qualquer tipo de car-acter´ıstica de confidencialidade ao protocolo base.

Transferˆencias seguras de zona

Apesar de o DNSSEC permitir autentica¸cão da origem e integridade dos dados para os RRsets, não o consegue fazer para zonas inteiras e, deste modo, devem ser utilizados outros mecanismos como o TSIG [7], SIG(0) [17] ou IPsec [18] para proteger essas opera¸cões de transferência.

3.1.3 Algoritmos e tipos de s´ıntese de DNSSEC

As extens˜oes de seguran¸ca do DNS foram desenhadas para serem independentes dos algoritmos criptogr´aficos.

Os RRs DNSKEY, RRSIG e DS usam um número de algoritmo que identifica o algoritmo criptográfico utilizado nesse resource record. O RR DS define ainda um tipo de resumo que identifica o algoritmo utilizado na cria¸cão da s´ıntese.

Os clientes e servidores DNS que tenham suporte a DNSSEC devem implementar todos os algoritmos obrigat´orios.

Alguns dos algoritmos presentes na Tabela 3.1 são usados unicamente para assi-natura de zona (DNSSEC), outros apenas para mecanismos de transaçcão segura (SIG(0) e TSIG), e alguns em ambas as situa¸cões. Os que são usados na assinatura de zona podem aparecer em resource records DNSKEY, RRSIG e DS.

(42)

Os algoritmos e tipos de s´ıntese definidos actualmente est˜ao listados na Tabela 3.1 [10].

Value Algorithm [Mnemonic] Zone Signing References Status 0 reserved

1 RSA/MD5 [RSAMD5] no [19] not recommended 2 Diffie-Hellman [DH] no [20]

-3 DSA/SHA-1 [DSA] yes [21] optional

4 Elliptic Curve [ECC]

-5 RSA/SHA-1 [RSASHA1] yes [22] mandatory

252 Indirect [INDIRECT] no

-253 Private [PRIVATEDNS] yes optional 254 Private [PRIVATEOID] yes optional 255 reserved

6 - 251 Available for assignment by IETF Standards Action. Tabela 3.1: Tipos de algoritmos

Tipos de s´ıntese

O campo de tipo de s´ıntese no resource record DS identifica o algoritmo crip-tográfico utilizado no cálculo da s´ıntese aplicado à chave pública a que este resource record diz respeito.

A Tabela 3.2 [10] mostra os tipos de algoritmos actualmente definidos para esta opera¸c˜ao.

Value Algorithm Status 0 Reserved -1 SHA-1 mandatory 2-255 Unassigned

-Tabela 3.2: Tipos de s´ıntese

Identificador da chave

O identificador da chave (key tag), presente nos resource records RRSIG e DS, permite seleccionar uma chave pública de forma eficiente. Na maioria dos casos, a combina¸cão do nome de dom´ınio, algoritmo e chave podem identificar univocamente um resource record DNSKEY. Ambos os resource records RRSIG e DS têm resource records DNSKEY correspondentes. Nestes RRs, o identificador da chave pode ser

(43)

usado para ajudar a seleccionar o resource record DNSKEY quando existe mais do que um resource record candidato dispon´ıvel.

No entanto, é de salientar que este identificador não garante a unicidade de referência para um único resource record. E teoricamente poss´ıvel dois resource´ records DNSKEY terem o mesmo nome de dom´ınio, algoritmo e chave.

O identificador da chave ´e calculado atrav´es de um algoritmo simples de hash.

3.2 Adop¸

c˜

ao do DNSSEC

De modo a desenvolver o DNSSEC operacionalmente, os servidores com suporte a DNSSEC devem somente desempenhar a inclusão automática de resource records quando há uma indica¸cão expl´ıcita que o Resolver (cliente DNS) pode compreender esses RRs.

3.2.1 Requisitos

Complexidade

Apesar de conter apenas algumas regras simples, o DNS tem-se desenvolvido num sistema enorme e complexo. O DNSSEC introduz complexidade adicional ao DNS, o que acarreta novas possibilidades de aparecimento de incoerências no código e de zonas mal configuradas. Em particular, a activa¸cão da verifica¸cão da assinatura de DNSSEC num cliente DNS pode fazer com que zonas leg´ıtimas se tornem inacess´ıveis devido a erros de configura¸cão.

Aloca¸c˜ao de maior largura de banda

A adop¸cão do DNSSEC implica uma troca de mensagens de maiores dimensões. Em resposta a pedidos de dados em zonas assinadas, os servidores DNS com suporte a seguran¸ca vão responder com os resource records DNSKEY, RRSIG, NSEC e/ou DS. A adi¸cão destes novos RRs implica a aloca¸cão de uma maior largura de banda para se efectuarem as trocas de mensagens entre o servidor e o cliente. No entanto, a grande maioria dos pedidos efectuados inicialmente a zonas assinadas serão real-izados por clientes sem suporte às extensões de seguran¸ca e esses resource records adicionais não trarão qualquer mais-valia para esses clientes.

(44)

Cientes deste facto, os membros do grupo de trabalho para o desenvolvimento do DNSSEC definiram desde logo uma sinaliza¸cão a ser enviada por clientes e servidores de nomes recursivos de modo a informar os servidores de nomes autoritativos de que têm suporte a extensões de seguran¸ca e que pretendem receber todos os resource records necessários para verifica¸cão da assinatura da zona. Deste modo, evita-se uma sobrecarga desnecessária da rede.

Para além do exposto anteriormente, uma vez que o protocolo DNS utiliza data-gramas UDP no seu modo de funcionamento padrão, e que esses datagramas estão limitados a 512 bytes, existe uma grande probabilidade em as respostas que incluem os novos resource records DNSSEC terem de ser truncadas. Nestes casos, o cliente reenvia o pedido utilizando TCP e isto resulta numa utiliza¸cão significativamente maior da largura de banda da rede devido ao estabelecimento de liga¸cões. O impacto destes pedidos TCP podem acarretar um grande aumento do tráfego da rede (em média, 5 pacotes por cada pedido/resposta em vez de apenas dois), um maior tempo de resposta devido aos tempos de ida-e-volta, um aumento de pedidos com falhas devido aos timeouts (limites de tempo de concretiza¸cão) e um aumento significativo da carga de processamento dos servidores de nomes.

Para colmatar este aumento de carga na rede existe a necessidade de utilizar o mecanismo de extensão ao protocolo DNS designado por EDNS0 (Extension Mech-anisms for DNS [23]). Este mecanismo permite o envio de mensagens de maiores di-mensões, definindo uma sinaliza¸cão no header (bit DO) que corresponde a “DNSSEC OK”. Se o cliente enviar este bit a 1, significa que está preparado para receber os resource records de extensões de seguran¸ca para zonas assinadas. Caso contrário, o servidor de nomes irá responder apenas com os resource records do protocolo base.

3.2.2 Novas Vulnerabilidades

Varrimento da Zona

O DNSSEC garante a autenticidade da resposta da não existência de um nome ou tipo de resource record através de uma cadeia de nomes, na qual cada um indica o próximo nome existente na zona, formando uma sequência canónica. Os resources records que desempenham o papel desses apontadores são do tipo NSEC.

O motivo pelo o qual o DNSSEC adoptou a solu¸cão NSEC, é a necessidade de garantir que um nome não existe, o que corresponde a caracter´ısticas de autentici-dade.

No entanto, esta solu¸cão permite obter todo o conteúdo de uma zona com simples consultas de DNS, método conhecido por varrimento de zona (Zone Walking).

(45)

Deste modo o DNSSEC introduz a possibilidade de qualquer utilizador com boas ou más inten¸cões obter todos os nomes de uma zona, por ordem canónica, ao percorrerem a cadeia de resources records NSEC. Embora por si só, não se trate de um ataque, a informa¸cão que é poss´ıvel recolher por este método permite descobrir os servidores existentes numa rede, facilitando assim o acesso à arquitectura de rede e por consequência a possibilidade de um ataque.

A combina¸cão de NSEC com informa¸cão fornecida pelo servi¸co Whois é poten-cialmente muito mais grave. O servi¸co Whois é um servi¸co público que fornece informa¸cões pessoais sobre os responsáveis de um dado dom´ınio. Se um utilizador percorrer uma zona, obtendo a lista de nomes existentes nessa zona, e de seguida pesquisar os contactos associados, de cada um dos nomes no servi¸co Whois, irá obter uma grande quantidade de informa¸cão pessoal (endere¸cos de mail, números de telefone, moradas, entre outros). Para fazer face ao problema de Zone Walking, foi criada a solu¸cão “DNSSEC Hashed Authenticated Denial of Existence” [24] mais vulgaremente conhecida por NSEC3.

Os resource records NSEC3 são assinados à semelhan¸ca dos resource records NSEC, mas em vez de incluir directamente o próximo nome (o que permitia per-correr a zona), o NSEC3 inclui o resultado cifrado de uma fun¸cão de hash sobre o próximo nome. Inclui ainda uma componente adicional conhecida por sal (salt) que aumenta o grau de complexidade do acesso à informa¸cão, pois o campo sal é adicionado ao nome original do proprietário antes do hash ser realizado a fim de proteger contra ataques de dicionário. O NSEC3 é uma solu¸cão recente que ainda está em desenvolvimento, e a sua especifica¸cão actual ainda gera alguns conflitos com metodologias já existentes como as actualiza¸cões dinâmicas no DNS.

Ataque de processamento extra

As extensões do DNSSEC tornam o DNS vulnerável a uma nova classe de ataques de nega¸cão de servi¸co, baseada nas opera¸cões de criptografia processadas tanto pelos clientes como pelos servidores de DNS que suportam as extensões de seguran¸ca, uma vez que um atacante pode tentar consumir todos os recursos das suas v´ıtimas através desse processamento.

Esta classe de ataques pode tomar pelo menos duas formas. Um atacante pode tentar consumir recursos de processamento extra de valida¸cão de assinaturas num cliente DNS com suporte a seguran¸ca alterando o RRSIG na resposta às mensagens ou através da constru¸cão desnecessária de cadeias de assinaturas. Um atacante pode também ser capaz de consumir recursos num servidor de nomes com suporte a seguran¸ca através do envio de mensagens de altera¸cão dinâmica que forcem o servidor a re-assinar alguns RRsets na zona, de forma mais frequente do que o que

(46)

seria de esperar [25].

Com base numa análise de custo/benef´ıcio para a organiza¸cão a usufuir da im-plementa¸cão do protocolo DNSSEC, medidas de precau¸cão (como por exemplo, uti-liza¸cão de máquinas mais eficientes ou solu¸cões de gera¸cão de assinaturas baseadas em hardware) podem ser empregues para atenuar este tipo de vulnerabilidade, pois não existem ainda solu¸cões baseadas em software que impe¸cam este tipo de amea¸cas.

3.3 Implementa¸

c˜

oes Existentes

Neste momento o estado actual do DNSSEC encontra-se completo e pronto a ser utilizado, com alguns promenores relativamente a questões de privacidade mas que se encontram já em fase de resolu¸cão (NSEC3 e assinatura online [25]).

Na fase inicial do desenvolvimento do DNSSEC eram apenas duas as imple-menta¸cões de software com suporte DNSSEC para servidores de nomes (BIND e NSD) e com o passar dos anos o número foi aumentando e existem cerca de 7 imple-menta¸cões, sendo o BIND [26] a ferramenta mais adequada de se utilizar até a data porque é aquela que oferece mais funcionalidades para um desenvolvimento mais eficiente de DNSSEC.

3.4 Concretiza¸

c˜

ao e Testes

3.4.1 Hierarquia org.pt assinada

A Figura 3.8 apresenta um excerto da zona da hierarquia org.pt assinada, por meio as extens˜oes de seguran¸ca ao DNS, numa simula¸c˜ao com 1000 subdom´ınios assinados.

Além das ferramentas oferecidas pela versão 9 do BIND (Berkeley Internet Name Domain) para a cria¸cão de chaves públicas (dnssec-keygen) e de assinaturas digi-tais (dnssec-singzone) dos resource records da zona, foram criados “scripts”, isto é, ferramentas de execu¸cão que possibilitaram realizar determinadas opera¸cões de um modo automatizado, seguindo o modelo padrão de assinatura de zonas utilizado em muitos dos trabalhos relacionados, que proporcionou o desenvolvimento de um ambiente simulado de zonas e sub-zonas assinadas. Foi também crucial a utiliza¸cão do DiG (Domain Information Groper), uma ferramenta de investiga¸cão de sistemas DNS também fornecida pelo BIND, que permite procurar informa¸cão DNS via in-terroga¸cões a servidores de nomes.

(47)

Figura 3.8: Segmento da zona pai assinada (zona org.pt)

Os procedimentos realizados para a obten¸cão de zonas filhas assinadas em grande número, para fins de estudo estat´ıstico do impacto que esta implementa¸cão poderá refletir sobre sistema, tiveram a seguinte sequência:

(48)

1o Assinar as zonas filhas (zona de teste dnssec.org.pt)

1. Gerar os pares de chaves ZSK e KSK (Zone Signing Key e Key Signing Key):

# dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n zone dnssec.org.pt ZSK: Kdnssec.org.pt.+005+51096

# dnssec-keygen -r /dev/urandom -f KSK -a RSASHA1 -b 1024 -n ZONE dnssec.org.pt KSK: Kdnssec.org.pt.+005+39379

2. Colocar as chaves p´ublicas na respectiva zona:

# cat *.key >> dnssec.org.pt (faz o mesmo que um $include)

3. Actualizar o n´umero de s´erie da zona

4. Assinar efectivamente a zona filha (dnssec.org.pt):

# dnssec-signzone -k Kdnssec.org.pt.+005+39379 dnssec.org.pt Kdnssec.org.pt. +005+51096

Ap´os a assinatura de todas as zonas filhas segue-se a assinatura da zona pai de modo a criar uma cadeia segura ou as chamadas ilhas.

2o Assinar a zona pai (zona org.pt) 1. Gerar os pares de chaves ZSK e KSK:

# dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE org.pt ZSK: Korg.pt.+005+17058

# dnssec-keygen -r /dev/urandom -f KSK -a RSASHA1 -b 1024 -n ZONE org.pt KSK: Korg.pt.+005+10783

2. Colocar as chaves p´ublicas na respectiva zona:

# cat *.key >> org.pt

3. Actualizar o n´umero de s´erie da zona

4. Assinar a zona pai com a op¸c˜ao -g para incluir keyset dos filhos (org.pt):

# dnssec-signzone -r/dev/urandom -g -o org.pt -f org.pt.signed -a -t -k Korg.pt.+005+10783

(49)

5. Reiniciar o servidor de nomes com a nova configura¸c˜ao da zona (editar named.conf definindo a KSK da zona org.pt como uma trusted key)

# cat Korg.pt.+005+10783.key >> named.conf

6. Efectuar uma pesquisa (dig) por forma a verificar que a responta cont´em a informa¸c˜ao DNSSEC da zona, segue o exemplo:

dig @193.136.192.3 +dnssec +multiline dnssec.org.pt.

3.4.2 Resultados Obtidos

Após a cria¸cão de um ambiente simulado de zonas assinadas numa hierarquia também ela assinada foi poss´ıvel verificar os diversos tempos de resposta consoante a dimensão da zona que era simulada.

Os testes efectuados tiveram em vista a preocupa¸cão do impacto do processa-mento e sobrecarga de memória do servi¸co, foram simulados ambiente com zonas contendo apenas um único subdom´ınio assinado, até zonas contendo 1000 dom´ınios. Dimensão do ficheiro de zona

Figura 3.9: Dimens˜ao da zona vs. zona assinada

O presente gr´afico da Figura 3.9 tem como objectivo comparar a dimens˜ao de um ficheiro de zona antes e depois de assinado. Foi tomado como exemplo a zona org.pt, que tem actualmente cerca de 500 dom´ınios dos quais apenas 400 se encontram

(50)

activos, se todos os dom´ınios activos pretendessem aderir ao DNSSEC o ficheiro de zona org.pt passaria, como se pode ver por análise ao gráfico, de um tamanho de 46 KB para 432 KB, passando o ficheiro actual a ter uma dimensão 10 vezes superior `

a dimens˜ao inicial antes de assinado.

Apesar do aumento acentuado do tamanho do ficheiro de zona, a unidade em causa s˜ao KB (KiloByte), sendo de dimens˜oes ainda irrelavantes para afectar de algum modo o processamento dos servidores de DNS.

Dura¸c˜ao do processo de assinatura de uma zona

Foi também realizado um teste comparativo do tempo que uma zona demora a assinar um determinado número de dom´ınios (ver gráfico da Figura 3.10) para que fosse poss´ıvel observar a capacidade de resposta do servidor de DNS aquando a execu¸cão imoderada de dom´ınios assinados.

Figura 3.10: Tempo de assinatura de uma zona

Os resultados aqui obtidos foram também bastante positivos pois o tempo de resposta em segundos é pouco significativo com o aumento do número de dom´ınios assinados, existindo quase uma rela¸cão de propor¸cão directa entre as variáveis.

Apesar da divergência da dimensão do ficheiro de zona antes e depois de assinado e do tempo de resposta do processo de assinatura pode-se concluir que o número não é preocupante para uma poss´ıvel entrada em produ¸cão, pois as máquinas a suportar estas novas implementa¸cões tem uma enorme capacidade de processamento assim como de memória, tendo sido analisado um impacto pequeno em máquinas com menores caracter´ısticas é prudente assumir que se irá trabalhar num ambiente com

(51)

uma consider´avel margem de manobra, estando teoricamente ausente de riscos e de falhas de funcionalidades.

Estimativa de Largura de Banda

Foram também efectuados testes com o objectivo de estimar um valor aproxi-mado da largura de banda necessária ao servidor primário de .PT para suportar uma zona .PT completamente assinada.

Através de dados obtidos por meio de uma sonda que analisa o tráfego na rede do servidor primário (ns.dns.pt) foi poss´ıvel obter as seguintes métricas:

• O tamanho médio das mensagens DNS recebidas pelo servidor primário é de 88 bytes

• O volume de tráfego de DNS que flui de e para o servidor primário tem um valor médio de 11 KB/s

Uma estimativa média do tamanho das mensagens assinadas que irão partir do servidor primário assim que come¸car a haver zonas com DNSSEC é de 330 bytes.

Estes dados permitem extrapolar que as necessidades de largura de banda impres-cind´ıvel ao servidor prim´ario de .PT para suportar uma zona .PT completamente assinada ´e de:

11 x 330 / 88 * 8 = 41,25 KB/s Tempo de acesso ao DNS

Outra questão relevante a ter em conta, é a capacidade de resposta do DNS com implementa¸cão DNSSEC aos futuros utilizadores, para isso foi realizada uma medi¸cão do tempo necessário para aceder ao DNS por parte de um cliente. Através da utiliza¸cão da ferramenta de gestão do DNS designada por DiG (Domain Informa-tion Groper) foi poss´ıvel medir o tempo de resposta do DNS de dom´ınios assinados. Após um número considerável de testes foi poss´ıvel concluir que o tempo de acesso ao DNS de um dom´ınio não varia praticamente nada (varia¸cões na ordem de mais ou menos 1 msec), no caso de ter sido efectuada uma interroga¸cão a um dom´ınio assinado com pedido de informa¸cão opcional de DNSSEC. No caso de não ser pedida informa¸cão opcional o tempo de resposta era exactamente o mesmo.

Na Figura 3.11 segue o resultado do DiG efectuado a um dom´ınio assinado com o comando dig @193.136.192.3 org.pt. +dnssec +multiline que corresponde aos respectivos campos dig @server name +[query options]:

(52)

Figura 3.11: DiG realizado a um dom´ınio assinado

O mesmo teste foi realizado para a zona org.pt (ver Figura 3.12) com cerca de 100 dom´ınios assinados e os resultados foram idênticos aos da interroga¸cão DNS de um único dom´ınio, o tempo de acesso ao DNS não modificou em rela¸cão ao tempo obtido quando esta não era assinada.