proposta de um sistema de segurança autônomo utilizando ... · proposta de um sistema de...

UNIVERSIDADE FEDERAL DO SUL E SUDESTE DO PARÁINSTITUTO DE GEOCIÊNCIAS E ENGENHARIAS

Faculdade de Computação e Engenharia ElétricaBacharelado em Sistemas de Informação

Proposta de um Sistema de Segurança autônomo utilizandohoneypot de baixa interação no contexto de Nuvem.

Ane dos Santos Viana

Marabá - PA2016

Ane dos Santos Viana

Proposta de um Sistema de Segurança autônomo utilizandohoneypot de baixa interação no contexto de Nuvem.

Trabalho de Conclusão de Curso, apresentadoà Universidade Federal do Sul e Sudestedo Pará, como requisito necessário paraobtenção do Título de Bacharel em Sistemasde Informação.

Orientador:Prof. MSc. Gleison de Oliveira Medeiros

Coorientador:Prof. MSc. Diego de Azevedo Gomes

Marabá - PA2016

Dados Internacionais de Catalogação-na-Publicação (CIP)

Biblioteca Josineide da Silva Tavares da UNIFESSPA. Marabá,PA

Viana, Ane dos Santos

Proposta de um sistema de segurança autônomo utilizando

honeypot de baixa interação no contexto de nuvem / Ane dos Santos

Viana ; orientador, Gleison de Oliveira Medeiros, coorientador, Diego

de Azevedo Gomes. — 2016.

Trabalho de Conclusão de Curso (Graduação) - Universidade Federal

do Sul e Sudeste do Pará, Campus Universitário de Marabá, Instituto de

Geociências e Engenharias, Faculdade de Computação e Engenharia

Elétrica, Curso de Bacharelado em Sistemas de Informação, Marabá,

2016.

1. Sistemas de recuperação da informação - Medidas de segurança. 2.

Computação em nuvem. 3. Processamento eletrônico de dados - Medidas

de segurança. 4. Computadores - Controle de acesso. 5. Tecnologia da

informação. 6. Firewalls (Medidas de segurança para computadores). I.

Medeiros, Gleison de Oliveira, orient. II. Gomes, Diego de Azevedo,

coorient. III. Universidade Federal do Sul e Sudeste do Pará. IV. Título.

CDD: 22. ed.: 005.8

RESUMO

A Computação em Nuvem tem sido bastante utilizada como solução recente paraas demandas crescentes de usuários de serviços de Tecnologia da Informação, contudo esteambiente de Nuvem por ser um aglomerado de informações que hospeda diversos tiposde serviços com uma imensa quantidade de máquinas interligadas em rede, torna-se umalvo propício para os invasores. Como resposta ao aumento de intrusos, são elaboradasnovas estratégias para garantir a segurança. Nesse contexto, este trabalho tem por objetivopropor um sistema de segurança autônomo para a Nuvem Computacional, utilizando umhoneypot de baixa interação para coletar informações, e a tecnologia de agentes inteligentespara a extração de contramedidas, a fim de auxiliar na defesa de máquinas virtuais contraeventuais ataques, causados tanto por usuários mal-intencionados oriundos da internetquanto da própria Nuvem.

Palavras Chaves: Computação em Nuvem, Honeypot, Agentes, Script de Firewall.

Lista de ilustrações

Figura 1 – Total de incidentes de ataques por ano . . . . . . . . . . . . . . . . . . 14Figura 2 – Modelo Conceitual Parte-1 . . . . . . . . . . . . . . . . . . . . . . . . . 16Figura 3 – Modelo Conceitual Parte-2 . . . . . . . . . . . . . . . . . . . . . . . . . 16Figura 4 – Software como Serviço (SaaS) . . . . . . . . . . . . . . . . . . . . . . . 22Figura 5 – Plataforma como Serviço (PaaS) . . . . . . . . . . . . . . . . . . . . . 23Figura 6 – Infraestrutura como Serviço (IaaS) . . . . . . . . . . . . . . . . . . . . 24Figura 7 – Hypervisor Tipo I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figura 8 – Hypervisor Tipo II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 9 – Virtualização Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 10 – Paravirtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 11 – Localização física e lógica dos honeypots . . . . . . . . . . . . . . . . . 34Figura 12 – Arquitetura Básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 13 – LokiHoneypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figura 14 – Modelo de arquitetura proposta para Nuvem . . . . . . . . . . . . . . . 47Figura 15 – Diagrama da Disposição dos Serviços Emulados . . . . . . . . . . . . . 49Figura 16 – Configuração do Sistema Linux . . . . . . . . . . . . . . . . . . . . . . 50Figura 17 – Escaneamento no Sistema Linux Emulado . . . . . . . . . . . . . . . . 50Figura 18 – Diagrama do algoritmo das ações do AVM . . . . . . . . . . . . . . . . 51Figura 19 – Diagrama da relação entre os Agentes . . . . . . . . . . . . . . . . . . 52Figura 20 – Ambiente montado para a realização dos testes. . . . . . . . . . . . . . 54Figura 21 – Cenário das máquinas virtuais para os testes. . . . . . . . . . . . . . . 55Figura 22 – Log da interação com o HoneyD no serviço de SSH. . . . . . . . . . . . 55Figura 23 – Log da interação com o HoneyD no serviço telnet. . . . . . . . . . . . . 55Figura 24 – Diagrama de Caso de Uso do agente AVM . . . . . . . . . . . . . . . . 56Figura 25 – Codificação do agente AVM . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 26 – Esquema básico de comunicação entre agentes de ambientes diferentes. 58Figura 27 – Varredura no CloudNode . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 28 – Varredura na VMHoney . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 29 – Codificação do envio de mensagem . . . . . . . . . . . . . . . . . . . . 60Figura 30 – Estrutura Básica de um Agente JADE . . . . . . . . . . . . . . . . . . 61Figura 31 – Arquivo de configuração XML . . . . . . . . . . . . . . . . . . . . . . . 62Figura 32 – Registro do Envio do Script . . . . . . . . . . . . . . . . . . . . . . . . 62Figura 33 – Arquitetura para teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 34 – Escaneio de Portas no Usuário . . . . . . . . . . . . . . . . . . . . . . . 63Figura 35 – Firewall com política ACCEPT . . . . . . . . . . . . . . . . . . . . . . 64Figura 36 – Acessando os serviços ssh e telnet . . . . . . . . . . . . . . . . . . . . . 64

Figura 37 – Acesso os serviços ssh e telnet . . . . . . . . . . . . . . . . . . . . . . . 64Figura 38 – Bloqueio do Atacante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Figura 39 – Inibição do Ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Lista de tabelas

Tabela 1 – Discrepâncias entre os níveis de Interação . . . . . . . . . . . . . . . . 33Tabela 2 – Comparativo entre os pontos principais dos trabalhos relacionados . . . 44Tabela 3 – Configuração de hardware e software do cenário proposto . . . . . . . . 54

Lista de abreviaturas e siglas

IDS Intrusion Detection System

TI Tecnologia da Informação

NIST National Institute of Standards and Technology

WIS Worldwide Infrastructure Security

DDoS Distributed Denial of Service

DoS Denial of Service

HaaS Honeypot as a Service

SaaS Software as a Service

PaaS Platform as a Service

IaaS Infrastructure as a Service

XSS Cross Site Scripting

JVM Java Virtual Machine

VM Virtual Machine

FIPA Foundation for Intelligent Physical Agents

KVM Kernel-based Virtual Machine

JADE Java Agent Development Environment

HTTP Hypertext Transfer Protocol

ACL Access Control List

WEB World Wide Web

VLAN Virtual Local Area Network

CERT.br Centro de Estudos, Respostas e Tratamento de Incidentes de Segurançano Brasil

CN Computação em Nuvem

TI Tecnologia da Informação

ISO International Organization for Standardization

KQML Knowledge Query and Manipulation Language

ACL Agent Communication Language

SO Sistema Operacional

DMZ Zona Desmilitarizada

NMAP Network Mapper

SMA Sistema Multiagente

LGPL Lesser General Public License

XML Extensible Markup Language

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Objetivos Geral e Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Características Essenciais . . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Arquitetura da Nuvem Computacional . . . . . . . . . . . . . . . . 20

2.1.2.1 Atores e Papeis . . . . . . . . . . . . . . . . . . . . . . . . 202.1.2.2 Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.2.3 Modelos de Serviços . . . . . . . . . . . . . . . . . . . . . 21

2.1.3 Infraestrutura da Plataforma de Nuvem . . . . . . . . . . . . . . . 242.1.4 Modelos de Implantação . . . . . . . . . . . . . . . . . . . . . . . . 272.1.5 Benefícios Associados . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.6 Barreiras Inibidoras . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2 Fundamentos da Segurança Computacional . . . . . . . . . . . . . . . . . . 292.3 Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.1 Categorias quanto ao objetivo de Aplicação . . . . . . . . . . . . . 312.3.1.1 Honeypot de Produção . . . . . . . . . . . . . . . . . . . . 312.3.1.2 Honeypot de Pesquisa . . . . . . . . . . . . . . . . . . . . 32

2.3.2 Classificação baseada na Implementação . . . . . . . . . . . . . . . 322.3.3 Níveis de Interatividade . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.3.1 Baixa Interação . . . . . . . . . . . . . . . . . . . . . . . . 322.3.3.2 Alta Interação . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.4 Localização Física e Lógica . . . . . . . . . . . . . . . . . . . . . . . 332.3.5 Benefícios Associados . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.6 Deficiências Agregadas . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.7 Arquivo de Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4 Agentes Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.1 Categorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.4 Sistemas MultiAgentes - SMA . . . . . . . . . . . . . . . . . . . . . 382.4.5 Comunicação entre Agentes . . . . . . . . . . . . . . . . . . . . . . 392.4.6 Linguagem de Comunicação entre Agentes . . . . . . . . . . . . . . 39

3 Trabalhos Correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1 Modelo de Segurança Autônomo para Computação em Nuvem com Uso de

Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2 Automatic XSS detection and Snort signatures/ACLs generation by the

means of a cloud-based Honeypot System . . . . . . . . . . . . . . . . . . . 413.3 Honeypot as a Service in Cloud . . . . . . . . . . . . . . . . . . . . . . . . 423.4 Fast Dynamic Extracted Honeypots in Cloud Computing . . . . . . . . . . 423.5 Modelagem de um Sistema Distribuído orientado à Agentes para Coleta e

Análise de Código Malicioso da Internet . . . . . . . . . . . . . . . . . . . 433.6 Uma Ferramenta Adaptativa Baseada em Agentes Móveis Inteligentes para

Segurança de Aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . 443.7 Análise Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Modelo Proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1 Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Caracterização do Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 HoneyD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.2 Configuração dos Serviços . . . . . . . . . . . . . . . . . . . . . . . 494.2.3 Varredura de Portas . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Caracterização dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.1 Agente Virtual Machine (AVM) . . . . . . . . . . . . . . . . . . . . 504.3.2 Agente Controller (ACR) . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 Implementação e Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Descrição do Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 Interações com o HoneyD . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 Implementação do Agente . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3.1 Comunicação entre os Agentes . . . . . . . . . . . . . . . . . . . . . 585.3.2 Agent Development Framework (JADE) . . . . . . . . . . . . . . . 60

5.4 Manipulação do Arquivo de Log . . . . . . . . . . . . . . . . . . . . . . . . 615.5 Validação do Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.6 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

12

1 Introdução

O termo Cloud Computing, ou em português, "Computação em Nuvem"constitui,atualmente, um dos temas mais abordados na área da Tecnologia da Informação (TI) [1].É um paradigma global que provê serviços para as massas, que vão desde o usuário finalque hospeda seus documentos pessoais na internet, até empresas que terceirizaram todaa parte de TI para outras organizações [2]. Para exemplificar a Computação em Nuvempode-se citar o Dropbox ou provedores de email.

De acordo com National Institute of Standards and Technology (NIST) [3], aComputação em Nuvem é um modelo que possibilita acesso, de modo conveniente e sobdemanda, a um conjunto de recursos computacionais configuráveis, como por exemplo,redes, servidores, armazenamento, aplicações e serviços, que podem ser rapidamenteadquiridos e liberados com o mínimo esforço gerencial ou interação com o provedor deserviços. Entretanto, apesar dos aspectos positivos e dos benefícios potenciais que a cercam,trouxe consigo uma série de novos desafios no contexto da segurança da informação, poisestão sujeitos a uma gama de ameaças [4]. Como resposta a esta situação, alguns esforçosvêm sendo direcionados para detecção e prevenção de intrusos, principalmente na camadade Infrastructure as a Service (IaaS) [5, 6].

Esse ambiente de Nuvem é marcado pela contínua evolução tecnológica, e faz comque novos ataques surjam e tenham como resposta a elaboração de novas estratégiaspara garantir a segurança na Computação em Nuvem [4]. Uma das formas de lidar comeste problema é utilizar o que chamamos de honeypot, o qual consiste em um recurso desegurança cujo valor está na sua sondagem, ataque ou comprometimento [7]. O honeypotpermite simular softwares com vulnerabilidades, para distrair os invasores e/ou acompanhare colher dados sobre suas atividades, fazendo-os acreditar que estão obtendo acesso aosistema de produção real.

O valor de um honeypot está diretamente relacionado ao fato de que qualqueratividade direcionada a este, pode ser considerada suspeita [7]. Desta forma, é menosprovável a detecção de falsos positivos 1 e falsos negativos 2, fornecendo informações dealto valor em um volume bem menor, que outras ferramentas tradicionais de segurança,como por exemplo, o Intrusion Detection System (IDS) [8].

O IDS baseado em assinaturas, consiste em procurar características e padrões deataques conhecidos e armazená-los em uma base de dados. Contudo, precisa-se atualizar abiblioteca de regras, caso contrário um ataque mais recente lhe será omisso. Para eliminar1 Falso positivo ocorre quando uma ação legítima é classificada como uma possível intrusão.2 Falso negativo ocorre quando uma intrusão é classificada como uma ação legítima.

Capítulo 1. Introdução 13

esta deficiência, os honeypots são utilizados como defesa proativa, os quais detectam osintrusos na rede e capturam as informações dos ataques. A análise dos registros quesão gerados pelas interações, favorece o estudo de novas ações dos atacantes, como asmotivações, métodos, e as ferramentas frequentemente empregadas. Deste modo, viabiliza-se a construção de novos padrões de ataques, que posteriormente serão utilizados paramelhorar contramedidas às ameaças futuras e contribuindo para o desenvolvimento daspráticas de segurança [7, 9].

Nesse contexto, os honeypots podem aproveitar-se das características contidas nosagentes inteligentes, automatizando técnicas de segurança.

Na área de segurança em sistemas de informação, os agentes computacionais podemser utilizados na automatização de tarefas como na coleta e análise dos dados, aperfeiçoandoa rapidez de resposta em casos de ataques, provendo estatísticas, identificando ameaças,analisando grandes massas de dados ou observando tendências. Estas ações auxiliam natomada de decisão na ocorrência de incidentes e pode inclusive contribuir na prevenção dadisseminação de ataques. [10]

