MONITORAÇÃO DE ATIVIDADES EM MÁQUINAS PREPARADAS PARA SEREM COMPROMETIDAS (HONEYPOTS)

INPE-12904-TDI/1010 MONITORAÇÃO DE ATIVIDADES EM MÁQUINAS PREPARADAS PARA SEREM COMPROMETIDAS (HONEYPOTS) Luiz Gustavo Cunha Barbato Dissertação de Mestrado do Curso de Pós-Graduação em Computação Aplicada, orientada pelo Dr. Antonio Montes Filho, aprovada em 21/05/2004. INPE São José dos Campos 2005

681.324 BARBATO, L. G. C. Monitoração de atividade e máquinas preparadas para serem comprometidas (honeypots) / L. G. C. Barbato. São José dos Campos: 2004. 147p. (INPE-12904-TDI/1010). 1.Segurança computacional. 2.Monitoração de sistemas. 3.Sistemas operacionais. 4.Funções de Kernel. 5.Redes de computadores. I.Título.

Subjugar o exército inimigo sem lutar é o verdadeiro ápice da excelência. A estratégia para empregar o exército não é confiar que o inimigo não virá, mas ter em nossas mãos meios de esperá-lo. Não confiar em que ele não atacará, mas termos nós uma posição inatacável. Quando alguém excele na defesa, o inimigo não sabe onde atacar. Se não quero travar combate, mesmo que eu simplesmente desenhe uma linha no chão e a defenda, ele não conseguirá fazer-me combater, porque nós frustaremos seus movimentos. SUN T ZU (A Arte da Guerra)

A meus pais, minha irmã e minha noiva os quais eu amo muito.

AGRADECIMENTOS Em primeiro lugar, gostaria de agradecer a Deus pela vida que me proporcionou, e por sempre me iluminar e me ajudar a conquistar os meus objetivos. Agradeço a meus pais, Luiz Alberto e Elizete por ter me concebido, pelo amor, pelo carinho e pela educação tanto dentro de casa quanto pelas escolas de primeira qualidade por onde passei. À minha noiva Adriene, que eu amo muito, por ter me compreendido e me apoiado durante a minha ausência desde o começo do nosso namoro, por eu estar em busca de meu grande sonho. E, principalmente, por ter me provado que o verdadeiro amor sobrevive às distâncias geográficas. À minha irmã Anelise pelo amor e carinho que tem me dado durante toda a minha vida, e principalmente, nos finais de semana em que vou para Pouso Alegre. Aos meus amigos de Pouso Alegre pela lealdade durante a vida, pelas ajudas e conselhos durante os momentos difíceis que passei. Aos colegas de faculdade que me agüentaram por 4 anos, aturando as minhas brigas e brincadeiras. À Faculdade na qual me formei ( FAI - Faculdade de Administração e Informática ) que me deu uma base muito boa para enfrentar as dificuldades do Mestrado e os problemas durante o desenvolvimento desta dissertação. A todo pessoal do INPE, principalmente o pessoal do LAC que também tive que me aturar por pouco mais de 1 ano, durante o período que trabalhei. Ao Amândio, Benício e Carlos pelas ajudas, ensinamentos e compreensão durante o período que estava trabalhando nesta dissertação. Ao Professor Dr. Antonio Montes, pelos ensinamentos, experiências e, principalmente, conselhos que me ajudaram a mudar várias perspectivas da área na qual sempre sonhei em atuar. Ao pessoal do NBSO, Cristine, Klaus e Marcelo, pelas ajudas durante a elaboração deste trabalho, pelos conselhos e ensinamentos. Ao Lucio que me indicou o curso de Mestrado no INPE, pelas ajudas e trocas de informações durante 2 anos de república. E finalmente, o meu agradecimento especial ao professor Moisés que hoje não está mais entre nós, pelos bons conselhos, ajudas, e, principalmente, por ter me ensinado o mais importante: sempre ter força de vontade para lutar pelos nossos objetivos e nunca desistir dos nossos sonhos por mais difíceis e distantes que eles sejam: Quem quer, sempre consegue

