Avaliação experimental do uso de honeypots de baixa interatividade para detecção de ataques em redes de computadores

Transcrição

1 Leonardo Arruda do Amaral Andrade Avaliação experimental do uso de honeypots de baixa interatividade para detecção de ataques em redes de computadores Vitória - ES 09 de setembro de 2009

2 Leonardo Arruda do Amaral Andrade Avaliação experimental do uso de honeypots de baixa interatividade para detecção de ataques em redes de computadores Monografia apresentada para obtenção do Grau de Engenheiro de Computação pela Universidade Federal do Espírito Santo. Orientador: Prof. Dr. Magnos Martinello UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO - UFES CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA Vitória - ES 09 de setembro de 2009

3 Monografia de Projeto Final de Graduação sob o título Avaliação experimental do uso de honeypots de baixa interatividade para detecção de ataques em redes de computadores, defendida por Leonardo Arruda do Amaral Andrade e aprovada em 09 de setembro de 2009, em Vitória, Estado do Espírito Santo, pela banca examinadora constituída pelos professores: Prof. Dr. Magnos Martinello Universidade Federal do Espírito Santo Orientador Prof. MSc. Gilmar Luiz Vassoler Instituto Federal do Espírito Santo Prof. MSc. Jadir Eduardo Souza Lucas Universidade Federal do Espírito Santo Eng. Salim Suhet Mussi Universidade Federal do Espírito Santo

4 Dedicatória A Dona Arruda, minha avó, por todas as suas boas histórias.

5 Agradecimentos Este trabalho consiste em um dos passos finais de uma jornada de cinco anos, oficialmente iniciada no dia do ingresso no curso o qual estou agora concluindo. A verdade, porém, é que as condições para essa caminhada se iniciaram muito antes disso. Acredito também que este é um marco importante, um ponto de júbilo que deve ser dividido com algumas pessoas e uma oportunidade única de agradecer àqueles que até aqui me ajudaram de alguma forma. Agradeço a minha família materna e paterna, incluindo aí tios, tias, primos e primas que, no mínimo, sempre torceram para que essa vitória fosse concretizada. Aos mais próximos, agradeço por todo o carinho, amor incondicional dedicados desde a minha infância. Sou muito grato a vocês por isso! Separo um ponto de agradecimento especial a minha mãe, Luciane, e ao meu pai, Leonardo, por toda a educação, amor, carinho e proteção proporcionados até aqui. Nunca pouparam esforços para proporcionar-me o que de melhor eles poderiam oferecer. Fantástico trabalho, vocês estão de parábens! Sinto-me orgulhoso de tê-los como pais. Vencedores por suas histórias e escolhidos por Deus! A jornada pode ser dura, mas sabemos quem nos guia. Aos meus avós: ao meu avô Delzo (Seu Dedé) [in memorian] e à minha avó Valdemira (Dona Arruda, Arrudinha e outros tantos carinhosos nomes)[in memorian] que não podem mais presenciar estas palavras. A vocês, minhas palavras de agradecimento por tudo. Especialmente, a minha avó, que tanto desejou ver me formar, minha gratidão por todas as boas histórias compartilhadas. Ficarão sempre guardadas em minha mente! No âmbito pessoal, lembranças aos amigos da pequena Itabatã, lugar onde vivi minha infância e adolescência. Também aos irmãos da Igreja Cristã Maranata, agradeço por suas orações. É claro, no âmbito do convívio de curso, agradeço a todos os colegas (uma turma com pessoas acima da média) e, principalmente, amigos que foram feitos durante esses cinco anos. Agradecimentos especiais àqueles que tive a oportunidade de fazer trabalhos conjuntamente, dividindo as aflições e desesperos inerentes a esse tipo de tarefa, de forma que não vou citar nomes porque trata-se uma lista considerável. Não se pode esquecer também das listas de exercícios resolvidos e cópias das anotações de aula: muito obrigado! Impossível dizer que elas não facilitaram um pouco no estudo de matérias essenciais do curso. Agradeço também

6 ao colega e amigo Felipe Dalvi por ter compartilhado o modelo Latex de forma a produzir um documento com formatação muito vistosa. :) Agradecimentos também aos amigos e colegas dos mais de três anos em que fui integrante do Suporte do Departamento de Informática. Cabem aqui os agradecimentos aos professores Raul Henrique, Sérgio Freitas e Hilário Seibel pela oportunidade de participar desse grupo e pelo respeito destinado a seus integrantes. Meu reconhecimento especial ao trabalho realizado pela profa. Mariella Berger, por encorajar o trabalho do grupo e fazê-lo com muita boa vontade e por ter se tornado uma amiga durante esse tempo de trabalho. Também precisam ser reconhecidos aqueles professores e funcionários da UFES que, lutando contra a correnteza, dão suas aulas e fazem seus trabalhos com esforço, dedicação e decência. Não poderia me esquecer de agradecer ao meu orientador, prof. Magnos Martinello, por encorajar e apoiar o desenvolvimento e a aplicabilidade desse trabalho. Obrigado pelas dicas e pelo tempo dispendido na revisão do mesmo. Agradeço também aos colegas da equipe do PoP-ES, Rafael (vulgo Rezo), Salim e Pedro pelo ambiente de trabalho e por suportarem toda a gambiarra necessária (nem tanta assim) para a montagem do ambiente de testes. :) Agradecimentos institucionais ao PoP-ESRNP por possibilitar a execução desse trabalho e ao Suporte-DI pela cessão das máquinas utilizadas no mesmo. E finalmente, agradeço a Deus por me proporcionar tudo isso e muito mais que se chama vida, por me auxiliar nos momentos difíceis, mesmo quando não merecia, e também, porque, bem... ele primeiro me amou. =) Obrigado a todos!

7 Resumo Este trabalho visa avaliar ferramentas (relacionadas a tecnologia de honeypots) para detecção de ataques em redes de computadores utilizando uma abordagem experimental. Inicialmente, uma visão conceitual sobre o tema é apresentada. Em seguida, a atenção é voltada para o modo de funcionamento das ferramentas utilizadas. Por meio de experimentação em um ambiente real, dados são coletados e analisados posteriormente por um conjunto de ferramentas e scripts especializados com o intuito de entender as características de determinados ataques. As conclusões extraídas destas análises bem como as lições aprendidas durante o desenvolvimento dos ambientes também são descritas. Este trabalho poderá ser útil como base para outros trabalhos relacionados à detecção de atividades maliciosas em redes de computadores em nível local. Palavras-chave: segurança de redes, honeypot, honeynet, ataques, malware, botnet, Honeyd, Nepenthes, Amun, Honeytrap, SSH Kojoney, libemu, Nebula, Honeycomb, software livre.

8 Sumário Lista de Figuras Lista de Tabelas Lista de Siglas e Abreviaturas 1 Introdução p Contexto p Motivação p Objetivo p Metodologia p Estrutura da monografia p Honeypots p Breve histórico da tecnologia de honeypots p Definição do termo honeypot p Classificação referente a honeypots p Quanto ao nível de interatividade p Honeypots de baixa interatividade p Honeypots de média interatividade p Honeypots de alta interatividade p Honeytokens p Honeypots de baixa versus honeypots de alta interatividade p. 28

9 2.3.2 Quanto a estrutura p Honeypots físicos p Honeypots virtuais p Honeypots físicos versus honeypots virtuais p Quanto a finalidade p Honeypots de pesquisa p Honeypots de produção p Quanto ao modo de comunicação p Honeypots tradicionais p Honeypots clientes (client honeypots) p Quanto a adaptabilidade p Honeypots estáticos p Honeypots dinâmicos p Custos e benefícios relacionados aos honeypots p Vantagens p Custos p Custos de desenvolvimento p Custos de manutenção p Questões legais relacionadas aos honeypots p Questões relacionadas a detecção de honeypots p Usos e trabalhos relacionados a tecnologia de honeypots p Mitigação dos problemas de spam e rastreamento de spammers... p Detecção de malwares e botnets p Estudo e entendimento das ações dos blackhats p Ferramentas utilizadas neste trabalho p Introdução p. 47

10 3.2 Honeyd p Recebimento de dados da rede p Arquitetura dos componentes do Honeyd p O sistema de personalidades (Personality Engine)..... p Topologias de roteamento p Configuração do Honeyd p Logs do Honeyd p Honeycomb p Mecanismo de rastreamento de conexões p Mecanismo de análise de protocolos p Forma de exibição das assinaturas p Nepenthes p Arquitetura da plataforma Nepenthes p Módulos de vulnerabilidade p Módulos de análise de shellcode p Módulos de busca p Módulos de submissão p O sistema de emulação de shell p Captura de novos exploits p Limitações do Nepenthes p Amunhoney p Honeytrap p Captura de ataques desconhecidos p Modos de ação do Honeytrap p Emulação de serviços e captura de arquivos p Nebula p. 72

11 3.5.5 Libemu p SSH Honeypot p Ferramentas utilizadas para ataques SSH via força bruta p Kojoney SSH Honeypot p Ambiente experimental e resultados obtidos p Introdução p Experimentos com o Honeyd p Descrição do ambiente e recursos utilizados p Descrição dos resultados obtidos p Análise do tráfego relativo ao dia 02/03/ p Análise do tráfego relativo ao dia 04/03/ p Análise do tráfego relativo ao dia 15/03/ p Análise do tráfego relativo ao dia 08/04/ p Experimentos com o Nepenthes p Descrição do ambiente utilizado p Descrição dos resultados obtidos p Experimentos com o Amunhoney p Descrição do ambiente utilizado p Descrição dos resultados obtidos p Experimentos com o Honeytrap p Descrição do ambiente utilizado p Descrição dos resultados obtidos p Experimentos com o SSH Kojoney p Descrição do ambiente utilizado p Descrição dos resultados obtidos p. 109

12 5 Conclusões e trabalhos futuros p Conclusões p Trabalhos futuros p. 116 Referências p. 118

13 Lista de Figuras 1 Visão geral da operação do framework Honeyd em relação a rede p Diagrama dos compomentes da arquitetura do Honeyd p Fingerprint no formato Nmap que descreve algumas característica da pilha de rede do Windows Server p Diagrama da arquitetura do Honeycomb, mostrada na situação de configuração típica do Honeyd, com o Honeyd simulando diferentes máquinas, cada qual executando alguns serviços pré-configurados p Arquitetura da plataforma Nepenthes e os relacionamentos entre os módulos que a compõe p Trecho da configuração do Honeyd responsável pelo comportamento do template e por associar os endereços IP aos honeypots virtuais p Série temporal com a quantidade de pacotes recebidos a cada dia pelos honeypots virtuais do Honeyd (período de 15 de fevereiro de 2009 a 11 de abril de 2009) p Histograma relativo a quantidade de pacotes recebidos pelos honeypots virtuais do Honeyd em relação ao dia da semana p Histograma relativo a quantidade de bytes recebidos pelos honeypots virtuais do Honeyd em relação ao dia da semana p Histograma relativo a quantidade de pacotes recebidos pelos honeypots virtuais do Honeyd em relação a hora do dia p Histograma relativo a quantidade de bytes recebidos pelos honeypots virtuais do Honeyd em relação a hora do dia (apenas pacotes TCP e UDP foram contabilizados) p Gráfico de barras com a quantidade de pacotes recebidos por cada honeypot virtual durante o período de experimentação p. 86

14 13 Gráfico de barras com a quantidade de bytes recebidos (apenas referentes aos pacotes que utilizaram os protocolos UDP e TCP) por cada honeypot virtual durante o período de experimentação p Exemplo de assinatura gerada (no formato Bro) pelo Honeycomb em decorrência dos pacotes recebidos pelos honeypots virtuais p Série temporal das interações diárias registradas pelo Nepenthes (com downloads bem sucedidos ou não) p Série temporal das interações diárias registradas pelo Nepenthes (apenas as que resultaram em downloads bem-sucedidos) p Série temporal das interações diárias registradas pelo Nepenthes com relação ao Slammer p Exemplo de assinatura gerada (no formato Snort) pelo Nebula ao analisar os traces obtidos pelo Honeytrap p Kojoney SSH Honeypot em ação durante o processo de autenticação de usuário (observe que não há diferenças visuais em relação às informações exibidas por um servidor OpenSSH legítimo) p Ocorrências de detecção de indícios de acessos SSH manuais destinados ao honeypot p Comandos utilizados pelos atacantes para obter arquivos maliciosos como executar atividades maliciosas p. 113

15 Lista de Tabelas 1 Alguns dos módulos de vulnerabilidades do Nepenthes e as notificações de segurança associadas a eles p Dias com a maior quantidade de pacotes recebidos p Dias da semana e o número total de pacotes recebidos (ordenado descrescente pelo número de pacotes) p Número total de pacotes recebidos em relação a cada protocolo identificado pelo Honeyd p Endereços IP que mais enviaram pacotes para os honeypots virtuais p Lista com os 10 países que mais enviaram pacotes aos honeypots virtuais... p Quantidade de pacotes e bytes recebidos por cada honeypot virtual durante o período de experimentação p As 10 portas mais visadas pelos atacantes durante o período de experimentação do honeypot p Quantidade de pacotes originados de determinadas versões de sistemas operacionais (identificados por meio de fingerprinting remoto) p Os 10 endereços IP com maior número de interações registradas pelo Nepenthes durante o período de observação p Os 10 países com maior número de interações registradas pelo Nepenthes durante o período de observação p Os 10 países com maior número de interações registradas pelo Nepenthes referentes ao Slammer (MS-SQL Worm) p Os 10 endereços IP com maior número de interações registradas pelo Nepenthes referentes ao Slammer (MS-SQL Worm) p Formas de transferência do binário durante o processo de captura do worm e o número de ocorrências de cada uma delas p. 97

16 15 Os 10 binários que mais foram baixados o processo de coleta de worms.... p Resultado da avaliação do conjunto de binários coletados com relação à detecção pelas ferramentas anti-vírus (referente ao conjunto coletado pelo Nepenthes) p Tipos de malwares coletados pelo Nepenthes (segundo a ferramenta AVG).. p Os 10 países com maior número de interações bem-sucedidas registradas pelo Amun durante o período de observação p Os 10 endereços IP com maior número de interações bem-sucedidas registradas pelo Amun durante o período de observação p Resultado da avaliação do conjunto de binários coletados com relação à detecção pelas ferramentas anti-vírus (referente ao conjunto coletado pelo Amun).p Tipos de malwares coletados pelo Amun (segundo a ferramenta AVG)..... p Os 10 países com maior número de conexões endereçadas à máquina do Honeytrap durante o período de observação p Os 10 endereços IP com maior número de conexões endereçadas à máquina do Honeytrap durante o período de observação p As 10 portas mais visadas pelos atacantes durante o período de experimentação do Honeytrap p Lista dos 20 usuários mais usados nas tentativas de ataques ao serviço SSH provido pelo Kojoney p Os 10 endereços IP que mais requisitaram conexões SSH ao honeypot durante o período de experimentação p Os 10 países com maior número de conexões SSH realizadas ao endereço IP do honeypot p Os 10 comandos mais requisitados pelos atacantes quando o acesso ao shell falso era concedido depois de uma autenticação bem sucedida p. 112

17 Lista de Siglas e Abreviaturas API ARP AS CBL COTS DCE DDoS DHCP DNS FTP GHH GRE HTTP ICMP IDS IGMP IIS IP ISN ISP IRC LAN MAC Application Programming Interface Address Resolution Protocol Autonomous System Composite Blocking List Comercial Off-the-shelf Distributed Computing Environment Distributed Denial of Service Dynamic Host Configuration Protocol Domain Name System File Transfer Protocol Google Hack Honeypot Generic Routing Encapsulation HyperText Transfer Protocol Internet Control Management Protocol Intrusion Detection System Internet Group Management Protocol Internet Information Services Internet Protocol Initial Sequence Number Internet Service Provider Internet Relay Chat Local Area Network Media Access Control

18 MTA NAT NetBIOS NIDS NTP PoP-ES RBL RFI RNP ROI RPC RRDTool SIP SIV SMB SMTP SQL SSH TCP TFTP TTL UBE UCE UDP UFES URI Mail Transfer Agent Network Address Translation Network Basic Input/Output System Network IDS Network Time Protocol Ponto de Presença da Rede Nacional de Ensino e Pesquisa no Estado do Espírito Santo Realtime Block List Remote File Inclusion Rede Nacional de Ensino e Pesquisa Return of Investiment Remote Procedure Call Round Robin Database Tool Session Initiation Protocol System Integrity Verifier Server Message Block Simple Mail Transfer Protocol Structured Query Language Secure Shell Transmission Control Protocol Trivial File Transfer Protocol Time to Live Unsolicited Bulk Unsolicited Commercial User Datagram Protocol Universidade Federal do Espírito Santo Uniform Resource Identifier

19 UML XML XOR WINS User Mode Linux extensible Markup Language Exclusive OR (ou exclusivo) Windows Internet Name Service API ARP AS CBL COTS DCE DDoS DHCP DNS FTP GHH GRE HTTP ICMP IDS IGMP IIS IP ISN ISP IRC LAN MAC MTA NAT NetBIOS NIDS NTP PoP-ES RBL RFI RNP ROI RPC RRDTool SIP SIV SMB SMTP SQL SSH TCP TFTP TTL UBE UCE UDP UFES URI UML XML XOR WINS

20 19 1 Introdução 1.1 Contexto Tradicionalmente, as redes universitárias de modo geral têm por característica serem bastante permissivas, impondo a seus usuários poucas restrições reais quanto ao tráfego gerado e recebido pelos mesmos. Essa característica facilita a execução de ataques destinados ou partindo das mesmas. Certamente, proporcionar uma rede totalmente segura pode ser considerada uma ilusão. A segurança das redes não abrange apenas aspectos técnicos como, por exemplo, sobre qual solução de firewall, roteador, sistema operacional ou outra tecnologia usar; envolve também aspectos sociais e políticos, normalmente refletidos na política de segurança de rede e que compreendem questões desde aspectos relativos às alocações físicas e restrições de acesso a equipamentos até a conscientização dos usuários. Desse modo, os administradores da rede devem estar conscientes do nível de segurança que proporcionam a seus usuários com base na infra-estrutura disponível e na avaliação dos aspectos não-técnicos que influem nas questões de segurança. A falta de mecanismos de detecção de ataques (e outras atividades maliciosas) contribui para o uso dessas redes por atacantes ou usuários mal-intencionados, sem que alertas sejam produzidos de maneira que os administradores das redes sejam minimamente informados sobre essas ações. Além disso, a falta de informações sobre ataques a sua rede pode dar aos administradores a falsa sensação de proteção e segurança. 1.2 Motivação A motivação para o desenvolvimento deste trabalho originou-se da constatação da falta de mecanismos de detecção de intrusão nas redes principais da UFES (Universidade Federal do Es-

21 20 pírito Santo), como também nas redes servidas pelo PoP-ES/RNP 1 (Ponto de Presença da Rede Nacional de Ensino e Pesquisa no Estado do Espírito Santo), sendo que não há qualquer ação conhecida neste sentido, seja utilizando para isso sistemas de detecção de intrusão baseados em assinaturas, análise de fluxos (flows), honeypots ou qualquer outra tecnologia. Os alertas sobre ataques e atividades maliciosas para essas redes são reportados por organizações externas como centros de tratamentos de incidentes ou até mesmo pelos administradores das redes atacadas devido a ações originadas a partir das redes locais. Assim, optou-se por examinar as potencialidades e fraquezas da tecnologia de honeypots para que alguma ação local de detecção de incidentes possa ser iniciada. É preciso, entretanto, deixar claro que os honeypots sozinhos não proporcionam proteção adicional diretamente; devendo, desse modo, estarem integrados com outras tecnologias já consagradas (como firewall, sistemas de detecção de intrusão [Intrusion Detection Systems (IDS)], entre outras) além de uma política de segurança estabelecida e respeitada dentro de uma determinada rede. Eles normalmente são usados como fontes de informação para o ajuste de outros elementos da rede, ou seja, aumentam o nível de segurança de forma indireta. 1.3 Objetivo O objetivo deste trabalho é a avaliação de ferramentas (relacionadas a tecnologia de honeypots) para detecção de ataques em redes de computadores utilizando para isso uma abordagem experimental. Para isto, as ferramentas foram distribuídas em três grupos: as que serão utilizadas para observar unicamente as características relacionadas ao tráfego malicioso direcionado aos honeypots a nível de rede (relacionados aos endereços IP) e a nível de transporte (relacionado às portas utilizadas como alvo dos ataques). Neste caso, a ferramenta Honeyd será utilizada. as que serão utilizadas para estudar meios de detecção de malware que se auto-propagam pela rede (worms), onde serão observados algumas características dos ataques e dos binários que porventura forem capturados, sendo representadas pelos honeypots Nepenthes, Amun e Honeytrap; e as que serão utilizadas para avaliar algumas características de ataques a servidores SSH 1 Os não familiarizados com o contexto podem entender simplificadamente o PoP-ES/RNP como um ISP (Internet Service Provider).

22 21 (um serviço seguro bastante comum e amplamente usado), onde será utilizado um honeypot especializado nesta tarefa: o SSH Kojoney. 1.4 Metodologia A metodologia geral adotada neste trabalho é observar os ataques que chegam aos honeypots de maneira passiva para análise posterior dos dados obtidos. O conjunto de análise destes dados foi realizado por ferramentas especializadas e scripts personalizados para a obtenção de estatísticas a partir dos arquivos de log gerados pelos honeypots. 1.5 Estrutura da monografia No capítulo 2, são apresentados os conceitos gerais relacionados aos honeypots, um pouco de sua história, uma discussão sobre o que são honeypots, bem como as diversas classificações existentes, além de uma visão geral sobre os custos e benefícios envolvidos, as questões legais relacionadas e finalizando com exemplos da utilização da tecnologia para auxiliar no entendimento e resolução de alguns problemas da área de segurança de redes. O capítulo 3 se concentra em apresentar o modo de funcionamento das ferramentas utilizadas neste trabalho. Ele descreve, portanto, a forma de operação de um framework para a criação de honeypots virtuais, o Honeyd; ferramentas especializadas na coleta de informações sobre malwares que se auto-propagam pela rede, sendo incluídas aqui o Nepenthes, o Amun e o Honeytrap; e também sobre as funcionalidades providas pelo Kojoney SSH Honeypot. Nesse capítulo, são apresentados boa parte das funcionalidades presentes em cada ferramenta, não significando porém, que todas as funcionalidades descritas foram usadas durante o período de experimentação. A descrição dos ambientes construídos e os parâmetros relevantes em cada um deles, bem como a análise dos dados obtidos a partir destes experimentos são apresentados no capítulo 4. As conclusões e possíveis trabalhos futuros que possam ser desenvolvidos dentro do mesmo escopo deste trabalho são apresentados no capítulo 5.

23 22 2 Honeypots 2.1 Breve histórico da tecnologia de honeypots Embora os honeypots na área de segurança de redes de computadores tenham ganhado maior destaque a partir da iniciativa internacional do Honeynet Project (PROJECT, 2009) em 1999 (liderado por Lance Spitzner) e do lançamento de livros que descreviam as experiências obtidas e as lições aprendidas sobre as táticas, objetivos e ferramentas usadas pela comunidade blackhat 1, sua utilização iniciou-se antes desses marcos. O conceito de honeypots foi introduzido em sistemas computacionais por Clifford Stoll no fim da década de No artigo conhecido como Cuckoo s Egg (STOLL, 1988), ele descreve uma maneira de monitorar e rastrear um intruso. Para atingir este propósito, ele criou um projeto governamental completo, que parecia ser verdadeiro, nos quais os invasores gastaram uma boa quantidade de tempo baixando-os e analisando-os, o que ofereceu uma oportunidade para que os atacantes fossem rastreados até sua origem. O primeiro honeypot real, embora não tenha sido chamado dessa forma, foi mantido por Bill Cheswick, que realizou uma experiência no início do ano de 1990 em que um intruso, explorando uma falha do sendmail 2, obteve acesso a um gateway dos Laboratórios da AT&T Bell. A equipe deixou o atacante, por muitos meses, ter acesso à máquina com intuito de rastrear sua localização e aprender sobre as técnicas e ferramentas por ele utilizados. Todos os resultados dessa experiência foram relatados em um artigo, que cobriu todos os sucessos e insucessos do atacante, as iscas e armadilhas para enganá-lo e detectá-lo e a gaiola chroot que foi construída para observar suas atividades (CHESWICK, 1990). O termo honeypot para descrever esse tipo de estratégias e ferramentas apenas foi introduzido em 1999 por Lance Spitzner. A partir de então muitos autores propuseram diversas definições e classificações, que serão descritas nas seções seguintes. 1 Termo utilizado para definir os indivíduos que são especializados em realizar intrusões não autorizadas em redes de computadores. 2 Sendmail é dos mais populares servidores de mail em ambientes Unix.