Este trabalho está organizado da seguinte forma: No capítulo 1, será exposto adefinição do problema, a solução proposta, a metodologia da pesquisa e os objetivos gerale específicos. No capítulo 2, encontra-se a fundamentação teórica. No 3 apresenta-se ostrabalhos relacionados que serviram de base para esta pesquisa. No 4,5 e 6 retrata-se sobreo modelo proposto, implementação e teste, e por fim a conclusão respectivamente.

1.1 ProblemáticaSegundo dados do Centro de Estudos, Respostas e Tratamento de Incidentes de

Segurança no Brasil (CERT.br) [11], o total de notificações recebidas sobre incidentescontra a segurança da informação no ano de 2015 foi de 722.205, como mostra a Figura1. Este número foi 31% menor que o total de 2014. No entanto, os dois últimos anossão os com maior índice em relação aos demais. Observa-se no ano de 2014 que númerode notificações revela-se alarmante com 1.047.031 incidentes. Dentre essas notificaçõesdo ano de 2015 estão diversos tipos de atividades maliciosas, agrupadas em categoriade incidentes e classificadas em rankings de primeiro a sexto lugar, respectivamentetemos, ataques a servidores web, ataques Denial of Service (DoS), tentativas de fraude,varreduras e propagação de código malicioso, comprometimento de computadores e porfim as enquadradas na categoria outros incidentes.

Ainda no ano de 2015, o relatório anual volume XI do Worldwide InfrastructureSecurity (WIS) aponta, que ameaças contra ambientes computacionais são recorrentesdurante todo o ano, havendo um aumento de ataques em relação ao ano anterior, visandoqualquer forma de serviço de nuvem, porém os serviços de IaaS revelam-se como os alvos


Figura 1: A figura mostra o total de incidentes por ano. Fonte: [11]

mais comuns, e também apontam em suas pesquisas, que os centros de dados são comoímãs para as atividades Distributed Denial of Service (DDoS), e assim tornando-se umagrande ameaça e motivo de preocupação [5].

A percepção de que o ambiente de Nuvem é um aglomerado de informações, quehospeda diversos tipos de serviços com uma imensa quantidade de máquinas interligadasem rede, torna-se alvo propício para os invasores.

Com o aumento das possibilidades de consumo em diversas formas na NuvemComputacional, as ameaças são potencializadas [12]. Apesar dos benefícios que trazconsigo, os consumidores preocupam-se com os riscos que a utilização deste ambiente poderepresentar [13].

A segurança e a privacidade são os principais desafios que podem impedir a amplaadoção da abordagem de Computação em Nuvem [14, 15]. Nos provedores de IaaS, porexemplo, o processo de registro para adquirir seus serviços é simples, tanto quanto fazer umacompra em um e-commerce. Como os registros podem ser anonimizados e o uso do serviçoé imediato após a contratação, malfeitores são capazes de realizar atividades maliciosasfacilmente, como propagar malwares ou qualquer outro comportamento consideradoilícito [13].

A administração de servidores e instâncias em Nuvem, torna-se aos poucos umaatividade complexa e árdua. As instâncias por exemplo, estão suscetíveis a usuários queutilizam suas próprias instâncias para capturar dados ou deflagrar ataques, além dapreocupação das ameaças oriundas da internet [16].

A motivação principal, surgiu do acréscimo dos incidentes maliciosos e a constanteevolução das estratégias de ataques às Nuvens Computacionais, e como forma de entender


tais ataques, a implantação de honeypots neste contexto apresenta-se como uma táticaardilosa, pois são armadilhas que preparam ambientes para que sejam explorados, paraa efetiva monitoração dos invasores, podendo ser classificados como uma camada desegurança complementar, que produz logs dos ataques ocorridos. Desta maneira, serãoempregados para implementar técnicas de segurança executadas por agentes inteligentes,para uma análise eficiente dos logs e assim gerar padrões de ataques de modo automatizado,pois tratam-se de um recurso de programação que representam elementos autônomos coma capacidade de manipular, trocar informações ou conhecimento e através da codificaçãoinserida adquirem autonomia para executar as operações que lhes foram designadas.

1.2 Solução PropostaA solução consiste em propor um sistema de segurança autônomo utilizando

honeypot de baixa interação no contexto de Nuvem, com a finalidade de empregar agentesautônomos para a extração de scripts de firewall de forma contínua a partir da verificaçãodo log gerado por interações feitas com um honeypot de baixa interatividade 3, no qualas interações são vistas como ataques ou invasões, pelo fato de ser uma ferramenta desegurança exclusivamente preparada ou configurada para simular vulnerabilidade paraatrair intrusos. O intuito é prover maior segurança para as instâncias, como da própriaNuvem. Esta solução proporciona que os scripts gerados sejam armazenados em um logespecífico, juntamente com a possibilidade da troca destes entre os agentes.

A Figura 2 ilustra o modelo conceitual no qual representa a estrutura interna daNuvem com um Cluster Controller, gerenciando suas VLAN’s e instâncias de usuários,contendo uma instância honeypot com a finalidade de atrair invasores.3 No honeypot de baixa interatividade são instaladas ferramentas para emular sistemas operacionais e

serviços com os quais os atacantes irão interagir.


Figura 2: Modelo Conceitual Parte-1.

A Figura 3 ilustra o modelo conceitual no interior da estrutura da Nuvem, no qualdo Node instanciará a VM honeypot aguardando interações para que os agentes atuem naaveriguação log, e com isso extrair os scripts armazenando-os em um log específico parapossíveis compartilhamentos.

Figura 3: Modelo Conceitual Parte-2.


1.3 Objetivos Geral e EspecíficosO objetivo deste trabalho é aplicar um honeypot de baixa interatividade na camada

IaaS da Computação em Nuvem, associando a tecnologia de agentes inteligentes paraexecutar o processo de geração de scripts de firewall válidos, com finalidade de auxiliar nasegurança da Nuvem juntamente com um IDS baseado em sistema multiagente (SMA).

No sentido de alcançar o objetivo geral, tem-se os seguintes objetivos específicos:

1. Analisar e expor as ferramentas necessárias para a associação entre a tecnologia deagente inteligente com o honeypot de baixa interatividade.

2. Aplicar um modelo de honeypot na Computação em Nuvem.

3. Implementar agentes que geram scripts de interações, baseando-se no log do honeypot.

4. Comprovar a funcionalidade dos scripts elaborados pelos agentes.

1.4 MetodologiaA pesquisa foi dividida em etapas, que consistiram na estrutura metodológica que

levou a contribuição desta pesquisa.

1. Busca do Tema: A segurança da informação é um dos fatores mais importantesna atualidade, devido ao valor que a informação representa para indivíduos comuns,e para as organizações. Pode ser comprometida por pessoas mal-intencionadas quetem o objetivo de furtar, destruir ou modificar tal informação [17]. Nesse contexto,soluções precisam ser criadas ou evoluídas, permitindo aplicações de metodologiasde defesa. O tema escolhido e abordado nesta pesquisa, envolve um procedimentotécnico para a defesa aos ataques na Infraestrutura da Computação em Nuvem.

2. Revisão Literária: Iniciou-se com a revisão da literatura relacionada ao tema,buscando a análise de paradigmas, metodologias e resultados de cada trabalho.

3. Definição do Problema: Com base na revisão literária observa-se que a Computa-ção em Nuvem, por transformar-se em um alvo conveniente para os intrusos, faz-senecessário a captura das informações geradas pelas ações maliciosas dos praticantes,a fim de aproveitá-las para aprendizagem de suas atividades e prevenir contra ataquesfuturos. Diante disto, a problemática explorada nesta pesquisa envolve usufruir dascaracterísticas concedidas pela tecnologia de agentes inteligentes, e aplicá-los demaneira associada a um honeypot de baixa interação, com a finalidade de gerarscripts de firewall de forma autônoma, e contribuir para minimizar as ameaças nesteambiente.


4. Modelo Proposto: Consiste em associar um modelo de honeypot de baixa interati-vidade com a tecnologia de agentes inteligentes, para a análise do log gerado pelohoneypot em uma Nuvem Computacional.

5. Implementação: A proposta será implementada utilizando a linguagem Java, agen-tes de software, hypervisor, e honeypot. As ferramentas de trabalho selecionadas sãolistadas e descritas a seguir:

• Linguagem Java: É uma linguagem de programação orientada a objetos,no qual sua portabilidade depende da existência de Máquinas Virtuais Java(JVM) [18]. Com o intuito de desenvolver o agente com uma linguagem concisa,concorrente e multiplataforma, favorecendo a extensibilidade e reusabilidade docódigo.

• HoneyD: É um software Open Source e uma camada de segurança comple-mentar para a rede [7].Com a finalidade de atrair e/ou dissuadir adversáriosque geram ataques na rede, através da configuração de serviços arbitrários.

• Kernel based Virtual Machine (KVM): É um virtualizador Open Sourcecompleta de hardware baseada em Linux [17]. Com o propósito de implementaro ambiente de Computação em Nuvem, utilizando a virtualização total deum hypervisor tipo 1, no qual é o componente chave no gerenciamento dainfraestrutura de virtualização.

• Java Agent Development Environment (JADE): É um framework de-senvolvido na linguagem Java e Open Source que cumpre as especificações Foun-dation for Intelligent Physical Agents (FIPA) [18]. Tem por objetivo facilitar aimplementação de aplicações baseadas em agentes inteligentes interoperáveisna rede.

• Log4j: É um framework de registro para Java, Open Source e distribuído sob alicença Apache Software [?].

• Putty: É um software de emulação de terminal que suporta acesso remoto porssh e telnet.

6. Teste: Etapa de avaliação dos resultados gerados nesta pesquisa, no qual utilizou-seum software de emulação de terminal.

19

2 Fundamentação Teórica

2.1 Computação em NuvemA Computação em Nuvem (CN) surge como um modelo para acessar serviços

oferecidos sob demanda, com transparência de localidade e provisão dinâmica de recursos [3].Ou seja, podem ser rapidamente providos ou liberados com pouco esforço de gerenciamento,pois é facilmente escalável.

O mecanismo de virtualização é uma das principais abordagens que permite aflexibilização do uso da camada de hardware, provendo ambientes de processamentoindependentes e isolados. Dessa forma, o ambiente de máquinas virtuais constitui umabase adequada para a construção de infraestruturas da CN [13].

A migração para a Nuvem computacional vem ocorrendo nos últimos anos nãoapenas atingindo empresas que terceirizam recursos de TI para outras organizações, comotambém os usuários domésticos que possuem maior necessidade de terem seus dados emmãos a qualquer momento. Vale destacar que estes consumidores, tornam-se isentos depreocupações corriqueiras ocorridas em modelos tradicionais de computação, como porexemplo, as manutenções e atualizações de softwares, hardwares e backup de arquivos.Por outro lado, tais responsabilidades passam a pertencer exclusivamente ao provedor deserviço da Nuvem [17].

Esse novo modelo de computação torna possível o acesso de arquivos, aplicativos eserviços que estão armazenados em servidores físicos e virtuais, por diversos usuários comqualquer dispositivo compatível, sejam eles móveis ou fixos através de uma rede disponível,tornando-se uma solução inteligente com facilidades e características atraentes. Contudo,para que todo o potencial da CN possa ser explorado pelas organizações, é fundamentalgarantir a segurança e a privacidade dos dados armazenados na Nuvem [19].

2.1.1 Características Essenciais

Segundo [3], há cinco características básicas que compõem uma solução de CN, sãoelas:

• Sob demanda: O consumidor dos serviços da CN adquire recursos computacionaisde acordo com sua necessidade e de forma instantânea. Para suportar este tipo deexpectativa, deve possibilitar o (self service) para que os usuários possam solicitar,personalizar, pagar e usar os serviços desejados sem intervenção humana [20]. Todoesse ajuste de hardware e software deve ser feito de maneira transparente para o

Capítulo 2. Fundamentação Teórica 20

usuário, afim de não interferir na utilização dos serviços contratados como completa[16].

• Amplo acesso: Os recursos devem estar disponíveis através da rede e podem seracessados por meio de mecanismos que permitam a utilização dos mesmos porplataformas heterogêneas [3]. A interface de acesso à Nuvem não obriga o usuário amudar suas condições e ambientes de trabalho, como por exemplo, em relação aslinguagens de programação e sistema operacional, e este acesso é feito através desoftwares clientes instalados localmente [2].

• Agrupamento de recursos: Os recursos computacionais disponibilizados porprovedores são organizados em um pool para servir múltiplos usuários usando ummodelo multi-inquilino, com diferentes recursos físicos e virtuais, dinamicamenteatribuídos e a justados de acordo com a demanda dos usuários [2]. Adicionalmente,o consumidor não precisa ter controle ou conhecimento acerca da localização dosrecursos providos.

• Elasticidade rápida: A Nuvem computacional propicia a ilusão de recursos infinitosdisponíveis para o uso. Portanto, os usuários idealizam a capacidade de consumirrapidamente recursos em qualquer quantidade e momento [21]. Esta expansão outambém a redução, só é possível devido à tecnologia de virtualização [2].

• Serviço medido: Há a possibilidade de diferentes modelos de pagamento, porémos serviços da Nuvem são tarifados normalmente por horas [16]. O uso de recursospode ser monitorado e controlado, propiciando a transparência tanto para o provedorquanto para usuário do serviço [2]. Contudo, em todos os casos, o pagamento seráestabelecido pela utilização do serviço e não de acordo com o custo do equipamento.

2.1.2 Arquitetura da Nuvem Computacional

De acordo com [22], os elementos principais da arquitetura sobre a qual Computaçãoem Nuvem baseia-se, distribui-se da seguinte maneira: atores, camadas, modelo de serviçoe modelos de implantação. Estes elementos encontram-se elencados subsequentemente.

2.1.2.1 Atores e Papeis

Os atores podem assumir vários papéis simultaneamente de acordo com os interesses,sendo que apenas o provedor fornece suporte a todos os modelos de serviços [2]. A seguirretrata-se a perspectiva de funcionamento do ambiente de Nuvem de acordo com a relaçãode atores e serviços, são eles: os provedores de infraestrutura, prestadores de serviços e porfim os consumidores.


a) Provedor de infraestrutura: Ator ou um conjunto de responsáveis peloambiente físico que gerenciam e monitoram a estrutura da Nuvem, propiciando os trêsmodelos de serviços. Este conjunto de empresas ou provedores, operam no nível dohardware e equipamentos de rede e transmissão. Contudo, trata-se como computaçãoutilitária entregue a prestadores de serviços [2, 23].

b) Prestadores de Serviços: Consumidor da infraestrutura da Nuvem, ou seja,concedem serviços para os usuários finais [23].

c) Consumidor ou Usuário final: Utilizam os serviços disponibilizados, sejameles software, plataforma ou infraestrutura. Dependendo do serviço e de suas regras, estãodisponíveis diversas interfaces de usuário [24].