RESUMO Até algum tempo atrás, segurança de sistemas de informação era sinônimo exclusivamente de proteção, assumindo sempre uma posição puramente defensiva. Hoje em dia, essa mentalidade vem mudando. Medidas reativas vêm ajudando a melhorar a segurança de sistemas, com o uso de máquinas preparadas para serem comprometidas (honeypots) visando o aprendizado das técnicas adotadas pelos invasores com os próprios invasores. Com base nesta nova visão de segurança de sistemas de informação, este trabalho tem como objetivo o desenvolvimento de um sistema capaz de monitorar de forma imperceptível, todas as atividades dos invasores nos honeypots, transmitindo essas informações para estações de monitoração.

MONITORING ACTIVITIES IN HOSTS PREPARED TO BE COMPROMISED (HONEYPOTS) ABSTRACT Not long ago, information systems security was closely associated with passive protection, always assuming a purely defensive stance. Nowadays, this approach is changing. Reactive measures are helping to improve systems security, with the use of hosts prepared to be compromised (honeypots) providing information about the techniques used by the attackers, from the attackers themselves. Based on this new approach to information systems security, the present work aims to develop a system to stealthily monitor all the attackers activities in the honeypots and transfer this information to monitoring stations.

SUMÁRIO Pág. LISTADE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS CAPÍTULO 1 INTRODUÇÃO.. 25 1.1 Segurança com Base no Conhecimento do Inimigo.. 26 1.2 Honeypots 29 1.3 Honeynets 30 1.4 Esboço Geral desta Dissertação 31 CAPÍTULO 2 COLOCAÇÃO DO PROBLEMA 33 2.1 Análise do Problema 33 2.1.1 Captura das Ações dos Invasores. 33 2.1.2 Armazenamento de Dados Capturados. 34 2.1.3 Transferência dos Dados dos Honeypots. 34 2.1.4 Análise dos Dados 34 2.1.5 Ocultamento do Processo.. 34 2.2 Revisões do Estado da Arte.. 35 2.2.1 Bash Patch. 36 2.2.2 Bash Patch Anton 37 2.2.3 Linux Kernel Patch 37 2.2.4 Utilitário Script Modificado. 37 2.2.5 Sebek. 39 2.2.6 Sebek2. 40 2.2.7 UML.. 40 CAPÍTULO 3 ARQUITETURA DO LINUX.. 43 3.1 Comunicação com okernel.. 44 3.1.1 Chamadas de Sistema. 46 3.1.2 Interrupções de Software 49 3.2 Módulos de Kernel. 54 3.2.1 Compilação do Linux com Suporte amódulos 55 3.2.2 Ferramentas de Manipulação de Módulos de Kernel 58 3.2.3 Criação de Módulos 58

CAPÍTULO 4 TÉCNICAS DE MONITORAÇÃO DE ATIVIDADES 61 4.1 Captura em User Space. 62 4.1.1 Interpretadores de Comandos 62 4.1.2 Utilitário Script.. 62 4.1.3 Bibliotecas de Sistema. 63 4.1.4 Discussão.. 64 4.2 Captura em Kernel Space 66 4.2.1 Uso da sys read e sys write......................... 66 4.2.2 Uso da tty write............................... 67 4.2.3 Uso da sys execve............................... 69 4.2.4 Discussão.. 69 4.3 Modificação no Interpretador de Comandos Bash.. 70 4.3.1 Ferramentas Auxiliares. 72 4.3.2 Resultados.. 75 CAPÍTULO 5 TÉCNICAS DE OCULTAÇÃO DE TRÁFEGO DE REDE............................. 79 5.1 Fluxo de Dados no Kernel 80 5.1.1 Visão Detalhada. 82 5.1.2 Registro de Drivers de Protocolos Genéricos. 89 5.1.3 Representação dos Pacotes perante okernel. 93 5.2 Técnicas de Ocultação de Tráfego de Rede 98 5.2.1 Driver da Placa de Rede 98 5.2.2 Gerenciador de Recepção de Pacotes Genéricos.. 99 5.2.3 Módulo de Kernel de Tratamento de Protocolos Genéricos.. 100 CAPÍTULO 6 SISTEMA DE MONITORAÇÃO E RECON- STRUÇÃO DE ATIVIDADES EM HONEYPOTS.. 103 6.1 Solução Adotada.. 103 6.1.1 Resumo da Solução Adotada. 103 6.1.2 Visão Geral da Solução Adotada. 105 6.1.3 Estruturação da Solução Adotada. 105 6.2 Descrição do Sistema SMaRT. 110 6.2.1 Arquitetura do Sistema. 111 6.2.2 Módulos do Sistema.. 112 6.2.3 Precauções.. 121

