CEP , Manaus-AM, Brasil

Transcrição

1 MyDnsDump: Uma ferramenta para medição do tráfego DNS Diógenes Luis B. de Freitas 1, Kaio R. S. Barbosa 1, Eduardo Feitosa 1 1 Instituto de Computação - Universidade Federal do Amazonas (UFAM) Av. Rodrigo Otávio Jordão Ramos, 3000, Coroado. CEP , Manaus-AM, Brasil dextop123@gmail.com, {kaiorafael,efeitosa}@icomp.ufam.edu.br Abstract. This paper presents a proposed architecture for monitoring DNS traffic based on libtrace network library. To illustrate the performance enhancement, a prototype was developed as a proof of concept, MyDnsDump. Results from real traffic dataset show that, even though been a recent library, libtrace has superior performance compared to libpcap. Furthermore, this work extends the library adding support for link layer type loop, not yet supported in the current version Resumo. Este artigo apresenta uma proposta de arquitetura para monitoramento de tráfego DNS baseado na biblioteca de rede libtrace. Para ilustrar o ganho de desempenho, um protótipo foi desenvolvido como prova de conceito, MyDnsDump. Os resultados a partir de base real de tráfego mostram que, apesar de ser uma biblioteca recente, a libtrace tem comportamento superior em relação a libpcap. Além disso, este trabalho estende a biblioteca com suporte a camada de enlace do tipo loop, ainda não suportado na versão atual Introdução O DNS (Domain Name System) [Mockapetris 1987b] é um banco de dados hierarquicamente distribuído, responsável por um serviço fundamental para aplicações e comunicação na Internet, a tradução de nomes de domínios e endereços IPs. Por ser um serviço global, o DNS foi projetado para ser escalável e oferecer bom desempenho sob altas cargas. Contudo, ao longo dos anos, iniciativas como [Castro et al. 2008, Barbosa e Souto 2009, Zdrnja et al. 2007], através do monitoramento do tráfego e da utilização dos recursos dos servidores DNS de primeiro nível, vem encontrando e identificando diferentes tipos de tráfego anômalo no DNS, incluindo vírus e malware. Atualmente, a maioria dos serviços da Internet é baseada em um modelo de funcionamento onde uma consulta ao sistema de resolução de nomes é realizada antes de qualquer atividade de comunicação. As mensagens DNS oferecem informações que identificam comportamentos típicos, como solicitações empregando classe padrão de consultas e registros de recursos bem definidos. Nesse contexto, técnicas de medição e análise de informações de tráfego permitem inferir e melhor compreender as particularidades do comportamento da rede. Entretanto, investigações do tráfego DNS também detectam comportamentos não desejados ou anômalos, isto é, tráfego que não deveria estar presente nas consultas ou respostas do DNS. Este trabalho apresenta uma ferramenta para medição e análise passiva do tráfego DNS usando a biblioteca libtrace [Alcock et al. 2012]. A principal contribuição deste Manaus, 25 a 27 de abril de ISSN (CDR)