24 Definição do termo honeypot A definição do termo honeypot ainda é um pouco controversa. A definição mais conhecida é dada por Lance Spizner como (COMMUNITY, 2001): Um honeypot é um recurso computacional de segurança dedicado a ser sondado, atacado ou comprometido. Como pode-se perceber, o termo honeypot não possui uma definição exata. Ele descreve um conjunto de ferramentas e artefatos de rede usados para enganar atacantes. Diferentemente de um filtro de pacotes (como um firewall), um honeypot não fornece segurança por si só. Por isso ele deve estar integrado a toda uma infra-estrutura de segurança de rede. De fato, o próprio Spitzner considera em (COMMUNITY, 2001) sua definição um pouco vaga, e atribui a isso o fato de que honeypots são ferramentas altamente flexíveis que podem ser aplicadas em uma variedade de diferentes situações. Ainda assim, essa definição oferece uma boa idéia do que se tratam os honeypots. Teoricamente, não importa a natureza do recurso de rede, contanto que a importância desse recurso esteja em ser sondado ou atacado. Um honeypot precisa ser atacado para coletar algum tipo de informação. Um sistema de detecção de intrusão (IDS) mesmo sem detectar ataques pode ser um indicador de atividade normal da rede, entretanto um honeypot que não é atacado não serve para nada, ou seja, perde o seu valor. Em seu artigo, Pouget (POUGET; DACIER; DEBBAR, 2003) discute as definições usadas por outros autores e define o termo como: Um honeypot consiste em um ambiente onde vulnerabilidades são deliberadamente introduzidas de forma que sejam observadas intrusões (invasões). Segundo Spitzner (COMMUNITY, 2001), mesmo sem uma definição exata, o conceito de honeypot é simples. Ele é um recurso que não tem valor produtivo, não existindo razão para alguém interagir com ele. Assim, qualquer tentativa de se comunicar com o sistema pode ser considerado uma sondagem, varredura ou ataque. Além disso, de forma geral, se um honeypot inicia uma conexão de saída, então o sistema onde ele foi instalado provavelmente está sendo comprometido. Como um honeypot não roda nenhum serviço com valor real dentro da rede de produção, cada conexão destinada a ele é uma evidência de um ataque ou, no mínimo, uma indicação de uma má configuração na rede.

25 24 Além disso, um honeypot precisa ser capaz de enganar possíveis atacantes. Para isso, ele pode se passar por um host que contém informações ou serviços interessantes ou com algum valor para o atacante, de forma que o nível de realismo propiciado ( a doçura do mel ) é definido pelo contexto e aplicação a que se destina o honeypot e também pelas informações ou serviços que ele disponibiliza. Com relação a novos ataques, eles não podem ser diretamente evitados por um honeypot. Entretanto, é possível detectá-los a partir de um. Também pode-se citar que uma das vantagens do uso de honeypots é que o tempo que o atacante perde com eles pode ser usado pelo administrador da rede para proteger os recursos importantes de produção da rede. Na próxima seção, serão discutidos os aspectos relativos as principais classificações referentes aos honeypots e fatores que devem ser considerados quando da execução de um projeto envolvendo-os. 2.3 Classificação referente a honeypots Existem diferentes tipos de honeypots que variam dependendo do contexto em que eles são aplicados, cada um tendo suas vantagens e desvantagens. Ou seja, o tipo do honeypot a ser usado depende do objetivo que se deseja alcançar (SPITZNER, 2002). Há também alguns fatores que devem ser levados em consideração durante a escolha de um determinado tipo de honeypot como, por exemplo, questões relacionadas a: Instalação e configuração: é importante ter uma medida do tempo e esforço que será gasto para se instalar e configurar um determinado tipo de honeypot. De maneira geral, quanto mais funcionalidades um honeypot provê, mais complexas são as atividades necessárias de instalação e configuração. Desenvolvimento e manutenção: é uma questão relacionada ao tópico acima. Quanto mais opções e serviços um honeypot provê, normalmente, mais tempo e recursos são necessários para desenvolver e manter este sistema. Coleta de informações: quanto maior a interação com o atacante que o honeypot permite, mais informações podem ser adquiridas. Nível de risco: um alto nível de interação proporcionado por um honeypot significa mais complexidade e pode resultar em um risco maior. Por exemplo, um honeypot que provê o

26 25 máximo de interação a um atacante pode ser usado indevidamente para atacar outros sistemas, sendo necessário, portanto, o uso de mecanismos que impeçam tais atividades. Nas subseções seguintes, serão apresentadas diversas classificações usadas na literatura corrente sobre honeypots, que usam como critério de diferenciação fatores como o nível de interatividade proporcionado, a estrutura, a finalidade de uso, a forma como se dá a interação com os atacantes ou alvos e a sua capacidade de adaptação ao meio Quanto ao nível de interatividade Os honeypots podem ser classificados quanto ao nível de interatividade proporcionado como de baixa, média ou alta interatividade, além dos honeytokens, um tipo especial de honeypot. Alguns autores(provos; HOLZ, 2007) preferem considerar apenas os honeypots como de baixa ou alta interatividade, enquanto outros também não citam os honeytokens. Para fins deste trabalho, preferiu-se apresentar os quatro tipos por questões de clareza, muito embora seja completamente justificável a divisão entre apenas as classes baixa e alta interatividade, por se tratarem das duas principais classes Honeypots de baixa interatividade Um honeypot de baixa interatividade fornece, como o próprio termo já apresenta, um nível de interação limitado entre os atacantes e o honeypot. Normalmente, ele tem por característica ser mais simples de instalar, configurar 3, desenvolver e manter, se forem comparados aos honeypots de alta interatividade. Um honeypot de baixa interatividade não é um sistema operacional real. Ele é meramente um programa que emula serviços e registra as conexões relativas a ele. Assim sendo, esse tipo de honeypot apresenta um risco muito pequeno, e de certa forma, pode-se relacionar baixa interatividade com o baixo risco oferecido às operações e recursos produtivos de uma determinada rede. Em contrapartida, existe a desvantagem de que as informações coletadas pelo honeypot são limitadas. Alguns determinados programas não são capazes de registrar mais do que o tempo e a data do ataque, endereço IP e porta de origem da conexão, endereço IP e porta de destino da conexão. Como o protocolo IP permite manipulação do cabeçalho dos pacotes, as únicas 3 O autor faz ressalvas a essa afirmação por ter encontrado dificuldades com a falta de documentação de algumas ferramentas quanto a sua instalação e devida configuração necessária para uso em determinados ambientes. :)

27 26 informações confiáveis em alguns casos sobre o atacante (sobretudo quando UDP é utilizado na camada de transporte) são o tempo e a data da tentativa de conexão. O principal objetivo dos honeypots de baixa interatividade é detectar tentativas de conexão não autorizadas. Como exemplos dessa classe de honeypots, pode-se citar LaBrea (LA- BREA, 2009), GHH (HONEYPOT, 2009b), Tiny Honeypot (HONEYPOT, 2009a), Deception Toolkit(TOOLKIT, 2009) Honeypots de média interatividade Um honeypot de média interatividade oferece um forma de interação mais rica do que a provida por honeypots de baixa interatividade mas não provêem qualquer sistema operacional real para o atacante. Esses falsos daemons são mais sofisticados e possuem maior conhecimento sobre os serviços específicos que eles fornecem. Teoricamente, um serviço emulado em um honeypot de baixa interatividade terá sua conexão com o atacante terminada depois de exibir um banner simples para se passar por um determinado serviço. Por sua vez, um serviço emulado em um honeypot de média interatividade pode responder a requisições e comandos realizados por um determinado atacante (WIR- CHERSKI, 2006). Na categoria de honeypots de média interatividade também se enquadram os honeypots que utilizam ambientes como jail ou chroot. Esses ambientes se comportam como um sistema operacional real, mas são fortemente controlados e monitorados pelo sistema operacional base. Esse tipo de honeypot não é muito empregado e normalmente são criados por indivíduos para atender a uma necessidade específica dos mesmos. Como pode-se perceber, a caracterização que alguns autores utilizam para justificar o título de honeypot de média interatividade trata-se de uma tentativa de encontrar um meio termo entre os sistemas muito básicos (alguns tipos de honeypots de baixa interatividade) e os sistemas reais (alta interatividade). Entretanto, grande parte dos autores preferem apenas diferenciar honeypots de alta e baixa interatividade, incluindo os que seriam de média interação, segundo determinado critério ou visão, no grupo dos de baixa interatividade. Essa abordagem de divisão entre apenas honeypots de baixa e alta interação é a que será utilizada nos próximos capítulos deste trabalho.

28 Honeypots de alta interatividade Os honeypots de alta interatividade podem fazer qualquer coisa que é permitido fazer com um sistema real. Eles normalmente são sistemas computacionais convencionais, como um computador comum (COTS - commercial off-the-shelf), um roteador, um switch, etc. Atacantes que invadem ou tem acesso a um honeypot de alta interatividade operam um sistema operacional real e isso significa que nenhum serviço, funcionalidade ou parte do sistema operacional é emulada. Tal abordagem possui a vantagem de que muito mais informações e de maior granularidade podem ser obtidas do atacante. Mais informações também significam uma análise mais abrangente de determinado ataque, sendo que o principal propósito desse tipo de honeypot é aprender as técnicas e motivações dos atacantes (possivelmente servindo de base para um trabalho de pesquisa sobre determinada ameaça). Por outro lado, a principal desvantagem em relação a esse tipo de honeypot é maior risco associado a ele. Como os atacantes atuam sobre um sistema real, eles são capazes de fazer mal uso do sistema e atacar sistemas em produção de uma determinada rede local ou externa. Um firewall que bloqueia todo o tráfego do honeypot pode resolver o problema, mas mesmo assim o risco permanece, uma vez que técnicas talvez desconhecidas possam ser usadas para furar esse bloqueio. Atualmente, vem-se empregando ambientes de virtualização de sistemas operacionais como VMWare (VMWARE, 2009), User-Mode-Linux (UML) (LINUX, 2009) e Argos (PORTOKALIDIS, 2009) (usando QEMU (QEMU, 2009)) para a utilização de honeypots de alta interatividade. O Honeynet Project também disponibiliza um sistema de honeypot de alta interatividade chamado Honeywall e a Symantec possui um produto chamado Symantec Decoy Server, também conhecido como ManTrap Honeytokens Uma forma simples e especial de honeypots são os honeytokens, descritos por Lance Spitzner em Honeytokens: The Other Honeypot (SPITZNER, 2007). Segundo Spitzner, uma das más concepções que são feitas sobre honeypots é que eles precisam ser um computador ou algum recurso físico para que o atacante interaja com eles. Esta, de fato, é a manifestação mais tradicional dos honeypots, mas não é a única. Um honeypot precisa apenas ser um recurso computacional com o qual os atacantes possam interagir. Um token nesse contexto significa um arquivo, uma planilha, uma apresentação ou qualquer

29 28 artefato do mundo real (como um registro médico em um banco de dados). Os honeytokens são usados para detectar acesso não autorizado a um recurso. Um hospital, por exemplo, pode gerar um honeytoken inserindo um falso registro médico de uma pessoa fictícia no bando de dados. Se o registro for acessado, poderia-se então assumir que alguém está coletando dados sobre os quais não tem autorização para manipulá-los Honeypots de baixa versus honeypots de alta interatividade Os honeypots de baixa e alta interatividade possuem diferentes características que permitem que um ou outro se adequem melhor aos objetivos que desejam ser alcançados em decorrência de sua implantação. Ao delinear esses objetivos, o administrador da rede deve estar atento a diferentes fatores não somente técnicos mas também econômicos (custos). Um ponto importante é o tipo da informação que deseja ser coletada. Os honeypots de baixa interatividade produzem logs limitados, mas que ao mesmo tempo podem ser especializados em realizar uma determinada tarefa, como a detecção e captura de worms e bots. Se esse for o intuito do administrador da rede, então esse honeypot se adequa bastante bem às suas necessidades. Por outro lado, se o administrador pretende obter informações sobre ataques desconhecidos a sistemas operacionais reais é recomendado, nesse caso, um honeypot de alta interatividade, pois as informações por ele coletadas permitem uma análise mais completa do incidente. Alguns honeypots de baixa interatividade permitem a detecção de ataques desconhecidos, mas a fazem de forma limitada, o que pode dificultar um trabalho de análise mais elaborado. Também deve-se levar em consideração se a equipe que administrará o honeypot possui o nível de conhecimento e experiência necessários para operar um determinado tipo de honeypot. Os honeypots de alta interatividade normalmente demandam mais tempo e dedicação dos administradores para o acompanhamento e análise dos incidentes. Por sua vez, esses incidentes podem ter as mais variadas naturezas, o que pode exigir um nível elevado de conhecimento da equipe responsável por sua análise. Já os honeypots de baixa interatividade, por proverem informações limitadas em algum aspecto, não requerem que os administradores de honeypots tenham alto nível técnico. Se for desejado utilizar honeypots de alta interatividade, mas a equipe que será responsável por eles não possuir experiência e conhecimentos necessários, começar o trabalho com os de baixa interatividade pode ser um bom ponto de partida para a ambientação com a tecnologia de honeypots, além de estar sujeito a menores riscos do que em relação à utilização de honeypots

30 29 de alta interatividade. Talvez pela falta de equipes qualificadas, os honeypots de alta interatividade normalmente não estão presentes em organizações cujos negócios não envolvem diretamente segurança de redes. Assim, eles são mais frequentemente encontrados em universidades e fabricantes de anti-vírus e outros produtos ligados a área de segurança de rede. Em relação aos aspectos econômicos, os honeypots costumam requerer poucos recursos computacionais, se comparados a outras soluções como IDS, análise de fluxos, etc. Entretanto, em quase todos os ambientes, os custos necessários à instalação, configuração, operação e manutenção também devem ser obrigatoriamente analisados. Nesse caso, um honeypot de baixa interatividade costuma apresentar custos menores em relação aos honeypots de alta interatividade. Uma discussão sobre esses custos será realizada na seção Tanto honeypots de baixa como os de alta interatividade podem ser detectados usandose, é claro, diferentes técnicas. Uma suscinta discussão a respeito das formas de detecção de honeypots é feita na seção 2.6. Por último, honeypots de baixa e alta interatividade podem ser combinados em uma determinada arquitetura de maneira a ser formar arquiteturas de honeypots híbridos (PROVOS; HOLZ, 2007) Quanto a estrutura Os honeypots também podem ser classificados quanto a estrutura computacional que utilizam, sendo neste caso divididos entre honeypots físicos e virtuais Honeypots físicos Os honeypots físicos são aqueles que rodam em uma máquina física diretamente. Ser um honeypot físico implica em ser de alta interatividade, portanto permitindo que o sistema possa ser completamente comprometido. Eles são tipicamente custosos principalmente quanto a instalação e manutenção. Para grandes espaços de endereçamento de rede, é impraticável ou impossível construir uma estrutura baseado em honeypots físicos, cada um com um endereço IP específico. Neste caso, os honeypots virtuais são mais indicados.

31 Honeypots virtuais Os honeypots virtuais são aqueles na qual o honeypot não executa diretamente sobre o hardware da máquina física (via sistema operacional da máquina hospedeira). Isso compreende os honeypots de alta interatividade que executam sobre ferramentas de virtualização como VMWare, Xen, User Mode Linux, etc. e os honeypots de baixa interatividade, que, por natureza, apenas emulam determinadas partes de um sistema operacional real (como a pilha de rede IP de um sistema) Honeypots físicos versus honeypots virtuais Comparando os dois tipos de honeypots, é possível perceber que os virtuais possuem algumas vantagens sobre os honeypots físicos. Uma delas é o fato de que honeypots virtuais são menos custosos e mais fáceis de manter. A principal economia de recursos é o fato de que usando a abordagem de honeypots virtuais, várias máquinas podem ser executadas usando apenas uma máquina física. Isso também permite que múltiplos sistemas operacionais e suas aplicações possam rodar concorrentemente, aumentado as possibilidades de recebimento e estudo de ataques. Os honeypots virtuais também podem ser usados com maior vantagem em ambientes que utilizam NAT. Neste caso, determinados tráfegos de rede, vindos (por exemplo) da Internet, podem ser redirecionados para honeypots que tratam distintos tipos de tráfego. Por outro lado, nem sempre é possível utilizar honeypots virtuais, principalmente quando eles são de alta interação. Isso porque dependendo das máquinas disponíveis para rodá-los, não é possível executar satisfatoriamente determinados tipos de ferramenta de virtualização pelo fato das máquinas não atenderem aos requisitos mínimos solicitados pela aplicação Quanto a finalidade Lance Spitzner cita em (COMMUNITY, 2001) que os honeypots podem ser classificados de acordo com a sua finalidade. De fato, dependendo do seu tipo, eles acrescentam valor e reduzem o risco associado a segurança da rede de diferentes maneiras. Também Joho (JOHO, 2004) defende que a importância dos honeypots pode ser melhor verificada se eles forem separados em duas categorias: honeypots de produção e honeypots de pesquisa.

32 Honeypots de pesquisa A falta de informações sobre atacantes, seus procedimentos e ferramentas usadas é um grande problema para a indústria de segurança da informação. De fato, é díficil proteger sistemas se o inimigo ou ameaça não são conhecidos. Se um sistema é comprometido, os blackhats frequentemente deixam suas ferramentas usadas na máquina; o que permite que profissionais de segurança as examinem. Um honeypot de pesquisa auxilia consideralmente nessas atividades de estudos, permitindo seguir um ataque passo a passo desde o início até sua conclusão. Normalmente, honeypots de pesquisa são de alta interatividade. Para obter as informações do atacante, eles registram todos os eventos de um sistema, as aplicações instaladas e as teclas digitadas pelo atacante. Essa estratégia previne o atacante de tentar esconder os vestígios de suas ações. É também perceptível que honeypots de pesquisa não reduzem o risco a que está exposta a organização que os abriga. Eles podem até aumentar esse risco se não forem operados e protegidos de forma correta, mas de forma geral, apresentam os mesmos riscos aos quais estão estão expostas as máquinas de produção (KAâNICHE et al., 2006). Os honeypots de pesquisa normalmente são utilizados no ambiente acadêmico ou por organizações diretamente ligadas ao setor de segurança da informação. O Projeto Honeynet 4 é um exemplo de uma comunidade que utiliza-os para obter um melhor conhecimento sobre incidentes de segurança. Martin Roesch, criador do Snort IDS 5, define esse tipo de honeypot como uma plataforma para estudar ciber-ameaças e entender as ações da comunidade blackhat, portanto, tornandose uma ferramenta educacional ou acadêmica Honeypots de produção Um honeypot de produção é um sistema que reduz o risco associado a uma rede. Assim, um honeypot de produção normalmente é de baixa interatividade, usado para coletar dados sobre ataques específicos e não permitindo ao atacante a possibilidade de atacar outras máquinas a partir do honeypot atacado. Martin Roesch define honeypots de produção como sistemas que auxiliam a mitigar riscos associados a rede em uma organização, tendo uma importância específica nas tarefas de

33 32 prevenção, detecção e resposta a ataques. Ele defende também que os honeypots podem ser poderosas ferramentas para complementar a capacidade de reação de um administrador de rede, capturando detalhes precisos sobre como o atacante chegou até a máquina e o que ele fez Quanto ao modo de comunicação Outra uma classificação existente faz a diferenciação entre os honeypots pela forma como eles interagem com os atacantes ou agentes maliciosos. Dentro desta abordagem, existem os honeypots tradicionais (server side) e os honeypots clientes (client honeypots) Honeypots tradicionais Os honeypots tradicionais são aqueles que disponibilizam serviços e informações esperando pelo contato dos atacantes. Esse tipo de abordagem é a tradicional, onde o honeypot se comporta como um servidor. Logo, o principal objetivo desse tipo de honeypot é entender e obter informações sobre ameaças da rede que incidem sobre os servidores, não sendo totalmente apropriado para investigar ataques que ocorrem do lado cliente da comunicação. Todos os honeypots usados durante as experimentações deste trabalho são considerados honeypots tradicionais. Assim, pode-se citar como representantes dessa classe o Honeyd, Nepenthes, Honeytrap, Amun(honey), LaBrea, Tiny Honeypot, Honeywall (do Projeto Honeynet), Argos, etc Honeypots clientes (client honeypots) Os honeypots clientes são aqueles que iniciam a comunicação com os atacantes ao invés de tomarem uma postura passiva típica dos honeypots tradicionais. Para isso, eles procuram por servidores maliciosos que provêem códigos maliciosos que quando executados atacam máquinas clientes. Um honeypot cliente se passa por um cliente comum de determinado serviço ou aplicação e interage com o servidor de maneira a examinar se um algum código malicioso é enviado pelo servidor ao cliente. Essa abordagem é útil para examinar falhas em navegadores web (web browsers) e também nas aplicações que rodam dentro do navegador (como Flash e outros plugins). Embora sua utilização atual seja voltada para a web, nada impede que a mesma estratégia seja utilizada para verificar as ameaças a que estão expostos clientes de , FTP, etc.

34 33 A arquitetura mais comum dos honeypots clientes pode ser genericamente dividida em três componentes: o enfileirador (queuer), o módulo de requisição e o módulo de análise. O enfileirador é responsável por criar uma lista com os servidores que o cliente deve visitar. Essa lista pode ser criada a partir de varredura em ferramentas de busca disponíveis na web ou atráves da passagem manual da lista dos servidores a serem visitados. Por sua vez, o componente de requisição é responsável por fazer o processo de requisição (e de dar eventuais respostas) ao servidor. Por fim, normalmente após a interação, o componente de análise é responsável por determinar se uma dada interação tratou-se de um ataque ou não. Honeypots clientes podem ser tanto de alta interatividade (como o Capture-HPC 6, Honey- Client (PROJECT, 2009), HoneyMonkey (MICROSOFT, 2009), Shelia (SHELIA, 2009), Web Exploit Finder (XNOS.ORG, 2009)) ou de baixa interatividade (como o HoneyC 7, Monkey-Spider (MONKEYSPIDER, 2009), SpyBye (PROVOS, 2009)) Quanto a adaptabilidade Os honeypots também podem ser classificados quanto a sua capacidade de adaptação ao ambiente em que estão integrados ou ao tipo de atacante que se comunica com ele. Dessa forma, os honeypots podem ser divididos em estáticos (também denominados por alguns autores de passivos) e dinâmicos (também chamados por alguns autores de ativos) Honeypots estáticos Os honeypots estáticos (ou passivos) são aqueles que não possuem capacidades de se adaptar ao meio em que estão integrados ou do tipo de atacante que se comunica com ele. Ou seja, uma vez feita a sua configuração não é possível fazer com que ele mude algumas de suas características ou até mesmo que tome medidas para acionar outros elementos como firewalls, atualizações de regras de IDS, etc Honeypots dinâmicos Os honeypots dinâmicos (ou ativos), diferentemente dos passivos, podem mudar suas características em função do ambiente. Idealmente, esses honeypots geram uma configuração que é produzida de forma a satisfazer os atacantes. Assim, eles também tem por objetivo induzir os

35 34 atacantes a gastarem mais tempo dentro do honeypot. Conceitualmente, honeypots dinâmicos podem também fazer a manipulação automática de incidentes ou a resposta automática a ataques (possivelmente acionando outros dispositivos ativos da rede). Honeypots dinâmicos que desempenham estas características apresentam algumas dificuldades para sua implementação no mundo real, Joho (JOHO, 2004) discute esses aspectos em sua tese. Entretanto, segundo ele, esse tipo de honeypot poderia ser útil em ambientes de pesquisa quanto à formação de um banco de dados de incidentes e também para estudos de avaliação de atratividade de determinadas configurações e os riscos envolvidos. 2.4 Custos e benefícios relacionados aos honeypots Conforme já citado, embora um honeypot não possa prover segurança adicional por si só (normalmente são usados como fontes de informação para ajuste de outros elementos da rede, ou seja, aumentam o nível de segurança de forma indireta), eles possuem algumas vantagens que justificam o seu uso Vantagens A primeira vantagem que se pode citar é o valor dos dados (relacionado à qualidade e a importância) que podem ser coletados por um honeypot. Toda infra-estrutura computacional contém muitas fontes de dados, que por sua vez fornecem ou coletam grandes quantidades de informações. De fato, cada serviço e cada máquina possuem seus próprios arquivos de log que informam sobre os mais variados tipos de eventos. Frequentemente, isso implica em uma situação em que muitas organizações não apresentam competência para transformar os dados brutos em informação, porque elas estão sobrecarregadas por um número inacreditavelmente grande de eventos comunicados e a serem analisados. Honeypots, por sua vez, coletam pouca informação (em relação ao tráfego total da rede e ao número de acões que nela ocorrem). Além disso, essas informações possuem grande valor, pois não é necessário classificar o tráfego entre normal ou malicioso simplesmente porque honeypots não deveriam receber tráfico normal ou produtivo, de forma que cada conexão ao sistema é considerada uma evidência de um ataque. Um segundo ponto positivo dos honeypots é que, de modo geral, não necessitam da alocação de muitos recursos. Por consequência, dificilmente apresentam problemas com exaustão de

