TCC - DNS e DNSSEC

(1)

UNIÃO DOS INSTITUTOS BRASILEIROS DE TECNOLOGIA – UNIBRATEC CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES

ANNE STEPHANE MENDONÇA BORBA ANTÔNIO MARCOS DA SILVA COSTA

ANTONIO SIMÃO JÚNIOR RODOLFHO ALVES DE QUEIROZ SAMUEL FELLER DE MOURA SENA

DNS e DNSSEC: UMA ANÁLISE COMPARATIVA.

(2)

ANTONIO SIMÃO JÚNIOR RODOLFHO ALVES DE QUEIROZ SAMUEL FELLER DE MOURA SENA

Trabalho de conclusão de curso apresentado ao Curso de Tecnologia de Redes de Computadores, para obtenção do título acadêmico de graduação em Redes de Computadores, da UNIBRATEC, sob a orientação dos Professores Dailson Fernandes e Marcos Gondim.

(3)

ANTONIO SIMÃO JUNIOR RODOLFHO ALVES DE QUEIROZ SAMUEL FELLER DE MOURA SENA

Este trabalho de conclusão de curso foi julgado adequado como parte dos requisitos para obtenção do título acadêmico em Redes de Computadores,

FACULDADE DE TECNOLOGIA IBRATEC

Recife, 22 de Maio de 2014.

______________________________________________________ Prof.º DAILSON DE OLIVEIRA FERNANDES

UNIBRATEC – FACULDADE DE TECNOLOGIA IBRATEC

______________________________________________________ Prof.º MARCOS ANTONIO ALVES GONDIM

(4)

AGRADECIMENTOS ANNE STEPHANE MENDONÇA BORBA

Grata a Deus pelo dom da vida, pelo seu amor infinito. Agradeço à minha família, principalmente aos meus pais, Emanoel e Roberta, pela preocupação para que estivesse sempre andando pelo caminho correto. Obrigada ao professor Roberto Mendonça, o meu Tio Beto, por cada incentivo e orientação, ele sempre será um espelho. Aos meus amigos que fazem parte do grupo, em especial a Marcos Costa, por todo carinho, paciência, compreensão, pelo sorriso, pela mão que sempre se estendia quando eu precisava. Esta caminhada não seria a mesma sem você. Obrigada aos grandes mestres que tive o privilégio de conhecer ao longo deste curso, em especial a Fred Lucena, Carlos Schuller e aos meus orientadores Dailson Fernandes e Marcos Gondim. Obrigada a todos que, mesmo não citados aqui, tanto contribuíram para a conclusão desta etapa.

ANTÔNIO MARCOS DA SILVA COSTA

Eu quero agradecer primeiramente a Deus por me permitir dar este grande passo na minha vida. Gostaria de agradecer a cada um dos integrantes do grupo por se dedicar a este trabalho com empenho. Agradeço de coração à minha família e principalmente à minha noiva, Roberta, por ter compreendido as minhas ausências enquanto estudava e realizava este trabalho. Agradeço a todos os professores deste curso que me passaram todo o conhecimento necessário não somente para fazer este trabalho, mas também para a minha vida profissional e acadêmica. E por último, gostaria de agradecer aos professores Carlos Schuler, Dailson Fernandes e Marcos Gondim por nos ter norteado durante a realização deste trabalho.

ANTONIO SIMÃO JÚNIOR

Agradeço em primeiramente a Deus por mais esta conquista na minha vida. Quero agradecer imensamente à minha família e a minha namorada Thalyta que me apoiaram em todos os momentos. Gostaria de agradecer aos integrantes da equipe que sempre estiveram juntos desde o começo do curso e se dedicaram ao trabalho com louvor. Também estou grato a esta instituição de ensino e todo o corpo docente atuante neste curso e principalmente aos orientadores: Dailson Fernandes e Marcos Gondim por terem orientado de forma brilhante.

(5)

Agradeço a todos os meus familiares pelo apoio durante essa difícil jornada da vida, aos meus colegas de curso pelo companheirismo, aos professores que contribuíram para minha formação profissional. Também a faculdade Unibratec pela estrutura prestada aos seus alunos e principalmente aos meus caros colegas ANNE STEPHANE MENDONÇA BORBA, ANTONIO MARCOS DA SILVA COSTA, ANTONIO SIMÃO JUNIOR e SAMUEL FELLER DE MOURA SENA pelo apoio e companheirismo durante todo o curso e realização do TCC.

SAMUEL FELLER DE MOURA SENA

Em primeiro lugar, agradeço a Deus por permitir, em sua infinita graça, este momento ímpar em minha vida. Gostaria também de agradecer a cada integrante deste grupo por sua dedicação. A meus pais, Roberto e Sheila, pelo amor e apoio incondicionais. A meus colegas de trabalho pelas palavras de incentivo. Agradeço a todos os professores da Unibratec, por nos mostrarem o caminho a ser trilhado e serem coautores de minha história pessoal, profissional e acadêmica, com destaque aos grandes mestres Fred Lucena, Roberto Mendonça e Sandro Tamman, sempre próximos e prontos para me auxiliar. E por fim, em especial homenagem; agradeço aos professores Carlos Schuler, Dailson Fernandes e Marcos Gondim, que nos auxiliaram na elaboração deste trabalho.

(6)

“A tarefa não é tanto ver aquilo que ninguém viu, mas pensar o que ninguém ainda pensou sobre aquilo que todo mundo vê.”

(Arthur Schopenhauer)

(7)

Trabalho de conclusão de curso que tem como objetivo maior realizar uma análise comparativa entre a utilização de um servidor DNS recursivo sem os complementos de segurança do DNSSEC e a posterior implementação destes componentes no intento de sanar uma das vulnerabilidades conhecidas do DNS, o cache poisoning. Para explorar esta vulnerabilidade, utilizou-se um metasploit denominado de MSF3, que possui uma ferramenta para envenenamento de cache chamada de BAILIWICKED_HOST. A ferramenta analisa o cabeçalho dos pacotes DNS com o propósito de identificar o QID gerado na consulta e, quando encontrado, injeta uma entrada falsa no cache do servidor DNS recursivo, redirecionando os acessos do endereço original para um endereço fornecido pelo atacante. Foram implementadas as extensões de segurança do DNSSEC ao servidor DNS recursivo e foram repetidos os mesmos testes, contudo, não houve sucesso no ataque, pois o DNSSEC mitigou a vulnerabilidade outrora relatada.

Palavras-chave: DNS. DNSSEC. Segurança. Vulnerabilidades. Metasploits.

Bailiwicked_Host. MSFCONSOLE.

LISTA DE ABREVIATURAS E SIGLAS

(8)

AAAA Address IPv6

ANY Requisição de Todas as RRs do Domínio

ARPA Advanced Research Projects Agency

AXFR Requisição para Transferência de Zona

Cache Armazenamento Temporário em HD

CNAME Canonical Name

CRC32

DIG Cyclic Redundancy CheckDomain Information Groper

DLV DNS Lookaside Validation

DNS Domain Name System

DNSKEY RR do DNSSEC

DNSSEC Domain Name System Security Extensions

DoS Denial of Service

DS Delegation Signer

FQDN Fully Qualified Domain Name

Hash Algorírimo de Verificação de Comprimento de Dados.

HINFO Host Information

Host Qualquer Equipamento Endereçável numa Rede

Hostid Parte do Endereçamento IP para Hosts

HTTPS Hyper Text Transfer Protocol Secure

IANA Internet Assigned Number Authority

ICANN Internet Corporation for Assigned Names and Numbers

In-Addr No Endereço

Internet Rede Mundial de Computadores

IP

ISC Internet ProtocolInternet Systems Consortium

Key Tag Etiqueta Chave

KSK Key Signing Key

MD5 Message-Digest Algorithm 5

MX Mail Exchange

Netid Parte do Endereçamento IP para Rede

NS Name Server

NSEC Next Secure

PGP

PING Pretty Good PrivacyUtilitário para testar a conectividade entre equipamentos

PTR Pointer

Resolver Cliente DNS

RFC Request for Comments. Documento que descreve os padrões de cada protocolo da Internet previamente a serem considerados um padrão.

RR Resource Records

RRset Resource Record Set

RRSIG Resource Record Signature