CAPÍTULO 7 RESULTADOS OBTIDOS. 123 7.1 Descrição do Ambiente.. 123 7.1.1 Descrição do Honeypot. 125 7.1.2 Vulnerabilidades nos Serviços Disponibilizados 126 7.2 Resultados Coletados com osmart 127 7.2.1 Análise da Sessão. 130 7.2.2 Vulnerabilidade Explorada.. 134 7.2.3 Ferramentas Utilizadas. 134 7.2.4 Motivação do Ataque.. 135 7.3 Testes de Desempenho no Coletor.. 135 CAPÍTULO 8 CONCLUSÕES.. 137 8.1 Sugestões para Trabalhos Futuros.. 139 8.2 Considerações Finais 140 REFERÊNCIAS BIBLIOGRÁFICAS.................... 143

LISTA DE FIGURAS Pág. 3.1 Rastreio das chamadas de sistema....................... 48 3.2 Associação da interrupção de software com a função tratadora........ 49 3.3 Definição do valor da interrupção de software................. 49 3.4 Definição de uma chamada de sistema..................... 50 3.5 Chamada de sistema com 3 argumentos.................... 50 3.6 Definição dos valores das chamadas de sistema................ 51 3.7 Visualização da interrupção de software.................... 52 3.8 Definição do valor da chamada de sistema execve............... 53 3.9 Análise da implementação da função execve na glibc............. 53 3.10 Momento em que glibc efetua a interrupção de software........... 54 3.11 Parâmetros de compilação de módulos..................... 56 3.12 Exemplo de um módulo simples......................... 59 3.13 Resultados do módulo simples......................... 59 3.14 Erro no carregamento de módulos....................... 60 4.1 Modificação no utilitário Script......................... 63 4.2 Modificação na biblioteca de sistema Glibc................... 64 4.3 Modificação nas chamadas de sistema sys read e sys write.......... 67 4.4 Modificação na operação de escrita na tela terminais............. 68 4.5 Modificação na chamada de sistema sys execve................ 69 4.6 Modificação no bash............................... 70

4.7 Função responsável pelo envio dos dados.................... 71 4.8 Algoritmo simples de embaralhamento utilizado................ 71 4.9 Resultado da alteração das variáveis do patch................. 72 4.10 Resultados obtidos com o bash modificado................... 75 4.11 Comando utilizado para teste de desempenho do bash modificado...... 75 5.1 Caminho da recepção dos pacotes e as funções mais importantes...... 81 5.2 Diagrama de encadeamento entre as funções................. 82 5.3 Função responsável por tratar a interrupção gerada pela placa de rede... 83 5.4 Função responsável por extrair os dados da placa de rede.......... 84 5.5 Função gerenciadora de recepção de pacotes genéricos............ 85 5.6 Chamada da função de sinalização da recepção de dados.......... 85 5.7 Geração de interrupção sinalizando a recepção de dados........... 86 5.8 Função responsável por tratar a interrupção NET RX SOFTIRQ..... 86 5.9 Inicialização da filas de recepção de pacotes................. 87 5.10 Retirada dos pacotes da fila.......................... 88 5.11 Filas de protocolos genéricos e específicos................... 89 5.12 Função de inicialização do módulo af packet................. 90 5.13 Associação da função de criação de sockets PF PACKET.......... 90 5.14 Operações que podem ser feitas com sockets PF PACKET......... 91 5.15 Função de criação dos sockets PF PACKET................. 91 5.16 Definição da estrutura packet type....................... 92 5.17 Registro do protocolo genérico......................... 92 5.18 Função de recepção de protocolos genéricos.................. 93