36 35 recursos. De fato, honeypots podem ser instalados em máquinas que não se adequam mais para a utilização em serviços de produção, mas que podem ser muito úteis para a detecção de ataques na rede quando utilizadas como honeypots. Outra vantagem dos honeypots é a sua simplicidade. Vários tipos de honeypots não requerem configurações complexas. Em algumas situações, basta colocar um sistema de forma passiva para capturar algum tráfego suspeito e poder analisá-lo posteriormente. Também, eles podem ser utilizados para justificar determinados investimentos na área de segurança da informação. É realmente díficil mensurar fatores como retorno de investimento (ROI), muito empregado em relação a investimentos gerais de uma empresa, para justificar monetariamente um determinado investimento que promete mitigar determinada ameaça na rede. De fato, uma organização que tem a impressão de estar sendo bem protegida por determinadas tecnologias pode ser convencida das ameaças a que sua rede está exposta a partir da implantação de honeypots para monitorar a rede. Dessa forma, os honeypots podem ser uma forma prática de justificar determinados investimentos em tecnologias de segurança de redes (DORN- SEIF; GARTNER; HOLZ, 2004) Custos Embora os pesquisadores e profissionais de segurança proclamem que os honeypots são uma solução barata e pouco custosa, deve-se também analisar mais minuciosamente os custos associados a sua utilização. Nesta análise, eles foram divididos em dois grupos: custos de desenvolvimento e custos de manutenção Custos de desenvolvimento O primeiro custo que pode ser analisado é o custo de desenvolvimento inicial do honeypot, que compreende os passos referentes a sua compra, instalação e configuração. Comprar um honeypot pode não significar apenas comprar algum pacote de software. Em alguns casos, deve ser considerado também a compra do hardware necessário para abrigá-lo. Felizmente, os requisitos de sistema necessários para a grande parte dos honeypots são modestos. Portanto, em alguns casos, pode-se usar um hardware que seria descartado para a execução de determinados serviços da rede de produção, mas que pode ser usado tranquilamente para abrigar um honeypot. Alguns ambientes de honeypots físicos e de alta interatividade podem precisam de alguns dispositivos adicionais para proteger os outros sistemas de ataques originados a partir dos honeypots quando comprometidos. Para separar o honeypot dos sistemas de produção, dispositivos

37 36 como firewall, switches ou roteadores podem ser necessários. Ou seja, a utilização de honeypots físicos e de alta interatividade aumenta o custo de desenvolvimento do ambiente, motivo pelo qual os honeypots virtuais e/ou de baixa interatividade tem ganhado espaço atualmente. Com relação ao software, os custos referentes a sua aquisição podem variar porque existem tanto soluções de código aberto (open source) quanto proprietárias. Comprar uma licença para rodar um único honeypot pode ser um gasto negligenciável em muitos casos, mas quando pretende-se usar vários honeypots em um mesmo ambiente, esse custo pode ser bastante relevante em relação ao orçamento destinado ao projeto. Nesse contexto (e felizmente), as ferramentas de software livre podem ser usadas satisfatoriamente. Na realidade, as ferramentas opensource disponíveis são suficientes para a implantação de honeypots em a quase a totalidade dos ambientes, permitindo, se desejado, que várias dessas ferramentas sejam combinadas. Mesmo para os honeypots de código aberto, existe o custo de configuração dos ambientes para que possam atender a uma determinado objetivo. Os honeypots de baixa interatividade costumam ser mais fáceis de configurar do que os de alta interatividade Custos de manutenção Após as fases de compra, instalação e configuração (fase de desenvolvimento do ambiente), existe também o custo de manutenção do ambiente. Esse tipo de custo é muito mais díficil de ser estimado que os custos de desenvolvimento. Naturalmente, os benefícios dos honeypots dependem de sua manutenção, e estes gastos ocorrem todo mês, e podendo, em alguns casos, aumentarem durante o tempo; por isso, precisam ser um fator a ser levado em consideração pelo responsável do projeto. Os custos de manutenção consistem de diferentes componentes. Um deles é o custo de observação do honeypot, que compreende o tempo no qual o administrador está checando o funcionamento do sistema. Outro é custo de restauração do honeypot, que abrange o esforço que será feito para reinstalar ou limpar o sistema após o seu comprometimento pelos atacantes. Por fim, o custo da análise dos incidentes é considerado o terceiro e mais importante componente. A começar pelo custo de observação dos honeypots, é fácil entender que, idealmente, os administradores deveriam sempre estar atentos as ações executadas pelo honeypot. Esse processo é muito importante, porque cada incidente que permanece indetectado apresenta um risco de segurança para a rede. Conforme já explicitado, um atacante pode fazer mal uso do honeypot para atacar outros sistemas e se os administradores (ou a ferramenta utilizada) não estiverem atentos, ele pode ten-

38 37 tar apagar os vestígios de sua ação, normalmente apagando arquivos ou todo o sistema. E ainda que o honeypot possa registrar todos os eventos em um servidor remoto, arquivos importantes poderão ser destruídos (o que pode inviabilizar determinadas análises ou incrementar os custos da análise do incidente). O custo de observação também varia em relação ao tipo de honeypot que é usado. Um honeypot de baixa interação, como o Honeyd, pode ser verificado semanalmente, por exemplo, sem que isso signifique um risco para a segurança da rede. Honeypots de baixa interatividade proporcionam poucas opções aos atacantes e, por isso, muito raramente são comprometidos a tal ponto de serem utilizados como bases de ataques para outras máquinas. Por sua vez, um honeypot de alta interatividade requer muito mais esforço com relação a tarefa de observação. Neste caso, um atacante que invadí-lo operará sobre um sistema real e poderá causar muito estrago se ele não estiver devidamente bem configurado. Por isso, é interessante que o incidente seja notado enquanto o atacante ainda está ativo no honeypot. Dentro desse contexto, muitas soluções envolvendo honeypots de alta interatividade incluem algum mecanismo para alertar os administradores de um incidente. O lado ruim disso é que eles podem ser alertados dezenas de vezes por dia, o que pode ser equivalente a sempre estar verificando o que acontece no sistema para que seja possível desconectar o honeypot da rede antes do intruso ser capaz de apagar seus vestígios. Quanto aos custos de restauração, eles são relevantes principalmente em honeypots físicos e de alta interação. Ao terem acesso ao sistema operacional da máquina alvo, os atacantes, por exemplo, frequentemente instalam backdoors para permitir mais fácil acesso à máquina comprometida no futuro. Esse é um dos motivos que justificam a importância de restaurar um honeypot após um incidente. Uma maneira de fazer isso é reinstalar o sistema completamente, o que garante que todos os backdoors de atacantes anteriores sejam removidos e que o sistema volte ao estado padrão. Esse procedimento é seguro, mas também pode ser muito custoso do ponto de vista operacional. Para restaurar um honeypot de alta interatividade de forma mais conveniente, é aconselhável a utilização de honeypots virtuais com a ajuda de ambiente de virtualização ou emulação como Xen, VMWare, UML, QEMU, etc. Assim, com uns poucos comandos (ou cliques) depois do incidente, o honeypot virtual poderá estar operando novamente. Outro custo que deve ser considerado é o de análise dos incidentes, existente principalmente para os honeypots de alta interatividade. Na prática, fazer uma investigação abrangente dos incidentes é um processo bastante custoso, especialmente quando os atacantes usam ferramentas e técnicas até então desconhecidas (PROJECT, 2000).

39 38 Para se ter uma idéia, em 2001, o Honeynet Project lançou um desafio de análise forense (Forensic Challenge), colocando uma imagem de um sistema comprometido disponível no site da organização. O objetivo era permitir que investigadores de incidentes do mundo inteiro pudessem ver os mesmos dados e que informações sobre o ataque poderiam ser inferidas. O sistema comprometido era uma instalação padrão do então Red Hat Linux 6.2 Server. Dados adicionais do Snort também foram fornecidos. Todas as submissões dos participantes deveriam, por regra, incluir uma estimativa do tempo gasto no desafio. Os resultados dos participantes mostraram que eles empreenderam muitos esforços para analisar o sistema comprometido. Embora as equipes tenham sido bem sucedidas em desvendar o ataque, cada uma delas encontrou, no mínimo, um aspecto que não foi observado pelos outros (o que serve como prova prática que em análise forense de sistemas computacionais não existe análise de incidentes perfeita, porque tempo é um fator limitante). Os participantes gastaram, em média, 46 horas na análise desse caso. Ou seja, eles trabalharam por mais de uma semana para analisar o que o intruso fez em meia hora (tempo do ataque). Então, considerando que as organizações detectam dezenas de eventos similares em poucos meses, fica evidente que os custos de análise dos incidentes é bastante considerável. Talvez, a quantidade de dinheiro necessária para uma investigação aprofundada de um incidente seja a principal razão para que os honeypots de alta interatividade não sejam largamente utilizados nas organizações em geral, pois pode ser impossível justificar junto a gerência de TI a reserva de um grande montante de investimento para a realização dessas atividades. 2.5 Questões legais relacionadas aos honeypots Como já discutido anteriormente, os honeypots de alta interatividade podem apresentar algum risco se um determinado atacante conseguir comprometer algum deles e usá-lo para iniciar ataques contra redes que podem possuir sistemas críticos e que podem estar localizadas em qualquer lugar na Internet. Tal situação implica em algumas questões legais, que podem se aplicar em determinados países sobre a utilização de honeypots. Um provedor de serviços de Internet pode, por exemplo, proibir explicitamente que um sistema de honeypot seja mantido em um de seus endereços IP ou, pelo menos, que o cliente garanta que outras máquinas não serão comprometidas. Uma outra questão importante existente em muitos países é o direito à privacidade. Deve-se, portanto, estar atento a como será feita a manipulação dos dados obtidos por meio do honeypot e a forma de divulgação das mesmas (SPITZNER, 2003).

40 39 Os atacantes podem usar o honeypot para qualquer atividade maliciosa ou ilícita. Por exemplo, um honeypot que disponibilizar um servidor web para ser atacado, deve monitorá-lo de forma que o mesmo não seja usado para armazenar conteúdos ilícitos (como informações bancárias de terceiros, pornografia infantil, etc.) sob o risco de responder pela veiculação desse conteúdo dependendo das leis vigentes no país em questão (LEE; NAM, 2007). Por outro lado, honeypots podem ser usados a favor das autoridades policiais. O projeto francês Antipaedo (LAPATY, 2008) utiliza uma abordagem baseada em honeypots para gerar conteúdo atrativo (mas falso) em redes P2P (peer-to-peer) para os pedófilos. Assim, autoridades podem rastrear os interessados nesse tipo de conteúdo e desmontar parte das redes de pedofilia e pornografia infantil. É importante dizer também que atividades maliciosas na Internet movimentam um mercado negro mundial, composto por desenvolvedores e administradores de bots, spammers, etc. Esses aspectos são abordados em artigos como o de Holz (HOLZ et al., 2008), o que mostra que as informações sobre a forma de atuação da comunidade blackhat obtidas por meio de honeypots são essenciais para o entendimento de como comportam-se ou organizam-se esses grupos no mundo real. Com relação a utilização de honeypots no Brasil, um dos projetos de maior destaque é o Projeto Honeypots Distribuídos que envolve várias organizações que possuem honeypots instalados em suas redes sob a administração central do CERT.br 8. Dentre as organizações participantes existem várias universidades federais e até órgãos ligados ao poder judiciário brasileiro. Atualmente, não existe ainda uma lei específica para crimes de Internet no Brasil, entretanto, o administrador de um honeypot deve estar atento às suas responsabilidades em caso de mal uso do recurso pelo atacante. A inexistência de uma lei específica para o assunto não significa que não possa haver consequências legais, uma vez que determinados atos podem ser enquadrados em leis de crimes com um contexto mais geral ou relacionado. 2.6 Questões relacionadas a detecção de honeypots Como discutido anteriormente, os honeypots estão sujeitos a alguns riscos e um deles é o de serem detectados. Ao detectar um honeypot, o atacante pode tomar diversas atitudes. Uma delas poderá ser evitar uma interação com o honeypot já devidamente reconhecido. Uma outra tática poderia ser interagir com o honeypot e poluí-lo com informações falsas ou incoerentes, dificultando o trabalho de análise de dados do incidente. Também, um atacante poderia ao 8

41 40 detectar o honeypot, tentar apagar todas as evidências de suas ações anteriores na máquina. Essas são apenas algumas das alternativas possíveis de ação dos atacantes ao perceberem a existência de um honeypot. Para honeypots de baixa interatividade seria importante então a possibilidade de enganar ferramentas automáticas como scanners de rede (o Nmap, por exemplo); e para honeypots de alta interatividade, estar o mais próximo possível de um ambiente de sistema operacional comum. Mas apenas essas características podem não ser suficientes para evitar a detecção dos honeypots a partir de outras técnicas. Honeypots de baixa interatividade são comumente mais fáceis de serem detectados por atacantes humanos, por normalmente proverem poucos recursos em relação a ambiente de um sistema operacional real. Mesmo assim, são ferramentas adequadas para capturar ataques automatizados ou mesmo de atacantes com pouca experiência. Nesse cenário, os atacantes poderiam, ao lançarem suas ferramentas automatizadas, fazer determinadas verificações de indícios de presença de honeypot em um determinado alvo. O Honeyd, um honeypot de baixa/média interatividade bastante conhecido, poderia ser detectado se estiver rodando algum de seus scripts padrão. Se o script, por exemplo, que emula um servidor de SMTP falso estiver rodando, basta que o atacante verifique se determinadas funcionalidades do falso servidor SMTP, e que são normalmente encontradas em servidores legítimos, não estão implementadas. Outra forma de detecção poderia se dar por meio da disponilização de serviços incoerentes com a plataforma base em que está instalado o honeypot de baixa interatividade. Pode ser fácil identificar, por exemplo, que há algo errado quando um sistema Linux está rodando um IIS ou Active Directory 10. Alguns honeypots também ao serem executados deixam muitas portas abertas ao mesmo tempo, como é o caso do Nepenthes e Amun, honeypots especializados na captura de malwares, que podem utilizar mais de 20 portas diferentes para tentar coletar diferentes tipos de worms que vagam pela rede explorando vulnerabilidades em diferentes portas. Assim, uma ferramenta automatizada poderia fazer uma contagem do número de portas abertas no alvo e se elas ultrapassassem um determinado limiar o ataque seria abortado ou um aviso de possível honeypot existente no alvo poderia ser exibido. Embora possa ser possível fazer a verificação por alguma dessas características, a boa notícia é que elas muito raramente são realizadas. Não foram encontrados registros de worms 9 Servidor Web da Microsoft. 10 Serviço de diretórios de sistemas Windows.

42 41 que verificam se um número grande de portas estão abertas e, caso estejam, abortem o ataque por receio da existência de um honeypot. Ferramentas automáticas de envio de spam também não verificam pela falta de funcionalidades em servidores SMTP falsos, simplesmente tentam enviar seus s. Talvez a falta de ações desse tipo decorram do fato de que elas podem ser um pouco custosas em alguns casos. Até mesmo atacantes com pouca experiência, ao entrarem em honeypots de baixa interatividade a partir da execução de exploits e encontrarem um ambiente com poucas opções, podem pensar que se trata de um ambiente controlado ou mesmo simplesmente saírem frustados sem executarem maiores ações. No caso de honeypots de alta interatividade, a detecção poderá acontecer a partir da verificação de alguma mudança em relação ao sistema operacional padrão. Um exemplo é a arquitetura de honeypots de alta interatividade Honeywall disponibilizada pelo Honeynet Project. Essa arquitetura possui um componente chamado Sebek, que é um módulo de kernel Linux que é responsável por capturar os eventos a nível de sistema do honeypot. Por padrão, o Sebek permanece oculto e não é detectável por um simples lsmod, comando responsável por listar os módulos de kernel ativos. Em versões anteriores do Honeywall e Sebek, uma vulnerabilidade permitia que o módulo Sebek fosse detectado como presente na memória principal a partir da execução de um exploit. Embora essa vulnerabilidade não esteja mais presente em versões atuais, tal fato mostra que podem existir muitas maneiras de se detectar um honeypot. Um outra questão interessante quanto a detecção diz respeito aos honeypots virtuais. Ambientes de virtualização, como VMWare, Xen, UML, VirtualBox, QEMU, podem ser detectados a partir de algumas características de sua execução, normalmente relacionadas a instruções específicas ou emulações necessárias que são por elas executadas. A alguns anos atrás, tecnologias de virtualização ainda não estavam tão disseminadas e poderiam apontar o indício da existência de um honeypot, simplesmente por estarem rodando em máquinas virtuais. Provos e Holz(PROVOS; HOLZ, 2007), por exemplo, dão dicas de como máquinas virtuais podem ser detectadas. Hoje, porém, é quase impossível inferir que uma máquina trata-se de um honeypot por apenas estar rodando dentro de ambiente de virtualização, uma vez que esses ambientes já estão se tornando bastante comuns em servidores de produção. De modo geral, os administradores de honeypots devem estar atentos às formas de detecção que cada tipo de honeypot que for instalado está sujeito e tentar minimizar as características que possam levar a uma fácil detecção por parte dos atacantes, nos casos em que isso for possível.

43 2.7 Usos e trabalhos relacionados a tecnologia de honeypots 42 A tecnologia de honeypots vem sendo empregada em diversos contextos relacionados a segurança de redes. Nessa seção, serão exemplificados alguns usos mais comuns dessas ferramentas Mitigação dos problemas de spam e rastreamento de spammers Spam (também conhecido como Unsolicited Bulk (UBE) e Unsolicited Commercial (UCE)), embora não seja classificado como um ataque, talvez seja o que mais polui o tráfego da Internet no mundo, afetando todos que usam serviço de . Essas mensagens normalmente são enviadas por profissionais (os conhecidos spammers) que são pagos para espalhar mensagens a destinatários aleatórios, gerando um mercado negro para a negociação desses serviços. Normalmente, eles usam hardware de terceiros para suas atividades, utilizando sem permissão sua banda e outros recursos para o envio dessas mensagens. Spammers utilizam principalmente relays e proxies abertos para o envio de spam. Relays abertos são MTAs (Mail Transfer Agents) que aceitam repassar mensagens de de terceiros mesmo que elas não sejam destinadas ao seu próprio domínio. Normalmente tratam-se de servidores SMTP pouco ou mal configurados. Por causa dessa facilidade, spammers usam esses servidores como rota de envio de grandes quantidades de s não solicitados. Atualmente, existe um número cada vez menor de servidores de conhecidos que tem como configuração padrão o comportamento como um relay aberto. Por isso, os atacantes usam outras alternativas, como os proxies abertos. Um proxy aberto é um servidor proxy disponível para o mundo externo e que podem manipular praticamente qualquer tipo de requisição (ou seja, são proxies mal configurados). Servidores de proxy bem conhecidos são SOCKS (normalmente disponível na porta 1080/TCP), Squid Proxy (normalmente na porta 3128/TCP) e o serviço de cache web (normalmente na porta 8080/TCP). Os proxies abertos permitem que spams sejam enviados de forma praticamente anônima, principalmente quando uma cadeia de proxies é utilizada. Alguns worms possuem servidores proxies abertos embutidos, possibitando o envio de a partir dos mesmos. Se por um lado alguns poucos lucram com essa atividade, de outro, organizações do mundo inteiro sofrem perdas milionárias devido a alta quantidade de spams que enchem as suas contas de . Essas organizações tem tomado medidas para prevenir a propagação de spams e

44 43 impedir que as pessoas disperdicem seu tempo manipulando mensagens não requisitadas. Organizações que retransmitem spams, por vontade própria ou não, são colocados em blacklists como a RBL (Realtime Block List) ou a CBL (Composite Blocking List). Um provedor de serviços de internet (ISP) ou organização empresarial que possui um IP de seu servidor presente em uma lista negra por um longo tempo pode receber muitas reclamações de seus usuários com relação a qualidade dos serviços e até afetar a reputação da organização, refletindo em perdas financeiras futuras. Neste contexto, honeypots podem ser úteis na luta contra os spammers como descrito por Laurent Oudot no artigo Fighting Spammers with Honeypots (OUDOT, 2003), ajudando a frustá-los durante suas atividades. Eles podem ser usados para simular relays ou proxies abertos e permitir que spams e suas rotas sejam capturados bem como seus padrões de comportamento. Essas informações podem inclusive alimentar blacklists. Outra alternativa é usá-los para enfileirar todos os s que chegarem, sem enviar nenhum deles. Uma outra estratégia é tornar a comunicação entre a máquina spammer e o honeypot tão lenta (usando mecanismos de janela do TCP), que praticamente nenhum spam conseguirá ser enviado ao honeypot e ainda estará bloqueando um recurso da máquina de origem da atividade maliciosa. Abordagens mais atuais para o cenário brasileiro são propostas por Pedro Guerra et al.(guerra et al., 2008) e Klaus Steding-Jessen et al. (STEDING-JESSEN; VIJAYKUMAR; MONTES, 2008) a partir dos dados coletados por honeypots de baixa interação (no caso, o Honeyd) espalhados por várias redes do país. O primeiro trabalho busca maneiras de identificar e possivelmente bloquear spams o mais próximo possível de sua origem a partir de estratégias baseadas nos padrões de comportamento dos spammers, evitando consumo desnecessário de recursos. O segundo trabalho, por sua vez, busca caracterizar as principais redes de origem dos spams, portas utilizadas, etc. com o objetivo de fornecer informações técnicas que possam auxiliar os administradores de rede no combate aos spams Detecção de malwares e botnets Malwares são softwares desenvolvidos com o propósito de trazer dano a um sistema computacional; tal classificação inclui termos como vírus, worms, cavalos de tróia, backdoors, spywares, bots(holz, 2005), etc. e constituem uma ameaça constante para as redes de computadores. Novas versões de softwares como esses são desenvolvidos todos os dias. Alguns deles possuem a capacidade de se espalhar rapidamente e de forma autônoma pela Internet e podem causar

45 44 muitos prejuízos em redes ao redor do mundo, como o famoso caso do Slammer em 2003(CAIS, 2003). Novas e velhas versões de malwares aparecem todo dia na Internet. Para profissionais de segurança, mantenedores de listas de assinaturas para sistemas de detecção de intrusão ou desenvolvedores de anti-vírus é importante coletar os malwares, o que permite a eles construir novas assinaturas que são capazes de detectar tráfego e/ou comportamento malicioso e proteger seus sistemas. Uma das formas de se coletar os malwares em um ambiente controlado é utilizando honeypots de alta interação para a captura principalmente de novos malwares. Alguns malwares (também chamados de bots) possuem a capacidade de se organizar em redes, formando um exército de máquinas infectadas a serviço de atividades maliciosas dos atacantes. Essas redes são conhecidas como botnets e permitem aos seus controladores expandir o poder de ataques distribuídos de negação de serviço (Distributed Denial of Service - DDoS). Também, dentro desse contexto, arquiteturas de honeypots podem capturar estes malwares. Para cada tipo de malware, um tipo de honeypot diferente é recomendado para a sua captura. Para aqueles que se propagam de forma automática, honeypots de baixa interatividade como Honeyd podem ser utilizados; e mais especificamente honeypots desenvolvidos para a captura dessas ameaças como o Nepenthes e o Amun são ainda mais indicados Estudo e entendimento das ações dos blackhats Quando se trata principalmente de honeypots de pesquisa, o principal objetivo é conhecer os procedimentos dos invasores e as ferramentas que eles utilizam. Existem muitas questões que precisam ser respondidas para se conhecer um incidente e o atacante. Dentre as quais pode-se citar: Quem é o atacante? De qual sistema ele lançou o ataque? Que ferramentas ele usou? Quais são os seus propósitos com esse ataque? Que nível de habilidade o atacante possui? Que informações (ou simplesmente dados) os atacantes coletaram? Como ele entrou no sistema?

46 45... etc... Algumas dessas questões podem ser facilmente respondidas com o uso de honeypots adequados. Honeypots de alta interatividade normalmente capturam todo o tráfego entrante e sainte da máquina; isso fornece o IP do atacante, a que serviços ele se conectou e muitas outras informações. A maior dificuldade é, porém, coletar informações desconhecidas (nunca antes vistas ou analisadas) de um ataque. Para isso, um módulo de kernel que captura todos os eventos no nível de sistema pode ser bastante útil. Esse procedimento permite capturar eventos de processos ou atividades no kernel. Neste nível, mesmo a utilização de criptografia no nível de aplicação não é suficiente para esconder as atividades do atacante, pois todas as teclas por ele digitadas e as ações das ferramentas usadas são capturadas. Essa técnica permite rastrear as atividades intrusas no sistema passo a passo, normalmente sob a forma de um arquivo de log que contém a ordem e o tempo de todos os comandos que foram executados. Ataques em honeypots de alta interatividade frequentemente mudam, trocam ou adicionam arquivos aos sistemas invadidos. Eles costumam modificar arquivos de configuração para que serviços comportem-se da maneira que eles desejam. Para mascarar seus rastros, os atacantes normalmente trocam programas importantes do sistema. Em sistemas UNIX, é comum trocar o comando ls, que lista o conteúdo de diretórios, se o atacante quiser esconder alguns arquivos que foram inseridos no sistema. Ele também pode trocar o comando ps, que mostra a lista dos processos atuais, para ocultar os serviços que ele iniciou. Portanto, ter algum sistema verificador de integridade (System Integrity Verifier - SIV) que detecta todas as mudanças feitas em arquivos de um sistema é bastante útil nesse caso, permitindo assim capturar os arquivos que foram incluídos ou modificados como parte do ataque ao honeypot. Algumas das questões listadas em forma de itens nesta seção não podem ser respondidas diretamente. O propósito do ataque ou o nível de habilidade do atacante, por exemplo, não é algo que pode ser diretamente inferido em qualquer caso. Normalmente, conclusões a esse respeito são obtidas pela monitoração de conversas entre os atacantes, via canal de IRC (Internet Relay Chat). Atacantes humanos também costumam se organizar em grupos, os chamados clãs. O livro Know your Enemy do Honeynet Project possui uma análise interessante das motivações, comportamentos e nível de habilidade dos atacantes a partir do monitoramento de um determinado ataque, além de traçar um perfil geral da organização desses grupos(community, 2001).