2.1.2.2 Camadas

Conforme [2,22] a arquitetura da CN pode ser dividida em três camadas abstratas,e cada uma delas pode ter seu gerenciamento ou monitoramento realizado de formaindependente das outras, melhorando a flexibilidade, reuso e escalabilidade em relaçãoa substituição ou adição de recursos computacionais sem afetar outras camadas, como éexposto a seguir.

• Camada de Infraestrutura: É através desta, que os prestadores de IaaS disponi-bilizam seus serviços. Dessa forma, fazem parte os servidores, sistemas de armazena-mento, roteadores e outros recursos de hardware. Com isso, fornece flexibilidade efacilidade de agregação de novos recursos à medida que tornam-se necessários.

• Camada de Middleware: Responsabiliza-se por gerenciar a camada física e tempor objetivos prover um ambiente de execução apropriado para que as aplicaçõespossam ser desenvolvidas, testadas, implantadas e mantidas no ambiente de Nuvempelos prestadores de serviços.

• Camada de Aplicação: É a camada com o maior nível de abstração, disponibili-zando diversas aplicações como serviços para os usuários.

2.1.2.3 Modelos de Serviços

A Computação em Nuvem distribui os recursos na forma de serviços, e podem serprovidenciados em qualquer uma das camadas apresentadas [22]. O modelo de prestação deserviço são divididos normalmente em três classes dependendo do nível de abstração e doserviço a ser fornecido para o cliente [16]. Essas classes definem um padrão arquitetural esão nomeadas da seguinte forma: Camada superior - Software as a Service (SaaS); Camadaintermediária - Platform as a Service (PaaS); e a Camada inferior - Infrastructure as aService (IaaS) [21].


• Software as a Service – SaaS: Serviço que permite o uso de aplicações execu-tando dentro da infraestrutura de Nuvem. Estas estão acessíveis aos usuários atravésde vários tipos de dispositivos, como uma interface web. A obtenção de softwarescomo serviço torna-se atraente pelas vantagens de custo, dispensando a aquisição delicenças [2,25]. Um exemplo de SaaS comumente utilizado, é o software Skype, noqual dispõe de várias funcionalidades, e os usuários podem contratar funções quenecessitam pelo próprio programa, aceitando seus termos de serviço [26]. A figura 4representa um SaaS.

Figura 4: Software como Serviço (SaaS). [16]

• Platform as a Service – PaaS: Oferece como serviço um ambiente no qual ocliente pode criar e implementar aplicações, usando linguagens de programação eferramentas suportadas pela Nuvem, sem a preocupação com a camada subjacente[21, 25]. Um exemplo de PaaS é o Facebook, pois desenvolvedores podem criaraplicativos específicos para a plataforma desta rede social e deixá-los disponíveis paraqualquer um de seus usuários, como por exemplo jogos [26]. A figura 5 representaum PaaS.


Figura 5: Plataforma como Serviço (PaaS). [16]

• Infrastructure as a Service – IaaS : Plataforma de serviço utilizada por clientesempresariais em grande escala. O seu principal objetivo é facilitar o acesso aofornecimento de recursos de computação fundamentais para construir um ambientede aplicação sob demanda, e que podem incluir sistemas operacionais e aplicativos.Baseada em técnicas de virtualização esta infraestrutura pode escalar dinamicamente,aumentando ou diminuindo recursos de acordo com as necessidades das aplicações [2].Por se tratar da camada inferior, responsabiliza-se por prover a infraestruturanecessária para as demais camadas [21]. A Amazon EC2 é um exemplo de IaaS, poissuporta desde o menor aplicativo até sites em grande escala, fornecendo infraestruturade Nuvem para executá-los [26]. A figura 6 representa um IaaS.


Figura 6: Infraestrutura como Serviço (IaaS). [16]

2.1.3 Infraestrutura da Plataforma de Nuvem

Conforme [27], a infraestrutura para prover Computação em Nuvem é o conjuntodo hardware e software que viabiliza as cinco características básicas desse modelo. Assim,a Nuvem mescla uma camada física e uma de abstração que serão descritas a seguir.

• Camada Física: É composta pelos recursos de hardware necessários para comportaros serviços providos, e geralmente inclui componentes de servidores, armazenamentoe rede.

• Camada de Abstração: Consiste no sistema implantado na camada física, demodo a prover as características básicas do modelo. Essa estratégia para viabilizaruma plataforma que cumpra com os requisitos básicos para a CN utiliza-se a técnicade virtualização.

A virtualização funciona como uma camada computacional lógica entre a infra-estrutura física real e os processos computacionais, permitindo a abstração do recursofísico subjacente, no qual pode ser dividido em recursos lógicos ou virtuais conformenecessário, proporcionando um alto grau de portabilidade e flexibilidade ao ensejar quevárias aplicações de sistemas operacionais diferentes executem em um mesmo hardware.Essa técnica só é possível com inclusão da camada extra de gerenciamento de recursosde hardware e software. Tal camada, é denominada de Hypervisor ou Virtual MachineMonitor (VMM) [17,28].

Segundo [29], a virtualização possui uma nomenclatura própria para distinguir osseus componentes, são eles:


• Máquina Virtual: Simula um host real e executa instruções como se fosse a máquinafísica.

• Hospedeiro: É aquele que utiliza a virtualização de software para a execução deVMs.

• Guest Operating System: É um sistema operacional executado em uma VM.

Um componente chave da Computação em Nuvem é o gerenciamento da infraestru-tura de virtualização, cujo sistema é chamado de hypervisor [27]. Ou seja, responsabiliza-sepela virtualização e controle dos recursos físicos compartilhados pelas máquinas virtuais,como por exemplo, processadores, dispositivos de entrada e saída, memória, armazena-mento e pela gerência do sistema operacional executado na VM [17]. A seguir é descritodois tipos de VMM.

• Hypervisor Tipo I: Neste modelo, o hypervisor é executado diretamente nohardware subjacente, igualmente ao sistema operacional tradicional. Desta forma, oGuest é executado em uma camada acima do hardware, logo acima do hypervisor [17].Este controla a máquina real, e prover a noção para as máquinas virtuais. O trabalhode [30] cita exemplos de hypervisores do tipo 1, como o VMware ESXi, IBM PowerVM, XenServer e Kernel-based Virtual Machine (KVM). A figura seguinte demonstrao modelo. A figura 7 representa um Hypervisor Tipo I.

Figura 7: Hypervisor Tipo I. [17]

• Hypervisor Tipo II: Neste modelo, toda a camada de gerenciamento de VM éaplicada sobre sistema operacional subjacente. O Guest executa em um terceiro nívelacima do hypervisor [17]. Isso torna a aplicação virtual independente de software, poiso VMM não interage com o hardware, e sim com o Sistema Operacional hospedeiro. Otrabalho de [30] cita exemplos de hypervisores do tipo 2, como o VMWare Workstation,


Parallels Desktop e VirtualBox. A figura a seguir demonstra o modelo. A figura 8representa um Hypervisor Tipo II.

Figura 8: Hypervisor Tipo II. [17]

A implementação de máquinas virtuais pode ser obtida por intermédio das técnicasde virtualização total e paravirtualização. São descritas a seguir segundo os trabalhosde [17,30].

• Virtualização Total: Técnica que consiste na simulação completa dos hardwaressubjacentes, resultando em um sistema capaz de executar qualquer software queexecute diretamente sobre o hardware. O sistema Guest não precisa ser modificadopara ser executado pelo VMM. Para que essa técnica seja eficiente toda a infraes-trutura do hardware subjacente deve ser virtualizada. Entretanto podem ocorrerperdas de desempenho do ponto de vista da VM, uma vez que todo o hardware évirtualizado e as instruções de máquina devem ser interpretadas pelo hypervisor. Afigura 9 representa uma virtualização total.

Figura 9: Virtualização Total. [31]


• Paravirtualização: Nessa técnica, o Guest sofre alterações no seu Kernel para quehaja uma interação mais eficiente com o hypervisor. A paravirtualização não simulaum novo hardware para a VM, e sim possibilita o acesso direto os recursos físicosreais. O acesso é monitorado pelo hypervisor, que fornece ao sistema convidado todosos “limites” do sistema, tais como endereços de memória que podem ser utilizados eendereçamento de disco, aumentando o desempenho em relação a técnica anterior. Afigura 10 representa uma paravirtualização.

Figura 10: Paravirtualização. [31]

2.1.4 Modelos de Implantação

A implementação da Nuvem dependerá da necessidade do modo de acesso e adisponibilidade dos serviços proporcionados pelo provedor de Computação em Nuvem. Arestrição ou abertura de acesso depende do processo de negócios, do tipo de informaçãoe do nível de visão desejado [2]. Conforme [3], abaixo é exposto os quatros modelos deimplantação.

• Nuvem pública: A infraestrutura da Nuvem disponibiliza-se para o público emgeral, sendo acessado por qualquer usuário que conheça a localização do serviço.Neste modelo não podem ser aplicadas restrições de acesso quanto ao gerenciamentode redes, e menos ainda, aplicar técnicas de autenticação e autorização [2].

• Nuvem privada: Refere-se aos centros de dados internos de uma empresa ou outraorganização que são não disponibilizadas ao público em geral, e aplica-se técnicas deautenticação e autorização, afim de restringir o acesso [32].

• Nuvem comunitária: Possui a característica de compartilhamento da infraestruturapor várias organizações, no qual normalmente partilham preocupações como missão,requisitos de segurança, política e considerações de conformidade [21].

• Nuvem Híbrida: Compõem-se de duas ou mais modelos de implantação, em quecada Nuvem permanece como uma entidade única, mas estão unidas pelo uso da


tecnologia proprietária ou padronizada, permitindo a portabilidade de dados eaplicações [33].

2.1.5 Benefícios Associados

Grande parte das organizações independente do porte, demandam cada vez maisde recursos tecnológicos e necessitam contar com grande flexibilidade para ajustar seuscustos e suas capacidades de acordo com as demandas do mercado [12]. Assim, a CN provêo ambiente propício para esse desenvolvimento rápido e crescente, tornando-se convenientepara os consumidores em diversas perspectivas.

Comparando as listas de benefícios relacionados à CN, expostos por três autoresdistintos, sendo eles [21,22,34] verificou-se que muitos dos benefícios associados repetiam-se,então houve uma seleção, no qual são descritos a seguir.

• A Escalabilidade ou Flexibilidade: permite que aplicações adquiram mais re-cursos dinamicamente para hospedar os seus serviços, afim de lidar com ápice dotrabalho, e da mesma forma liberá-los quando a carga diminui.

• Redução de Investimento e Custeio: O usuário só paga por aquilo que con-some, e não arca com custos de manutenção, espaço físico para instalações ou comremuneração de pessoal especializado.

• Disponibilidade imediata de Recursos: Possibilita o provisionamento e a aqui-sição de recursos em tempo real, de qualquer lugar e para utilização imediata,conferindo maior disponibilidade e viabilizando, dessa forma a implantação maisrápida dos serviços. É possível ser acessado através de mecanismos que promovem ouso de plataformas heterogêneas, como por exemplo, desktops, laptops, smartphonese tablets, facilitando a utilização dos serviços.

• Foco no Negócio: Com a terceirização da infraestrutura de Nuvem significa usufruirsob uma arquitetura de última geração, possibilitando que empresas foquem nonegócio e nas suas aplicações.

• Redução do Investimento Inicial: A adoção da Computação em Nuvem leva àredução do investimento inicial em TI, permitindo que pequenas e grandes empresasganhem agilidade para rodar suas aplicações, tendo em visa que os recursos são depropriedades de terceiros.

• Minimização dos Riscos de Infraestrutura: Uma organização não precisa com-prar muitos recursos físicos para desenvolver uma aplicação. A responsabilidade dainfraestrutura passa a ser dos prestadores de IaaS, e não do usuário.


2.1.6 Barreiras Inibidoras

Os desafios da Computação em Nuvem que envolvem a segurança, escalabilidade,interoperabilidade, confiabilidade e disponibilidade são entraves que devem ser superadospara que esse novo paradigma se expanda ainda mais, e estão ligados às barreiras queinibem a sua adoção [21,22].

Ao comparar os diferentes autores [34] e [35, 36] percebeu-se uma concordânciasobre o que consideram como potenciais barreiras que podem servir de impedimento àcontratação de serviços em ambientes de Nuvem, no qual são relatados adiante.

• Falta de Capacidade Técnica: O ambiente de Computação em Nuvem por possuirum algo grau de complexidade, exige uma capacidade técnica para sua estruturaçãoe operação, e os usuários questionam-se se os provedores estão preparados para odesafio.

• Falhas de Segurança: A perspectiva de poder se defrontar com falhas de segurançaque comprometam suas operações é uma questão crítica para os consumidores e temcontribuído para levá-los a questionar a adoção da CN.

• Privacidade: A existência da possibilidade de violação é outra questão crítica paraos consumidores.

• Tradição Comportamental: Os consumidores mostram-se desconfiados perante ofato de não saberem onde e de que forma seus acervos de informações estão sendoguardados e manipulados.

• Qualidade: A complexidade dos ambientes de Nuvem é um fator que pode limitaro nível de qualidade dos serviços prestados.

• Confiabilidade: Se os consumidores sentem que não podem tê-la em plenitude,resistem em aderir aos modelos de serviços.

2.2 Fundamentos da Segurança ComputacionalA segurança na Nuvem refere-se a um amplo conjunto de políticas, tecnologias

e controles implantados para proteger os dados, aplicativos e infraestrutura associada àComputação em Nuvem [16]. Como este ambiente está sendo utilizado para hospedardiversos tipos de serviços que exigem garantias de segurança dos dados, os provedores econsumidores de serviços necessitam de abordagens seguras, abrangentes e confiáveis [13].

Na Computação em Nuvem, seja em um ambiente virtual, físico, compartilhado oudedicado, onde é possível que usuários obtenham poder computacional através de processose ferramentas, deve haver maior atenção e controle à segurança das informações [37]. Como


há a percepção da Nuvem ser um aglomerado de informações e com uma imensa quantidadede máquinas interligadas em rede, caracteriza-se como alvo propício aos potenciais invasoresexplorarem vulnerabilidades de qualquer lugar do mundo e o impacto causado por essaação pode gerar problemas de grande dimensão. Portanto, a segurança passa a ser um dosfatores chaves para o sucesso ou fracasso na adoção de CN e ao adotá-la, evidencia-se asdúvidas e preocupações pelos utilizadores.

Entidades como Open Cloud Manifesto, Computing Use Cases Group e o CloudSecurity Alliance trabalham no desenvolvimento de padrões de segurança para CN quepermitam empresas integrar seguramente os serviços de Nuvem de diferentes fornecedorese terem garantia que seus dados permanecerão seguros [38].