2 trabalho é estender o funcionamento da libtrace, adicionando tratamento ao tipo de dado loop, o qual ainda não é suportado pela versão atual, Além disso, a motivação para o emprego da análise passiva do DNS é detectar e correlacionar os domínios usados para produzir spam, vírus, worms e varredura de rede. Como prova de conceito e validação, este trabalho utiliza o tráfego de rede real do projeto DITL 2008 [Neves et al. 2008] para análise de dados. 2. Fundamentação Teórica O sistema de nomes de domínio, ou DNS, foi proposto para solucionar problemas de tradução de nomes. O DNS é um banco de dados distribuído, representado como uma árvore, usado para traduzir nomes de máquinas para os seus respectivos endereços IP [Mockapetris 1987b]. O termo distribuído é aplicado na definição, pois nenhum nome de domínio possui conhecimento sobre outros domínios existentes na Internet, em outras palavras, cada domínio apenas responde pelo seu próprio espaço de nomes. Por exemplo, o domínio google.com não possui informações referentes ao domínio yahoo.com e viceversa. Cada nome de domínio na árvore do DNS possui um atributo que permite identificá-lo no espaço de nomes de domínio. Os atributos são chamados registro de recurso, os quais fornecem um mapeamento entre os nomes de domínio e objetos de rede como, por exemplo, o endereçamento numérico IP, servidor de correio eletrônico e servidor de nome com autoridade. Cada mensagem de resposta DNS carrega um ou mais registros de recursos. Existem diferentes registros de recursos que estão descritos com mais detalhes na RFC 1034 [Mockapetris 1987a]. Os mais relevantes apontados por trabalhos como [Castro et al. 2008],[Barbosa e Souto 2009] e [Yuchi et al. 2009] são: A - indica um endereço numérico a partir do nome simbólico ; PTR - realiza a tradução reversa de nomes apontando para um nome simbólico por meio do endereço IP; MX - especifica servidor um responsável pelo recebimento do correio eletrônico que chega ao domínio. 3. Trabalhos Relacionados Problemas de segurança no DNS são observados desde a década de 90, onde atacantes exploram falhas do sistema de nomes para subverter a segurança do sistema [Bellovin 1995]. Por isso, diversos trabalhos têm utilizado o monitoramento do tráfego DNS para identificar anomalias de redes como computadores infectados por vírus e worms [Barbosa e Souto 2009, Castro et al. 2008, Yuchi et al. 2009, Deri et al. 2012]. Em [Danzig et al. 1992] é apresentado um dos trabalhos pioneiros no processo de detecção de anomalias através do tráfego DNS. Nesse trabalho são avaliados aspectos do DNS como cache de consultas e eficiência do resolvedor de nomes. Dentre essas observações, onde foi observado que os principais problemas de consumo indevido de recurso de rede estão relacionados à quantidade de consultas repetidas e servidores de nome com problemas de configuração. Em [Brownlee et al. 2001] a análise passiva do tráfego DNS dos servidores de nome raiz demonstra que anomalias observadas em [Danzig et al. 1992] ainda são recorrentes. Para mitigar o volume de consultas inválidas que alcançam os servidores de nome raiz, em [Wessels e Fomenkov 2003] existe uma proposta para que administradores de Manaus, 25 a 27 de abril de ISSN (CDR)

3 rede configurem uma zona de domínio local para responder às consultas destinadas à zona de domínio in-addr.arpa. Outra solução encontrada em [Wessels 2004] sugere que fabricantes de software atualizem seus produtos com correções relacionadas ao DNS para reduzir a quantidade de consultas mal formadas. O trabalho de [Barbosa e Souto 2009] investigou o tráfego DNS do.br e constatou que aproximadamente 43% dos registros de recursos mais vistos são consultas do tipo PTR (reverso) enquanto outros trabalhos relacionados ao tema indicam que o registro do tipo A é o mais frequente. Em [Castro et al. 2008], a análise do tráfego dos servidores raiz mostrou que 90% das consultas que alcançam os Root Servers são solicitações indevidas. Para [Yuchi et al. 2009], o processo de análise dos servidores de primeiro nível da China (.cn) ilustra como o tráfego DNS daquele país é consultado internamente e por outros países. 4. Metodologia Esta seção apresenta a base de dados utilizada e os componentes da ferramenta, MyDns- Dump, para extração e análise do tráfego DNS Base de dados A base de dados para o experimento utiliza o tráfego de rede do projeto DITL 2008 [Neves et al. 2008]. O projeto DITL é uma ação entre os principais servidores de nomes autorizativos da Internet no mundo. No Brasil, participaram cinco instâncias dos servidores de nomes que respondem às consultas do tráfego DNS brasileiro. Cada servidor que participou do evento coletou durante os dias 18 e 19 de março de 2008, de modo passivo, o tráfego DNS (tráfego UDP, porta 53). Durante esses dois dias, foram coletados aproximadamente 5,4 bilhões de consultas, totalizando quase 230 GB de informação. Por razões claras de segurança e privacidade, os dados coletados são armazenados e mantidos pelo Centro de Pesquisa e Análise de Operações DNS [DNS-OARC 2013], disponíveis em diretórios separados pela nacionalidade do servidor das consultas capturadas, em arquivos compactados pela ferramenta de compressão Gzip. Este trabalho utiliza 13 arquivos como prova de conceito de implementação da ferramenta. A Tabela 1 apresenta um sumário dos arquivos utilizados referente à instância a.dns.br, no dia 18/03/2008. Para ilustrar o poder computacional de processamento de arquivo compactado, o arquivo pcap.gz é utilizado como exemplo. O processo de descompactação demora em média 3 minutos e resulta em um arquivo no formato original, o qual ocupa 2,3GB de espaço em disco. Como o ambiente é compartilhado com outros pesquisadores, o espaço em disco acaba sendo um limitador para os experimentos. Por esse motivo, a libtrace foi escolhida pela capacidade nativa de tratamento de arquivos compactados. A biblioteca libtrace tem demonstrado grandes avanços na análise profunda de pacotes de redes. O acesso nativo de leitura aos formatos compactados permite que análise do tráfego de rede seja mais rápida, através de paralelismo computacional. Para ilustrar o ganho de desempenho com a biblioteca, este trabalho comparou o processo de leitura dos arquivos indicados na Tabela 1 entre a libtrace e a biblioteca comumente utilizada em ferramentas de análise de rede, a libpcap [Jacobson et al. 2004]. Manaus, 25 a 27 de abril de ISSN (CDR)