47 46 Mesmo honeypots de baixa interatividade podem ter um papel relevante em relação ao estudo e entendimento de determinadas ameaças, principalmente as que ocorrem com pouca intervenção humana. A partir deles, profissionais ligados a área de segurança de redes, podem ter um contato maior com as tecnologias, ferramentas e táticas envolvidas nos processos de ataques. Em particular, isto demonstra, por exemplo, que honeypots também podem ser usados em treinamentos de equipes de segurança.

48 47 3 Ferramentas utilizadas neste trabalho 3.1 Introdução Neste trabalho optou-se por utilizar honeypots de baixa interatividade para a obtenção de dados sobre ataques na rede local do PoP-ESRNP e avaliação do uso desse tipo de tecnologia. Tal decisão foi tomada devido a vários fatores como a possibilidade de aprender os conceitos básicos envolvidos nos ataques de forma mais fácil do que a requirida na análise de incidentes de honeypots de alta interatividade, os recursos computacionais disponíveis para a realização dos experimentos, o menor custo de manutenção e principalmente devido a se adequar melhor ao contexto da rede onde foram instalados. Os honeypots avaliados podem ser distribuídos em três categorias: os que podem ser usados para propósito geral (como o Honeyd (HONEYD, 2009) [que se trata de uma arquitetura mais genérica]), os especializados na interação e coleta de malwares (como o Nepenthes, Amun (GOEBEL, 2009) e Honeytrap (HONEYTRAP, 2009)) e os especializados em ataques via serviço ssh, como o Kojoney SSH Honeypot. Nas próximas seções deste capítulo, cada uma das principais ferramentas utilizadas serão descritas em maiores detalhes, onde será percebido que algumas delas possuem características em comum, mas também diferenças em suas estratégias para tentar coletar informações sobre os ataques. Também é preciso deixar claro que este capítulo tem por finalidade apresentar uma visão geral sobre as ferramentas e as funcionalidades que elas possuem, uma vez que este é o primeiro trabalho local relacionado a tecnologia de honeypots e julgou-se interessante realizar esta descrição que pode servir como base para futuros trabalhos. Não significa, portanto, que todas as funcionalidades que forem descritas neste capítulo foram utilizadas durante a fase de experimentação. A descrição do ambiente de experimentação e os parâmetros relevantes usados em cada ambiente serão descritos no capítulo 4.

49 Honeyd Honeyd é um honeypot de baixa interatividade considerado um framework leve para a criação de honeypots virtuais, permitindo capturar conexões e tentativas de ataques a partir da simulação de serviços TCP e UDP bem como a partir de mensagens ICMP destinadas aos honeypots. O framework permite manipular até milhares de máquinas virtuais e seus serviços correspondentes, utilizando cada qual um endereço IP (PROVOS, 2004). No Honeyd, a interação com os atacantes é limitada apenas ao nível de rede. Ou seja, ao invés de simular todos os aspectos de um sistema operacional, simula-se apenas sua pilha de rede IP. A principal desvantagem dessa abordagem é que um adversário nunca ganhará acesso a um sistema completo, mesmo se ele comprometer algum serviço simulado, uma vez que estará interagindo apenas com um ambiente emulado. Para aumentar sua efetividade, o Honeyd precisa fazer com seus honeypots virtuais operem em múltiplos endereços IP simultaneamente, de maneira a preencher a rede com muitos honeypots virtuais simulando diferentes sistemas operacionais e serviços. Com o intuito de aumentar o realismo da simulação, o framework também é capaz de simular arbitrárias topologias de rede, suportando tunelamento e um mecanismo simplificado de balanceamento de carga. A figura 1 mostra uma visão geral em relação à operação do framework. Nela, uma máquina central (a máquina física) intercepta o tráfego de rede enviado para os endereços IP dos honeypots configurados e simula suas respectivas respostas. Nas próximas subseções serão explanados os mecanismos que podem ser utilizados para a interceptação desse tráfego e também como funcionam os componentes que formam a arquitetura do Honeyd.

50 49 Figura 1: Visão geral da operação do framework Honeyd em relação a rede Recebimento de dados da rede Como dito previamente, o Honeyd é projetado para responder a pacotes da rede cujos endereços IP de destino pertençam a um dos honeypots simulados. No entanto, para que o Honeyd possa receber os pacotes corretamente, a rede precisa ser configurada apropriadamente. Existem muitas maneiras de fazer isso, algumas alternativas são (mas não necessariamente restritas a estas): a criação de rotas especiais para os endereços IP virtuais que apontem para o host que abriga o Honeyd; usar um proxy ARP; usar tunelamento (Honeyd tem suporte a túneis GRE); usar um daemon ARP (arpd) na máquina física onde o Honeyd será instalado. Neste trabalho, optou-se pelo uso de um daemon ARP por não requerer acréscimos ou mudanças nos dispositivos de produção (roteadores) que gerenciam as rotas das redes de produção e pesquisa.

51 Arquitetura dos componentes do Honeyd A arquitetura do Honeyd consiste de muitos componentes: uma base de dados de configuração, o expeditor (dispatcher) central de pacotes, os manipuladores de protocolos, o mecanismo de personalidades (personality engine) e um componente opcional de roteamento. Conforme pode ser observado no figura 2, o funcionamento do sistema ocorre da seguinte forma: os pacotes que chegam na máquina onde o Honeyd está instalado e que tem como destino um dos endereços IP referenciados por algum honeypot virtual são processados pelo expeditor central de pacotes. Inicialmente, ele checa o tamanho de um pacote IP e verifica o checksum do pacote. Antes de processar os outros campos do pacote, o dispatcher precisa consultar a base de dados de configuração para encontrar uma configuração de honeypot que corresponda ao endereço IP de destino. Se não existe uma configuração específica, o template default é usado. Dada uma configuração, o pacote e sua respectiva configuração são direcionados para o manipulador do protocolo do pacote em questão. O framework processa os três maiores protocolos da Internet: ICMP, TCP e UDP. Os pacotes que utilizam outros protocolos são registrados e silenciosamente descartados. O manipulador do protocolo ICMP foi projetado de forma a suportar muitas requisições. Por padrão, todas as configurações de honeypots virtuais respondem a pacotes echo request e processam mensagens destination unreachable. A manipulação de outras requisições depende das personalidades configuradas, sendo definida pelas informações do sistema de personalidades. Para os protocolos TCP e UDP, o framework pode estabelecer conexões para serviços arbitrários. Neste contexto, serviços são aplicações externas que recebem dados na entrada padrão stdin e enviam suas saídas através de stdout.

52 51 Figura 2: Diagrama dos compomentes da arquitetura do Honeyd. O comportamento do serviço depende inteiramente da aplicação externa ou script utilizado. Quando uma requisição de conexão é recebida, o framework checa se o pacote é parte de uma conexão estabelecida. Se esse for o caso, qualquer novo dado é enviado para o serviço de aplicação já iniciado. Porém, se o pacote contém uma nova requisição de conexão, então um novo processo é criado para rodar o serviço apropriado. Nos casos em que não se deseja criar um novo processo para cada conexão, o Honeyd disponibiliza alternativas como os subsystems ou internal services. Um subsystem é uma aplicação externa específica (como um servidor Apache) que executa vinculada a algum honeypot virtual. Ele é iniciado quando o honeypot virtual correspondente é instanciado e pode se associar a portas, aceitar conexões e até iniciar algum tráfego de rede. Enquanto um subsistema roda como um processo, um internal service é um script Python que emula um determinado serviço e que é executado diretamente dentro do Honeyd. Por esta razão, internal services costumam requerer menos recursos do que quando utilizados subsistemas. O Honeyd também contém uma máquina de estados TCP simplicada. Nela, o mecanismo three-way handshake para estabelecimento de conexões e o encerramento via FIN ou RST são totalmente suportados, mas os mecanismos de janelas de controle de congestionamento não são totalmente implementados. Por sua vez, os datagramas UDP são repassados diretamente para as aplicações ou scripts de serviços. Quando o framework recebe um pacote UDP para uma porta fechada, ele envia uma

53 52 mensagem ICMP de port unreachable, a menos que esta ação seja proibida pela configuração da personalidade do honeypot. Ao enviar mensagens desse tipo, o Honeyd permite que ferramentas de mapeamento como traceroute possam identificar a topologia de rede simulada, aumentando o realismo da simulação realizada. Além de estabelecer uma conexão para serviços locais, o framework pode também lidar com redirecionamento de conexões [que pode ser estático ou ser feito com base na tupla (endereço de origem, porta de origem, endereço de destino, porta de destino)]. Este redirecionamento permite que uma requisição seja encaminhada do serviço em um honeypot virtual para o serviço rodando em um servidor real (por exemplo, pode-se redirecionar requisições DNS para um servidor que abrigue o BIND). Uma outra forma de redirecionamento é fazer um espelho (mirror) das conexões, refletindo de volta para os atacantes os pacotes por eles enviados. Por exemplo, as conexões SSH recebidas poderiam voltar para a própria máquina atacante, fazendo que com seja atacado o próprio servidor SSH do autor da atividade maliciosa. Para gerar respostas às requisições, na última etapa antes de um pacote ser enviado pela rede, ele é processado pelo sistema de personalidades (personality engine). O sistema de personalidades ajusta o conteúdo dos pacotes de forma que eles pareçam ter sido criados pela pilha de rede do sistema operacional configurado no Honeyd, ajudando a enganar e confundir os atacantes. A seguir, o funcionamento desse sistema será melhor detalhado O sistema de personalidades (Personality Engine) Durante o processo de reconhecimento do alvo, os atacantes comumente podem usar ferramentas de fingerprinting como Xprobe(XPROBE2, 2009) ou Nmap(FYODOR, 1998) para coletar informações sobre o alvo. Para tentar fazer o honeypot parecer um servidor com serviços reais para essas ferramentas, o Honeyd simula o comportamento da pilha IP de um dado sistema operacional. Essa simulação é chamada dentro da arquitetura do Honeyd de personalidade (personality) de um honeypot virtual. O sistema de personalidades permite ao honeypot se comportar como especificado pela personalidade (escolhida no arquivo de configuração) a partir da introdução de mudanças no cabeçalho do protocolo da camada de rede e transporte de cada pacote sainte, de maneira que eles apresentem as mesmas características dos pacotes do sistema operacional escolhido como personalidade do honeypot no arquivo de configuração. O framework usa a base de dados de fingerprint do próprio Nmap como referência para

54 53 o comportamento dos protolocos TCP e UDP. Já a base de dados do Xprobe, é usada como referência para o comportamento do protocolo ICMP. O fingerprint do Nmap para cada sistema operacional tem um formato similar ao mostrado na figura 3. As informações nele presentes são usadas para formar as características da pilha de rede do honeypot. Figura 3: Fingerprint no formato Nmap que descreve algumas característica da pilha de rede do Windows Server Analisando o formato de fingerprinting, definiu-se que a string depois de Fingerprint é usada como identificador para o nome da personalidade. As linhas depois deste identificador descrevem o resultado de nove diferentes testes que o Nmap executa para determinar a sistema operacional do host remoto. Observa-se também que a separação entre os campos é feita pelo caractere %. O primeiro teste é o mais compreensivo. Ele determina como a pilha de rede do sistema operacional remoto cria o número de sequência inicial (ISN - initial sequence number) para os segmentos TCP SYN. O Nmap indica o nível de dificuldade de previsão dos ISNs na informação do campo Class. ISNs previsíveis resultam em um problema de segurança porque eles permitem que um atacante fraude conexões (spoofed connections). Os campos gcd e SI fornecem informações detalhadas sobre a distribuição do número de sequência inicial. Este primeiro teste também determina como o número de identificação IP e a marca de tempo TCP (TCP timestamps) são gerados, determinados por outros campos adicionais. Os sete próximos testes (T1 a T7) determinam o comportamento da pilha de rede para pacotes que chegam em portas TCP quando elas estão abertas ou fechadas. Por sua vez, o último teste (PU) determina as características do pacote de resposta ICMP enviado em resposta a uma requisição para uma porta UDP fechada. O Honeyd também mantém os estados de cada honeypot. O estado inclui informações sobre

55 54 a geração de ISNs, o tempo de boot (uptime) do honeypot e o número atual de identificação do pacote IP. Manter o estado é necessário para que se possa gerar ISNs subsequentes seguindo a distribuição designada pelo fingerprint. A forma de identificação de sistemas operacionais feita pelo Nmap é muito preocupada em seguir a implementação TCP dos sistemas. O TCP tem por características ser um protocolo stateful e orientado a conexões que fornece mecanismos de recuperação de erro e controle de congestionamento. Ele também suporta opções adicionais, que não são implementadas por todos os sistemas e são estas diferenças que possibilitam a identificação remota do sistema operacional. O tamanho da janela anunciada pelo receptor varia entre as implementações e é uma das características usadas pelo Nmap como parte das informações de fingerprint. Quando o Honeyd envia um pacote para uma nova conexão TCP estabelecida, ele usa o fingerprint fornecido pelo Nmap para decidir o tamanho da janela inicial usada pelo sistema. Após a conexão ser estabelecida, o framework ajusta a janela de acordo com a quantidade de dados existente no buffer. Se as opções TCP presentes no fingerprint forem negociadas durante o estabelecimento da conexão, então o Honeyd insere-as no pacote de resposta. Além disso, as informações fornecidas pela base de dados do Nmap determinam a frequência com que as marcas de tempo TCP são atualizadas. Para muitos sistemas operacionais, a frequência de atualização é igual a 2 Hz. O processo de gerar a distribuição correta do número de sequência é algo não trivial. Para realizar essa tarefa, o Nmap obtém seis amostras de ISN e analisa suas diferenças consecutivas, e partir delas é capaz de reconhecer muitos tipos de geração de ISN: diferenças constantes, diferenças que são múltiplas de uma constante, diferenças completamente aleatórias, dependentes do tempo ou por meio de incrementos aleatórios. Para diferenciar os dois últimos casos, Nmap calcula o máximo divisor comum (gcd - greatest common divisor) e o desvio padrão das diferenças coletadas. O sistema também mantém os registros do último ISN que foi gerado por cada honeypot e seu tempo de geração. Com essa informação, para cada nova requisição de conexão TCP, o Honeyd usa uma fórmula que aproxima a distribuição descrita pelo gcd do fingerprint. É desta maneira que o Honeyd consegue fazer com que os seus hoenypots virtuais se passem por uma determinada classe de sistema operacional. Quanto ao cabeçalho do pacote IP, o Honeyd ajusta a geração do número de identificação. Este número pode ser zero, incrementado por um ou aleatório. Já para os pacotes ICMP, o

56 55 sistema de personalidades usa o teste PU para determinar como o cabeçalho IP deve ser modificado, usando o fingerprint apropriado fornecido pela base de dados do Xprobe. O honeypot também permite a geração de vários tipos de mensagens ICMP, dentre elas as de destination unreachable Topologias de roteamento O Honeyd pode simular topologias de roteamento arbitrárias para aumentar o nível de realismo e tentar enganar atancantes e ferramentas de mapeamento de rede. Aqui, não se tem o mesmo objetivo de simuladores de topologias (como o NS (SIMULATOR, 2009)) que tentam reproduzir fielmente o comportamento para rede com o propósito de entender sua operação no mundo real. No caso do Honeyd, são simulados apenas alguns aspectos relacionados a topologia de rede (apenas o bastante para tentar enganar agentes maliciosos). Vale notar que quando configurado para simular topologias de roteamento, não é possível empregar um Proxy ARP para redirecionar os pacotes para o host do Honeyd. Neste caso, é necessário configurar os roteadores para delegar o espaço de endereçamento da rede em questão para o host do Honeyd. Normalmente, a topologia de roteamento virtual é uma árvore onde os pacotes se deslocam pela estrutura. Cada nó interior da árvore representa um roteador e cada aresta um link que contém características de latência e perda de pacotes. O framework permite múltiplos pontos de entrada e saída na rede virtual e a forma como é disposta a rede é definida no arquivo de configuração. Para se simular uma topologia de rede assimétrica, são consultadas as tabelas de roteamento quando o pacote entra no framework e novamente quando ele deixa-o (conforme pode ser visto na figura 2). Assim, quando um pacote é recebido, encontra-se a árvore de entrada de roteamento correta e ele a atravessa, começando pela raiz até chegar no nó que contém o endereço IP de destino do pacote. Durante este caminho, a perda de pacotes e latência de todas as arestas presentes no caminho são acumuladas para determinar se o pacote será rejeitado (dropped) e por quanto tempo sua entrega deverá ser atrasada. O Honeyd também decrementa o campo TTL (time to live) do pacote para cada roteador virtual que ele passar. Se o TTL chegar a zero, o framework envia uma mensagem ICMP de tempo excedido (time exceeded) com o endereço IP de origem do roteador que fez com que o TTL chegasse a zero.

57 56 Para simulações de rede, é possível integrar sistemas reais dentro de um topologia de roteamento virtual. Quando o framework recebe um pacote para um sistema real, ele atravessa a topologia até encontrar um roteador virtual que é diretamente responsável por aquele espaço de endereçamento no qual a máquina real está inserida. O sistema então envia, se necessário, uma requisição ARP para descobrir o endereço MAC do sistema e então encapsula o pacote em um quadro Ethernet. Similarmente, o framework responde às requisições ARP a partir do roteador virtual correspondente quando o sistema real envia requisições ARP. Outra possibilidade que a simulação de topologias do Honeyd permite é dividir a topologia de roteamento usando túneis GRE para fazer o tunelamento de rede. Isso permite o balanceamento de carga entre diversas instalações do Honeyd, delegando partes do espaço de endereçamento a diferentes hosts que abrigam o Honeyd. Usando túneis GRE, é possível também delegar redes que pertencem a partes separadas do espaço de endereçamento a um único host Honeyd. Para realizar a rota reversa, um túnel de saída é selecionado baseado tanto no endereço IP de origem como no de destino Configuração do Honeyd No Honeyd, um honeypot virtual é configurado por meio de um template, que é um conceito no contexto do Honeyd que se refere as configurações escolhidas para que um honeypot virtual se passe por um determinado sistema computacional, com comportamentos específicos. A criação de novos templates é possível a partir da utilização do comando create. Já os comandos set e add são usados para mudar as configurações de um template específico. O comando set atribui uma personalidade do arquivo de fingerprint do Nmap para um template e, conforme já descrito, a personalidade define o comportamento da pilha de rede. O comando set também define o comportamento padrão para os protocolos de rede suportados. O comportamento padrão é definido por um dos seguintes valores: block, reset ou open. Block significa que todos os pacotes para um protocolo especificado são descartados por padrão. Reset indica que todas as portas são fechadas por padrão. Open significa que elas são todas abertas por padrão, não importando se elas são UDP ou TCP. A configuração dos serviços que são acessíveis remotamente são especificados com o comando add. Nele, em complemento ao nome do template, é necessário especificar o protocolo, a porta e o comando para executar cada serviço. Além da possibilidade de especificar um serviço, o Honeyd também reconhece a palavra-

58 57 chave proxy que permite redirecionar as conexões de rede para outro host. O framework também expande as quatro váriaveis seguintes para serviços e proxies: $ipsec, $iodst, $sport, $dport. A existência delas permite a um serviço adaptar seu comportamento dependendo da conexão de rede que ele está lidando, possibilitando também redirecionar varreduras de rede de volta para o host que está executando-as. Por último, o comando bind é o responsável fazer a associação um template a um endereço IP. Se nenhum template é associado a um endereço IP, então o template default é utilizado Logs do Honeyd Os logs gerados pelo Honeyd podem ser divididos em dois níveis: os logs a nível de conexão (que registram eventos ao nível de camada de rede e transporte) e os logs que registram as atividades dos serviços (que registram os eventos ao nível de aplicação, sendo seu formato definido por cada serviço). O Honeyd suporta diferentes formas de registro das atividades de rede do honeypot. Em uma delas, ele cria um log de conexões que registra todas as tentativas de conexão e as conexões completadas para todos os protocolos suportados pelo honeypot e a partir dele é possível extrair estatísticas relacionadas sobre quais portas foram mais contactadas pelo atacante, que protocolo de transporte foi utilizado, o IP de origem do pacote, etc. É possível também configurá-lo para usar o syslog para armazenar informações no sistema operacional que abriga o Honeyd. A coleta de informações dos serviços em si também é realizada, porém cabendo a eles definir os arquivos de saída dos logs. Os serviços do Honeyd também podem enviar dados para serem registrados via stderr Honeycomb O Honeyd possui uma infra-estrutura de plugins que permite escrever extensões que podem se manter separadas do código-fonte base do Honeyd, possibilitando a integração do plugin às atividades do honeypot. Honeycomb é um plugin para o Honeyd para a geração de assinaturas de ataques para o Snort(SNORT, 2009) e Bro(BROIDS, 2009), que são NIDS de código aberto bastante conhecidas. Em se tratando de ferramentas NIDS, não existe um padrão definido para essas assinaturas. Como consequência, diferentes IDSs possuem suas próprias linguagens de definição de assinaturas, que variam em termos de expressividade (KREIBICH; CROWCROFT, 2003).

59 58 Geralmente, uma boa assinatura precisa ser esperta o bastante para capturar precisamente as características da forma de exploração ou ataque que ela está tentando descrever; ao mesmo tempo, ela deve ser flexível o suficiente para capturar pequenas variações entre ataques do mesmo tipo. Se ela não alcançar nenhum desses objetivos, grandes quantidades de falsos positivos ou falsos negativos podem ser geradas. Como dito anteriormente, Honeycomb (HONEYCOMB, 2009) gera assinaturas para o Bro e Snort. Bro possui uma poderosa linguagem específica que permite o uso de expressões regulares, associação de tráfego em ambas as direções e a divisão da codificação do ataque em múltiplos estágios. Snort, por sua vez, não possui uma linguagem de assinaturas tão expressiva quanto a do Bro, mas também oferece muitos recursos essenciais para a existência de boas assinaturas. No entanto, Snort é uma ferramenta NIDS de código aberto mais usada e conhecida do que Bro. Isso se deve principalmente ao fato de que o Snort encontra-se num estágio de desenvolvimento e confiabilidade muito maior do que Bro e por possuir um grande repositório de regras (assinaturas), constantemente atualizado por sua comunidade. Não serão expostos aqui detalhes sobre as duas ferramentas, mas deve-se deixar claro que existem grandes diferenças nas arquiteturas das mesmas. Figura 4: Diagrama da arquitetura do Honeycomb, mostrada na situação de configuração típica do Honeyd, com o Honeyd simulando diferentes máquinas, cada qual executando alguns serviços pré-configurados. Para a geração das assinaturas, o Honeycomb utiliza o algoritmo da maior substring comum (longest common substring - LCS) para encontrar as similaridades entre os payloads dos pacotes.

60 59 Atráves de um mecanismo de hooks, os plugins são informados sempre que um pacote é recebido ou enviado, bem como sobre atualização de estados das conexões em honeypots gerenciados pelo Honeyd. A figura 4 ilustra a arquitetura. A integração de um sistema de geração de assinaturas para IDS dentro do Honeyd tem muitas vantagens sobre uma abordagem que captura tráfego direto na rede. A primeira delas é que não há duplicação de esforço: o Honeyd já acessa o tráfego de rede - inspecionando o tráfego (usando a libpcap) e passando os pacotes relevantes para as pilhas de rede dos hosts simulados e eventualmente para os subsistemas configurados. Isto, portanto, poupa esforço, uma vez que faz uso de pacotes que já foram transferidos para o espaço do usuário (user space). Outra vantagem é o fato de não existir o problema de partida fria (cold-start problem), uma vez que não existe a desincronização do estado atual das conexões. Isso porque quando o Honeyd recebe um pacote que inicia uma nova conexão, o Honeycomb fica sabendo que aquela conexão iniciou-se. Logo, a questão de perder o início de uma conexão deixa de ser um problema, que é comumente encontrado em sistemas que rastream o tráfego de rede diretamente (bump-in-the-wire) para a inspeção do tráfego Mecanismo de rastreamento de conexões O Honeycomb mantém o estado para um número limitado de conexões TCP e UDP 1, possuindo algumas peculiaridades com relação a maneira de manter os estados das conexões de rede. Uma vez que o objetivo é gerar assinatura a partir da comparação do novo tráfego que chega ao honeypot com relação aos outros vistos anteriormente, não se pode apagar todos os estados das conexões imediatamente quando uma conexão é terminada. Ao invés disso, apenas marcam-se as conexões como terminadas mas mantendo-as o tanto quanto for possível, ou até que tenha-se alguma certeza de que elas não trarão benefícios por armazená-las por mais tempo. Conexões que trocam muita quantidade de informação são potencialmente muito mais valiosas para detectar padrões de tráfego novos. Adicionalmente, o sistema precisa prevenir que port scans transbordem a capacidade das tabelas hash de conexões, o que poderia causar a perda de conexões valiosas (ou seja, que possuem conteúdos mais interessantes). Por isto, tanto conexões UDP como TCP são armazenadas em dois estágios: as conexões são primeiro armazenadas em uma tabela de handshake e, se ocorrer troca de pacotes na conexão, são então movidas posteriormente para uma tabela established. O Honeycomb também realiza a remontagem de fluxo (stream reassembly): para TCP, os 1 quando fala-se em conexões UDP, deseja-se referir aos pacotes trocados entre os mesmos pares de IP e porta.

