protótipo de um sistema de detecção de intrusão para contexto … · 2018-03-01 · duandys f....

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

Protótipo de um Sistema de Detecção de Intrusão para Contexto deNuvens Computacionais

Duandys F. de Sousa

MARABÁ2016

Duandys F. de Sousa

Protótipo de um Sistema de Detecção de Intrusão para Contexto deNuvens Computacionais

Trabalho de Conclusão de Curso apresentadocomo requisito parcial para obtenção do graude bacharelado em Sistemas de Informaçãona Faculdade de Computação e EngenhariaElétrica da Universidade Federal do Sul eSudeste do Pará.

Orientador:Prof. MSc. Gleison de O. Medeiros

Coorientador:Prof. MSc. João V. C. Carmona

MARABÁ2016

Dados Internacionais de Catalogação-na-Publicação (CIP) Biblioteca Josineide da Silva Tavares da UNIFESSPA. Marabá,PA

Sousa, Duandys F. de

Protótipo de um sistema de detecção de intrusão para contexto de nuvens computacionais / Duandys F. de Sousa ; orientador, Gleison de O. Medeiros, coorientador, João V. C. Carmona. — 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. Arquitetura de rede de computador. I. Medeiros, Gleison de O., orient. II. Carmona, João V. C., coorient. III. Universidade Federal do Sul e Sudeste do Pará. IV. Título.

CDD: 22. ed.: 005.8

Dedico este trabalho a minha família.

Agradecimentos

Primeiramente agradeço a Deus por minha vida, sem ele os demais agradecimentosnão seriam possíveis.

Agradeço a minha mãe Maria do Socorro e ao meu pai Daniel Rodrigues portodos os ensinamentos repassados, pelo apoio incondicional e incentivo que sempre mepropuseram. Sem eles, seria impossível a realização deste trabalho.

Agradeço aos meus irmãos e irmã que sob diferentes perspectivas a mim colaborarampara a conclusão do trabalho.

Aos amigos por longas horas de conversações sobre a magnifica área da computação,que de forma direta e indireta contribuíram para este trabalho.

Ao prof. MSc. Glesion de Oliveira Medeiros, por contribuir com sua orientaçãoacadêmica, compartilhando parte de seu conhecimento e experiencia, por sempre incentivare acreditar em mim.

Regracio o Prof. MSc. João V. C. Carmona pelo incentivo, suporte, conselhos eensinamentos a mim doutrinado.

Gratifico a todos os colegas de turma, por terem trilhado este caminho juntamentecomigo durante a o curso de graduação e todas as pessoas que contribuíram de forma ame permitir chegar a este ponto em minha vida.

Muito obrigado a todos!

“Se você não existisse, que falta faria?”(Mário Sergio Cortella)

ResumoA computação em nuvem oferece a possibilidade de acessar arquivos e realizar diferentestarefas por meio da internet. Esta abordagem extrai a atividade de instalação e manutençãode serviços do usuário final e atribui a empresas especializadas denominadas provedorasde nuvem, que além destes fatores devem preocupar-se fundamentalmente com aspectosrelacionados a privacidade e segurança dos dados. Hoje em dia, sistemas disponibilizadosvia internet estão expostos a diversas categorias de ataques e formas possíveis de intrusão,dentre estas apresentam-se os ataques de negação de serviço, que resume-se em esgotarrecursos computacionais do seu alvo, de forma a deixá-lo lento ou até mesmo indisponível.Nessas circunstâncias a proposta deste trabalho é apresentar uma arquitetura de sistemade detecção de intrusão, apoiando-se em tecnologias de sistemas multiagentes para aidentificação de ataques que buscam comprometer a disponibilidade de serviços ofertados,definindo sua aplicação na camada de infraestrutura da nuvem.

Palavras-chave: Computação em Nuvem, Segurança da Informação, Sistemas de Detecçãode Intrusão.

Lista de ilustrações

Figura 1 – Riscos da computação em nuvem . . . . . . . . . . . . . . . . . . . . . 18Figura 2 – Incidentes reportados ao CERT.br de jan. a dez. de 2015 . . . . . . . . 19Figura 3 – Comparação entre data centers . . . . . . . . . . . . . . . . . . . . . . 31Figura 4 – Arquitetura hipervisor modelo 01 . . . . . . . . . . . . . . . . . . . . . 32Figura 5 – Arquitetura hipervisor modelo 02 . . . . . . . . . . . . . . . . . . . . . 33Figura 6 – Benefícios da computação em nuvem . . . . . . . . . . . . . . . . . . . 34Figura 7 – Criptografia simétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 8 – Criptografia assimétrica . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 9 – Arquitetura EICIDS com nó único . . . . . . . . . . . . . . . . . . . . 57Figura 10 – Arquitetura EICIDS com múltiplos nós . . . . . . . . . . . . . . . . . . 58Figura 11 – Arquitetura geral SDIMIN . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 12 – Arquitetura geral GCCIDS . . . . . . . . . . . . . . . . . . . . . . . . 60Figura 13 – Arquitetura geral MAIDPS . . . . . . . . . . . . . . . . . . . . . . . . 62Figura 14 – Arquitetura geral NICE . . . . . . . . . . . . . . . . . . . . . . . . . . 64Figura 15 – Hierarquia de agentes e natureza de atividades por camada . . . . . . . 66Figura 16 – Arquitetura dos componentes . . . . . . . . . . . . . . . . . . . . . . . 68Figura 17 – Esquema de elasticidade . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figura 18 – Tolerância na camada estática . . . . . . . . . . . . . . . . . . . . . . . 71Figura 19 – Tolerância na camada dinâmica . . . . . . . . . . . . . . . . . . . . . . 72Figura 20 – Acordo de chaves simétricas . . . . . . . . . . . . . . . . . . . . . . . . 72Figura 21 – Troca de chaves públicas . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figura 22 – Casos de uso administrador . . . . . . . . . . . . . . . . . . . . . . . . 75Figura 23 – Casos de uso agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figura 24 – Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figura 25 – Trecho de código da classe ControllerNodeAgent . . . . . . . . . . . . . 80Figura 26 – Trecho de código da classe SnifferNodeAgent . . . . . . . . . . . . . . . 81Figura 27 – Trecho de código da classe AnalyzerVMAgent . . . . . . . . . . . . . . 81Figura 28 – Trecho de código da classe FilterVMAgent . . . . . . . . . . . . . . . . 82Figura 29 – Trecho de código da classe SnifferNodeAgent 2 . . . . . . . . . . . . . . 83Figura 30 – Interação entre agentes no esquema de elasticidade. . . . . . . . . . . . 83Figura 31 – Trecho de código da classe ControllerNodeAgent 2 . . . . . . . . . . . . 84Figura 32 – Trecho de código da classe SecurityService . . . . . . . . . . . . . . . . 85Figura 33 – Ambiente de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figura 34 – Consumo de recursos inicial do servidor HTTP . . . . . . . . . . . . . 88Figura 35 – Interface de execução de comandos dos hosts atacantes. . . . . . . . . . 88Figura 36 – Consumo de recursos durante SYN Flood no servidor HTTP. . . . . . . 89

Figura 37 – Interação entre agentes na identificação do ataque. . . . . . . . . . . . 89Figura 38 – Consumo de recursos após a interrupção do SYN Flood. . . . . . . . . 90Figura 39 – Consumo de recursos inicial do servidor HTTP 2 . . . . . . . . . . . . 91Figura 40 – Interface de execução de comandos dos hosts atacantes 2. . . . . . . . . 91Figura 41 – Consumo de recursos durante UDP Flood. . . . . . . . . . . . . . . . . 92Figura 42 – Log das interações entre componentes. . . . . . . . . . . . . . . . . . . 92Figura 43 – Consumo de recursos após a interrupção do UDP Flood. . . . . . . . . 92Figura 44 – Gráfico de resultados da situação normal . . . . . . . . . . . . . . . . . 94Figura 45 – Gráfico de resultados da situação DoS . . . . . . . . . . . . . . . . . . 94Figura 46 – Gráfico de resultados da situação DoS com IDS . . . . . . . . . . . . . 95

Lista de tabelas

Tabela 1 – Ferramentas selecionadas para etapa de modelagem e implementação . 23Tabela 2 – Ferramentas selecionadas para etapa de testes . . . . . . . . . . . . . . 25Tabela 3 – Principais características dos trabalhos relacionados . . . . . . . . . . . 65Tabela 4 – Descrição dos participantes do ambiente de teste . . . . . . . . . . . . 87Tabela 5 – Parâmetros do plano de teste JMeter . . . . . . . . . . . . . . . . . . . 93

Lista de abreviaturas e siglas

AC Autoridade Certificadora

ACL Agent Communications Language

CSA Cloud Security Alliance

DDoS Distributed Denial of Service

DIDS Distributed Intrusion Detection System

DoS Denial of Service

FIPA Foundation for Intelligent Physical Agents

HIDS Host-based Intrusion Detection

IaaS Infrastructure as a Service

ICMP Internet Control Message Protocol

ICP Infraestrutura de Chave Pública

IDE Integrated Development Environment

IDS Intrusion Detection System

IP Internet Protocol

JADE Java Agent DEvelopment

KVM Kernel-based Virtual Machine

NIDS Network-based Intrusion Detection

NIST National Institute of Standards and Technology

PaaS Platform as a Service

PING Packet Internet Grouper

PKI Public Key Infrastructure

POO Programação Orientada a Objetos

SaaS Software as a Service

SDI Sistemas de Deteção de Intrusão

SMA System Multi-Agent

SO Sistema Operacional

TCP Transmission Control Protocol

TI Tecnologia da Informação

UDP User Datagram Protocol

UML Unified Modeling Language

VM Virtual Machine

VMM Virtual Machine Monitor

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.1 Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.2.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.2 Características Fundamentais . . . . . . . . . . . . . . . . . . . . . 272.1.3 Serviços em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.4 Modelos de Implantação . . . . . . . . . . . . . . . . . . . . . . . . 282.1.5 Data Center em Infraestrutura Nuvens . . . . . . . . . . . . . . . . 292.1.6 Virtualização de Recursos Computacionais . . . . . . . . . . . . . . 312.1.7 Benefícios da Computação em Nuvem . . . . . . . . . . . . . . . . . 332.1.8 Riscos da Computação em Nuvem . . . . . . . . . . . . . . . . . . . 35

2.2 Segurança e da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.2 Segurança em Redes de Computadores . . . . . . . . . . . . . . . . 36

2.2.2.1 Criptografia simétrica . . . . . . . . . . . . . . . . . . . . 382.2.2.2 Criptografia assimétrica . . . . . . . . . . . . . . . . . . . 382.2.2.3 Assinaturas digitais . . . . . . . . . . . . . . . . . . . . . . 392.2.2.4 Certificados digitais . . . . . . . . . . . . . . . . . . . . . 40

2.2.3 Ataques a Redes de Computadores . . . . . . . . . . . . . . . . . . 412.2.4 Ameaças as Nuvens . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.4.1 Vazamento de dados . . . . . . . . . . . . . . . . . . . . . 432.2.4.2 Perda de dados . . . . . . . . . . . . . . . . . . . . . . . . 442.2.4.3 Sequestro de contas/tráfego de serviços . . . . . . . . . . . 442.2.4.4 Interfaces inseguras . . . . . . . . . . . . . . . . . . . . . . 452.2.4.5 Negação de serviços . . . . . . . . . . . . . . . . . . . . . 452.2.4.6 Usuário mal intencionado . . . . . . . . . . . . . . . . . . 462.2.4.7 Abuso dos serviços da nuvem . . . . . . . . . . . . . . . . 462.2.4.8 Investigação insuficiente . . . . . . . . . . . . . . . . . . . 472.2.4.9 Vulnerabilidades de recursos compartilhados . . . . . . . . 47

2.3 Sistemas de Detecção de Intrusão . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.1 Métodos de Coleta . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.1.1 Host-based Intrusion Detection (HIDS) . . . . . . . . . . . 482.3.1.2 Network-based Intrusion Detection (NIDS) . . . . . . . . . 492.3.1.3 Distributed Intrusion Detection System (DIDS) . . . . . . 502.3.1.4 Híbridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.3.2 Estratégias de Análises . . . . . . . . . . . . . . . . . . . . . . . . . 512.3.2.1 Baseado em Assinaturas . . . . . . . . . . . . . . . . . . . 512.3.2.2 Baseado em Comportamentos . . . . . . . . . . . . . . . . 51

2.3.3 Técnicas de Análises . . . . . . . . . . . . . . . . . . . . . . . . . . 522.3.3.1 Utilizando Dados Estatísticos . . . . . . . . . . . . . . . . 522.3.3.2 Utilizando Conhecimento . . . . . . . . . . . . . . . . . . 522.3.3.3 Utilizando Aprendizagem de Máquina . . . . . . . . . . . 53

2.3.4 Quanto a Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . 532.3.4.1 Centralizada . . . . . . . . . . . . . . . . . . . . . . . . . 532.3.4.2 Descentralizada . . . . . . . . . . . . . . . . . . . . . . . . 53

2.4 Tolerância a Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 Trabalhos Correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1 EICIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2 SDIMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3 GCCIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4 MAIDPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.5 NICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.6 Análise Comparativa dos Trabalhos Relacionados . . . . . . . . . . . . . . 64

4 Modelo Proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.1 Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2 Arquitetura dos Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 Elasticidade do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4 Esquema de Tolerância a Falhas . . . . . . . . . . . . . . . . . . . . . . . . 70

4.4.1 Agentes Estáticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4.2 Agentes Dinâmicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.5 Modelo de Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 Modelagem e Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.2 Implementação dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 Mecanismo de Elasticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.4 Mecanismo de Tolerância . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.5 Validação das Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.1 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.2 Teste 01 - TCP SYN Flood . . . . . . . . . . . . . . . . . . . . . . . . . . 876.3 Teste 02 - UDP Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.4 Teste 03 - Viabilidade da Ferramenta . . . . . . . . . . . . . . . . . . . . . 92

7 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.1 Contribuição do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.2 Pesquisas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

16

1 Introdução

Com o decorrer do anos foi possível observar a evolução gradativa de componentese sistemas de computadores, inicialmente capazes apenas de exercer um comportamentomonolítico na execução de processos, e que já atualmente permitem que tarefas sejamexecutadas até mesmo de forma distribuída em diversos dispositivos, com o auxilio dasredes de computadores. A evolução destes componentes agregaram consigo novos desafios,dentre estes destacamos os atrelados a segurança dos dados e das informações, consideradopor muitos pesquisadores os aspecto de maior complexidade de mediação [1].

A computação em nuvem é um modelo computacional recente que tem ganhadoforça nas últimas duas décadas. Consiste em gerenciar um conjunto de recursos, podendo sertanto hardwares como softwares, e disponibilizá-los de forma dinâmica e escalável, variandoo provisionamento destes aos usuários em função da demanda apresentada [2]. Possuiuma arquitetura distribuída, ou seja, permite conciliar recursos de diversos dispositivos,necessitando apenas que estes estejam interconectados entre si.

Devido a computação em nuvem combinar diversas tecnologias distintas, as vulne-rabilidades encontradas em cada uma destas isoladamente também são empregadas quandoassociadas, e mesmo se tratando de ataques com padrões comumente explorados, técnicasde prevenções tradicionais não são suficientes quando aplicadas neste tipo de arquitetura,sendo necessário efetuar modificações afim de adaptá-las as estes contextos. Mediante istoSistemas de Detecção de Intrusão (SDI), ou do inglês como é mais conhecido, IntrusionDetection System (IDS) recebem destaque quando comparadas com outras tecnologias,principalmente em virtude da flexilidade de adaptação [3]. Estes tipos de sistemas atuamcoletando conjuntos de informações, sejam de host, da rede, de processos, etc., e após umaclassificação detém a capacidade de inferir se um comportamento deve ser classificadocomo malicioso ou não. A arquitetura de nuvem possuem três camadas, porém os modelosde IDS atuam principalmente na camada de mais baixo nível, denominada Infrastructureas a Service (IaaS), pois desta posição é possível capturar dados das demais camadasexistentes.

Dentre os diferentes tipos de ameaças existentes atualmente, este trabalho serádirecionado aos que têm por finalidade tornar um sistema indisponível. Ataques de negaçãode serviço ou Denial of Service (DoS), e ataques distribuídos de negação de serviço ouDistributed Denial of Service (DDoS), buscam comprometer serviços disponibilizados,atrapalhar o acesso de usuários a recursos, ou comprometer a integridade das informações,diferenciando-se apenas na quantidade de participantes do ataque, enquanto no DoSapenas um único host participa do ataque, no DDoS existem diversos participantes.

Capítulo 1. Introdução 17

O objetivo principal é não permitir ou atrapalhar o acesso de usuários legítimos aosrecursos que foram previamente contratados, realizando isto através do esgotamento dosrecursos computacionais (processador, rede, memória, etc.) mediante um grande númerode solicitações falsas [3, 4].

A segurança dos dados e informações é uma preocupação constante principalmenteem sistemas distribuídos. Existe a necessidade de inserir mecanismos de proteção quepossam prevenir ou minimizar os impactos de vulnerabilidades. Moraes [1] relata que os IDSnão foram projetados inicialmente para serem utilizados em ambientes distribuídos, porémao combiná-los com técnicas de sistemas baseados em multiagentes, apresentam-se comouma eficaz solução, permitindo assim aplicá-los a estes contextos. Sistemas multiagenteou System Multi-Agent (SMA) são um exemplo de aplicações distribuídas, que possuemum conjunto de processos autônomos (agentes) que cooperam entre si para a solução deproblemas complexos, na qual suas capacidades individuais não são suficientes [5].

1.1 JustificativaAo optar por utilizar serviços de nuvem, dados e informações pessoais deverão ser

entregues ao provedor contratado, podendo levar a acreditar que estes estejam armazenadosde forma vulnerável, uma vez que diversos usuários compartilham os mesmo recursosde forma simultânea. Os provedores de nuvem por sua vez, garantem essa segurança ea privacidade necessária, pois afirmam que compartilhamento dos recursos é realizadode forma isolada, ou seja, as ações de um usuário não reflita de forma alguma a outrosusuários, menos ainda na integridade e privacidade das informações que não estejam aeste autorizadas [6].

Segundo Carroll, Merwe e Kotze [7] após realizarem uma revisão na literatura,constataram quais aspectos são considerados como os principais riscos atrelados aos serviçosde nuvem, tendo como base o volume de ocorrências identificadas, onde segurança aparececomo principal fator, conforme podemos observar na Figura 1.

Dentre os tipos de comportamentos que buscam afetar a segurança em uma nuvemcomputacional, destacamos os ataques de negação de serviço que põem em alerta diversosserviços oferecidos através da internet. O tráfego malicioso proveniente destes tipos deconduta vem aumentando gradativamente com decorrer dos anos, em 2006 um ataque comuma banda de 10Gb/s de tráfego foi detectado, já em 2010 foram constatado ataques deaté 100Gb/s, e em 2014 atingiu-se a faixa de 400Gb/s [8]. Esses ataques buscam afetar adisponibilidade de serviços através da inundação de pacotes mesmo estando mais frequentecontinuam sendo difícil evitá-los.

Servidores espalhados por todo planeta que dispõem seus recursos através dainternet sofrem com diversos tipos de ataques constantemente. Um relatório apresentando


Figura 1 – Riscos da computação em nuvem. Fonte: Adaptado de [7]

recentemente (12/2015), apresenta dados do segundo trimestre de 2015. A Akamai 1 [9]relata que 81% dos ataques registrados tinham como alvo serviços localizados nos EstadosUnidos, seguido por Brasil com 7%, a Republica da China aparece com 4%, a Espanha2%, e os países Suécia, Canadá, Austrália, Reino Unido, Índia e Alemanha com 1% cada.Neste mesmo relatório, dados do terceiro trimestre de 2015 mostram que ataques DDoScresceram 23% em relação ao trimestre anterior. Quando comparado com o mesmo períodode 2014 o aumento foi de 180%.

Segundo o [10] em 2015 foram reportados um total de 722205 incidentes relacionadasa segurança da informação no Brasil, englobando diversos tipos de ataques, tais como osnegação de serviço e os específicos para serviços fornecidos através da internet, resultandoem uma média superior a 60 mil para cada mês do ano, conforme podemos perceber naFigura 2.

Profissionais de segurança da informação acreditam que sistemas que se baseiam emarquiteturas de nuvens são mais vulneráveis a ataques DDoS e DoS, pois como o hardwareé compartilhado com diversos usuários, tornam esses tipos de ataques mais prejudiciais,ou seja, usuários autenticados, porém mal intencionados, podem direcionar suas aplicaçõespara consumo de mais recursos físicos do que sistemas de outros usuários, ocasionado aindisponibilidade total do sistema [11,12].

IDS tem ganhado cada vez mais espaço entre os administradores de redes, poispossuem a capacidade de identificar ações que tenham objetivo de prejudicar serviços1 Empresa fornecedora de soluções de aceleração e segurança para a internet. Mais informações acesse:

https://www.akamai.com/


Figura 2 – Incidentes reportados ao CERT.br em 2015. Fonte: [10]

ou hosts. Devido à natureza distribuída dos ambientes de computação em nuvem, oIDS precisa ser adaptado para monitorar vários nós físicos e virtuais, e ainda para umfuncionamento mais seguro deve garantir a segurança interna dos componentes auxilaresque atuam no processo de detecção [13]. Para uma proteção eficiente aos usuários danuvem, o IDS também deve ter flexibilidade, para respeitar as modificações que ocorramdevida a demanda dos usuários, ativando e desativando sensores e analisadores de formaescalável e autônoma.

Uma alternativa comumente utilizada para resolver o problema de escalabilidadeem IDS se dá através da combinação com SMA em sua infraestrutura, estes permitem aflexibilidade necessária em ambientes distribuídos, porém não necessariamente implicamque são sistemas verdadeiramente seguros, existindo então a necessidade de garantir asegurança das informações compartilhadas entre os agentes participantes [1].

De acordo com [14], a utilização de IDS em conjunto com SMA é atualmente omodelo mais adequado para alcançar os objetivos de segurança em ambientes distribuídosque são inseguros, incertos e dinâmico, pois possuem autonomia e capacidade de dinamismoem tempo de execução, características essa fundamental em ambientes de nuvem.

Diversos modelos de IDS podem ser encontrados em meio a comunidade acadêmica,no entanto a maioria destes trabalhos deixam de apresentar pelo menos um dos aspectostido como fundamentais para aplicações em ambientes de nuvens computacionais. Um fatorque chama atenção em relação aos modelos analisados, se da ao fato de nenhum prover


qualquer mecanismo que permitam tolerância a falhas em nível de softwares, ou seja, casoo IDS apresente alguma falha a segurança estará comprometida até sua reconfiguração.

1.2 ObjetivosA seguir são descritos o objetivo geral e os específicos que se busca atingir com

esta trabalho.

1.2.1 Geral