4 Tabela 1. Arquivos utilizados da base de dados como prova de conceito. Arquivo Quantidade de Pacotes Tamanho Compactado pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB pcap.gz MB O cálculo de desempenho entre as duas bibliotecas foi denotado na Equação 1. Considere A = {Arquivo1, Arquivo2,..., Arquivo13} o conjunto de arquivos da base de dados, e (A i ) o cálculo do tempo (em milissegundos) para contagem de pacotes do arquivo A i. Para obter um conjunto de valores de tempo, cada arquivo é aberto 20 vezes, sendo Φ i o tempo total para processamento de A i. Em virtude do ambiente fornecido pela OARC-DNS ser compartilhado com outros pesquisadores, o processo de leitura de cada arquivo visa encontrar um valor que não sofra interferências por outros processos. Φ i = 20 i=1 (A i ) (1) Conforme ilustrado na Figura 1, o tráfego de rede é processado pelo MyDnsDump que, por sua vez, decompõe os pacotes através da biblioteca libtrace [Alcock et al. 2012]. Após o tratamento do pacote, tem-se como saída a impressão em texto claro dos campos da mensagem de rede (endereço IP de origem e destino, tipo da consulta e nome da consulta, por exemplo). As subseções seguintes descrevem com mais detalhes o funcionamento de cada componente da ferramenta proposta. Figura 1. Arquitetura proposta para coleta e análise do tráfego DNS. Manaus, 25 a 27 de abril de ISSN (CDR)