61 60 fluxos são remontados até a quantidade de bytes máxima configurada que podem ser trocados em uma conexão. Esses fluxos são guardados como uma lista de mensagens trocadas até um máximo tamanho permitido. Neste contexto, uma mensagem é definida como todos os dados que foram transmitidos em uma direção sem qualquer outros dados vindo na outra direção. Por exemplo, uma típica requisição HTTP é armazenada em duas mensagens: uma para a requisição HTTP e outra para a resposta HTTP que for gerada. Para UDP, de forma similar, mensagens são criadas para todos os payloads que vem em uma direção sem quaisquer outros dados na outra direção Mecanismo de análise de protocolos Depois de atualizar o estado da conexão, o Honeycomb cria um registro de assinatura vazio para o fluxo e começa a inspecionar o pacote. Cada assinatura tem um identificador único e armazena os fatos descobertos, isto é: as características do tráfego investigado independentemente da linguagem de assinaturas usada por um NIDS específico. O registro de assinatura (signature record) é então acrescido continuamente por meio do processo de detecção, sendo mantido um contador do número de fatos registrados. A análise do protocolo de rede é feita nos níveis da camada de rede (IP) e transporte (TCP e UDP), usando técnicas de header-walking utilizadas em processos de normalização de tráfego. No lugar de anomalias detectadas corretamente, são armazenadas a assinatura em si, como por exemplo os deslocamentos (offset) inválidos de fragmentação IP e combinações não usuais de flags TCP. Para realizar essas checagens, o Honeycomb não precisa fazer qualquer comparação com os pacotes por ele vistos anteriormente. Após essas verificações, o Honeycomb então faz a comparação de cabeçalhos com cada conexão do mesmo tipo (TCP ou UDP) atualmente armazenada. Se a conexão armazenada já foi movida para o segundo nível da tabela hash, então o Honeycomb tenta olhar a mensagem correspondente e usar os cabeçalhos associados com a mensagem. Se casamentos (como de identificadores IP ou faixa de redes) são detectados, a análise de assinaturas é clonada e torna-se específica para os fluxos comparados. Os fatos descobertos são então armazenados na forma de uma nova assinatura Forma de exibição das assinaturas O conteúdo das assinaturas geradas são enviadas periodicamente para um módulo de saída que implementa o formato de registro em arquivo das assinaturas.

62 61 Assim, existem módulos que convertem os registros de assinatura no formato aceito pelo Bro ou pelo Snort (se submetido a pequenas alterações) e um módulo que joga as strings das assinaturas para um arquivo. 3.3 Nepenthes Os artefatos de software que servem para propósitos maliciosos são comumente chamados de malware. Eles não são apenas um tipo de ameaça constante para a integridade de computadores individuais na Internet. Na forma de botnets, por exemplo, eles podem tornar indisponível praticamente qualquer servidor através de um ataque de negação de serviço distribuído (Distributed Denial of Service - DDos) como consequência da combinação das "forças"de muitas máquinas comprometidas, sendo um perigo constante mesmo para máquinas não infectadas com os mesmos. Em geral, quanto mais e melhor são conhecidos os malwares que estão se propagando em um dado momento, melhor poderão ser as estratégias de defesa adotadas. Uma das formas de se obter esse conhecimento é por meio da coleta de malwares, a partir da qual torna-se possível que ferramentas de detecção de intrusão e sistemas anti-vírus refinem suas assinaturas a partir dos arquivos que forem coletados. Se a atividade de coleta for realizada em larga escala, então pode-se gerar estatísticas para a observação de padrões de ataques e o nível de tráfego malicioso diário gerado pela ação de worms. Porém, coletar e principalmente analisar malware em alta escala não é uma tarefa fácil, principalmente se forem necessárias análises forenses manuais de máquinas que foram identificadas como comprometidas. Em alguns casos, é possível automatizar a coleta de determinados worms e a principal ferramenta utilizada para isto atualmente são os honeypots. Dentro deste contexto está o Nepenthes, um honeypot especializado na coleta de malwares que se propagam pela rede. O Nepenthes é um honeypot de baixa interatividade projetado para a coleta em larga escala de informações sobre malwares que se auto-propagam pela rede. Seu princípio básico é emular apenas das partes vulneráveis dos serviços, sendo que estas vulnerabilidades são implementadas como máquinas de estados finitos. A partir dos malwares coletados por ele, é possível até mesmo examinar o nível de efetividade das ferramentas de anti-vírus para o grupo de binários capturados.

63 62 O Nepenthes também pode ser utilizado como uma plataforma para o desenvolvimento de novos módulos que emulam as vulnerabilidades (os chamados vulnerability modules), tendo como pré-requisito conhecimentos em C++. Tal possibilidade pode tornar o honeypot ainda mais abrangente quanto a captura de novos worms. Além disso, por ser um honeypot de baixa interatividade, ele permite que o honeypot se passe por máquinas com diferentes serviços, dependendo da vulnerabilidade encontrada. Além de ser um honeypot voltado para a coleta de informações sobre worms, o Nepenthes possui como principal diferencial em relação a outras soluções baseadas em honeypot a sua característica escalável. Ele foi projetado e testado para cobrir grandes faixas de endereços IP, suportando requisições para mais de endereços IP para uma única máquina física. Além disso, é possível criar, se necessário, uma arquitetura hierárquica para reporte das informações geradas por múltiplas instalações Nepenthes distribuídas pela rede (GOEBEL; HOLZ; WILLEMS, 2007). Isto não seria possível com a utilização de honeypots de alta interatividade, uma vez que os requisitos necessários de hardware e espaço físico inviabilizariam tal abordagem. Ao mesmo tempo, o Nepenthes é mais adequado do que o Honeyd para a tarefa de coleta, uma vez que os scripts do Honeyd costumam ser bastante simples e (a menos do desenvolvimento personalizado de novos scripts) insuficientes para a obtenção de determinados worms (HOLZ, 2006). Na próxima subseção, será apresentada a arquitetura do Nepenthes e os seus componentes Arquitetura da plataforma Nepenthes O projeto do Nepenthes foi concebido de forma a ser bastante modularizado. Nele, o núcleo do programa (o daemon em si) é responsável por manipular a entrada e saída de pacotes resultantes das interações com os atacantes pelas interfaces de rede, bem como coordenar as ações de outros módulos (BAECHER et al., 2006). A arquitetura do Nepenthes é composta de muitos módulos, que se comunicam com a parte central do programa. Existem muitos diferentes tipos de módulos, dentre os quais cita-se os mais importantes: Módulos de vulnerabilidade (Vulnerability modules): são os módulos responsáveis por emular as partes vulneráveis do serviços de rede. Módulos de análise de shellcode (Shellcode parsing modules): são os módulos que analisam os pacotes recebidos por um módulo de vulnerabilidade. Eles analisam o shellcode

64 63 (uma pequena porção de código usada como payload de pacotes para a exploração de uma vulnerabilidade) recebido, e extraem informações sobre o malware e como ele se propaga. Módulos de busca (Fetch modules): são os módulos que usam a informação extraída pelos módulos de análise de shellcodes para obter o binário do malware a partir de servidores onde eles ficam armazenados. Módulos de submissão (Submission modules): assim que a localização do binário é obtida, os módulos de submissão são responsável por tarefas como salvar o binário no disco rígido local, armazená-lo num banco de dados ou enviá-los a ferramentas de análise dinâmica (sandboxes) ou fabricantes de anti-vírus. Módulos de logging (Logging modules): são os módulos que registram as informações sobre o processo de emulação, bem como sobre a lista dos binários capturados, etc. auxiliando na tarefa de se obter uma visão geral sobre os padrões dos dados coletados. Além destes, alguns outros componentes são responsáveis por funcionalidades importantes providas pelo Nepenthes: o sistema de emulação de shell (shell emulation), o sistema de arquivos virtual (virtual filesystem) para cada shell emulado, os módulos de geolocalização (geolocation modules) [permitindo que se tenha a informação do país de origem do ataque] e de resolução assíncrona de DNS (asynchronous DNS resolution). A figura 5 mostra as interações existentes entre os módulos e o núcleo do aplicativo. Figura 5: Arquitetura da plataforma Nepenthes e os relacionamentos entre os módulos que a compõe.

65 Módulos de vulnerabilidade Os módulos de vulnerabilidade são considerados como os principais componentes da arquitetura do Nepenthes porque são eles que proporcionam o mecanismo de comunicação com os worms. Atualmente, existem 21 módulos de vulnerabilidades disponíveis, que quando utilizados todos ao mesmo tempo requerem 29 portas TCP abertas. O princípio básico da construção desses módulos é emular apenas as partes necessárias de uma vulnerabilidade, com o intuito que esta emulação seja suficiente para capturar informações sobre o worm em questão. Ou seja, ao invés de emular o serviço inteiro, emula-se somente as partes relevantes do ponto de vista de coleta do malware. Esta característica torna estes módulos menores, fazendo-os requerer muito menos recursos de memória e processamento do que os necessários para a execução de um serviço completo. De certa forma, isto também ajuda a dar escalabilidade ao projeto do Nepenthes, tornando possível a implantação do mesmo em maior escala. Em alguns casos a emulação pode ser bastante simples, de forma que é necessário fornecer apenas algumas poucas informações a respeito de determinados deslocamentos (offsets) existentes no fluxo de pacotes que ocorre durante o processo de exploração da vulnerabilidade. Isto é o bastante para enganar alguns worms que se auto-propagam e fazê-los acreditar que realmente podem explorar o honeypot. A partir da ação dos módulos de vulnerabilidade, que fazem a comunicação com estes worms, é possível receber o payload, que é então repassado aos módulos de análise de shellcode. A tabela 1 mostra alguns dos módulos de vulnerabilidades e as notificações de segurança (security advisory) associadas a eles Módulos de análise de shellcode Os módulos de análise de shellcode analisam o payload (a carga útil do pacote, sem os cabeçalhos) recebido e extraem automaticamente informações relevantes sobre a tentativa de exploração de vulnerabilidade. Apenas um módulo como esse é capaz de analisar muitos shellcodes encontrados em larga escala em worms que se propagam pela Internet. Estes módulos funcionam da seguinte maneira: primeiro, eles tentam decodificar o shellcode. Muitos dos shellcodes são criptografados com um codificador XOR (XOR encoder), que é uma maneira bastante difundida de encriptar os shellcodes atuais de maneira a tentar enganar sistemas de detecção de intrusão que operam por meio de processamento de strings (assinaturas). Depois, o módulo decodifica o código em si de acordo com a chave XOR computada e então aplica algum padrão de detecção como a existência de URLs ou comandos para a criação

66 65 Nome do módulo Referência da notificação de segurança vuln-asn1 ASN.1 Vulnerability Could Allow Code Execution (MS04-007) vuln-bagle Emulação do backdoor do worm Bagle vuln-dcom Buffer Overrun in RPC Interface (MS03-026) vuln-iis IIS SSL Vulnerability (MS e CAN ) vuln-kuang2 Emulação do backdoor do worm Kuang2 vuln-lsass LSASS vulnerability (MS e CAN ) vuln-msdtc Vulnerability in MSDTC Could Allow Remote Code Execution (MS05-051) vuln-msmq Vulnerability in Message Queuing Could Allow Code Execution (MS05-017) vuln-mssql Buffer Overruns in SQL Server 2000 Resolution Service (MS02-039) vuln-mydoom Emulação do backdoor do worm mydoom/novarg vuln-optix Emulação do backdoor do trojan Optix Pro vuln-pnp Vulnerability in Plug and Play Could Allow Remote Code Execution (MS05-039) vuln-sasserftpd Sasser Worm FTP Server Buffer Overflow (OSVDB ID: 6197) vuln-ssh Logging of SSH password brute-forcing attacks vuln-sub7 Emulação do backdoor do trojan Sub7 vuln-wins Vulnerability in WINS Could Allow Remote Code Execution (MS04-045) Tabela 1: Alguns dos módulos de vulnerabilidades do Nepenthes e as notificações de segurança associadas a eles. de processos (como o CreateProcess() do Windows). Caso informações suficientes para baixar o malware sejam obtidas, então elas são repassadas para os módulos de busca Módulos de busca Os módulos de busca (fetch modules) tem como tarefa baixar os arquivos a partir das informações repassadas pelos módulos de análise de shellcode. Atualmente, existem sete diferentes módulos de busca. Eles são responsáveis por suportar diferentes modos de download como a partir de protocolos como TFTP, HTTP, FTP e csend/creceive (um método de submissão baseado no IRC). Além disso, alguns tipos de worms usam protocolos próprios para propagação e por isso alguns módulos de busca específicos foram desenvolvidos para manipular estes protocolos. Assim que o download é bem sucedido, as informações são repassadas para os módulos de submissão, que tomarão a decisão sobre o que fazer com o binário.

67 Módulos de submissão Os módulos de submissão são responsáveis por manipular os arquivos baixados com sucesso. Atualmente, existem quatro diferentes tipos de módulos de submissão. O primeiro possibilita que o arquivo seja armazenado no disco local, em um caminho previamente configurado para armazenamento do mesmo. Uma segunda opção disponível é submeter o arquivo a um banco de dados central, o que permite a existência de uma arquitetura de sensores distribuídos com uma interface de log centralizada. Outro módulo de submissão permite que o arquivo seja enviado a outras instâncias do Nepenthes, permitindo a construção de uma estrutura hierárquica de sensores. Por último, um outro módulo torna possível a submissão automática do arquivo a sandboxes (como Anubis (ISECLAB, 2009), CWSandbox (MANNHEIM, 2009) ou Joebox (SECURITY, 2009)) ou a fabricantes de anti-vírus O sistema de emulação de shell Determinados tipos de worms se espalham a partir do fornecimento de um shell ao atacante. Assim, é necessário em algumas situações criar e emular um shell Windows (cmd.exe). O Nepenthes possibilita este tipo de interação com o atacante fazendo uma simulação rudimentar do shell do Windows, onde muitos comandos podem ser interpretados e até mesmo a execução de arquivos batch (.bat) é suportada. Mesmo sendo uma simulação limitada, ela tem provado ser suficiente para enganar os ataques automáticos mais comuns que se baseiam nesta estratégia. Neste caso, baseado na coleta de informações da sessão shell, é então possível também baixar o malware correspondente. Uma técnica comum de infecção de um host via shell é atráves da escrita e execução de um arquivo batch temporário com comandos para baixar e executar os malwares. Para suportar este tipo de operação, o Nepenthes implementa um sistema de arquivos virtual (virtual filesystem) simplificado. Nele, os arquivos são criados sob demanda, similar ao esquema copy-on-write (COW). Assim que o processo de ataque tenta criar um arquivo, ele é criado sob demanda e o atacante pode modificá-lo e acessá-lo. Tudo isso é feito virtualmente, proporcionando uma maior eficiência na utilização dos recursos. Após o processo de ataque ser finalizado, o malware é baixado automaticamente. Cada sessão de shell tem seu próprio sistema de arquivos virtual, logo, as infecções que ocorrem concorrentemente usando falhas similares não interferem uma

68 67 na outra Captura de novos exploits Uma característica interessante de um sistema baseado em honeypot é também a habilidade de detectar e responder a zero-day (0day) attacks, isto é, ataques que exploram vulnerabilidades desconhecidas ou, pelo menos, vulnerabilidades para as quais ainda não existam correções (patches) disponíveis. O Nepenthes tenta atender a demanda de deteçcão de ataques zero-day disponibilizando de um módulo básico chamado portwatch. Ele funciona rastreando o tráfego de rede em determinadas portas, capturando os primeiros pacotes da conexões (de forma bastante semelhante ao Honeytrap, que será exposto na seção 3.5), registrando-os para que o operador possa realizar uma análise posterior e determinar se alguns destes pacotes estão relacionados a 0day exploits. Além disso, caso um novo exploit se destine ao honeypot, o Nepenthes disparará as primeiras ações de um módulo de vulnerabilidade. Entretanto, se um certo fluxo de pacotes não puder ser manipulado por este módulo de vulnerabilidade, todas as informações coletadas são armazenadas no disco rígido para facilitar uma análise posterior. Tal característica permite a detecção dos padrões de ataques, podendo ser um indicador de novas tendências e auxiliando no desenvolvimento de futuros módulos. Além disso, no caso de 0-day attacks, tal funcionalidade permite uma análise mais rápida, uma vez que os primeiros estágios do ataque já podem ser sido capturados por um determinado módulo do Nepenthes. Uma desvantagem desta abordagem é que atacantes podem enviar dados randômicos para uma determinada porta, fazendo com que o Nepenthes armazene estes dados em disco. Em uma situação limite, isto pode levar a uma condição de negação de serviço (DoS) se o atacante enviar uma grande quantidade de tráfego falso, muito embora problemas como esses sejam raros. Adicionalmente, é possível também estabelecer medidas de restrição de uso de recursos no sistema operacional hospedeiro do Nepenthes. Outra alternativa é que quando, em algum ponto, o novo exploit divergir das ações emuladas pelo módulo de vulnerabilidade, o malware pode ser encaminhado para um honeypot de alta interatividade ou algum outro tipo de sistema especializado de análise dinâmica de malwares como, por exemplo, o Argos(PORTOKALIDIS, 2009) para que seja verificado se algum novo exploit está se propagando.

69 Limitações do Nepenthes O plataforma Nepenthes possui várias limitações decorrentes das escolhas realizadas durante a sua construção. A primeira delas é que o Nepenthes só é capaz de coletar malware que se propaga autonomamente, isto é, que se espalha varrendo os sistemas vulneráveis de uma rede e explorando-as (os chamados worms). Entretanto, esta é uma limitação comum a muitas soluções envolvendo honeypots e até compreensível para algo projetado para a captura de malwares. Ele também não possui suporte a operação como client honeypot, não sendo capaz de detectar um exploit que é disparado apenas quando um página web é acessada em um browser. Em segundo lugar, malwares que se propagam usando uma hitlist para encontrar sistemas vulneráveis são díficeis de serem detectados com Nepenthes. Esta também é uma limitação compartilhada com muitas soluções que se baseiam na tecnologia de honeypots. Neste caso, a solução para esse possível problema seria se tornar parte da hitlist. Se, por exemplo, o malware gera sua hitlist consultando um sistema de busca por sistemas vulneráveis, poderia-se tentar enganá-lo incluindo o honeypot de alguma forma no índice do sistema de busca. Além disso, é possível que a presença do Nepenthes seja detectada remotamente: uma vez que a plataforma emula um grande número de vulnerabilidades e que normalmente muitas portas TCP ficam abertas ao mesmo tempo, um atacante poderia achar, durante a fase de reconhecimento da vítima, esta característica suspeita. Este é um problema compartilhado com outros honeypots como o Amunhoney (seção 3.4) e até mesmo o Honeyd (seção 3.2). Para mitigar este problema, poderia-se então usar apenas módulos de vulnerabilidades que existissem em um sistema específico, como por exemplo, os que afetassem o Windows 2000 SP1. A desvantagem desta abordagem é que isso poderá reduzir a expressividade dos resultados devido às poucas amostras de worms coletadas. Por fim, a análise do malware feita pelo Nepenthes não é abrangente, e normalmente apenas se concentra no objetivo de capturar o worm. Quanto a isto, uma análise mais aprofundada pode ser feita de forma estática (manual) ou dinâmica (atráves de sandboxes) e pode sobrepor o problema da qualidade da análise feita com relação ao malware. 3.4 Amunhoney O Amunhoney é um honeypot escrito na linguagem Python por Jan Goebel em 2007 e que funciona de forma similar ao Nepenthes, com o diferencial que novos módulos podem ser escritos em Python ou XML.

70 69 Assim como o Nepenthes, ele possui seus módulos de vulnerabilidades, de logging, captura de worms, etc. A versão disponibiliza 26 vulnerabilidades que quando totalmente ativadas usam 25 portas diferentes. Segundo o autor, a arquitetura do Amun é bastante similar a do Nepenthes, refletindo os mesmos conceitos básicos. As vulnerabilidades são implementadas por máquinas de estados finitos. As maiores diferenças se dão quanto a linguagem usada para implementação e suas consequentes vantagens e desvantagens, além de algumas poucas diferenças relativas ao modo de configuração do honeypot. Por estes motivos, são serão feitas maiores explanações sobre a arquitetura do Amunhoney, uma vez que a descrição da arquitetura do Nepenthes serviu de base para sua implementação. 3.5 Honeytrap Honeytrap é um daemon honeypot de baixa interação desenvolvido para observar ataques contra serviços de rede, principalmente serviços TCP ou UDP. Em contraste com outros honeypots que focam na coleta de malware, o Honeytrap procura capturar a falha explorada. Para alcançar esse objetivo, ele coleta e posteriormente processa os traces gerados pelo ataque, o que faz com que ele se distingua também do Honeyd. O modelo aplicado na arquitetura do Honeytrap distingue entre a captura dos dados e a análise do ataque. Explicitamente, isso significa que o processo de coleta de informações relacionado aos ataques são completamente realizados dentro do próprio núcleo do programa e os dados que chegam são manipulados como fluxos de bytes por sessão. Os dados são então reunidos em uma string chamada de string de ataque (attack string), que depois é armazenada em arquivo sob a forma de um trace (no formato lido pelo utilitário hexdump). A partir deste, outros processamentos (como análise automatizada), podem ser feitos por meio de plugins específicos para tais tarefas. Existem plugins para, por exemplo, tentar encontrar certos padrões conhecidos, para decodificação do fluxo de bytes (como, por exemplo, base64 ou XOR shellcode), para executar os comandos que se refiram dentro do trace a downloads de malwares, e até mesmo para avaliar se o binário baixado trata-se ou não de um malware (pela execução automática de um programa anti-vírus). A forma como é realizada a obtenção dos fluxos de bytes também é diferenciada em relação a abordagem utilizada pelo Nepenthes, Amun e até mesmo pelo Honeyd, onde muitas portas ficam sempre abertas a espera de requisições. No caso do Honeytrap, ele implementa um conceito de servidor dinâmico e, para esse propósito, monitora o fluxo da rede por sessões

71 70 entrantes e inicia sob demanda os listeners apropriados; ou seja, ele roda como um daemon e inicia processos dinamicamente nas portas requisitadas. Cada listener pode lidar com múltiplas conexões e encerrar a si mesmo após algum tempo de inatividade Captura de ataques desconhecidos Uma abordagem clássica em tecnologias de honeypots é emular serviços ou vulnerabilidades conhecidas, seguida por ferramentas como o Nepenthes. Entretanto, elas não funcionam bem para ataques completamente desconhecidos que podem ocorrer em portas aleatórias e fazer uso de protocolos desconhecidos. Contudo, não existe necessidade de manter centenas de portas abertas. Por ataques desconhecidos está referindo-se àqueles em que nenhum pré-conhecimento sobre o protocolo ou vulnerabilidade são usados, ou seja, a vulnerabilidade é desconhecida publicamente ou muito recente. Entretanto, essa mesma característica de abertura de portas sob demanda pode resultar em muitas delas abertas, como nos casos em que varreduras de portas são lançadas por atacantes. Portanto, em alguns casos, é recomendável ajustar a configuração para lidar satisfatoriamente com essas ocorrências. Conforme dito acima, o Honeytrap extrai tentativas de conexões a partir do fluxo da rede. A funcionalidade responsável por isso é chamada de monitores de stream (stream monitors). Cada monitor é responsável por detectar uma requisição para uma porta não aberta e informar essa ação para que o o processo servidor possa abrir a porta requisitada e ficar a espera de dados. Tal estratégia permite a manipulação de ataques quando eles ocorrem, não importa se eles são conhecidos ou não. Atualmente, existem três diferentes tipos de monitores de conexão disponíveis no Honeytrap: O primeiro deles é baseado na biblioteca libpcap, sendo um sniffer que pega os pacotes RST gerados localmente com um sequência numérica de zero, o que normalmente indica uma requisição de conexão rejeitada. A porta requisitada é então aberta e as próximas requisições são adequadamente atendidas. Particularmente no caso de ataques, o sistema remoto irá fazer novas conexões com o mesmo alvo e terá sua ação registrada, ainda que a primeira requisição tenha sido ignorada. O monitor de stream pcap é o padrão utilizado pelo Honeytrap, por causa de sua portabilidade (é também utilizado no presente trabalho). Uma segunda opção, exclusiva para sistemas Linux, é usar a interface ip_queue provida pelo netfilter_iptables e criar uma regra de iptables para entregar os pacotes relacionados