Este trabalho objetiva-se a expor uma proposta de arquitetura de IDS baseadoem SMA embarcado com um mecanismo detecção de erro em componentes interno aomodelo, com o intuito de utilizá-lo em contextos de nuvens computacionais, definindo seuposicionamento na camada de infraestrutura, buscando não permitir que a disponibilidadede serviços e recursos ofertados sejam comprometidos em função de ataques DoS e DDoS.

1.2.2 Específicos

A lista abaixo descreve os objetivos específicos que servem como delimitadores doescopo deste projeto e contribuem para o alcance do objetivo geral pretendido.

• Prototipar uma arquitetura de detecção de intrusos baseada em sistemas multiagentes,que atue na camada de mais baixo nível da nuvem, de forma que se adapte ao numerode maquinas virtuais em execução de forma dinâmica;

• Utilizar mecanismos que busquem permitir ao sistema a capacidade de continuar emexecução mediante eventuais falhas;

• Aplicar métodos de segurança para aumentar a confiabilidade e integridade dasinformações compartilhadas entre os componentes do sistema;

• Desenvolver testes para exposição e avaliação da capacidade e desempenho daarquitetura proposta.

1.3 MetodologiaPara realização desta obra as atividades foram dividias em 6 etapas principais. A

lista abaixo apresenta características de cada uma:

1. Seleção da Área de Conhecimento:Atualmente vivemos em uma era denominada "Era da Informação" [15], podemosdeduzir através desta afirmação que as informações possuem um valor fundamental


na sociedade contemporânea, tanto as relacionadas a pessoas, empresas, governos, etc.Este valor acaba por atrair pessoas mal intencionadas que agem de forma maliciosa,buscando de alguma forma obter acesso, afetar a integridade ou até mesmo nãopermitir que o proprietário tenha acesso a tais informações. Para evitar ou mediarincidentes deste gênero, soluções de segurança precisam ser constantemente criadas eatualizadas, a fim de garantir a confiabilidade de serviços aos usuários finais. O usoda computação em nuvem encontra se em expansão, gradativamente sendo adotadaspor pessoas e organizações, no entanto, questões de segurança e privacidade sãoos principais fatores que atuam em contra partida, diminuindo a velocidade deadesão deste serviço [7, 16]. Mediante estes aspectos, observou-se uma oportunidadede pesquisa, tendo como área de conhecimento a segurança da informação emcontexto de nuvens computacionais classificando está como a primeira etaparealizada;

2. Inspeção Bibliográfica:A segunda etapa realizada tinha como objetivo alcançar informações necessáriassobre o contexto atual relacionado a área de conhecimento da pesquisa. Um conjuntode teses, dissertações, artigos científicos, livros e documentos de hipermídia (estesencontram-se escritos em língua inglesa ou em língua portuguesa) foram selecionadospreviamente. Os documentos classificados como relevantes para este trabalho foramanalisados, servindo como base científica;

3. Definição do Problema:Posterior a inspeção bibliográfica a terceira etapa foi iniciada. Observou-se que dentreos mecanismos mais utilizados como alternativa de segurança para computação emnuvens, os IDS recebiam destaque, sendo apontada por alguns autores como amais viável para estes tipos de ambiente. Porém percebeu-se que diversos modelospropostos não possuíam a flexilidade e escalabilidade para acompanhar as variaçõesfrequentes dos contextos de nuvens. Outros aspectos que ficaram evidentementedeixados de lado por parte dos modelos analisados, são os relacionados a falta demecanismos de segurança envolvendo os componentes participantes do próprio IDS,juntamente como a incapacidade de tolerarem quaisquer tipos de falhas a nível desoftwares;

4. Solução Proposta:A quarta etapa consistiu na elaboração de uma arquitetura que pudesse ser apre-sentada como um solução aceitável aos problemas identificados na etapa anterior,sendo exposta através do desenvolvimento de um protótipo de IDS tolerante a falhas,baseado em SMA, na qual os agentes pertencentes ao sistema possam ser validadose autorizados a realizarem ações, e aplicá-lo na camada de infra estrutura da nuvem,


buscando detectar ataques de negação de serviços em função do trafego gerado narede;

5. Modelagem e Implementação:Nesta etapa as classes dos objetos pertencentes ao sistema foram modeladas eimplementadas. Com o objetivo de auxiliar na realização destas atividades algumasferramentas foram selecionadas, onde é possível observar informações sobre cadauma delas na listagem a seguir:

a) Astah Community: Ferramenta voltada para a modelagem de diagramas da UML2 (Unified Modeling Language) [17]. Optou-se por utilizá-la no projeto em funçãode prover suporte a todos os diagramas UML na versão 2.1 gratuitamente;

b) Java é uma linguagem utilizada no desenvolvimento de aplicações que seguemo paradigma de Programação Orientada a Objetos (POO), na qual foi lançadapela Sun Microsystems em 1995 [18]. Como vantagem em seu uso destacamos aportabilidade. Java traz como lema: "Write Once Run Anywhere", traduzidopara o português: "Escreva uma Vez e Execute em Qualquer Lugar", pois possuiuma arquitetura que fornece independência em relação o SO instalado em umdispositivo. Desta forma permite que códigos sejam executados em qualquerplataforma (Windows, Linux, Mac OS, etc.), desde que possua seu interpretadorinstalado. Logo o IDS proposto poderá ser adaptado a qualquer ambiente, sema necessidade de realizar modificações em sua estrutura interna;

c) O Java Agent DEvelopment (JADE) é framework implementado na linguagemJava. Busca simplificar o desenvolvimento de SMA através de ummiddleware queatende as especificações da Foundation for Intelligent Physical Agents (FIPA)[19]. Foi selecionada por oferecer diversas ferramentas que facilitam e auxiliamdurante o processo de desenvolvimento de SMA, tais como: Interface visualque gerencia vários agentes e containeres de agentes inclusive remotamente;Mecanismos para depuração; Suporte ao transporte de mensagens entre osagentes; Permite a integração com aplicações externas;

d) O Log4J é um framework de código aberto implementado na linguagem Javaque permite aos desenvolvedores escreverem informações de log em fragmentosde seus códigos e configurá-los externamente através de arquivos de propriedadesde forma simplificada [20]. Como principal vantagem em seu uso, destacamos apossibilidade de criar e modificar arquivos de log em ambientes que utilizammúltiplas threads ou que serão acessados por diversos componentes em tempode execução, descartando o trabalho dos desenvolvedores em relação ao controlede concorrências destes arquivos;

2 linguagem que define uma série especificações que ajudam a moldar e documentar os sistemas orientadosa objetos.


e) NetBeans é definindo como um Integrated Development Environment (IDE) decódigo aberto, ou seja, um ambiente de desenvolvimento que permite escrever,compilar, depurar e instalar programas de maneira integrada [21]. Selecionadapor fornecer suporte a diversas linguagens de programação e frameworks, dentreelas o Java, JADE e o Log4J;

A tabela 1 apresenta resumidamente o ofício de cada ferramenta dentro do projeto,em conjunto com os principais aspectos que foram considerados na fase de seleção.

Ferramentas Selecionadas Para Etapa de Modelagem e Implementação

Nome - Aplicação- Justificativa(s) da escolha

Astah - Auxilio na modelagem dos Diagramas da UML.- Licença de uso gratuita;- Suporte a todos os diagramas UML;- Permite exportar diagramas para arquivos de imagens.

Java - Implementação das funcionalidades pesistentes ao modelo.- Licença de uso gratuita;- Multiplataforma;- Está entre as 5 linguagens mais utilizadas no mundo [22];- Diversas comunidades de desenvolvedores.

JADE - Plataforma para desenvolvimento dos agentes.- Código aberto;- Implementado na linguagem Java;- Oferece gerenciamento em tempo real tanto dos agentes locais como remotos;- Suporte ao transporte de mensagens entre os agentes;- Permite a integração com aplicações externas.

Log4J - Manipulação dos arquivos de logs.- Código aberto;- Implementado na linguagem Java;- Possibilita sua configuração,de uso através de arquivos de propriedades;- Gerencia a modificação dos arquivos mesmo quando acessado por mais deuma thread simultaneamente.

NetBeans - Auxilio no processo de escrita, compilação e depuração dos códigos Java.- Código aberto;- Implementado na linguagem Java;- Oferece suporte ao JADE e o Log4J.

Tabela 1 – Ferramentas selecionadas para etapa de modelagem e implementação. Fonte: Autoriaprópria

6. Realização dos Testes:Posteriormente a implementação dos componentes fundamentais, três experimentosforam realizados com o objetivo de averiguar a atuação do protótipo. O primeiro esegundo teste avaliavam a capacidade de identificação de ataques, o terceiro serviupara analisar a viabilidade da ferramenta de forma a apresentar qual benefício dautilização do sistema, classificando assim esta como a etapa final do trabalho. Para


realização desta atividade mais quatro ferramentas foram escolhidas com o intuitode assessorar e simplificar esta fase. A lista abaixo apresenta um resumo sobre cadauma delas:

a) Kernel-based Virtual Machine (KVM) é uma solução de virtualização completapara o sistema operacional (SO) Linux [23]. Ao utilizar o KVM como ferramentade virtualização é necessário apenas adicionar um módulo ao kernel do SO,descartando a necessidade de configurações adicionais. ;

b) Virt-manager ferramenta que apresenta uma interface de linha de comando ouinterface gráfica com o usuário para gerenciar de máquinas virtuais [24]. Foiselecionada para este projeto por apresentar integração com nativa com módulodo KVM;

c) JMeter é um software de código aberto utilizado para testes de carga em serviçosoferecidos por sistemas computacionais [25]. Possui como principal vantagemum funcionalidade denominada thread group, no qual é possível configurar onúmero de threads, a quantidade de vezes que cada thread será executada e ointervalo entre cada execução, possibilitando a realização dos testes de stress;

d) Hping é uma ferramenta capaz de gerar pacotes TCP, UDP e ICMP. Utilizadaprincipalmente em teste de firewall e de redes de comunicação [26]. Foi seleci-onada por permitir realizar ataques DoS de forma simplificada, necessitandoapenas da definição de parâmetros essenciais, como endereço da vitima e tipodo pacote (TCP, UDP, etc.) por exemplo.

A tabela 2 apresenta o papel de cada uma das quatro ferramentas e cita os principaisaspectos que foram considerados para sua seleção.

1.4 Estrutura do documentoEste trabalho encontra-se agrupado em sete capítulos, onde o primeiro destes

apresenta a justificativa, os objetivos e a metodologia abordada no projeto. O capitulo 2expõem a base teórica utiliza acerca dos conceitos fundamentais persistentes a pesquisa.No capitulo 3 os trabalhos relacionados são apresentados. O modelo proposto é detalhadono capitulo 4. A modelagem do sistema e trechos de códigos desenvolvidos são evidenciadosno capitulo 5. Os testes realizados são retratados no capitulo 6. Por fim, no capítulo 7são expostas as conclusões do trabalho bem como levantados apontamentos de trabalhosfuturos.


Ferramentas Selecionadas Para Etapa de Testes

Nome - Aplicação- Justificativa(s) da escolha

KVM - Criação e gerenciamento das maquinas virtuais.- Código aberto;- Facilidade de configuração (necessário apenas adicionar um módulo ao kernel do SO).

Virt-manager - Interface para o gerenciamento gráfico da máquinas virtuais.- Código aberto;- Integração nativa com o KVM;- Recomendada pela comunidade mantedora do KVM.

JMeter Testes de carga em serviços.- Código aberto;- Implementado na linguagem Java;- Permite definir o número de threads, quantidade de vezes que cada threadserá executada e o intervalo entre cada execução.

Hping - Simulação de ataques DoS.- Código aberto;- Fornece uma interface de utilização em modo texto que simplifica a geração de pacotes de rede,necessitando apenas informar parâmetros essenciais.

Tabela 2 – Ferramentas selecionadas para etapa de testes[Ferramentas selecionadas para etapa de testes] Ferramentas selecionadas para etapa de

testes. Fonte: Autoria própria

26

2 Fundamentação Teórica

Neste capítulo serão apresentados os principais conceitos sobre computação emnuvem, segurança da informação, sistemas de detecção de intrusão e tolerância a falhas.Tais conceitos foram de fundamental importância para o entendimento de cada tecnologia,sintetizando então o conhecimento necessário a ser utilizado no desenvolvimento do modeloproposto neste trabalho.

2.1 Computação em Nuvem

2.1.1 Visão Geral

A computação em nuvem é uma tendência que vem ganhando gradativamentereconhecimento em áreas de TI (Tecnologia da Informação), que busca mover dados erecursos computacionais de computadores locais para grandes centros prestadores desseserviço, disponibilizando o acesso a esses através da internet [27].

Segundo [28] a computação em nuvem está intimamente ligada com tecnologias jáexistentes, tais como virtualização, sistemas distribuídos e rede de computadores. Sendouma arquitetura orientada a serviços, que visa reduzir a sobrecarga ao usuário finalrelacionada a necessidade de configuração e manutenção em componentes de hardwaresou softwares, pois devem preocupar-se apenas em conectar a internet, permitindo maiorflexibilidade e redução de custos.

A computação em nuvem foi definida pelo Instituto Nacional de Padrões e Tec-nologia americano (NIST - National Institute of Standards and Technology) como ummodelo de acesso facilitado, sob a demanda do usuário, e de qualquer ponto geográfico ainterconexões de recursos computacionais, que podem ser disponibilizados e liberados comum esforço mínimo de gestão ou interação com o provedor de serviços [29].

A computação em nuvem impacta diretamente a forma de gerenciar sistemasindependentemente do gênero da atividade ou tamanho da organização. É um modelo parapermitir acesso a dados e recursos em qualquer momento, sendo dependente apenas de umdispositivo cliente e sua conexão com internet. Provê acesso sob demanda e compartilharecursos computacionais entre usuários que podem ser rapidamente providos e liberadosem um esforço mínimo de gerenciamento ou interação com o provedor do serviço [29].

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

2.1.2 Características Fundamentais

A computação em nuvem possui várias características que as diferem notoriamenteem relação de serviços tradicionais. Segundo [30] essas características são:

• Múltiplos InquilinosEstá ligado ao conceito de compartilhamento de recursos entre grupos de clientes,independente da camada em que o recurso se encontra (hardware ou software). Cadacliente é denominado inquilino e estes podem disponibilizar serviços a outros gruposde usuários, podendo também realizar modificações em recursos obtidos, porém essasações não devem influenciar no contexto de outros inquilinos.

• Geo-distribuição e Acesso Ubíquo a RedeÉ necessário que qualquer dispositivo capaz de se conectar com a internet como umtelefone celular ou um notebook por exemplo, permita o acesso aos os serviços emnuvem.

• Orientado a ServiçosNuvem computacionais seguem um modelo operacional conduzido a serviço, por issoé necessário grande ênfase na gestão destes de forma transparente aos clientes.

• Provisionamento Dinâmico de RecursosCapacidade de alocar e modificar de forma dinâmica recursos computacionais queestejam atribuídas aos usuários da nuvem a qualquer momento. Tal dinâmica ofereceflexibilidade ao provedor de serviço em relação ao seu gerenciamento bem como ousuário, que pode alocar ou liberar recursos à medida que necessário seja.

• Auto OrganizaçãoUma vez que recursos são alocados ou liberados dinamicamente, os provedores deserviços ao detectar o aumento ou diminuição da demanda em determinada instânciade um serviço, podem tomar medidas necessárias para melhor gerir seus recursos,buscando diminuir desperdício, o que acarreta em diminuição de gastos.

• Cobrança Baseada na UtilizaçãoPreços aplicado pelo provedor do serviço devem ser de acordo com o uso do cliente.Geralmente define-se um valor a ser pago por hora. Por exemplo, se durante 24horas passadas o serviço foi utilizado apenas 2 horas então só será cobrado o valorequivalente a essas horas de atividade.

2.1.3 Serviços em Nuvem

Uma nuvem computacional pode prover três tipos de serviços, em que diferenciam-seprincipalmente na forma em que os recursos serão oferecidos aos usuários [31]. O relatório


apresentado pela A NIST [29] caracteriza cada um deles como:

• Software como Serviço (SaaS - Software as a Service)O consumidor deve ser capaz de acessar e utilizar aplicações que não estejaminstaladas em sua máquina local e sim no provedor do serviço executando em umainfraestrutura de nuvem. O acesso poderá ser realizado de diversos dispositivoscomo notebooks ou celulares através de interfaces leves, com a menor alocaçãocomputacional possível por parte do cliente. O consumidor não pode obter acessonem controlar a infraestrutura da nuvem na qual o provedor dispõem seus serviços,como definições de redes, capacidade de armazenamento, sistema operacional, etc.Os prestadores de serviços disponibilizam o modelo SaaS como uma camada deexecução de softwares na nuvem. Do ponto de vista do usuário, esse modelo denotadiminuição dos custos na aquisição de licenças de uso, tendo em vista que todosos custos da utilização destes estão incluídos na contratação dos serviços junto aoprovedor de nuvem.

• Plataforma como Serviço (PaaS - Platform as a Service)A disponibilização do serviço deve ser destinada a infraestrutura adquirida ou criadapelo usuário. Pode-se utilizar bibliotecas, linguagens de programação, serviços eferramentas que possam ser suportadas pelo provedor. O consumidor não podeobter acesso nem controlar a infraestrutura da nuvem na qual o provedor dispõemseus serviços, porém deverá estar disponível a ele o controle sobre as aplicaçõesimplementadas bem como configurações para o ambiente de hospedagem. No PaaS,os desenvolvedores podem obter um pacote com todos os sistemas e ambientesnecessários para o ciclo de vida de um software, ou seja, desenvolvimento, teste,implantação e a hospedagem de aplicações Web.

• Infraestrutura como Serviço - (IaaS - Infrastructure as a Service)Destinada a prover recursos computacionais como capacidade de processamentoe armazenamento, endereçamentos redes, frequência de banda e outros recursosque sejam necessários para permitir que o consumidor seja capaz de implementarseus softwares, que podem ser de quaisquer tipo, como um sistema operacionalou um aplicativo comercial. O consumidor não pode obter acesso nem controlar ainfraestrutura da nuvem, mas é possível modificar os softwares implementados.

2.1.4 Modelos de Implantação

De acordo com o relatório apresentado pelo NIST [29], são considerados possíveisquatro modelos de nuvem computacional. São eles:


• Nuvem Pública (Public Cloud)A infraestrutura nesse modelo está disponível para qualquer usuário que conheçaa localização virtual na qual o serviço se encontra publicado. Restrições de acessonão podem ser aplicados referentes ao gerenciamento de redes nem técnicas deautenticação e autorização aos usuários. Este modelo pode fornecer mais economiade recursos uma vez que tais são compartilhados a todos, porém suas limitaçõesquanto a segurança das informações levam a concluir quem em contextos onde asconfidencialidade dos dados seja de fundamental importância, não seria interessanteoptar em utilizar uma nuvem sob esta perspectiva.

• Nuvem Privada (Private Cloud)Uma nuvem privada permite o gerenciamento do controle de serviços e de acessos,que podem ser realizado pela própria empresa que detém os recursos computacionaisde hardwares ou por terceiros. O gerenciamento pode ser de endereçamento deredes, largura de banda, definições dos provedores de serviços, portas e protocolosa serem utilizados na comunicação com dispositivos clientes, e aplicar tecnologiasde autenticação e autorização. Esse modelo pode prover um menor risco em seuuso quanto ao vazamento de informações visto que apenas usuários cadastradose autenticados poderão acessar dados que estejam armazenados, porém diminui aeconomia de recurso pois exige gerenciamento do controle aplicado.

• Nuvem Comunitária (Community Cloud)Neste modelo o compartilhamento ocorre entre duas ou mais empresas que possuamuma nuvem, geralmente por possuírem interesses semelhantes. Pode ser implementadalocalmente ou remotamente. A administração da nuvem poderá ser realizada poralguma empresa da comunidade ou por terceiros. Nuvens comunitárias são semelhanteao modelo de nuvem privada pois permitem definir controle e gerenciamento danuvem e políticas de acesso aos usuários. E torna-se especial por poder disponibilizarrecursos tanto de hardwares ou softwares como se fosse apenas uma única instância.

• Nuvem Híbrida (Hybrid Cloud)Caracteriza-se pela agregação de dois ou mais modelos de implantação de nuvem(privada, pública e comunitária), na qual permanecerão como instâncias únicasinterconectas por protocolos definidos para ambos. Para a utilização deste modelodevem ser adotado mecanismos de identificação afim de determinar a qual nuvemdeterminado usuário pertence.

2.1.5 Data Center em Infraestrutura NuvensO data center é uma estrutura que possui papel de centralizar recursos computacio-

nais em grande escala, interconectados através de redes e que permitam flexibilidade paraadição ou remoção de outros recursos caso sejam necessários. Levando em consideração


a dimensão do datacenter pode torna-se complexa a administração, fatores como altosgastos com consumo de energia, necessária para alimentação dos dispositivos e refrigeraçãodo ambiente na qual estão inseridos, como quantidade de servidores e comutadores deredes a serem monitorados. Na literatura existem algumas definições acerca deste assunto,nas quais três estão descritas abaixo. Veras e Tozer [32] conceitua data center como:

conjunto integrado de componentes de alta tecnologia que permitemfornecer serviços de infraestrutura de TI de valor agregado, tipicamente deprocessamento e armazenamento de dados, laga escala, para qualquer tipode organização. Os data centers e suas conexões forma a infraestruturada nuvem, que seja pública ou privada [32].

Para Velte, Velte e Elsenpeter [33] o data center é classificado como:

um conjunto de servidores onde o aplicativo é armazenado. Poderia serum grande quarto no porão de seu edifício ou em um espaço cheio deservidores no outro lado do mundo que você acessa através da internet.Uma tendência crescente no mundo de TI é a virtualização de servidores,isto é, o software pode ser instalado permitindo que vários servidoresvirtuais sejam usados [33].

Verdi et al. [34] afirmam que:

data center é a infraestrutura que abrigam os servidores e técnicas devirtualização, oferecem os serviços em nuvem. Portanto são a manifestaçãofísica da computação em nuvem, sendo a infraestrutura de rede a base deconsumições que habilita este paradigma, interligando servidores físicosem grande escala. Dependendo do tamanho da provia infraestrutura físicae sua localização, os data centers podem ser classificados como mega,micro, nano ou baseado em contêineres [34].

No trabalho de [35] é apresentado um gráfico na qual um data center local e datacenter para nuvens são comparados, na tentativa de esboçar o ganho com diminuição doconsumo de recursos realizado quando aplicados em nuvem, como mostrado na Figura 3.

O primeiro gráfico representa um data center local que segundo [35] é necessáriosinvestimentos em recursos a fim de atender a demanda, sendo estes fixos, não existindo apossibilidade de se desfazer da infraestrutura adquirida, exaltando os recursos humanos naqual devem ser utilizados para garantir o funcionamento dos equipamentos e sistemas deTI. Visivelmente a quantidade de recursos que serão subutilizados com decorrer do tempoirá aumentar, principalmente em momentos de menor demanda.