RSA Rivest, Shamir e Adleman

(9)

SHA Secure Hash Algorithm

SOA Start of Authority

SSL Secure Sockets Layer

String Sequência Ordenada de Caracteres

Subnetid Parte do Endereçamento IP para Máscara de Rede

TCP/IP Modelo de Referência

Top Level Domain Domínios de Maior Nível

TTL Time To Live

Web Sistema hipertextual que opera através da Internet Webmail Acesso a Servidor de Email Através de Interface Web

WKS Well Known Services

(10)

Nenhuma entrada de índice de ilustrações foi encontrada.

Índice de Quadros

(11)

Quadro 2: RRs - Resource Records Set do DNS...22

Quadro 3: Servidores Raiz...24

Quadro 4: Arquivo de Zona Inverso...27

Quadro 5: Domínios Genéricos...29

Quadro 6: Domínios de Universidades...29

Quadro 7: Domínios de Pessoas Físicas...29

Quadro 8: Pessoas Jurídicas com Restrições...30

Quadro 9: Pessoas Jurídicas - DNSSEC Obrigatório...30

Quadro 10: Tabela de Hosts...49

Quadro 11: Pessoas Jurídicas - DNSSEC Obrigatório...50

Quadro 12: Parâmetros do Ataque...50

Quadro 13: O Ataque...52

Quadro 14: DIG www.tjpe.jus.br...56

Quadro 15: DIG www.tjpe.jus.br comprometido...56

Quadro 16: Arquivo de Configuração Servidor DNSSEC...59

Quadro 17: Declaração do DLV no Arquivo de Configuração...59

Quadro 18: Teste de Funcionamento Servidor DNSSEC...60

Quadro 19: Ataque ao DNSSEC...61

Quadro 20: DIG para www.tjpe.jus.br...62

Quadro 21: DIG www.google.com...64

Quadro 22: Domínio www.google.com comprometido...65

Índice de Figuras

Figura 1: Sites e Domínios...17

Figura 2: Hierarquia do DNS...19

Figura 3: Zona e Domínio .br...23

(12)

Figura 5: Transferência de Zona...25

Figura 6: DNS na Internet...26

Figura 7: Exemplo de Domínio Inverso...27

Figura 8: Domínios de Países...28

Figura 9: Domínios Genéricos...28

Figura 10: Resolução Recursiva...32

Figura 11: Cabeçalho DNS...33

Figura 12: Mensagens DNS...35

Figura 13: Ataque DNS...36

Figura 14: Hash criada com o algoritmo MD5 sobre mensagem...38

Figura 15: Codificação e decodificação simétrica...39

Figura 16: Codificação e decodificação assimétrica...40

Figura 17: Processo de assinatura digital...41

Figura 18: Topologia do Laboratório...46

Figura 19: DNS Spoofing...48

Figura 20: Tática do Metasploit...51

Figura 21: Interface de Rede com DNS...53

Figura 22: Ping para www.tjpe.jus.br...54

Figura 23: Ping www.tjpe.jus.br comprometido...54

Figura 24: Acesso Comprometido...55

Figura 25: Topologia do Laboratório...57

Figura 26: Ilhas de Confiança...57

Figura 27: Exemplo de Domínio Sem DNNSEC...58

Figura 28: Acesso Normalizado à www.tjpe.jus.br...63

Figura 29: Cenário do Laboratório...63

Figura 30: Acesso Comprometido a www.google.com...66

Figura 31: DNSSEC Não Implementado...66

Figura 32: DNSSEC Implementado...67

Figura 33: Incidentes Reportados em 2012...69

Figura 34: Incidentes Reportados em 2013...69

(13)

Sumário

1. Introdução...13 1.1. Objetivo Geral...16 1.2. Objetivos Específicos...16 2. Fundamentação Teórica...17 2.1. Espaço de nomes...18

2.2. Hierarquia de Servidores de Nome...20

2.3. Zona e Domínio...20

2.4. Tipos de Registros...22

2.5. Servidor Raiz...23

2.6. Servidores Primário e Secundário...25

2.7. O DNS na Internet...26 2.8. Categorias de Domínios...29 2.9. Resolver...30 2.10. Resolução Recursiva...31 2.11. Resolução Interativa...33 2.12. Cabeçalho do DNS...33 2.13. Cache...34 2.14. Mensagens DNS...35 2.15. DNSSEC...36 2.16. Hash...37

2.17. Criptografia de chave pública...38

2.18. Assinatura Digital no DNSSEC...40

2.19. Tipos de Chaves do DNSSEC...42

2.20. Tipos de registros do DNSSEC...42

3. Análise Comparativa...46

3.1. DNS Spoofing...47

3.2. Análise Prática...48

3.3. Realização do Ataque ao DNS...49

3.4. Implementação do DNSSEC...57

3.5. Realização do Ataque ao DNSSEC...61

4. Considerações Finais e Trabalhos Futuros...68

(14)

1. Introdução

Conforme Forouzan (2008) para que um equipamento seja identificado em uma rede de computadores, os protocolos de comunicação de dados utilizam o endereço IP, todavia, as

(15)

pessoas preferem memorizar nomes a endereços numéricos. Desta forma, faz-se necessária a implantação de um sistema que realize a tradução destes nomes para endereços numéricos, ou seja, os endereços IP de cada equipamento.

Quando a Internet não era tão difundida, o mapeamento era feito usando um arquivo de host local. Este arquivo continha apenas duas colunas: nome e endereço IP. Todo computador possuía este arquivo e o atualizava periodicamente com base em um arquivo de

hosts central (mestre).

De acordo com Lucas (2013), a partir do crescimento das redes de computadores e da Internet, tornou-se inviável a utilização de um arquivo de hosts para relacionar cada endereço IP presente na rede mundial de computadores. O arquivo de hosts seria grande demais para ser armazenado em um computador, e, além disso, seria impossível manter este arquivo atualizado sempre que houvesse uma alteração. Uma solução centralizada para fornecer as informações de mapeamento dos endereços causaria um tráfego exagerado na Internet, então foi proposta uma solução distribuída que tem por objetivo dividir entre determinados computadores as informações de modo que uma requisição pudesse ser realizada a um destes computadores que estivesse mais próximo do solicitante, melhorando assim a eficiência e a agilidade nas consultas e, por consequência, diminuindo o tráfego de dados na rede durante estas requisições. O DNS ou Sistema de Nomes de Domínios foi estruturado e, posteriormente, implementado como o principal sistema para resolução de nomes em redes TCP/IP.

No início da Internet, apenas entusiastas e estudiosos utilizavam os recursos desta rede. O compartilhamento de informações acadêmicas praticamente dominava o tráfego da Internet nesse tempo. Não havia motivos que incentivassem usuários mal intencionados a executarem ataques de invasões e de captura de dados. Os usuários pouco se preocupavam em garantir a segurança dos dados trafegados. O DNS foi implantado durante essa época, e consequentemente, absorveu essa falta de preocupação com a autenticidade da informação.

O crescimento desta rede mundial proporcionou a imersão de usuários e aplicações que a Internet não foi originalmente projetada para absorver.

(16)

A utilização da Internet para ter acesso à conta bancária, realização de transações financeiras e a trocas de informações contendo segredos industriais atraiu o interesse de pessoas que quisessem tirar proveito desse cenário.

Aproveitando-se de falhas no DNS, durante uma requisição do resolver, o atacante pode responder a requisição antes do servidor DNS. Com isso, o atacante direciona o usuário a outro destino. O usuário está sujeito a passar as suas informações sem sequer perceber o ataque. Era preciso desenvolver uma forma de comprovar a autenticidade dos servidores DNS e para isso, foi criado um conjunto de extensões de segurança para ser adicionado ao DNS, o DNSSEC.

Segundo Lucas (2013), o DNSSEC mantém a estrutura original do DNS, entretanto, adiciona verificações criptográficas para assegurar que os dados recebidos pelo computador cliente sejam idênticos aos transmitidos pelo servidor.