O esquema de segurança computacional preserva através da International Orga-nization for Standardization (ISO) com a norma ISO 7498-2, os seguintes princípios: aautenticidade, confidencialidade, integridade, disponibilidade e não-repúdio [39]. Estas porsua vez, também devem ser aplicados em processos executados na Nuvem com o propósitode ser uma solução tecnológica eficaz e transparente. A seguir descreve-se os princípiossupracitados.

• Autenticidade: Os usuários são especificados e estabelecidos às prioridades de acessoe permissões, dependendo da Nuvem adotada e do modelo de troca de dados. [16].

• Confidencialidade: Mantém o controle sobre os dados das organizações situadasem vários bancos de dados distribuídos, e que devem permanecer secretos e somenteacessados por usuários autorizados [16]. Os Principais mecanismos de proteçãoda confidencialidade em sistemas de informação, são desenvolvidos com base nosconceitos de criptografia, politicas de acesso e de uso [40].

• Integridade: É uma implicação do acesso aos dados na Computação em Nuvem.Portanto, as propriedades ACID (atomicidade, consistência, isolamento e durabili-dade) devem ser robustamente impostas em todos os seus modelos de serviços [16].Os Principais mecanismos de proteção da integridade são controles de acesso queimpedem a modificação não autorizada de informações e mecanismos que se des-tinam a detectar modificações não autorizadas quando os dispositivos preventivosfalham [40].

• Disponibilidade: Garante que a informação será acessada quando necessário e umdos requisitos de segurança da informação para decidir entre os fornecedores deNuvem privada, pública ou híbrida [16]. Ataques de DDoS e DoS são corriqueiroscontra disponibilidade dos sistemas [41].

• Não Repúdio: Na Nuvem Computacional obtém-se através da aplicação dos tra-dicionais protocolos de segurança de e-commerce e provisionamento token para


transmissão de dados das aplicações, tais como assinaturas digitais, timestamps eserviços de confirmação [16].

2.3 HoneypotNos dias atuais com a amplitude da internet, as redes de computadores estão

sujeitas a ação de atacantes que visam não só em benefício próprio, sejam em termosfinanceiros ou intelectuais, como também prejudicar os usuários da rede com a intençãode adquirir acessos, alterar informações e comprometer serviços. Essas vulnerabilidades eos riscos emergentes, despertam o interesse pelo estudo e desenvolvimento de mecanismosde segurança capazes de minimizar as possibilidades de comprometimento da rede. Ouso de firewall é um desses mecanismos, no qual normalmente é inserido em pontos deconcentração, nas fronteiras entre as redes e de forma à propiciar o gerenciamento dotráfego, aplicando as restrições definidas em sua configuração [42,43]. Outro método usadopara detectar possíveis ataques maliciosos à rede são os sistemas de detecção de intrusão,pois são mecanismos de monitoramento de sistemas ou recursos da rede em busca deindícios que identifiquem uma invasão, ou seja, tem o objetivo de localizar o motivo deum problema ocorrido na rede e quando isto ocorrer, notificam os incidentes ou aplicaçõesnecessárias contra o ataque [42, 44]. Para que haja entendimento sobre os objetivos etécnicas utilizadas pelos invasores, existem os honeypots, o valor destes baseia-se no fato deque tudo o que é observado é suspeito e potencialmente malicioso, e sua aplicação dependedo tipo de resultado que se quer alcançar [11]. São sistemas de segurança defensivos quepreparam um ambiente para ser atacado, sondado e potencialmente explorado, e assim sejafeita uma monitoração das ações do atacante, no qual dados são coletados e armazenadosem logs, para que uma devida análise seja efetuada. Desse modo, através das informaçõescontidas nos logs há a possibilidade da formação de conhecimento a respeito dos padrões deataques, como as motivações, métodos, e ferramentas comumente utilizadas, melhorandodefesas às ameaças futuras [42, 45,46].

2.3.1 Categorias quanto ao objetivo de Aplicação

Conforme [46, 47], os honeypots podem ser divididos de acordo com seus objetivos,em duas categorias: Produção e Pesquisa. Entretanto, essa divisão não é totalmente distinta,sendo possível haver características de ambas as categorias. Descritas a seguir.

2.3.1.1 Honeypot de Produção

Estes honeypots são valiosos para as organizações, particularmente a comercial,uma vez que contribui para proteger a infraestrutura de segurança, no qual o objetivoé diminuir os riscos da rede principal utilizando as configurações da rede de produção


real e deste modo, agindo de maneira ativa na prevenção de novos ataques. São facil-mente implementados e gerenciados, pois dispõem de poucas funções e consequentementedisponibilizam informações limitadas sobre os atacantes.

2.3.1.2 Honeypot de Pesquisa

Empregados principalmente por organizações militares, acadêmicas e governo. Oobjetivo destes honeypots é capturar o máximo de informações sobre os ataques, permitindoa análise detalhada sobre sua efetivação, ferramentas e técnicas utilizadas, origem doataque e vulnerabilidades exploradas. Ou seja, o foco está nas ações do intruso e nãoapenas na detecção.

2.3.2 Classificação baseada na Implementação

Os trabalhos dos autores [16,48] apresentam uma distinção entre honeypots, no qualdistinguem-se em: Físicos e Virtuais. O honeypot virtual é um software executado em umaVM que permite a configuração de seus comportamentos e simular sistemas. As respostaspara requisições externas variam de software para software. Inúmeros honeypots podem sersimulados em um ambiente, tornando-se atraentes para implementação por requisitarempoucos recursos, reduzindo os custos de manutenção. O honeypot real significa que estásendo executado em uma máquina física com seu próprio endereço IP, implicando em umnível de alta interação com o invasor, e consequentemente propicia o comprometimento dosistema. Para uma grande faixa de endereços, torna-se impraticável implantar um honeypotfísico para cada grupo de endereços IP, pois os custos de implantação e manutenção seriamelevados, nesse caso a solução viável seria implantar honeypots virtuais.

2.3.3 Níveis de Interatividade

Outra maneira de classificação leva em conta o nível de envolvimento, no qual éequivalente ao grau de interação entre o invasor e o honeypot. A quantidade coletada e ovalor da informação, o risco de comprometimento e o nível de implementação, seja commáquinas, sistemas e aplicações reais ou virtuais, torna-se diretamente proporcional aonível de interação oferecido pelo honeypot [47, 49]. Abaixo os dois níveis de envolvimentoconsiderados.

2.3.3.1 Baixa Interação

Proporciona uma comunicação limitada entre o honeypot e o atacante, contudosão constantemente utilizados para pesquisa, identificando e coletando informações deataques. São configurados para emular determinados sistemas operacionais e serviços derede em portas pré-configuradas, como FTP, SQL e SSH. Ou seja, o atacante não interage


com o sistema real, e sim com um ou conjunto de softwares que emulam outros tipos desistemas. Em termos de instalação, configuração e manutenção, são os mais fáceis paraimplementar [16,50]

2.3.3.2 Alta Interação

Nestes honeypots os atacantes interagem com sistemas operacionais, aplicaçõese serviços reais, em função disto pode obter total controle e oferecer risco para todoo sistema. São instrumentos que coletam uma vasta quantidade de informações, o queresulta em um registro mais completo dos dados referentes aos ataques e sobre as etapasrealizadas para a sua deflagração. Portanto, são utilizados para descobrir vulnerabilidadese estudar com detalhes o invasor e seu comportamento. Normalmente implementados ondehá um controle da rede com a presença de ferramentas e métodos de proteção e detecção,resultando em uma implantação e administração complexas [51,52].

A tabela subsequente expõe os níveis de interatividade considerados.

Características Baixa Interatividade Alta InteratividadeInstalação Fácil DifícilManutenção Fácil Difícil

Aceso ao SO real Não SimAplicações e Serviços Emulados Reais

Risco de comprometimento Baixo AltoColeta de Informações Limitada Extensa

Tabela 1: Discrepâncias entre os níveis de Interação. Adaptado de [7]

2.3.4 Localização Física e Lógica

Em conformidade com [53,54] ao se construir um ambiente de monitoramento comhoneypot, necessita-se considerar a localização do mesmo. Esta posição varia de acordocom o que espera-se capturar. Expõem-se em seus trabalhos as três principais localizaçõesna captura de ataques: Em frente ou atrás do firewall, ou na Zona Desmilitarizada (DMZ).

(a) Antes do firewall: Neste local o honeypot ficará propositalmente exposto ao máximo,sem ter nenhum tipo de ferramentas de proteção e prevenção no ambiente, e portantoo invasor conseguirá causar mais dados, pois haverá a liberdade para acessá-lo econsequentemente será capaz de capturar um grande volume de informações.

(b) Junto à rede interna, após o firewall: Esse tipo de configuração é recomendada parainvestigação interna de ataques e roubos de informação dentro de vlan’s privadas.Para outros tipos de utilização esta técnica não recomenda-se, como para detecçãode vulnerabilidades do firewall, pois obriga os administradores abrirem restrições de


acesso para a rede interna, situação que pode causar grandes riscos ao possibilitarque o invasor acesse a intranet, sem limitações do firewall.

(c) Zona Desmilitarizada (DMZ): Nessa arquitetura o honeypot estará no mesmo níveldos principais servidores da rede. Por estar dentro da mesma faixa, um invasor podefazer uma varredura de portas, encontrar o honeypot e acreditar que trata-se de umservidor real. Em contrapartida, considera-se a solução mais segura e eficiente, pois otráfego é filtrado por um firewall e por outros sistemas de controle e monitoramento,diminuindo significativamente os riscos para a intranet da organização.

Figura 11: Localização física e lógica dos honeypots. [53]

2.3.5 Benefícios Associados

Embora o conceito envolvendo honeypots seja simples, esses recursos proporcionamalgumas vantagens como características. A seguir são listadas de acordo com o artigode [16,55].

• Ausência de falsos negativos.

• Exigência de mínima de hardware nos casos de honeypot virtuais.

• Captura de tráfego criptografado.

• Coleta de dados variante sobre o invasor e do ataque.

• Camada adicional de segurança.

• Simplicidade na utilização no sentido de não necessitar desenvolver algorítimoscomplexos.


2.3.6 Deficiências Agregadas

Como toda tecnologia, os honeypots também possuem pontos fracos, geradosprincipalmente pela configuração incorreta. No trabalho de [55] lista-se as seguintesdesvantagens:

• Gera uma visão limitada no sentido de capturar somente atividades diretamenterelacionadas a ele.

• Oferece riscos caso seja utilizado pelo invasor para lançar ataques a outros sistemas.

2.3.7 Arquivo de Log

Como a maioria dos sistemas computacionais, os honeypots geram logs e estespossuem informações úteis para a investigação de problemas. O formato desses logs dependeda necessidade de armazenamento de registros do sistema. Porém, a escolha do formato irádeterminar como os dados estão organizados, e dependerá de como, para que, por quem,de quanto em quanto tempo, onde e por qual motivo serão utilizados. Especificamenteno caso dos honeypots, os logs são a base para o estudo de vulnerabilidades e de ataquesocorridos em busca de técnicas, ferramentas, e motivos pelos quais os atacantes estãoagindo. Através da análise adequada, todas estas informações sobre os invasores podemser obtidas possibilitando a detecção de padrões de ataques. Contudo, da mesma formaque nos outros sistemas, os logs são de difícil análise e por esse motivo são buscadasferramentas que auxiliem na realização desta tarefa [42,56].

2.4 Agentes InteligentesA Inteligência Artificial contempla uma imensa variedade de subcampos, e busca o

desenvolvimento de sistemas que simulem a capacidade humana de raciocínio, percepção etomada de decisão para a resolução de problemas, ou seja, sistemas que tenham capaci-dade de serem inteligentes. Com as descobertas relacionadas à construção de programascapazes de exibir um comportamento inteligente, pela qual a computação convencionalnão traz resultados satisfatórios, suas aplicações tornaram-se inúmeras e veio sendo empre-gados em diversas áreas, como Sistemas Distribuídos, Segurança da Informação, Rede deComputadores e outros [57].

O termo "agente inteligente "emerge nesta evolução. A tecnologia de agentes é umcampo abrangente e tem adquirido, nos últimos anos, uma importância cada vez maiorem muitos aspectos da computação. O conceito de autonomia e de aplicações capazes deexecutar tarefas de forma inteligente e independente tem despertando grandes interesses.Interações entre agentes que trabalham juntos para um objetivo único e maior, vêm


reforçando e amadurecendo o conceito de sistemas multiagentes que não são apenas tópicosde pesquisa, mas já estão se tornando um importante assunto na área de ensino acadêmicoe em aplicações comerciais e industriais. Como consequência disso, várias metodologias,arquiteturas e ferramentas já foram criadas para facilitar o desenvolvimento de sistemasmultiagentes [58].

Não há um conceito unânime e uniforme para o termo “agente”. O que existe narealidade é uma convergência para características fundamentais que uma “peça de software”deve possuir para ser considerada um agente [59]. Contudo, uma definição completa édada por [60], que descreve um agente como uma entidade de software que funciona deforma contínua e autônoma em um ambiente particular, sendo capaz de perceber e atuarde forma flexível e inteligente, sem requerer intervenção ou orientação humana constantes.O trabalho de [61] destaca algumas características dos agentes a seguir.

• Autonomia: Opera independentemente, sem a intervenção direta de humanos oude outros agentes. Ele tem controle sobre seu estado interno e comportamento.

• Sociabilidade: Capaz de interagir/cooperar com outros agentes (humanos ou não)por meio de uma linguagem de comunicação.

• Reatividade: Percebe estímulos do seu ambiente e reagir a estes estímulos.

• Proatividade: Um agente não é apenas uma entidade que reage a um estímulo, elepossui a habilidade de iniciar ações.

• Mobilidade: Locomoção através de rede de computadores.

• Adaptabilidade: Capacidade de adaptação, ou seja, é capaz de alterar o seucomportamento com base na sua experiência (aprendizagem).

2.4.1 Categorias

Para melhor compreensão da aplicabilidade da tecnologia de agentes, é possívelfazer uma classificação de acordo com aspectos quanto à mobilidade, ao relacionamentointeragentes e à capacidade de raciocínio [61]. Assim, os agente são classificados a seguir.

• Agentes Móveis: Movem-se por uma rede interna local ou pela web, transportando-se pelas plataformas levando dados e códigos.

• Agentes Estacionários: Opostos aos móveis. Isto é, são fixos em um mesmoambiente e/ou plataforma.

• Agentes Competitivos: Competem entre si para a realização de seus objetivos outarefas, ou seja, não há colaboração entre os agentes.


• Agentes Colaborativos: Possuem a finalidade de alcançar um objetivo maior.Realizam tarefas específicas, coordenando-as entre si de forma que suas atividadesse completem.

• Agentes Reativos: Comportam-se segundo o modo estímulo-resposta, ou seja, nãohá memória sobre ações realizadas no passado e nem previsão de ações que poderãoser executadas no futuro.