O gráfico a direita o autor demostra que a computação em nuvem aplicada aodata center permite a elasticidade de seus serviços de acordo com a demanda, reduzindoa possibilidade de subutilização de recursos e respeitando as requisições por parte dosclientes, implicando assim que a longo do tempo recursos de TI, bem como mão de obradiminuem consideravelmente.


Figura 3 – Comparação entre data centers. Fonte: [35]

2.1.6 Virtualização de Recursos Computacionais

O principal fator que permite a flexibilidade em contexto de nuvens é a utilizaçãode técnicas de virtualização [36]. Segundo [37], com a utilização destas técnicas é possívelque recursos de hardwares como processadores ou memorias primária que estejam dispostasem um único componente do data center sejam compartilhados entre diversos servidoresvirtuais.

Recentemente com o avanço na produção de componentes de hardwares cadavez mais potente e robustos, a virtualização adequa-se de forma providencial a evitarsubutilizações desses equipamentos. Trata-se de uma camada computacional lógica queencontra-se entre as aplicações e a infraestrutura física [36].

Com a virtualização é possível abstrair o recurso físico, permitindo então que sejamcriados recursos virtuais ou lógicos, nas quais estarão disponíveis para compartilhamentoentre processos. Os recursos lógicos podem ser distribuídos de forma dinâmica, assim épossível que a demanda dos usuários defina a quantidade a ser consumida, ou seja emmomentos de pico mais recursos lógicos são criados, desta forma componentes de hardwaressão exigidos em uma maior quantidade, porém quando a demanda for diminuída, menortambém será a quantidade de recursos lógicos consumidos, logo diminuindo também aexigência do hardware.

Para que diversos sistemas operacionais homogêneos ou heterogêneos executemsobre um mesmo servidor físico, é necessário que haja uma camada a mais a fim derealizar o gerenciamento destes recursos (hardwares ou softwares), esta camada é nomeadade hipervisor ou Virtual Machine Monitor (VMM) [36]. Ainda de acordo com [36] ohipervisor é o principal responsável por converter os recursos físicos em lógicos bem como


seu gerenciamento e compartilhamento entre as máquinas virtuais ou Virtuais Machine(VM).

Existem dois modelos de hipervisores segundo [38,39]:

• Modelo 01O hipervisor exerce seu papel uma camada acima do hardware, exatamente igual asistemas operacionais convencionais, assim os sistemas operacionais convidados ficamdispostos logo acima do hipervisor. Na Figura 4 é apresentado esta arquitetura.

Figura 4 – Arquitetura hipervisor modelo 01. Fonte: Adaptado de [38]

• Modelo 02Neste modelo o hipervisor encontra-se sobre um sistema operacional, os sistemasoperacionais convidados logo acima. Na Figura 5 é apresentado esta arquitetura.

Segundo [38] Este Modelo possui duas formas de exercer a virtualização:

– Virtualização CompletaNão necessita de alterações no kernel (núcleo) do sistema operacional adja-cente, ou seja o hipervisor tem acesso ao hardware de forma restrita, uma vezque depende totalmente do sistemas operacional para controle de tal recurso.Segundo [40] o desempenho por parte das VM podem ser significativamentediminuído, pois todas as instruções terão uma camada a mais de processamento,porém a um ganho de portabilidade em relação ao sistema operacional instalado,já que as instruções a nível de hardware não ficam mais sob a responsabilidadedo hipervisor.

– ParavirtualizaçãoNesta técnica é necessário que modificações no kernel do sistemas operacional


Figura 5 – Arquitetura hipervisor modelo 02. Fonte: Adaptado de [38]

sejam aplicadas, logo a interação entre o hipervisor e o hardware se tornammais eficazes, pois passa a depender de forma parcial do sistema operacional.Inversamente a virtualização completa ao optar por esta forma de trabalho dohipervisor há diminuições de portabilidade, pois cada sistema operacional podeter formas diferentes de trabalhar, o que acarreta em modificações especificaspara cada tipo de sistema, porém o ganho no desempenho da VM é expandido,justamente por acessar alguns recursos de hardwares diretamente, diminuindoa quantidade de processamento por instrução [40].

2.1.7 Benefícios da Computação em Nuvem

Em diferentes fatores a computação em nuvem mostra-se benéfica. Segundo [32]a principal vantagem a ser destacada é a escalabilidade suportada por estes tipos deplataforma, pois permite uma utilização de forma otimizada tantos em momentos de altademanda como em casos de ociosidade de requisições por parte dos usuários. Exemplo,servidores nas quais não estejam sendo utilizados porém consumindo carga elétrica, podeimplicar ineficiência na administração do data center certamente acarreta em gastosdesnecessários, com tudo se aplicado as técnicas de computação em nuvem, esse uso serámelhor gerenciado.

Velte, Velte e Elsenpeter [33] salientam que nessa arquitetura os servidores inter-conectados que estão formando uma plataforma de nuvem, podem estar distantes umdos outros do ponto de vista geográfico, permitindo assim maior flexibilidade em relaçãoa armazenado ou até mesmo segurança dos dados. Exemplo, supondo que em um dos


data center de uma determinada empresa seja afetada por catástrofes naturais, como umterremoto, os administradores ao observarem que possa de alguma forma comprometer aintegridade física dos componentes dessa região, possuem a possibilidade de enviar essasinformações a servidores que estejam em outra cidade sem muitas complicações.

A computação em nuvem prover a diminuição de custos relacionados aos equipa-mentos de hardwares, como manutenções ou alterações de peças danificadas, reduzindotambém gastos com refrigeração, espaço físico para alocação destes componentes, pois aresponsabilidade sobre a infraestrutura será atribuída a um prestador de serviços. Destaforma a computação em nuvem permite as organizações se tornarem mais competitivas,devida a flexibilidade e agilidade, disponibilizando plataformas escaláveis, recursos emalto desempenho e dados e aplicações respeitando então a disponibilidade. Empresasdesenvolvedoras de sistemas podem economizar em tempo, qualidade das aplicações, im-plantações, segurança, e manutenção enquanto se beneficiam da escalabilidade provida. Omeio ambiente pode se torna mais sustentável, pois é reduzido a quantidade e equipamentosa serem utilizados, bem como gastos em alimentação elétrica, e espaços de utilização [7].Ainda no trabalho de Carroll, Merwe e Kotze [7] são apresentados os principais benefícioscitados na literatura durante sua pesquisa, como visto na Figura 6.

Figura 6 – Benefícios da computação em nuvem. Fonte: Adaptado de [7]

Observa-se que o fator a receber mais destaque são as questões relacionadas a custos,porém diversos fatores também são em grandes números mencionado como escalabilidade,


flexibilidade, agilidade, gestão de recursos, permitir melhor foco em regras de negócios porparte da organização, eficiência e a confiabilidade elevada.

2.1.8 Riscos da Computação em Nuvem

Os aspectos principais que podem determinar a não adoção por computação emnuvem são questões que envolvem a segurança e a privacidade, pois o fato de manterdados sigilosos de uma organização em data centers em outras organizações pode assustarum pouco, ainda mais se pensar que estes podem ser utilizados por milhares de usuáriossimultaneamente.

Veras e Tozer [32] descrevem alguns cuidados que devem ser atentados no momentoda contração de um provedor de nuvem, pois todos eles podem representar ricos ao usuários:

• Saber como é feito o acesso dos usuários;

• Saber como o provedor obedece às normas de regulamentação;

• Saber como se localizam os dados;

• Saber como os dados são segregados e como são recuperados;

• Saber como é feito o suporte;

• Entender a viabilidade do provedor no longo do prazo.

Subashini e Kavitha [41] lembram que a arquitetura da nuvem computacional possui3 modelos de entrega de serviços a usuários finais que são: Saas, Paas e Iaas. Por teremnicho de usuários diferentes, os níveis e técnicas de segurança também são dessemelhantes,por isso o provedor de serviço deve ter bastante cautela ao gerenciar a forma como sedará a transição de dados entre as camadas, evitando possíveis conflitos relacionados adiferentes técnicas de segurança, pois falhas nos níveis mais abaixo podem comprometeras camadas acima.

2.2 Segurança e da Informação

2.2.1 Visão Geral

A segurança da informação consiste em aplicações de medidas visando desencorajar,impedir, detectar e corrigir violações de qualquer conteúdo que por ventura possa serarmazenado ou transferido de algum modo, servindo a determinado propósito para umindivíduo ou uma organização [42].


A segurança da informação possui três pilares, nas quais devem ser fundamental-mente preservados mediante uso de uma gestão de riscos, que são: a confidencialidade, aintegridade e a disponibilidade dessas informações [43].

A confidencialidade, princípio na qual implica que as informações permanecerãosecretas, e somente aos usuários autorizados será permitido o acesso [44]. O uso deinformações confidenciais por usuários nas quais não sejam aptos, podem casuar impactosnegativos em aplicações, bem como na comércio e na indústria [45].

A integridade ocupa-se em garantir que as informações sejam confiáveis, tantoquanto sua origem, bem como sua exatidão e a prevenção de modificações feitas porusuários que não possuam autorização para tal [42].

Segundo [44] mecanismos de proteção da integridade são divididos em dois tipos:

• Mecanismos de Prevenção: Objetiva-se a coibir modificações não autorizadas;

• Mecanismos de Detecção: Atuam detectando modificações realizadas por usuáriosnão autorizados, geralmente posteriores a falhas nos mecanismos de prevenção.

A disponibilidade busca garantir que um sistema ou algum recurso esteja disponívelpara uso sempre que necessário sem exigir algum tipo de aviso prévio, pois deve respeitara demanda do usuário na qual está autorizado o acesso [42]. Kurose et al. [45] afirmam quea disponibilidade é tão importante e fundamental quanto a confidencialidade e integridade.

2.2.2 Segurança em Redes de Computadores

Em redes de computadores, as questões de segurança estão intimamente relacionadasa forma da troca de informações entre os equipamentos, ou seja, nos protocolos decomunicação. Para [42] o termo segurança de redes é de certo ponto incorreto, pois todas asempresas, governos e organizações em geral interconectam seus equipamentos em diversasredes computacionais. Inter-rede é o nome aplicado a esses conjuntos, sugerindo então otermo segurança em inter-redes.

Tanenbaum e Wetherall [46] descrevem resumidamente algumas medidas que podemser aplicadas para proteger os dados, dividido-as por camada da pilha de protocolo TCP/IP:

• Física: tubos nas quais os cabos são guiados podem ser lacrados com gás inerte emalta pressão. Uma queda da pressão que pode ser ocasionada por um rompimentodo cabo seria capaz de disparar um alarme. Diversos sistemas militares optam poruso dessa técnica;

• Enlace: pacotes de um determinado canal ponto a ponto podem ser codificados ámedida que são enviados de um ponto a outro, posteriormente decodificados em


seu recebimento. Os detalhes dessa codificação podem ser tratados na camada deenlace. No entanto essa técnica pode não ser eficaz quando existem vários roteadoresna rede, pois em cada um deles o pacote deve ser decodificado e codificado casonecessário. Porém esse método pode ser facilmente incluído em qualquer rede e comfrequência é muito útil;

• Rede: O uso de firewalls para controle de pacotes é comumente utilizada. A própriasegurança provida pelo protocolo IP (ipsec) pode ser bem aproveitado nessa camada;

• Transporte: É possível criptografar conexões inteiras de processo a processo. Paraseu uso de forma eficaz é necessário aplicada em ambos os lados da comunicação;

• Aplicação: Questões de autenticação de usuários e não repudio, só podem sertratados na camada de aplicação;

A camada física é a única na qual não baseia sua segurança em métodos decriptografia. Segundo [47] as técnicas criptográficas são meios de permitir que mensagenssejam disfarçadas de modo que apenas usuários diretamente envolvidos na comunicaçãoconsigam compreendê-las, assim os dados que por ventura venham a ser capturados porum intruso estarão de forma ilegível, logo não conseguirá obter nenhuma informação doconteúdo dessas massagens interceptadas.

Hendricks et al. [48] definem criptografia como:

ciência que trata da preservação dos dados privados. Na terminologiacriptográfica, esses dados são chamados de textos simples ou puros. Acodificação dos dados, de maneira que os dados tornem-se ininteligíveispara os que venham a interceptá-los, é chamada de criptografia. Essesdados criptografados são chamados de texto cifrado. O processo dereconversão do texto cifrado para texto puro é chamado de descriptografia.

As técnicas de criptografia baseiam-se em uso de dados privados para efetuar acodificação e decodificação de dados, denominada neste processo de chave. Existem duasclasses de algoritmos de criptografia, nas quais diferem-se as chaves que estes utilizampara realização de sua tarefa [42, 46,48]:

• Algoritmos simétricos: para realização da codificação e decodificação é utilizadoapenas uma única chave, logo esta deve ser compartilhada entre todos os usuáriosque participam da conversação.

• Algoritmos assimétricos: aplica-se o uso de duas chaves, nas quais são classificadasem chave pública e a chave privada, uma chave para encriptação e outra paradecrepitação. Nesta técnica apenas a chave publica é compartilhada, a privada deveser utilizada apenas por seu dono.


2.2.2.1 Criptografia simétrica

A criptografia simétrica também é chamada de criptografia de chave privada, sendoesta a forma mais comum de criptografia. Os participantes compartilham uma única chaveno decorrer do processo, por isso faz se necessário um canal de comunicação totalmenteseguro, na qual a chave deverá ser transmitida no inicio para conversação.

Araujo [49] ressalta que ao a utilizar-se desta técnica, não é possível distinguirpor qual das chaves a informação foi criptografada, ou seja não existe a propriedade deirretratabilidade. Destaca também como uma das vantagens em seu uso, é por prover omesmo nível de segurança para os dados criptografados, e em geral, são mais rápidos queos algoritmos de criptografia assimétrica. A Figura 7 apresenta uma conversação sobreeste modelo.

Figura 7 – Criptografia simétrica. Fonte: [48]

2.2.2.2 Criptografia assimétrica

A criptografia assimétrica também é chamada de criptografia de chave pública, naqual foi inserida na computação posteriormente a publicação do artigo do New Directionsin Cryptograph [50], na qual foi proposto o primeiro modelo para acordo de chaves, permitiaque dois participantes combinassem uma chave secreta sobre um canal de comunicaçãonão seguro.

A criptografia assimétrica foi criada objetivando sanar as falhas do modelo anterior,como por exemplo a como a necessidade de troca da chave secreta e falta de autenticidade.A necessidade de troca da chave secreta é eliminada por meio uso de chaves públicas,onde estas serão disponibilizadas publicamente, a chave privada deve ser mantida sobreproteção por seu dono. Ao escrever uma mensagem a chave pública do destinatário deve serutilizada para codificação, na qual o conteúdo so poderá ser decodificado pela respectivachave privada. A Figura 8 oferece uma ilustração desse processo.


Figura 8 – Criptografia assimétrica. Fonte: [48]

Tem sua desvantagem principal o fato de exigir mais recursos computacionaisem sua aplicação, tendo desempenho baixo no processo de encriptação e desencriptaçãoaté mesmo para computadores mais modernos, variando de acordo com o tamanho damassagem.

Para utilização deste modelo é necessário um mecanismos de controle e gerenci-amento de chaves, denominado aqui de ICP (Infraestrutura de Chave Pública) ou eminglês PKI (Public Key Infrastructure). Segundo [48] a PKI é uma entidade na qual devese responsabilizar por um conjunto de serviços necessários para se gerar e gerenciar paresde chaves pública/privada, também emitir e controlar certificados digitais e administrar ociclo de vida das chaves.

2.2.2.3 Assinaturas digitais

A autenticidade de documentos impressos geralmente é caracteriza pela presençade uma assinatura manual do emissor. Para que sistemas de mensagens computadorizadaspossam substituir o modo tradicional de papel e tinta, é necessário uma forma que permitaaos usurários assinar de forma digital seu documentos, de modo que este não possa serforjado [46], essa solução é conhecida como assinatura digital.

Assinaturas digitais tem por objetivo fundamental garantir dois princípios desegurança, a integridade e identidade, com seu uso é permitido conferir a integridade dosdados e garantir a identidade do remetente. A criptografia assimétrica é de fundamentalimportância para está tecnologia. Geralmente cria-se uma assinatura mediante um resumoou algum bloco da mensagem ou documento que deve ser assinado, combinando-as cominformações do assinante, bem como data e hora, ou qualquer dado que possa ser útil [48].

De forma resumida, podemos exemplificar o uso da assinatura digital por meio


da criptografia assimétrica da seguinte forma: Ao enviar uma massagem remetente gerauma assinatura para o documento que deseja enviar utilizando-se de sua chave privada, Odestinatário recebe o documento juntamente com a assinatura, posteriormente valida ainformações recebidas usando a respectiva chave pública, logo se efetuada com sucesso, odestinatário tem a certeza de que a mensagem foi enviada de fato por que alega ser, ouseja o dono da chave privada.

Importante ressaltar que o uso de assinaturas digitais não visa proteger os dados,assim como no uso de criptografia, pois atua sobre os princípios de autenticação, integri-dade e não repúdio (emissor não pode negar a sua autenticidade), no entanto as duastécnicas podem ser combinadas sobre um mesmo documento, gerando então documentoscriptografados e assinados digitalmente.

2.2.2.4 Certificados digitais

Uma aplicação importante de assinaturas digitais é a certificação das chaves, ouseja, prover a certeza de que uma chave publica é de fato pertencente a uma entidadeespecífica [45].

Certificados digitais tem a função principal de vincular uma chave publica a umaentidade (pessoa, empresa, governo etc.), porém eles não são secreto ou protegidos e sãocompartilhados pela própria organização que está certificando [46].

É documento eletrônico utilizado para identificar uma pessoa, servidor, empresaou outra entidade qualquer, através de terceiros que confirmam esse certificado. Essesterceiros são chamados de Autoridades Certificadoras (AC). Os certificados gerados poruma AC devem seguir as seguintes características [48]:

• Ligar uma chave pública a uma entidade que a identifica;

• Incluir o nome da entidade, a data de expiração, o nome da AC e o número de seriedo certificado;

• Sempre incluir a assinatura digital da AC emissora, para que usuários deste certificadopossam confiar no mesmo.

Segundo Silva et al. [51]:

certificação digital é um conjunto de técnicas e processos que propiciammais segurança às comunicações e transações eletrônicas, permitindotambém a guarda segura de documentos. Permite que informações tran-sitem pela Internet com maior segurança. É baseada na existência deCertificados Digitais emitidos por uma Autoridade Certificadora(AC),considerada confiável pelas partes envolvidas. Garantindo o conteúdo demensagens ou textos, sua autoria e data em que foi assinada. Baseia-seno princípio da terceira parte confiável, que oferece confiabilidade entre


partes que se utilizem de Certificados Digitais, para isso utiliza-se deuma ICP, cuja principal função é definir técnicas e procedimentos.

A certificação digital é o uso de documentos de identificação eletrônicos, nas quaissão emitidos por uma autoridade certificadora, na qual seja considerada confiável portodas as partes envolvidas numa comunicação. É principalmente utilizada para garantir aautenticidade das chaves publicas. Titulares de Certificados é o nome atribuído a pessoa,organização, governo etc, na qual possui um certificado digital.

2.2.3 Ataques a Redes de Computadores

Ações que busquem comprometer princípios da segurança de qualquer entidade,estas classificam-se como ataques. Segundo [42] os ataques à segurança da informaçãoestão divididos em duas classes:

• Passivos: Possui o objetivo de obter informações do conteúdo de mensagens emenlaces de comunicações. Este tipo de ataque torna-se de difícil detecção, pois nãoocorrem modificações nos dados.

• Ativos: Objetiva-se a realizar a Modificações de dados em conversações ou criar defluxos falsos, afim de alocar recurso da entidade vítima de forma desnecessária.

Kurose et al. [45] complementam dividindo os ataques passivos em quatro categoriasdistintas, disfarce, repetição, modificação e negação de serviço, e afirma que os diferentestipos podem ser combinados em uma única ação.

• Disfarce: Quando um entidade assume ser outra entidade. Este tipo de ataquegeralmente envolve outras técnicas de ataque em conjunto.

• Repetição: Captura passiva de uma de dados de uma entidade, posteriormenteutiliza-as em alguma retransmissão na tentativa de criar um efeito não autorizado.

• Modificação: Ocorre modificações no conteúdo de mensagens ou até mesmo reorde-nação de fluxo para criar um efeito na qual o atacante não está autorizado.

• Negação de Serviço (DoS): Busca afetar a disponibilidade de elementos na rede,geralmente através de fluxos de pacotes falso.

Ataques passivos são extremante difíceis de ser detectar, porém existem medidaspara coibi-los (uso de criptografia no conteúdo das mensagem por exemplo). Em relaçãoaos ataques passivos, mesmo sendo mais fácil detectá-los, combater é difícil, isto se dádevido à grande classes de vulnerabilidades, que podem ser físicas, de software e ou de


rede, por isso durante um ataque ativo o preocupa-se em detectar os alvos e recuperarinformações, interrupções e atrasos ocasionados [42].

Santos [52] descreve uma variação do ataque de DoS, denominado de DDoS, nasquais os divide em três aspectos:

• Automação: Etapa inicial do processo de ataques DDoS, que envolve a localizaçãodas botnets e o envio de instruções como endereço da vítima e inicio do ataque.

• Vulnerabilidade: Buscam explorar falhas em sistemas alvos para ocasionar umapossível perda de disponibilidade.

• Impacto: Classificação quanto ao nível do ataque que aplicam em suas vítimas.

Ainda Segundo [52], os tipos de ataques amplamente utilizados em DDoS são:

• UDP (User Datagram Protocol) Flooding: Consiste em enviar quantidadesexorbitantes de pacotes UPD (protocolo da camada de transporte não orientado aconexão) em portas aleatórias do host vítima, em seu recebimento é verificado qualo processo de destino, ao constatá que o processo não está disponível, um pacoteICMP (Internet Control Message Protocol) é enviado ao atacante informando ainacessibilidade, ou seja, que não será possível atender a requisição. Desta forma osrecursos vão sendo alocados na entidade que está sob ataque, para que esta possaresponder as solicitações, causando assim a indisponibilidade do host.

• ICMP Flooding: Possui semelhança em ataques com pacotes UDP, porém ospacotes enviados agora são do tipo PING (Packet Internet Grouper) em alta demanda,de forma que a fila de pacotes a serem respondidos seja gigantesca, consumindo omáximo da largura de banda tanto entrada como saída da rede, pois a vitima alocarárecursos para enviar pacotes os pacotes de resposta.

• TCP (Transmission Control Protocol) SYN (Synchronize) Flooding: OTCP é protocolo da camada de transporte orientado a conexão, ou seja mantem oestado da conversação entre as entidade. Para o estabelecimento de uma conversaé necessário utilizar um acordo em três vias (Three-Way Handshake) na qual fazparte das especificações do protocolo. O ataque então consiste em solicitar a vitimao estabelecimento de multiplicas conexões. No acordo de três vias ao receber umapocote com a flag syn ativa o servidor retorna um pacote com a flag syn e ackinformando que está disponível para estabelecer uma conexão, então o host queestá sob ataque passa a dedicar recursos a essa conversa, no entanto para que umaconexão seja estabelecida completamente a vítima fica aguardando um pacote com aflag ack do atacante, na qual nunca chegará, decorrido alguns segundos o servidor