72 71 a novas conexões para o Honeytrap. A utilização deste monitor apresenta a vantagem de tratar a conexão logo na sua primeira tentativa, diferentemente do monitor baseado na libpcap onde a mesma é ignorada. Alternativamente e também exclusiva a sistemas Linux, a interface netfilter_queue pode ser usada. Novamente, as regras do iptables definem quais pacotes são entregues para o Honeytrap. Este é monitor de stream recomendado para utilização em sistemas Linux quando não há preocupações com portabilidade Modos de ação do Honeytrap Analogamente ao Honeyd, o Honeytrap também pode manipular as requisições de diferentes modos. O modo padrão é modo normal (normal mode). Mas existem outros modos disponíveis. Um deles é o modo mirror, no qual todos os dados que chegam são espelhados de volta para o atacante. Para cada conexão que o Honeytrap recebe, ele estabelece uma conexão espelho de volta para o host remoto, na mesma porta que foi requisitada pelo atacante. Respostas provenientes de conexões espelhadas também são refletidas para a conexão inicial. Pode-se pensar que o Honeytrap no modo mirror atua como um proxy TCP genérico, fazendo com que o atacante ataque a si mesmo. Se a conexão espelhada não puder ser estabelecida, o manipulador de conexões automaticamente volta para o modo normal. Um ataque pode também ser processado no modo proxy (proxy mode), onde as conexões entrantes são repassadas para um host diferente que possui determinado serviço sendo executado. As portas podem ser explicitamente configuradas para serem manipuladas no modo normal (normal mode) ou no ignore mode. No último caso, as conexões para estas portas simplesmente não são analisadas pelo Honeytrap. A configuração de modo pode ser feita individualmente para cada porta TCP ou UDP. A presença de diferentes modos permite a configuração do Honeytrap como um meta-honeypot onde as conexões que deverão ser manipuladas por outros honeypots ou serviços reais possam ser transferidas a eles, enquanto outras possam ser espelhadas e outras possam ser manipuladas no modo normal. Esta característica aliada a estratégia de apenas disponibilizar as portas requisitadas faz com que o Honeytrap seja conhecido como um metahoneypot dinâmico.

73 Emulação de serviços e captura de arquivos Embora a emulação de serviços não seja o foco principal do Honeytrap, ele possui algumas capacidades básicas para isto. Para alguns serviços, ele pode emular um cmd.exe do Windows com funcionalidades muito básicas. Em alguns poucos casos, ele implementa seus próprios clientes para os serviços com o objetivo de se comportarem como os serviços dos sistemas Windows. Ao receber uma requisição de um atacante, o Honeytrap pode ler respostas padrão para portas específicas a partir de arquivos que basicamente contém as mensagens capturadas dos serviços originais. Quando não existe um template disponível para uma porta, é utilizada uma resposta padrão: que é simplesmente um caracter de nova linha, tal comportamento algumas vezes é capaz de manter a conexão, obtendo melhores resultado que a abordagem de não enviar uma resposta ao atacante. Desta forma, muitos atacantes podem ser enganados e enviar respostas para o processo servidor do Honeytrap. O honeypot também pode analisar uma string de ataque a procura de comandos que permitam fazer o download de um arquivo a partir do host remoto. Se o comando de download é encontrado, o servidor tenta recuperar automaticamente o arquivo correspondente. O arquivo baixado é então armazenado localmente com o checksum MD5 do mesmo como seu nome. Atualmente, apenas downloads baseados em FTP e TFTP são suportados, entretanto URIs HTTP são reconhecidas e registradas em logs Nebula Nebula (NEBULA, 2009) é um gerador de assinaturas compatível com o formato utilizado pelo Snort para detecção de intrusão de rede, também disponível sob a forma de um plugin do Honeytrap. Ele pode ajudar a proteger a rede produzindo regras para IDSs a partir de traces de ataques. Normalmente, o Nebula é executado como um daemon e recebe os ataques recebidos por honeypots (atualmente suporta os formatos usados pelo Honeytrap e pelo Argos(PORTOKALIDIS, 2009)). Ele é capaz de processar milhares de traces em poucos minutos e funciona de forma a encontrar padrões entre os fluxos de dados capturados para a geração de assinaturas. A medida que mais ataques vão sendo submetidos, as assinaturas tornam-se mais elaboradas e precisas e o Nebula é capaz de gerar novas versões atualizadas das mesmas. Como caso de uso recente, o Nebula foi utilizado por integrantes do Honeynet Project para

74 73 gerar uma assinatura Snort para as variantes A e B do worm Conficker, obtendo ótimos resultados (LEDER, 2009). Fatos como estes demonstram a importância da tecnologia de honeypots bem como a sua integração com outras abordagens já bastante difundidas, como os NIDSs Libemu Libemu é uma pequena biblioteca, desenvolvida por Paul Baecher e Markus Koette em 2007 e escrita em C para sistemas Unix, que oferece capacidades de emulação básica de instruções x86 e detecção de shellcode utilizando heurísticas para detecção de determinados padrões. Seu desenvolvimento é voltado para a aplicação em sistemas de detecção (ou prevenção) de intrusão de redes e honeypots. Ela suporta a execução de instruções da arquitetura x86 e a leitura de seus códigos binários, com suporte a API do Windows 32 bits (win32), útil no processo de execução de shellcodes. A importância dela neste trabalho é o fato do pacote da biblioteca também disponibilizar a aplicação sctest, que é parte do conjunto das aplicações de teste da libemu. Este aplicativo é muito útil para a extração de dados como portas e IPs do atacantes obtidos por meio de traces (hexdumps) disponibilizados por determinadas ferramentas, como é o caso do Honeytrap. 3.6 SSH Honeypot SSH (Secure Shell) é um protocolo que permite a troca de dados de forma segura, garantindo a confidencialidade e integridade dos dados sobre uma rede insegura. Ele foi projetado para substituir a utilização do protocolo Telnet e de outros shells remotos inseguros, que enviam informações (dentre elas a senha de acesso) em texto plano, possibilitando que dados críticos sejam facilmente interceptados. O SSH pode ser considerado o protocolo de shell seguro de facto para sistemas like-unix. O SSH possui várias implementações, tanto livres como proprietárias, sendo que a mais conhecida delas é o OpenSSH (que utiliza a versão 2 do protocolo). Esta implementação é conhecida por sua confiabilidade e por ter um histórico de poucas falhas de segurança (ou mesmo pela rapidez na correção desta falhas, nos casos que ocorreram) nas suas versões estáveis, além de ser livre. O protocolo também permite a utilização de diferentes métodos de autenticação (como, por exemplo, por meio de senhas ou atráves do sistema de criptografia de chave pública). No entanto, a forma mais comum de autenticação é realmente atráves do par (usuário, senha) re-

75 74 querido na parte inicial da conexão, que é conferido com a base de usuários da máquina e se as informações dadas estiverem corretas, o acesso ao host remoto é permitido. Esta forma de autenticação, por sua própria natureza, torna-se um ponto a ser explorado por atacantes. Percebe-se então que embora o protocolo em si seja bastante seguro e raramente apresente falhas de segurança, a utilização deste método de autenticação permite o sistema seja invadido em razão de uma senha fraca escolhida por algum usuário. Para explorar esta possível vulnerabilidade, os atacantes fazem uso de ferramentas automatizadas para quebra das senhas atráves de força bruta, utilizando para isso um conjunto préselecionado de conjuntos (usuário, senha) que comumente são utilizados Ferramentas utilizadas para ataques SSH via força bruta Existem várias ferramentas para tentativas de ataques de força bruta baseadas em dicionários contra servidores SSH. Algumas bases de usuários e senhas são facilmente encontradas na Web, assim como também é possível e fácil montar listas próprias com os nomes que possam ter uma boa possibilidade de serem usados como senhas fracas. Uma destas ferramentas é o script brutessh2, que se tornou público em 2004, e disponível em implementações em diversas linguagens como C, Python ou Shell Script e que automatiza este processo necessitando apenas do fornecimento de poucas informações como o host a ser atacado, a porta onde está o servidor SSH e o arquivo que contém o dicionário com usuários e senhas a serem usados no ataque Kojoney SSH Honeypot Honeypots especializados em capturar ataques deste tipo contra o serviço SSH podem ser utéis na obtenção de informações como, por exemplo, para determinar quais são os nomes de usuários e as senhas presentes nos dicionários usados pelas ferramentas automáticas de ataques via força bruta. Além disso, pode-se determinar a origem do ataque, número de tentativas, etc. e principalmente fornecem ao atacante um terminal remoto falso que permite o registro dos comandos utilizados por estas ferramentas ou até mesmo por agentes humanos que invadiram o honeypot. Para a tarefa de examinar o comportamento destes ataques, foi escolhido o Kojoney (CORET, 2009): um honeypot de baixa interatividade, escrito em Python e desenvolvido por José Antonio Coret, especializado em ataques SSH. Uma outra opção de honeypot para avaliar este tipo de ataque seria a utilização do Honeyd com um script que emulasse um prompt SSH; entretanto a

76 75 construção deste script seria custosa e muito provavelmente não forneceria as funcionalidades providas pelo Kojoney. O Kojoney é um honeypot que emula um servidor SSH, provendo suporte a autenticação via usuário/senha ou chave pública. A base de dados utilizada para permitir ou negar acesso ao falso shell remoto é armazenada em um arquivo (chamado fake_users), que lista as combinações de usuário e senha aceitas como válidas. Ele também realiza uma forma simplificada de detecção de atacantes humanos (acesso não automatizado), por meio da procura de caracteres equivalentes as teclas DELETE ou BACKS- PACE nos comandos executados. Além disso, apresenta funcionalidades como a geração de relatórios sobre os ataques, atráves da ferramenta kojreport.

77 76 4 Ambiente experimental e resultados obtidos 4.1 Introdução Neste capítulo serão apresentados os ambientes utilizados na avaliação de cada um dos honeypots descritos no capítulo 3: Honeyd, Nepenthes, Amun, Honeytrap e SSH Kojoney, além dos resultados obtidos a partir da avaliação de cada um deles. A opção por avaliar estas ferramentas se baseou no fato de que, na época do planejamento da realização deste trabalho, não haviam recursos computacionais suficientes e disponíveis para que se pudessem aplicar soluções relacionadas a segurança de redes como um NIDS (que necessitaria de uma máquina com grande poder de processamento para coleta e análise de todo o tráfego da rede). Além disso, este tipo de abordagem necessitaria de ajustes na configuração do roteador, o que não era desejável, uma vez que ele era responsável por um serviço de produção. Por outro lado, embora houvesse a limitação de recursos de hardware disponíveis, existia uma grande quantidade de endereços IPs públicos e roteáveis na Internet que não estavam sendo utilizados dentro da rede do PoP-ES. Além disso, a abordagem dos honeypots pareceu também ser aplicável para a tarefa de detecção de ataques em redes departamentais da universidade, onde normalmente não há possibilidade nem recursos para a instalação de, por exemplo, um NIDS como o Snort. Aliado a estes fatores, viu-se nos estudos dos honeypots uma boa oportunidade para que fossem adquiridos conhecimentos relacionados a área de segurança de redes a partir de ambientes e dados reais. 4.2 Experimentos com o Honeyd Conforme visto na seção 3.2, o Honeyd é um framework para a criação de honeypots virtuais bastante flexível em sua configuração. Entretanto, para fins de experimentação, não foram

78 77 utilizadas as funcionalidades disponíveis de execução de serviços a nível de aplicação. Ao invés disso, o objetivo determinado foi o de usar a ferramenta para analisar apenas as características do tráfego malicioso a nível de rede (relacionados a endereços IP) e a nível de transporte (relacionados às portas e protocolos utilizados). Com isso, foi possível a obtenção de estatísticas sobre as portas mais atacadas, os protocolos mais utilizados, a origem dos ataques, entre outras informações. Adicionalmente, foi ativado o plugin Honeycomb, apenas para avaliar a quantidade de assinaturas geradas para o caso em que não existem serviços ao nível de aplicação vinculados ao Honeyd Descrição do ambiente e recursos utilizados A primeira tarefa para a montagem do ambiente foi alocar uma máquina física dedicada exclusivamente à execução do experimento. Conforme dito no capítulo 2, os honeypots (principalmente os de baixa interatividade) não requerem uma máquina poderosa em termos de processamento e memória, podendo utilizar máquinas que não são mais usadas para serviços de produção. Pois foi justamente o caso; a máquina utilizada para este experimento pertencia a um antigo cluster e já não era mais utilizada para serviços de produção. A máquina montada foi um Athlon 1800 XP (arquitetura x86) com 768 MB de memória RAM, configuração mais que suficiente para a execução do Honeyd, tanto em termos de processamento como em termos de memória disponível. O sistema operacional utilizado foi o Linux CentOS 5.2, pois verificou-se 1 que esta distribuição possibilitava uma instalação completa (com todas as funcionalidades, inclusive com suporte a integração com o plugin Honeycomb) da última versão do Honeyd (1.5c) a partir do código-fonte. Como a máquina física se tratava de um hardware já bastante utilizado (descartado para serviços de produção e montado a partir da composição de peças de outros computadores) e também por não existir conhecimento prévio sobre a estabilidade da instalação da última versão do Honeyd no CentOS 5.2, foram desenvolvidos pequenos scripts para que caso os processos do Honeyd ou ARPd caíssem, o tempo de restabelecimento deles não se estendesse por mais de 60 segundos. (Após o experimento verificou-se que este mecanismo foi pouco utilizado, o que significa que o Honeyd e ARPd conseguiram ficar dias e dias executando sem que ocorresse alguma quebra nestes serviços). 1 Na verdade, descobriu-se depois de várias instalações do Honeyd no Debian que resultaram em segmentation fault quando uma resposta ICMP do honeypot era requerida. :)

79 78 Outro cuidado tomado foi manter o ajuste do relógio do computador, sincronizando-o periodicamente com um servidor NTP (Network Time Protocol). Isso é muito importante para que se mantenha a confiabilidade dos dados existentes no arquivo de log em termos temporais. Para este experimento, foram alocados 11 (onze) endereços IP públicos contíguos para os honeypots virtuais mais 1 (um) para a máquina física que abrigou o Honeyd. Para fins de não divulgação dos nomes e IPs reais da máquinas físicas e honeypots, serão utilizados nomes e identificação diferentes com o intuito de anonimizar as máquinas, uma vez que estes serviços de monitoramento atráves de honeypots poderão ser utilizados posteriormente na rede do PoP- ES. Assim a máquina física deste experimento será chamada de fisica, e a ela também foi atribuído um endereço IP que será considerado como IP00. Esta máquina abriga o Honeyd. Por sua vez, os honeypots virtuais serão referenciados como IP01 a IP11. A configuração escolhida no Honeyd para coletar informações sobre as características do tráfego ao nível de rede e transporte baseou-se em criar 11 honeypots virtuais (cada qual com um IP diferente) utilizando o mesmo template, e portanto possuindo os mesmos comportamentos. As configurações deste template liberavam a comunicação para todas as portas TCP, UDP e também permitia o envio e recebimento de mensagens ICMP, conforme visto na figura 6. Figura 6: Trecho da configuração do Honeyd responsável pelo comportamento do template e por associar os endereços IP aos honeypots virtuais. Para que os honeypots virtuais gerenciados pelo Honeyd pudessem receber as requisições de atacantes externos, era necessário que o tráfego destinado aos endereços IPs aos quais eles estavam configurados fosse direcionado para a máquina física. Dentro deste contexto, foi utilizado o ARPd, que é um daemon cuja tarefa é responder às requisições ARP, realizadas para descobrir a máquina responsável por determinado endereço IP.