5.19 Estruturas da camada de enlace........................ 94 5.20 Manipulação dos dados do protocolo Ethernet................ 94 5.21 Estruturas da camada de rede......................... 95 5.22 Manipulação dos dados do protocolo IP................... 95 5.23 Estruturas da camada de transporte..................... 96 5.24 Manipulação dos dados do protocolo UDP.................. 96 5.25 Manipulação dos dados do protocolo TCP.................. 97 5.26 Variável de representação dos dados da camada de aplicação........ 97 5.27 Manipulação dos dados da camada de aplicação............... 97 5.28 Alteração do driver da placa de rede..................... 99 5.29 Alteração do gerenciador de recepção de pacotes genérico.......... 100 5.30 Alteração da operação de recepção do módulo................ 101 5.31 Modificação das operações da família PF PACKET............. 102 6.1 Visão geral da solução adotada......................... 105 6.2 Estruturação da solução adotada........................ 106 6.3 Subsistemas do sistema de monitoração.................... 106 6.4 Subsistemas do sistema de processamento................... 108 6.5 Subsistemas do sistema de acompanhamento................. 109 6.6 Arquitetura do sistema............................. 111 6.7 Técnica de ocultação de módulos de kernel.................. 113 6.8 Rotina utilizada para emissão de dados em kernel space........... 115 6.9 Algoritmo de controle de sessões nos honeypots................ 117 6.10 Estrutura de diretórios dos arquivos de sessão................. 117

6.11 Captura de tela do SMaRT reconstruindo uma sessão............. 120 7.1 Topologia da noneynet.............................. 124 7.2 Primeiro comprometimento no honeypot.................... 128 7.3 Tentativa de descarregamento de ferramenta.................. 129 7.4 Sessão dia 15/02/2004-15:11 (continua).................... 130 7.4 Conclusão..................................... 131 7.5 Sessão dia 26/02/2004-10:06.......................... 133

LISTA DE TABELAS Pág. 3.1 Chamadas de sistema.............................. 47 4.1 Amostra 1.................................... 76 4.2 Amostra 2.................................... 76 4.3 Amostra 3.................................... 76 7.1 Vulnerabilidades dos serviços.......................... 126 7.2 Vulnerabilidade do kernel............................ 127 7.3 Horário dos primeiros acessos aos serviços................... 127

LISTA DE SIGLAS E ABREVIATURAS ANSI American National Standards Institute API Application Program Interface ARP Address Resolution Protocol ASCII American Standard Code for Information Interchange BPF BSD Packet Filtering BSD Berkeley Systems Development CPU Central Processing Unit FDDI Fiber Distributed Data Interface FTP File Transfer Protocol GPL General Public License ICMP Inter Control Message Protocol IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPX/SPX Internet Payment exchange/sequenced Packet exchange I/O Input/Output IDS Intrusion Detection System IRC Inter Relay Chat ISO International Standards Organization LAN Local Area Network LBL Lawrence Berkeley Laboratory LKM Loadable Kernel Module LSM Linux Security Modules MAC Media Access Control MIT Massachussets Institute of Technology NetBIOS Network Basic Input Output System NDIS Network Driver Interface Specification OSI Open System Interconnection PC Personal Computer Perl Practical Extraction and Report Language PPP Point-to-Point Protocol RAM Random Access Memory RFC Request For Comment SLIP Serial Line Internet Protocol SMaRT Session Monitoring and Replay Tool SMP Simetric Multi-Processor SMTP Simple Mail Transfer Protocol SSH Secure Shell TCP Transmission Control Protocol TCP/IP Transmission Control Protocol/Internet Protocol UDP User Datagram Protocol UML User Mode Linux