decide encerar a conexão por inatividade e desalocar todos os recursos previamentereservados. Desta forma os host se esgota ao ponto de não aceitar mais conexõestemporariamente de forma mais acelerada em relação aos ataques UDP ou ICMP.

2.2.4 Ameaças as Nuvens

O conceito de computação em nuvem apesar de ter se difundido a pouco tempo nomercado, utiliza-se de diversas ideias já conhecidas na área da computação [53], por issoos pontos fracos também são explorados e reaproveitados por usuários mal intencionados.Essas vulnerabilidades se tornam um dos principais aspectos a influenciar uma organizaçãoa optar por migrar para sistemas em nuvens ou não.

Cloud Security Alliance (CSA) buscando identificar as principais ameaças a am-bientes de nuvem, criou um questionário e aplicou a especialistas em Computação emnuvem, utilizando as respostas obtidas como base, um relatório foi elaborado, na qualfoi chamado de “As Notórias Nove Principais Ameaças a Computação em Nuvem de2013” [54], no intuito de auxiliar as organizações a compreenderem ameaças existentes demaiores destaques dentro do contexto de nuvem, possibilitando assim uma melhor análisedos riscos. No relatório é apresentado nove ameaças, que são: vazamento de dados, perdade dados, sequestro de contas ou tráfego de serviços, interfaces inseguras, negação deserviços, usuário mal intencionado, abuso de serviços da nuvem, investigação insuficiente evulnerabilidades de recursos compartilhados.

2.2.4.1 Vazamento de dados

Antes mesmo da utilização de computadores o vazamento de dados já era umproblema de grande risco, pois informações indo parar sob controle de concorrente poderiaser decisiva para uma organização, podendo acelerar o seu processo entrópico. Consideradopor especialistas como uma das principais riscos dos ambientes de nuvem, e acredita-se queessa ameaça tende a crescer, um vez que na era digital dados aumentam a cada segundoem larga escala, consequentemente o número de criminosos interessados nessas informaçõescresce.

Esta vulnerabilidade torna-se visível ao vermos alguns casos envolvendo grandeempresas, como em abril de 2011 a Sony [55] sofreu um grande golpe ao ter vazado dados,algo en torno de 77 milhões de contas de usuários. A principal suspeita é que o vazamentoocorreu partir do computador de um dos administradores da rede PlayStation Network(PSN), estando infectado por algum tipo de virus. Entre os dias 17 e 19 de abril, nomes,endereços, e-mails, usuários, senhas, perguntas de segurança, dentre outras informaçõesforam comprometidas. Assim que a Sony se deu conta do problema, tirou o sistemasdo ar, pelo período de 20 de abril à 14 de maio, buscando implementar um mecanismo


segurança, corrigindo a falha da sua rede. Esse vazamento de dados custou à Sony cercade 171 milhões de dólares.

A T.J. Maxx (rede de lojas de departamentos norte americana) em 2007 teve umprejuízo avaliado em 25 milhões de dólares [56], mediante a um vazamento considerávelde dados. Durou de 2005 à 2007 e acabou comprometendo aproximadamente 40 milhõesde transações de crédito. Albert Gonzalez [57] foi o cracker responsável por esse ataque,na qual agiu através da quebra do mecanismo de criptografia da rede sem fio utilizadana empresa (WEP), ao conseguir o acesso criou-se um sistema para captura de todas astransações que fossem realizadas.

Podemos notar nesses dois casos que o vazamento dos dados se deu por vulnerabili-dades do sistemas, computador infectado e mecanismo de criptografia fraco, provocandogrande prejuízo as vítimas.

2.2.4.2 Perda de dados

Ao migrar os dados de uma organização para nuvem, além de se preocuparemcom o vazamento de dados, é necessário cuidar para não provocar perdas dos mesmos,podendo ser classificadas em acidentais ou intencionais. Acidentais são aquelas que ocorremmediante um usuário ou até mesmo um sistema, exclui, sobrescreve ou altera dados deforma não premeditada, sem a intenção de prejudicar o dono das informações. Quandouma pessoa ou sistema apaga, altera ou sobrescreve de forma proposital, com o objetivode causar problemas ao proprietariado dos dados, ou de alguma forma obter vantagenscom essa ação, a estas são denominadas perdas intencionais.

A perda de dados pode causam impactos negativos, sujam a imagem da organizaçãovítima, ao transpor incapacidade de guardar com segurança os dados de seus clientes,podendo até mesmo enfrentar consequências judiciais, logo sofrer prejuízos financeiros [58].

2.2.4.3 Sequestro de contas/tráfego de serviços

Tipo de ataque que pode ser amplificado em ambientes de nuvens, isso ocorredevido a uma nuvem poder abrigar diversos serviços e contas em uso, desta forma usuáriosmal intencionados podem centralizar o seu ponto de ataque.

Geralmente envolve outro ataques, explorando vulnerabilidades ja conhecidas emserviços existentes para alcançar seu objetivo. Posteriormente ao sucesso de controlede uma conta, pode então se inciado um monitoramento de transações, ter acesso amanipulação de dados, distribuir informações falsificadas e até mesmo redirecionar clientespara sites maliciosos, desta forma abrindo possibilidades para outros tipos de ataques,como vazamento de informações, ataques internos, dentre outros [54].

Em 2013 Dropbox, uma grande empresas de armazenamento de arquivos na nuvem


foi alvo deste tipo de ataque [59]. Foi constatado que a parir da decompilação do códigodo software cliente, que deve ser instalado em um computador local, permita interceptartrafego ssl oriundo do servidor, de tal forma a autenticação dos usurários poderia serburlada.

2.2.4.4 Interfaces inseguras

Comumente os provedores de nuvens disponibilizam interfaces (APIs) para permitiraos clientes utilizarem-se de diversas informações e recursos internos. Empresas tendema criar uma novas camada de softwares a partir dessas APIs, agregando maior valor aosseus serviços. Isso garante uma grande flexibilidade, contudo a sua implementação requeresforços extras, a fim de garantir a segurança bem como seu correto funcionamento [54]. [60]em sua pesquisa apresenta diversas falhas encontradas nas APIs providas pela Amazon,onde 60% dos problemas são relacionados a paradas como falhas, 19% são falhas emconteúdo, como conteúdo errado para uma requisição, 12% são falhas por respostasdemoradas e 9% relacionados a erros genéricos. Ainda em seu trabalho ele classifica emtres categorias de falhas, que são: problemas no desenvolvimento, falhas de dispositivos efalhas em interações dos sistemas.

Diante dessa série de falhas encontradas em APIs disponibilizadas pela Amazon,Usuários mal intencionados poderiam explorar estas falhas, por exemplo sobrecarregandoo servidor mediante uma série de requisições de operações que possam gerar algum tipode erro no servidor.

2.2.4.5 Negação de serviços

Tem como objetivo fazer com que um sistema pare de responder ou passe a responderde forma lenta. O atacante busca enviar grande trafego de requisições a um máquina virtual,podendo ser com pacotes TCP, UDP, ICMP ou até mesmo uma combinação deste, afetandoa disponibilidade de serviços providos na vítima, consequentemente qualquer outro serviçoque tenha dependência do host sob ataque. Um detalhe que deve ser mencionado é apossibilidade de um ataque de negação de serviço indireto, pois o servidor de virtualizaçãopode dedicar recursos a mais ao host vítimas a fim de processar as requisições falsas,de forma que venha a atrapalhar no processamento de outras instâncias sob controle domesmo hipervisor [3].

O ataque de negação de serviço distribuído também pode ser aplicado no ambientede nuvem, de modo a dificultar que sistemas alvos que estejam preparados para ataquesde negação de serviços centralizado, processar apenas o trafego que não seja malicioso. Ostipos mais comuns desse ataque são: UDP flood, TCP SYN flood, dentre outros [61].

Ataques de negação de serviço aumentaram nos últimos anos, isso se dá em funçãoao aumento gradativo de sistemas disponíveis online. Um dos princípios da computação


em nuvem é o compartilhamento de recursos através de técnicas de virtualização, destaforma usuários mal intencionados podem criar múltiplas contas em nuvens publicas ou atémesmo privadas para gerar trafego de negação de serviço a sistemas ou hosts [61].

Alliance [54] chama a atenção em relação a custos financeiros que pode ser cobrado amais, uma vez que durante um ataque de negação de serviço o consumo de recursos aumenta,desse modo o dono da máquina terá gastos adicionais, pois em nuvens normalmente acobrança é baseada na utilização dos recursos.

Ao afetar a disponibilidade de serviços a insatisfação dos clientes do mesmo cresceconsideravelmente, uma vez que um sistema comprometido podem ficar lento e até mesmofora do ar enquanto o mesmo estiver sob ataque, diminuindo então a credibilidade doprovedor.

2.2.4.6 Usuário mal intencionado

Usuário mal intencionado pode ser um empregado, parceiro ou terceirizado de umaempresa em que lhe é permitido o acesso a recursos internos da nuvem, como sistemas decontrole, rede, dados e etc, e de forma intencional atua a afetar os princípios fundamentaisda segurança da informação em uma organização [62].

Duncan, Creese e Goldsmith [63] descrevem em seu trabalho alguns atores quepodem assumir o papel de usuários mal intencionados dentro de um ambiente de nuvem.Este indivíduo pode estar atuando junto a algum cliente do serviço de nuvem, pode estartrabalhando diretamente dentro da empresa que oferece o serviço ou até mesmo estando noprovedor de Internet, capturando dados de transações nas quais não estejam devidamenteprotegidas.

Quando o usuário mal intencionado está dentro da empresa, os danos causados aorganização podem ser inestimáveis, pois possuem acesso físico às máquinas, onde estãoimplementados os hipervisores, podendo comprometer dados de grande quantidades declientes.

2.2.4.7 Abuso dos serviços da nuvem

A escalabilidade proveniente em nuvem é uma das principais vantagens destatecnologia, permite ao cliente pagar apenas aquilo que consumir, desta forma qualquerusuário pode obter grande poder computacional oferecido pela nuvem apenas pagandopela utilização [54].

A risco de usuários utilizarem recursos que estão sobre seu controle providos pornuvens para fins ilícitos é alta, seja para distribuição de malware, software pirata e atémesmo criar ataques DDoS. Esta ameaça impacta em grande parte o provedor da nuvem,pois é de sua responsabilidade coibir este tipo de ação [64]. A detecção desta prática por


parte do provedor é extremamente complicada, na maioria dos casos esses abusos não sãodetectados instantaneamente, geralmente só apos diversos ataques serem realizados [65].

2.2.4.8 Investigação insuficiente

Vulnerabilidade associada ao fato empresas optarem por migração de seus sistemaspara ambientes de nuvem sem o devido conhecimento das características específicas doambiente de nuvem do provedor a ser contratado. Geralmente esto se da em função dapressão das organizações para adoção muito cedo do ambiente de nuvem [54].

Na pressa de se tornar a pioneira em determinada área, empresas acabam por deixa-rem de lado questões fundamentais para adoção de uma tecnologia, aspectos relacionadosaos acordos legais com o provedor do serviço de nuvem por exemplo, que no futuro podegerar conflitos sobre as responsabilidades de ambas as partes, como se dará a proteção dosdodos, a disponibilidade dos serviços, dentre outros tantos que devem ser analisados antesde uma migração [64].

2.2.4.9 Vulnerabilidades de recursos compartilhados

O compartilhamento de recurso é um dos pilares da computação em nuvem, destaforma é possível que diferentes aplicações possam ser executadas simultaneamente dentrode um mesmo servidor, os dados trafeguem em uma mesma rede, estejam armazenados nomesmo disco, permitindo então dividir os custos de infraestrutura entre seus clientes [54].

O alvo de um ataque de recursos compartilhados é o hipervisor, que é o softwareresponsável por gerenciar as instâncias de máquinas virtuais, pois ao compromete-lo umusuário mal intencionado obtém o controle de todas as máquinas virtuais locais.

Dawoud, Takouna e Meinel [66] em seu trabalho distinguem as ameaças a umamáquina virtual quando parte do servidor de virtualização, ou seja, o hospedeiro dohipervisor. Possui a capacidade de monitorar as informações das máquinas virtuais, tantocomo a comunicação que ocorre entre as demais máquinas que estejam virtualizadas. Existea possibilidade de ameaças serem providas de outra máquina virtual no mesmo hipervisor,tentando monitorar ou interceptar a comunicação da outra através da rede interna. Outraameaça é a relacionada a mobilidade das máquinas virtuais, que por possuírem mecanismosde migração um usuário mal intencionado pode comprometer a integridade das mesmasdurante este tipo de operação.

2.3 Sistemas de Detecção de IntrusãoSistemas de detecção de intrusão são comumente citados na literatura com a sigla

IDS (Intrusion Detection Systems). Segundo [67], o IDS é considerado uma das soluções


de segurança mais eficazes para resistir ameaças de usuários mal intencionados.

É um processo de monitoração de eventos ocorridos em uma rede ou sistema decomputadores, as suas analises serve para detectar sinais de intrusão, ou seja, tentati-vas de comprometer pilares da segurança da informação, confidencialidade, integridade,disponibilidade.

Os objetivo principal de um IDS é identificar indivíduos que tentam utilizar umdeterminado sistema ou participar de uma rede de computadores de forma não autorizadaou desejando obter privilégios além dos concedidos aos mesmos [68].

Uma boa analogia aos sistemas de detecção de intrusão é encontrada ao compará-loscom um alarme em uma casa. Antes de viajar, a casa é trancada para proteção dos objetosde valores, através do uso de fechaduras, correntes, cadeados, etc. Essa segurança podeapresentar um efeito negativo se for permitida ao ladrão a liberdade para testar chaves emcadeados e serrar as correntes. Para resolver esta vulnerabilidade, o proprietariado optarpor adicionar alarmes e câmeras de segurança em pontos estratégicos. Qualquer tentativade invadir o imóvel, vigias serão alertados automaticamente pelo sistema de segurança [69].

Para [68], independente de sua classe, um IDS apresenta três componentes funda-mentais:

• Sensor: Responsável por coletar as informações da rede ou sistemas;

• Analisador: Possui a função de analisar os dados capturados, e através da análiseindicar se ocorreram ou não intrusões

• Interface de usuário: Forma organizada de apresentação dos dados coletados eanalisados aos administradores.

2.3.1 Métodos de Coleta

2.3.1.1 Host-based Intrusion Detection (HIDS)

OS HIDS foram os primeiros tipos de IDS a serem implementados [70]. Atuaapenas sobre um único host, descartando os demais participantes da rede. Normalmente asinformações coletadas são provenientes de arquivos de log, tanto logs criados pelo kerneldo sistemas operacional, como por outras aplicações, e pode monitorar também o trafegode redes, buscando conexões irregulares, falsas, ou que caracterizem como uma possíveltentativa de invasão [71].

Os HIDS possem a vantagem de poder detectar ataques locais, que não poderiamser detectados através rede. No entanto exigem instalação e manutenção constante, umavez que o próprio HIDS pode ser alvo de ataques, afim de diminuir sua capacidade dedescoberta de instruções, além de interferir no desempenho do host [72].


Segundo [71], a taxa de falsos-positivos apresentas pelos HIDS são menor em relaçãoaos outros tipos de IDS, e apresentam como principais aspectos negativos os seguintespontos:

• Necessário a instalação e configuração para a máquina na qual deverá ser observada,exigindo uma carga adicional para o host;

• A confiabilidade da capacidade de analise do IDS, é exercidas individualmente, sobrecada host na qual se encontra instalado;

Ao utilizar estes tipos de IDS em ambientes de Nuvem, pode-se escolher aplicá-lotanto sobre as VMs como nos hipervisores. Ao ser instalado na VM, a responsabilidade docontrole e manutenção do processo é transferida ao usuário. Caso os hipervisores sejamescolhido para suporte do IDS, a responsabilidade recaem sobre o provedor do serviço denuvem [3].

2.3.1.2 Network-based Intrusion Detection (NIDS)

Tipo de IDS que coleta informações do tráfego da rede, na tentativa de identificarpossíveis ataque. Possuem dois modos de implantação, modo inline e modo passivo. Nestaabordagem o NIDS é posicionado em um ponto especifico da rede, e atua diretamente notrafego corrente, capturando pacotes para detectar uma intrusão. No modo passivo ele éposicionado sobre um centralidade de rede, por exemplo uma switch, na qual os pacotesde redes são copiados e só posteriormente analisados [69].

Para detectar ações maliciosas na rede, o NIDS pode utilizar como base o compor-tamento atual do usuário com comportamentos já observados anteriormente e consideradosnormais, pode analisar os cabeçalhos dos pacotes, ou optar por utilizar de detecção deintrusão baseado em assinaturas de ataques já conhecidos [3].

Algumas vantagens dos NIDSs são descritas por [72], que citam por exemplo, acapacidade de serem transparente para o atacante, uma vez que se encontra externamenteao host vítima, são facilmente implementados sem que interferiram no desempenho doshosts e possui independência de plataforma, pois atuam apenas sobre os pacotes de redes,descartando informações de aplicações internas aos hosts e dos sistemas operacionaisinstalados que possam ter sido corrompidas por atacantes.

Por outro lado, algumas desvantagens dos NIDSs estão em tratar dados de redesde alta velocidade; dependência da rede e dos dispositivos, e a dificuldade em tratar dadoscriptografados. Por não interferir no fluxo da rede, existe a dificuldade em reagir a umataque.

Alguns aspectos que são considerados como negativos em relação ao NIDS deacordo com [1] são:


• O tráfego total da rede não é monitorado, somente nos pontos em que estes estejamposicionados;

• Podem gerar congestionamento da rede (variando de acordo com a estratégia deanálise utilizada), isso de dará deivdo a trafego em larga escala e analise limitada depacotes por vez;

• Aponta simplesmente inicio ou possíveis ataques, não reconhecendo por exemplo seum ataque foi realizado com sucesso;

• Dificilmente pode detectar ataques com dados de pacotes criptografados.

O NIDS pode ser implantado diretamente no servidor de Nuvem, nas conexões comredes externas, no entanto, os ataques de origem da rede interna, ou seja da rede virtualizadautilizada pelas VM’s, não serão detectados. No contexto de Nuvem, a responsabilidade doNIDS é de inteiramente do provedor [47].

2.3.1.3 Distributed Intrusion Detection System (DIDS)

Quando um IDS é composto por vários IDS, todos do mesmo tipo ou não, porexemplo apenas HIDS, apenas NIDS, ou até mesmo uma combinação destes, no decorrerda infraestrutura rede nos os quais estejam interconectados entre si, e a um servidor central.Este modelo de IDS colecta informações sobre a rede e sistemas hosts e utilizam protocolosde comunicação pré-definido para troca de mensagens entre os demais IDS’s, ou enviam asinformações ao analisador central, na qual este componente pode analisar informações devários IDS simultaneamente [47].

Os DIDS em ambientes Nuvem, podem ser dispostos nas máquinas virtuais ou noshipervisores. Um exemplo desta abordagem pode ser utilizando agentes cooperativos, naqual cada agente é posto em um componente ou ponto da Nuvem [3]. Qualquer trafegomaliciosos que seja detectado, o agente responsável por essa descoberta pode divulgaralertas ao demais.

2.3.1.4 Híbridos

Pode ser optar por utilizar IDS de tipos de diferentes, por exemplo NIDS, HIDS eDIDS, na tentativa de ampliar o poder de analise e detecção de ataques. Atualmente écomum que os IDS implementem técnicas de HIDS e NIDS simultaneamente [67].


2.3.2 Estratégias de Análises

2.3.2.1 Baseado em Assinaturas

IDS baseado em assinaturas, aplica-se uma técnica onde padrões de ataques jáconhecidos são utilizados na detecção de ações de usuários mal intencionados. O padrão quecorrespondente a um tipo de ataque é denominado de assinatura. A camada responsávelpor analisar as informações coletadas, compara os dados com uma base de assinaturas,buscando assim identificar um ataque [73].

Ataques que desconhecidos, ou que não possuam uma assinatura equivalente nabase dados não serão detectados, então é se faz necessário uma constante atualização dasassinaturas, a medidas que novos padrões de ataques sejam determinados. A facilidade demodificações e atualizações de assinaturas, é umas das principais razões que motivam ouso deste tipo de estratégia [70].

[74] destaca como vantagem desse método, o fato de consumir menos recursoscomputacionais para detecção de ataques em relação as outras técnicas, uma vez se suaanalise é baseada em condicionais booleanas, ou seja, o comportamento em questão possuias características de um ataque ou não, desta forma o processamento pode ser otimizado eo número de falsos positivos é diminuído.

Ao utilizar este tipo de IDS, é exigido um determinado nível de conhecimento aosresponsáveis por criação e modificação das assinaturas, e a necessidade de atualizaçãoconstante também é apontada como desvantagem, pois o sistema não se adapta a compor-tamentos estranhos de forma autônoma. Outra desvantagem é que ações normais possamse assemelhar a atividades suspeitas, gerando um grande número de falsos positivos até asua atualização [74].

2.3.2.2 Baseado em Comportamentos

Estes tipos de IDS, realizam a captura de dados relativos ao comportamento dosusuários legítimos do sistema durante um determinado período, desta forma cria-se umperfil de uso [47].

Os dados coletados são utilizados como base no monitoramento das atividadesrealizadas por este mesmo usuário, qualquer alteração de comportamento é classificadocom uma anomalia, gerando alertas ao administrador do sistema [72].

A principal vantagem dos IDS baseado em comportamentos, é sua capacidade dedetectar novos ataques pelo simples desvio de comportamento, descartando o trabalhode manutenção de assinaturas, contento padrões de ataques ja conhecidos. Umas dasdesvantagens que pode ser citada, é fato de apontar como ataques, qualquer modificaçãono comportamento de usuários legítimo, podendo gerar um alto número de falsos alertas.


A criação dos perfies de usuários, podem ser difícil e extensa, principalmente em ambientesque o tipo de atividades exercidas mudam constantemente [72].

2.3.3 Técnicas de Análises

2.3.3.1 Utilizando Dados Estatísticos

Os IDS baseados em comportamentos são grandes utilizadores da detecção com baseem estatística, uma vez que os perfis que representam, por exemplo, o comportamento deuma rede, é composto por diversas métricas, como o número de pacotes, total de conexões,endereços de IPs envolvidos nas conversações, dentre outras. Eventos que não se enquadramno perfil, o IDS atribui uma pontuação para determinar se o evento é irregular. Estaanálise pode ser univariada, ou seja, uma variável é dividida em intervalos e frequênciasou multivariada, onde se considera as correlações entre duas ou mais métricas [69].

Modelos de séries temporais, este é outra técnica que se baseia no uso de intervalode tempo em conjunto a um contador de eventos, se a ocorrência de diversos eventosdurante esse intervalo possuir uma frequência acima do esperado, serão apontados comoeventos anômalos [75].