5 Tratador de arquivos O Tratador de arquivos é responsável pelo gerenciamento e leitura dos pacotes de rede. Este componente pode processar arquivos em tempo real (online) ou salvos em disco rígido (offline). Para processar um arquivo em disco, deve-se indicar o nome do mesmo, por exemplo./mydnsdump arquivo.pcap. Por outro lado, o monitoramento em tempo real exige que uma interface de rede seja informada, por exemplo./mydnsdump eth0. É importante ressaltar que a libtrace suporta arquivos no formato gzip, o que diminui o tempo para abrir arquivos neste formato, isto é, não há necessidade de descompactação do arquivo antes de processá-lo. A leitura de arquivo é realizada através da chamada de função trace create. Os parâmetros dessa função podem ser a entrada padrão (stdin); uma interface de rede; um arquivo no formato da libpcap ou um nome de computador remoto [Jacobson et al. 2004]. Quando as leituras ocorrem sem problemas, as funções trace start e trace read packet abrem de fato o parâmetro de entrada e processam os arquivos, respectivamente. A partir da abertura do arquivo, o conteúdo do mesmo é processado pelo componente que decodifica os campos tráfego DNS. Durante o desenvolvimento desde protótipo foi observado que o tipo de enlace loop não tinha suporte na libtrace. Este trabalho, portanto, contribui com um patch que adiciona o suporte ao tipo loop Decodificador de DNS A implementação da biblioteca libtrace é baseada no modelo OSI. No entanto, a partir da análise das referências e investigação de códigos fonte, não foi constatado códigos que gerenciam as camadas 5, 6 e 7 (sessão, apresentação e aplicação, respectivamente). De forma geral, para acessar a camada de aplicação é preciso encontrar a camada de transporte primeiro e depois incrementar para o próximo endereço de ponteiro. A implementação do MyDnsDump acessa à carga útil do DNS como ilustra o exemplo: udp = trace get udp(packet);... dnspkt = (char *) (udp + 1); Para o gerenciamento da camada de aplicação do DNS, este trabalho utiliza a implementação da função rfc1035nameunpack da ferramenta dnstop [Wessels 2012], uma das mais utilizadas no meio acadêmico, para obter acesso à carga útil do DNS. Neste método itera-se um conjunto de dados para acessar informações do DNS como, tipo da consulta (query type - qtype) e nome da consulta (query name - qname). Se tudo ocorrer corretamente, o módulo retorna 0, confirmando que os campos foram extraídos com sucesso e o query type e query name já podem ser identificados. Se retornar um valor diferente a 0, houve algum erro com a extração das informações do DNS. Manaus, 25 a 27 de abril de ISSN (CDR)

6 Tratador de estatística O tratador de estatística realiza operações matemáticas para ajudar no entendimento do tráfego de rede. Este componente realiza, por exemplo, a distribuição de frequência por registro de recurso de domínio (qtype). Outros cálculos realizados são o total de pacotes de rede, o total de solicitações e as respostas DNS. Para que o MyDnsDump seja competitivo com ferramentas como o dnstop, tcpdump ou wireshark, os seguintes requisitos funcionais, úteis para o processo de análise de anomalias de rede, precisam ser contemplados no protótipo: Domínios mais frequentes: lista os domínios que são mais frequentes nas consultas de nome. Quantidade de consultas por IP: dado um IP de entrada listar o total de consultas enviadas. Quantidade de erros de consultas: apresenta quais são os domínios que mais retornam erro de consulta, por exemplo, domínios inexistentes (NXDOMAIN). Sumário do tráfego de rede: lista o tempo médio de consultas, tamanho do nome de domínio e quantidade de pacotes Tratador de anomalias O tratador de anomalias fornece dados ao componente de estatística para operação de cálculos. O trabalho em [Castro et al. 2008] apresenta uma lista de consultas DNS consideradas como anomalias de rede. Para tornar o entendimento mais claro considere: consultas para domínios de primeiro nível inválidos; consultas para o endereçamento de rede privado; consultas A-para-A. Além da classe especificada por Castro et al., o trabalho em [Barbosa e Souto 2009] estende essa lista indicando que consultas compostas pelo também devem ser consideradas como não desejadas. Portanto, este trabalho considera como desenvolvimento futuro, todos os itens apontados em ambos artigos Formatador de saída A última fase da arquitetura proposta é o formatador de saída. Nesse componente, os dados processados em outros módulos são tratados e apresentados ao usuário do MyDns- Dump. Uma saída clara e adaptativa é essencial para adoção da ferramenta. Como prova de conceito, este protótipo apresenta o IP de origem e destino, o tipo de registro de recurso (qtype) e o nome do domínio (qname). É importante observar que cada linha impressa representa um pacote de rede analisado e, ao final do processamento do tráfego, a ferramenta apresenta a distribuição de frequência por tipo de registro de recurso. No entanto, entende-se que esse fluxo de apresentação de dados não é adequado para análise rápida de dados. Para facilitar a utilização da ferramenta, os seguintes requisitos estão em abertos para desenvolvimento futuro: Frequência de IP: essa opção permite ao usuário listar os endereços de IP mais frequente no tráfego. O usuário deveria indicar uma opção da hora da execução da ferramenta, por exemplo,./mydnsdump -s IP. Manaus, 25 a 27 de abril de ISSN (CDR)