CAPÍTULO 1 INTRODUÇÃO Dia 07 de dezembro de 1941, os Estados Unidos sofrem ataque surpresa em Pearl Habor. Centenas de aviões japoneses bombardeiam a base norte-americana no Hawaí. Muitas pessoas morrem. Dia 11 de setembro de 2001, os Estados Unidos sofrem ataques surpresas em Nova York. Dois aviões de passageiros comandados por terroristas são lançados contra as famosas torres gêmeas na ilha de Manhattan. Ambas desabam matando muitas pessoas. Outro avião é jogado sobre um dos maiores símbolos de poder e segurança norte americano, o Pentágono. O que há de comum entre estes acontecimentos é o fato de que em todos eles muito dinheiro foi investido em segurança: mecanismos sofisticados de defesa, em suas épocas correspondentes, foram instalados para detectar e interceptar o inimigo. Outro aspecto em comum é que apesar de tudo, o inimigo conseguiu o seu objetivo. As estratégias adotadas pelos invasores 1 foram mais planejadas e eficientes que as estratégias utilizadas pelos orgãos de defesa. Aqueles sabiam como e quando atacar, e assim, atingir os seus objetivos com sucesso. Estratégias militares de defesa bem sucedidas são aquelas criadas com base no conhecimento do inimigo, seus tipos de armas, seus métodos de ataques, suas táticas de guerra e, principalmente, o seu objetivo. Conhecendo suas armas é possível conduzir treinamentos práticos. Conhecendo seus métodos de ataque é possível desenvolver métodos de defesa. Conhecendo suas táticas de guerra é possível projetar mecanismos para combatê-lo. E conhecendo seu objetivo é possível entender a motivação que o incentivou a iniciar os ataques. Assim como os militares, a área de segurança de sistemas de informação também utiliza estes conhecimentos para se defender contra ataques. Esta busca motivou os profissionais de segurança a criarem metodologias para obter informações mais precisas sobre os invasores. Uma das metodologias criadas faz uso de ferramentas de pesquisa, conhecidas como honeynets, que permitem a captura e o estudo de cada passo dos invasores. Honeynets são redes preparadas para serem comprometidas, compostas por várias máquinas e equipa- 1 Nesta dissertação, os termos invasores e invasores possuirão o mesmo significado. Serão interpretados como sendo indivíduos mal intencionados que atacam e/ou invadem sistemas. 25

mentos denominados honeypots. Em cada honeypot são instalados sistemas e aplicativos reais, com intuito de criar ambientes similares aos que são utilizados em muitas organizações atualmente. Além dos sistemas e aplicativos, outros artifícios são necessários para monitorar as operações efetuadas pelos invasores durante um processo de invasão. 1.1 Segurança com Base no Conhecimento do Inimigo Como se pode notar na maior parte das publicações sobre o assunto, a ênfase da segurança é somente proteção. Até um tempo atrás segurança de sistemas de informação era sinônimo exclusivamente de proteção assumindo sempre uma posição puramente defensiva. O número de pessoas tentando violar a segurança de sistemas, passando dias e noites em busca de vulnerabilidades nos software com intuito de desenvolver ferramentas que permitam o acesso ao sistema alvo, é muito grande. Se acrescentar a este número as pessoas que não possuem conhecimentos técnicos para criar ferramentas, mas mesmo assim as utilizam para comprometer os sistemas, percebe-se a desproporcionalidade entre o número de invasores e os responsáveis pela segurança de tais sistemas. Se para cada organização existe pelo menos um profissional dedicado a estudar e manter os sistemas seguros, por outro lado, existem inúmeras pessoas tentando encontrar uma maneira de penetrar e comprometer os mesmos. Trabalhar na segurança dos sistemas computacionais de uma organização é uma tarefa árdua e necessita de dedicação exclusiva do profissional alocado para isso. Configurar de maneira correta os sistemas, deixá-los sempre atualizados de acordo com os alertas que circulam nas listas de discussão, analisar o comportamento da rede em busca de tentativas de intrusão, garantir o cumprimento das políticas de segurança são algumas das tarefas de um analista de segurança. Mesmo que os sistemas estejam sempre atualizados, a garantia da segurança não existe. Tipos de testes, utilizados na Engenharia de Software, como caixa preta e caixa branca somente procuram erros para garantir o funcionamento normal do sistema de acordo com os requisitos de desenvolvimento especificados. Procurar por situações onde o sistema pode falhar ou ser induzido a falhas, e desta forma permitir que seja explorado, requer muito tempo e auditores realmente capacitados para exercer tal tarefa. Um outro fator crucial é o tempo. Empresas que desenvolvem software são contratadas para especificar, projetar, desenvolver, testar e documentar em um tempo determinado, onde o não cumprimento deste tempo pode acarretar multas contratuais e/ou perda dos clientes. E esta pressão de terminar o desenvolvimento no prazo induz, muitas vezes, a 26