• Agentes Cognitivos: Ao contrário dos agentes reativos, podem raciocinar sobre asações tomadas no passado e planejar ações para o futuro. Esses agentes são dirigidospor intenções, isto é, por metas explícitas que conduzem seu comportamento e ostornam capazes de escolher entre possíveis ações e atingir seus objetivos.

2.4.2 Arquitetura

Um agente é construído a partir de técnicas e algoritmos que são usados por umametodologia específica que irá definir se ele irá agir isoladamente ou em grupo, definindoos funcionamentos de seus sensores e estados internos, que são fatores determinantes paraa realização de todas as ações dos agentes com o decorrer da utilização [62]. Os agentesinteligentes baseados em sistemas computacionais possuem o seguinte esquema:

Figura 12: Arquitetura Básica do Agente Inteligente. [62]

Esclarecendo os itens que compõem a figura, temos:

• Setas: fluxo de dados.

• Sensores: Obtém as informações do ambiente e concede os dados para o mecanismode inferência.

• Mecanismo de inferência: Atua como cérebro do agente. As operações são execu-tadas através das regras estabelecidas e determina a reação do agente de acordo comos dados recebidos pelos sensores.


• Base de conhecimento: Onde a aprendizagem adquirida pelo agente é armazenada.

• Atuadores: Executam as ações definidas pelo agente com o ambiente.

2.4.3 Classes

Na construção de programas que utilizam agentes, deve-se decidir como construir omapeamento de percepções a ações. No trabalho de [63] é exposto a existência de quatroclasses diferentes de agentes, possuindo cada um aspectos diferenciados na busca da soluçãode problemas, são os seguintes:

• Agentes de Reflexos Simples: Reagem a eventos no ambiente utilizando umconjunto de regras condição-ação predeterminadas. São considerados os mais simples,pois seu comportamento é puramente reativo.

• Agentes Reativos baseados em Modelo: Possuem uma representação do estadodo mundo no qual é atualizada dinamicamente com sua percepção. A reatividade écondicionada pelas experiências anteriores que se encontram refletidas nesse estadodo mundo. Implica que a mesma percepção ocorrida em momentos distintos econsequentemente estados diferentes do mundo, tenham como resultados açõesdiferentes.

• Agentes baseados em Objetivo: Além da descrição do estado corrente do mundo,utilizam a informação sobre os objetivos que pretendem atingir. São mais flexíveis,pois diferentes comportamentos podem ser obtidos para o mesmo estado do mundo,dependendo de seus objetivos.

• Agentes baseados na Utilidade: A utilidade corresponde à uma medida desatisfação do agente relativa ao cumprimento dos seus propósitos, e podem serempregadas para decidir entre objetivos em conflito ou medir a proximidade noalcance destes, quando existe incerteza nas ações. Conseguem ser mais racionais,pois possuem a capacidade para avaliar a utilidade da execução de uma determinadaação.

2.4.4 Sistemas MultiAgentes - SMA

São sistemas compostos por múltiplos agentes que atuam no sistema por meiode cooperação e/ou concorrência. Ou seja, cada agente deverá possuir conhecimento ehabilidades para executar uma determinada tarefa, ou cooperar para satisfazer objetivosem comuns. Também são capazes de interagir para aprender, informando uns aos outrossobre mudanças no ambiente ou sobre novas descobertas, trocando experiências [57, 64].


2.4.5 Comunicação entre Agentes

Conforme [65], os métodos de comunicação ou a troca de informações entre osagentes, podem ser divididos em dois grupos: Quadro de avisos e Trocas de mensagens.

1. Quadro de avisos ou Quadro negro: Mantem-se uma área de trabalho comumnas quais os agentes podem trocar informações, dados e conhecimentos. Uma açãode comunicação é iniciada quando algo é escrito no quadro negro e assim, outrosagentes podem a qualquer momento verificar se alguma informação foi modificadaou adicionada.

2. Troca de Mensagens: Esse tipo de comunicação forma uma base flexível paraa implementação de estratégias de coordenação complexas. Em contraste com ossistemas de quadro negro, as informações são trocadas diretamente entre os agentes.

No trabalho de [66], a troca de mensagens é classificada em:

• Ponto-a-ponto: As mensagens são enviadas para um agente especifico que deveser conhecido pelo emissor. Uma grande vantagem dessa abordagem é que o agenteemissor sempre sabe para onde uma mensagem está sendo enviada, o que permite afácil introdução de controles de segurança.

• Broadcast: A mensagem é enviada para todos os agentes da sociedade. Nesseabordagem, um agente pode ser substituído por outro equivalente e o processamentodo sistema será inalterado. A passagem por broadcast não é segura, já que qualqueragente pode examinar o conteúdo das mensagens.

• Multicast: A sociedade de agentes é dividida em grupos. Desta forma, as mensagenspodem ser enviadas somente aos agentes de determinados grupos.

2.4.6 Linguagem de Comunicação entre Agentes

O mecanismo de troca de mensagens necessita da definição de um protocolode comunicação que especifique o exato processo de comunicação, um formato para asmensagens e uma linguagem de comunicação. Esses requisitos nos levam as Linguagens deComunicação de Agentes (ACL) e aos serviços de transportes de mensagens. Uma ACLdetermina um meio através do qual uma atitude (por exemplo, afirmação, requisição econsulta) a respeito do conteúdo da troca de conhecimentos é comunicada [66].

A FIPA-ACL [67] é uma linguagem de comunicação de agentes padronizada esugerida pela Foundation for Intelligent Physical Agents (FIPA), surgindo como concorrenteda Knowledge Query and Manipulation Language (KQML), que era a única linguagemcom implementações disponíveis na época e muito criticada por suas imprecisões na


semântica de sua gramática e dificultando que sistemas multiagentes de serem compatíveise interoperáveis.

41

3 Trabalhos Correlatos

Nesta seção o objetivo é expor alguns trabalhos que apresentam uma relação a estee o que há de diferente em comparação aos existentes na literatura.

3.1 Modelo de Segurança Autônomo para Computação em Nuvemcom Uso de HoneypotO protótipo apresentado no trabalho [16] testa um modelo de segurança com o

objetivo de fornecer características autonômicas a uma Nuvem Computacional privada,a fim de assegurar a integridade das máquinas virtuais, reduzir a interação humana e otempo de manutenção. Utilizou-se um framework, no qual foram configurados dois ciclosautônomos, o primeiro responsável por monitorar as interação como um honeypot debaixa interatividade, e coletar das informações necessárias para gerar listas de permissãoe controle de acesso, inserindo-as no controlador da Nuvem. O segundo ciclo restaurainstâncias honeypot comprometidas. Por fim, disponibilizando o serviço honeypot paragerar lucros ao provedor e auxiliar na defesa contra ataques de usuários mal-intencionadosda própria Nuvem no nível da infraestrutura.

3.2 Automatic XSS detection and Snort signatures/ACLs genera-tion by the means of a cloud-based Honeypot SystemA arquitetura proposta por [68] detecta automaticamente ataques cross site scrip-

ting (XSS) e gera assinaturas para implementá-las no Network based IDS Snort (NIDS),bloqueando ataques similares no futuro. Para isso, utiliza-se um honeypot de baixa inte-ratividade configurado em uma VM, localizado no interior da infraestrutura da Nuvemprivada, em outro grupo de acesso diferente das instâncias de produção, no qual simula umservidor web que fica exposto e/ou vulnerável à esses tipos de ataques XSS. A fim de atingirseu objetivo, este desenvolve um script 1 que irá extrair automaticamente informaçõesnecessárias do log do honeypot e analisá-las em seu modelo (ACL 2ou assinatura Snort).1 Scripts podem classificar-se como arquivos de comandos executados por sistemas computacionais.2 ACL refere-se a uma lista de controle de acesso.

Capítulo 3. Trabalhos Correlatos 42

3.3 Honeypot as a Service in CloudDemonstra-se na pesquisa [69] a implementação de um honeypot de alta intera-

tividade 3, no qual independentemente do software usado para configurar o ambientede Nuvem, cria um serviço denominado de Honeypot as a Service (HaaS). Ou seja, osserviços são disponibilizados mediante a solicitação de compra do cliente. Baseia-se noredirecionamento do tráfego malicioso para o honeypot. Além disso, o usuário terá acessoaos registros que disponibilizam informações sobre os atacantes e as estatísticas sobre seusataques.

3.4 Fast Dynamic Extracted Honeypots in Cloud ComputingÉ descrito no artigo [70] a implementação e avaliação da arquitetura de um

honeypot dinâmico adaptado para a infraestrutura de Nuvem. A arquitetura propostadetecta possíveis ataques nas fases iniciais e atrasa-os até que uma nova VM honeypot sejaextraída da VM original do usuário que está sob ataque. O processo de extração refere-sea um processo de clonagem, porém com dados reduzidos evitando a divulgação dos dadosinternos. Com base em um modelo de notificação definido, o usuário da Nuvem recebe umrelatório com erros de configuração atuais e vulnerabilidades desconhecidas da sua VMoriginal. Abaixo lista-se o fluxo da arquitetura proposta pelo autor, no qual segue-se seteetapas de forma sequencial.

• Passo 1: O controlador honeypot identifica um ataque que visa um convidado.Essa identificação é o gatilho para a extração honeypot e para o procedimento deimplantação. O controlador recupera o endereço IP do alvo e da fonte do ataque. Oprocedimento de extração do honeypot é um processo de clonagem da VM originalporém sem dados privados ou confidenciais.

• Passo 2: O controlador atrasa o ataque até um novo honeypot ser instanciado.Este atraso é importante, pois o processo de ataque não deve ser interrompido ouperturbado.

• Passo 3: O honeypot é extraído e implantado em poucos segundos, para não surgirsuspeita e não haver interrupção do fluxo de trabalho do atacante.

• Passo 4: O controlador redireciona o tráfico da fonte de ataque para o honeypotrecentemente implantado.

• Passo 5: O honeypot é monitorado e as informação sobre o ataque em curso épassivamente coletado.

3 Em honeypots de alta interatividade os atacantes interagem com sistemas operacionais, aplicações eserviços reais.


• Passo 6: Após a detecção de um ataque bem sucedido, o honeypot é cancelado semrevelar qualquer informação. Por isso a monitorização é necessária.

• Passo 7: Um relatório para o usuário Nuvem dono da VM original é gerado, revelandoas vulnerabilidades encontradas.

3.5 Modelagem de um Sistema Distribuído orientado à Agentespara Coleta e Análise de Código Malicioso da InternetA arquitetura desenvolvida por [10] para a coleta e análise de malware baseia-se em

agentes afim de automatizar o processo. Este sistema multiagente, consiste de 5 módulos:Módulo de Captura de Spam, Módulo de Captura por Ataques, Módulo de Coleta deMalware, Módulo de Análise (Estática e Dinâmica) e Módulo de Gerenciamento. O módulode Captura por Ataques contém um honeypot de baixa interatividade, onde o agenteresponsável por este, monitora-o periodicamente e obtém os malwares coletados, e insere-osem um banco de dados especifico. O protótipo do sistema foi desenvolvido para analisarmalware no sistema operacional Windows XP, contido em um emulador sobre plataformabase Linux. A seguir lista-se os módulos detalhadamente.

• Módulo de Captura de Spam: Opera a partir de um agente de email. Este agentefica em estado dormente e periodicamente acessa o servidor de email em busca demensagens não lidas para analisá-las na busca de links com arquivos executáveis einseri-los no banco de dados específico e assim voltar à dormência.

• Módulo de Captura por Ataques: Dividi-se em duas partes: um sensor de ataquese o agente que obtém osmalwares coletados pelo sensor. O sensor é implantado a partirde um honeypot. O agente responsável por esse módulo, monitora periodicamente osensor e, caso haja malwares no diretório, insere-os no banco de dados especifico.

• Módulo de Coleta de Malware: Possui grande capacidade de armazenamentopara os malwares. Este módulo hospeda os agentes de spam e de captura de ataques.

• Módulo de Análise: Analisa o malware estática e dinamicamente. Na análiseestática, o agente visa obter informações sem executá-lo, e um outro agente verificaseu comportamento. Após isto, cada agente conecta-se ao banco de dados de análisee insere os dados obtidos.

• Módulo de Gerenciamento: Responsável pelo banco de dados de análise e pelobanco de dados de exemplares, o agente enviará os exemplares de malwares nãoanalisados para o módulo de Análise, controlando a transferências dos mesmos. Epor fim, gerar os relatórios de cada um deles, após a análise completa.


3.6 Uma Ferramenta Adaptativa Baseada em Agentes Móveis In-teligentes para Segurança de Aplicações WebO trabalho [28] trata da implementação de um firewall de aplicação que contém

algumas características dos sistemas autônomos. Sua função é receber todas as solicitaçõesHTTP 4 direcionadas aos servidores web e filtrar pacotes nocivos às aplicações, redirecio-nando esse tráfego suspeito para o honeypot de baixa interatividade, que irá documentar astentativas de intrusão nas aplicações o que auxiliará o agente móvel inteligente a detectarnovos padrões de ataques e atualizar a base de conhecimento do firewall em tempo real.

Figura 13: LokiHoneypot. [28]

3.7 Análise Comparativa

Trabalho Aplicação na Nuvem Tipo de Honeypot Baseado em Agente[16] Sim Baixa Interação Não[70] Sim Baixa Interação Não[69] Sim Alta Interação Não[68] Sim Baixa Interação Não[10] Não Baixa Interação Sim[28] Não Baixa Interação Sim

Tabela 2: Comparativo entre os pontos principais dos trabalhos relacionados

Todos os trabalhos apresentam objetivos em comum à esta pesquisa, no qualutiliza-se o honeypot para coletar dados dos invasores da rede e a partir da análise,extrair informações relevantes para desenvolver estratégias de segurança. Nas pesquisas[16,69,70] [68] o honeypot concentra-se em uma Nuvem Computacional para auxiliar naproteção, e pode ser disponibilizado como serviço ou não. As formas de análise e usodos dados são diversificados, contudo não utilizam a tecnologia de agentes autônomos.4 HTTP refere-se como um protocolo da camada de aplicação para a transferência de hipertexto


Nos trabalhos [10, 28] o honeypot apresenta interações com agentes inteligentes, paraautomatizar a análise dos dados coletados. Do mesmo modo, explorando juntamente outrascaracterísticas além da sua autonomia. Porém, o honeypot não localiza-se no ambiente deNuvem. No entanto, o presente trabalho tem por objetivo utilizar um honeypot de baixainteratividade, em conjunto com a tecnologia de agentes. O honeypot se responsabilizarápor coletar informações de atacantes, e os agentes cooperativos por automatizar o processode extração de contramedidas, através das informações obtidas pelo honeypot no ambienteda Nuvem. Tais características não são observadas nos trabalhos citados como podemosverificar na Tabela 3.7, no qual faz uma comparação entre os principais atributos dostrabalhos relacionados

46

4 Modelo Proposto