7 Campos de cabeçalho: listar com mais detalhes de uma camada. Por exemplo, o DNS possui campos que indicam os parâmetros utilizados na consulta tais como, bit de recursividade, código de retorno da consulta ou tempo em que aquele domínio não é mais válido. Formatos de saída: fornecer a saída de dados em outros formatos como XML e CSV. 5. Resultados 5.1. Leitura de arquivos Figura 2. Comparativo entre arquitetura proposta e capinfo. A Figura 2 apresenta o resultado comparativo entre duas ferramentas (MyDns- Dump e capinfos, uma ferramenta baseada na biblioteca libpcap) do tempo gasto no processamento de cada arquivo da base de dados. A obtenção do tempo é o resultado da saída do programa time do Unix, sendo que cada ponto do gráfico é obtido através do cálculo da Equação 1. É possível constatar que a ferramenta MyDnsDump é, em todos os casos, superior a seu concorrente, Capinfos. O nível de confiança utilizado no gráfico foi de 95% e, a partir daí, encontrou-se o intervalo de confiança. Os maiores valores foram observados na ferramenta que utiliza a libpcap, isto é, milissegundos, enquanto para MyDnsDump, o tempo é de Mesmo para os valores mínimos, a biblioteca libtrace é mais rápida que a capinfo, e milissegundos, respectivamente Contribuição libtrace Apesar da libtrace ser uma biblioteca bastante completa, seria impossível a implementação de todos os tipos de padrões contidos no universo das redes computacionais. Além do mais, é uma ferramenta relativamente nova no mercado em relação a sua principal concorrente libpcap. Manaus, 25 a 27 de abril de ISSN (CDR)

8 Por esse motivo, foi necessário o desenvolvimento de um patch para acrescentar o reconhecimento de tipos de compressão de cabeçalhos diferentes, como o tipo loop, que ainda não vem definido na biblioteca. Esse tipo de encapsulamento é utilizado nos sistemas que utilizam o OpenBSD. Figura 3. Modificação da biblioteca libtrace para suporte do formato OpenBSD- Loop A Figura 3 ilustra a principal modificação no código fonte da biblioteca, lib/protocols l2.c. Ao identificar esse tipo de encapsulamento, deve-se caminhar pelo cabeçalho, pois a biblioteca não reconhece o início dos campos das camadas. Sabendo disso, soma-se 4 bytes no ponteiro onde apontava para a camada de enlace e, com isso, foi possível encontrar a camada de rede. A partir daí a biblioteca forneceu os artifícios necessários para chegar ao DNS. 6. Conclusões e Trabalhos Futuros Neste artigo foi apresentado uma ferramenta para extração e análise do tráfego DNS chamada MyDnsDump, cujo maior diferencial é o uso da biblioteca de análise de trace de redes libtrace. Como a biblioteca é bastante nova e, por isso, pouco trabalhada, houveram dificuldades em encontrar soluções para alguns problemas, sendo que o principal foi a não existência do encapsulamento do tipo loop. Para resolvê-lo, foi criado uma patch para acrescentar essa nova funcionalidade. O mesmo foi enviado aos mantenedores da biblioteca, aprovado e estará disponível na próxima versão, Mesmo com esse contratempo, a biblioteca mostrou uma grande facilidade no desenvolvimento de novas aplicações, capacidade de leitura nativa de arquivos compactados e online (a partir da interface de rede do dispositivo) e grande velocidade de processamento das informações dos arquivos, obtendo resultados superiores ao seu principal concorrente libpcap, conforme a Seção 4. É importante salientar que a medição dos tipos de consultas ao DNS deve ser contínua, pois por meio da análise dos resultados processados pelo aplicativo, as ope- Manaus, 25 a 27 de abril de ISSN (CDR)