Ainda em conformidade com o referido autor, o DNSSEC compartilha muitos pontos em comum em comparação com os protocolos HTTPS e PGP, com exceção de seus rigorosos métodos de codificação de dados. O DNSSEC garante a autenticidade da informação obtida do servidor, a integridade, assegurando que a informação não seja alterada durante o transporte até o solicitante e a garantia da não existência de um nome. Caso haja uma consulta a um nome de domínio que não exista, o DNSSEC tem mecanismos que asseguram e comprovam que este nome realmente não existe.

O DNSSEC não garante confidencialidade, as informações continuarão públicas e também não garante proteção contra ataques de negação de serviço, os ataques DoS.

(17)

1.1.Objetivo Geral

Comparar o comportamento do DNS e do DNSSEC diante de ataques e violações de segurança.

1.2.Objetivos Específicos

 Realizar uma análise entre as vulnerabilidades do DNS e a aplicação do DNSSEC;  Descrever as melhorias de segurança apresentadas pelo DNSSEC.

(18)

Conforme Forouzan (2008), para que um equipamento seja identificado em uma rede de computadores, os protocolos de comunicação de redes utilizam o endereço IP, contudo, as pessoas preferem memorizar nomes a endereços numéricos. Desta feita, faz-se necessária a implantação de um sistema que realize a tradução destes nomes para endereços numéricos, ou seja, os endereços IP de cada equipamento. Com a expansão da Internet o arquivo de hosts que realizava este mapeamento tornou-se obsoleto e ineficaz, despertando a necessidade de um sistema de resolução de nomes centralizado. Uma das soluções foi o DNS, ferramenta em uso até os dias atuais. Vide Figura 1.

As informações sobre hosts x endereços IP são divididas de forma hierárquica entre determinados computadores e disponibilizados para a consulta dos demais computadores.

Figura 1: Sites e Domínios

Fonte: Próprios autores, (2014)

Quando um computador necessitar uma consulta de endereço, ele vai solicitar ao computador mais próximo que possua as informações necessárias à resolução de nome para o endereço IP daquele host. Para que estes nomes sejam inequívocos, selecionados dentro de um espaço de nomes. Um espaço de nomes único pode ser definido de duas maneiras, simples ou hierárquica.

2.1.Espaço de nomes

Em um espaço de nomes simples, um nome é atribuído a um endereço, sendo uma sequência não estruturada de caracteres. Uma das principais desvantagens é que este

(19)

endereçamento não pode ser utilizado na Internet devido à necessidade de um gerenciamento de forma centralizada com objetivo de evitar entradas duplicadas ou ambíguas.

Exemplo: laboratorio-d4.

Muitas instituições podem possuir computadores em laboratórios e nomeá-los de laboratorio-d4, por ser um nome simples e sem estrutura hierárquica, este nome não é válido para a Internet, pois os computadores não saberiam para qual estação encaminhar os pacotes caso o nome fosse ambíguo.

Num sistema de espaçamento de nomes hierárquico, cada entrada de nome é constituída por várias partes. A primeira delas é responsável pela identificação da origem ou natureza da organização; A segunda pode definir o nome de uma organização; a terceira definir os departamentos da mesma e assim em diante. Neste cenário, há uma estruturação para os endereços de maneira hierárquica.

Exemplo: laboratorio-d4.campuslocal.unibratec

Para que exista este espaçamento de nomes hierárquico se fez necessária a produção e desenvolvimento do espaçamento de nomes de domínio. Na referida estrutura, os nomes são definidos em um formato de árvore invertida com a raiz no topo, um modelo top down. Esta estrutura hierárquica pode conter até 128 níveis; a partir do nível “0” (o raiz, representado pelo “.”) seguido de 127 níveis. Cada espaço de nomes utilizado é denominado de rótulo. Cada nó na árvore hierárquica do DNS tem um nome de domínio.

Um nome de domínio totalmente qualificado, ou FQDN, é a sequência dos rótulos separados por pontos. (.), sempre lidos do nó à raíz.

Na Figura 2 é exibido um domínio com 4 níveis até a raiz: webmail.unibratec.edu.br. Também demonstra a separação dos espaços de nomes e mostra a raiz, que não possui rótulo. Um nome de domínio completo ou nome de domínio totalmente qualificado, o FQDN, termina sempre em um rótulo vazio, que é a raiz. Na Figura 2 o FQDN é webmail.unibratec.edu.br.

(20)

Na Figura 2 pode-se observar a hierarquia dos domínios, onde webmail é parte integrante do domínio unibratec e é seu subdomínio, unibratec está abaixo do domínio edu, sendo parte integrante do mesmo, que, por sua vez, está abaixo do domínio .br e é parte do referido domínio.

2.2.Hierarquia de Servidores de Nome

As informações existentes no espaço de nomes de domínio precisam ser armazenadas, contudo, é extremamente ineficiente e também inseguro ter um único computador armazenando essa massa de dados. A ineficiência parte da incapacidade do computador responder a um grande volume de requisições de todo o mundo, sobrecarregando o sistema, e inseguro, pois qualquer inconsistência tornaria os dados inacessíveis. (Forouzan, 2008).

Para mitigar tais falhas, é necessário dividir estes dados entre diversos computadores, denominados servidores DNS. Eliminando um ponto único de falha, e dividindo o espaço

(21)

inteiro em muitos domínios baseados no primeiro nível, ou seja, todos os domínios abaixo do raiz.

2.3.Zona e Domínio

Conforme Forouzan (2008), como toda a hierarquia de nomes de domínio completa não pode ser alocada em apenas um único servidor, ela é dividida entre muitos servidores. Cada servidor é responsável ou têm autoridade sobre o que é denominado de zona. Pode ser definida como uma parte adjacente da árvore inteira. Se um servidor aceitar a responsabilidade por um domínio e não o dividir em domínios menores, o “domínio” e a “zona” se referem à mesma coisa. O servidor criará uma base de dados chamada de arquivo de zonas e manterá todas as informações sobre cada nó sobre este referido domínio. Entretanto, no caso de um servidor dividir seu domínio em subdomínios e delegar parte da sua autoridade a outros servidores, “domínio” e “zona” se referem a coisas diferentes. As informações sobre os nós nos subdomínios são armazenadas nos servidores dos níveis inferiores, com o servidor original mantendo algum tipo de referência para esses servidores de nível mais baixo. É claro que o servidor original não fica totalmente liberado da responsabilidade: ele ainda tem uma zona, mas as informações detalhadas são mantidas pelos servidores de nível mais baixo que ele.

Os dados sobre cada domínio são armazenados no arquivo de zona. Vide Quadro 1. Estes arquivos podem ser de associação direta, realizando o mapeamento de nome para endereço IP, ou reversa, de endereço IP para nome.

No Quadro 1, na linha ”mail.exemplo.com.br IN 10.1.1.1” exemplifica-se a associação direta, nome para endereço IP. Já na linha zone "0.223.186.in-addr.arpa" exemplifica-se a associação reversa para o bloco de endereços IP 186.223.0.0.

Exemplo de arquivo de zona:

Quadro 1: Exemplo de Arquivo de Zona

20