erros graves, como, por exemplo, a não preocupação com a escolha de funções seguras para exercer determinadas tarefas, ou a utilização incorreta das interfaces de programação que a linguagem utilizada disponibiliza. Um outro aspecto que deve ser levado em consideração é a má formação dos desenvolvedores de software. São poucas as universidades que ensinam seus alunos a programarem de maneira correta, aplicando todas as técnicas de programação segura (Viega e McGraw, 2002). E são em menor número ainda as que fornecem a disciplina de programação segura (Viega e McGraw, 2002) em suas grades curriculares. Por causa disso, muitos aprendem a programar de forma eficiente porém errada. Esta falta de preparo dos desenvolvedores junto com a pressão sofrida pelas empresas desenvolvedoras de software podem ser consideradas as grandes responsáveis pelos erros graves cometidos no processo de implementação dos sistemas. Como os software não são plenamente seguros, os analistas de segurança devem ficar sempre atentos aos alertas emitidos pelas empresas desenvolvedoras para tentar garantir que seus sistemas não sejam comprometidos. Em contrapartida, há muito mais pessoas tentando encontrar erros nos software, independentemente de que estes sejam de código aberto ou não. E, em muitos casos, estas pessoas descobrem falhas nas implementações que tempo depois as empresas desenvolvedoras irão perceber. E neste intervalo de tempo, muitos sistemas são comprometidos através das ferramentas criadas pelos invasores. Tempo depois, estes mesmos invasores, que já conseguiram comprometer vários sistemas pela Internet, anunciam em listas de discussão possíveis vulnerabilidades nestes sistemas. A empresa desenvolvedora, que também participa destas listas, verifica que realmente o seu sistema pode ser explorado e publica uma correção para o mesmo. Depois da publicação, os analistas de segurança mais atentos atualizam seus sistemas imediatamente. E pode acontecer que estes sistemas que estão sendo atualizados já foram comprometidos e que os invasores também já inseriram mecanismos, chamados de backdoors, para acessarem as máquinas invadidas de uma outra maneira. Este ciclo de descoberta e publicação de vulnerabilidades, criação e divulgação de correções, pode ser bastante desfavorável para quem trabalha com segurança pois estes não são os desenvolvedores dos sistemas. Nesta batalha os profissionais desta área ficam sempre desfavoráveis atuando somente na defensiva. Para tentar reagir nesta batalha injusta, conhecimentos militares de certa de 512 a.c vêm sendo muito úteis nos dias de hoje. Certa vez, Sun Tzu, estrategista militar chinês e autor da famosa obra A arte da guerra, disse: Assim, diz-se que aquele que conhece 27

o inimigo e a si mesmo não correrá perigo algum em cem confrontos. Aquele que não conhece o inimigo mas conhece a si mesmo será por vezes vitorioso e por vezes encontrará a derrota. Aquele que não conhece o inimigo e tampouco a si mesmo será invariavelmente derrotado em todos os confrontos. Desde muito tempo atrás, estratégias militares (Tzu e Pin, 2002) de defesa bem sucedidas são aquelas criadas com base no conhecimento do inimigo, seus tipos de armas, seus métodos de ataques, suas táticas de guerra e, principalmente, o seu objetivo. Conhecendo suas armas é possível conduzir treinamentos práticos. Conhecendo seus métodos de ataque é possível desenvolver métodos de defesa. Conhecendo suas táticas de guerra é possível projetar mecanismos para combatêlo. E conhecendo seus objetivos é possível entender a motivação que o incentivou a iniciar os ataques. Assim como os militares, a área de segurança de sistemas de informação também pode utilizar estes conhecimentos análogos para se defender contra ataques. Esta busca motivou os profissionais de segurança a criarem metodologias para obter informações mais precisas sobre os invasores, como utilizar máquinas preparadas para serem comprometidas (honeypots), visando o aprendizado das técnicas adotadas pelos invasores com os próprios invasores. Estas máquinas atuam como iscas para os invasores fisgarem, permitindo que todos os seus passos dentro destas sejam monitorados. Com esta nova metodologia é possível estudar novos ataques, capturar novas ferramentas, descobrir novas vulnerabilidades. Tudo dentro de um ambiente de rede controlado, conhecido como honeynet. Dentro desta abordagem, os analistas de segurança podem descobrir novas vulnerabilidades em sistemas antes mesmo que estas sejam publicadas em listas, permitindo que eles mesmos anunciem o fato as empresas desenvolvedoras dos software. Uma outra possibilidade de utilizar estas máquinas preparadas para serem comprometidas é auxiliar os sistemas de detecção de intrusão, visto que estes emitem muitos alertas falsos, e o tráfego destinado para os honeypots é considerado anômalo. A seguir serão mostrados mais detalhes sobre esta nova metodologia de segurança, que utiliza máquinas preparadas para serem comprometidas; e depois como capturar essas informações para serem analisadas. 28