9 radoras de serviços de DNS podem desenvolver soluções para minimizar o tráfego de consultas não desejadas. Como trabalhos futuros, pretende-se i) encontrar o valor mais apropriado para leitura de cada arquivo, onde uma possível alternativa é a utilização de modelos de regressão; ii) fornecer outros formatos de saída dos dados, por exemplo, XML e CSV; iii) exibir novas funcionalidades como frequência de IP e campos do cabeçalho DNS. Referências Alcock, S., Lorier, P., e Nelson, R. (2012). Libtrace: a packet capture and analysis library. SIGCOMM Comput. Commun. Rev., 42(2): Barbosa, K. R. S. e Souto, E. (2009). Analise passiva do tráfego dns da internet brasileira. Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, 9(1): Bellovin, S. M. (1995). Using the domain name system for system break-ins. In Proceedings of the 5th conference on USENIX UNIX Security Symposium - Volume 5, SSYM 95, pages 18 18, Berkeley, CA, USA. USENIX Association. Brownlee, N., Claffy, K., e Nemeth, E. (2001). Dns measurements at a root server. In Global Telecommunications Conference, GLOBECOM 01. IEEE, volume 3, pages vol.3. Castro, S., Wessels, D., Fomenkov, M., e Claffy, K. (2008). A day at the root of the internet. SIGCOMM Comput. Commun. Rev., 38(5): Danzig, P. B., Obraczka, K., e Kumar, A. (1992). An analysis of wide-area name server traffic: a study of the internet domain name system. SIGCOMM Comput. Commun. Rev., 22(4): Deri, L., Trombacchi, L. L., Martinelli, M., e Vannozzi, D. (2012). Towards a passive dns monitoring system. In Proceedings of the 27th Annual ACM Symposium on Applied Computing, SAC 12, pages , New York, NY, USA. ACM. DNS-OARC (2013). (dns-oarc) the dns operations, analysis, and research center. (acessado em 01/03/2013). Jacobson, V., Leres, C., e McCanne, S. (2004). pcap - packet capture library. http: // (acessado em 01/03/2013). Mockapetris, P. (1987a). Domain names - implementation and specification. RFC 1035, Internet Engineering Task Force. Mockapetris, P. (1987b). RFC 1034 Domain Names - Concepts and Facilities. Internet Engineering Task Force. Neves, F., Kobayashi, H. K., do Amaral, M. G., e Wessels, D. (2008)..br DNS traces DITL 2008 (collection) HS-K=.br+DNS+traces+DITL+2008 (accessed on 2009?02?13). Wessels, D. (2004). Is your caching resolver polluting the internet? In Proceedings of the ACM SIGCOMM workshop on Network troubleshooting: research, theory and operations practice meet malfunctioning reality, NetT 04, pages , New York, NY, USA. ACM. Manaus, 25 a 27 de abril de ISSN (CDR)

10 Wessels, D. (2012). Dnstop: Stay on top of your dns traffic. measurement-factory.com/tools/dnstop/ (acessado em 01/03/2013). Wessels, D. e Fomenkov, M. (2003). that s a lot of packets. In in Proc Passive and Active Measurements Workshop. Yuchi, X., Wang, X., Li, X., e Yan, B. (2009). Dns measurements at the.cn tld servers. In Proceedings of the 6th international conference on Fuzzy systems and knowledge discovery - Volume 7, FSKD 09, pages , Piscataway, NJ, USA. IEEE Press. Zdrnja, B., Brownlee, N., e Wessels, D. (2007). Passive monitoring of dns anomalies. In Proceedings of the 4th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, DIMVA 07, pages , Berlin, Heidelberg. Springer-Verlag. Manaus, 25 a 27 de abril de ISSN (CDR)