exemplo.com.br. IN SOA ns1.exemplo.com.br. hostmaster.exemplo.com.br. (

20140320 ; serial

3600 ; refresh (1h)

1800 ; retry (30m)

(22)

Tais informações são adicionadas ao DNS através de um registrador. Uma entidade comercial autorizada pelo ICANN. Tal entidade verifica se o nome solicitado é único e, posteriormente, o insere no banco de dados do DNS. Também é cobrada uma taxa para o registro do domínio. No Brasil a entidade responsável pelo registro e publicações de domínios do domínio br é o Registro.BR.

2.4.Tipos de Registros

Na Quadro 2 são encontrados os tipos de Resource Records, que são os registros utilizados para o apontamento dos diversos serviços utilizados no DNS:

Quadro 2: RRs - Resource Records Set do DNS

Tipo RR Descrição

1 A (Address) Mapeamento de um endereço de 32 bits IPv4.

2 NS (Name Server) Identifica o servidor autoritativo para a zona.

5 CNAME (Canonical Name) Define um apelido para o nome real de um servidor.

6 SOA (Start Of Autority) Define onde a zona se inicia.

(23)

12 PTR (Pointer) Utilizado para conversão de um endereço IP para um nome_{de domínio.}

14 HINFO (Host Information) Especifica o hardware e o sistema operacional do servidor.

15 MX (Mail Exchange) Redireciona o correio para o servidor de correio eletrônico.

28 AAAA (Address) Mapeamento de um endereço IPv6.

252 AXFR (Requisição de transferência de uma zona) Requisição de transferência de uma zona inteira.

255 ANY (Uma Requisição para todos os RRs.) Uma requisição para todos os RRs.

Fonte: Adaptado de Forouzan, (2008)

Na Figura 3 ilustra-se a distinção entre zona e domínio. A zona .br restringe-se ao servidor ou grupo de servidores da referida zona, e o domínio .br consiste em todos os nós ou domínios abaixo dele mesmo. Todos os domínios que estão sob a sua jurisdição.

Figura 3: Zona e Domínio .br

Fonte: Próprios autores, (2014)

Zona BR

(24)

2.5.Servidor Raiz

O servidor raiz é aquele cuja zona consiste na árvore inteira. Normalmente os servidores raiz não armazenam informações relativas a domínios, mas delegam esta atividade a outros servidores. Os servidores raiz estão espalhados pelo mundo.

Conforme o REGISTRO.BR, membro do NIC.BR - Núcleo de Informação e Coordenação do Ponto BR, na zona br encontram-se seis servidores raiz, sendo três deles em território nacional e os outros três no exterior. Na Figura 04 é ilustrado um exemplo de cenário onde o servidor raiz fica posicionado em relação aos domínios de primeiro nível.

Figura 4: Hierarquia de Servidores de Nomes

Na Tabela 2, de acordo com os dados da IANA – Internet Assigned Numbers

Authority, organização mundial de autoridade máxima incumbida da atribuição dos números

na Internet, nos quais estão os endereços IP e os números de portas de comunicação de protocolos de rede, são apresentados os 13 servidores raiz ao redor do mundo, seus respectivos endereços IP e seus mantenedores:

Quadro 3: Servidores Raiz

Hostname Endereço IPv4 e Ipv6 Gestor

a.root-servers.net 198.41.0.4, 2001:503:ba3e::2:30 VeriSign, Inc.

b.root-servers.net 192.228.79.201 University of Southern California (ISI)

c.root-servers.net 192.33.4.12 Cogent Communications

(25)

e.root-servers.net 192.203.230.10 NASA (Ames Research Center)

f.root-servers.net 192.5.5.241, 2001:500:2f::f Internet Systems Consortium, Inc.

g.root-servers.net 192.112.36.4 US Department of Defence (NIC)

h.root-servers.net 128.63.2.53, 2001:500:1::803f:235 US Army (Research Lab)

i.root-servers.net 192.36.148.17, 2001:7fe::53 Netnod

j.root-servers.net 192.58.128.30, 2001:503:c27::2:30 VeriSign, Inc.

k.root-servers.net 193.0.14.129, 2001:7fd::1 RIPE NCC

l.root-servers.net 199.7.83.42, 2001:500:3::42 ICANN

m.root-servers.net 202.12.27.33, 2001:dc3::35 WIDE Project

Fonte: http://www.iana.org/domains/root/servers, (2014)

2.6.Servidores Primário e Secundário

Para Forouzan (2008), há dois tipos de servidores DNS, o primário e o secundário. O servidor primário é responsável pelo armazenamento do arquivo de zona, onde são armazenadas todas as publicações de novos domínios ou atualizações de domínios existentes, que sejam de sua autoridade. Também incumbido dos processos de criação, manutenção e atualização do arquivo de zona, que é armazenado localmente.

O servidor secundário é um servidor que recebe uma réplica dos dados de um servidor primário ou de outro servidor secundário e também os armazena localmente. Estas atualizações ocorrem com a periodicidade de 30 minutos, conforme ilustrado na Figura 5.

Figura 5: Transferência de Zona

Quando da ocorrência de uma atualização e da necessidade do servidor secundário ser atualizado, estas informações serão enviadas pelo servidor primário, tarefa denominada de transferência de zona.

(26)

Ambos servidores, primário e secundário, são os servidores autoritativos das zonas que os mesmos pertencem. A motivação para criar servidores secundários é de estabelecer redundância nos dados e serviços caso o primário falhe e não criar um nível inferior de autoridade para o servidor secundário. Desta feita, caso o servidor primário falhe, o secundário assumirá o tráfego de requisições dos clientes e estes continuarão tendo o serviço de DNS sendo prestado.

2.7.O DNS na Internet

Para Forouzan (2008), o DNS é multiplataforma. Na Internet, a árvore é separada em três categorias; domínios genéricos, domínios de países, e domínios inversos, conforme detalhado na Figura 6.

Figura 6: DNS na Internet

Fonte: Adaptado de Forouzan, (2008)

Na estrutura de domínio inverso, a consulta é realizada através do endereço IP para o nome de domínio. Também intitulada de consulta de ponteiro, PTR nos Resource Records.

“Este tipo de consulta é chamado de consulta

inversa ou de ponteiro (PTR). Para tratar de uma consulta de ponteiro, o domínio inverso é adicionado ao espaço de nomes de domínio com o nó de primeiro nível chamado arpa (por motivos históricos). O segundo nível também em um único nó, chamado in-addr (de inverse address – endereço inverso). O restante do domínio define endereços IP”. Forouzan, 2008.

No Quadro 4 é apresentado um exemplo de arquivo de zona inversa. Evidenciam-se os RRs de ponteiro, ou simplesmente de PTR, nas linhas ”IN PTR

(27)

server01.exemplo.com.br.” “IN PTR server02.exemplo.com.br.” e “IN PTR mail.exemplo.com.br.”

Tais registros são necessários para que quando as requisições de resoluções inversas cheguem ao servidor DNS, sejam respondidas para seus respectivos hosts tais como mail.exemplo.com.br, server01.exemplo.com.br.

Quadro 4: Arquivo de Zona Inverso

Na Figura 7 é apresentada a estrutura de uma consulta inversa ou de ponteiro onde o endereço IP é 108.171.43.177, que apresentado no formato invertido é 177.43.171.108.in-addr.arpa.

Figura 7: Exemplo de Domínio Inverso

Os servidores que gerenciam o domínio inverso também possuem estrutura hierárquica. E, isso, quer dizer que a parte netid do endereço deve estar em um nível mais alto que a parte de subnetid, por sua vez, deve estar um nó acima da parte de hostid. É este modelo que faz com que o domínio pareça invertido comparado a um domínio genérico ou de países.

Em sequência, na Figura 8, são exemplificados alguns domínios de países. Que são definidos pela abreviação do nome do país em dois caracteres. No exemplo da Figura 7 temos

; reverse address file for exemplo.com.br

exemplo.com.br. IN SOA ns1.exemplo.com.br. hostmaster.exemplo.com.br. (

20140320 ; serial 3600 ; refresh (1h) 1800 ; retry (30m) 86400 ; expire (1d) 900 ) ; minimum (15m) exemplo.com.br. IN NS ns1.exemplo.com.br. exemplo.com.br. IN MX 10 mail.exemplo.com.br. mail.exemplo.com.br. IN A 10.1.1.1 www.exemplo.com.br. IN A 10.1.1.2 ; Registers of exemplo.com.br 1 IN PTR server01.exemplo.com.br. 2 IN PTR mail.exemplo.com.br.

(28)

os servidores da Alemanha (DEutschland), BRasil, FRança e Reino Unido (United Kingdom).

Figura 8: Domínios de Países

Na Figura 9 observa-se a distribuição de alguns domínios genéricos, abaixo do servidor raiz.

Figura 9: Domínios Genéricos

(29)

No Quadro 5 são apresentados os tipos de domínios genéricos: Quadro 5: Domínios Genéricos

Genéricos

Rótulo Descrição

COM.BR Atividades comerciais

ECO.BR Atividades com foco eco-ambiental

EMP.BR Pequenas e micro-empresas

NET.BR Atividades comerciais

Fonte: http://registro.br/dominio/categoria.html, (2014)

No Quadro de número 6 é apresentado o tipo de domínio utilizado por universidades: Quadro 6: Domínios de Universidades

Universidades

EDU.BR Instituições de ensino superior

No Quadro de número 7 são apresentados os tipos de domínios que podem ser utilizados por pessoas físicas:

Quadro 7: Domínios de Pessoas Físicas Pessoas Físicas

BLOG.BR Web logs

FLOG.BR Foto logs

NOM.BR Pessoas Físicas

VLOG.BR Vídeo logs

WIKI.BR Páginas do tipo 'wiki'

No Quadro 8 são descritos os tipos de domínios para pessoas jurídicas com restrições:

Quadro 8: Pessoas Jurídicas com Restrições Pessoas Jurídicas com Restrições

AM.BR Empresas de radiodifusão sonora

(30)

FM.BR Empresas de radiodifusão sonora

G12.BR Instituições de ensino de primeiro e segundo grau

GOV.BR Instituições do governo federal

MIL.BR Forças Armadas Brasileiras

ORG.BR Instituições não governamentais sem fins lucrativos

PSI.BR Provedores de serviço Internet

Por último, no Quadro 9 são apresentados os tipos de domínios com obrigatoriedade de utilização do DNSSEC:

Quadro 9: Pessoas Jurídicas - DNSSEC Obrigatório Pessoas Jurídicas - DNSSEC OBRIGATÓRIO

B.BR Bancos

JUS.BR Instituições do Poder Judiciário

LEG.BR Instituições do Poder Legislativo

MP.BR Instituições do Ministério Público

2.9.Resolver

O mapeamento de um nome para um endereço ou de um endereço para um nome é chamado de resolução de nome-endereço.

FOROUZAN (2008).

O DNS é projetado como aplicativo cliente-servidor. Quando um computador precisa realizar o mapeamento de um endereço para o nome ou de um nome para o endereço, ele acionará um cliente DNS chamado de resolver. O resolver acessa o servidor DNS que esteja mais próximo com a requisição do mapeamento. Se o servidor possuir tal informação, ele responderá ao resolver, caso contrário, ele direcionará o resolver para outros servidores DNS para que forneçam os dados para o mapeamento.

Por fim, o resolver verifica se a informação recebida é de fato uma solução real para a requisição ou um erro e envia o resultado ao servidor DNS.

(31)

Geralmente, o resolver indica o nome do domínio ao servidor e solicita o endereço IP daquele domínio. O servidor fará uma verificação nos domínios genéricos ou domínios de países com intuito de entregar a informação solicitada.

O resolver também pode solicitar a consulta de um endereço IP para o servidor a fim de mapear o nome do domínio. Como descrito no tópico 2.7, tal tipo de consulta é denominada de consulta de ponteiro, ou PTR. Para responder as requisições de mapeamento, o servidor utiliza o DNS inverso, onde o endereço IP é invertido e dois rótulos são adicionados, in-addr e arpa antes de enviar a requisição ao servidor, criando assim um nome de domínio válido no cenário de DNS inverso.

2.10.Resolução Recursiva

De acordo com Forouzan (2008), o resolver pode solicitar uma resposta recursiva de um servidor de nomes. Ou seja, o resolver aguarda que o servidor forneça a resposta final. Caso o servidor possua autoridade sobre o domínio requisitado, o mesmo verifica em seu banco de dados e responderá a requisição. Do contrário, o servidor envia o pedido a outro servidor, normalmente o servidor de um nível acima. Se este servidor for a autoridade sobre o domínio, ele responde a requisição; de outro modo, a consulta será direcionada a outro servidor. Quando a requisição for por fim resolvida, a resposta será encaminhada até o solicitante, o resolver, conforme Figura 10.

(32)

Fonte: Adaptado de ftp://ftp.registro.br/pub/doc/introducao-dns-dnssec.pdf, (2014)

2.11.Resolução Interativa

Segundo Forouzan (2008), num caso onde o resolver não solicite uma resolução recursiva, o mapeamento poderá ser feito interativamente, ou seja, repetidamente. O resolver questionará o servidor local sobre o mapeamento de um domínio, uma vez não seja de sua

(33)

autoridade, o servidor retornará ao resolver o endereço de um servidor DNS que possa realizar o mapeamento. O cliente é responsável pela repetição das consultas aos servidores subsequentes até obter o endereço IP do domínio outrora solicitado.

2.12.Cabeçalho do DNS

Na Figura 11 pode-se observar o que consta dentro do cabeçalho do DNS e os detalhes importantes para a compreensão do funcionamento de um dos ataques ao DNS.

Figura 11: Cabeçalho DNS

Fonte: Adaptado de Liu; Albitz, (2006)

 Source / Destination IP Address

Os campos Source e Destination IP Address, refletem o endereço IP de origem e destino. Ou seja, o host que originou a consulta ao host responsável pela resolução da mesma.

 Source / Destination Port Numbers

Os campos Source e Destination Port Numbers, identificam o número das portas de origem e destino, respectivamente, no cabeçalho IP. O servidor DNS “escuta” a porta 53 por padrão, mas pode ser alterada ou escolhida aleatoriamente.

(34)

 Query ID

O campo Query ID, ou identificação de pergunta, como o nome sugere, identifica e vincula as requisições de resolução de nomes a um número, capacitando assim o servidor DNS a responder mais de uma consulta ao mesmo tempo.

2.13.Cache

Toda vez que um servidor recebe uma consulta de um nome que não está em seu domínio, ele precisa procurar um endereço IP de servidor em seu banco de dados.

A redução deste tempo de pesquisa aumentaria a eficiência e por consequência, a percepção do usuário ao receber com maior celeridade a resposta da consulta. O DNS utiliza o procedimento chamado cache. Toda vez que um servidor solicitar um mapeamento a outro servidor e receber sua resposta, ele escreverá esta informação em sua memória cache. Se o mesmo computador ou mesmo outro solicitar a resolução daquele mesmo endereço, o servidor poderá consultar o cache para responder aquela solicitação. Para informar ao computador solicitante que a resposta que foi encaminhada é oriunda do cache, o servidor marcará a resposta como não autorizada. Forouzan (2008).

O uso do cache acelera a resolução, mas também pode significar um problema. Se um servidor inserir um mapeamento na memória cache por um longo tempo, poderá ocorrer de um domínio ter trocado de endereço IP e o mapeamento desatualizado será enviado aos usuários.

No intuito de mitigar esta deficiência, são empregadas duas técnicas; sempre será adicionada no cache a informação referente ao tempo de vida, em segundos, daquele mapeamento, denominado de TTL – Time To Live. Passado este intervalo de tempo, o mapeamento se tornará inválido e as demais consultas para aquele domínio serão encaminhadas ao servidor autoritativo. Em segundo lugar, o DNS exige que cada servidor possua um contador de TTL. Uma varredura deve ser realizada periodicamente na memória cache para eliminar os registros com TTL expirados.

(35)

2.14.Mensagens DNS

Para Forouzan (2008), o DNS tem dois tipos de mensagens; perguntas e respostas. A mensagem de consulta consiste em um cabeçalho e o registro de pergunta; a mensagem de resposta também consiste em um cabeçalho, registros de resposta, registros autorizados e registros adicionais. Na Figura 13 é exibido o fluxo de troca de mensagens do DNS:

Figura 12: Mensagens DNS

2.15.DNSSEC

Existem ataques contra o serviço DNS, por exemplo, que afetam diretamente no seu funcionamento, causando interrupções na rede e gerando prejuízos. Entretanto, um atacante pode agir de modo que a sua máquina responda a requisição de um usuário que deseja acessar o site desta empresa antes que o servidor DNS original possa responder. Com isto, o usuário pode ser direcionado a outro servidor contendo um site semelhante ao original e inserir dados de controle de acesso ou dados sigilosos. Conforme a Figura 13, o atacante coletaria estes dados sem nem sequer ter alterado ou sabotado o serviço de DNS da empresa. Logo não chamaria a atenção dos administradores do serviço.

Figura 13: Ataque DNS

Troca de Mensagens

(36)

Segundo Lucas (2013), um site pode garantir a sua autenticidade através da utilização de certificados SSL. Porém, para que este tipo de autenticação funcione, é necessário que o tráfego encontre o destino correto. O site criado e disponibilizado pelo atacante também pode possuir uma assinatura digital fornecida por uma unidade certificadora não oficial. Com o descuido, o usuário acaba aceitando essa assinatura sem verificar a unidade certificadora e o pequeno cadeado aparece no navegador. Isto passa uma falsa segurança ao usuário. Estes problemas normalmente são resolvidos de forma rápida. Mas garantir acesso correto e autenticado ao DNS permite evitar toda uma categoria de problemas.

O DNSSEC é um conjunto de extensões de segurança para ser implementado ao DNS. Definido no RFC 2065 em 1997, o DNSSEC trouxe ajustes para mitigar ataques que abrangia a autenticidade das partes envolvidas em uma requisição DNS. As melhorias de segurança trazidas pelo DNSSEC consistiam em adicionar a criptografia de assinatura digital nos dados

(37)

DNS transmitidos. Esta melhoria evita que um atacante possa introduzir informações alteradas e falsas, respondendo a requisição de um resolver antes que o servidor recursivo possa responder. Ou o atacante pode intermediar a comunicação entre o servidor recursivo e o servidor autoritativo, onde as informações alteradas e falsas sejam enviadas ao servidor recursivo antes que o servidor autoritativo possa enviar as informações corretas. Para a criptografia de assinatura digital funcionar, e por sua vez, fazer o DNSSEC também funcionar, é preciso a utilização de hash e da criptografia de chaves públicas.

2.16.Hash

Segundo Carvalho, um hash, ou função hash, é um algoritmo que converte toda uma sequência de informação em uma string de tamanho fixo. Esta conversão é realizada de forma que não é possível reverter e obter os dados originais. Existem vários algoritmos de hash que geram string de vários tamanhos. Mas cada algoritmo de hash gera um tamanho especifico de

string. E este tamanho será sempre o mesmo se utilizado o mesmo algoritmo. Por exemplo, o

algoritmo de hash SHA-1 gera sempre strings de 40 caracteres de tamanho, o algoritmo de

hash CRC32 gera sempre strings de 8 caracteres e o algoritmo MD5 gera strings de 32

caracteres.

A Figura 14 mostra a diferença entre os hashes gerados pelo algoritmo MD5 com a adição de um ponto final na mensagem.

(38)

Fonte: http://www.gta.ufrj.br, (2014)

2.17.Criptografia de chave pública

Uma mensagem ou informação que precisa ser protegida e modificada (criptografada) para que não possa ser lida por quem não possuir o modo de desfazer as modificações. Tanto quem envia quanto quem recebe a informação, possue a mesma chave para proteger ou desfazer a proteção. Logo, esta chave deve ser compartilhada apenas por quem for autorizado a enviar e receber as informações. A criptografia simétrica é ao que representa o método utilizado neste paragrafo e ilustrado na Figura 15.

(39)

Outro método foi criado para mitigar os problemas causados no compartilhamento da chave utilizada na criptografia simétrica. Este método é o utilizado na criptografia assimétrica e faz uso de duas chaves por partes envolvidas na transmissão da informação: chave pública e chave privada. A chave pública, como o nome já sugere, é a chave que deve ser compartilhadas entre todas as partes envolvidas na troca de informações. Já a chave privada deve ser mantida em segurança, pois além de a chave privada de cada parte poder desfazer a proteção realizada utilizando-se a sua respectiva chave pública, ela serve como uma assinatura digital, pois garante que a mensagem enviada e criptografada pela chave privada de uma das partes foi realmente enviada por ela. A Figura 16 apresenta o processo de codificação e decodificação de uma mensagem com o uso de chaves privada e pública.

(40)

O DNSSEC faz uso da criptografia assimétrica e também de hash para assinar digitalmente os dados DNS.

2.18.Assinatura Digital no DNSSEC

De acordo com Lucas (2013), com a combinação da criptografia de hash e da utilização da criptografia de chave pública é que se forma a assinatura digital no DNSSEC. Esta assinatura tem como objetivo certificar a autenticidade da mensagem enviada. Dando garantias da identidade do remetente da mensagem. Um servidor DNS, com as extensões do DNSSEC, cria um hash a partir da mensagem, e em seguida, criptografa o hash com sua chave privada. Em seguida, o receptor da mensagem utiliza a chave pública do remetente para decifrá-la e certificar que o remetente é o esperado. Esta sequência é apresentada na Figura 17.

(41)

Caso o remetente seja diferente do esperado, a mensagem é considerada inválida e, consequentemente, descartada. Após a descriptografia com a chave pública do remetente e

(42)

confirmação da sua autenticidade, é verificado o hash para garantir a integridade da mensagem. Em caso de alteração da mensagem original através da verificação do hash. A mensagem também será considerada inválida.

2.19.Tipos de Chaves do DNSSEC

Dois tipos de chaves são utilizadas pelo DNSSEC: o KSK (Key Signing Keys) e ZSK

(Zones Signing Keys). A ZSK é designada para assinar uma determinada zona. Esta chave

pode ser mudada a qualquer momento. Já a chave do tipo KSK é apenas utilizada para assinar as RRs que contem todas as chaves DNS, inclusive as ZSK e KSK. Toda zona possui uma KSK, também chamado de SEP (Security Entry Point). Para que haja uma alteração do KSK, o registro de domínio e o registro de endereço IP devem também ser alterados.

As zonas DNSSEC passam por um processo onde são assinadas duas vezes. Os dados do DNS são primeiramente assinados pela chave ZSK, que por sua vez é assinado pela chave KSK. Este processo dificulta muito uma possibilidade do atacante, com os recursos tecnológicos atuais, de usar engenharia reversa para descobrir estas chaves. O avanço tecnológico pode chegar a conseguir quebrar este método de segurança por força bruta. Isso forçará uma atualização para o algoritmo de criptografia mais recente e mais eficaz. Estas chaves somente precisarão de uma atualização quando os algoritmos RSA-SHA1 com tamanho de 2048 bits passarem a ser quebrados através de força bruta.

2.20.Tipos de registros do DNSSEC

Assim como os registros que o DNS possui, o DNSSEC adiciona alguns registros que contém informações de criptografia e hash para fazer funcionar a validação das partes envolvidas em uma requisição DNS. Os quatro registros do DNSSEC são: DNSKEY, DS, RRSIG e NSEC.

DNSKEY – Registro que possui as chaves públicas da zona. Exemplo: manguetown.org. 3600 IN DNSKEY 257 3 8 HxAECbEjKMgZhc…

Este registro é composto pelos seguintes campos: manguetown.org. – representa o domínio.

3600 – Representa o Time To Live, que é medido em segundos. IN DNSKEY – indica o registro DNSKEY pertence à classe Internet.

(43)

257 – É o indicador do tipo de chave que o registro representa. Caso o valor seja igual a 256, o registro é do tipo ZSK. E caso seja igual 257 mostra que o registro é do tipo KSK.

3 – Indica o protocolo para qual o registro foi criado, ou seja, para que um registro DNSKEY seja utilizado pelo DNSSEC, o valor deverá ter valor 3. Caso tenha outro valor que não 3 neste campo, significa que o registro não é para o protocolo para DNSSEC.

8 – Representa qual algoritmo é utilizado. O algoritmo RSA-SHA256, que é recomendado atualmente, é representado pelo indicador 8.

HxAECbEjKMgZhc... – É a chave pública que possui tamanho de acordo com o algoritmo utilizado para gerá-la.

DS – É o registro que possui um hash do KSK ativo da zona, também possui informações sobre o algoritmo utilizado e a key tag atribuída. Exemplo: manguetown.org. 43200 IN DS 13099 8 2 BF258808...

Este registro é composto pelos seguintes campos: manguetown.org. – representa o domínio. 43200 – É o Time To Live, medido em segundos. IN DS – Indica o registro DS pertence à classe Internet. 13099 – É a key tag.

8 – Representa qual algoritmo é utilizado. O valor 8 representa o algoritmo RSA-SHA256. 2 – Indica o tipo de algoritmo que é utilizado para calcular o hash. O valor 2 representa o SHA256.

Um registro DS de uma zona está contido na sua zona pai. Logo, para se obter o registro DS manguetown.org. deve-se ser consultado os servidores de nomes de .org. Os servidores de nomes de uma zona deve possuir um registro DS para cada domínio único que faz uso do DNSSEC.

RRSIG – É o registro que provem a assinatura digital de um RRset. No caso de uma zona protegida por DNSSEC possui um RRset para www.manguetown.org. Um registro RRSIG está incluso nesta RRset. Exemplo: www.manguetown.org. 7200 no RRSIG A 5 3 3600 20140425054000 20140320050021 28367 manguetown.org. Th3NpusKq73oE...

Este registro é composto pelos seguintes campos:

www.manguetown.org. – Este conjunto de caracteres representa o nome do RRset. 7200 – É o Time To Live, medidos em segundos.

(44)

A – Representa qual o tipo de registro DNS que a assinatura é aplicada. Este campo pode ser identificado por SOA , AAAA, PTR, e até mesmo registro adicionado à zona pelo DNSSEC, como por exemplo, o NSEC.

8 – Indica o algoritmo utilizado para criar a chave. 3 – Define o número de nomes no RRset.

3600 – Indica o Time To Live original.

20140425054000 e 20140320050021 – Representam a data, hora, minuto e segundo que a assinatura expira, e respectivamente a data, hora, minuto e segundo que a assinatura torna-se válida.

28367 – Fornece a key tag (ou chave id) do registro DNSKEY que realizou essa assinatura. manguetown.org. – Representa o nome do signatário.

Th3NpusKq73oE... – São sequências longas de caracteres, formando a assinatura digital que é gerada após a zona ser assinada com a ZSK.

NSEC – Este registro de recurso proporciona uma prova da não-existência de um registro. Caso se tente localizar um registro que não consta no DNS, espera-se receber uma declaração do servidor autoritativo que este registro não existe. Logo, apresentar uma prova de que abc.manguetown.org não existe igualmente importante do que provar a sua existência. Exemplo: mail.manguetown.org. 900 IN NSEC www.manguetown.org. A TXT AAAA RRSIG NSEC DNSKEY

Este registro é composto pelos seguintes campos:

mail.manguetown.org. – Representa um nome de um host válido na zona. 900 – É o Time To Live, medidos em segundos.

IN NSEC – Indica o registro RRSIG pertence à classe Internet.

www.manguetown.org. – indica o seguinte nome de host válido na zona.

A TXT AAAA RRSIG NSEC DNSKEY – Representam uma lista dos tipos de registro associados com o host mail.manguetown.org.

(45)

3. Análise Comparativa

Neste capítulo, no intuito de promover uma análise comparativa entre DNS e DNSSEC, demonstrou-se a tática e a implementação de um Metasploit, um agente capaz de explorar uma vulnerabilidade do DNS, realizando um envenenamento de cache através de inundações de consultas e respostas ao servidor utilizando-se das Query IDs, números gerados para cada consulta ao servidor DNS, e as Destination Ports, Portas de Destino para inserir falsos registros no servidor DNS, tendo como finalidade o redirecionamento dos usuários para outo host e a posterior implementação do DNSSEC, no intuito de mitigar esta vulnerabilidade.

A topologia utilizada neste laboratório é exibida na Figura 18, onde observa-se uma estação cliente DNS sendo representado por um host com sistema operacional Windows 7® que consultou o domínio www.tjpe.jus.br através de um servidor DNS utilizando o sistema operacional Debian 7 e o atacante que está utilizando o sistema operacional BackTrack 5 R3.

Figura 18: Topologia do Laboratório

(46)

O Metasploit MSF3, é um conjunto de ferramentas nativas da distribuição Linux BackTrack 5 R3, direcionada à forense computacional, segurança e testes de penetração. Uma das ferramentas do MSF3 é denominada de MSFCONSOLE, que por sua vez possui uma aplicação chamada BAILIWICKED_HOST, a qual foi utilizada para realização do ataque de envenenamento do cache do DNS. Tal ferramenta pode ser encontrada no diretório /opt/metasplosploit/msf3/ utilizando o aplicativo MSFCONSOLE e em seguida iniciar o

BAILIWICKED_HOST.

O ataque de envenenamento do cache do DNS, também chamado de DNS Spoofing, pode ocorrer no seguinte cenário: uma rede que possua um servidor DNS recursivo, onde o atacante realizará uma inundação de perguntas, também denominada de flooding, de nomes de domínio ao servidor e simultaneamente as responderá com um endereço IP diferente do verdadeiro do endereço do domínio consultado.

Cada uma destas consultas possui um código de identificação, a Query ID, que é gerada aleatoriamente pelo servidor DNS recursivo e a cada nova consulta é incrementado “1” no valor da Query ID. Como o atacante não possui esta informação, se fez necessária uma inundação de tráfego de consultas para que em dado momento, a Query ID coincida com o número gerado pelo servidor DNS recursivo, e desta feita, o ataque logrou êxito, conforme ilustrado na Figura de número 19.

No passo 1, o cliente DNS direcionou uma pergunta ao servidor DNS recursivo; Qual o endereço para test.atacante.com? No passo 2, o servidor DNS realiza uma consulta ao servidor raiz que não possui o registro solicitado e no passo 3 indica qual o servidor DNS que possui a informação solicitada. No passo 4, o servidor DNS recursivo realiza uma consulta ao servidor presente na rede do atacante, onde o metaspoit analisa a consulta DNS e identifica o

Query ID e porta utilizada na consulta.

(47)

O metasploit também pode alterar a porta de consulta, que por padrão é a 53 e realizar a inundação em portas aleatórias, alterando o cabeçalho da consulta DNS.

3.2. Análise Prática

Para a execução do ataque, foi necessária a criação de um ambiente de laboratório que está detalhado no Quadro 10. Este ambiente foi virtualizado através do software VirtualBox na versão 4.3.10 r93012.

(48)

3.3. Realização do Ataque ao DNS

O procedimento realizado consistiu na utilização de três máquinas virtuais atacantes para executar o flooding com a ferramenta BAILIWICKED_HOST, a fim de obter o resultado esperado, ou seja, envenenar efetivamente o cache do servidor DNS recursivo com um endereço IP injetado pelos atacantes e não receber o endereço real do domínio consultado. O modelo de conFiguração utilizado para o ataque proposto é exibido no Quadro 15.

Como visto no Quadro 11, os domínios .jus.br têm obrigatoriedade de implementação do DNSSEC, por isso o domínio escolhido foi o www.tjpe.jus.br, conforme disposto no Quadro 12.

(49)

Pessoas Jurídicas - DNSSEC OBRIGATÓRIO

B.BR Bancos

JUS.BR Instituições do Poder Judiciário

LEG.BR Instituições do Poder Legislativo

MP.BR Instituições do Ministério Público

Quadro 12: Parâmetros do Ataque

Nome ConFiguração Atual Requerida Descrição HOSTNAME www.tjpe.jus.br sim Hostname a ser atacado

INTERFAC E

não O nome da interface. Exemplo: eth2

NEWADDR 192.168.0.110 sim Novo endereço para o hostname.

RECONS 8.8.8.8 sim Servidor de Domínio utilizado para reconhecimento.

RHOST 192.168.1.100 sim Endereço do Servidor alvo.

SNAPLEN 65535 sim Número de bytes a serem capturados

SRCADDR Real sim Endereço de origem para envio de queries (Aceitos: Real, Aleatório)

SRCPORT 53 sim Porta alvo do servidor para consultas.

TIMEOUT 500 sim Tempo de espera em segundos para aguardar novas informações.

TTL 48766 sim TTL para a entrada envenenada de host

XIDS 0 sim Número de XIDs para tentativa de cada query (0 for automatic)

O Metasploit realiza o envio de várias consultas DNS para o domínio alvo direcionadas ao servidor DNS recursivo, forçando-o a realizar estas consultas aos servidores DNS autoritativos, prática realizada no intuito de ganhar tempo enquanto, simultaneamente, o

Metasploit realiza a injeção de entradas envenenadas de registro no DNS recursivo com o

endereço IP alterado, conforme demostrado na Figura 20. Figura 20: Tática do Metasploit

(50)

Para que esta injeção de respostas possa ser recebida e validada pelo servidor, o número da QID tem que coincidir com o da requisição outrora solicitada. O servidor DNS recursivo realiza as consultas e a cada nova consulta incrementa “1” na contagem do QID tornando possível a descoberta do valor e a antecipação da resposta como exibido na Figura 20.

No passo 1, o cliente DNS direcionou uma pergunta ao servidor DNS recursivo; qual o endereço para www.manguetown.org? No passo 2b, o servidor DNS recursivo realiza uma consulta ao servidor raiz que não possui o registro solicitado. Simultaneamente, no passo 2a, o atacante realiza uma inundação de respostas para o servidor, injetando um endereço IP forjado para o domínio consultado. No passo 3, o servidor raiz indica qual o servidor DNS que possui a informação solicitada no passo 2b. No passo 4, o DNS realiza uma consulta ao servidor presente na zona .org que conhece o host www.manguetown.org, e responde a consulta para o servidor DNS recursivo, contudo, a resposta já foi respondida pelo atacante e a entrada foi inserida no cache.

A ferramenta BAILIWICKED_HOST faz uma requisição com o endereço alvo do ataque e responde simultaneamente com o QID definido pela ferramenta e com o

(51)

apontamento para o endereço diferente do endereço original. A definição do padrão de aleatoriedade, forçando a realização de mais de uma tentativa no processo de ataque para obter sucesso. Com a utilização de três máquinas, as chances de sucesso no ataque foram aumentadas. Foram realizadas “8” tentativas conjuntas para obter êxito. Uma nova sequencia de ataque foi feita um dia após e foi obtido êxito no ataque com “11” tentativas.

No quadro 13, em destaque, pode-se observar a injeção de 27 respostas envenenadas para cada servidor de nomes com o registro envenenado para www.tjpe.jus.br no servidor de endereço IP 192.168.0.100 na porta 53. Após 250 perguntas e 26000 respostas o registro foi envenenado no servidor alvo do ataque.

Quadro 13: O Ataque

Na Figura 21 é exibido o detalhamento da interface de rede do cliente DNS, o

resolver, de um computador utilizando o sistema operacional Windows 7®_{, cujo servidor DNS} está definido para o endereço IP 192.168.0.100, o servidor DNS utilizado em laboratório.

Figura 21: Interface de Rede com DNS msf auxiliary(bailiwicked_host) > run

[*] Targeting nameserver 192.168.0.100 for injection of www.tjpe.jus.br. as 192.168.0.110

[*] Querying recon nameserver for tjpe.jus.br.'s nameservers...

[*] Got an NS record: tjpe.jus.br. 21599 IN NS dns2.tjpe.jus.br.

[*] Querying recon nameserver for address of dns2.tjpe.jus.br.... [*] Got an A record: dns2.tjpe.jus.br. 21599 IN A 200.238.65.4

...

[*] Sending 27 spoofed replies from each nameserver (2) for each query [*] Attempting to inject a poison record for www.tjpe.jus.br. into 192.168.0.100:53...

[*] Calculating the number of spoofed replies to send per query... [*] race calc: 100 queries | min/max/avg time: 0.15/0.2/0.16 | min/max/avg replies: 43/115/71

...

[*] Poisoning successful after 250 queries and 26000 responses: www.tjpe.jus.br == 192.168.0.110

[*] TTL: 230 DATA: #<Resolv::DNS::Resource::IN::A:0xb59fbef0> [*] Auxiliary module execution completed

(52)

Após o envenenamento do cache do servidor, todas as consultas para o domínio alvo foram redirecionadas para o endereço estabelecido pelo atacante, e quando realizado um acesso, obteve-se como resposta o endereço adulterado injetado no cache do servidor DNS recursivo pelo atacante.

O Packet InterNet Grouper ou, simplesmente, ping, é um utilitário capaz de medir, em milissegundos, o tempo de resposta de um host a outro. O ping recebeu este nome devido ao som produzido por um sonar e por operar de maneira semelhante a ele, conforme descrito pelo seu criador, Muuss (1983). O ping utiliza o protocolo ICMP, protocolo de mensagens de controle, com as mensagens de ECHO REQUEST e ECHO REPLY, requisição de eco e resposta de eco, respectivamente.

A sintaxe de uso do aplicativo ping possui algumas variáveis, e o teste pode ser realizado pela consulta a um endereço IP ou a um nome de domínio. Quando realizada uma consulta a um nome de domínio, a resposta será dada com o endereço IP do host, em conformidade com a Figura 22, onde o teste foi para o domínio www.tjpe.jus.br, antes da realização do ataque, obteve-se como resposta o endereço IP 200.238.65.7, o endereço real do domínio.

(53)

Figura 22: Ping para www.tjpe.jus.br

Após o sucesso no ataque ao servidor DNS recursivo, o cliente DNS realizou o teste de ping para www.tjpe.jus.br e obtém como resposta o endereço injetado pelo atacante conforme evidenciado na Figura 23.

Figura 23: Ping www.tjpe.jus.br comprometido

Demonstra-se o sucesso do ataque através de acesso via navegador web na Figura 24.

(54)

O Domain Information Groper, ou DIG, é uma ferramenta que exibe informações sobre os registros de DNS de um domínio, host ou IP solicitado, além de informar o servidor DNS recursivo que indicou aquele mapeamento. Como exibido no Quadro 14, que exibe, como exemplo, o resultado do comando DIG para o domínio www.tjpe.jus.br antes do ataque, e posteriormente, no Quadro 14, a mesma requisição de informações de domínio após o envenenamento do cache do servidor DNS recursivo, onde o endereço IP injetado pelo atacante, 192.168.0.110, é exibido.

Quadro 14: DIG www.tjpe.jus.br

53

root@DNS:~# dig @localhost www.tjpe.jus.br

; <<>> DiG 9.7.3 <<>> @localhost www.tjpe.jus.br ; (1 server found)

;; global options: +cmd ;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19344

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION:

;www.tjpe.jus.br. IN A ;; ANSWER SECTION:

www.tjpe.jus.br. 86392 IN A 200.238.65.7

(55)

No Quadro 15, através da consulta DIG pode-se visualizar o endereço IP injetado. Quadro 15: DIG www.tjpe.jus.br comprometido

3.4. Implementação do DNSSEC

No intento de sanar a vulnerabilidade do DNS exposta neste trabalho, foi implementado o DNSSEC em um servidor DNS recursivo a fim de validar as consultas oriundas dos clientes DNS, confirmando a veracidade das repostas recebidas pelos servidores de DNS autoritativos.

A topologia utilizada neste laboratório é exibida na Figura 25, onde observa-se uma estação cliente DNS sendo representado por um host com sistema operacional Windows 7® que consultou o domínio www.tjpe.jus.br através de um servidor DNS utilizando o sistema

root@DNS:~# dig @localhost www.tjpe.jus.br

; <<>> DiG 9.7.3 <<>> @localhost www.tjpe.jus.br ; (1 server found)

;; global options: +cmd ;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20535

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.tjpe.jus.br. IN A ;; ANSWER SECTION: www.tjpe.jus.br. 3277 IN A 192.168.0.110 ;; AUTHORITY SECTION: tjpe.jus.br. 85043 IN NS dns1.tjpe.jus.br. tjpe.jus.br. 85043 IN NS dns2.tjpe.jus.br. ;; Query time: 0 msec

;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Apr 10 17:47:13 2014 ;; MSG SIZE rcvd: 87

(56)

operacional Debian 7 e com as extensões de segurança do DNSSEC e também visualiza-se o atacante que está utilizando o sistema operacional BackTrack 5 R3.

Figura 25: Topologia do Laboratório

Em linhas gerais, para que as resolução de nomes de domínios que utilizam DNSSEC sejam realizadas é necessário conFigurar no servidor DNSSEC recursivo a chave pública dos servidores raiz “.” que foi disponibilizada em 15 de julho de 2010.

Na Figura 26 é exibida a cadeia de confiança do domínio zone.dnssec.cz. até sua raiz. Figura 26: Ilhas de Confiança

(57)

Fonte: Adaptado de http://www.pop-ba.rnp.br/pub/Cert/DNSSEC_DocDetalhada/dnssec_ds_scheme.png, (2014)

Segundo Lucas (2013), nem todos os domínios possuem o DNSSEC assinado desde sua raiz. Na Figura 27 é exibido um exemplo em que a zona nlnetlabs.nl utiliza DNSSEC, mas a raiz, nl., não possui o DNSSEC implementado, nem existe uma âncora de confiança na raiz, e por isso é necessário o uso de um recurso chamado de Domain Lookaside Validation

Registry, ou DLV.

Figura 27: Exemplo de Domínio Sem DNNSEC