Esta técnica possui algumas vantagens, como por exemplo, não exigir conhecimentoprévio da atividade normal, pois o próprio método aprende o comportamento do sistemaa partir de observações. Esses métodos baseados em estáticas podem detectar até mesmoatividades maliciosas que ocorrem durante longos períodos de tempo. Entre as desvantagensé destacado a possibilidade de treinar esses IDS de forma que ataques sejam classificadoscomo uma atividade normal, não esquecendo a dificuldade em atribuir valores aos diferentesparâmetros de entrada para as funções matemáticas, pois nem todos os comportamentospodem ser modelados por processos estocásticos [76].

2.3.3.2 Utilizando Conhecimento

IDS trabalha no conceito de sistemas especialistas, na qual devem filtrar e classificaros dados que lhes estejam disponíveis, de acordo com um conjunto de regras. Em casode IDS baseados em assinaturas, as regras ja estão prontas, o administrador do sistemaadiciona já da forma em que o IDS deverá utilizar. Os IDS baseados em anomalias, devemcriar seus próprios padrões, primeiro criam se perfil de uso mediante o comportamentodos usuários em um contexto, posteriormente as variações que por ventura ocorram, serãoclassificadas como anomalias de comportamento. Desta forma o IDS utiliza apenas oconhecimento já obtido, não se modifica autonomamente com o decorrer do tempo oumediante modificações no ambiente [69].

[76] aponta como vantagens desse tipo de IDS, a sua robustez e flexibilidadepermitida em relação a modificações das regras, e como principal desvantagem, o fato


de ser dificultoso e podendo ser demorado o processo de desenvolvimento de base deconhecimento para o IDS.

2.3.3.3 Utilizando Aprendizagem de Máquina

IDS que encapsulam técnicas de aprendizagem de máquina, são previamentemunidos de padrões categorizados de comportamentos que são classificados como maliciosos.Como visto anteriormente esses padrões podem ser criados através de assinaturas de ataquesjá conhecidos ou com perfil de uso, obtidos através da observação durante um períodode um determinado contexto. Esta técnica utiliza conhecimento, porém se diferenciada técnica anterior, por sua capacidade de adquirir conhecimento de forma dinâmica, amedida que novas informações vão sendo coletados e analisadas. O IDS possui capacidadede classificar uma mudança de comportamento dentro de um ambiente, como atividadenormal, mesmo esta não tendo sido previamente adicionada a base de padrões [69].

2.3.4 Quanto a Arquitetura

2.3.4.1 Centralizada

Nesta arquitetura podem existir um ou mais sensores, responsáveis por coletar asinformações, tanto de sistemas, como hosts ou redes, porém a análise é realizada em apenasum único ponto central, todos os sensores enviam as informações a serem analisadas paraum único responsável [77].

A vantagem a ser destacada se dá em função de centralizar o armazenamento ea análise dos eventos, o que permite ao administrador do sistema acessar a informaçõesgeradas pelo IDS em um único local, no entanto para um melhor funcionamento, énecessário que o este sejam posicionado em ambientes onde o volume e a frequência doseventos são baixos. As desvantagens principais estão relacionadas as escalabilidade, poiso servidor central provavelmente sofrerá gargalos para analisar todos os dados geradospelos sensores, além de possuir apenas um ponto de falha, o que facilita os trabalho dosatacantes, pois podem direcionar seus ataques a um único alvo, acarretando problemas atodo o IDS [78].

2.3.4.2 Descentralizada

Arquitetura na qual prover que tanto os dados são coletados de maneira distribuídacomo a análise aplicada será de forma distribuída. Apresenta diversas vantagens tais comoescalabilidade, permite que o IDS seja tolerante a falhas, dentre outras [69]. A lista abaixoapresenta os tipos mais comuns com análise descentralizada:

• Hierárquica: Sensores e analisadores estão hierarquicamente dispostos, na qual osanalisadores encontram-se na camada mais a cima e me menor número em relação aos


sensores. Os sensores são espalhados nos pontos estratégicos da rede, as informaçõescoletadas são então enviadas a qualquer um dos analisadores disponíveis [79,80];

• Multiagentes: De forma geral, um agente definido como uma entidade de software,que possui comportamentos e capacidade de aprendizagem, que em comumenteutilizam técnicas de inteligência artificial, daí o termo agentes inteligentes [73].Sistemas que utilizam um conjunto de agentes na quais interajam entre si a fim derealizarem alguma tarefa, são denominados de Sistemas Multiagentes (SMA). Segundo[68], IDS Multiagentes representam uma nova geração de sistemas de detecção deintrusos, pois neste modelo os agentes podem atuar como IDS’s independente. Notrabalho de [68], é descrito diversas vantagens em usar agentes em IDS, abaixo éapresentado algumas destas:

– São entidades autônomas que trabalham de forma independente aos demaisagentes, desta forma um agente pode ser adicionado, modificado ou removidodo sistema, sem alterar o comportamento dos outros;

– Permite organizar os sistemas de forma hierárquica, dividindo os agentes emcamadas, tornando-o assim facilmente escalável;

– Cada agente pode ser implementado em uma linguagem de programação distinta,o que torna possível utilizar aquela mais adequada a tarefa que deverá serexecutada.

• Correlacionadores de Eventos: Objetiva-se a coletar o maior número de dadospossíveis, de vários ambientes, podendo até mesmo utilizar vários IDS independentes,na qual esse dados serão correlacionados, buscando identificar atividades maliciosas,desta forma é permitdo também a fusão dos eventos para reduzir o número de alertasgerados ao administrador [81]. O correlacionamento de informações é uma técnicaeficaz, que permite identificar ataques que não poderiam ser detectados por IDS’sde forma isoladas, porém pode se tornar lento e ineficiente quando não é otimizado,uma vez que o número de informações coletadas poderá ser em grande volume [69].

2.4 Tolerância a FalhasSistemas com poder tecnológico de maior desempenho e mais sofisticados são

complexos, pois em sua execução englobam diversos processos, que são realizados porcomponentes variados. Devido a extensão de elementos envolvidos no clico de vida de umsistema ser em grande número, é permitido então um aumento na possibilidade eventuaisfalhas, logo conclui-se que à a necessidade de permitir que sistemas possam apresentar acapacidade de lidar com estas falhas, tornando-os assim mais seguros [6].


A Tolerância a falhas é um conjunto de técnicas que são utilizadas na detecção,mascaramento e ações de correção que devem ser aplicadas a falhas em sistemas. Tem oprincipal objetivo de permitir que sistemas alcancem dependabilidade, isso implica que adisponibilidade e qualidade do serviço fornecido não será interrompido mediante a detecçãode falhas [82,83].

Para o desenvolvimento de sistemas que sejam tolerantes a falhas, antes é necessárioa compreensão deste conceito, bem como entender os causadores deste comportamentoanômalo. Segundo [6] Em um sistema os níveis de percepção são três: falhas, erros edefeitos.

Weber [83] apresenta alguns conceitos para nos ajudar na compreensão deste trêsníveis de percepção. Define um defeito como um desvio da especificação aplicada, afirmandoque defeitos não podem ser remediados, por isso devem ser evitados. Descreve que umsistema está em estado de erro se o processamento posterior a partir desse estado ser geradoou implicar em um defeito. Por fim conceitua falha como a causa física ou algorítmica doerro.

Uma das principais dificuldade encontrada no processo de implementação detolerância a falhas é a imprevisibilidade de ocorrência das falhas e os efeitos posterioresgerados ao sistema [82]. Antes que as funcionalidades de relacionadas a capacidade de lidarcom falhas sejam utilizas, é necessário que ocorra a detecção de erros, ou seja resultadosde falhas. Mediante esta detecção o sistema pode ser capaz de realizar ações de formaautônoma, na quais busquem de permitir ao sistema sua reconfiguração e remoção dafalha, gerando assim maior confiança aos usuários do sistema. Este processo é chamado derecuperação de erro.

56

3 Trabalhos Correlatos

Este capítulo apresenta os principais trabalhos relacionados a sistemas de detecçãode intrusão aplicados em ambientes de nuvem.

3.1 EICIDSO projeto EICIDS (Elastic and Internal Cloud-based Intrusion Detection System)

foi apresentado por [84], seu objetivo é garantir a segurança aos usuários de computaçãoem nuvem no nível de infraestrutura (IaaS). Para garantir a segurança das instânciasde máquinas virtuais da nuvem, o EICIDS captura e analisa o tráfego diretamente nosswitchs virtuais utilizados pelos hipervisores. Foi desenvolvido sobre o conceito de módulosde softwares, desta forma permite que componentes sejam processados e modificados deforma independente.

EICIDS possui uma arquitetura centralizada e utiliza assinatura de ataques conhe-cidos para detecção de trafego malicioso, tanto de usuários internos como usuários externos.Dividi-se em 2 componentes principais que são: IDS_Admin e IDS_Node, que por suavez se subdivide em 4 partes: Netsensor, IDS_Analyser, IDS_Pool, IDS_Reaction. Asdefinições de cada um destes componentes bem como sua responsabilidade estão descritasa seguir [84]:

• IDS_Admin: Componente central que possui a responsabilidade de coordenar oprocesso de detecção de intrusão através da integração dos demais componentes.Também cabe a este módulo o papel de organizar, sumarizar e apresentar alertas desegurança emitidos pelos os IDS_Node, visando facilitar o trabalho do administradordo sistema;

• IDS_Node: Possui como tarefa principal instanciar e desativar sensores e ana-lisadores, mediante o número de máquinas virtuais e seus respectivos estados. Éresponsável por receber alertas de segurança gerados pelos analisadores e repassarao IDS_Admin;

• IDS_Pool: Monitora constantemente o ambiente de Nuvem, verificando os esta-dos das máquinas virtuais, sempre que uma modificação no estado é detectada, oIDS_Node é notificado. Este módulo objetiva-se a auxiliar na elasticidade do IDS;

• IDS_Sensor (Netsensor): Responsável por capturar os pacotes de dados quetrafegam na rede, e enviá-los ao IDS_Analyzer. Atua de forma passiva, ou seja,maquinas virtuais não sabem que os pacotes estão sendo capturados;

Capítulo 3. Trabalhos Correlatos 57

• IDS_Analyzer: Recebe os pacotes capturados pelo IDS_Sensor, e os analisabuscando identificar comportamento anormal comprando as informações com a basede assinaturas do IDS;

• IDS_Reaction: O objetivo do IDS_Reaction é aplicar uma contramedida a umcomportamento que seja classificado como malicioso pelo IDS_Analyzer. A ação quedeve ser realizada varia de acordo com o ataque detectado.

As figuras 9 e 10 apresentam a arquitetura do IDS descrito acima.

Figura 9 – Arquitetura EICIDS com nó único. Fonte: Adaptado [84]

3.2 SDIMINO modelo de detecção de intrusos proposto por [47] SDIMIN (Sistema de Detecção

de Intrusão Multiagentes para Infraestrutura de Nuvens), é baseado na colaboração entreagentes inteligentes, e possui objetivo principal inibir comportamentos que buscam afetar adisponibilidade de serviços, utilizando assinaturas de ataques já conhecidos no seu processode detecção.

A arquitetura do SDIMIN é distribuída e composta por 5 partes fundamentais,que são: Monitoramento, Análise e Controle, Armazenamento e Administração. A seguir édescrito a responsabilidade de cada um desses componentes [47]:


Figura 10 – Arquitetura EICIDS com múltiplos nós. Fonte: Adaptado [84]

• Camada de Monitoramento: Composta por grupos de agentes que atuam captu-rando pacotes de dados que trafegam dentro do ambiente virtualizado pelo hipervisor.Visa coletar o máximo de pacotes de E/S (Entrada e Saída) e filtrá-los por protocolo(ex: TCP, UDP, ICMP, etc.). Para cada instância de máquina virtual em execuçãohaverá um agente desta camada;

• Camada de Análise: Conjunto de agentes responsáveis por receber, organizar,formatar e com as assinaturas de ataques existentes na base de conhecimento doIDS, aos pacotes coletados pela camada de monitoramento. Assim como na camadade monitoramento, cada instância de máquina virtual em execução também haveráum agente desta camada;

• Camada de Controle: Principal camada deste modelo, dentre suas diversas ati-vidades, podemos destacar a responsabilize de instanciar ou desativar agentes dascamadas anteriores, mediante as variações dos estados das máquinas virtuais, garan-tindo assim elasticidade ao IDS. Destaca-se também o papel de aplicar medidas desegurança, visando interromper comportamentos malicioso. Através dos agentes destao administrador do sistema gerencia o status e a configuração dos agentes da camadade análise e monitoramento. Por ser tratar de um IDS de arquitetura distribuída,cada servidor de virtualização conterá um agente desta camada, funcionando deforma independente dos demais;

• Camada de Armazenamento: Nesta camada encontram-se repositórios de dadoe que são classificados em:

1. Base de Comportamentos: Responsável por armazenar ações de atividadesmaliciosas para fins de inspeção e possível alimentação da base de assinaturas;

2. Base de Assinaturas: Responsável por armazenar as assinaturas de ataquesconhecidos. Pode ser atualizado dinamicamente baseado nos comportamentos


adquiridos no decorrer da execução do sistema ou de acordo com as políticasde cada provedor de Nuvem;

3. Base de Contramedidas: Armazenar as ações de segurança que devem seraplicadas, variando de acordo com a o ataque detectado. Varia de acordo comas políticas de cada provedor de Nuvem e deve ser constantemente atualizadapara garantir que novas técnicas de ataques sejam neutralizadas;

• Camada de Administração: Responsável por interagir com o agente humanoatravés de uma Interface de comunicação com os agentes da camada de controle,de forma que permitam a realização de tarefas como: Ativar ou desativar agentese aplicar modificações de dados na camada de armazenamento (comportamentos,assinaturas e contramedidas).

Na Figura 11 apresenta a arquitetura deste IDS.

Figura 11 – Arquitetura geral SDIMIN. Fonte: [47]

3.3 GCCIDSNo trabalho [85] é proposto um um sistema de detecção de intrusão distribuído para

ambientes de computação em Nuvem, denominado GCCIDS (Grid and Cloud ComputingIntrusion Detection System), utiliza técnicas de redes neurais artificiais juntamente comassinaturas de ataques já conhecidos. O autor ressalta que o fato de nuvens serem ambientesdistribuídos e geralmente em grande escala, atraem um maior número de usuários mal


intencionados, gerando diversos tipos de ataques distintos, logo uma combinação demétodos diferentes no processo de detecção utilizado pelo IDS, possam surtir efeitos maiseficazes em relação aos IDS que adotam apenas um único tipo.

O GCCIDS propõem a cooperação entre os serviços fornecidos por componentespertencentes ao sistema de detecção, possibilitando analisar eventos de forma individualem cada nó da nuvem, como tráfego de rede, modificações em configurações de serviços,arquivos de logs, etc., que por ventura possam ser classificadas como atividades suspeitas,visando causar danos locais ou a outros nós da nuvem.

Os componentes do IDS são distribuídos pelo ambiente da nuvem e atuam de formatotalmente independente, nas quais compartilham as informações geradas entre si. Umacamada de middleware garante que a comunicação ocorra sem a necessidade de considerarquestões da plataforma utilizada em cada nó. Na Figura 12 é demostrado a arquiteturadeste IDS.

Figura 12 – Arquitetura geral GCCIDS. Fonte: [85]


A lista abaixo descreve a responsabilidade dos componentes principais que compõema arquitetura do GCCIDS [85]:

• Gride Node: Contém os recursos que devem ser acessados de forma homogêneaatravés do encapsulamento provido pelo Middleware;

• Services: Atua integrando as funcionalidades disponíveis nos componentes e facili-tando a comunicação entre os nós da nuvem que estejam sendo monitorados;

• Event Auditor: Responsável por capturar de dados que possam ser utilizados paradetecção de anomalias, tais como: arquivos de logs, conexões de rede, massagem deoutros nós, etc.;

• Storage Service: Responsável por armazenar dados que serão utilizados paraanálise, de forma a garantir que estes estejam disponíveis a todos os componentespertencentes ao IDS;

• IDS Service: Realiza a análise dos dados persistidos pelo Storage Service, utilizandométodo de detecção com base nos comportamentos dos usuários e no conhecimentode ataques anteriores.

3.4 MAIDPSComo resultado de sua pesquisa, [86] propõem um sistema de detecção e prevenção

de intrusão multiagentes, intitulado como MAIDPS (Multi-Agent Intrusion Detection andPrevention System), para ser aplicado em contexto de nuvens, na qual em seu processo deanalise utilia tecncias baseads em anomalis de comportamento e assinaturas de ataques jaconhecidos. Possui o objeito de identifcar e coibir ataques do tipo:

1. Mascarados: Ameaças geradas por usuários legítimos e autenticados que sejampertencentes a nuvem;

2. Baseados em Host: Comportamento anômalo não intencional realizado por determi-nado host da nuvem, na qual este esteja de alguma forma comprometido;

3. Baseados em Rede: Ataques que buscam conseguir acesso ou afetar a disponibilidadede host ou serviços através da rede.

O modelo proposto é constituído por agentes de software que compõem um ambientede execução do tipo Agente Runtime Environment (ARE), este componente é responsávelpela criação e destruição dos agentes, mediante as necessidades do ambiente. A trocade informações entre os agentes pertencentes ao IDPS será realizada por um esquema


baseado em eXtensible Markup Language (XML), denominado Intrusion Detection MessageExchange Format (IDMEF), já no processo de comunicação com o cliente o compoenteutilizado será o Client Agent Runtime Environment (CARE). Na Figura 13 é demostradoa arquitetura deste MAIDPS.

Figura 13 – Arquitetura geral MAIDPS. Fonte: [86]

Abaixo está descrito o papel dos componentes principais que compõem a arquiteturado MAIDPS [86]:

• Knowledge Data Table (KDT): Armazena os padrões de assinatura de malwareja conhecidos, porém pode ser atualizado dinamicamente pelo UA, após detectarcomportamento anormal e que possa ser gerada uma nova assinatura de ataque;

• Behavioral Data Table (BDT): Armazena os padrões de comportamentos classi-ficados como normais que são gerados e atualizados pelo UA. A classificação destescomportamentos é realizada através da aplicação de algoritmos que implementamlógica difusa;

• Smart Agent (SA): Agente inteligente presente no nó do cliente ou em um nó quepertencente a Nuvem. Atua investigando o comportamento do usuário e as atividadessuspeitas, que possam ser classificadas como anormais;


• Verifier Agent (VA): Responsável por verificar a identidade do SA antes dos dadosserem enviados ao IDPS, de forma que permita apenas aos agentes autorizados ocompartilhamento de informações;

• Update Agent (UA): Responsável por atualizar novas assinaturas de malware oupadrões de comportamento no KDT e BDT;

• Analyzer Agent (AA): Possui a tarefa de analisar pacotes a procura de ataque oucomportamentos que não sejam classificados normais, utilizando técnicas de lógicafuzzy neste processo;

• Event Signaling Agent (ESA): Possui a responsabilidade de receber os alertasemitidos pelo AA e reportar ao administrador do sistema, permitindo analisar agravidade do ataque e definir a medida preventiva a ser aplicada;

• Smart Malware Detection Agent (SMDA): É um agente inteligente que executaem intervalos de tempo pré definidos no sistema que hospeda o IDPs, buscandoidentificar processos ou ações de malware que possuam como alvo o próprio IDPs.

3.5 NICEA arquitetura de IDS NICE (Network Intrusion Detection and Countermeasure

Selection in Virtual Network Systems) foi apresentada por [87], baseia-se em uso de modelosanalíticos de grafos para detecção de ataques e realiza modificações nas configurações dasredes virtuais como reação a comportamentos maliciosos. Possui como principal objetivocoibir tentativas de comprometimento das instâncias de máquinas virtuais, de forma queestas não sejam utilizadas de forma involuntária em ataques distribuídos de negação deserviços. Quando em execução o NICE contempla duas tarefas principais:

• Inicialmente implementa-se um agente de detecção de intrusão (NICE-A) em cadaservidor da nuvem, de forma que permita a captura e analise do tráfego da rede. Combase nas informações coletadas são gerados Scenario Attack Graph (SAGs), na quaisserão utilizados na identificação de ataques e posteriormente na classificação da suagravidade. Tendo esses gráficos como base, o NICE irar decidir se uma instância demaquina virtual comprometida deve ser ou não modificada para o estado de inspeçãoda rede;

• Ao ser modificada para o estado de inspeção, o Deep Packet Inspection (DPI) éaplicado e ocorre então a reconfiguração da rede virtual em uso na VM comprometida.Esta ação tem como objetivo permitir que seja realizado a analise do comportamentode possíveis ataques diretamente no host comprometido.


Na Figura 14 a arquitetura de detecção de intrusos proposta por [87] é apresen-tado, ilustrando a aplicação em apenas um único servidor de nuvem, e logo abaixo ascaracterísticas de cada componente estão discriminadas.

Figura 14 – Arquitetura geral NICE. Fonte: [87]

• NICE-A: Tipo de NIDS baseado no Snort, na qual encontra-se em cada hipervisor daNuvem. Atua capturando e analisando o tráfego no switch de rede virtual utilzandooentre as VMs;

• VM Profiling: Responsável por obter informações em tempo real sobre o estadodas VM’s, como detalhes de serviços, processos ativos, conexões de rede, etc.;

• Attack Analyzer: Componente central do NICE, possui a tarefa de analisar otráfego malicioso gerado por VM comprometida e então construir e atualizar ográfico de ataque, alem de definir quais medidas devem ser realizadas para inibiçãode ataques;

• Network Controller: Responsável por aplicar reconfiguração da rede virtual dentrodos hipervisores.

3.6 Análise Comparativa dos Trabalhos RelacionadosNa tabela 3, é apresentado um resumo comparativo das principais características e

funcionalidades disponíveis nos modelos descritos anteriormente.

Uma características fundamentais da computação em nuvem é a elasticidade,mecanismo na qual permite maior dinamismo a alocação de host e serviços, no entantoapenas os modelos EICIDS e SDIMIN disponibilizam funcionalidades que acompanhameste comportamento da nuvem, permitindo assim ao IDS alocar recursos para captura eanalise das informações das instâncias de maquinas virtuais de forma dinâmica e escalável.


Modelo Método de Coleta Estratégia de Ana-lise

Elasticidade ComunicaçãoSegura

Tolerância aFalhas

EICIDS Máquina Virtual Assinatura Sim Não NãoSDIMIN Máquina Virtual Assinatura Sim Sim NãoGCCIDS Host Assinatura e Com-

portamentoNão Sim Não

MAIDPS Host e Rede Assinatura Não Não NãoNICE Máquina Virtual Assinatura e Com-

portamentoNão Sim Não

Tabela 3 – Principais características dos trabalhos relacionados. Fonte: Autoria própria

Todos os modelos descritos acima utilizam diversos tipos de componentes, que serelacionam entre si, trocando informações de forma síncronas ou assíncronas, entretanto averificação da integridade e veracidade destes dados compartilhados são validadas apenasnos modelos SDIMIN, GCCIDS e NICE. Esta funcionalidade ajuda a garantir apenascomponentes que sejam autorizados e autenticados poderão participar do processo dedetecção de ataques.