1.2 Honeypots A primeira ocorrência publicada sobre monitoração dos passos dos invasores ocorreu em 1988, quando Clifford Stoll (Stoll, 1988) relatou um ataque sofrido pelo LBL (Lawrence Berkeley Laboratory). Um ano mais tarde, este relato se tornou um livro (Stoll, 1989). Nesta invasão sofrida pelo LBL, ao invés de tentarem bloquear os intrusos, Stoll e sua equipe resolveram permitir o acesso ao sistema enquanto monitoravam todas as atividades dos invasores até que suas origens fossem descobertas, o que levou quase um ano. Para acompanhar os passos dos invasores, impressoras foram instaladas em todas as portas de entrada do sistema, configuradas para imprimir todas as atividades que os invasores realizavam nas máquinas. Com a ajuda dessas informações, foi possível identificar não só a origem dos invasores, mas também quais eram seus objetivos e motivações, quais redes foram comprometidas e quais redes os invasores estavam interessados em atacar. Em 1992, Bill Cheswick (Cheswick, 1992) publicou um artigo descrevendo o acompanhamento de uma invasão ocorrida em 7 de janeiro de 1991 no Laboratório Bell da AT&T. Esta invasão ocorreu no gateway do laboratório que estava preparado para ser comprometido, rodando várias aplicações falsas tais como: FTP (File Transfer Protocol)(Postel e Reynolds, 1985), telnet (Postel e Reynolds, 1983), SMTP (Simple Mail Transfer Protocol)(Postel, 1982), finger (Zimmerman, 1991) e rlogin. O intuito desta monitoração era descobrir quem estava interessado em atacar o Laboratório; de onde vinham e qual a frequência destes ataques; e em que tipos de vulnerabilidades os invasores estariam mais interessados. Esta monitoração durou meses, e contou com a ajuda de várias pessoas como Steven M. Bellovin (Bellovin, 1992) que desenvolveu várias ferramentas utilizadas para atrair, conter e capturar as ações dos invasores. Em 17 de maio de 2002, Lance Spitzner (Spitzner, 2002) definiu claramente o conceito de honeypot como sendo Um recurso de segurança preparado para ser sondado, atacado ou comprometido, e explicou a sua real função Honeypots não são uma solução, eles não consertam nada, são apenas uma ferramenta. E o seu uso depende do que se deseja alcançar. Em 2003, March Roesch (Spitzner, 2003), o criador do sistema de detecção de intrusão Snort 2, categorizou o uso dos honeypots em 2 tipos: produção ou pesquisa. Para Roesch, honeypots de produção são utilizados para diminuir os riscos e ajudar a proteger as redes das organizações; e os honeypots de pesquisa são designados para estudar e obter informações da comunidade dos invasores. 2 http://www.snort.org 29