Esta seção apresenta a proposta de um mecanismo autônomo para a geraçãode scripts de firewall, para a proteção de instâncias e do ambiente de Computação emNuvem. Para isso, seu funcionamento será apresentado, bem como a ferramenta para atrairinvasores, pois o mecanismo baseia-se nas informações das interações com os atacantesdisponibilizadas no log do honeypot. Deste modo, o agente inteligente se responsabilizaráem extrair os respectivos scripts das interações vigentes de forma autônoma.

4.1 Arquitetura PropostaA arquitetura proposta tem como objetivo fornecer uma técnica autônoma no

contexto da Nuvem Computacional, a fim de auxiliar na defesa de máquinas virtuaiscontra eventuais ataques, causados tanto por usuários mal-intencionados oriundos dainternet quanto da própria Nuvem, que utilizam as próprias instâncias para sondar asdemais, com a possibilidade de capturar dados ou lançar ataques para comprometero seu funcionamento. O modelo proposto age na segurança no nível da Infraestruturacomo Serviço (IaaS), no qual emprega-se a tecnologia de agente inteligente para prover aeconomia de tempo e autonomia de forma contínua na análise do log concedido por umhoneypot de baixa interatividade, e também na automatização do processo de filtragemdas informações necessárias para extração de scripts dos ataques ou invasões no interior doambiente de Nuvem. Este modelo resume-se na instalação e configuração de um honeypot,o qual simula ambientes para atrair potenciais atacantes, e no desenvolvimento de doisagentes que possuem tarefas diferenciadas. O agente AVM é instanciado na VMHoneypotrealizando um conjunto de ações definidas para alcançar o objetivo proposto. O agentede software ACR é instanciado no Node Controller incorporando-se a um IDS baseadoem multiagentes, e suas funcionalidades são implementadas pelo autor [?]. Isto tem porobjetivo complementar um ambiente de segurança composto por um IDS multiagente,onde será utilizado juntamente um honeypot baseado em agente como uma ferramentaauxiliar na prevenção de novos ataques. O ACR responsabiliza-se por executar os scripsgerados pelo AVM e assim contribuir para a segurança das instâncias. Esta funcionalidadede troca de informações entre os agentes facilita a identificação e neutralização de usuárioscom más intenções na Vlan.

A figura 14 ilustra o modelo de ambiente interno proposto para Nuvem. Tem-seuma Vlan e nesse ambiente os componentes necessários para o funcionamento do modelo,e logo após é descrito cada elemento deste diagrama.

Capítulo 4. Modelo Proposto 47

Figura 14: Modelo de arquitetura proposta para Nuvem. Autoria Própria.

• Node Controller : É executado em todos os hosts físicos da Nuvem que hospedarãoas máquinas virtuais. Este componente responsabiliza-se pelo gerenciamento dasVirtual Machines (VMs), no qual pode iniciar, parar e colher informações sobreas mesmas. Essas ações sobre a plataforma de virtualização são realizadas pelacomunicação entre o NC e o hypervisor 1 das máquinas físicas.

• Honeypot: Tem por objetivo atrair e/ou dissuadir adversários que geram ataques narede, através da configuração de serviços arbitrários. Fornecendo o log das interaçõesocorridas.

• Agente VM: Efetua a tarefa de análise do log gerado pelas interações feitas como honeypot, e extrai os scripts dos ataques, a partir da filtragem das informaçõesfundamentais, automatizando ambas as atividades. Por fim, envia os scripts paraoutro agente na rede.

• Agente ACR: Dentre outros agentes de um IDS baseado em multiagentes, esteresponsabiliza-se por receber e executar os scripts de bloqueio para conter as açõesde invasores.

1 Hypervisor pode considerar-se como um camada extra de gerenciamento de recursos de hardware esoftware.


• Cluster Controller : Gerencia e escalona as requisições de instanciação das VMsentre os NCs, conferindo os recursos disponíveis decide qual máquina física deveráinstanciar as VMs requisitadas, além de administrar as vlans das instâncias.

4.2 Caracterização do HoneypotO honeypot descrito é o HoneyD, onde há inúmeras possibilidades de configuração,

desde a emulação de um até dezenas de sistemas ou serviços, no qual o administrador possuia responsabilidade de decidir quantos sistemas e/ou serviços será necessário implementar.

4.2.1 HoneyD

O HoneyD é um daemon para o desenvolvimento de hosts virtuais, concebidopara processar pacotes de rede destinados ao IP dos sistemas emulados, e cada endereçocorresponde a um sistema com serviços distintos. Nas suas configurações defini-se como oshosts funcionarão, como por exemplo, quais os sistemas que serão emulados, quais serãoos IP’s, o endereço físico, as portas TCP ou UDP abertas, os scripts desenvolvidos nalinguagem Perl ou em shell script para emular serviços associando-os as portas.

Este software disponibilizado nas versões Unix e Windows, consiste em um ho-neypot de baixa interatividade, no qual as ações dos atacantes restringe-se às interaçõesapenas com serviços emulados e consequentemente a coleta de informações sobre essesinvasores torna-se limitada. Devido todas essas interações realizadas com o honeypot seremconsideradas maliciosas, por sua finalidade ser exclusivamente atrair atacantes ao simularvulnerabilidades, um ping nessa instância também é monitorado, e deste modo regrasprecisam ser criadas para que um determinado IP de destino não seja classificado comouma ameaça.

Para a realização deste trabalho foi instalado e configurado o HoneyD em suaultima versão 1.5c em uma instância com o sistema operacional Ubuntu versão 14.04. Valefrisar, que outro tipo de honeypot poderia ser utilizado. O HoneyD foi escolhido por ser aferramenta de baixa interação mais aplicada no meio acadêmico segundo [68].

A figura 15 representa a distribuição dos serviços no host emulado pelo HoneyD.O Sistema Linux está configurado para interagir nas portas 22 e 23, rodando respectiva-mente um serviço SSH e telnet. Vale frisar, que ambos os serviços são ferramentas paraacesso remoto em máquinas conectadas na rede. O sistema e as portas foram escolhidosaleatoriamente para testes, porém qualquer outro sistema, porta ou serviço pode sersimulado.


Figura 15: Diagrama da Disposição dos Serviços Emulados.

4.2.2 Configuração dos Serviços

Primeiramente criou-se um modelo para implantar as características do honeypot,e após ser criado uma personalidade para este modelo ou seja, como o sistema queserá emulado, pode-se determinar a ação padrão que o honeypot tomará. A ação resetno protocolos TCP, significa que a porta ficará fechada por padrão, até que haja umainteração para responder a conexão. Posteriormente, adiciona-se as portas abertas e/ouserviços que serão emulados. Por fim é atribuído um endereço físico qualquer para sevincular ao IP do modelo de honeypot, no qual pode ser fixo ou atribuído por DHCP.Vale ressaltar que existem diversos outros comandos possíveis de serem combinados noarquivo de configuração do HoneyD. A figura 16 representa a configuração básica paraque o honeypot simule um sistema Linux.


Figura 16: Configuração do Sistema Linux

4.2.3 Varredura de Portas

Utilizou-se a ferramenta Network Mapper (Nmap) para auxiliar na análise e desco-brimento de vulnerabilidades. As funcionalidades do Nmap consistem, por exemplo, emfazer uma avaliação da rede e quais serviços estão disponibilizados, identificação de portasabertas, e do sistema operacional da máquina alvo. A figura 17 ilustra a detecção dasportas abertas e o nome dos serviços associados, para fins de teste no sistema emuladopelo HoneyD.

Figura 17: Escaneamento no Sistema Linux Emulado

4.3 Caracterização dos AgentesOs agentes participantes da arquitetura serão descritos com a finalidade de de-

monstrar suas atividades e relações, nos quais são aplicados diretamente em hypervisorese máquinas virtuais da Nuvem.

4.3.1 Agente Virtual Machine (AVM)

O agente VM é instanciado na máquina virtual do HoneyD, e inicia em modo deespera, verificando em intervalos de tempo até que haja alteração no log do honeypot, o


que indica uma interação. Se não satisfazer esta condição, o agente mantem-se em modode espera até a próxima verificação. Caso contrário, serão buscadas apenas as interaçõesrealizadas nos sistemas simulados pelo honeypot, pois serão consideradas contatos maliciosos.Logo após, ocorre a filtragem do endereço IP do invasor e a porta do serviço que estáacessando, para que seja gerado scripts de bloqueio, e por fim armazená-los em um logespecífico para que deste modo possam ser enviados. Se não houver interação com osserviços emulados não serão gerados scripts de bloqueio. A figura 18, ilustra o diagramade fluxo do algoritmo das ações do AVM.

Figura 18: Diagrama do algoritmo das ações do AVM. Autoria Própria.

4.3.2 Agente Controller (ACR)

Este agente é instanciado no hypervisor local para coordenar o ciclo de vida deoutros agentes, e também responsabiliza-se por receber e armazenar notificações de ataques.Para cada recebimento de alerta define-se uma ação a ser realizada, ou seja, aplica-se umacontramedida associada a uma assinatura de ataque para conter as ações de intrusos nacamada de IaaS da Nuvem [?].


Assim como o ACR que haverá apenas uma instância em execução por vez paracada hypervisor, haverá apenas um AVM em execução responsável por gerar scripts deuma VM Honeypot. A comunicação entre os agentes estabelece-se quando o AVM extraium script de bloqueio advindo de uma interação maliciosa da VM Honeypot. O AVM entãoguarda-o em um log específico e envia-o através da rede para o ACR do hypervisor, com oobjetivo de compartilhar a técnica de bloqueio para impossibilitar o mesmo ataque emoutras VMs. O ACR recebe o script e guarda-o para finalmente executar a neutralizaçãodo ataque.

Figura 19: Diagrama da relação entre os Agentes. Adaptado de [?].

4.4 Considerações FinaisNeste capítulo buscou-se apresentar e esclarecer tanto a forma como a ferramenta

HoneyD serviu de auxilio para os agentes inteligentes na geração de scripts de bloqueio,como também as atividades e relações entre os agentes para que atingissem o objetivofinal proposto.

53

5 Implementação e Teste

Este capítulo aborda a implantação e implementação dos componentes dispostosna metodologia proposta no trabalho. Primeiramente descreve-se o ambiente de teste paraavaliar a solução posposta, simulando um cenário que permitisse a coleta de resultados.Logo após, busca-se explanar sobre os resultados obtidos com a ferramenta HoneyDe demonstrar a modelagem e codificação do agente de software como um mecanismoautônomo para a geração de scripts de firewall. Ao final realizou-se a exemplificação passoa passo da técnica de validação, a partir dos resultados obtidos com a concretização destapesquisa. A seguir, a construção do ambiente e os detalhes do desenvolvimento de cadaum dos componentes serão apresentados.

5.1 Descrição do CenárioPara a realização deste trabalho foi elaborado um ambiente de teste que simula

uma infraestrutura de Nuvem. O ambiente é composto por um host Node Controllerdenominado CloudNode, o qual gerencia as máquinas virtuais instanciadas. Na figura20, é possível visualizar esse ambiente de teste que utiliza as máquinas virtuais criadase as conexões entre elas para simular as operações em um ambiente virtual, o qualserve de base ao funcionamento de uma Nuvem Computacional. As inter-relações doscomponentes são as seguintes: O CloudNode é o host que instancia e gerencia a VMHoney ea VMAttack; VMHoney simula o sistema (Linux Suse) e aguarda por interações; VMAttacké o responsável por interagir com o sistema simulado (Linux Suse).

Capítulo 5. Implementação e Teste 54

Figura 20: Ambiente montado para a realização dos testes. Autoria Própria

A configuração de hardware e software utilizado para a montagem do ambiente deteste são detalhados na tabela 3, e a seguir a figura 21 mostrando o cenário das VMs emexecução.

Nome Endereço IP Hardware SoftwareCloudNode 192.168.122.1; Br0

200.18.89.29Processador: Corei3 1.70 ghz; Memó-ria: 4 GB;

Linux Mint 17; Hyper-visor KVM; API Lib-virt; Virt-Manager 10.1;NetBeans 8.0.2; JADE4.3.3.

VMHoney 192.168.122.205;Br0 200.18.89.84

Processador: 1 nú-cleo; Memória: 2GB;

Ubuntu 14.04; HoneyD1.5c; Eclipse standard4.3.2; JADE 4.3.3; Log4j2.

VMAttack 192.168.122.74 Processador: 1 nú-cleo; Memória 512MB;

Ubuntu 14.04

Tabela 3: Configuração de hardware e software do cenário proposto. Autoria Própria.


Figura 21: Cenário das máquinas virtuais para os testes. Autoria Própria.

5.2 Interações com o HoneyDNesta seção é exposto os resultados das interações realizadas na ferramenta honeypot,

especificamente nos serviços simulados. O log gerado contém informações sobre a interaçãoe sobre o invasor. As figuras 22 e 23 demonstram as tentativas de intrusão de outra instânciada rede no sistema Linux simulado pelo HoneyD por indivíduos mal intencionados. Oarquivo de log gerado derivou das interações percebidas pelo honeypot na porta 22 e 23respectivamente. O papel principal do HoneyD foi exercido quando atingiu seu objetivo deservir como isca para atrair invasores e assim coletar informações dos mesmos com baseno nível de interatividade permitido. Optou-se por um honeypot de baixa interação, poisfornecia as informações necessárias para gerar resultados nesta pesquisa.

Na primeira linha do arquivo de log do HoneyD os dados são apresentados seguindoa sequência, o primeiro campo corresponde ao tempo em que o evento ocorreu, incluindomilissegundos. O segundo campo corresponde ao protocolo (TCP, UDP ou ICMP). A letra"S"significa o início de uma ligação (interação) com o sistema, e os quatro campos seguintesrepresentam o IP do invasor e porta de origem, IP do honeypot e porta de destino. Por fim,no último campo é apresentado uma identificação passiva do sistema operacional simulado.Vale frisar, que a estrutura do log no decorrer do tempo sofre pequenas variações, nãoseguindo sempre a sequência acima.

Figura 22: Log da interação com o HoneyD no serviço de SSH. Autoria Própria.

Figura 23: Log da interação com o HoneyD no serviço telnet. Autoria Própria


5.3 Implementação do AgenteNesta fase de implementação do agente, utilizou-se as informações das interações

contidas no log do honeypot para a extração dos scripts de bloqueio das invasões. Nodecorrer da seção explica-se cada ação do agente genericamente através da diagramação eposteriormente o detalhamento por meio da codificação.

Para um melhor entendimento, utilizou-se como auxílio as notações do diagramade caso de uso da UML, descrevendo objetivamente as funcionalidades do agente AVMsem se preocupar com a implementação interna de cada função. Conforme a figura 24, oator representa o agente de software e seus casos de uso são: "Analisar Log", "Filtrar Log","Extrair Script", "Enviar Script"e "Gerar Log". O caso de uso "Analisar Log"é responsávelpor executar uma leitura contínua no arquivo de log do HoneyD, no qual constantementesofrerá alterações em seu tamanho a medida que ocorrem as interações com o honeypot.O "Filtrar Log"busca por interações com o sistema simulado pelo HoneyD. O "ExtrairScript"corresponde a ação em que são extraídas as informações necessárias para montarum script de bloqueio do ataque. O "Enviar Script"é o compartilhamento do produtofinal após vários outros processos. O "Gerar Log"é uma inclusão da ação anterior, ou seja,sempre será executado quando o agente enviar um script, e deste modo finaliza as tarefasdo agente AVM.