Sistemas gradativamente estão se tornando mais comuns e importantes na sociedade,levando a um crescente estado de dependência destes, garantir que estejam sempre ativose disponíveis não é uma tarefa fácil, porém esforços devem ser aplicados buscando evitarprejuízos com paralisações temporárias ocasionadas por eventuais falhas. Ao analisarmosa tabela 3, podemos observar que nenhum dos modelos apresentados se atentam para esteaspecto, de modo que os IDS’s não possuem a capacidade de lidar que quaisquer tiposde eventuais falhas, não sendo capazes de se reconfigurarem automaticamente, provendoentão uma modificação de seu estado de execução sem a necessidade da interação humana.

A lista abaixo resume características que não são apresentas pela maioria dosmodelos citados:

• Elasticidade autônoma;

• Mecanismo de proteção para a comunicação entre os componentes;

• Tolerância a falhas.

66

4 Modelo Proposto

Este capítulo tem o como objetivo descrever os componentes persistentes daarquitetura proposta para um modelo de IDS baseado em SMA, tendo infraestruturas denuvem como contexto de aplicação.

4.1 Considerações IniciaisApós a análise de trabalhos relacionados, buscou-se moldar um esquema que

aproveitasse as principais características desejáveis e apresentasse melhorias aos aspectosclassificados como insatisfatórios, na tentativa de contribuir com soluções plausíveis aproblemas enfrentados em IDS para nuvens.

Para a composição da arquitetura uma hierarquia que agentes foi empregada,tendo suas naturezas de atividades aplicadas diretamente aos hipervisores da nuvem ou asmáquinas virtuais de forma individuais como mostrado na Figura 15, com esta abordagempretende-se facilitar o processo escalabilidade e manutenibilidade do modelo.

Figura 15 – Hierarquia de agentes e natureza de atividades por camada. Fonte: Autoria própria.

Ainda na Figura 15 podemos observar quatro grupo de atividades que se encontramdistribuída na hierarquia, a lista abaixo descreve resumidamente cada uma:

• Monitoramento (hipervisor): objetivo de observar e notificar modificações ocorri-das em relação aos estados de todas máquinas virtuais gerenciadas por um hipervisor;

• Monitoramento (máquina virtual): propósito de capturar todo o tráfego de redegerado ou que tenham como destino uma máquina virtual especifica;

Capítulo 4. Modelo Proposto 67

• Análise: tarefa de classificar as interações de redes capturadas como normal oumaliciosa;

• Controle: gestão das informações geradas pelos componentes, bem como garantiade funcionamento dos mesmos, englobando também os tipos de reações a seremtomadas caso um comportamento suspeito seja identificado.

Nas atividades para a análise dos pacotes de rede coletados, a metodologia de detec-ção de ataques por assinaturas conhecidas foi escolhida, isto se deu em função da maioriados ataques corriqueiros serem adaptações de ataques com características relacionadas,sendo possível detectar as variantes destes que exploraram as mesmas vulnerabilidadescom taxas de falsos-positivos inferiores quando comparadas outras abordagens.

A divisão de responsabilidades traz a necessidade de assegurar a veracidade eintegridade das informações as serem compartilhas entre os agentes das diferentes camadas,por isso uma combinação de tecnologias de criptografia simétrica, assimétrica e assinaturadigital foi utilizada com o intuito de garantir tais aspectos, tornando o sistema mais seguroe confiável.

4.2 Arquitetura dos ComponentesAs funcionalidades a serem apresentadas pelo modelo estará dividia em quatro cate-

goria de agentes distintos, onde poderão estar relacionado diretamente a uma instância demáquina virtual ou a um hipervisor especifico. Na Figura 16 os componentes participantessão apresentados.

A lista abaixo oferece a descrição individual dos componentes disposto na arquite-tura proposta:

• FilterAgent: Atividades relacionadas ao monitoramento do tráfego de rede envol-vendo uma instância de máquina virtual especifica, com o objetivo de coletar omáximo de pacotes tanto de entrada como saída que sejam relevantes para o processode detecção dos ataques, e posteriormente enviá-lo ao agente responsável pela análisedos dados;

• AnalyzerAgent: Responsável por receber, organizar e analisar os pacotes recebidos,realizando a detecção de comportamentos maliciosos com base nas assinaturas jaexistentes em seu repositório de conhecimento, e caso necessário uma notificação seraenviada ao ControllerAgent contendo uma descrição do ataque. Todos os pacotesrecebidos por esta categoria de agentes será de um único FilterAgent, uma vez queambos possuem suas atividades ligadas diretamente a uma máquina virtual de formaisolada;


Figura 16 – Arquitetura dos componentes. Fonte: Autoria própria.

• SnifferAgent: Tem como objetivo monitorar o hipervisor local, atentando-se asmodificações dos status das máquinas virtuais (ativa, inativa, suspensa, etc.) poreste gerenciadas, sempre que uma alteração for detectada, o ControllerAgent deveráreceber uma notificação contendo os dados relevantes desta mudança. Para cadahipervisor existirá apenas uma instância deste de tipo de agente em atividades porvez;

• ControllerAgent: A exemplo do SnifferAgent, este também haverá apenas umainstância em execução por vez para cada hipervisor, pois será o responsável porcoordenar o clico de vida dos agentes FilterAgent e AnalyzerAgent em função do statusda máquina virtual a eles atreladas. Possui também a responsabilidade de receberas notificações de ataques e aplicar a contra medida associada a uma assinatura deataque;

• Ações: Representa a base comportamentos associado a cada categoria de agente,cada repositório será compartilhado apenas com instâncias dos componentes quesejam de um mesmo tipo;

• Assinaturas 1: Abstração do repositório das assinaturas de ataques disponíveis paradetecção de comportamentos maliciosos, em tempo de execução apenas as instânciasde AnalyzerAgent deverão consultar esta base;

1 O administrador do sistema pode realizar modificações a base após analisar o trafego da rede, como oobjetivo de atualizar a lista de assinaturas, não exigindo a interrupção do sistema para esta tarefa.


• Reações 2: Abstração do repositório das ações a serem aplicadas de acordo com oataque detectado. Em tempo de execução apenas as instâncias de ControllerAgentdeverão consultar esta base;

• Camada de Agentes: Abstração da hierarquia de agentes utilizada. Na camada01 estão disposto os agentes que possuem suas atividades ligadas ao hipervisor local,na camada 02 os agentes que possuem atividades relacionadas as máquinas virtuais.Os componentes da camada 02 apenas serão inicializados após a execução e corretofuncionamento dos agentes da camada 01;

• Plataforma JADE: Middleware responsável por gerenciar o ciclo de vida dosagentes participantes e oferecer uma interface para a comunicação baseada em trocade massagem.

4.3 Elasticidade do ModeloTendo a elasticidade como uma das características fundamentais da computação

em nuvem, buscou-se adaptar a arquitetura proposta para suportar este comportamento.A hierarquia de agentes apresentadas acima foi criada com o objetivo de auxilar nestatarefa, tendo uma subdivisão em duas categorias:

• Agentes Estáticos: Os participantes desta camada são os primeiros a serem inicia-lizados e permanecem em execução enquanto os sistema estiver ativo, é exigido nomínimo uma instância de cada tipo de agente, mesmo que nenhuma máquina virtualesteja em atividade no hipervisor local;

• Agentes Dinâmicos: Estes dependem da camada superior (agentes estáticos) paraserem executados e trabalham em pares de tipos diferentes, desta forma um agentenão será mantido em execução sem seu respectivo díade. Só haverá instâncias deagentes deste nível quando o número de máquinas virtuais em atividade no hipervisorlocal for superior ou igual a 1.

Na Figura 17 é exemplificado como os componentes deverão se comportar quandomodificações nos estados das máquinas virtuais forem detectadas. Observa-se neste exemploque o SnifferAgent detectou duas modificações hipervisor local, que em um determinadomemento uma VM foi inicializada (VM X), em função disto uma notificação foi envia aoControllerAgent que por sua vez disparou o processo para criação do par de agentes queatuarão sobre esta máquina, já em um outro momento uma VM que estava em execução foi2 Assim como a base de assinatura, o administrador também pode alterar as ações a serem realizadas

em função de um ataque, isto permite que as regras sejam adaptadas para respeitar a politica desegurança utilizada pelo provedor.


inativada (VM Y), ao ser detectado isto pelo SnifferAgent outra notificação foi enviada aoControllerAgent, que realizou o processo inverso, invocado desta vez a rotina de remoçãodo par de agentes atrelados a esta VM.

Figura 17 – Esquema de elasticidade. Fonte: Autoria própria

4.4 Esquema de Tolerância a FalhasObservou-se nos trabalhos correlatos que nenhum propôs qualquer mecanismo de

tolerância a falhas, então a partir disso uma serie de possibilidades foram levantadas,buscando alternativas para uma possível contribuição que pudesse auxilar neste aspecto.A solução proposta tem como base a observação agentes participantes para determinaçãodo seu estado atual. A plataforma JADE oferece a interface para manipulação e realizaçãode comportamentos com base nas variações do ciclo de vida de forma transparente, ondeo container de execução se encarrega de processar as instruções determinadas para cadaestado especifico.

4.4.1 Agentes Estáticos

Como ja definido anteriormente, estes agentes possuem apenas uma instância decada tipo em atividade por vez para cada hipervisor da nuvem, e já que esta é camadamais acima na hierarquia a complexidade de detectar error aumenta, pois não existe umgrupo de agentes monitorando seus estados. Para resolução deste problema foi utilizada atolerância a falhas baseado em replicação de agentes, assim para cada componente ativode cada classe, existirá uma respectiva cópia, com o sufixo de substitute, este por sua vezapenas sera inicializado em conjunto com o sistema, porém só terá atividades atribuídasapós o componente principal falhar. A Figura 18 esboça o comportamento do sistema casoalgum agente principal apresente falha.

A plataforma JADE monitora os estados de todos os agentes ativo, como exemploinicial supomos que o ControllerAgent principal apresentou uma falha e que o levou


Figura 18 – Tolerância na camada estática. Fonte: Autoria própria

a mudar de estado, o container na qual os agentes se encontram em execução deveráenviar uma notificação aos SnifferAgent (principal e substituto) e todos os AnalyzerAgentque estejam em atividade, alertando para que as novas mensagens sejam direcionadas aoControllerSustitueAgent. A primeira notificação do SnifferAgent ao ControllerSustitueAgentserá informando que o ControllerAgent falhou e ele deverá assumir o papel de principal.Um comportamento similar será observado quando o SnifferAgent principal falhar, porémapenas os ContollerAgents serão notificados, já que são os únicos com quem este interage,essa notificação serve apenas para informar aos ContollerAgents que passem a utilizar ascredenciais corretas para verificação da integridade e validação das massagens recebidas (oesquema de segurança da troca de informações está descrito na próxima seção).

4.4.2 Agentes Dinâmicos

Os agente desta camada são controlados pelo ContollerAgent, desta forma a me-todologia utilizada para tratar eventuais falhas é mais simples quando comparada coma apresentada na camada superior. As instâncias de agentes participantes neste nívelsó operam se seu par estiver ativo, seguindo esta premissa o mecanismo é similar aodemostrado anteriormente, caso o container identifique falha em um ou mais componentes,uma notificação sera enviada ao ContollerAgent em atividade. A Figura 19 apresenta ocomportamento como o sistema deverá ser comportar caso algum agente apresente falhas.

Supondo que uma falha seja apresentada levando um FilterAgent a modificar seuestado, uma notificação será emitida ao ControllerAgent, que por sua vez ira remover orespectivo AnalyzerAgent, e só após um novo par de agentes com as mesmas definições seráinicializado. Este processo também ocorre caso um AnalyzerAgent falhe e mude de estado,porém o ControllerAgent irar eliminar o respectivo FilterAgent para então inicializar umnovo par exatamente igual.


Figura 19 – Tolerância na camada dinâmica. Fonte: Autoria própria

4.5 Modelo de SegurançaCom o objetivo de garantir a confiabilidade e integridade das mensagens comparti-

lhadas, foi elaborado duas estratégias para a utilização de chaves criptográficas, aplicandouma para cada camada de agentes. A lista a seguir descreve cada um dos planos:

• Chaves simétricas: Empregada na comunicação dos agentes estáticos, após ainicialização do sistema os participantes entrarão em um acordo para criação dechaves simétricas através do método Diffie-Hellman, onde uma chave distinta serágerada para cada fluxo de comunicação (Figura 20). Esta abordagem foi utilizadadevido os agentes deste nível quando em execução sem anomalias, apresentaremestados de vida continuo, desta forma exige-se um adicional de tempo inicial paraconcordância das chaves, porém este processo será efetuado uma única vez e seuresultado mantido até que o sistema seja reiniciado, onde novos acordos deverão serefetuados.

Figura 20 – Acordo de chaves simétricas. Fonte: Autoria própria

• Chaves assimétricas: Metodologia abordada na comunicação dos agentes dinâmi-cos. Cada agente estanciado será responsável por gerar um par de chaves, na qualsua chave publica será enviada ao ControllerAgent, onde este por sua vez responderáesta mensagem com sua chave publica, posteriormente os agentes dinâmicos deverão


repetir o mesmo processo de troca de chaves publica com o seu agente complementar(a Figura 21 apresenta um esboço deste esquema). Esta abordagem foi utilizada emfunção dos agentes desta camada poderem ter seu ciclo de vida em curtos períodos eexigirem o menor intervalado de tempo desde sua inicialização até o inicio de suasatividades, para o acompanhamento eficaz das modificações ocorridas na nuvem,por isso optou-se pela exclusão do acordo de chaves utilizando o Diffie-Hellman,desta forma garantir maior desempenho ao modelo porém sem diminuição do nívelde segurança.

Figura 21 – Troca de chaves públicas. Fonte: Autoria própria

74

5 Modelagem e Implementação

5.1 Visão GeralCom o objetivo de facilitar o entendimento sobre o modelo de IDS proposto alguns

recursos da UML foram utilizados, na qual inicialmente os diagramas de casos de usosforam concebidos, sendo auxiliado pela ferramenta astah comunity na etapa de desenhoe organização dos componentes. Segundo [88] este diagrama procura expor uma visãogeral das funcionalidades que o sistema deverá oferecer aos utilizadores, descartando anecessidade de explicação dos detalhes técnicos aplicados em suas existências. O diagramade caso de uso simplifica a identificação e compreensão dos requisitos de sistema, ajudandoa especificar, visualizar e documentar características, funções e serviços que deverão serdisponibilizadas aos usuários.

O primeiro diagrama de caso de uso desenhado está disponível na Figura 22, emque é esboçado as principais atividades do administrador do sistema. Em um ambiente denuvem provavelmente seria o mesmo responsável por controlar a infraestrutura física elógica, pois este profissional é o responsável pelo controle de diversas tarefas que exigemalto conhecimento técnico, dentre estas as de segurança, logo seu papel é fundamentalpara melhor atuação do IDS, como por exemplo na definição novas assinaturas de ataques.A lista a seguir descreve o casos de uso do administrador do sistema:

• Inicializar IDS: Atividade na qual serve como base para início de todos os subprocessos do IDS. Em resumo podemos dizer que é através desta ação que os agentesestáticos serão inicializados e irão iniciam suas atuações;

• Manter Assinaturas: Manutenção das assinaturas de ataques utilizada na identifi-cação de comportamentos maliciosos;

• Analisar Logs: Verificação e classificação dos dados escritos nos arquivos de logs;

• Manter Comportamentos: Manutenção dos comportamentos disponíveis paraexecução de tarefas por parte dos agentes

• Manter Contramedidas: Manutenção dos procedimentos a serem realizados me-diante a identificação de ataques.

O segundo diagrama de caso de uso projetado e apresentado na Figura 23 tem ointuito de destacar as principais atividades que estarão disponíveis aos agentes de softwaresque ajudam a compor o sistema. A baixo um resumo é apresentado sobre cada caso de uso:

Capítulo 5. Modelagem e Implementação 75

Figura 22 – Casos de uso administrador. Fonte: Autoria própria

• Enviar / Receber Chave de Cripto.: Ação ligada a troca de chave de segurançaque deverá ser utilizada no processo de criptografia e validação das mensagensutilizadas na comunicação entre os agentes;

• Criptografar / Descriptografar Mensagem: Capacidade de criptografar e des-criptografar o conteúdo das mensagens envidas ou recebidas;

• Gerar Log: Possibilidades para escrita em arquivos de registros de ações que poderãoser utilizados em processos futuros de auditorias;

• Enviar / Receber Mensagem: Habilidade para se comunicar com outros agentesatravés do envio e recebimento de mensagens;

• Validar Mensagem: Possibilidade de aplicar técnicas que permitam checar aintegridade de mensagens recebidas;

• Executar Comportamento: Um agente poderá exercer um ou mais comporta-mento, podendo ser realizados sequencial ou paralelamente;

• Manter Agentes Dinâmicos: O ControllerAgent deverá possuir a capacidade deinicializar ou remover agentes da camada 2 do modelo em tempo de execução;

• Aplicar Contramedida: Possibilidade do ControllerAgent de realizar uma açãoem resposta a um ataque detectado;


• Monitorar Hipervisor: Será permitido ao SnifferAgent monitor as alterações deestados nas estancias de máquinas virtuais presente em um Hipervisor;

• Monitorar Máquina Virtual : O FilterAgent deverá monitorar o trafego de redeproveniente de uma estancia de maquina virtual;

• Analisar Pacotes: Ao AnalyzerAgent será atribuído a capacidade de analisar ospacotes coletados afim de classificação do mesmo em normal ou malicioso.

Figura 23 – Casos de uso agentes. Fonte: Autoria própria

Após a idealização dos diagramas de casos de uso um outro recurso da UML foiutilizado, cujo o seu foco está na representação das classes que irão compor a estrutura doprojeto de software orientado a objetos. Segundo [88] o diagrama de classes é um dos maisvalorosos da UML, pois permite visualizar quais classes, seus atributos e/ou métodos, bemcomo suas interligações com outras classes, desta forma definir a estrutura lógica principaldo sistema. Na Figura 24 podemos perceber o diagrama de classes do modelo propostode forma resumida. A lista a seguir descreve o papel das principais classes existentes noarcabouço do sistema, onde encontram-se organizadas em ordem alfabética:

• ACLMessageService: Responsável por implementar métodos que permitam oenvio e mensagens atraves do padrão ACL;


Figura 24 – Diagrama de classes. Fonte: Autoria própria

• Agent: Classe existente no framework JADE, na qual representa um agente desoftwares. Os demais agentes herdarão as características contidas em sua estruturainterna;

• AgentState: Componente do tipo enumeração java, em que armazena os possíveisestados de um agente durante a execução do sistema;

• AnalyzerVMAgent: Representação do agente de analise que será associado a umamaquina virtual;

• AttackSignature: Classe que simboliza as assinaturas de ataque já conhecidas;

• Behaviour: Classe também provida pelo framework JADE, o seu papel é mapearum comportamento a ser exercido por um agente;

• ConsoleService: Responsável por prover métodos que permitam a interação com oS.O e desta forma facilitar a execução de chamadas de sistema;

• ControllerNodeAgent: Representação do agente de controle, responsável porexercer diversas atividades, como por exemplo gerenciamento dos agentes dinâmicos;

• CurrentState: Componente do tipo enumeração java, encarregado de definir ospossíveis estados atual de um agente;

• CyclicBehaviour: Representação de um comportamento cíclico que poderá serexecutado pelos agentes. Também pertencente ao JADE;


• DHPublicKeyMessage: Mapeamento da uma mensagem utilizada durante a ne-gociação da chave de segurança entre dois agentes;

• FilterVMAgent: Representação do agente de captura que será associado a umamaquina virtual;

• Host: Modelo para representação das característica de um host;

• KeyPair: Classe nativa da linguagem java, em que representa um par de chavesutilizadas na criptografia assimétrica;

• LoggerService: Responsável por oferecer métodos que simplifiquem a escrita emarquivos de logs;

• Message: Modelo para representação das característica de uma mensagem utilizadana conversação entre agentes;

• MessageType: Componente do tipo enumeração java, responsável por armazenaros possíveis tipos de mensagens permutadas entre os agentes;

• OneShotBehaviour: Representação de um comportamento que deverá ser execu-tado apenas uma única vez pelos os agentes. Também pertencente ao JADE;

• ReactionAttack: Classe que simboliza uma reação a ataques;

• SecurityService: Responsável por prover comportamentos que auxiliem nas ativi-dades que busquem manter inviolados os pilares da segurança;

• Service: Representação de uma classe de serviço. Seu principal objetivo é oferecermétodos estáticos que poderão ser compartilhados entre os componentes;

• SignedObject: Classe nativa da linguagem java, em que representa um objetoassinado através da criptografia assimétrica;

• SignedObjectMessage: Modelo para representação das característica de umamensagem que eu seu interior embarcar um objeto assinado;

• SnifferNodeAgent: Representação do agente de monitoramento do hipervisor,responsável por coletar informações dos sobre os estados das máquinas virtuaislocais;

• TCPAtackSignature: Classe que simboliza as assinaturas de ataque TCP;

• TCPReactionAttack: Classe que simboliza reações aos ataques do tipo TCP;

• TickerBehaviour: Também pertence ao framework JADE, onde representa umcomportamento que deverá ser executado continuamente, respeitando um intervalode tempo entre cada realização;


• UDPAtackSignature: Classe que simboliza as assinaturas de ataque UDP

• UDPReactionAttack: Classe que simboliza reações aos ataques do tipo UDP;

• UtilitesService: Responsável por prover métodos utilitários, como por exemplo aconversão de um endereço MAC que encontra-se representado em vetor de bytespara uma apresentação em texto legível;

• VirtualMachine: Modelo para representação das característica de uma estancia demáquina virtual.

5.2 Implementação dos AgentesA implementação do modelo proposto iniciou com o sintetização das classes res-

ponsáveis por exercerem os papeis de agentes. A lista a baixo apresenta uma descrição doconteúdo destas classes:

• ControllerNodeAgent: Na Figura 25 é possível observar duas características queserão repetidas nos demais agentes: O relacionamento de herança com a classeAgent, onde este representa a classe do framework JADE que poderá ser executadaem sua plataforma, e a sobrescrita do método setup, isto ocorre em função destecomportamento ser o que deverá ser interpretado imediatante após a inicializaçãodo agente, sendo assim em seu escopo aplica-se os passos que precedem quaisqueroutros comportamentos que o agente deverá no decorrer do seu clico de vida. OControllerNodeAgent inicialmente deverá verificar qual o seu tipo, isto é, principalou substituto e assim armazenar este status, logo apos iniciara o acordo que deveráresultar na chave simétrica para a comunicação com os agentes SnifferNodeAgentprincipal e substituto, e depois um par de chaves de criptografia assimétrica será cri-ada, onde estas serão utilizadas na comunicação com os agentes dinâmicos. Podemosnotar a aplicação de um comportamento ciclico ao agente ataves da sobrescrita dométodo action contido na classe CyclicBehaviour, as atividades em seu núcleo irãotratar do processamento das massagem recebidas do outros agentes e isto deveráocorrer durante toda a existência do agentes, justificando assim a aplicação de umaação cíclica. Outros contentamentos serão exercidos pelo agente mediate o tipo damensagem recebida;