80 79 Assim, a função do ARPd é produzir o pacote ARP de resposta e dizer que a interface da máquina física pode responder a requisições referentes a determinado endereço IP configurado para um honeypot virtual do Honeyd. Quando o pacote chega até a interface da máquina física, o Honeyd pode então capturá-lo e fazer as devidas operações com o mesmo, seja abrindo, mantendo ou fechando uma conexão ou até repassando para determinado serviço que esteja configurado. O plugin Honeycomb foi compilado separadamente e depois integrado ao Honeyd. Ele foi utilizado apenas para verificar o funcionamento do mecanismo de plugins do Honeyd e para avaliar como ocorreria a geração de assinaturas de detecção de intrusão e as razões para geração deste tipo de assinaturas. Feita a montagem e configuração do ambiente de experimentação, deixou-se o serviço rodando com esta configuração do dia 19 de janeiro de 2009 até 16 de abril de Entretanto, nos primeiros dias houveram quedas da máquina devido à falta de energia e ocasionais falhas de hardware. Assim, o período de 15 de fevereiro de 2009 (domingo) a 11 de abril de 2009 (sábado) foi escolhido para análise dos dados devido a tratar-se de um período onde o serviço esteve disponível continuamente, totalizando 56 dias, exatas 8 semanas de observação. A partir do arquivo de log de conexões gerado pelo Honeyd, foram então extraídas estatísticas relacionadas ao tráfego malicioso que atingiu os IPs dos honeypots virtuais. Para analisar este arquivo, foi utilizada uma ferramenta de análise de logs chamada Sawmill 2. Importante ressaltar que antes de submeter o arquivo de log para processamento pelo Sawmill, dele foram excluídas as referências a conexões realizadas em direção aos honeypots por máquinas internas da subrede onde eles foram alocados e que rodavam serviços que se utilizam de broadcast ou varreduras periódicas na rede. Isto foi feito para que os resultados não sofressem interferência de atividades desta natureza que existem internamente na subrede. Os resultados obtidos com a ajuda da ferramenta de análise de logs e as discussões sobre alguns aspectos relacionados aos ataques serão apresentados na próxima seção (seção 4.2.2) Descrição dos resultados obtidos Nesta seção, os dados obtidos serão analisados relação a alguns aspectos: a quantidade de pacotes recebidos pelos honeypots diariamente; a quantidade de pacotes e bytes recebidos em relação ao dia da semana; 2 Possui uma versão para plataforma Linux (

81 80 a distribuição do recebimento de pacotes durante o experimento entre as horas do dia; a quantidade de pacotes TCP, UDP, ICMP e de outros protocolos recebidos; os endereços IP de origem que mais enviaram pacotes aos honeypots; os países responsáveis por enviarem as maiores quantidades de pacotes; o número de pacotes recebidos por cada honeypot virtual; as portas de destino mais atacadas; os sistemas operacionais usados nas máquinas de origem dos ataques ou port scan. Por fim, são feitas análises pontuais sobre a natureza do tráfego malicioso para os 4 (quatro) dias que apresentaram maior quantidade de pacotes recebidos. A primeira análise realizada foi a do comportamento do número de pacotes recebidos pelos honeypots durante os 56 dias de observação. A figura 7 mostra a série temporal do número de pacotes recebidos a cada dia. A tabela 2 indica os 10 dias com maior quantidade de pacotes recebidos durante todo o período de observação: Figura 7: Série temporal com a quantidade de pacotes recebidos a cada dia pelos honeypots virtuais do Honeyd (período de 15 de fevereiro de 2009 a 11 de abril de 2009). Dia Número de pacotes 02/03/ /03/ /03/ /04/ /04/ /03/ /03/ /03/ /03/ /02/ Tabela 2: Dias com a maior quantidade de pacotes recebidos.

82 81 A partir do gráfico e da tabela 2, observou-se que os 4 dias que mais receberam pacotes apresentaram números muito acima da média diária de pacotes, que foi igual a pacotes. Assim, optou-se posteriormente por fazer uma análise pontual desses dias para tentar descobrir algumas características dos ataques que neles ocorreram. Optou-se por não contabilizar o número de bytes recebidos diariamente, uma vez que o Honeyd apenas registra o número de bytes de uma conexão para os pacotes TCP e UDP, não registrando o tamanho dos pacotes ICMP enviados aos honeypots. Como isto poderia gerar conclusões errôneas sobre as características e distribuição do tráfego diário, essa análise foi omitida. A seguir, foi examinada a distribuição do número de pacotes recebidos em relação ao dia da semana 3. A figura 8 mostra o histograma relativo a quantidade de pacotes recebidos pelos honeypots virtuais em relação a este critério. Figura 8: Histograma relativo a quantidade de pacotes recebidos pelos honeypots virtuais do Honeyd em relação ao dia da semana. A tabela 3 indica a soma dos pacotes recebidos em cada dia da semana durante o período de observação. Dia da semana Número de pacotes Segunda-feira Quarta-feira Domingo Quinta-feira Sábado Sexta-feira Terça-feira Tabela 3: Dias da semana e o número total de pacotes recebidos (ordenado descrescente pelo número de pacotes). Ao visualizar o gráfico com a distribuição dos pacotes em relação ao dia da semana, inicialmente pode-se supor que segunda e quarta-feira foram os dias preferenciais para ataques. 3 Para tornar mais justa esta análise, o período de observação foi escolhido como exatamente igual a 8 semanas.

83 82 Entretanto, tal afirmação não é verdadeira, uma vez que estas diferenças de valores são, em grande parte, consequência da grande quantidade de pacotes que chegaram em dias específicos, como por exemplo, 02 de março de 2009 (segunda-feira; pacotes) e 04 de março de 2009 (quarta-feira; pacotes). Figura 9: Histograma relativo a quantidade de bytes recebidos pelos honeypots virtuais do Honeyd em relação ao dia da semana. Se for vista a distribuição do número de bytes recebidos em relação aos pacotes TCP e UDP e agrupados pelo dia da semana (figura 9), pode-se perceber que a quantidade de bytes recebidos é mais constante, sem diferenças tão significativas como em relação ao gráfico com relação ao número de pacotes. Isto reforça a hipótese dos ataques não terem um dia específico de incidência muito acentuada em relação aos demais, principalmente devido ao fato de a maioria deles serem automatizados. Outra estatística extraída foi relativa à distribuição dos pacotes em relação a hora do dia em que foram recebidos. As figuras 10 e 11 mostram estas distribuições em relação ao número de pacotes e bytes recebidos, respectivamente. Figura 10: Histograma relativo a quantidade de pacotes recebidos pelos honeypots virtuais do Honeyd em relação a hora do dia.

84 83 Figura 11: Histograma relativo a quantidade de bytes recebidos pelos honeypots virtuais do Honeyd em relação a hora do dia (apenas pacotes TCP e UDP foram contabilizados). Observando gráficos das figuras 10 e 11, pode-se perceber que também não há uma preferência acentuada por um horário em especial. Isto pode também ser explicado pelo fato de que a grande maioria dos ataques serem automatizados e de não requisitarem intervenção humana. Desta forma, mesmo em horários do período da madrugada, existe um nível de tráfego malicioso considerável em relação aos outros horários, não existindo, por exemplo, a clássica curva de comportamento rotineiro humano 4 presente muitas vezes quando se monitora, por exemplo, o tráfego geral de um LAN. Outro motivo que justifica este comportamento é o fato de muitos ataques serem realizados com origem em outros países, onde existem diferentes fuso horários. A próxima estatística extraída dos dados foi relativa aos protocolos utilizados na camada de transporte. A tabela 4 mostra o número de pacotes TCP, UDP, ICMP e IGMP manipulados pelo Honeyd; bem como o número de bytes recebidos em relação aos protocolos TCP e UDP (o Honeyd não registra o tamanho dos pacotes ICMP e IGMP). Protocolo Pacotes Percentual Bytes (MB) TCP ,4% 115,97 ICMP ,4% UDP ,1% 2,54 IGMP 470 0,1% Tabela 4: Número total de pacotes recebidos em relação a cada protocolo identificado pelo Honeyd. A tabela 4 mostra que 87,4% dos pacotes recebidos utilizam o TCP na camada de transporte. Pacotes maliciosos deste tipo estão relacionados, por exemplo, a worms e ataques SSH. Já os pacotes maliciosos UDP são normalmente utilizados em tentativas de negação de serviço ou em determinadas opções de port scan. Os pacotes UDP representaram apenas 6,1% dos recebidos pelos honeypots durante o período de observação. 4 Aqui deseja-se referir ao comportamento do tráfego que segue o padrão das atividades humanas, majoriatariamente, diurnas.

85 84 Por sua vez, 6,4% dos pacotes eram ICMP; neste caso não há como determinar o motivo de seu uso uma vez que eles podem ser utilizados desde para a varredura de hosts a partir de ping feitos por usuários (ou worms) até ataques de negação de serviço baseados no envio de pacotes ICMP. E finalmente, apenas uma pequena parcela dos pacotes (0,1%) foram relativos ao protocolo IGMP. Aqui também não é possível afirmar a natureza destes pacotes uma vez que o Honeyd apenas registra poucas informações sobre eles. As vulnerabilidades mais comuns que utilizam esse tipo de protocolo estão relacionadas a falhas na família de sistemas operacionais Windows. Em seguida, após analisar o tipo dos protocolos de camada de transporte envolvidos, verificouse quais foram os endereços IP que mais enviaram pacotes durante o período de observação do honeypot, bem como os principais países de onde estas conexões foram originadas. A tabela 5 reúne os 10 endereços IPs que mais enviaram pacotes para o honeypot. IP de origem País Pacotes Percentual do total de pacotes Brasil ,5% Hong Kong ,1% Argentina ,9% Estados Unidos ,8% China ,4% Estados Unidos ,8% China ,1% Quênia ,0% China ,0% México ,8% Tabela 5: Endereços IP que mais enviaram pacotes para os honeypots virtuais. A classificação dos endereços IP mais ativos em termos de atividades maliciosas mostra que o que enviou a maior quantidade de pacotes é um endereço da Internet brasileira. Tal fato pode estar relacionado a proximidade geográfica entre os hosts ou a algum processo de infecção por um worm que escolheu a rede como vítima por estar dentro do bloco /8. A lista também traz outros endereços IP de países já conhecidos pelo nível considerável de atividades maliciosas como a China (incluindo Hong Kong 5 ), os Estados Unidos e a Argentina. O único fato mais peculiar é o fato de um endereço IP do Quênia estar nesta lista, o que pode ser considerado um fato pontual e isolado. É importante lembrar também que o verdadeiro controlador dessas atividades maliciosas pode estar em situado em outros países, utilizando esses hosts por estarem infectados com algum worm ou terem sido comprometidos de alguma 5 Embora Hong Kong seja politicamente pertencente à China, pode ser considerado como um país no ecossistema da Internet, principalmente pelas diferenças relativas quanto à censura da Internet em relação a outras regiões da China.

86 85 forma. A tabela 6 mostra os principais países que foram origem dos ataques destinados aos honeypots. País Pacotes Percentual do total de pacotes Bytes (MB) Brasil ,7% 4,09 MB China ,2% 13,84 MB Estados Unidos ,2% 18,29 MB Argentina ,0% 1,06 MB Hong Kong ,4% 15,31 MB Japão ,4% 15,31 MB Taiwan ,3% 6,31 MB México ,0% 2,42 MB Alemanha ,7% 5,07 MB Reino Unido ,7% 6,22 MB Tabela 6: Lista com os 10 países que mais enviaram pacotes aos honeypots virtuais. Pela tabela 6, vê-se que novamente o Brasil é o responsável pelo maior número de pacotes, seguido de China, Estados Unidos e Argentina e dos demais países. Esta observação é condizente com outros trabalhos como o de (STEDING-JESSEN; VIJAYKUMAR; MONTES, 2008), pois comparando a lista dos 10 países responsáveis pelas maiores quantidades de atividades maliciosas com a lista disponível no trabalho de Jessen et al. (que apresentava os 10 mais países que mais originaram spam), observa-se que existem 6 países em comum entre as duas listas. Deve-se ressaltar, porém, que as abordagens adotadas foram bastante distintas entre os dois trabalhos, sendo que em (STEDING-JESSEN; VIJAYKUMAR; MONTES, 2008) a classificação foi feita por número de spams enviados. Também com o trabalho (POUGET; DACIER; PHAM, 2004), ao realizar a comparação com a lista disponível no artigo, são encontrados 6 países em comum (no caso, Estados Unidos, China, Taiwan, Japão, Alemanha e Reino Unido). Outro aspecto analisado foi a quantidade de pacotes que chegaram a cada um dos honeypots virtuais criados (lembrando que todos eles possuem a mesma configuração quanto a comportamento). A tabela 7 exibe a quantidade de pacotes e bytes recebidos por cada um dos honeypots. Os dados obtidos mostram que os ataques se distribuíram de forma aproximada pelos honeypots; sendo que a diferença do entre o honeypot que mais recebeu (IP01) em relação ao que menos (IP05) recebeu pacotes foi de 33,5%, o não chega a ser uma diferença exagerada (maior que 100%). Analisando este fato com relação ao número de bytes recebidos de pacotes que utilizam os protocolos UDP e TCP, tem-se que a diferença entre o que mais e o que menos recebeu bytes foi de 48,9%.

87 86 Honeypot Pacotes Bytes (MB) IP ,42 IP ,57 IP ,75 IP ,11 IP ,43 IP ,22 IP ,56 IP ,00 IP ,62 IP ,80 IP ,03 Tabela 7: Quantidade de pacotes e bytes recebidos por cada honeypot virtual durante o período de experimentação. As figuras 12 e 13 ilustram a quantidade de pacotes e bytes por eles recebidos em forma de gráficos de barras. Figura 12: Gráfico de barras com a quantidade de pacotes recebidos por cada honeypot virtual durante o período de experimentação. As diferenças nos valores se devem ao fato de que diferentes atacantes lançaram quantidades distintas de pacotes ao honeypots e que, em geral, os ataques não sondam todos os honeypots, mas apenas parte deles. A princípio, não existem motivos para que um dos endereços IP seja mais atacado, uma vez que todos os honeypots possuem os mesmos e poucos atrativos.

88 87 Figura 13: Gráfico de barras com a quantidade de bytes recebidos (apenas referentes aos pacotes que utilizaram os protocolos UDP e TCP) por cada honeypot virtual durante o período de experimentação. Em seguida, foi obtida a lista com as portas mais visadas pelos atacantes durante o período de observação do honeypot. A tabela 8 reúne as 10 portas mais visadas pelos atacantes durante o período em que os ataques foram analisados. Porta Pacotes Tabela 8: As 10 portas mais visadas pelos atacantes durante o período de experimentação do honeypot. As duas primeiras portas (1433 e 445) são usadas normalmente em serviços providos dentro da plataforma Windows: o Microsoft SQL Server e o serviço de compartilhamento de arquivos e recursos (SMB). A terceira porta mais visada foi a 22, que é a porta padrão utilizadas pelos servidores SSH. A quarta e quinta porta (139 e 135) são também utilizados por serviços Windows: o NetBIOS Session Service e o DCE/RPC Locator service (que é usado para gerenciar remotamente serviços como servidor DHCP, DNS e WINS), respectivamente. A sexta porta da relação foi a 3306, utilizada pelo sistema de banco de dados MySQL. A sétima foi a 1080,

89 88 relacionada normalmente a proxies SOCKS. A oitava foi a famosa porta 80, utilizado por servidores Web (como Apache e Microsoft IIS, por exemplo). A nona foi a 2967 relacionada ao anti-vírus Symantec e a décima foi 6588, relacionada ao proxy AnalogX (utilizado por alguns worms). Quanto aos sistemas operacionais utilizados nos computadores de origem de ataques, verificouse que a grande maioria dos pacotes, onde foi possível realizar a resolução remota do sistema operacional do host atráves da base de fingerprinting do Nmap ou Xprobe, eram provenientes de sistemas Windows. Em menor escala, foram detectados pacotes advindos de sistemas Linux e ainda uns poucos pacotes com origem em um sistema Solaris. A tabela 9 sumariza estas informações. Sistema Operacional Pacotes Windows XP SP Linux Windows XP Windows Windows 2000 RFC Windows Linux Windows NT Solaris Tabela 9: Quantidade de pacotes originados de determinadas versões de sistemas operacionais (identificados por meio de fingerprinting remoto). O fato de que a grande parte dos pacotes ter sido originado de sistemas Windows é coerente com a lista de portas mais utilizadas para os ataques, pois a maioria delas está ligada a serviços que executam exclusivamente em estações Windows ou que tem versões instaláveis neste sistema (caso do MySQL). Quanto a execução do Honeycomb, observou-se que o mesmo gerou um número muito grande de assinaturas (resultando em um arquivo texto de 1,1 GB). No entanto, estas regras eram pouco expressivas (conforme podem ser vistas na figura 14), baseando-se em combinações pouco usuais de flags TCP e ou endereços IP e portas de origem e destino, e que dificilmente poderiam ser utilizadas em ambientes reais. Outro ponto negativo foi a geração de regras referente a tráfego de broadcast e endereços multicast, gerados por algumas máquinas legítimas que pertenciam a mesma sub-rede onde foram feitos os experimentos.

90 89 Figura 14: Exemplo de assinatura gerada (no formato Bro) pelo Honeycomb em decorrência dos pacotes recebidos pelos honeypots virtuais. De certa forma, estes resultados com o Honeycomb eram esperados, uma vez que não foi ativado nenhum serviço a nível de aplicação na configuração do Honeyd. É preciso considerar portanto que a ferramenta deve ser melhor investigada em algum trabalho futuro em um ambiente de tráfego mais controlado e também restrito a algum serviço ao nível de aplicação. Examinados os vários aspectos até aqui descritos, considerou-se adequada a realização de análises pontuais para tentar descobrir as características do tráfego nos dias em que ocorreram maior incidência de pacotes para os honeypots. Desse modo, foram analisados os dias 02/03/2009, 04/03/2009, 15/03/2009 e 08/04/ Análise do tráfego relativo ao dia 02/03/2009 Restringindo a análise do arquivo de log apenas à parte relativa aos ataques ocorridos no dia 02 de março de 2009, procurou-se analisar os outros campos para tentar descobrir que tipo de ataque ocasionou este número de pacotes muito acima da média. Utilizando as estatísticas extraídas por meio da ferramenta Sawmill, detectou-se que dos pacotes recebidos, 99,2% (ou pacotes) deles empregavam TCP, enquanto 0,6% (ou 451 pacotes) eram UDP e apenas 0,2% (114 pacotes) eram mensagens ICMP. Verificou-se também que os pacotes foram recebidos por todos os honeypots virtuais em nível aproximadamente equivalente. Ao examinar os endereços IP de origem dos pacotes, observou-se que 91,1% (65.303) deles vieram do endereço IP : um IP da Internet brasileira, sob a responsabilidade de uma empresa de internet a cabo 6 e que estava alocado no momento do ataque para uma máquina Windows XP. De maneira complementar a informação anterior, verificou-se quais portas de destino foram mais visadas. O resultado encontrado foi que 93,5% dos pacotes (67.008) tinham como destino 6 Foi utilizada a ferramenta whois para a determinação desse tipo de informação.

91 90 a porta 1433/TCP [a segunda porta mais visada foi a 22/TCP, responsável por apenas 1,6% (1128) do total de pacotes]. Dadas as informações obtidas, pode-se afirmar que o host em questão tentou explorar seguidamente uma vulnerabilidade na porta (1433/TCP) utilizada pelo servidor de banco de dados Microsoft SQL Server. Possivelmente, tratou-se da ação de um worm que tinha por objetivo infectar a máquina e se propagar pela rede. O mais famoso worm (e ainda existente de forma ativa na Internet) que explorou uma vulnerabilidade na porta em questão foi o Slammer (MS-SQL worm), lançado em Embora em menor escala, os pacotes com destino a porta 22/TCP possivelmente tinham como propósito tentar explorar servidores SSH que possuem autenticação por usuário e que contenham senhas fracas. A título de curiosidade, os atacantes em questão utilizavam máquinas Linux 2.6.x, sendo que dos dois mais ativos, um estava utilizando um endereço IP da Índia ( ) e outro estava utilizando um IP ( Universidade Federal de Goiás) pertencente ao mesmo AS (Autonomous System) em que está inserida a rede do PoP-ES Análise do tráfego relativo ao dia 04/03/2009 Limitando agora a análise dos dados apenas aos pacotes recebidos no dia 04 de março de 2009, detectou-se que dos pacotes recebidos, 98,2% (ou pacotes) eram TCP, enquanto 1,3% (ou 512 pacotes) eram UDP e apenas 0,5% (190 pacotes) eram referentes a mensagens ICMP. Ao analisar o IP de origem dos pacotes, observou-se que 86,5% (33.310) deles vieram do endereço IP , que é um IP da Internet argentina. Além disso, os pacotes foram recebidos por todos os honeypots virtuais, mas em maior volume para os endereços IP01, IP02 e IP10 (não foi possível determinar o motivo deste comportamento). Quando observadas as portas para as quais se destinavam os pacotes, viu-se que 88,8% deles ( pacotes) tinham como destino a porta 1433/TCP e que a segunda porta mais visada foi a 445/TCP, responsável por 4,4% deles (1.678 pacotes). As afirmações feitas em relação à porta 1433/TCP na análise do dia 02/03/2009 também se aplicam aqui (novamente a maior quantidade de pacotes observada referiu-se a tentativas de exploração de um possível servidor Microsoft SQL Server). Quanto aos pacotes visando a porta 445/TCP, observou-se que estes pacotes foram recebidos a partir de diversas fontes localizadas em diversos países como Noruega, França, Reino Unido, Brasil, Índia, Estados Unidos, Japão, etc. Os serviços Windows que utilizam esta porta

92 91 tem um longo histórico de vulnerabilidades exploradas, a última delas foi explorada pelo worm Conficker, que ganhou visibilidade recentemente ao infectar milhões de máquinas em todo o mundo Análise do tráfego relativo ao dia 15/03/2009 O tráfego relativo ao dia 15 de março de 2009 foi selecionado empregando os mesmos procedimentos aplicados ao arquivo de log anteriormente. A partir das informações obtidas, detectou-se que dos pacotes recebidos, 98,2% (ou pacotes) eram TCP, enquanto 1,0% (ou 356 pacotes) eram UDP e apenas 0,8% (286 pacotes) eram mensagens ICMP. Começando a investigação pelo IP de origem dos pacotes, observou-se que 85,5% (30.724) deles vieram do endereço IP , que é um IP com origem em Hong Kong. Além disso, os pacotes foram recebidos por todos os honeypots virtuais, mas em maior volume pelos endereços IP03, IP04, IP05, IP06 e IP09 (também aqui não foi possível determinar a razão de tal comportamento). Quando observadas as portas de destino dos pacotes, viu-se que a porta que teve maior número de pacotes recebidos foi a 445/TCP, mas com apenas 4,0% (1.424) do total de pacotes. Em seguida, as portas 1433/TCP, 22/TCP, 5900/TCP, 2967/TCP, 80/TCP, 1434/TCP, 8080/TCP e 1080/TCP também foram sondadas. Além delas, outras 1096 portas foram contactadas. Essa forma de distribuição de pacotes entre muitas portas de forma bastante diversificada, sem que um número acentuado de pacotes se concentre em uma determinada porta, é característica de atividades de port scan, realizadas por ferramentas como o Nmap Análise do tráfego relativo ao dia 08/04/2009 Por último, analisou-se o dia com o quarto maior número de pacotes recebidos (08 de abril de 2009) e o último a receber mais que duas vezes a quantidade média diária de pacotes verificada durante o período de experimentação. Novamente, verificou-se que a grande parte dos pacotes recebidos eram TCP [92,8% (ou pacotes)], enquanto 5,7% (ou pacotes) eram UDP e apenas 1,2% (322 pacotes) eram relativas a mensagens ICMP. Além disso, os pacotes foram recebidos por todos os honeypots virtuais, distribuídos de forma quase igualitária. Ao analisar o endereço IP de origem dos pacotes, observou-se que 35,9% (9.990) deles vieram do endereço IP , que é um IP com origem na China e que 29,4% (8.173)

93 92 vieram do endereço IP , que é um IP com com origem nos Estados Unidos. Verificou-se também que o host com endereço IP da China realizou uma varredura entre as portas 1024 a 1517, totalizando 493 portas escaneadas neste intervalo. Por sua vez, os pacotes provenientes do endereço IP , destinaram-se unicamente às portas 6588/TCP e 1080/TCP. Estas portas são comumente usados por spammers que possivelmente estavam à procura de servidores proxies abertos (SOCKS e AnalogX). Análises de outros determinados trechos do arquivo de log, selecionados segundo dado critério, também podem ser feitos a partir da ferramenta Sawmill, possibilitando o entendimento de outras ações específicas ocorridas durante o tempo em que os eventos foram registrados. 4.3 Experimentos com o Nepenthes Na seção 3.3, os componentes e o funcionamento do honeypot Nepenthes foram explanados. O experimento envolvendo-o foi utilizado com o objetivo de se conseguir informações sobre as características de propagação dos worms, bem como testar a eficácia da ferramenta. Como foi observado nos resultados obtidos a partir do ambiente montado envolvendo o Honeyd (seção 4.2), a exploração de vulnerabilidades por worms está entre as atividades maliciosas mais comuns da Internet; daí a fundamental importância de avaliar algumas características desse tipo de ameaça Descrição do ambiente utilizado Para este experimento, foi alocada uma máquina Compaq Pentium MHz (arquitetura x86) com 384 MB de memória RAM e que possuia Linux Debian 4.0 como sistema operacional. Da mesma forma que no caso do Honeyd, foram também desenvolvidos scripts para que o tempo de restabelecimento dos processos, em caso de queda, não ultrapassasse 60 segundos. Igualmente, era realizada a sincronização periódica do host com um servidor NTP. A (então) última versão do Nepenthes (0.2.2) foi instalada e configurada e um único endereço IP público foi alocado para a máquina. A configuração escolhida para o Nepenthes foi a de habilitar todos os módulos de vulnerabilidade estáveis existentes, com o intuito de se capturar a maior quantidade e variedade de worms possível. Após a configuração, deixou-se o serviço disponível para acesso público, iniciando-se o processo de coleta de dados no dia 02 de janeiro de 2009 e com término em 13 de abril de 2009

94 93 (total de 102 dias). Os logs e os binários coletados foram então analisados com a ajuda de scripts personalizados para a geração de estatísticas com relação: ao número diário de interações com worms realizadas pelo Nepenthes (que resultaram em coleta de binário ou não); aos endereços IP e países de origem dos ataques; aos protocolos utilizados na transferência dos binários; aos binários mais baixados (identificados pelo seu MD5sum). Posteriormente, o conjunto de binários coletado foi submetido ao webservice VirusTotal 7 para verificar a porcentagem de arquivos identificados pelos diversos programas anti-vírus existentes no mercado, bem como os tipos de binários mais coletados pelo Nepenthes Descrição dos resultados obtidos Durante todo o período de observação foram registradas 940 interações de worms com o Nepenthes, incluídas aquelas ocasiões onde ocorreram falhas durante o processo de download dos binários. Do total de interações com o intuito de coleta de malwares, por 571 vezes o download do binário ocorreu com êxito e como resultado foram armazenados 254 binários maliciosos diferentes (com um tamanho total de aproximadamente 32 MB). Além disso, 662 interações referentes ao Slammer foram detectadas pelo Nepenthes. Neste caso, o programa não registra seus binários, deixando os registros relacionados a este worm em um arquivo de log diferente de onde se registram as comunicações com outros worms em que os binários são eventualmente baixados. A figura 15 ilustra a distribuição diária do total de interações registradas pelo Nepenthes, enquanto que a figura 16 indica a distribuição referente somente às ocasiões onde ocorreram coleta de binário. Por sua vez, a figura 17 refere-se somente às interações referentes ao Slammer (MS-SQL worm). 7

95 94 Figura 15: Série temporal das interações diárias registradas pelo Nepenthes (com downloads bem sucedidos ou não). Figura 16: Série temporal das interações diárias registradas pelo Nepenthes (apenas as que resultaram em downloads bem-sucedidos). Figura 17: Série temporal das interações diárias registradas pelo Nepenthes com relação ao Slammer. Observou-se que a quantidade de interações durante o tempo do experimento apresentou um comportamento variável, com um número médio de interações menor durante o terço final

96 95 do tempo do experimento. Entretanto, não é possível afirmar que o número de interações diárias apresentava uma tendência de queda uma vez que outro pico de atividade poderia ocorrer nos dias posteriores ao término do experimento. O máximo de interações registradas em um dia foi 34 (03/01/2009), sendo registrada a média de 9,21 interações por dia, equivalente a uma interação a cada duas horas e meia, aproximadamente. Por sua vez, o dia 05 de janeiro de 2009 registrou a maior quantidade de interações onde foi possível obter, de forma bem-sucedida, o binário resultante da comunicação com o worm. A média diária de interações com download completo de binário foi igual a aproximadamente 5,60; ou um binário obtido a cada 4 horas e 15 minutos, aproximadamente. Quanto às interações relacionadas ao Slammer, foi registrado um máximo de 13 interações no dia 21 de março de 2009; com média de 6,50 interações por dia e equivalente a uma detecção da atividade do worm a cada 3 horas e 40 minutos. A próxima investigação realizada foi quanto aos endereços IP e países de onde se originaram os ataques. As tabelas 10 e 11 mostram os endereços IP e países com o maior número de interações registradas pelo Nepenthes durante o período de observação. Endereço IP País de origem Número de interações registradas Chile Argentina Brasil Chile Brasil México Guatemala Cuba Brasil México 13 Tabela 10: Os 10 endereços IP com maior número de interações registradas pelo Nepenthes durante o período de observação. É interessante observar o fato de que todos os 10 endereços IP que mais registram interações com o Nepenthes estão situados em países da América Latina. Mais do que uma coincidência, pode-se inferir que, nos worms que tiveram suas interações registradas, existe uma preferência por escanear hosts que pertencem ao mesmo bloco da máquina que está infectada. Isto pode ser percebido na tabela 10, onde todos os endereços IP listados pertencem ao bloco /8. A confirmação desta característica presente nos dados coletados será também verificada nos resultados obtidos por meio do Amunhoney. Quanto às detecções referentes a atuação do Slammer, os endereços IP e países com maior

97 96 País de origem Número de interações registradas Chile 136 Brasil 130 Argentina 101 Estados Unidos 78 China 60 México 51 Japão 38 Colômbia 31 Espanha 24 Taiwan 20 Tabela 11: Os 10 países com maior número de interações registradas pelo Nepenthes durante o período de observação. número de ocorrências são apontados nas tabelas 12 e 13. País de origem Número de interações registradas China 543 Coréia do Sul 23 Japão 22 Estados Unidos 22 Vietnã 15 Irã 7 Brasil 3 República Tcheca 3 Itália 3 Rússia 3 Tabela 12: Os 10 países com maior número de interações registradas pelo Nepenthes referentes ao Slammer (MS-SQL Worm). Neste caso, observou-se que a China foi responsável por 82,0% das interações referentes ao Slammer, o que indica que existem muitos hosts desse país infectados com o worm ou que a vulnerabilidade está sendo utilizada por atacantes chineses. Neste caso específico, não foi registrado o fato dos maiores atacantes serem originários do mesmo bloco /8 da máquina atacada, sendo que o único país da América Latina presente entre os 10 primeiros é o Brasil, mas com insignificantes 3 detecções. Dessa forma, como consequência do grande número de interações registradas, 9 dos 10 hosts que mais foram detectados pelo Nepenthes como infectados pelo Slammer são originários da China (tabela 13). Observe que os hosts pertencem a blocos /8 diferentes, diferentemente do caso registrado para os outros worms detectados. Também examinou-se quais foram os métodos de transferência de arquivos (dentre os suportados pelo Nepenthes) mais utilizados pelos worms capturados. Estes dados foram reunidos

98 97 Endereço IP País de origem Número de interações registradas China China China China China China China China China Coréia do Sul 17 Tabela 13: Os 10 endereços IP com maior número de interações registradas pelo Nepenthes referentes ao Slammer (MS-SQL Worm). na tabela 14. Formas de transferência de arquivo Número de interações registradas Bind shell 250 creceive (método IRC) 227 Connectback shell 49 FTP 29 TFTP 11 HTTP 5 Tabela 14: Formas de transferência do binário durante o processo de captura do worm e o número de ocorrências de cada uma delas. Os resultados indicaram que os métodos de transferência mais usados são relativos a abertura de uma sessão shell Windows (bind shell e connectback shell) ou através da obtenção do binário utilizando o protocolo IRC (possivelmente também relacionado a alguma botnet em que o controlador central usa-o para se comunicar com os hosts infectados) (ZHUGE et al., 2007). Outros métodos de transferência como a utilização de FTP, TFTP e HTTP foram registrados em menor escala. Há de ser lembrado que existe uma tendência atual de novos worms na utilização de protocolos de comunicação P2P (incluindo troca de binários). Essa tendência porém não pôde ser observada com nenhuma das ferramentas utilizadas, devido a falta de suporte das mesmas a esse tipo de comunicação baseada em protocolos próprios. Também investigou-se quais os binários que mais foram obtidos durante todo o período de execução do experimento. O Nepenthes utiliza os hashes MD5sum como critério de diferenciação entre os arquivos. Assim, quando um malware que já está no disco é obtido novamente, ele é descartado, sem criar uma outra (desnecessária) cópia do mesmo. A tabela 15 reúne os 10 binários que apresentaram o maior número de transferências durante as comunicações com os

99 98 worms. Binário (MD5sum) Número de ocorrências cbed a0bf3c92fff9a99cccdc 86 1bcc533cc610257b fd b55ee1164bafdfc66db9bf6e 35 d184a8ac3c26a22d9a e b6257d4d21d51ec13247ee4c1cdb 24 4ec0e5e40d4b97091b7f4ce4e935d d ced22a51cbce a0e2bde02f5ea32d852fe883c4696bcb 10 a832f357e87581beae018e92f8d4a28b 9 b09cf5b bf85ee09d184a2a92 6 Tabela 15: Os 10 binários que mais foram baixados o processo de coleta de worms. Adicionalmente, resolveu-se submeter todos os malwares capturados ao webservice Virus- Total, um serviço que analisa arquivos e indica se eles são maliciosos ou não, de acordo com determinada ferramenta de anti-vírus. Este procedimento tinha por finalidade indicar os principais worms que foram capturados pelo Nepenthes e também avaliar a eficiência de detecção das ferramentas com relação ao conjunto de arquivos obtidos. No total, as respostas de detecção de 41 programas anti-vírus diferentes consultados pelo webservice foram testadas. A tabela 16 reúne os resultados obtidos em relação a cada uma das ferramentas testadas em relação ao conjunto de 254 binários diferentes obtidos pelo Nepenthes. Os resultados mostram que determinados softwares como Panda Antivirus e PCTools sequer alcançaram o patamar de 90% de detecção em relação ao número de malwares, registrando um desempenho bastante inferior ao de outras ferramentas. Interessante observar também que o ClamAV, um software anti-vírus bastante usado em ambientes de software livre, conseguiu uma taxa de detecção pouco acima dos 90%, sendo superado por diversos outros concorrentes. Pode-se inferir então que mesmo com a utilização de ferramentas anti-vírus, os usuários dos sistemas Windows (principalmente de versões mais antigas) não estão totalmente protegidos contra infecções por worms, pois alguns binários maliciosos não são identificados como tal por determinadas ferramentas.

100 99 Anti-vírus Arquivos não detectados Arquivos detectados (%) McAfee-GW-Edition 2 99,2% a-squared 3 98,8% AVG 3 98,8% Ikarus 3 98,8% McAfee+Artemis 3 98,8% AntiVir 4 98,4% BitDefender 4 98,4% F-Secure 4 98,4% GData 4 98,4% Authentium 5 98,0% F-Prot 5 98,0% McAfee 5 98,0% Norman 5 98,0% Rising 6 97,6% Fortinet 7 97,2% Jiangmin 7 97,2% Symantec 7 97,2% VirusBuster 7 97,2% Kaspersky 8 96,8% Avast 12 95,2% CAT-QuickHeal 13 94,8% K7AntiVirus 14 94,5% Microsoft 14 94,5% NOD ,5% Sophos 14 94,5% VBA ,5% etrust-vet 16 93,7% AhnLab-V ,3% TrendMicro 18 92,9% TheHacker 21 91,7% esafe 22 91,3% ClamAV 24 90,5% Sunbelt 24 90,5% DrWeb 26 89,7% ViRobot 30 88,1% Panda 47 81,4% PCTools 48 81,1% Antiy-AVL 69 72,8% Comodo ,7% Prevx ,9% nprotect ,5% Tabela 16: Resultado da avaliação do conjunto de binários coletados com relação à detecção pelas ferramentas anti-vírus (referente ao conjunto coletado pelo Nepenthes).

101 100 Por fim, é importante também determinar quais os tipos de malwares que mais foram coletados pelo Nepenthes. Normalmente, outros autores preferem utilizar o ClamAV para efetuar esta esta análise, principalmente pelo fato do mesmo ser software livre e estar facilmente disponível em muitas distribuições Linux. Entretanto, como ele não obteve um excelente desempenho para o conjunto de arquivos em questão, optou-se por utilizar os resultados obtidos pela ferramenta AVG, que também classifica os worms de uma maneira mais compreensiva e agrupada. Nome do worm (notação AVG) Número de ocorrências Worm/Allaple.B 39 Worm/Allaple.A 35 Worm/Allaple.C 33 BackDoor.RBot.KB 23 Win32/Virut 20 Worm/Allaple.E 19 Win32/Heur 16 Worm/Allaple.D 15 IRC/BackDoor.SdBot2.KWD 11 Generic_c.AGJB 3 Tabela 17: Tipos de malwares coletados pelo Nepenthes (segundo a ferramenta AVG). A tabela 17 aponta que os principais malwares detectados referem-se a variantes do Allaple, ao RBot, ao SdBot, ao Virut e Heur. Tal resultado mostrou-se dentro das expectativas, uma vez que os módulos de vulnerabilidades do Nepenthes não são capazes de capturar todo tipo de malware, mas ainda assim mostraram-se efetivos na captura de algumas classes de worms e bots. 4.4 Experimentos com o Amunhoney Conforme visto na seção 3.4, o projeto de desenvolvimento do Amun(honey) foi baseado nos mesmos princípios de funcionamento do Nepenthes. Assim, entendeu-se como pertinente também avaliar a ferramenta e verificar sua eficácia na coleta de informações sobre os malwares que se auto-propagam pela rede e na coleta dos binários relacionados a estes ataques Descrição do ambiente utilizado Para este experimento, foi necessário alocar uma máquina com a mesma configuração e condições de hardware da utilizada no experimento envolvendo o Honeyd, entretanto foi utilizado como sistema operacional o Linux Debian 4.0 e sendo designada à mesma um único endereço IP público da rede do PoP-ES. Do mesmo modo, foram também desenvolvidos scripts

102 101 para que o tempo de restabelecimento dos processos, em caso de queda, não ultrapassasse 60 segundos; além dos cuidados relativos a sincronização do host com um servidor NTP. A versão utilizada nos testes foi a então (a última da época), disponível via códigofonte. Percebeu-se durante os experimentos que a ferramenta ainda se encontra em caráter experimental de desenvolvimento, sendo que o mecanismo de restabelecimento dos processos do Amun foi bastante útil neste caso. Quanto à configuração, habilitou-se todos os módulos de vulnerabilidade existentes no Amun. Por esta razão, não seria possível colocar o Nepenthes e Amun executando em uma mesma máquina ao mesmo tempo, uma vez que eles tentariam escutar as requisições nas mesmas portas (e que já estariam sendo utilizadas). O período de observação iniciou-se no dia 06 de fevereiro de 2009 até o dia 09 de abril de 2009 (63 dias). Algumas análises que poderiam ser realizadas com relação ao Amunhoney foram prejudicadas pelo fato de que a ferramenta, na época do período de experimentação, estava em um estágio ainda inicial de desenvolvimento, com a existência de alguns bugs que se refletiram na dificuldade de obter os binários e também de manter o servidor sempre disponível (algumas interações com worms resultavam em falha abrupta do software) 8. Assim, optou-se apenas por fazer uma análise com relação apenas aos binários coletados e aos endereços IP e países de origem dos ataques nos casos em que a obtenção do arquivo malicioso foi bem-sucedida. Os resultados obtidos são descritos na seção Descrição dos resultados obtidos Durante todo o tempo do experimento, 93 binários diferentes foram obtidos pelo Amun, o que foi equivalente a coleta de um binário diferente a cada 16 horas e 15 minutos, aproximadamente. A primeira investigação realizada com relação aos binários capturados foi a respeito dos endereços IP e países de origem dos ataques. As tabelas 18 e 19 apontam os países e endereços IP responsáveis pelo maior número de interações com captura de malware (bem-sucedidas) durante o período de coleta de dados. Examinando os dados obtidos, vê-se também que muitos dos principais endereços IP responsáveis pelos ataques pertencem ao mesmo bloco /8 da máquina atacada, assim como foi observado no experimento envolvendo o Nepenthes. Como consequência disso, muitos países 8 A versão atual (0.1.7) obtida atráves de svn mostra-se muito mais estável, com níveis de deteccção e de coleta de malware equivalentes aos registrados com o Nepenthes.

103 102 País de origem Número de interações registradas China 23 Argentina 13 Chile 13 Estados Unidos 9 Brasil 8 Colômbia 4 Alemanha 4 Guatemala 4 México 4 Cuba 2 Tabela 18: Os 10 países com maior número de interações bem-sucedidas registradas pelo Amun durante o período de observação. da América Latina aparecem na lista das maiores origens de propagação de malware. Deve-se resaltar, porém, que este é um dado local e possivelmente máquinas que se situam em outros blocos /8 receberão mais ataques a partir de máquinas infectadas que também estão inseridas no mesmo bloco da máquina atacada. Nota-se também que a China novamente foi a origem de muitas das interações referentes aos worms coletados pelo Amun, e que hipoteticamente pode-se pensar que o país possui um alto índice de máquinas infectadas mesmo por worms que exploram falhas já muito conhecidas. Endereço IP País de origem Número de interações registradas Chile China Argentina China Guatemala Argentina México Brasil Chile China 3 Tabela 19: Os 10 endereços IP com maior número de interações bem-sucedidas registradas pelo Amun durante o período de observação. Depois, da mesma forma como foi feita com os binários coletados pelo Nepenthes, os malwares coletados pelo Amun foram submetidos à analise pelo webservice VirusTotal. Os resultados obtidos pela avaliação dos 93 binários capturados pelo Amun são mostrados na tabela 20.

104 103 Anti-vírus Arquivos não detectados Arquivos detectados (%) Ikarus 10 89,2% McAfee-GW-Edition 10 89,2% GData 10 89,2% a-squared 11 88,1% AntiVir 11 88,1% AVG 11 88,1% BitDefender 11 88,1% McAfee+Artemis 11 88,1% Microsoft 11 88,1% Avast 12 87,0% K7AntiVirus 12 87,0% F-Secure 13 86,0% VirusBuster 13 86,0% Authentium 14 84,9% CAT-QuickHeal 14 84,9% esafe 14 84,9% F-Prot 14 84,9% McAfee 14 84,9% Symantec 14 84,9% Kaspersky 15 83,8% NOD ,8% Sophos 15 83,8% Comodo 16 82,8% Fortinet 16 82,8% Jiangmin 16 82,8% Rising 18 80,6% VBA ,6% Norman 21 77,4% etrust-vet 24 74,2% Panda 25 73,1% DrWeb 27 70,9% Prevx 30 67,7% Sunbelt 30 67,7% AhnLab-V ,5% TrendMicro 35 62,3% TheHacker 37 60,2% nprotect 38 59,1% Antiy-AVL 50 46,2% ViRobot 50 46,2% ClamAV 54 41,9% Tabela 20: Resultado da avaliação do conjunto de binários coletados com relação à detecção pelas ferramentas anti-vírus (referente ao conjunto coletado pelo Amun).

105 104 Nota-se que a ferramenta com maior porcentagem de arquivos detectados garantiu que 10 dos 93 binários coletados foram identificados como não sendo malware. Esse fato pode estar relacionado ao fato de, ocasionalmente, terem ocorrido falhas de transferência de alguns binários durante o processo de download, resultando em arquivos corrompidos. Por outro lado, alguns deles podem realmente se tratar de arquivos maliciosos que não foram corretamente identificados por qualquer uma das ferramentas. Há de se ressaltar, porém, que em todos os 93 relatórios produzidos pelo webservice, pelo menos uma das ferramentas testadas identificou o arquivo analisado como malicioso. Independentemente desse fato, novamente observou-se que determinadas ferramentas como Panda e TrendMicro Anti-virus tiveram um desempenho bastante fraco quanto ao conjunto de binários utilizados. Entretanto, o maior destaque negativo ficou por conta do ClamAV que detectou apenas 41,9% dos binários coletados. Por fim, também efetuou-se a determinação dos tipos de malwares que mais foram coletados pelo Amun, novamente utilizando os resultados obtidos pela ferramenta AVG. Nome do worm (notação AVG) Número de ocorrências BackDoor.RBot.KB 14 BackDoor.PcClient.2.AM 7 BackDoor.Generic10.SAP 5 Pakes.CTU 3 SHeur.BAOL 3 Win32/Heur 3 BackDoor.Generic_r.FC 2 BackDoor.Generic_r.GE 2 BackDoor.Ircbot.7.K 2 BackDoor.PcClient.2.AZ 2 Tabela 21: Tipos de malwares coletados pelo Amun (segundo a ferramenta AVG). A tabela 21 aponta que os principais malwares detectados referem-se aos worms RBot, PcClient, Heur e Ircbot. Verifica-se que diferentemente do Nepenthes, nenhum malware classificado como Allaple foi capturado. Isso significa que o Amunhoney e o Nepenthes podem ser usados de maneira complementar para a obtenção de um conjunto mais variado de malwares. 4.5 Experimentos com o Honeytrap Durante o período de decisão dos honeypots a serem escolhidos para testes e avaliação experimental, o Honeytrap chamou a atenção devido ao modo como ele atua: monitorando as requisições destinadas às portas do host, abrindo-as sob demanda e ficando à espera da comu-

106 105 nicação dos atacantes, conforme explicado na seção 3.5. Além disso, sua capacidade de gerar traces com o conteúdo dos primeiros pacotes recebidos das máquinas atacantes mostrou-se uma característica diferente e interessante. Por fim, sua integração com o gerador de assinaturas de detecção de intrusão Nebula configurou-se como outro atrativo para o teste do honeypot Descrição do ambiente utilizado A máquina alocada para os experimentos relativos ao Honeytrap possuía a mesma configuração da máquina usada nas atividades relacionadas ao Amunhoney. Aqui também, um único endereço IP público foi alocado a máquina. Como nas outras situações, os mesmos cuidados quanto ao tempo de restabelecimento dos processos e sincronização de relógio foram tomados. A versão do Honeytrap foi instalada e configurada a partir do código-fonte disponibilizado pelos autores. A configuração realizada foi a padrão, com todas as portas habilitadas no modo normal e utilizando-se o monitor de stream baseado na libpcap. Isto significa que o Honeytrap poderia atender a requisições UDP e TCP em qualquer uma das portas (com exceção da porta 22, usada para gerência remota da máquina), capturando os primeiros pacotes enviados de cada conexão. O experimento foi realizado entre os dias 26 de janeiro de 2009 e 13 de abril de 2009, mas apenas foram analisados os dados do período entre 15 de fevereiro de 2009 e 11 de abril de 2009 (56 dias). Os arquivos de log e traces foram sendo armazenados durante o período de experimentação e depois analisados com a ajuda da aplicação sctest (componente da libemu), scripts personalisados e também submetidos para o Nebula (com o intuito de se observar o processo de geração das assinaturas para o Snort). A partir dessa análise, foram geradas estatísticas tais como: os endereços IP de origem que mais enviaram pacotes aos honeypots; os países responsáveis por enviarem as maiores quantidades de pacotes; a quantidade de pacotes TCP e UDP (pacotes ICMP ou IGMP não são registrados pelo Honeytrap); as portas de destino mais atacadas.

107 Descrição dos resultados obtidos Durante todo o período de observação, pacotes foram capturados pelo Honeytrap. Desses, eram pacotes que utilizavam o protocolo TCP e apenas 22 eram UDP. A pequena quantidade de pacotes de pacotes UDP recebida pode estar relacionada a forma como estes pacotes eram enviados pelos atacantes, pois o Honeytrap (usando a libpcap como monitor de stream) só registra as conexões em uma porta depois que um pacote é enviado para determinada porta e rejeitado (o primeiro pacote enviado para uma porta fechada não é registrado). Novamente, a primeira análise efetuada foi relativa aos endereços IPs e países de origem dos pacotes que foram registrados pelo Honeytrap. As tabelas 22 e 23 mostram os principais países e endereços IP de origem dos pacotes que chegaram até o Honeytrap. País de origem Número de pacotes Brasil Venezuela 2911 Coréia do Sul 2305 Argentina 1829 Estados Unidos 1234 Japão 509 Alemanha 387 Chile 360 Taiwan 313 México 290 Tabela 22: Os 10 países com maior número de conexões endereçadas à máquina do Honeytrap durante o período de observação. Pelos dados obtidos, percebe-se que 5 dos 10 principais países de origem dos pacotes maliciosos situam-se na América Latina, o que indica a presença de atividade considerável de worms no meio desse tráfego. Observa-se também que o resultado obtido por meio do Honeytrap é coerente em relação ao obtido por meio da experiência com o Honeyd pois, ao ser comparado com os resultados presentes na tabela 6, constata-se que as listas possuem 8 países em comum. Quanto aos endereços IP de origem responsáveis pelo maior número de pacotes, novamente nota-se que metade deles pertencem ao mesmo bloco /8 e assim como no experimento envolvendo o Honeyd, pacotes foram recebidos de um host situado no Quênia; o que novamente demonstra a coerência dos dados. Também foi verificado quais foram as portas que registraram maior número de pacotes recebidos durante o período de experimentação. Assim, como no experimento com o Honeyd, as portas mais acessadas foram a 1433 e 445,

108 107 Endereço IP País de origem Número de conexões registradas Brasil Venezuela Coréia do Sul Argentina Venezuela Brasil Brasil Estados Unidos Quênia Japão 182 Tabela 23: Os 10 endereços IP com maior número de conexões endereçadas à máquina do Honeytrap durante o período de observação. Porta Pacotes Tabela 24: As 10 portas mais visadas pelos atacantes durante o período de experimentação do Honeytrap. seguida pela porta 3306, 135 e 139. Todas elas estavam presentes na lista das mais acessadas no experimento feito com o Honeyd no mesmo período, sendo que as duas listas possuem, em comum, 6 portas listadas. A porta 5900/TCP e 4899/TCP são usadas respectivamente pelos serviços de controle remoto VNC e Radmin. Ambos os serviços tiveram em anos anteriores vulnerabilidades publicadas e bastante exploradas por atacantes. Já a porta 3128 é utilizada normalmente por proxies (porta padrão do Squid Proxy) e poderia estar sendo inspecionada por spammers para verificar a existência de proxies abertos (seção 2.7.1). Finalmente, as portas 80 e 8080 são normalmente usadas por servidores web, o que indica que ataques que exploram vulnerabilidades nestes servidores podem ter sido lançados contra o host. Por último, quanto às assinaturas geradas pelo Nebula a partir dos traces obtidos pelo Honeytrap, notou-se a geração de apenas 12 regras quando todos os traces foram analisados. Em-

109 108 bora não tenham sido testadas em um IDS, aparententemente as regras geradas poderiam ser usadas para detectar ataques pois possuem informações sobre o payload dos pacotes. Avaliar a eficácia e eficiência dessas regras está fora do escopo desse trabalho, que nesse caso específico tinha por finalidade apenas exemplificar a utilização dos dados de rede registrados pelo Honeytrap. Figura 18: Exemplo de assinatura gerada (no formato Snort) pelo Nebula ao analisar os traces obtidos pelo Honeytrap. 4.6 Experimentos com o SSH Kojoney Na seção 3.6.2, foi apresentado o Kojoney SSH, um honeypot especializado em detectar ataques contra servidores SSH. Neste caso, definiu-se que ele seria utilizado com o objetivo de se obter informações sobre os ataques de força bruta contra os servidores SSH. Como resultados foram gerados a lista dos nomes de usuário mais comumente utilizados durante as tentativas, os comandos mais utilizados pelos atacantes logo depois de adentrarem no honeypot, a lista com os endereços IP e países responsáveis pelas maiores quantidades de tentativas de ataques e até mesmo algumas situações onde foram detectadas possíveis ações humanas. Figura 19: Kojoney SSH Honeypot em ação durante o processo de autenticação de usuário (observe que não há diferenças visuais em relação às informações exibidas por um servidor OpenSSH legítimo).

110 Descrição do ambiente utilizado Diferentemente dos outros ambientes onde foi necessário separar uma máquina física para a realização do experimento, no caso do Kojoney SSH foi utilizada uma estação de trabalho empregada para fins gerais (um Pentium GHz com 384 MB de memória). A máquina em questão já estava com o Linux Debian 4.0 instalado e rodava um servidor OpenSSH legítimo na porta 22 (padrão do serviço SSH), com um endereço IP público associado a sua interface de rede. Após ter sido realizada a instalação da última versão do Kojoney ( ) 9, apenas mudouse o servidor SSH legítimo para outra porta acima de 1024 e deixou-se com que o Kojoney respondesse às requisições enviadas para a porta padrão do serviço SSH, a 22/TCP. Deste modo, as requisições SSH legítimas direcionadas a estação de trabalho eram feitas especificando a nova porta utilizada pelo OpenSSH e as conexões maliciosas provenientes de ataques de força bruta continuaram sendo absorvidas pela porta 22, onde o honeypot estava executando. O experimento foi realizado entre os dias 30 de março de 2009 e 13 de abril de 2009, com o serviço do honeypot operando ininterruptamente. Após este período, o arquivo de log foi submetido para análise pela ferramenta kojreport, que já é parte do pacote do Kojoney e tem por finalidade gerar estatísticas sobre alguns aspectos relativos aos ataques SSH ocorridos. Os resultados obtidos serão mostrados na seção Descrição dos resultados obtidos Nesta seção, os dados obtidos serão analisados em relação a alguns aspectos como, por exemplo: A partir dessa análise, foram geradas estatísticas tais como: os nomes de usuários mais utilizados nas tentativas de ataque; os endereços IP que registraram maior quantidade de conexões ao honeypot; os países responsáveis pelas maiores quantidades de conexões ao honeypot; os comandos mais utilizados pelos atacantes quando conseguem acesso a um shell remoto. 9 Não se assustem com a numeração da versão. A execução do programa se mostrou bastante estável.

111 110 A primeira investigação realizada foi a respeito dos nomes de usuários utilizados. No total, foram registrados 2215 diferentes nomes de usuários diferentes em tentativas. Os nomes obtidos incluem nomes de pessoas, cidades, serviços (por exemplo: postgres, postfix, wwwdata, oracle, mail, exim, ftp, www), nomes comuns de atendimento e contato (por exemplo, contact, suporte, webmaster, etc.) e até mesmo as clássicas tentativas com palavras como teste, test, user e usuário, além de outras combinações peculariares. Isso demonstra a diversidade dos dicionários de ataque utilizados durante as tentativas (resultados similares a esse podem ser encontrados em (ALATA et al., 2006)). A tabela 25 mostra a lista dos 20 nomes de usuários mais empregados nas tentativas de ataques SSH por força bruta. Nome do usuário Tentativas Falhas de autenticação Autenticações bem-sucedidas root teste admin test webmaster user mail suporte mp secretaria oracle usuario ftp web www guest radio tester loja student Tabela 25: Lista dos 20 usuários mais usados nas tentativas de ataques ao serviço SSH provido pelo Kojoney. Em seguida, analisou-se os endereços IP de origem dos responsáveis pelas maiores quantidades de ataques recebidos. No, total foram detectados 169 endereços IP diferentes situados em 35 países. A tabela 26 indica a relação dos 10 endereços IP que mais requisitaram conexões SSH ao Kojoney. Observando a tabela 26, tem-se que 6 dos 10 endereços situam-se em países da América do Sul; o que reforça a idéia de que determinados tipos de ataques escolhem seus alvos utilizando

112 111 Endereços IP Número de conexões SSH País de origem Estados Unidos Paraguai Brasil Brasil China Taiwan Brasil Coréia do Sul Argentina Peru Tabela 26: Os 10 endereços IP que mais requisitaram conexões SSH ao honeypot durante o período de experimentação como um dos critérios a proximidade geográfica ou pelo menos a faixa de endereços IP na qual a rede está contida. A tabela 27 indica a relação dos 10 países que mais originaram ataques SSH durante o período de observação. País de origem Número de conexões SSH Brasil 6583 Estados Unidos 4180 China 3607 Paraguai 2921 Coréia do Sul 1626 Taiwan 1186 Argentina 1181 Peru 720 Espanha 571 Holanda 519 Tabela 27: Os 10 países com maior número de conexões SSH realizadas ao endereço IP do honeypot. Pela tabela 27, observa-se também que os principais países de origem dos ataques estão distribuídos em 3 regiões geográficas: América do Sul (Brasil, Paraguai, Argentina e Peru), Estados Unidos e extremo oriente (China, Coréia do Sul, Taiwan). Em seguida, também foram coletados dados sobre acessos SSH que possivelmente ocorreram de forma manual, devido a existência de caracteres, por exemplo, de BACKSPACE ou DELETE nos comandos utilizados. Das tentativas de conexões, foram identificadas apenas 3 ataques em que foram detectados erros de digitação. Dois deles com origem na Romênia e outro com origem na Áustria, conforme pode ser observado na figura 20.

113 112 Figura 20: Ocorrências de detecção de indícios de acessos SSH manuais destinados ao honeypot. Uma vez que o Kojoney disponibiliza um falso shell remoto ao atacante quando a tentativa de autenticação realizada é bem-sucedida, também observou-se quais foram os comandos mais utilizados por eles durante o processo de exploração do honeypot. Ressalta-se novamente que nenhum destes comandos foi realmente executado, pois o Kojoney apenas gerava respostas padrões dependendo do comando utilizado. A tabela 28 indica os comandos mais utilizados nas sessões resultantes de autenticações bem-sucedidas. Comandos Número de vezes 45 w 23 ls 18 uname -a 15 ls -a 14 uptime 14 ps x 13 cat /proc/cpuinfo 12 wget 7 cd /tmp 6 passwd 5 id Tabela 28: Os 10 comandos mais requisitados pelos atacantes quando o acesso ao shell falso era concedido depois de uma autenticação bem sucedida. Conforme pode ser observado na tabela 28, o comando mais utilizado foi w (who), que é utilizado para listar os usuários que possuem alguma seção ativa no host. Outro comando utilizado com relação a usuários foi o id que lista as permissões e os donos de um determinado diretório. Percebe-se também a utilização do passwd, um comando para troca da senha do usuário; possivelmente os atacantes fizeram isso para ter, durante um determinado período, acesso exclusivo à maquina, evitando que outros intrusos também consigam acessá-la a partir da execução de ferramentas de ataques SSH por força bruta. Outro grupo de comandos, entre eles cat /proc/cpuinfo, uname -a e uptime foram utilizados para se obter informações sobre o processador, sistema operacional e quantidade de tempo que de atividade da máquina que supostamente foi invadida. Informações como estas poderiam

114 113 ajudar os atacantes a determinarem para que tipo de atividade maliciosa o host poderia ser utilizado, dependendo do sistema operacional e processador em questão. O terceiro grupo é composto por comandos usados para listagem de diretórios (ls), visualização dos processos atuais (ps) e acesso a diretórios (cd). Por último, verifica-se também a utilização do comando wget, usado para obter arquivos de servidores web e ftp. Assim, também foi observado que alguns atacantes (ou programas automatizados de ataque) tentaram baixar arquivos maliciosos de servidores remotos. Os comandos deste tipo executados durante o período de observação são visualizados na figura 21. Figura 21: Comandos utilizados pelos atacantes para obter arquivos maliciosos como executar atividades maliciosas. Os arquivos foram posteriormente baixados dos servidores remotos e verificou-se que eles continham ferramentas automatizadas para execução de flood UDP (utilizado em ataques DDoS), exploração de vulnerabilidades locais (não remotas) e até mesmo para iniciar outros ataques SSH a partir da máquina comprometida.