Figura 24: Diagrama de Caso de Uso do agente AVM. Fonte: Autoria Própria

O classe AVM é definida como subclasses da classe Agent e seu código inicial éposto dentro do método setup(). A instância Logger referencia o arquivo chamado pelo Log-Manager.getLogger(). A estrutura de dado do tipo HashSet aceita apenas valores únicos,ou


seja, qualquer valor duplicado inserido será automaticamente excluído, basicamente suafunção é armazenar scripts distintos. O comportamento temporal TickerBehaviour realizasuas ações de forma cíclica em um intervalo definido, no caso será em 60000 milissegundos,e o método onTick() deste comportamento nunca termina a menos que seja removido poroutros métodos. A leitura do arquivo de log inicia-se pelo InputStream, no qual cria-seuma instância de FileInputStream passando como argumento a localização do arquivo. Aclasse BufferedReader recebe o objeto Reader e concatena os diversos chars para formaruma String. O método readLine() devolve a linha que foi lida e muda o cursor para apróxima linha. O laço while() é para ler o arquivo por inteiro. Um vetor é criado paraarmazenar as linhas de log facilitando a extração dos dados posteriormente. A condiçãofiltra o log a partir da observação de que as interações com o sistema simulado continhamum tamanho superior a 90 caracteres. O IP e porta são extraídos pelo posicionamentono vetor. O script resume-se em inserir uma regra de firewall na tabela filter e na chainFORWARD para que haja o bloqueio de todos os pacotes que utilizam o protocolo detransporte tcp que se originam do ip do atacante com destino a porta dos serviços abertosno honeypot. Logo após, são selecionados e mostrados apenas os scripts distintos.

Figura 25: Codificação do agente AVM. Fonte: Autoria Própria


5.3.1 Comunicação entre os Agentes

Para que a comunicação entre os agentes ocorra corretamente entre plataformasdistintas, utilizou-se o protocolo Hypertext Transfer Protocol (HTTP), e o MessageTransport Protocol (MTP) no qual é responsável por empacotar, desempacotar e transmitirmensagens ACL de acordo com as especificações FIPA [67]. A figura 26 representa umesquema básico de comunicação com estes protocolos entre agentes de ambientes diferentes,porém localizados na mesma infraestrutura de Nuvem. Após o Agente AVM gerar scriptsde bloqueio dos ataques, encaminhará o mesmo para o agente ACR que tem a finalidadede executar esta contramedida, e assim proteger outras máquinas do mesmo tipo de ataquedetectado no HoneyD.

Figura 26: Comunicação entre agentes de plataformas distintas. Fonte: Autoria Própria

Por default no framework JADE, o HTTP-MTP é ativado no container principal,e com isso cria-se um socket que aguarda por conexões de plataformas remotas via HTTP,escutando na porta 7778. A porta do container principal por padrão é a 1099 paracomunicações locais. As figuras 27 e 28 ilustram as portas 1099 e 7778 ativas nos hostsonde ocorreu a comunicação entre os agentes AVM e ACR.

A figura 27 demonstra que na VMHoney realizou-se uma varredura de portas paraaveriguar se a porta 7778 estava aberta na máquina CloudNode.


Figura 27: Varredura no CloudNod. Fonte: Autoria Própria

A figura 28 indica que no CloudNode realizou-se uma varredura de portas paraconstatar se a porta 7778 estava aberta na máquina VMHoney.

Figura 28: Varredura na VMHoney. Fonte: Autoria Própria

A codificação prossegue dentro do laço com a troca de mensagens, onde cada scriptgerado e selecionado será enviado para o agente ACR automaticamente. Para iniciar o pro-cesso de comunicação entre agentes autônomos, instancia-se da classe jade.lang.acl.ACLMessageum objeto que irá receber a identificação INFORM. Cada instância Agent é identificadapor um AID, e desta maneira deve-se criar um objeto que recebe como parâmetro o nomeglobal do agente destinatário, e atribuir seu endereço HTTP, no qual será o canal de comu-nicação referente ao protocolo MTP. O addReceiver recebe um objeto AID, que contém asinformações necessárias para que a mensagem chegue ao seu destino. O setContent recebeuma String como conteúdo da mensagem para ser enviada posteriormente pelo métodosend(). A instância Logger registra a troca de informações entre os agentes armazenandoa identificação de ambos e classificando o nível da mensagem do tipo INFO. Por fim,enquanto existir conteúdo para ser lido passa para a próxima linha, finalizando as tarefasdo agente AVM.


Figura 29: Codificação do envio de mensagem. Fonte: Autoria Própria

5.3.2 Agent Development Framework (JADE)

Nesta subseção, apresenta-se a plataforma utilizada neste trabalho para o desen-volvimento do agente. Segundo [?], o JADE é uma plataforma para desenvolvimento deaplicações baseadas em agentes que implementam as especificações definidas pela FIPA,visando permitir a interoperabilidade entre sistemas multiagentes. Oferece diversas funcio-nalidades que buscam simplificar o trabalho do desenvolvedor, livrando-o de atividadescomo: Implementação de uma plataforma, gerenciamento do ciclo de vida dos agentes, eo desenvolvimento de uma infraestrutura para transporte de mensagens. Além disto, édesenvolvido na linguagem Java e distribuído pela Telecom Italia Lab (TILAB), sendo umsoftware livre sob os termos e condições da licença Lesser General Public License (LGPL).

Uma característica significativa da plataforma JADE é que pode adequar-se emum cenário distribuído, basta que os hosts executem uma Java Virtual Machine (JVM).Os agentes são implementados como threads Java e inseridos dentro de repositórios deagentes chamados de containers, no qual representam um ambiente onde os agentes podemexecutar seu ciclo de vida, ou seja, provê todo o suporte para a execução das aplicaçõesbaseadas em agentes [17].

A figura 30 ilustra a estrutura básica de um agente, onde os agentes são definidoscomo subclasses da classe Agent e o código inicial sobre o que o agente fará ao serexecutado será posto dentro do método "setup()". Cada ação que um agente pode realizaré representada como um comportamento. O código que implementa esta funcionalidadedeve estar em uma nova classe, que herde as funcionalidades da classe Behaviour, estaclasse que especifica o comportamento do agente, deve possuir o método action(), ondeserá incluído o código referente ao comportamento a ser executado pelo agente, e o métododone(), no qual devolve um valor booleano, indicando se o comportamento foi finalizado


ou não.

Figura 30: Estrutura Básica de um Agente JADE. Fonte: [17]

5.4 Manipulação do Arquivo de LogA tarefa de manipulação dos arquivos de log foi abstraída através da utilização

do Log4j, no qual é um framework de código aberto, distribuído sob a licença ApacheSoftware e implementado na linguagem Java que permite gravar informações de log de formasimplificada, exigindo apenas sua configuração prévia em um arquivo de propriedades, ondeeste pode ser escrito em diversos formatos, dentre estes o Extensible Markup Language(XML). Além disto, o Log4j oferece cinco níveis em sua hierarquia, classificando asmensagens de acordo com a especificação: DEBUG, INFO, WARN, ERROR e FATAL.

A imagem 31 ilustra o arquivo de configuração XML para a criação do log, ondeserá utilizado para armazenar o processo de comunicação entre os agentes. Primeiramentena seção de propriedades foi criado o diretório de registro, definindo um modelo padrãopara exibir o log, como mostrar a data e hora, o nível, a própria mensagem e uma quebrade linha. Após isto, criou-se um arquivo dentro do diretório e atribuiu uma referência. Osappenders são responsáveis por escreverem a mensagem no arquivo, e por identificar onível de log. Por fim, gerou-se uma instância Logger para ser utilizado na aplicação, ondeserá responsável por receber a mensagem e torná-la disponível para o Appender.


Figura 31: Arquivo de configuração XML. Fonte: Autoria Própria

A figura 32 representa o registro feito pelo agente AVM ao enviar uma mensagempara o agente ACR. Contém detalhadamente data e hora do envio, a identificação global eo endereço de ambos os agentes, e por fim os scripts.

Figura 32: Registro do Envio do Script. Fonte: Autoria Própria

5.5 Validação do ScriptEssa seção objetiva esclarecer o processo de validação tomado para testar a funcio-

nalidade dos scripts obtidos como resultado das ações do agente de software implementadoneste trabalho. Inicialmente desenvolveu-se uma arquitetura composta por um roteador, umatacante e um usuário, interligados pela mesma rede. O roteador continha o firewall iptables


para que os scripts pudessem ser inseridos manualmente. As etapas são detalhadamentedefinidas a seguir.

A figura 33 exemplifica uma arquitetura, onde a VM roteador aplicou-se os scriptsde firewall. A VM Atacante considerou-se um cliente na Nuvem mal intencionado, e porfim a VM Usuário que classificou-se como outro cliente qualquer na Nuvem.

Figura 33: Arquitetura para teste. Fonte: Autoria Própria

A figura 33 ilustra uma varredura de portas no host usuário para verificar seusserviços disponíveis, no qual sofrerá acesso não autorizado por terceiros.

Figura 34: Escaneio de Portas no Usuário. Fonte: Autoria Própria

A figura 35 representa o firewall com todas as tabelas com suas respectivas chainscom política padrão ACCEPT, ou seja, todo e qualquer acesso está liberado entre asmáquinas da rede.


Figura 35: Firewall com política ACCEPT. Fonte: Autoria Própria

A figura 36 demonstra um cliente da Nuvem (atacante) pronto para acessar osserviços ssh e telnet disponíveis em outra máquina na rede com o endereço de rede192.168.122.35. O Putty é um software de emulação de terminal que suporta acesso remotopor ssh e telnet.

Figura 36: Acessando os serviços ssh e telnet. Fonte: Autoria Própria

A figura 37 ilustra o cliente (atacante) obtendo acesso aos serviços ssh e telnet nohost com o endereço de rede 192.168.122.35.

Figura 37: Acesso os serviços ssh e telnet. Fonte: Autoria Própria

A figura 38 demonstra a inserção manual dos scripts de bloqueio no firewall iptables,para testar a funcionalidade dos scripts extraídos pelo agente de software AVM deste


Figura 38: Bloqueio do Atacante. Fonte: Autoria Própria

Figura 39: Inibição do Ataque. Fonte: Autoria Própria

trabalho.

A figura 39 representa a inibição do atacante após a inserção do script de bloqueio,e deste modo comprovando sua eficácia.

5.6 Considerações FinaisNeste capítulo foi apresentado o primeiro ambiente de teste, onde foi implementado

o modelo proposto, como também esclareceu-se os processos de implantação e desen-volvimento dos componentes do modelo. Por fim, demonstrou-se a elaboração de outraarquitetura para o teste de validação, focando na verificação da funcionalidade dos scriptsgerados a partir do log do honeypot. O resultado do teste demonstrou que é possívelneutralizar usuários mal intencionados.

66

6 Conclusão

A Computação em Nuvem demonstra-se como um paradigma tecnológico promissor,pois cada vez mais seus serviços vem sendo consumidos e como consequência as ameçassão potencializadas. Deste modo, trabalhos que contribuem para melhorar o quesito dasegurança deste ambiente são de extrema importância. Inúmeras tentativas de implementa-ção de mecanismos de proteção são motivadas pela problemática da insegurança a medidaque aumenta o número de aderentes.

Tendo em vista, que boa parte dos problemas de segurança nestes ambientessão causados por usuários da própria Infraestrutura, o presente trabalho teve comoobjetivo proteger os usuários da Nuvem de ameaças internas. Fundamentado em pesquisasexistentes, foi proposto neste trabalho como contribuição, um mecanismo autônomo paraa geração de scripts de firewall, baseado em agente inteligente, utilizando um honeypotde baixa interatividade para detectar as tentativas de ataques na camada IaaS. Alémdisso, o uso de uma plataforma específica permitiu que fossem aproveitadas habilidadesde comunicação e autonomia inerentes dos agentes. O agente implementado possui acapacidade de trabalhar em conjunto com outro agente de software de um sistema dedetecção de intrusão multiagente para a segurança da Nuvem.

Através do desenvolvimento deste trabalho, foi possível compreender que os honey-pots em conjunto com algumas ferramentas de segurança, podem servir como auxílio nadefesa de redes e sistemas computacionais, pois armazenam informações dos invasores eisso permite que sejam posteriormente estudadas ou extraídas para elaborar táticas desegurança.

A relevância dos honeypots como uma ferramenta adicional torna-se evidente, poiscom sua capacidade de coletar dados em tempo real e a praticidade do agente de extrairscripts em qualquer tempo determinado, a neutralização do atacante torna-se rapidamenteaplicável.

Por fim, a validação prática pode comprovar que os resultados gerados através dodesenvolvimento do modelo proposto são funcionais.

6.1 Trabalhos FuturosDurante o desenvolvimento do projeto, foram observadas algumas necessidades

para que o modelo pudesse ser melhor elaborado, são elas:

• Testar situações em que o modelo torna-se vulnerável para avaliar sua aplicabilidade

Capítulo 6. Conclusão 67

em um ambiente real de Nuvem.

• Desenvolver configurações para que atacantes da rede externa interajam com ohoneypot.

• Tornar os sistemas simulados pelo HoneyD mais atrativos para atacantes.

• Tratar exceções nas ações do agente que possam eventualmente ocorrer.

68

Referências

[1] RAMALHO, N. C. L. Um estudo sobre a adoção da Computação em Nuvem no Brasil.Tese (Doutorado) — Universidade de São Paulo, 2012. Citado na página 12.

[2] SOUSA, F. R.; MOREIRA, L. O.; MACHADO, J. C. Computação em nuvem:Conceitos, tecnologias, aplicações e desafios. II Escola Regional de Computação Ceará,Maranhão e Piauí (ERCEMAPI), p. 150–175, 2009. Citado 6 vezes nas páginas 12, 20,21, 22, 23 e 27.

[3] NIST, N. Definitoon of cloud computing v15. NIST, Editor, 2009. Citado 4 vezes naspáginas 12, 19, 20 e 27.

[4] MORAES, L. F. Segurança e confiabilidade em ids baseados em agente. 2009. Citadona página 12.

[5] WIS, Worldwide Infrastructure Security Report Volume IX. Copyright. Disponívelem: <https://www.arbornetworks.com/images/documents/WISR2016_EN_Web.pdf>.Acesso em: 05 Mar. 2016. Citado 2 vezes nas páginas 12 e 14.

[6] PATEL, A. et al. An intrusion detection and prevention system in cloud computing:A systematic review. Journal of Network and Computer Applications, Elsevier, v. 36, n. 1,p. 25–41, 2013. Citado na página 12.