• SnifferNodeAgent: Apos sua inicialização fara a mesma verficação na qual ar-mazenara se é do tipo principal ou substituto, isto é importante pois caso estejadefinido como substituto o único comportamento a ser executado sera o de trocade chave. Na Figura 25 podemo ver um trecho do código responsável por receberas mensagens do outros agentes através da método processACLMessage que assim


Figura 25 – Trecho de código da classe ControllerNodeAgent. Fonte: Autoria própria

como no ControllerNodeAgent será executada em um comportamento cíclico, ondebasicamente apos receber uma mensagem, verifica qual o seu tipo e entao segueos passos definidos , como por exemplo a continuação do acordo da chave com oController principal e substituto. O comportamento principal do SnifferNodeAgenté obsevar as variações no hipervisor, em um abiente real de nuvem isto é possívelatreves de api que são disponibilizadas para esta ativiade, no contexo atual estasinformações seroa capturadas mediate a leitura de um arquivo onde estes dados estãodefinidas, na qual é possível capturar o estado atual de cada estancia de máquinavirtual e mediante uma constante releitura deste arquivo ele será capaz de identificarquais maquinas tiveram estados alterados e assim notificar ao ControllerNodeAgentdesta forma prover a elasticidade ao modelo.

• AnalyzerVMAgent: Na Figura 27 é apresentado parte do método exclusivo doAnalyzerVMAgent, reponsavel por analisar os pacotes recebidos do FilterVMAgent emediante as assinaturas conhecidas será capaz de identificar comportamentos malici-osos. As assinaturas utilizadas neste trabalho possuem base no tempo e quantidadepacotes recebidso em um host. As classe TCPAtackSignature e UDPAtackSignaturepossuem a representação das caracteticas dos ataques de inundação que visam inter-romper um serviço. Casos uma ataque seja identificado uma notificação será enviadaao ControllerNodeAgent ataves da classe ACLMessageService.


Figura 26 – Trecho de código da classe SnifferNodeAgent. Fonte: Autoria própria

Figura 27 – Trecho de código da classe AnalyzerVMAgent. Fonte: Autoria própria

• FilterVMAgent: Podemo observar na figura na Figura 28 a implementação dométodo capturePacket, sendo este o principal comportamento deste agente e tambémdeverá ser executado de manira cíclica, porém somente apos o recebimento da chavepublica do seu respectivo Analyzer. Este método abrange desde a captura do pacotede rede com base em um host até o envio ao AnalyzerVMAgent para analise.


Figura 28 – Trecho de código da classe FilterVMAgent. Fonte: Autoria própria

5.3 Mecanismo de ElasticidadeO SnifferNodeAgent responsável por monitorar os estados das VMs, atuará de forma

fundamental para garantia da elasticidade do modelo. Na Figura 29 podemos ver partedo código executado pelo agente para identificar o estado atual de cada máquina, ondecaso possuam modificações mensagens deverão ser envidas imediatamente ao ControleNo-deAgent, onde o conteúdo destas será criptografado com a chave definida anteriormente.

A Figura 30 nos apresenta o container de execução do agntes em 3 momentosdistintos: A parte da imagem a esquerda mostra que apenas os agentes da camada estáticaestão ativos, ao centro é possível ver que ocorre a comunicao entre o agente snifer e ocontroller simbolizado por uma seta, onde o conteudo desta mensagem contem a informaçãoque uma maquina virtual esta ativa e por fim a parte da imaem mais a direita apresenta oresultado da açao do controller, onde dois agentes da camada dinamica forma inicializados.De forma similar ocorre quando uma VM é desligada, porém ao invés de inicializar ocontrollr remove o par de agentes responsável.


Figura 29 – Trecho de código da classe SnifferNodeAgent 2. Fonte: Autoria própria

Figura 30 – Interação entre agentes no esquema de elasticidade. Fonte: Autoria própria

5.4 Mecanismo de TolerânciaA classe Agent do framework JADE possui métodos que permitem indicar ao

container de execução o que deve ser realizado mediante uma mudança de estado para umagente. A tolerância a falha do modelo será a nível de agentes, baseando-se na definição deações que deverão ser executadas em casos onde uma alteração de estado não prevista foiidentificada. Podemos observar na Figura 31 a sobrescrita de dois métodos existentes naclasse Agent pela classe ControllerNodeAgent: doSuspend é chamado sempre que o agentepor algum motivo tiver seu processamento suspenso pelo plataforma, isto pode ocorrermediante falhas no container ou no próprio agente, caso isto aconteça o método doDeletedeverá ser executado; doDelete indica o que deve ser realizado para que o agente possa serremovido do container atual, também pode ser executado mediante problemas interno


Figura 31 – Trecho de código da classe ControllerNodeAgent 2. Fonte: Autoria própria

ao agente ou no contexto da plataforma. O método doDelete utiliza um comportamentoinformFailureAgent da classe ACLMessageService para notificar um outro agente sobre estamudança de estado, na qual o conteúdo é criptografado utilizando a chave de segurançada respectiva comunicação, neste caso o agente snifer atual (é possível que o sniffer nodeprincipal ja tenha falhado, logo a comunicação seria com o substituo) é informado sobre aremoção do agente, que por sua vez apos validar a mensagem define que a comunicaçãopadrão será com o controller substituto, e os agentes de analise também são informados dafalha, para que este notifiquem ataques ao agente ainda em execução. Os demais agentes domodelo atuam de forma similar, modificando perincipalmente o destinatário da mensagem,para que este execute o que lhe foi definido conforme a notificação recebida.

5.5 Validação das MensagensVisando aumentar a segurança da integridade do conteúdo das mensagens per-

mutadas entre os agentes, métodos de segurança foram desenvolvidos e centralizados naclasse SecurityService, sendo esta a principal responsável por disponibilizar procedimentosestáticos então assim facilitar o compartilhamento entre os componentes. Na Figura 32podemo ver dois dos métodos mais utilizados durante a execução do sistema, responsávelpor criptografar e desencriptar o conteúdo de uma mensagem, na qual obrigatoriamentedepende de uma chave de segurança. Através do recurso de polimorfismo é possível utilizareste mesmo método para a segurança do agentes que se comunicam com chaves simétricas(agentes estáticos) bem como os que atuam com chaves assimétricas (agentes dinâmicos).A classe SecurityService também disponibiliza métodos para criação de chaves simétricas,assimétricas, geração e checagem do resumo de mensagens.


Figura 32 – Trecho de código da classe SecurityService. Fonte: Autoria própria

Todas as mensagens referentes a notificações entre agentes são analisadas e verifica-das com base na chave de criptografia do respectivo agente emissor, que fora previamenterecebida durante sua inicialização, desta forma permitindo maior confiabilidade ao modelo.

86

6 Experimentos

6.1 Ambiente de TestesCom o objetivo de avaliar o modelo de IDS proposto, foi estruturado um ambiente

local, na qual os componentes fundamentais a uma nuvem computacional (em seu nívelmais baixo) foram representados. A Figura 33 ilustra o cenário estabelecido.

Figura 33 – Ambiente de testes. Fonte: Autoria própria

A lista a baixo descreve o papel dos participante inseridos no ambiente de teste:

• Internet: Representa o elance de saída na qual os pertencentes da rede local utilizampara se conectarem a Internet;

• Roteador 00 / Switch00: Roteador principal, responsável por interligar os com-ponentes da rede local entre si, bem como proporcionar a conectividade de tais coma internet;

• Host 00 e Host 01: Computadores que representam clientes dos serviços providospela nuvem;

• Node 00 / FrontEnd: Em infraestruturas reais de nuvens estes dois componentesestariam divididos em no minimo dois hosts, isto se dá devido a função de ambos: oFrontEnd implementa uma interface de usuário e disponibiliza aos clientes, permitindogerenciar suas estancias de vm de forma simplificada; os NODE’s são responsáveispelo provimento de recursos que deverão ser compartilhado através da rede; entãocomo uma nuvem pode possui vários NODES, a o papel de interação com usuário

Capítulo 6. Experimentos 87

fica centralizado no FrontEnd. No contexto utilizado há apenas um NODE, logouma divisão de tarefas não foi necessária;

• Switch Virtual 00: Comutador de rede virtual criado e gerenciado pelo hipervisordisponível no Node 00, que tem como objetivo interligar as estancias das máquinasvirtuas tanto com o próprio hipervisor como entre si através de uma rede privada;

• Servidor HTTP: Máquina virtual responsável por representar um servidor HTTPdisponível na nuvem.

A tabela 4 descreve as características dos hosts:

Componente Papel Tipo Endereçamento IP

Node 00 / FrontEnd - Hipervisor- Interface de usuário físico eth0: 192.168.122.1/24

Servidor HTTP - Provedor de Serviço virtualizado eth0: 192.168.122.106/24

Host 00 - Cliente- Atacante físico eth0: 192.168.122.10/24

Host 01 - Cliente- Atacante físico eth0: 192.168.122.20/24

Tabela 4 – Descrição dos participantes do ambiente de teste. Fonte: Autoria própria

6.2 Teste 01 - TCP SYN FloodO primeiro experimento aplicado foi iniciado a partir da simulação de um ataque

de negação de serviço utilizando a técnica de SYN FLood. Este teste serviu para verificar acapacidade do modelo proposto de identificar este tipo de ataque, bem como sua atuaçãona coordenação da comunicação entre componentes envolvidos desde a captura dos pacotesaté a aplicação de uma ação corretiva.

Com a utilização do cenário exposto anteriormente, o Servidor HTTP (máquina vir-tual disponibilizada pelo hipervisor do Node 00) possuinte do endereço IP 192.168.122.106foi definido como alvo das requisições maliciosas, onde estas foram originalizadas pelos Host00 e Host 01, conectados a mesma rede do servidor com os endereços IP 192.168.122.10e 192.168.122.20 respectivamente. Na Figura 34 é possível observar o nível de utilizaçãodos recursos consumidos pelo Servidor HTTP logo após sua inicialização, de modo que aspequenas variações no gráfico de uso da cpu representam acessos realizados através deum navegador de internet, executados com o objetivo de verificar se o serviço estava ematividade.

A ativação do ataque se deu através da ferramenta hping, que permite gerar pacotesde redes de forma simplificada, necessitando apenas da definição de alguns parâmetros.


Figura 34 – Consumo de recursos inicial do servidor HTTP. Fonte: Autoria própria

A Figura 35 apresenta os comandos executados pelos hosts atacantes. A lista a baixodescreve as propriedades utilizada na delineação do ataque:

• -V: Utilizado para detalhar outros parâmetros;

• -c: Define a quantidade de pacotes que será enviado ao destino;

• -d: Define o tamanho do Pacote a ser enviado;

• -S: Obriga a ativação da flag SYN do TCP em todos os pacotes;

• -w: Indica o tamanho da Janela TCP para a conexão;

• -p: Define a porta de destino para a conexão;

• -s: Define a porta de origem para conexão;

• -flood: Indica que os pacotes devem ser enviados o mais rápidos possível;

• -a: Utilizado para mascarar o IP de origem do atacante. O último parâmetro identificao endereço de destino do pacote;

Figura 35 – Interface de execução de comandos dos hosts atacantes. Fonte: Autoria própria

Podemos observar na Figura 36 o aumento do consumo de recursos no ServidorHTTP, chegado a atingir o seu limite de processamento, isto ocorre em função da alocaçãode recursos para a confirmação do estabelecimento de conexão com o host, porém asrespostas não são recebidas uma vez que o endereço legitimo foi mascarado.


Figura 36 – Consumo de recursos durante SYN Flood no servidor HTTP. Fonte: Autoria própria

Em meio a realização do ataque, o IDS proposto foi inicializado no Node 00, naqual o comportamento esperado previa a identificação das ações maliciosas providas pelosHost 00 e Host 01 e aplicação de uma regra de firewall como medida preventiva. Optou-sepor utilizar o bloqueio do tráfego através de uma especificação no firewall apenas paramelhor expor o desempenho do modelo, no entanto é possível que esta abordagem nãofosse necessária em outros ambientes, abrindo espaço para comportamentos distintos, comopor exemplo a remoção da máquina virtual para uma rede de quarentena, envio de ume-mail ao administrador do sistema, etc.

Na Figura 37 podemos observar a interface do JADE que permite ver de formagráfica uma representação da comunicação entre os agentes, as setas do agente filter-192.168.122.106 indicam que um pacote foi capturado e enviado ao analyzer-192.168.122.106,que por sua vez após analisar o trafego enviou duas notificações ao controler-node (umapara cada host participante), contendo uma descrição do ataque.

Figura 37 – Interação entre agentes na identificação do ataque. Fonte: Autoria própria

Por fim após o controler-node processar a mensagem do analyzer e aplicar o


comportamento pre definido o consumo de recusos no servidor diminiu rapidamente comopodemos ver na Figura 38, de forma liberá-los aos clientes legítimos caso necessário.

Figura 38 – Consumo de recursos após a interrupção do SYN Flood. Fonte: Autoria própria

6.3 Teste 02 - UDP FloodPara continuidade da etapa de realização do testes, um segundo experimento foi

proposto na qual consistia em aplicar uma taque DDoS porém utilizando o protocolo UDP.De acordo com o trabalho [47] a adoção deste protocolo para ataques de negação de serviçopossui uma dificuldade maior quando comparado ao TCP, isto ocorre em virtude do UDPembarcar uma arquitetura não orientada a conexão, desta forma o estabelecimento daconversação exige menos informações de controle, porém um ataque de inundação podeser iniciado através do envio de um número grande de pacotes para portas aleatórias deum host, onde este por sua vez irá seguir os seguintes passos:

1. Verificar se há uma aplicação aguardando uma conexão para a porta solicitada;

2. Identificar que nenhuma aplicação responde por essa porta;

3. Responder a solicitação com uma resposta ICMP de destino não acessível;

Hosts atacados sob esta abordagem são forçados a enviar pacotes ICMP em fluxocontínuo, o que impacta diretamente no desempenho do envio das respostas para requisiçõesdos demais usuários bem como o aumento significativo do consumo de recursos.

O cenário para realização deste teste foi exatamente igual ao descrito no DDoS comSYN Flood, onde o Servidor HTTP do Node 00 possuinte do endereço IP 192.168.122.106foi utilizado como alvo das requisições maliciosas provenientes dos Host 00 e Host 01,conectados a mesma rede do servidor com os endereços IP 192.168.122.10 e 192.168.122.20respectivamente. Na Figura 39 é possível observar o baixo nível de utilização dos recursosconsumidos pelo Servidor HTTP logo após sua inicialização.


Figura 39 – Consumo de recursos inicial do servidor HTTP 2. Fonte: Autoria própria

A ativação do ataque também foi auxiliada pela ferramenta hping. Na Figura 40podemos verificar os comandos executados pelos hosts atacantes. A lista a baixo descreveas propriedades utilizada na deliberação do ataque:

Figura 40 – Interface de execução de comandos dos hosts atacantes 2. Fonte: Autoria própria

• –flood: Indica que os pacotes devem ser enviados o mais rápidos possível;

• -udp: Define o protocolo de estabelecimento de conexão;

• -destport: Define a porta UDP de destino.

Na Figura 41 podemo ver o aumento do consumo de recursos no Servidor HTTP,chegado a atingir o seu limite, isto ocorre em função da alocação de recursos para enviode pacotes de resposta informando sobre a inacessibilidade do serviço.

Em meio a realização do ataque, o IDS proposto foi novamente inicializado noNode 00, na qual o comportamento esperado previa a identificação das ações maliciosasprovidas pelos Host 00 e Host 01 e aplicação de uma regra de firewall para interrupção doataque. A comunicação entre os agentes seguiu a mesma direção do teste anterior, ondeo agente responsável pela Servidor HTTP (filter-192.168.122.106) após capturar pacotede rede, realizou o envio ao par responsável pela analise (analyzer-192.168.122.106), que


Figura 41 – Consumo de recursos durante UDP Flood. Fonte: Autoria própria

por sua vez apos analisar o trafego enviou duas notificações ao controler-node (uma paracada host participante), contendo uma descrição do ataque. Na Figura 42 o arquivo de logincumbido por armazenar os registros das interações entre os componentes é mostrado,em que as quatro ultimas linhas descrevem o envio e o recebimento destas notificações.

Figura 42 – Log das interações entre componentes. Fonte: Autoria própria

Por fim apos o controler-node processar a mensagem do analyzer e aplicar ocomportamento pre definido o consumo de recusos no servidor diminiu rapidamente comopodemos ver na Figura 43.

Figura 43 – Consumo de recursos Após a interrupção do UDP Flood. Fonte: Autoria própria

6.4 Teste 03 - Viabilidade da FerramentaO objetivo principal deste teste é avaliar desempenho de serviços disponíveis aos

usuários da nuvem, mediante a simulação de três situações distintas:


1. Normal: solicitações envidas ao servidor sem quaisquer atividades maliciosas porparte de outro host da rede;

2. DoS: solicitações envidas ao servidor no mesmo período de tempo que este seencontrar em um ataque de inundação TCP SYN Flood;

3. DoS com IDS: Assim como no item anterior, as solicitações serão envidas umservidor que se encontra sob o ataque de inundação TCP SYN Flood porém com omodelo de IDS proposto em execução;

Para a realização do experimento, os seguintes papeis foram atribuídos aos compo-nentes:

• Servidor HTTP: Responsável por disponibilizar o serviço de páginas de internetque deverá ser testada;

• Host 00: Responsável por executar os testes de desempenho com o auxílio daferramenta Jmeter, que dentre suas funcionalidades permite simular requisições declientes HTTP mediante a definição de um plano de teste, ou seja, especificações deum conjunto parâmetros. A tabela 5 apresenta os parâmetros utilizados no JMeter.

Grupos de Usuários 01Numero de Usuários do Grupo 500Tempo de Inicialização Para Cada Requisição 1sContador de Iteração 1Tipo de Testador Requisições HTTPTipo de Requisição GET

Tabela 5 – Parâmetros do plano de teste JMeter. Fonte: Autoria própria

• Host 01: Utilizado para gerar o trafego malicioso e direcionar ao servidor HTTP.

Para cada uma das 3 situações descritas anteriormente, foram realizados 10 execu-ções do plano de teste Jmeter descrito na tabela 5, permitindo um intervalo de 30 segundoafim de evitar que houvessem conflitos entre as solicitações, resultando assim em um totalde 15000 requisições (distribuído em 3 grupos de 5000).

O gráfico apresentado na Figura 44 representa os dados obtidos no primeiro contexto,ou seja, condições normais. Podemos observar que o maior pico de tempo apresentadopelo servidor para a envio da resposta a uma requisição foi igual a 20ms, tendo sua médiaconcentrada na faixa de 1ms, onde a média aproximada do desvio padrão foi de 1,4ms.

Na Figura 45 ao analisarmos o gráfico que contem dados obtidos no segundocontexto (em que o servidor esta sob um ataque DoS) é possível observar o aumentoconsiderável no tempo de resposta para as requisições, chegando a atingir intervalos acima


Figura 44 – Gráfico de resultados da situação normal. Fonte: Autoria própria

de 12000ms. Em média um pouco mais de 550ms foi gasto para que o servidor conseguisseenviar cada resposta e a média do desvio padrão foi aproximadamente 1300ms.

Figura 45 – Gráfico de resultados da situação DoS. Fonte: Autoria própria

A Figura 46 expõem os resultados obtidos no terceiro contexto, na qual o servidoralvo está com o modelo de IDS proposto em atividade. O maior intervalo de tempo para queo servidor respondesse a uma requisição foi de 1100ms. Aproximadamente 13ms foi a médiado tempo para cada resposta, onde a média do desvio padrão foi de aproximadamente65ms.


Figura 46 – Gráfico de resultados da situação DoS com IDS. Fonte: Autoria própria

96

7 Conclusões

7.1 Contribuição do trabalhoProvedores de nuvens buscam constantemente inovações tecnológicas de diversos

gêneros, porém em maior escala por aquelas relacionadas a segurança, na qual possuemcomo objetivo oferecer maior privacidade e proteção dos dados e informações.

Diversos tipos de ataques comuns na internet podem por em risco uma nuvemcomputacional, dentre estes podemos destacar os ataques negação de serviço pois seusimpactos são ainda maiores neste contexto, isto se dá em função do compartilhamento derecursos criar ambientes que permitem grupos de usuários mal intencionados perturbar odesempenho da comunicação e oferecimento de serviços a outros usuários de forma maissimples que quando comparadas a outras estruturas de aplicações.

Atualmente o firewall continua sendo uma das tecnologias mais utilizada paracontenção de ataques em nuvens computacionais, no entanto seu uso de forma isolada nãose apresenta como uma solução trivial, pois nativamente não possui procedimentos que opermitam atuar de forma dinâmica, ou seja, reação autônoma mediante modificações nocenário em que se encontra aplicado.

Sistemas de Detecção de Intrusão quando adaptados para aplicação em nuvens,permitem alcançar diversas características que buscam acompanhar propriedades funda-mentais exigidas, como por exemplo elasticidade, caracterizando-se assim como a soluçãomais eficaz para estes tipos de contextos. No entanto em diversas pesquisas relacionadasa IDS observou-se a inexistência de um modelo que apresentasse o maior número deimplementação das peculiaridades persistentes nuvem.

Como forma de minimizar a lacuna identificada o trabalho apresentado visoucontribuir com um modelo para a detecção de comportamentos maliciosos em contextos denuvens computacionais, baseando-se na utilização de sistemas multiagentes em conjuntotécnicas de criptografia para maior segurança da comunicação entre os componentes. Aarquitetura de IDS exposta sugeriu atuação na camada de infraestrutura por ser a de maisbaixo nível, o que permite ter percepção das camadas acima, na qual dois mecanismoprincipais foram embarcados: elasticidade - foi empregado visando permitir uma adaptaçãode forma autônoma para acompanhamento das modificações no estado na nuvem; tolerânciaa falhas - desenvolvido com objetivo de diminuir os impactos negativos que poderiam serapresentados mediante falhas em agentes participantes do sistema.

Também foi apresentado a implementação desenvolvida dos componentes fundamen-tais necessários para execução do sistema. Uma ambiente de nuvem foi simulado visando

Capítulo 7. Conclusões 97

permitir testar e validar o funcionamento do modelo proposto. Os resultados obtidosnos três teste aplicados classificam-se como satisfatórios, uma vez que os ataques foramidentificados e mediados, permitindo assim a contenção dos comportamentos maliciosos deforma autônoma em um espaço de tempo aceitável.

7.2 Pesquisas FuturasComo proposta para trabalhos futuros e sugestões para o enriquecimento deste,

pode-se listar:

• Aplicar e avaliar o comportamento do modelo proposto em um ambiente real denuvem;

