AMBIENTE DE MONITORAÇÃO E ESTUDO DAS
VULNERABILIDADES DO SERVIÇO DE NOMES DE
DOMÍNIO
Rafael S. Reis1, Leonardo S. S. Thomaz1, Edna Dias Canedo2, Laerte Peotta1,
Rafael Timóteo de Sousa Júnior1
1
2
Departamento de Engenharia Elétrica – Universidade de Brasília (UnB)
Brasília – DF – Brasil
Faculdade UnB Gama – Universidade de Brasília (UnB) - Caixa Postal 8114 – 72.405610 - Gama – DF – Brasil
[email protected], [email protected], [email protected],
[email protected], [email protected]
Abstract. The domain name system (DNS) is one of the main pillars of the
Internet. Successful attacks to servers responsible for this service can generate
large losses for providers and consumers of Internet services. In this context,
given the DNS protocol vulnerabilities, it is crucial that this protocol be
replaced by DNSSEC. This article describes an environment for studying the
vulnerabilities of the domain name service, including the comparison between
DNS and DNSSEC, and running scans to assess the migration from DNS to
DNSSEC (especially in Brazil), as well as to monitor exploits to known
vulnerabilities in this context. Using such an environment, experiments results
are presented in order to give evidence of its interest as well as a picture of
the situation of this critical system in Brazil.
Resumo. O sistema de nome de domínio (DNS) é um dos principais pilares da
Internet. Ataques bem-sucedidos a servidores responsáveis por este serviço
podem gerar grandes prejuízos para provedores e usuários finais de serviços
da Internet. Nesse contexto, dadas as vulnerabilidades do protocolo DNS, é
crucial que tal protocolo seja substituído pelo DNSSEC. Este artigo descreve
um ambiente de estudo das vulnerabilidades do serviço de nomes de domínio,
incluindo a comparação entre DNS e DNSSEC, a execução de varreduras
para avaliar o estado da migração do DNS para o DNSSEC (especificamente
no Brasil), bem como para monitorar a exploração de vulnerabilidades
conhecidas nesse contexto. Resultados de experimentos realizados com tal
ambiente são apresentados de modo a dar evidências de seu interesse, bem
como um retrato da situação desse sistema crítico no Brasil.
1. Introdução
O Sistema de Nomes de Domínios traduz nomes de domínio em endereços IP,
permitindo que aplicações e usuários tenham acesso aos diversos serviços da Internet,
como sistemas de comércio eletrônico, navegação de sites e envio de e-mails, sem
precisar indicar o endereço IP, mas apenas o mnemônico para o serviço desejado
[Barbosa, Souto, Feitosa e Martins 2014].
Tal sistema se apoia em uma base de dados hierárquica e distribuída entre os
nodos participantes, podendo cada um dos nodos usar uma memória cache para
armazenar as consultas mais comuns, o que permite agilizar o processo realizado, além
de inibir uma sobrecarga aos servidores envolvidos [Albitz, Liu 2005]. Na versão
clássica do sistema, as comunicações entre tais nodos eram providas pelo protocolo
DNS, que, apesar de ter dado provas de um bom funcionamento, possui importantes
vulnerabilidades de segurança.
Em função dessas vulnerabilidades, são amplamente conhecidos, por exemplo,
os ataques de envenenamento de cache (cache poisoning) e de amplificação DNS, que
podem ser realizados contra esse sistema:


O envenenamento de cache consiste em um atacante responder a uma consulta
DNS com uma resposta maliciosa antes de o resultado verdadeiro chegar. Assim
essa informação maliciosa fica armazenada na memória cache de servidores que
estejam armazenando tal consulta. Todos os usuários que realizarem essa mesma
consulta e receberem resposta de um desses servidores DNS com cache serão
direcionados para um destino malicioso;
A amplificação DNS se baseia no fato de que a resposta é muito maior que a
consulta DNS. Assim, o atacante varre a Internet à procura de servidores DNS e
faz requisições a todos os servidores encontrados. O usuário malicioso modifica
o endereço IP de origem da consulta, substituindo-o pelo IP da vítima do ataque,
de modo que as respostas são direcionadas a esse alvo, sobrecarregando-o.
Em função disso, surgiu a necessidade de criar o DNS Security Extensions
(DNSSEC) [Iwasa & Hilário 2011], que busca eliminar grande parte das falhas de
segurança do sistema DNS, provendo autenticidade e integridade às mensagens, através
de algoritmos de criptografia assimétrica, funções de hash e técnicas eficientes de
gerência de chaves. Vale notar que, apesar de ser a principal ferramenta de segurança
para sistemas DNS, este protocolo não garante proteção contra ataques de negação de
serviços [Krishnaswamy 2009].
O sistema DNS é uma das bases mais importantes da infraestrutura da Internet,
sendo considerado crítico para o bom funcionamento dessa rede [Hoepers 2013]. A
tendência é que este serviço seja cada vez mais utilizado, aumentando ainda mais a sua
importância. Por essa razão, é necessário garantir que o DNSSEC seja implementado
em todos os servidores DNS.
É importante monitorar a migração para o DNSSEC e dar continuidade à análise
de vulnerabilidades nesse contexto, especialmente no Brasil. Dada essa motivação, o
presente artigo busca contribuir com a definição de um ambiente de monitoração e
estudo de vulnerabilidades do sistema de nomes de domínio, o que tem como resultado
outra contribuição também no que se refere a monitorar a migração para o DNSSEC,
em especial dando um retrato da situação brasileira quanto a esse sistema crítico.
Este artigo é então organizado, no seu restante, com uma seção 2, que trata da
metodologia adotada, seguida da descrição do ambiente de monitoração e estudos do
sistema DNS na seção 3. Na seção 4, descrevem-se os experimentos demonstrativos das
funcionalidades desse ambiente no que se refere ao estudo de vulnerabilidades do
sistema DNS, apresentando ainda um apanhado da monitoração dos serviços no Brasil.
Finaliza-se com uma seção de conclusões.
2. Metodologia
A metodologia proposta consiste primeiro na concepção e implantação de um ambiente
para monitorar e estudar os serviços do DNS.
Concomitantemente, foram projetados e realizados experimentos para validar o
ambiente, comparando a situação com proteção do DNSSEC em relação à situação com
o protocolo DNS clássico. Tais experimentos são relacionados a ataques de
envenenamento de cache, e incluem uma varredura de serviços DNS que permite obter
um panorama brasileiro de servidores DNS. Para tanto, são os seguintes os
experimentos desenvolvidos:


O primeiro experimento contempla uma atividade de estudo da eficiência do
DNSSEC contra fraudes e envenenamento de cache, evidenciando, de maneira
didática, o tipo de proteção fornecido com o uso das medidas de segurança desse
protocolo. Nesse sentido, foram construídos dois ambientes virtualizados; um
deles com o DNS comum e outro com a utilização do DNSSEC para o servidor
em modo recursivo de operação;
O segundo experimento consiste de atividade relacionada às estatísticas de uso
do DNS e DNSSEC no Brasil, e também inclui uma proposta de monitoramento
de incidentes de envenenamento do cache.
3. Ferramentas Utilizadas
Os cenários experimentais são realizados por intermédio de máquinas virtuais. O
sistema operacional usado em todas as máquinas virtuais foi o Ubuntu 12.04 LTS com o
BIND9 como software para o serviço de DNS.
Para os procedimentos experimentais, foram exploradas as ferramentas,
WireShark, para captura e análise de pacotes, NMAP, para efetuar a varredura de rede,
DIG, para verificação de recursividade e uso de DNSSEC, e Virtual Box, para criação
dos cenários em máquinas virtuais1.
O Wireshark é uma ferramenta muito disseminada para captura e análise de
pacotes em redes TCP/IP.
O NMAP é uma ferramenta clássica para varreduras de redes TCP/IP. Com esta
ferramenta, é possível especificar diversos parâmetros para otimizar e personalizar a
varredura (“scanning”) de modo a obter os resultados esperados. Dentre estes
parâmetros, se pode determinar o protocolo utilizado da camada de transporte, portas de
destino, listas de endereços IP, velocidade, tamanho do pacote, tempo limite de
resposta, etc.
O DIG é um cliente de DNS nativo de sistemas UNIX de derivação Debian,
muito útil em depurações de resoluções de nomes. Ele permite fazer uma consulta
especificando cada campo ou tipo de entrada, como MX (Mail Exchange), AA
(Endereço IPv6) ou NS (Name Server), com a opção de uso ou não de cache.
1
Instruções sobre as ferramentas DIG e NMAP podem ser encontradas no
https://www.nanog.org/meetings/nanog52/presentations/Sunday/Sinatra-DNS-DNSSEC_tutorialreallyfinal.pdf
site:
Os cenários dos experimentos foram criados utilizando o Virtual Box, um
produto gratuito da Oracle que permite oferecer os recursos físicos de um computador –
disco, memórias e interfaces de entrada e saída – para uma máquina virtual. Assim, é
preciso apenas um dispositivo físico para criar uma topologia virtual que integra
diferentes sistemas operacionais.
4. Descrição de Experimentos com Serviços do DNS
O primeiro experimento é realizado em dois cenários que permitem comparar DNS com
a extensão DNSSEC. Com os dois cenários, mostra-se que uma resposta DNS pode ser
facilmente fraudada e que com recurso do DNSSEC é possível garantir a integridade e
confiabilidade da consulta.
O segundo experimento consiste de uma varredura de baixa velocidade que concerne
tanto aos serviços pelo DNS, quanto pelo DNSSEC.
4.1. Experimento 1 – Cenário 1 – DNS Vulnerável
O cenário é composto por três dispositivos clientes (Usuários), um servidor DNS
operando no modo recursivo e um servidor DNS configurado para funcionar como
autoritativo do domínio alvo, sendo que todos estes componentes contam com acesso
total à Internet (Figura 1).
Figura 1. Cenário 1 – Atividade com o DNS Vulnerável
Nos experimentos realizados, foi usado o domínio "UNB.BR" pelo fato de o
mesmo fazer uso do DNSSEC, mas este teste pode ser repetido para qualquer domínio
com DNSSEC habilitado.
Neste cenário simulado, um dos clientes faz uma requisição do nome
"www.unb.br" para o Servidor Recursivo. O servidor do "BR." delega o domínio
"UNB.BR." apontando as consultas do tipo "NS” para o(s) IP(s) do(s) servidor(es) que
contêm a zona deste domínio. O ataque vem logo depois desta etapa. No momento em
que o Recursivo (sem DNSSEC) faz a consulta ao IP que recebeu como resposta do
“.BR”, o atacante intercepta a mensagem e dá uma falsa resposta, atribuindo o IP que
lhe convém ao nome "www.unb.br". Feito isto, o cache do Recursivo fica contaminado
com essa entrada falsa e consequentemente todos os clientes que usarem essa entrada
também terão a mesma resposta.
Para melhor evidenciar o ataque, foram feitas capturas de pacotes no modo
PCAP, que podem ser visualizadas graficamente pelo software WIRESHARK (Figura
2), e também capturas das telas dos clientes e evidências pelo NSLOOKUP (Figura 3).
Figura 2. Cenário 1 – Captura com o Wireshark
Figura 3. Cenário 1 – Saída do NSLOOKUP
Na Figura 4, é possível observar a resposta falsa enviada pelo dispositivo
malicioso, ou seja, aquele acessado através do endereço IP gerado pelo atacante e vetor
da contaminação do cache. Neste caso, a fraude consiste em redirecionar o cliente para
o IP 192.168.10.10, mas este poderia ser qualquer outro de interesse do atacante.
Especificamente, a Figura 4 apresenta a página www que é mostrada quando o cliente
acessa a falsa URL www.unb.br. No experimento, tal página foi configurada em um
servidor WEB apache2, instalado em um UBUNTU 12.04 - LTS, apenas para fim de
ilustração completa de um ataque de envenenamento de cache DNS.
Figura 4. Cenário 1 – Página Falsa Acessada
4.2. Experimento 1 – Cenário 2 – DNSSEC
Este cenário tem a mesma estrutura do Cenário 1, sendo feita apenas uma alteração no
Servidor Recursivo, no qual a validação de DNSSEC é habilitada (Figura 5).
Para habilitar o DNSSEC em um servidor Recursivo BIND9, deve-se editar o
arquivo de configuração em "/etc/bind/named.conf" e retirar o comentário da linha
"dnssec - validation auto" conforme apresentado na Figura 6.
Figura 5. Cenário 2 – Atividade com o DNSSEC
Figura 6. Cenário 2 – Habilitação DNSSEC
No cenário, repetem-se as mesmas consultas ao domínio "UNB.BR", efetuandose o mesmo tipo de tentativa de fraude. O resultado é que durante o ataque não há
nenhuma resposta fraudada, pois a integridade e a autenticidade foram garantidas pelo
DNSSEC.
Também são capturados os pacotes no formato PCAP e telas dos clientes para
validar o procedimento, mas, como o Bind9 registra os eventos de consultas DNS na
pasta /var/log/syslog, pode-se examinar este arquivo para confirmar a recusa da resposta
pela verificação de chaves: (Figura 7). Observa-se que, na primeira tentativa de acesso à
URL www.unb.br, obtém-se a resposta de que não foi possível resolver o nome em
questão. Já no segundo acesso, obtém-se o endereço correto. Isso é explicado pelo fato
de que a primeira resposta obtida não contém a chave fornecida pelo domínio pai, no
caso o ".BR". Assim, a resposta foi descartada pelo servidor recursivo.
Figura 7. Cenário 2 – Registros Syslog
No destaque da Figura 7, verifica-se que a resposta foi recusada, pois o domínio
"Parent" informou que o domínio "UNB.BR" possui DNSSEC, entretanto não recebeu
uma resposta segura, devendo assim ser descartada. Com estes resultados, mostra-se a
eficiência da extensão DNSSEC de segurança ao DNS, provendo integridade e
autenticidade ao protocolo.
4.3. Experimento 2 – Varreduras e Monitoração do Sistema DNS
A segunda atividade proposta está relacionada às estatísticas de uso do DNS e DNSSEC
no Brasil, e também inclui uma proposta de monitoramento de incidentes de
envenenamento do cache.
Neste experimento, além da configuração comum do Experimento 1, NMAP e
DIG, foi utilizada a ferramenta Notepad++, todas instaladas em um S.O. UBUNTU 12.4
LTS 64bits, processador Intel-I7 com 8 GBs de memória.
Ao fim deste experimento, é possível ter uma visão geral de como se encontra a
migração de DNS para DNSSEC no Brasil atualmente. Para isto, foi feita uma varredura
em todos os blocos de endereços IPs reservados ao Brasil, no período do dia primeiro de
abril até o dia 28 de maio de 2014. A varredura foi feita de maneira distribuída, ou seja,
a partir de diversas origens, para evitar problemas de bloqueios por firewalls das
operadoras.
Para obter os dados de interesse, a varredura foi feita de maneira gradual.
Primeiramente, foi levantada a quantidade de servidores DNS públicos com a porta 53
aberta. Nesta lista foram diferenciados servidores autoritativos e/ou recursivos. Das
duas listas resultantes, foram retiradas informações de uso de DNSSEC, sistema
operacional, software DNS e versão do software.
Para as varreduras, o NMAP foi configurado com os seguintes parâmetros:
"nmap -Pn -n -T5 -p T:53 --open -iL Lista_de_IPs > Resultado", onde “-Pn" é para não
executar o icmp request, "-n" para não fazer consulta reversa de DNS, "-T5" define a
velocidade, “-p T:53" especifica a porta e o protocolo a ser inspecionado, e "--open"
filtra a saída para mostrar apenas os abertos.
O programa "DIG" foi usado para verificar a recursividade e também para
checar o uso de DNSSEC.
Todos estes dados foram tratados e organizados para maior entendimento e
geraram os seguintes resultados:
a. Na primeira fase foram identificados cerca de 45 mil servidores respondendo a
requisições na porta 53/TCP-UDP. Observa-se que isso não significa que todos
estes servidores estejam com serviço de DNS ativado, simplesmente respondem
na porta 53.
b. Da lista acima, aproximadamente 7.500 são servidores recursivos.
c. Dentre os servidores recursivos abertos, 836 estão aptos a responder requisições
com a validação de DNSSEC. Esta fração representa aproximadamente 13% do
total.
O resultado do Item 'a' é puramente estatístico se analisado isoladamente, pois
este valor representa a soma de diferentes tipos de serviço como DNS recursivo,
autoritativo, Relay e diversos serviços com porta não padronizada. Deve-se ressaltar
também que a maioria dos servidores DNS recursivos de redes locais não são públicos,
obviamente por motivos de segurança e de desempenho.
No item 'b' pode-se registrar uma quantia razoável de servidores recursivos
abertos publicamente. Há indícios de que a grande maioria destes seja publicada
indevidamente e sem intenção definida, pois verifica-se que a maioria destes são
roteadores e equipamentos mal configurados. Estes servidores, como são abertos para
toda a Internet, podem contribuir para a insegurança na rede, sendo facilmente usados
em um ataque DNS amplificado.
O resultado 'c' mostra que a utilização de DNSSEC no Brasil ainda é baixa,
porém vale considerar também que a maioria destes servidores parecem não ser
administrados, já que em uma primeira análise muitos nem deveriam encontrar-se
abertos para a Internet. Logo, para tais casos, tendo sido fechadas as portas
desnecessariamente abertas, a implementação do DNSSEC seria um segundo
incremento de segurança.
Além de tais resultados do experimento, verifica-se outra possibilidade de uso
do ambiente apresentado neste artigo. De fato, como continuidade da atividade, foi
proposto um "script" de monitoramento de incidentes de envenenamento de cache. O
objetivo é detectar em tempo real a ocorrência de entrada fraudulenta em cache de
algum servidor recursivo vulnerável.
Para facilitar a detecção, são filtrados os servidores recursivos com a finalidade
de gerar uma lista apenas com os mais vulneráveis. Por exemplo, foi elaborada uma lista
de 20 prováveis alvos deste tipo incidente, dentre eles: bancos, seguradoras, governo, e
demais sites que exigem autenticação para movimentação financeira.
O fluxograma da figura 8 representa o funcionamento da rotina de
monitoramento que faz a resolução de cada nome da lista de alvos em todos os
servidores vulneráveis e compara com uma base obtida anteriormente de maneira
confiável. Sempre que existir uma entrada diferente da base, esta resposta é escrita em
um arquivo de endereços IP suspeitos, para uma posterior verificação manual e
individual. Este Script de monitoramento detecta a ocorrência de envenenamento de
cache, entretanto não corrigem os erros encontrados.
Figura 8. Experimento 2 – Rotina de monitoração de envenenamentos de cache
Para efeito de validação, esta rotina foi executada continuamente durante 28
dias. A primeira entrada suspeita foi escrita após 14 dias de monitoramento. Ao final
deste período, o arquivo de entradas suspeitas continha apenas 2 entradas, referentes ao
mesmo domínio. O IP da resposta encontrada foi pesquisado em algumas listas de
reputação, mas nenhuma informação foi encontrada.
Os resultados deste último experimento mostram que a rotina funciona, porém
não obteve o sucesso esperado. Talvez deva ser melhorada no que se refere à escolha
dos alvos, quantidade de servidores consultados e duração.
3. Conclusão
O DNS é um sistema que tornou mais amigável e gerenciável o acesso aos diversos
serviços da Internet, já que é inviável a memorização de endereços IP. Assim, seu
funcionamento tornou-se vital para a Internet e para todas as redes locais.
Entretanto, o DNS está vulnerável a diversos ataques e incidentes de segurança.
Portanto, é essencial incrementar segurança neste sistema. Existem muitas medidas que
podem ser tomadas para deixar este serviço mais seguro. Além da medida que consiste
em manter o software de DNS sempre atualizado, a adoção de DNSSEC parece ser a
melhor maneira de prover segurança para a resolução de nomes.
Por todos os benefícios de segurança que o DNSSEC fornece, é importante o
estudo de sua implementação, principalmente em um ambiente de alta criticidade, onde
a integridade e autenticidades das informações são requisitos importantes.
Neste trabalho, por meio da primeira atividade experimental, é possível mostrar
a efetividade do DNSSEC na proteção das transações de resolução de nomes.
Evidencia-se também o quão simples é a sua implementação em servidores recursivos, o
que pode encorajar mais administradores a aderirem a esta extensão segura, já que o
sucesso do DNSSEC está diretamente associado à sua disseminação. Neste experimento
indica-se ainda que, apesar da segurança contra alguns ataques, o DNSSEC não pode
contrabalançar ataques distribuídos de negação de serviço, cujo efeito inclusive pode ser
amplificado no DNSSEC, já que este traz consigo uma carga de dados um pouco maior
que o DNS em cada requisição.
O segundo experimento indica que, no cenário brasileiro geral, as estatísticas
não são muito boas em relação ao sistema DNS como todo, não só pelo fato de existir
apenas 13,5 % de uso de DNSSEC nos recursivos, mas pela quantidade de servidores
abertos para a Internet, desnecessariamente e com softwares desatualizados.
Dado este cenário, pode-se sugerir algumas políticas de segurança a nível
nacional para melhorar estes aspectos. A principal delas seria a obrigatoriedade de uso
do DNSSEC para um número maior de domínios, assim como já se estabeleceu para os
domínios de bancos e “.jus”. Como foram detectados servidores de DNS abertos
desnecessariamente, seria importante algum esforço nacional no sentido de filtrar
corretamente a porta 53 na Internet, já que hospedar um serviço de DNS é dispensável
para a grande maioria dos clientes de Internet, que muitas vezes possuem
inconscientemente um servidor disponível.
A administração do DNSSEC em servidores autoritativos pode trazer alguma
complexidade, e isso talvez explique por que é tão pouco utilizado. Já no caso dos
servidores recursivos, não há nenhuma dificuldade em sua implementação e
manutenção. Em um trabalho futuro, poderia ser considerada a configuração de um
servidor DNS em modelos de um "honeypot". Desta maneira, poderia ser alimentada
uma base de endereços IP maliciosos, e poderiam ser estudadas novas vulnerabilidades
que envolvem o DNS.
Referências
BARBOSA, K. R. S.; SOUTO, E; FEITOSA, E.; MARTINS, G. B. (2014).
Identificação e Caracterização de Comportamentos Suspeitos Através da Análise do
Tráfego DNS. XIV Simpósio Brasileiro em Segurança da Informação e de Sistemas
Computacionais – SBSeg 2014.
HOEPERS, C. (2013). Gestão de Incidentes e Resiliência das Infraestruturas Críticas de
Internet. Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no
Brasil. Núcleo de Informação e Coordenação do Ponto BR. Comitê Gestor da
Internet no Brasil.
ALBITZ, P.; LIU, C. (2006). DNS and BIND. 5th Edition. O’Reilly Media.
IWASA, A. M. DE A.; HILÁRIO, P. S. (2011). Análise de Segurança em DNS e Propostas
do Mecanismo de Defesa do DNSSEC. Trabalho de Graduação em Engenharia de
Redes de Comunicação, Faculdade de Tecnologia, Universidade de Brasília, Brasília,
DF.
KRISHNASWAMY, S., HARDAKER, W., & MUNDY, R. (2009). DNSSEC in
Practice: Using DNSSEC-Tools to Deploy DNSSEC. Conference for Homeland
Security, 2009. CATCH '09. Cybersecurity Applications & Technology.