[7] SPITZNER, L. Honeypots: tracking hackers. [S.l.]: Addison-Wesley Reading, 2003.v. 1. Citado 4 vezes nas páginas 12, 13, 18 e 33.

[8] PROVOS, N. et al. A virtual honeypot framework. In: USENIX Security Symposium.[S.l.: s.n.], 2004. v. 173. Citado na página 12.

[9] TANG, X. The generation of attack signatures based on virtual honeypots. In: IEEE.Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2010International Conference on. [S.l.], 2010. p. 435–439. Citado na página 13.

[10] GRÉGIO, A. R. Modelagem de um sistema distribuído orientado à agentes paracoleta e análise de código malicioso da internet. 2010. Citado 4 vezes nas páginas 13, 43,44 e 45.

[11] CERTBR, centro de estudos respostas e tratamento de incidentes de segurançano Brasil. Estatísticas dos Incidentes Reportados ao CERT.br. Disponível em:<http://www.cert.br/stats/incidentes/>. Acesso em: 05 Mar. 2016. Citado 3 vezes naspáginas 13, 14 e 31.

[12] SANTOS, U.; AMELOTTI LUIZ AUGUSTO; VILLAR, F. White Paper:Adoção de Computação em Nuvem e suas Motivações. Disponível em: <https://www.researchgate.net/publication/275519409_WhitePaper_-_Adocao_De_Computacao_Em_Nuvem_E_Suas_Motivacoes>. Acesso em: 16 Out. 2015. Citado 2vezes nas páginas 14 e 28.

https://www.arbornetworks.com/images/documents/WISR2016_EN_Web.pdf

http://www.cert.br/stats/incidentes/

https://www.researchgate.net/publication/275519409_WhitePaper_-_Adocao_De_Computacao_Em_Nuvem_E_Suas_Motivacoes



Referências 69

[13] JR, A. M. et al. Aspectos de segurança e privacidade em ambientes de computaçaoem nuvem. Livro-texto de minicursos do SBSeg, v. 1, p. 53–102, 2010. Citado 3 vezes naspáginas 14, 19 e 29.

[14] HANSEN, M.; SCHWARTZ, A.; COOPER, A. Privacy and identity management.Security & Privacy, IEEE, v. 6, n. 2, p. 38–45, 2008. Citado na página 14.

[15] KUMARASWAMY, S. et al. Domain 12: Guidance for identity & access managementv2. 1. Cloud Security Alliance (CSA), v. 10, 2010. Citado na página 14.

[16] MOURA, E. H. C. Modelo de Segurança Autonø̂mica para Computação em nuvemcom uso de Honeypot. Dissertação (Mestrado) — Universidade Federal do Maranhão,2013. Citado 14 vezes nas páginas 14, 20, 21, 22, 23, 24, 29, 30, 31, 32, 33, 34, 41 e 44.

[17] MEDEIROS, G. de O. Mitigando Ataques de Negação de Serviço em Infraestruturasde Computação em Nuvem. Dissertação (Mestrado) — Universidade Federal do Maranhão,2014. Citado 8 vezes nas páginas 17, 18, 19, 24, 25, 26, 60 e 61.

[18] SILVA, L. A. M. Estudo e desenvolvimento de sistemas multiagentes usando jade:Java agent development framework. 2003. Citado na página 18.

[19] JR, E. C. B.; MACHADO, J. C.; MONTEIRO, J. M. Estratégias para proteção daprivacidade de dados armazenados na nuvem. Simpósio Brasileiro de Banco de Dados.,v. 6, 2014. Citado na página 19.

[20] BUYYA, R.; BROBERG, J.; GOSCINSKI, A. M. Cloud computing: principles andparadigms. [S.l.]: John Wiley and Sons, 2010. v. 87. Citado na página 19.

[21] PEDROSA, P. H.; NOGUEIRA, T. Computação em Nuvem. Disponível em: <http://www.ic.unicamp.br/~ducatte/mo401/1s2011/T2/Artigos/G04-095352-120531-t2.pdf>.Acesso em: 4 Set. 2015. Citado 7 vezes nas páginas 20, 21, 22, 23, 27, 28 e 29.

[22] CHIRIGATI, F. S. Computação em nuvem. Universidade Federal do Rio de Janeiro,p. 34, 2009. Citado 4 vezes nas páginas 20, 21, 28 e 29.

[23] TUJAL, L. C. P. Modelo de referência de cloud. 2010. Citado na página 21.

[24] BORGES, H. P. et al. Computação em Nuvem. 2011. Disponível em:<http://livroaberto.ibict.br/handle/1/861>. Acesso em: 25 Out. 2015. Citado na página21.

[25] MARTINS, A. Fundamentos de computação em nuvem para governos. Amãpytuna:Computação em Nuvem: Serviços Livres para a Sociedade do Conhecimento, 2010. Citadona página 22.

[26] VIGGIANI, T.; VELLASCO, W. Aspectos contratuais na contratação de serviços decomputação em nuvem. 2014. Citado 2 vezes nas páginas 22 e 23.

[27] PAIXãO, C. A. Gerenciamento de recursos computacionais em plataformas deComputação em Nuvem. Dissertação (Mestrado) — Universidade de São Paulo, 2014.Citado 2 vezes nas páginas 24 e 25.

http://www.ic.unicamp.br/~ducatte/mo401/1s2011/T2/Artigos/G04-095352-120531-t2.pdf

http://www.ic.unicamp.br/~ducatte/mo401/1s2011/T2/Artigos/G04-095352-120531-t2.pdf

http://livroaberto.ibict.br/handle/1/861

Referências 70

[28] MACêDO, M. A.; QUEIROZ, R. J. de; DAMASCENO, J. C. Uma ferramentaadaptativa baseada em agentes móveis inteligentes para segurança de aplicações web. VIISimpósio Brasileiro de Sistemas de Informação, p. 105–116, 2011. Citado 3 vezes naspáginas 24, 44 e 45.

[29] ROCHA, L. A. Introdução a computação em nuvem. 2013. Citado na página 24.

[30] GROSMANN, D. et al. Estudo comparativo sobre o uso do vmware e xen server navirtualização de servidores. Instituto Federal do Piauí, 2011. Citado 2 vezes nas páginas25 e 26.

[31] CARISSIMI, A. Virtualização: da teoria a soluções. Minicursos do SimpósioBrasileiro de Redes de Computadores–SBRC, v. 2008, p. 173–207, 2008. Citado 2 vezesnas páginas 26 e 27.

[32] ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM,ACM, v. 53, n. 4, p. 50–58, 2010. Citado na página 27.

[33] LEANDRO, M. A. P. Federação de identidades e computação em nuvem: estudo decaso usando Shibboleth. Dissertação (Mestrado), 2012. Citado na página 28.

[34] CHAVES, S. A questão dos riscos em ambientes de computação em nuvem. Tese(Doutorado) — Universidade de São Paulo, 2011. Citado 2 vezes nas páginas 28 e 29.

[35] MARKS, E. A.; LOZANO, B. Executives guide to cloud computing. [S.l.]: JohnWiley and Sons, 2010. Citado na página 29.

[36] MILLER, M. Cloud Computing: Web Based Applications That Change the Way YouWork and Collaborate Online. [S.l.: s.n.], 2008. v. 11. Citado na página 29.

[37] BARROS, R. D. Segurança em computação na nuvem. 2014. Citado na página 29.

[38] FERNANDES, F. H. Riscos de segurança em cloud computing. 2013. Citado napágina 30.

[39] RAMGOVIND, S.; ELOFF, M. M.; SMITH, E. The management of security incloud computing. In: IEEE. Information Security for South Africa (ISSA), 2010. [S.l.],2010. p. 1–7. Citado na página 30.

[40] VERíSSIMO, P.; RODRIGUES, L. Fundamental security concepts. [S.l.]: Springer,2001. 377–393 p. Citado na página 30.

[41] SANTOS, W. H. Métodos de detecção de ataques ddos compostos baseados emfiltragem sequencial. XII Simpósio Brasileiro em Segurança da Informação e de SistemasComputacionais, 2012. Citado na página 30.

[42] SAKAMOTO, F. T. Desenvolvimento de uma ferramenta de auxilio a analise de logsgerados por honeypot com estudo de caso de uma rede sem fio padrao ieee 802.11. 2006.Citado 2 vezes nas páginas 31 e 35.

[43] BARBOSA, Á. N. Um sistema para análise ativa de comportamento de firewall.Tese (Doutorado) — Universidade de São Paulo, 2006. Citado na página 31.

[44] LINCK, G.; KREUTZ, D. Anomalias de rede e recursos de proteção contra ataques.HÍFEN, v. 30, n. 58, 2006. Citado na página 31.

Referências 71

[45] JABOUR, E.; DUARTE, O. C. Honeynets: Invasores, Ferramentas, Técnicas eTáticas. Disponível em: <http://www.gta.ufrj.br/seminarios/CPE825/tutoriais/eugenia/honeynets.PDF>. Acesso em: 05 Dez. 2015. Citado na página 31.

[46] HIJAZI, M. E. R. HONEYPOTS E ASPECTOS LEGAIS. Dissertação (Mestrado) —Pontifícia Universidade Católica do Paraná, 2004. Citado na página 31.

[47] OLIVEIRA, F. S. d. Honeypot: um ambiente para análise de intrusão. 2015. Citado2 vezes nas páginas 31 e 32.

[48] PROVOS, N. et al. A Virtual Honeypot Framework. [S.l.: s.n.], 2004. v. 173. Citadona página 32.

[49] SUZUKI, L. H.; DELPHINO, A. D. Implantação de um honeypot e proposta parametodologia de gerenciamento de projetos de honeynets. CEP, v. 70910, p. 900, 2007.Citado na página 32.

[50] HOEPERS, C. Projeto e Implementação De uma Infraestrutura para troca e AnaliseDe Informações de Honeypots E Honeynets. [S.l.]: INPE-Instituto Nacional de PesquisasEspaciais. Sao Paulo: INPE, 2008. Citado na página 33.

[51] STEDING, J. K. Uso de Honeypots para o Estudo de Spam e Phishing. Tese(Doutorado) — Tese de doutorado. INPE. 2008. URL: http://u rlib. net/sid. inpe.br/mtcm18@ 80/2008/08.18. 19.02. Acessado em: 12/06, 2013. Citado na página 33.

[52] LOPES, A. Honeypot e Honeynet: as vantagens de conhecer oinimigo. Disponível em: <http://www.profissionaisti.com.br/2013/11/honeypot-e-honeynetasvantagens-de-conhecer-o-inimigo>. Acesso em: 05 Mar.2016. Citado na página 33.

[53] ANDRUCIOLI, A. P. Proposta e Avaliação de Um Modelo Alternativo Baseado emHoneynet para Identificação de Ataques e Classificação de Atacantes na Internet. Tese(Doutorado) — Universidade Federal do Rio de Janeiro, 2005. Citado 2 vezes nas páginas33 e 34.

[54] ASSUNÇÃO, M. F. A. Honeypots e honeynets: aprenda a detectar e enganar osinvasores.-. [S.l.]: Visual Books, 2009. Citado na página 33.

[55] BATISTELA, V.; TRENTIN, M. A. Identificação e análise de tráfego maliciosoatravés do uso de honeypots. Revista Brasileira de Computação Aplicada, v. 1, p. 2–14,2009. Citado 2 vezes nas páginas 34 e 35.

[56] ADDISON, W. Conheça o seu inimigo: The Honeynet Project. [S.l.]: SãoPaulo:[Makron Books], 2002. Citado na página 35.

[57] DAMIãO, M. A.; CAçADOR, R. M. C.; LIMA, S. M. B. PrincÍpios e aspectos sobreagentes inteligentes. 2014. Citado 2 vezes nas páginas 35 e 38.

[58] FERNANDES, A. M. d. R. et al. Uma experiência com agentes inteligentes e jogosde cartas. Citado na página 36.

[59] SILVA, M. L. C.; LUÍS, S. Modelo de IDS Remoto baseado na tecnologia de Agentes,Web Services e MDA. Dissertação (Mestrado) — Universidade Federal do Maranhão, 2006.Citado na página 36.

http://www.gta.ufrj.br/seminarios/CPE825/tutoriais/eugenia/honeynets.PDF

http://www.gta.ufrj.br/seminarios/CPE825/tutoriais/eugenia/honeynets.PDF

http://www.profissionaisti.com.br/2013/11/honeypot-e-honeynetasvantagens-de-conhecer-o-inimigo

http://www.profissionaisti.com.br/2013/11/honeypot-e-honeynetasvantagens-de-conhecer-o-inimigo

Referências 72

[60] BRADSHAW, J. M. Software agents. [S.l.]: MIT press, 1997. Citado na página 36.

[61] SIQUEIRA, L. G. Tolerância a Falhas para o NIDIA: um Sistema de Detecção deIntrusão Baseado em Agentes Inteligentes. Dissertação (Mestrado) — Master’s thesis,Universidade Federal do Maranhão, 2006. 9, 14, 2006. Citado na página 36.

[62] DAVIDSSON, P. Concept acquisition by autonomous agents: Cognitive modelingversus the engineering approach. [S.l.]: Lund University, 1992. Citado na página 37.

[63] RUSSEL, S.; NORVIG, P. Inteligência artificial. Editora Campus, p. 26, 2004.Citado na página 38.

[64] HEGAZY, I. M. et al. A multi-agent based system for intrusion detection. IEEEPotentials, v. 22, n. 4, p. 28–31, 2003. Citado na página 38.

[65] BRENNER, W.; ZARNEKOW, R.; WITTIG, H. Intelligent software agents:foundations and applications. [S.l.]: Springer Science & Business Media, 2012. Citado napágina 39.

[66] FININ, T. et al. Kqml as an agent communication language. In: ACM. Proceedingsof the third international conference on Information and knowledge management. [S.l.],1994. p. 456–463. Citado na página 39.

[67] FIPA00061, F. Acl message structure specification. Foundation for IntelligentPhysical Agents, 2000. Citado 2 vezes nas páginas 39 e 58.

[68] JACOB, B. Automatic xss detection and snort signatures/acls generation by themeans of a cloud-based honeypot system. 2011. Citado 3 vezes nas páginas 41, 44 e 48.

[69] BALAMURUGAN, M.; POORNIMA, B. Honeypot as a service in cloud. In: IJCAProceedings on International Conference on Web Services Computing (ICWSC), ICWSC(1). [S.l.: s.n.], 2011. p. 39–43. Citado 2 vezes nas páginas 42 e 44.

[70] BIEDERMANN, S.; MINK, M.; KATZENBEISSER, S. Fast dynamic extractedhoneypots in cloud computing. In: ACM. Proceedings of the 2012 ACM Workshop onCloud computing security workshop. [S.l.], 2012. p. 13–18. Citado 2 vezes nas páginas 42e 44.

proposta de um sistema de segurança autônomo utilizando ... · proposta de um sistema de...

Documents