• Desenvolver de uma estrutura que permita a elaboração de assinaturas de ataquespor meio de honeypots, que atue de forma integrada ao modelo e que possa assimaumentar gradativamente a base dados responsável por persistir os padrões decomportamentos maliciosos a serem coibidos;

• Agregar aos agentes a capacidade de detecção de ataques desconhecidos com baseno tráfego gerado, através da combinação de ontologias e inteligência artificial;

• Adicionar técnicas de introspeção de VM para detecção de malwares e assim ampliaro nível de atuação do sistema;

• Avaliar o custo computacional necessário para execução da ferramenta em todas osseu níveis, componentes e processos;

• Embarcar mecanismos de tolerância a falhas a nível de container de agentes.

98

Referências

[1] MORAES, F. de A. L. Segurança e Confiabilidade em IDS Baseados em Agente.Dissertação (Mestrado) — Universidade Federal do Maranhão, 2009. Citado 4 vezes naspáginas 16, 17, 19 e 49.

[2] SHAIKH, F. B.; HAIDER, S. Security threats in cloud computing. In: IEEE. Internettechnology and secured transactions (ICITST), 2011 international conference for. [S.l.],2011. p. 214–219. Citado na página 16.

[3] MODI, C. et al. A survey of intrusion detection techniques in cloud. Journal ofNetwork and Computer Applications, v. 36, n. 1, p. 42 – 57, 2013. ISSN 1084-8045.Disponível em: <http://www.sciencedirect.com/science/article/pii/S1084804512001178>.Citado 5 vezes nas páginas 16, 17, 45, 49 e 50.

[4] MITROKOTSA, A.; DOULIGERIS, C. Denial-of-service attacks. Network Security:Current Status and Future Directions, John Wiley & Sons, Inc., p. 117–134, 2007. Citadona página 17.

[5] PEREZ, A. L. F.; POZZEBON, E. Aplicação de sistema multiagente no processode licitação. In: INTERNATIONAL INFORMATION AND TELECOMMUNICATIONTECHNOLOGIES SYMPOSIUM. [S.l.: s.n.], 2003. v. 2. Citado na página 17.

[6] RODRIGUES, D. de A. Mecanismo de Tolerância a Falhas para o EICIDS: Sistemade detecção de intrusão elástico e interno baseado em nuvem. Dissertação (Mestrado) —Universidade Federal do Maranhão, 2014. Citado 3 vezes nas páginas 17, 54 e 55.

[7] CARROLL, M.; MERWE, A. V. D.; KOTZE, P. Secure cloud computing: Benefits,risks and controls. In: IEEE. Information Security South Africa (ISSA), 2011. [S.l.], 2011.p. 1–9. Citado 4 vezes nas páginas 17, 18, 21 e 34.

[8] NETWORKS, A. DDoS Attacks: A 10-Year Timeline. Disponível em:<http://www.arbornetworks.com/resources/annual-security-report>. Acesso em:10/09/2015. Citado na página 17.

[9] AKAMAI. State of the Internet. Disponível em: <https://www.stateoftheinternet.com/>. Acesso em: 18/12/2015. Citado na página 18.

[10] CERT. Incidentes Reportados ao CERT.br – Janeiro a Dezembro de 2015. Disponívelem: <http://www.cert.br/stats/incidentes/2015-jan-dec/ataques-mensal.html>. Acessoem: 03/03/2016. Citado 2 vezes nas páginas 18 e 19.

[11] MARCON, D. S. et al. Mitigando ataques de egoísmo e negação de serviço emnuvens via agrupamento de aplicações. 2012. Citado na página 18.

[12] SINGH, A.; SHRIVASTAVA, M. Overview of attacks on cloud computing.International Journal of Engineering and Innovative Technology (IJEIT), v. 1, n. 4, 2012.Citado na página 18.

[13] ZHAO, X.; BORDERS, K.; PRAKASH, A. Virtual machine security systems.Advances in Computer Science and Engineering, p. 339–365, 2009. Citado na página 19.

http://www.sciencedirect.com/science/article/pii/S1084804512001178

http://www.arbornetworks.com/resources/annual-security-report

https://www.stateoftheinternet.com/

https://www.stateoftheinternet.com/

http://www.cert.br/stats/incidentes/2015-jan-dec/ataques-mensal. html

Referências 99

[14] RAMCHURN, S. D.; HUYNH, D.; JENNINGS, N. R. Trust in multi-agent systems.The Knowledge Engineering Review, Cambridge Univ Press, v. 19, n. 01, p. 1–25, 2004.Citado na página 19.

[15] PEREIRA, C. A. M.; HERSCHMANN, M. et al. Comunicação e novas estratégiasorganizacionais na era da informação e do conhecimento. Comunicação & Sociedade, p.27–42, 2002. Citado na página 20.

[16] 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 na página 21.

[17] ASTAH. Astah is Modeling. Disponível em: <http://astah.net/>. Acesso em:10/01/2016. Citado na página 22.

[18] CORPORATION, O. O que é a Tecnologia Java? Disponível em: <https://www.java.com/pt_BR/download/faq/whatis_java.xml>. Acesso em: 10/01/2016.Citado na página 22.

[19] ITALIA, T. JAVA Agent DEvelopment Framework. Disponível em: <http://jade.tilab.com/>. Acesso em: 10/01/2016. Citado na página 22.

[20] FOUNDATION, A. S. Apache Log4j 2. Disponível em: <http://logging.apache.org/log4j/2.x/>. Acesso em: 10/01/2016. Citado na página 22.

[21] CORPORATION, O. Welcome to the NetBeans Community. Disponível em:<https://netbeans.org/about/index.html>. Acesso em: 10/01/2016. Citado na página 23.

[22] SOFTWARES, T. January Headline: Java is TIOBE’s Programming Language of2015! Disponível em: <http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. Acesso em: 01/01/2016. Citado na página 23.

[23] ALLIANCE, O. V. Kernel Virtual Machine. Disponível em: <http://www.linux-kvm.org/page/Main_Page>. Acesso em: 10/01/2016. Citado na página 24.

[24] INC., R. H. Manage virtual machines with virt-manager. Disponível em:<https://virt-manager.org/>. Acesso em: 10/01/2016. Citado na página 24.

[25] FOUNDATION, A. S. JMeter. Disponível em: <http://jmeter.apache.org/>. Acessoem: 10/01/2016. Citado na página 24.

[26] SANFILIPPO, S. Hping. Disponível em: <http://www.hping.org/>. Acesso em:10/01/2016. Citado na página 24.

[27] DIKAIAKOS, M. D. et al. Cloud computing: Distributed internet computing for itand scientific research. Internet Computing, IEEE, IEEE, v. 13, n. 5, p. 10–13, 2009.Citado na página 26.

[28] BUYYA, R. et al. Cloud computing and emerging it platforms: Vision, hype, andreality for delivering computing as the 5th utility. Future Generation computer systems,Elsevier, v. 25, n. 6, p. 599–616, 2009. Citado na página 26.

[29] MELL, P.; GRANCE, T. The nist definition of cloud computing. Computer SecurityDivision, Information Technology Laboratory, National Institute of Standards andTechnology Gaithersburg, 2011. Citado 2 vezes nas páginas 26 e 28.

http://astah.net/

https://www.java.com/pt_BR/download/faq/whatis_java.xml

https://www.java.com/pt_BR/download/faq/whatis_java.xml

http://jade.tilab.com/

http://jade.tilab.com/

http://logging.apache.org/log4j/2.x/

http://logging.apache.org/log4j/2.x/

https://netbeans.org/about/index.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.linux-kvm.org/page/Main_Page

http://www.linux-kvm.org/page/Main_Page

https://virt-manager.org/

http://jmeter.apache.org/

http://www.hping.org/

Referências 100

[30] ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art andresearch challenges. Journal of internet services and applications, Springer, v. 1, n. 1, p.7–18, 2010. Citado na página 27.

[31] SHAW, S.; SINGH, A. A survey on cloud computing. In: Green ComputingCommunication and Electrical Engineering (ICGCCEE), 2014 International Conferenceon. [S.l.: s.n.], 2014. p. 1–6. Citado na página 27.

[32] VERAS, M.; TOZER, R. Cloud Computing: nova arquitetura da TI. [S.l.]: Brasport,2012. Citado 3 vezes nas páginas 30, 33 e 35.

[33] VELTE, A. T.; VELTE, T. J.; ELSENPETER, R. Cloud Computing - Computaçãoem Nuvem: Uma Abordagem Prática. [S.l.]: Alta Books, 2011. Citado 2 vezes nas páginas30 e 33.

[34] VERDI, F. L. et al. Novas arquiteturas de data center para cloud computing.Minicursos do XXVIII SBRC, p. 103–152, 2010. Citado na página 30.

[35] SILVA, F. R. H. d. Um Estudo Sobre os Benefícios e os Riscos de Segurança naUtilização de Cloud Computing. [S.l.]: Trabalho de Conclusão de Curso-UNISUAM-http://fabriciorhs. files. wordpress. com/2011/03/cloud_computing. pdf, Acesso em16/10/2015. Citado 2 vezes nas páginas 30 e 31.

[36] PRABAHAR, B. P.; EDWIN, B. E. Survey on virtual machine security. InternationalJournal of Advanced Research in Computer Engineering Technology (IJARCET), v. 1,n. 8, p. 115–121, 2012. ISSN 2278 ? 1323. Citado na página 31.

[37] TIANFIELD, H. Cloud computing architectures. In: Systems, Man, and Cybernetics(SMC), 2011 IEEE International Conference on. [S.l.: s.n.], 2011. p. 1394–1399. ISSN1062-922X. Citado na página 31.

[38] JESUS, J. de. Navegando na Nuvem IBM, Parte 1: Um Manual sobre Tecnologiasem Nuvem. [S.l.], 2013. Disponível em: http://www.ibm.com/. Acessado em 12-08-2015.Disponível em: <http://www.ibm.com/developerworks/br/websphere/techjournal/1206dejesus/1206dejesus.html>. Citado 2 vezes nas páginas 32 e 33.

[39] SRIDHARAN, S. A Performance Comparison of Hypervisors for Cloud Computing.Dissertação (Mestrado) — University of North Florida, 2012. Citado na página 32.

[40] SANTOS, C. F. Ambiente de virtualização: uma análise de desempenho. 2015.Citado 2 vezes nas páginas 32 e 33.

[41] SUBASHINI, S.; KAVITHA, V. A survey on security issues in service deliverymodels of cloud computing. Journal of network and computer applications, Elsevier, v. 34,n. 1, p. 1–11, 2011. Citado na página 35.

[42] STALLINGS, W.; VIEIRA, D. Criptografia e segurança de redes: princípios epráticas. [S.l.]: Pearson Prentice Hall, 2008. Citado 5 vezes nas páginas 35, 36, 37, 41 e 42.

[43] TéCNICAS, A. B. de N. Técnicas de Segurança - ABNT NBR ISO/IEC 27001. [S.l.],2006. Disponível em: http://www.abnt.org.br/. Acessado em: 14-09-2015. Disponível em:<http://www.abnt.org.br>. Citado na página 36.

http://www.ibm.com/developerworks/br/websphere/techjournal/1206dejesus/1206dejesus.html

http://www.ibm.com/developerworks/br/websphere/techjournal/1206dejesus/1206dejesus.html

http://www.abnt.org.br

Referências 101

[44] VERíSSIMO, P.; RODRIGUES, L. Fundamental security concepts. In: DistributedSystems for System Architects. Springer US, 2001, (Advances in DistributedComputing and Middleware, v. 1). p. 377–393. ISBN 978-1-4613-5666-0. Disponível em:<http://dx.doi.org/10.1007/978-1-4615-1663-7_16>. Citado na página 36.

[45] KUROSE, J. F. et al. Redes de computadores ea Internet: Uma abordagem top-down.[S.l.]: Pearson, 2010. Citado 3 vezes nas páginas 36, 40 e 41.

[46] TANENBAUM, A.; WETHERALL, D. J. Redes de computadoras. [S.l.]: PearsonPrentice Hall, 2011. Citado 4 vezes nas páginas 36, 37, 39 e 40.

[47] 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 6 vezes nas páginas 37, 50, 51, 57, 59 e 90.

[48] HENDRICKS, M. et al. Profissional Java Web Services. [S.l.]: Alta Books, 2002.Citado 4 vezes nas páginas 37, 38, 39 e 40.

[49] ARAUJO, R. W. M. d. Autenticação e comunicação segura em dispositivos móveisde poder computacional restrito. Dissertação (Mestrado) — Universidade de São Paulo,2013. Citado na página 38.

[50] DIFFIE, W.; HELLMAN, M. E. New directions in cryptography. InformationTheory, IEEE Transactions on, IEEE, v. 22, n. 6, p. 644–654, 1976. Citado na página 38.

[51] SILVA, L. G. C. et al. Certificação Digital-Conceitos e Aplicações. [S.l.]: EditoraCiência Moderna, 2008. Citado na página 40.

[52] SANTOS, W. H. dos. Métodos de Deteção de Ataques DDoS Compostos baseados emFiltragem Sequencial. [S.l.], 2012. Citado na página 42.

[53] TAURION, C. Cloud Computing-Computação em Nuvem. [S.l.]: Brasport, 2009.Citado na página 43.

[54] ALLIANCE, C. S. The Notorious Nine: Cloud Computing Top Th-reats in 2013. Disponível em: <https://cloudsecurityalliance.org/download/the-notorious-nine-cloud-computing-top-threats-in-2013/>. Acesso em: 10/11/2015.Citado 5 vezes nas páginas 43, 44, 45, 46 e 47.

[55] BAKER, L. B.; FINKLE, J. Sony playstation suffers massive data breach. Reuters,April, v. 26, 2011. Citado na página 43.

[56] MILLER, M. H. Data theft: Top 5 most expensive data brea-ches. Disponível em: <http://www.csmonitor.com/Business/2011/0504/Data-theft-Top-5-most-expensive-data-breaches/5.-US-Veterans-Affairs-25-30-million>.Acesso em: 10/11/2015. Citado na página 44.

[57] ZETTER, K. In Surprise Appeal, TJX Hacker Claims U.S. Authorized His Crimes.Disponível em: <http://www.wired.com/2011/04/gonzalez-plea-withdrawal/>. Acessoem: 10/11/2015. Citado na página 44.

[58] LIU, S.; KUHN, R. Data loss prevention. IT professional, IEEE, v. 12, n. 2, p. 10–13,2010. Citado na página 44.

http://dx.doi.org/10.1007/978-1-4615-1663-7_16

https://cloudsecurityalliance.org/download/the-notorious-nine-cloud-computing-top-threats-in-2013/

https://cloudsecurityalliance.org/download/the-notorious-nine-cloud-computing-top-threats-in-2013/

http://www.csmonitor.com/Business/2011/0504/Data-theft-Top-5-most-expensive-data-breaches/5.-US-Veterans-Affairs-25-30-million

http://www.csmonitor.com/Business/2011/0504/Data-theft-Top-5-most-expensive-data-breaches/5.-US-Veterans-Affairs-25-30-million

http://www.wired.com/2011/04/gonzalez-plea-withdrawal/

Referências 102

[59] ZORZ, Z. Researchers detail attacks for compromising Dropbox user accounts.Disponível em: <http://www.net-security.org/secworld.php?id=15480>. Acesso em:11/11/2015. Citado na página 45.

[60] LU, Q. et al. Cloud api issues: an empirical study and impact. In: ACM. Proceedingsof the 9th international ACM Sigsoft conference on Quality of software architectures. [S.l.],2013. p. 23–32. Citado na página 45.

[61] CHEN, X. Distributed denial of service attack and defense. In: 2010 InternationalConference on Educational and Information Technology. [S.l.: s.n.], 2010. v. 3. Citado 2vezes nas páginas 45 e 46.

[62] THE CERT Insider Threat Center. Disponível em: <http://www.cert.org/insider_threat/>. Citado na página 46.

[63] DUNCAN, A.; CREESE, S.; GOLDSMITH, M. Insider attacks in cloud computing.In: IEEE. Trust, Security and Privacy in Computing and Communications (TrustCom),2012 IEEE 11th International Conference on. [S.l.], 2012. p. 857–862. Citado na página46.

[64] MICHELIN, R. A. Mitigação de ataques de negação de serviço em rests autenticáveisna nuvem. Pontifícia Universidade Católica do Rio Grande do Sul, 2015. Citado 2 vezesnas páginas 46 e 47.

[65] SZEFER, J.; LEE, R. B. Bitdeposit: Deterring attacks and abuses of cloudcomputing services through economic measures. In: IEEE. Cluster, Cloud and GridComputing (CCGrid), 2013 13th IEEE/ACM International Symposium on. [S.l.], 2013. p.630–635. Citado na página 47.

[66] DAWOUD, W.; TAKOUNA, I.; MEINEL, C. Infrastructure as a service security:Challenges and solutions. In: IEEE. Informatics and Systems (INFOS), 2010 The 7thInternational Conference on. [S.l.], 2010. p. 1–8. Citado na página 47.

[67] K, M. C. A. Ids: Survey on intrusion detection system in cloud computing.International Journal of Computer Science and Mobile Computing, v. 3, n. 1, p. 497 –502, 2014. ISSN 2320–088X. Disponível em: <http://www.academia.edu/6772890/IDS_Survey_on_Intrusion_Detection_System_in_Cloud_Computing_>. Citado 2 vezes naspáginas 47 e 50.

[68] SIQUEIRA, L. G. Tolerância a Falhas para o NIDIA: um Sistema de Detecçãode Intrusão Baseado em Agentes Inteligentes. Dissertação (Mestrado) — UniversidadeFederal do Maranhão, 2006. Citado 2 vezes nas páginas 48 e 54.

[69] PEREIRA, H. Sistema de detecçao de intrusao para serviços web baseado emanomalias. Curitiba: Pontifícia Universidade Católica do Paraná, 2011. Citado 5 vezesnas páginas 48, 49, 52, 53 e 54.

[70] SAAD, E.; MAHDI, K.; ZBAKH, M. Cloud computing architectures based ids. In:Complex Systems (ICCS), 2012 International Conference on. [S.l.: s.n.], 2012. p. 1–6.Citado 2 vezes nas páginas 48 e 51.

http://www.net-security.org/secworld.php?id=15480

http://www.cert.org/insider_threat/

http://www.cert.org/insider_threat/

http://www.academia.edu/6772890/IDS_Survey_on_Intrusion_Detection_System_in_Cloud_Computing_

http://www.academia.edu/6772890/IDS_Survey_on_Intrusion_Detection_System_in_Cloud_Computing_

Referências 103

[71] DEBAR, H.; VIINIKKA, J. Intrusion detection: Introduction to intrusion detectionand security information management. In: ALDINI, A.; GORRIERI, R.; MARTINELLI,F. (Ed.). Foundations of Security Analysis and Design III. Springer Berlin Heidelberg,2005, (Lecture Notes in Computer Science, v. 3655). p. 207–236. ISBN 978-3-540-28955-5.Disponível em: <http://dx.doi.org/10.1007/11554578_7>. Citado 2 vezes nas páginas 48e 49.

[72] BACE, R.; MELL, P. NIST special publication on intrusion detection systems. [S.l.],2001. Citado 4 vezes nas páginas 48, 49, 51 e 52.

[73] LYDON, A. Compilation for Intrusion Detection Systems. Dissertação (Mestrado) —Ohio University, 2004. Citado 2 vezes nas páginas 51 e 54.

[74] MANDUJANO, S. A multiagent approach to outbound intrusion detection.Monterrey Campus, Citeseer, 2004. Citado na página 51.

[75] VIINIKKA, J. et al. Time series modeling for ids alert management. In: ACM.Proceedings of the 2006 ACM Symposium on Information, computer and communicationssecurity. [S.l.], 2006. p. 102–113. Citado na página 52.

[76] GARCIA-TEODORO, P. et al. Anomaly-based network intrusion detection:Techniques, systems and challenges. computers & security, Elsevier, v. 28, n. 1, p. 18–28,2009. Citado na página 52.

[77] SNAPP, S. R. et al. Dids (distributed intrusion detection system)-motivation,architecture, and an early prototype. In: CITESEER. Proceedings of the 14th nationalcomputer security conference. [S.l.], 1991. v. 1, p. 167–176. Citado na página 53.

[78] PENG, T.; LECKIE, C.; RAMAMOHANARAO, K. Information sharing fordistributed intrusion detection systems. Journal of Network and Computer Applications,Elsevier, v. 30, n. 3, p. 877–899, 2007. Citado na página 53.

[79] PORRAS, P. A.; NEUMANN, P. G. Emerald: Event monitoring enabling responseto anomalous live disturbances. In: Proceedings of the 20th national information systemssecurity conference. [S.l.: s.n.], 1997. p. 353–365. Citado na página 54.

[80] CHEUNG, S. et al. The design of GrIDS: A graph-based intrusion detection system.[S.l.], 1999. Citado na página 54.

[81] KRAWCZYK, P. Citado na página 54.

[82] SIQUEIRA, L.; ABDELOUAHAB, Z. A fault tolerance mechanism for networkintrusion detection system based on intelligent agents (nidia). In: IEEE. SoftwareTechnologies for Future Embedded and Ubiquitous Systems, 2006 and the 2006 SecondInternational Workshop on Collaborative Computing, Integration, and Assurance. SEUS2006/WCCIA 2006. The Fourth IEEE Workshop on. [S.l.], 2006. p. 6–pp. Citado napágina 55.

[83] WEBER, T. S. Tolerância a falhas: conceitos e exemplos. Apostila do Programa dePós-Graduação–Instituto de Informática-UFRGS. Porto Alegre, 2003. Citado na página55.

http://dx.doi.org/10.1007/11554578_7

Referências 104

[84] ARAúJO, J. D. et al. Eicids-elastic and internal cloud-based intrusion detectionsystem. International Journal of Communication Networks and Information Security(IJCNIS), v. 7, n. 1, 2015. Citado 3 vezes nas páginas 56, 57 e 58.

[85] VIEIRA, K. et al. Intrusion detection for grid and cloud computing. IT Professional,IEEE, v. 12, n. 4, p. 38–43, 2010. Citado 3 vezes nas páginas 59, 60 e 61.

[86] VENKATARAMANA, K.; PADMAVATHAMMA, M. Multi-agent intrusiondetection and prevention system for cloud environment. International Journal ofComputer Applications, v. 49, n. 20, p. 24–29, July 2012. Published by Foundation ofComputer Science, New York, USA. Citado 2 vezes nas páginas 61 e 62.

[87] CHUNG, C.-J. et al. Nice: Network intrusion detection and countermeasure selectionin virtual network systems. Dependable and Secure Computing, IEEE Transactions on,v. 10, n. 4, p. 198–211, July 2013. ISSN 1545-5971. Citado 2 vezes nas páginas 63 e 64.

[88] GUEDES, G. T. UML 2: uma abordagem prática. [S.l.]: Novatec Editora, 2009.Citado 2 vezes nas páginas 74 e 76.

protótipo de um sistema de detecção de intrusão para contexto … · 2018-03-01 · duandys f....

Documents