1.3 Honeynets A idéia de se criar uma rede preparada para ser comprometida visando o aprendizado, começou com uma pequena iniciativa de um analista de segurança da Sun Microsystems, chamado Lance Spitzner ( The Honeynet Project, 2002a), que resolveu conectar uma máquina Linux Red Hat 5.0 à Internet em 25 de fevereiro de 1999. Sua intenção era fazer com que a comunidade dos invasores lhe mostrasse como agia para rastrear, atacar e explorar sistemas. Surpreendentemente, sua armadilha funcionou em 15 minutos, quando sua máquina Linux foi invadida com sucesso. Infelizmente, o invasor percebeu que estava em um honeypot e apagou todo o conteúdo do sistema, destruindo todos os logs e ferramentas utilizadas durante o ataque. Em consequência disso, Spitzner resolveu preparar todo um ambiente para capturar os dados, de forma que os invasores não conseguissem mais apagá-los. Com a evolução desta idéia surgiu em 25 de abril de 1999 o Honeynet Project 3, que inicialmente foi formado por 30 profissionais interessados em aprender sobre as ferramentas, táticas e motivações dos invasores, e além disso compartilhar estas informações visando o aumento da segurança de sistemas. Só em junho de 2000 o projeto entrou em operação efetiva, quando um dos honeypots foi invadido. A invasão ocorreu em um Solaris 2.6 por um grupo organizado de invasores, tendo sido necessário contar com as habilidades de todos os integrantes do projeto para capturar os dados do ataque. Este estudo motivou o grupo a desenvolver uma ferramenta para ser especialmente utilizada com intuito de aprender quem são e como operam os invasores. Esta ferramenta foi denominada de honeynet, que nada mais é que uma rede preparada para ser comprometida, ou seja, uma espécie de laboratório que fica exposto à Internet para ser atacado, porém com alguns mecanismos de monitoração e coleta de dados. Com o passar do tempo, o grupo definiu dois elementos cruciais para a criação e manutenção bem sucedida de uma honeynet ( The Honeynet Project, 2002a). São eles: contenção a captura de dados. A contenção de dados foi definida como sendo uma forma de impedir que os invasores, após invadirem a honeynet, a utilize para atacar outras redes e a captura de dados foi definida com sendo uma maneira de coletar o maior número possível de informações sobre os passos dos invasores. 3 http://www.honeynet.org 30

Com a finalidade de juntar várias instituições internacionais envolvidas com pesquisas de honeynets foi criada a Honeynet Research Alliance 4. Um dos projetos que faz parte do Honeynet Research Alliance é o Honeynet.BR 5 (Balcão et al., 2002), criado em dezembro de 2001 no INPE (Instituto Nacional de Pesquisas Espaciais) com intuito de acompanhar as atividades maliciosas na Internet brasileira. 1.4 Esboço Geral desta Dissertação No próximo capítulo será mostrado o porque da utilização, quais os detalhes importantes que devem ser levados em consideração e por fim algumas soluções já disponíveis para tentar resolver este problema da monitoração, com as vantagens de desvantagens de cada uma. No Capítulo 3, será abordado uma pequena introdução ao Linux, sistema operacional para onde o presente trabalho foi desenvolvido, e módulos de kernel, pois como será mostrado, o processo de monitoração envolve detalhes de programação em kernel space. No Capítulo 4, algumas técnicas de captura de atividades em honeypots serão apresentadas. Nestas técnicas serão abordadas formas de monitoração em user e kernel space. Será mostrado também uma solução desenvolvida baseado na modificação do Bash. O Capítulo 5 mostrará algumas técnicas de ocultação de tráfego de rede em honeypots de alta interatividade. Estas técnicas são importantíssimas para evitar que os invasores percebam que estão sendo monitorados no momento em que os dados saem dos honeypots. Este capítulo envolverá detalhes da pilha de protocolos de rede do Linux. O Capítulo 6 apresentará o sistema de monitoração e reconstrução de atividades em honeypots nomeado SMaRT (Session Monitoring and Replay Tool), o qual é o objetivo desta dissertação. Será abordado também qual foi a solução adotado e o motivo, a arquitetura do sistema, como os módulos foram projetados e divididos, e por fim algumas precauções adotadas durante o desenvolvimento. Já no Capítulo 7 serão mostrados e discutidos os resultados obtidos com sistema desenvolvido. Sessões de ataques reais, capturadas na Honeynet.BR, com o SMaRT serão também apresentadas. E por último, o Capítulo 8 abordará as conclusões tiradas ao longo do desenvolvimento deste trabalho e algumas propostas para a continuação desta pesquisa. 4 http://www.honeynet.org/alliance 5 http://www.honeynet.org.br 31