UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS ...siaibib01.univali.br/pdf/Diego Lopes.pdf · utilizados nas redes de computadores, encontra frequentemente uma imediata resposta

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

VULSCANNER - SCANNER DE VULNERABILIDADES DE REDES LÓGICAS

por

Diego Lopes

Itajaí (SC), junho de 2014

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

VULSCANNER - SCANNER DE VULNERABILIDADES DE REDES LÓGICAS

Área de Redes de Computadores

por

Diego Lopes

Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Ademir Goulart, M.Sc.

Itajaí (SC), junho de 2014

Ao meu querido avô Pedro Natividade da Costa.

AGRADECIMENTOS

Primeiramente a Deus;

A minha mãe Lucélia da Costa Lopes por me colocar no caminho do bem;

Agradecimento especial a minha futura esposa Aline Olsson, por todo apoio, incentivo

e compreensão durante toda essa etapa da minha vida;

Aos colegas de sala, trabalho e aos professores.

Ao meu orientador Ademir, pelo incentivo e orientação durante todo o

desenvolvimento do trabalho.

Enfim, a todos que me incentivaram e ajudaram durante a minha jornada acadêmica.

RESUMO

LOPES, Diego. VULSCANNER - Scanner de Vulnerabilidades de redes lógicas. Itajaí, 2014. 69 f. Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2014. Devido à disseminação em larga escala de computadores e dispositivos móveis em redes de transmissão de dados é evidente o crescimento do uso de aplicativos que utilizam arquitetura cliente-servidor. Entretanto, falhas de seguranças são cada vez mais presentes na estrutura de programação desse tipo de sistema. Pessoas mal intencionadas podem usufruir de vulnerabilidades presentes nesses códigos para expor informações de computadores, obter dados confidenciais ou ganhar controle de máquinas ou aplicativos, sem que esse possua autorização. Além disso, falhas na codificação geram falhas ou erros, afetando os fluxos ou processos da aplicação. Devido a esses fatores, surge a necessidade de ferramentas que possuam a capacidade de efetuar uma varredura em uma rede de computadores, identificar serviços ativos e versão, informar possíveis vulnerabilidades descobertas e auxiliar na correção do mesmo. Portanto, a análise dos riscos em uma rede de computadores e o desenvolvimento de um scanner de vulnerabilidades de redes com base na fundamentação teórica aplicada em redes de computadores é de fundamental importância para o contexto de segurança de redes. Palavras-chave: Redes de Computadores. Vulnerabilidades. Scanner.

ABSTRACT

Due to the large-scale deployment of computers and mobile devices in data networks is clear an increase in the use of applications that use client-server architecture. However, computer’s security failures are increasingly present in the programming structure of such systems. Malicious users can take advantage of vulnerabilities present in these codes to expose information in computers, obtain confidential data or gain control of machines or applications, without express permission. Failures in the programming code can generate bugs or errors, affecting the flow or application processes. Because of this type of issue, are necessary tools that have the ability to perform a scan on a computer network, identify active services, list version, report to the end user potential vulnerabilities discovered and assist to correcting the issues. Therefore, analysis of risk in computer networks and development of a network vulnerability scanner based on the theoretical foundation applied in computer networks has fundamental importance to the context of network security. Keywords: Computer Networks. Vulnerabilities. Scanner.

LISTA DE FIGURAS

Figura 1.� Processo de interação do ambiente. ................................................................... 19�Figura 2.� As sete camadas do modelo de referência OSI.................................................. 24�Figura 3.� Representação dos quatro níveis conceituais TCP/IP........................................ 25�Figura 4.� Banco de dados interligados demonstrando um sistema distribuído. ................ 28�Figura 5.� Clientes realizando pedidos a servidores ........................................................... 30�Figura 6.� Ferramentas de exploit são utilizadas para atacar servidores e serviços. .......... 33�Figura 7.� Página principal do National Vulnerability Database. ...................................... 35�Figura 8.� Exemplo de marcações utilizadas pelo XML do NVD ..................................... 36�Figura 9.� Processo de varredura de portas do NMAP ....................................................... 40�Figura 10.� Processo de varredura de portas do NMAP ....................................................... 42�Figura 11.� Exemplo de captura de portas ............................................................................ 43�Figura 12.� Relatório de vulnerabilidades gerado pelo McAfee Foundstone....................... 44�Figura 13.� Painel de controle do McAfee Foundstone........................................................ 45�Figura 14.� Painel de controle central do eEye Retina CS ................................................... 46�Figura 15.� Exemplo de relatório gerado pelo aplicativo SAINT ........................................ 47�Figura 16.� Resultado da varredura do Nessus ..................................................................... 49�Figura 17.� Modelo de casos de uso da ferramenta Servidor ............................................... 53�Figura 18.� Diagrama Entidade Relacionamento do banco de dados................................... 57�Figura 19.� Fluxo de importação de novas informações no banco de dados local. .............. 58�Figura 20.� Parametrização da URL do website NVD. ........................................................ 58�Figura 21.� Análise do arquivo XML. .................................................................................. 59�Figura 22.� Armazenamento dos atributos em memória. ..................................................... 59�Figura 23.� Rotina de inserção ou atualização das informações no banco de dados. ........... 60�Figura 24.� Modelo de casos de uso da ferramenta cliente .................................................. 62�Figura 25.� Fluxo de varredura e identificação de vulnerabilidades. ................................... 66�Figura 26.� Detecção do aplicativo NMAP. ......................................................................... 67�Figura 27.� Tela principal da ferramenta cliente. ................................................................. 68�Figura 28.� Processo de levantamento de serviços da classe ThScanner.java. .................... 69�Figura 29.� Rotina de comparação da descoberta com o banco de dados. ........................... 69�Figura 30.� Instruções SQL para comunicação com o banco de dados. ............................... 70�Figura 31.� Contagem de registros no banco de dados antes da importação........................ 71�Figura 32.� Sintaxe de chamada da aplicação em modo texto. ............................................ 71�Figura 33.� Código de referência é exibido a cada importação no banco de dados. ............ 72�Figura 34.� Resumo final das entradas no banco de dados. ................................................. 72�Figura 35.� Contagem de registros no banco de dados após a importação. ......................... 73�Figura 36.� Checagem inicial no carregamento da aplicação. .............................................. 74�Figura 37.� Varredura da ferramenta cliente em execução. ................................................. 75�Figura 38.� Janela principal da ferramenta cliente populada após escaneamento. ............... 76�Figura 39.� Janela exibindo os serviços detectados pela ferramenta. ................................... 77�Figura 40.� Janela com vulnerabilidades da ferramenta cliente. .......................................... 78�Figura 41.� Lista de vulnerabilidades encontradas no host de teste. .................................... 78�Figura 42.� Detalhamento da vulnerabilidade selecionada. ................................................. 79� �

LISTA DE ABREVIATURAS E SIGLAS

ACK Acknowledgment field significant API Application Programming Interface CVE Common Vulnerabilities and Exposures FIN No more data from sender GNU-GPL General Public License HTML HyperText Markup Language ICMP Internet Control Message Protocol IPv4 Internet Protocol version 4 NVD National Vulnerability Database POC Proof of Concept PUSH Push Function RFC Request For Comments RST Reset the connection SAINT Security Administrator’s Integrated Network Tool SGML Standard Generalized Markup Language SYN Synchronize sequence numbers TCP Transmission Control Protocol TTC Trabalho Técnico-científico de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí URG Urgent Pointer field significant WEB World Wide Web XML eXtensible Markup Language

15

SUMÁRIO

1� INTRODUÇÃO ................................................................................................................... 16�1.1� PROBLEMATIZAÇÃO .................................................................................................. 18�1.1.1� Formulação do Problema .............................................................................................. 18�1.1.2� Solução Proposta ........................................................................................................... 18�1.2� OBJETIVOS .................................................................................................................... 20�1.2.1� Objetivo Geral ............................................................................................................... 20�1.2.2� Objetivos Específicos ................................................................................................... 20�1.3� METODOLOGIA ............................................................................................................ 21�1.4� ESTRUTURA DO TRABALHO .................................................................................... 22 2� FUNDAMENTAÇÃO TEÓRICA ................................................................................... 23�2.1� REDES DE COMPUTADORES ..................................................................................... 23�2.1.1� Protocolo TCP/IP .......................................................................................................... 24�2.1.2� Sistemas Distribuídos ................................................................................................... 28�2.2� VULNERABILIDADES ................................................................................................. 30�2.2.1� Footprinting .................................................................................................................. 32�2.2.2� Varreduras de redes ...................................................................................................... 32�2.2.3� Exploits ......................................................................................................................... 33�2.2.4� Base de dados de Vulnerabilidades............................................................................... 34�2.3� XML ................................................................................................................................. 35�2.3.1� Java.xml.stream.reader ................................................................................................. 37�2.3.2� NMAP4J ....................................................................................................................... 40�2.4� FERRAMENTAS DE AUXÍLIO À IDENTIFICAÇÃO DE SERVIÇOS ...................... 38�2.4.1� NMAP ........................................................................................................................... 39�2.4.2� Metasploit Framework .................................................................................................. 41�2.4.3� Wireshark ...................................................................................................................... 42�2.5� FERRAMENTAS SIMILARES ...................................................................................... 43�2.5.1� Mcafee Foundstone ....................................................................................................... 44�2.5.2� eEye Retina CS ............................................................................................................. 45�2.5.3� SAINT ........................................................................................................................... 46�2.5.4� Nessus ........................................................................................................................... 48�2.5.5� Análise Comparativa ..................................................................................................... 49 3� DESENVOLVIMENTO ............................................................................................... 51�3.1� ESPECIFICAÇÃO DAS FERRAMENTAS ................................................................... 51�3.1.1� Especificação de requisitos do Servidor ....................................................................... 51�3.1.2� Modelagem da ferramenta Servidor ............................................................................. 52�3.1.3� Processo de importação de novas vulnerabilidades no banco de dados ....................... 57�3.1.4� Especificação de requisitos do Cliente ......................................................................... 60�3.1.5� Modelagem da ferramenta Cliente ................................................................................ 61�3.1.6� Processo de varredura e detecção de vulnerabilidades de redes ................................... 65�3.2� TESTES E VALIDAÇÕES ............................................................................................. 70�3.2.1� Ferramenta Servidor ..................................................................................................... 70�3.2.2� Ferramenta Cliente ........................................................................................................ 73 4� CONCLUSÕES ............................................................................................................ 80�4.1� TRABALHOS FUTUROS .............................................................................................. 81�

16

1 INTRODUÇÃO

Na década de 1980, os chamados microcomputadores disseminaram-se rapidamente

pelo mundo, visto o baixo custo e desempenho cada mais elevados. Simultaneamente,

surgiram as primeiras redes locais de computadores (LAN) que causaram uma revolução na

automação dos escritórios e fábricas. A simplicidade da tecnologia Ethernet e seu baixo custo

foram responsáveis pelas primeiras tecnologias de sucesso, em termos de redes de

computadores (CARISSIMI, 2009).

Os cientistas, sejam da área de telecomunicações ou de informática, estão de acordo

com o fato de que essa rede global de informação deverá continuar a ser suportada

basicamente pela tradicional plataforma de protocolos TCP/IP da internet com algumas de

suas extensões (CARISSIMI, 2009).

Sockets são abstrações simplificadas, criadas com o intuito de facilitar o

desenvolvimento de aplicações que envolvam a comunicação entre dois ou mais

computadores interligados por uma rede TCP/IP. O servidor é responsável por abrir um socket

e ouvir eventuais pedidos de conexão. O outro computador, denominado cliente, usualmente

se conecta ao socket do servidor para obter dados (MENDES, 2007).

Footprinting é parte do processo de reconhecimento para a realização de uma

avaliação de segurança se autorizado ou como um prelúdio para um ataque. Esse processo

procura determinar informações de uma entidade por meio de consulta a informação

disponível publicamente (RAUSTIN, 2011).

Fingerprinting é o seguinte passo ao Footprinting e destina-se a identificar o software

executado em hosts visíveis. Essa técnica pode ser um prelúdio para auditar vulnerabilidades

de segurança ou mapear alvos para um possível ataque (RAUSTIN, 2011).

Técnicas de footprinting e fingerprinting permitem descobrir informações detalhadas

sobre computadores e serviços sendo executados em uma determinada rede de computadores.

Através dessas técnicas é possível descobrir e enumerar serviços, versões de aplicações de

rede e suas respectivas vulnerabilidades (SOBRAL, 2013).

Cada novo serviço ou funcionalidade implementada pelos fabricantes de softwares,

utilizados nas redes de computadores, encontra frequentemente uma imediata resposta de

17

hackers e crackers. Esses “usuários” utilizam seus conhecimentos avançados de programação

de computadores, para explorar falhas existentes nos códigos desenvolvidos para essas novas

funcionalidades. O resultado desses ataques pode ser simplesmente uma momentânea

indisponibilidade do serviço (DOS – Denial Of Service) ou, em pior situação, a abertura de

um acesso privilegiado no computador hospedeiro do serviço que sofreu o ataque

(ALMEIDA, 2013).

Um relatório divulgado pela F-Secure detectou que a exploração de vulnerabilidades

de software tornou-se a forma mais popular de ganhar acesso a um computador. Todas as

vulnerabilidades reportadas nos últimos dois anos já tiveram correções de segurança lançadas

por seus fornecedores – um lembrete da importância de manter o software atualizado (F-

SECURE, 2012).

Uma pesquisa sobre os últimos 25 anos de vulnerabilidades em aplicações revela que

de 1988 a 2005, o crescimento no número de vulnerabilidades aumentou, com uma leve

decaída em 2003. O pico foi em 2006, com 6612 relatos, e após, houve um declínio até o ano

de 2012, no qual a preocupação na segurança da rede teve significativa evolução. Após 2012

um aumento significativo nas vulnerabilidades foi novamente detectado (YOUNAN, 2013).

Atualmente, mais de 57 mil vulnerabilidades de redes são conhecidas pelo NVD

(National Vulnerability Database) (NVD, 2013).

Em uma empresa com tipos diferentes de plataforma, talvez com diversas versões do

Unix e Windows, a tarefa de corrigir falhas de segurança é muito mais complexa. Geralmente

a heterogeneidade fornece ao invasor persistente mais possibilidades de encontrar erros. Ela

também aumenta a imprevisibilidade do sistema (BURNETT, 2002).

Portanto, este trabalho contempla o desenvolvimento de uma ferramenta que deverá

encontrar em uma rede de computadores todos os serviços ativos, identificar o nome do

serviço, enumerar a versão e reportar ao usuário final possíveis vulnerabilidades encontradas

durante a varredura efetuada nesta rede.

18

1.1 PROBLEMATIZAÇÃO

1.1.1 Formulação do Problema

Em uma organização, tudo está ligado à informação, e de extrema importância dentro

da mesma. Dessa forma sua seguridade é de suma importância A segurança da informação

funciona em longo prazo, fazendo uma harmonização de seus processos, tarefas, buscando

diminuir os erros e não repassar informações desnecessárias ou sem importância (SILVA;

CARVALHO; TORRES, 2003).

Usuários mal intencionados utilizam brechas na programação ou arquitetura dos

serviços de rede para controlar computadores, roubar dados confidenciais e efetuar ataques de

negação de serviço sem que o mesmo possua autorização para o fim. Aplicativos que fazem

varreduras em redes lógicas são cada vez mais fáceis de encontrar, aliado ao conhecimento de

falhas na programação de serviços de rede simplificam a tarefa do crime cibernético.

Com isso, identifica-se a carência de uma ferramenta gratuita que forneça informações

sobre vulnerabilidades presentes em uma rede lógica e auxilie no processo de correção dessas

brechas, de forma unificada e simples. Desta forma a ferramenta proposta visa promover uma

diminuição de falhas e gastos com as ferramentas atualmente comercializadas por

determinadas empresas.

1.1.2 Solução Proposta

Pretendendo minimizar os riscos de ataques por vulnerabilidades presentes em uma

rede lógica e diminuir os custos envolvidos em adquirir produtos comerciais com o mesmo

objetivo, foi desenvolvida uma ferramenta que faz a análise de serviços ativos em uma rede

de computadores e auxilia na solução de possíveis falhas presentes nesses sistemas.

Foi utilizada uma ferramenta de identificação de serviços de redes sob licença GNU

GPL, aliada a informações do pelo banco de dados do website http://nvd.nist.gov (National

Vulnerability Database).

A solução, portanto foi dividida em dois aplicativos; cliente e servidor. O aplicativo

cliente é responsável por interagir com o usuário e reportar os dados obtidos de

vulnerabilidades presentes na rede.

O cliente armazena temporariamente em memória o resultado da busca efetuada pela

ferramenta de identificação de serviços ativos na rede e executa os algoritmos necessários

19

para comparar com os atributos previamente importados pelo sistema servidor. Neste

ambiente servidor, os dados referentes a falhas foram catalogadas, assim sendo possível a

disponibilidade do mesmo em um gerenciador de banco de dados gratuito na internet.

O aplicativo servidor é responsável pela coleta dos dados de novas vulnerabilidades

disponibilizadas pelo NVD – efetuando a leitura de arquivos XML – através de uma rotina de

agendamento automático. Todos os dias, em um determinado período especificado pelo

administrador do servidor, um processo da aplicação se conecta remotamente ao site do NVD,

efetua o download do arquivo XML, fazer a leitura dos atributos necessários e inclui, altera,

atualiza ou exclui no banco de dados local.

O processo completo da interação que os sistemas executam pode ser observado

conforme Figura 1.

Figura 1. Processo de interação do ambiente.

Ao final do processo de identificação de vulnerabilidades da rede escolhida pelo

usuário, uma janela da aplicação mostra uma breve descrição da vulnerabilidade, a data de

publicação, a severidade da falha, e a página com informações da solução da vulnerabilidade,

geralmente mantida pelo próprio fabricante ou sites da categoria.

20

As ferramentas cliente e servidor foram desenvolvidas para plataformas Windows e

Linux.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Desenvolver uma aplicação que auxilie na descoberta de vulnerabilidades de redes,

utilizando informações das vulnerabilidades disponibilizadas pelo banco de dados do website

National Vulnerability Database.

1.2.2 Objetivos Específicos • Estudar e descrever o processo de descoberta de serviços utilizando as técnicas de

footprinting e fingerprinting;

• Analisar ferramentas similares;

• Pesquisar e analisar identificadores de serviços de rede;

• Pesquisar e definir o processo de importação de informações de vulnerabilidades

conhecidas;

• Elaborar a especificação e modelagem da ferramenta proposta;

• Realizar a implementação da ferramenta de acordo com a modelagem

desenvolvida;

• Efetuar testes visando à validação das funcionalidades e o atendimento aos

requisitos especificados;

• Documentar o trabalho desenvolvido através do relatório final e artigo científico.

21

1.3 METODOLOGIA

A execução deste trabalho foi realizada em cinco etapas principais. São elas: (i)

fundamentação teórica, (ii) pesquisa, (iii) especificação da ferramenta, (iv) desenvolvimento e

validação e (v) documentação.

Na etapa de Fundamentação Teórica (i) procurou-se estudar e compreender os

conceitos teóricos de redes de dados padrão TCP/IP necessário para fundamentação básica na

compreensão do conjunto de protocolos de comunicação entre computadores em rede.

Adicionalmente a etapa de fundamentação teórica, estudos detalhados foram

realizados sobre o processo de identificação de serviços de rede, critério necessário para a

identificação dos serviços ativos em uma determinada rede de computadores.

Foram realizadas consultas em artigos, monografias e livros das áreas de Redes de

Computadores e Segurança da Informação. A metodologia de invasão de uma rede foi

estudada em livros específicos voltados a metodologia de enumeração de serviços através de

técnicas de footprinting e fingerprinting, além de sites na Internet, cujas referências

encontram-se nas referências bibliográficas.

Na etapa de pesquisa (ii), foram realizadas diversas buscas para identificar ferramentas

similares no objetivo de levantar e descrever suas funcionalidades. Nesse processo foi

possível mensurar detalhadamente as características dessas ferramentas, bem como suas

vantagens e desvantagens.

Complementando a etapa de pesquisa, foram analisados e identificados aplicativos que

coletem informações através de portas que escutam requisições de clientes e servidores

através de uma rede, onde foram catalogados pelos principais atributos como facilidade de

implementação, licenciamento de uso e métodos adotados para a função.

Na etapa de especificação da ferramenta (iii) foi realizada a definição da ferramenta

desenvolvida, parte do processo de especificação dos requisitos, elaboração do diagrama de

casos de uso, diagramas de sequencia e diagrama entidade-relacionamento.

Na etapa de desenvolvimento e validação (v) foi efetivado o desenvolvimento da

ferramenta proposta, objetivando transformar os modelos conceituais no software

propriamente especificado. Além disso, a validação foi concretizada através de testes em um

cenário planejado, onde algumas aplicações com vulnerabilidades presentes foram detectadas

22

pelo scanner. Essa etapa foi documentada na seção Testes e Validações, que pode ser

encontrado no Capitulo 3.2.

A documentação (vi) teve como objetivo produzir os documentos contendo os

registros referentes à pesquisa científica, contemplando desde a contextualização da proposta

(problematização e apresentação da solução), aquisição do conhecimento necessário,

desenvolvimento, validação e análise dos resultados obtidos. Além da documentação da

execução do projeto, foi elaborado um artigo científico com o intuito de divulgar o trabalho

realizado.

1.4 ESTRUTURA DO TRABALHO

Este documento está estruturado em 4 capítulos: (i) Introdução; (ii) Fundamentação

Teórica; (iii) Desenvolvimento; e (iv) Conclusões.

Na Introdução, Capítulo 1, o projeto foi descrito sucintamente, onde foi

contextualizada a questão problema e apresentada a proposta de solução, juntamente com o

objetivo geral e os específicos atingidos, além da metodologia utilizada na execução do

trabalho.

No Capítulo 2, Fundamentação Teórica, foi apresentado os conceitos relevantes à

compreensão sobre redes de dados padrão TCP/IP e a compreensão sobre as técnicas de

identificação de serviços de rede. Também foram explanadas ferramentas para auxílio na

etapa de identificação de serviços ativos em redes de computadores, além da análise de

ferramentas similares, contendo características semelhantes às da ferramenta proposta neste

trabalho.

Na seção Desenvolvimento, Capítulo 3, as ferramentas desenvolvidas foram

especificadas e detalhadas, com base no levantamento dos requisitos e da elaboração dos

diagramas de casos de uso, diagramas de sequência e diagrama entidade-relacionamento.

O desenvolvimento, testes, implantação e análise dos resultados obtidos também

foram documentados no Capítulo 3.

No Capítulo 4 (Conclusões), foram contextualizadas as conclusões obtidas com o a

pesquisa do projeto, bem como dificuldades encontradas e trabalhos futuros.

23

2 FUNDAMENTAÇÃO TEÓRICA

Nesse capítulo são apresentados os conceitos relevantes ao processo de identificação

de serviços ativos em uma rede de computadores e ao processo de análise de vulnerabilidades

encontradas relacionado com os objetivos desde trabalho técnico-científico de conclusão de

curso.

A primeira parte considera as definições a respeito do conjunto de protocolos de

comunicação entre computadores em rede, TCP/IP.

Na seção Sistemas Distribuídos, é levantado os requisitos necessários para a

formalização da fundamentação teórica sobre como sistemas que executam operações em

diversos equipamentos que não possuem memória compartilhada para troca de mensagens, o

modelo cliente-servidor.

Em seguida, na seção Identificação de Serviços de Rede, são descritos conceitos

gerais, caracterização e as etapas do processo de identificação dos serviços. Complementando,

são citadas tarefas de sistemas de varredura de portas em uma rede de computadores.

Finalizando o capítulo, a seção Ferramentas Similares traz conceitos relacionados a

diferentes ferramentas disponíveis no mercado, também contendo explanações sobre

funcionamento das ferramentas que desempenham funções semelhantes às da ferramenta

proposta.

2.1 REDES DE COMPUTADORES

Segundo Tanenbaum (1997, p. 2), uma rede de computadores pode ser definida por

um conjunto de computadores conectados, no qual possuem a capacidade de trocar

informações entre si.

Sob o aspecto da utilização de redes de computadores, define-se que a interligação de

computadores em redes é utilizada para diferentes propósitos, de acordo com a necessidade do

negócio. Ainda assim é comum que a grande maioria das corporações possuam múltiplas

redes, concretizando o fato que a o uso de redes de computadores estão em toda a parte.

(COMER, 2007, p. 33).

24

2.1.1 Protocolo TCP/IP

2.1.1.1 Conceitos gerais

Segundo Tanenbaum (1997, p. 20), para reduzir a complexidade de projetos de redes,

a maioria das redes foi organizada para conter uma série de camadas ou níveis, no qual o

conteúdo e a função diferem de uma rede para outra. Uma camada deveria fornecer

determinados serviços para as camadas superiores, abstraindo detalhes da implementação de

cada uma dessas camadas, conforme ilustra a Figura 2, exemplificando o oferecimento de

serviços entre camadas.

Figura 2. As sete camadas do modelo de referência OSI.

Fonte: adaptado de Tanenbaum (1997, p. 20).

Peterson e Davie (2004, p,13) falta bibliografia reforçam a necessidade da abstração

das camadas, pois o sistema em si pode se tornar complexo demais, dificultando a

implementação de sistemas. Sendo assim, o projetista define um modelo unificado que prove

informações para a próxima camada, facilitando a implementação de novos sistemas e

abstraindo ao usuários detalhes de como o modelo foi implementado.

Tanenbaum (1997, p. 33) define o surgimento do modelo de referencia OSI baseado

por uma proposta definida e desenvolvida pela ISO (International Standards Organization).

25

Define-se TCP/IP como uma pilha de protocolos como o TCP (Trasmission Control

Protocol), IP (Internet Protocol), bem como ARP (Address Resolution Protocol), RARP

(Reverse Address Resolution Protocol), UDP (User Datagram Protocol) e ICMP (Internet

Control Message Protocol) (MENDES, p. 18, 2007).

Torres (2001, p. 277) define a arquitetura Ethernet, baseada em TCP/IP como um

padrão no qual as informações e dados são compartilhados e transmitidos através de um meio

de conexão física, como um cabo de rede.

A camada de protocolos TCP/IP é organizada em quatro níveis ou camadas

conceituais, construídas sobre uma quinta camada (Comer, 2007), correspondente ao nível

físico ou de hardware, como mostra a Figura 3.

Figura 3. Representação dos quatro níveis conceituais TCP/IP

Fonte: Comer (2007).

Tanenbaum (1997, p. 26) cita as funções das camadas de pilhas de protocolos que são

apresentadas como se segue:

• Camada de Aplicação: corresponde ao nível mais alto, onde usuários executam

aplicações, através da utilização de serviços disponíveis em uma rede TCP/IP.

Uma aplicação interage com os protocolos da camada de transporte para enviar

ou receber dados. Cada aplicação escolhe o tipo de transporte, que pode ser

uma sequencia de mensagens individuais ou uma cadeia contínua de bytes.

• Camada de Transporte: a finalidade da camada de transporte é prover

comunicação entre aplicações, comumente denominada comunicação fim-a-

26

fim. Essa camada é responsável pelo estabelecimento e controle do fluxo de

dados entre dois hosts. Além disso, pode prover transporte confiável, de modo

a garantir que as informações sejam entregues sem erros e na sequência

correta. A cadeia de dados sendo transmitida é dividida em pacotes, que são

passados para camada seguinte (rede).

• Camada de Rede: a camada de rede trata da comunicação entre hosts. Esta

aceita uma requisição de envio de pacote vinda da camada de transporte, com a

identificação do host para onde o pacote deve ser transmitido. Encapsula o

pacote em um datagrama IP e preenche o cabeçalho do datagrama com os

endereços lógicos de origem e destino, dentre outros dados. Também utiliza

um algoritmo de roteamento para determinar se o datagrama deve ser entregue

diretamente, ou enviado para um gateway. Finalmente, o datagrama e passado

para a interface de rede apropriada, para que este possa ser transmitido.

• Camada de Enlace de Dados: e a camada de nível mais baixo na pilha de

camadas da tecnologia TCP/IP. E responsável por aceitar os datagramas IP,

encapsulá-los em frames, preencher o cabeçalho de cada frame com os

endereços físicos de origem e destino, dentre outros dados, e transmiti-los para

uma rede especificada. Na camada de enlace de dados está o device-driver da

interface de rede, por onde é feita a comunicação com a camada física.

• Camada Física: esta camada corresponde ao nível de hardware, ou meio físico,

que trata dos sinais eletrônicos. Esta recebe os frames da camada de enlace,

convertidos em sinais eletrônicos compatíveis com o meio físico, e os conduz

ate a próxima interface de rede, que pode ser a do host destino ou a do gateway

da rede, caso esta não pertença à rede local.

Para que uma aplicação possa se comunicar com outra aplicação residente em

qualquer máquina da rede é necessário que esta aplicação passe as suas informações para as

camadas do stack de protocolo TCP/IP. Uma forma de passar estas informações é usando uma

API (Aplication Program Interface) padronizando a forma de envio e recebimento entre a

camada de aplicação e a camada de transporte. Uma API padrão para esta troca de

informações é o SOCKETS.

27

Sockets possuem processo de abertura, leitura, escrita e fechamento (open-read-wirte-

close) de uma conexão de dados no qual aborda da entrada e saída do sistema operacional

UNIX (GROSS, 2008, p. 107).

O processo de estabelecimento de uma conexão através da rede é feito através da

conexão (connect) através do cliente para o servidor, e a aceitação (accept) do servidor para o

cliente. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 133).

2.1.1.2 A Camada de Aplicação

Conforme Tanenbaum (1997, p.42) logo acima da camada de transporte se encontra a

camada de aplicação, no qual possui os protocolos para compartilhamento de informações em

uma rede através de aplicações, como TELNET, FTP e SMTP.

Torres (2001, p. 65) afirma que a camada de aplicação do modelo TCP/IP equivale às

camadas de aplicação, sessão e apresentação do modelo OSI. Essa camada faz comunicação

através dos protocolos de aplicação. A camada de aplicação comunica-se com a camada de

transporte através de uma porta específica.

Segundo Orebaugh (p. 20, 2007), na camada de aplicação a aplicação do usuário faz

interação com a rede de computadores e demais serviços de rede.

Scrimger (2002, p.150) destaca uma visão geral sobre as portas da camada de

aplicação, pois o remetente precisa se certificar que a mensagem seja enviada ao destinatário.

Os protocolos de aplicação facilitam essa comunicação, através de portas e soquetes.

Para o protocolo de transporte saber qual é o tipo do pacote dos dados é utilizado um

número de porta, como a porta 80, que geralmente é o protocolo http. O receptor utiliza o

número da porta para saber para qual protocolo deverá entregar o conteúdo, visto que diversas

portas podem ser usadas em uma rede. (TORRES, 2001, p. 65).

A porta utiliza um soquete, que é um dos mecanismos para a comunicação entre

processos de troca de dados de uma rede. Através do soquete, ou socket, que é uma entidade

para a comunicação em uma rede TCP/IP, é possível estabelecer uma comunicação entre os

processos em uma rede de computadores (SCRIMGER, 2002, p. 154).

2.1.2 Sistemas Distribuídos

Um sistema distribuído pode ser definido como um grupo de computadores que

possuem ações independentes que

sistema único. (TANEMBAUM, STEEN, p. 1, 2007).

Segundo Gross (2008, p. 3),

forma praticamente involuntária, visto que com a utilização de redes e

processo de troca de informações

Segundo Tanembaum e Steen (p.2, 2007), a principal meta de um sistema distribuído é

facilitar aos usuários, e às aplicações, o acesso a recursos remotos e seu comparti

maneira controlada e eficiente

Figura 4. Banco de dados interligados demonstrando um sistema distribuído.

Tanembaum (1997, p.2)

sistema distribuídos, pois em uma rede

tarefas e movimentar arquivos. Em um sistema distribuído tudo é feito automaticamente pelo

sistema, sem que o usuário tenha que intervir ou saber qual processo está sendo executado.

Segundo Coulouris,

definidos como sendo componentes interligados como computadores ou sistemas através de

uma rede de computadores que se comunicam e executam tarefas e ações através de

mensagens entre si.

Sistemas Distribuídos


possuem ações independentes que cooperação entre si e que se apresenta ao usuário como um

(TANEMBAUM, STEEN, p. 1, 2007).

Segundo Gross (2008, p. 3), o surgimento dos sistemas distribuídos

forma praticamente involuntária, visto que com a utilização de redes e

processo de troca de informações se tornou comum entre os nós da rede.


facilitar aos usuários, e às aplicações, o acesso a recursos remotos e seu comparti

maneira controlada e eficiente, conforme Figura 4 .

Banco de dados interligados demonstrando um sistema distribuído.

, p.2) desmitifica a terrível confusão entre redes de compu

sistema distribuídos, pois em uma rede o usuário executa processo definidos, como submeter

as e movimentar arquivos. Em um sistema distribuído tudo é feito automaticamente pelo


Segundo Coulouris, Dollimore e Kindberg (2001), sistemas distribuídos podem ser

componentes interligados como computadores ou sistemas através de


28


cooperação entre si e que se apresenta ao usuário como um

o surgimento dos sistemas distribuídos aconteceu de

forma praticamente involuntária, visto que com a utilização de redes em grande escala o

.


facilitar aos usuários, e às aplicações, o acesso a recursos remotos e seu compartilhamento de

Banco de dados interligados demonstrando um sistema distribuído.

desmitifica a terrível confusão entre redes de computadores e

processo definidos, como submeter

as e movimentar arquivos. Em um sistema distribuído tudo é feito automaticamente pelo


(2001), sistemas distribuídos podem ser

componentes interligados como computadores ou sistemas através de


29

Um sistema distribuído é um conjunto de componentes de hardware, geralmente

computadores independentes, e de software interligados através de uma infraestrutura de

comunicação, como uma rede de computadores ou um barramento especial, que cooperam e

se coordenam entre si através da troca de mensagens, e eventualmente, pelo

compartilhamento de memória comum, para execução de aplicações distribuídas pelos

diferentes componentes.

Tanenbaum e Steen (2007) demonstram ainda que um sistema distribuído geralmente

está sempre disponível, mesmo que algumas partes estejam com problemas. Usuário e

aplicação não são notificados que partes estão sendo trocadas ou consertadas, ou que novas

partes foram adicionadas para servir mais usuários e aplicações.

Sendo assim, a utilização de sistemas distribuídos torna-se uma alternativa prática e

geralmente econômica. É possível adicionar computadores ao longo de uma rede e integrá-los

ao sistema distribuído aumentando seu poder de processamento ou desconectar computadores

que necessitem de reparos, sem que o sistema seja interrompido ou que o usuário perceba

estas alterações tornando-se um sistema naturalmente redundante. (JANKE, 2004)

Em um sistema distribuído, os processos possuem papéis e características definidas

fazendo que sua interação seja útil e de forma coerente para todo o processo envolvido. A

divisão das tarefas entre os aplicativos, servidores e outros processos é o fator mais

importante em um projeto de sistemas distribuídos. Essa divisão tem papel fundamental nos

quesitos de segurança, disponibilidade e confiabilidade de um sistema distribuído.

(COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 42).

Muitos dos recursos de informação disponíveis e mantidos em sistemas distribuídos

têm um alto valor essencial para seus usuários. Portanto, sua segurança é de considerável

importância. (GROSS, 2008).

2.1.2.1 Arquitetura Cliente-Servidor

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 40), a arquitetura cliente-

servidor de um sistema é composta de componentes independentes e com suas devidas

especificações, onde o conjunto tem como objetivo assegura o atendimento da demanda atual

e futura, tornando todo o processo confiável, gerencial, adaptável e de custo baixo.

30

Segundo Fernandes (1999, p. 38) o modelo cliente-servidor é uma exigência de

mercado. Devido à disseminação das redes de computadores onde múltiplos usuários podem

utilizar o sistema é necessário que os servidores e clientes estejam interligados através de

inúmeras redes e disponíveis 24 horas por dia.

Para Couloris, Dollimore e Kindberg (2007, p.43) a arquitetura cliente-servidor é a

arquitetura mais citadas quando sistemas distribuídos são discutidos. Historicamente essa

arquitetura é a mais importante e continua sendo amplamente empregada em inúmeros

sistemas.

De acordo com Fernandes (1999. p. 38-39), os componentes da arquitetura cliente-

servidor é definida por serviços e informações providos para determinados computadores

através de outros computadores, conforme pode ser observador na Figura 5.

Figura 5. Clientes realizando pedidos a servidores

Fonte: adaptado de Goulart (2002)

Conforme Coulouris, Dollimore e Kindberg (2007, p. 44-45), os serviços podem estar

implementados em vários computadores diferentes, e executando processos diferentes, porém

com a flexibilidade da interação conforme a necessidade para fornecer um serviço para os

processos clientes, como os usuários.

2.2 VULNERABILIDADES

31

Conforme Caruso e Steffen (1999, p. 167), a interligação cada vez maior dos

computadores entre si por meio de redes de acessos pública aumenta a vulnerabilidade dos

mesmos a ataques externos.

Vulnerabilidade é uma falha em um sistema, como uma brecha ou um bug, no qual um

usuário mal intencionado pode usá-lo para uma intenção não planejada pelo desenvolver do

sistema (ANLEY, 2007).

Vulnerabilidade pode levar a um invasor utilizar o sistema de outra maneira em que

esse foi desenvolvido. Isso pode implicar na indisponibilidade do sistema, elevar os

privilégios de acesso a um nível não intencional, o controle completo do sistema por uma

pessoa não autorizada, e muitas outras possibilidades. Também conhecido como brecha de

segurança ou bug de segurança. (ANLEY, 2007).

Nos primeiros anos da existência da rede de computadores, o principal objetivo era

usado por pesquisadores universitários, para troca de emails, e para compartilhamento de

arquivos e impressoras. Por tratar-se de serviços básicos, a segurança nunca foi muito levada

em consideração. Porém cada vez mais as redes são utilizadas para diversos propósitos, como

executar operações bancárias, fazer compras e utilização de dados financeiros. Sendo assim, a

segurança das redes assumiu um papel fundamental no processo, bem como um problema em

potencial (TANDEBAUM, 1997, p.658).

A possibilidade de interligar computadores e compartilhar dados através de uma rede

de computadores, além de facilitar e troca de informações, trouxe sérios problemas de

segurança, visto que a interligação desses dispositivos abriu brecas para ataques virtuais.

(DIÓGENES; MAUSER, 2011, p. 46).

De acordo com Coulouris (2005, p.237) existe uma demanda generalizada que visa

garantir a privacidade e disponibilidade dos recursos disponibilizados em sistemas

distribuídos, pois ataques contra esses recursos assumem as formas de intromissão,

mascaramento, falsificação e negação de serviço.

As vulnerabilidades são geralmente classificadas em duas categorias: a primeira delas

é causada por erros de programação e a segunda por configurações incorretas de sistemas

operacionais e aplicativos. (BERNSTEIN; BHIMANI, 1997, p.31).

32

2.2.1 Footprinting

Segundo McClure e Scambray (1999, p. 5), footprinting é uma das técnicas de coleta

de informações de possíveis alvos. A técnica permite que invasores criem um perfil completo

da postura de segurança de uma organização. Tendo o apoio de ferramentas e técnicas,

atacantes podem obter informações de um determinado servidor alvo, como nomes de

domínio, escopo de rede e IPs.

O objetivo primário da técnica de footprinting é encontrar informações relacionadas a

internet, intranet, acesso remoto e extranet. Com essa técnica é possível obter uma lista de IP

e redes por meio de consultas whois e zonas de transferência de DNS. Essas informações

podem conter informações valiosas para os atacantes, para que esse seja usado em futuro

ataque. (MCLURE; SCAMBRAY, 1999, p. 5).

2.2.2 Varreduras de redes

McClure e Scambray (1999, p. 32) detalham que o processo de footprinting é o

equivalente a cercar um lugar de informações. Já o processo de varredura é equivalente ao

escaneamento de uma rede a fim de descobrir todos os serviços ativos.

Com o processo de varredura, é possível determinas quais sistemas estão ativos e

alcançáveis através da rede, usando uma série de ferramentas e técnicas, como, por exemplo,

varredura ping, varredura de porta e ferramentas de descobertas automatizadas. (MCLURE,

SCAMBRAY, 1999).

Conforme McClure e Scambray(1999, p. 41), as principais técnicas de varredura de

portas são mencionadas abaixo:

• Varredura de conexão TCP: esse tipo de varredura se conecta à porta alvo e

completa um handshake de 3 etapas completo (SYN, SYN / ACK e ACK).

• Varredura TCP SYN: esta técnica é chamada de “varredura semi-aberta”,

porque não é feita uma conexão TCP completa. Em vez disso, um pacote SYN

é enviado à porta-alvo. Se um SYN / ACK for recebido, isto normalmente

indica que a porta está escutando.

• Varredura TCP FIN:

Com base na RFC 793, o sistema

fechada. Essa técnica normalmente funciona somente em pilhas TCP/IP

baseadas em UNIX.

• Varredura TCP de á

e PUSH para a porta

devolver um RST para cada porta fechada.

• Varredura TCP nula:

793, o sistema

• Varredura UDP:

porta-alvo responde com uma mensagem “ICMP port unreachable” (porta

ICMP impossível de alcançar) a porta está fechada. Do contrário, podemos

deduzir que a posta está aberta.

2.2.3 Exploits

Os passos necessários para explorar uma v

ferramentas ou códigos são descrito como

O conceito exploit

maneira de tirar proveito de uma vulnerabilidade de modo que o siste

forma diferente que o projetado

Figura 6. Ferramentas de exploit

Varredura TCP FIN: essa técnica envia um pacote FIN para a porta

se na RFC 793, o sistema-alvo deve devolver um RST para cada porta


baseadas em UNIX.

Varredura TCP de árvore de natal: essa técnica envia um pacote FIN, URG

e PUSH para a porta-alvo. Com base na RFC 793, o sistema

devolver um RST para cada porta fechada.

Varredura TCP nula: essa técnica desliga todas as flags. Com base na RFC

793, o sistema-alvo deve devolver um RST para cada porta fechada.

Varredura UDP: essa técnica envia um pacote UDP para a porta

alvo responde com uma mensagem “ICMP port unreachable” (porta


deduzir que a posta está aberta.

Os passos necessários para explorar uma vulnerabilidade através de usos de

ferramentas ou códigos são descrito como exploit. (MALERBA, 2010, p. 16).

pode ser definido em significado e ferramenta.

maneira de tirar proveito de uma vulnerabilidade de modo que o sistema alvo reage de uma

forma diferente que o projetado conforme demonstrado na Figura 6.

Ferramentas de exploit são utilizadas para atacar servidores e serviços

33

técnica envia um pacote FIN para a porta-alvo.

alvo deve devolver um RST para cada porta


técnica envia um pacote FIN, URG

ase na RFC 793, o sistema-alvo deve

técnica desliga todas as flags. Com base na RFC

alvo deve devolver um RST para cada porta fechada.

ote UDP para a porta-alvo. Se a

alvo responde com uma mensagem “ICMP port unreachable” (porta


ulnerabilidade através de usos de

(MALERBA, 2010, p. 16).

pode ser definido em significado e ferramenta. Exploit é uma

ma alvo reage de uma

são utilizadas para atacar servidores e serviços.

34

Exploit também pode significar uma ferramenta, conjunto de instruções, ou código que

é usado para tirar vantagem de uma vulnerabilidade. Também conhecido como “prova de

conceito (POC)”. (ANLEY, 2007).

2.2.4 Base de dados de Vulnerabilidades

O CVE (Common Vulnerabilities and Exposures, ou Vulnerabilidades e Exposições

Comuns) é um dicionário de nomes comuns para conhecimento público das vulnerabilidades

de segurança da informação (CVE, 2013).

O principal objetivo do CVE é tornar mais fácil entendimento e compartilhamento de

informações sobre vulnerabilidades utilizando um fator de demarcação comum. (MALERBA,

2010, p. 24).

Para MALERBA (2010, p. 24)

Essa enumeração é realizada através da manutenção de uma lista no qual, valem os seguintes princípios: • Atribuição de um nome padronizado e único a cada vulnerabilidade; • Independência das diferentes perspectivas em que a vulnerabilidade ocorre; • Abertura total voltada ao compartilhamento pleno das informações.

O CVE é um dos recursos utilizado pelo NVD (National Vulnerability Database). O

NVD é um repositório do governo dos EUA de padrões de dados de gerenciamento de

vulnerabilidades. (NVD, 2013).

Segundo o website do NVD (2013), essa informação permite a automação de

gerenciamento de vulnerabilidade, a medida de segurança e conformidade. NVD inclui base

de dados de listas de verificação de segurança, falhas de softwares relacionados à segurança,

erros de configuração, nomes de produtos e métricas de impacto conforme pode ser

visualizado na Figura 7.

35

Figura 7. Página principal do National Vulnerability Database.

Fonte: NVD (2013)

2.3 XML

Em uma rede como a internet, que conecta diferentes tipos de computadores e

plataformas, a informação deve ser acessível, sem restrições impostas por modelos ou

formatos de dados proprietários, os quais possibilitam às empresas que detém seus direitos

alterá-los arbitrariamente. (ALMEIDA, 2002, p. 6).

A linguagem de marcação SGML (Standard Generalized Markup Language) é um

padrão internacional, open source, utilizado para troca informações e de uso de diversos

sistemas operacionais. Um dos objetivos do SGML é garantir que documentos codificados de

acordo com um tipo de padronização poderão ser lidos em qualquer hardware ou software,

com fidelidade de informação (ALMEIDA, 2002, p. 6).

O XML tem como uma de suas características a definição de suas próprias marcas,

pois permite ao autor do documento a criação de um padrão para definição de sessões de

36

informação que auxiliaram na recuperação e disseminação da informação (ALMEIDA, 2002,

p. 6).

Todo o banco de dados do NVD pode ser baixado para uso público através de arquivos

XML. Não há restrições de licença sobre o uso dos dados, no entanto, é desejável creditar o

NVD em produtos, serviços e relatórios que usam seus dados. (NVD, 2013).

As marcações nos arquivos XML definidas pelo NVD permitem a fácil importação

dos dados das vulnerabilidades em um banco de dados comum, conforme se pode observar na

Figura 8.

Figura 8. Exemplo de marcações utilizadas pelo XML do NVD

As principais marcações que são disponibilizadas pelo NVD são apresentadas abaixo:

• Reference Code: código de referencia individual CVE. O texto apresentado

nessa marcação é o nome da vulnerabilidade baseado em sua referência

partícular;

• Published: data em que a vulnerabilidade foi modificada;

• Prod Vendor: fabricante do produto;

• Prod Name: nome do produto;

37

• Ref URL: página de referência sobre a vulnerabilidade descoberta;

• Vers Num: representa a versão do produto que é afetada pela vulnerabilidade;

• Vers Prev: indica que as versões anteriores ao Vers Num também são afetados

pela vulnerabilidade;

• Severity: a gravidade da brecha, conforme determinado pelos analistas da NVD

mensurados por Alta, Média ou Baixa;

• Descript: uma descrição de uma entrada a partir da fonte originaria do CVE;

• Impact: contém uma específica explicação sobre o impacto da vulnerabilidade,

medida pela fonte originaria do CVE.

2.3.1 Java.xml.stream.reader

A classe XMLStreamReader em Java fornece uma API estilo Cursor para analisar

XML. A API permite mover-se de evento para evento no XML, permitindo que você controle

quando deseja mudar para o próximo evento. Um "evento", neste caso, é, por exemplo, o

início de um elemento, o fim de um elemento, um grupo de texto, etc. (JENKOV, 2013).

A interface XMLStreamReader permite o avanço, o acesso somente leitura em

arquivos XML. Ele é projetado para ser o mais baixo nível de programação e mais eficiente

maneira de ler dados XML.

O XMLStreamReader é projetado para interagir em um arquivo XML usando next () e

hasNext (). Os dados podem ser acessados usando métodos como getEventType (),

getNamespaceURI (), getLocalName () e getText ();

O método next () faz com que o leitor leia o próximo evento de análise. O método next

() retorna um inteiro que identifica o tipo de evento acabou de ler. (ORACLE, 2013).

Abaixo a lista de eventos que podem ser encontrador com o XLMStreamReader. Elas

são constantes dos eventos na interface javax.xml.stream.XMLStreamConstants da linguagem

Java. (JENKOV, 2013).

• ATTRIBUTECDATA (dados do atributo);

38

• CHARACTERS (caracteres);

• COMMENT (comentário);

• DTD

• END_DOCUMENT (fim do documento);

• END_ELEMENT (fim do elemento);

• ENTITY_DECLARATION (declaração da entidade);

• ENTITY_REFERENCE (referencia da entidade);

• NAMESPACE (nome do espaço);

• NOTATION_DECLARATION (declaração da notação);

• PROCESSING_INSTRUCTION (instrução de processamento);

• SPACE (espaço);

• START_DOCUMENT (início do documento);

• START_ELEMENT (início do elemento);

2.4 FERRAMENTAS DE AUXÍLIO À IDENTIFICAÇÃO DE SERVIÇOS

O portscan ou varredor de portas é o processo de conectar a portas TCP ou UDP de

um sistema - alvo, com o intuito de identificar a existência ou não de um serviço atrelado

àquela porta. Se tais serviços estiverem mal configurados ou com falhas de segurança, estes

podem comprometer toda a rede deste sistema. (LAZILHA, 2005, p. 148)

A varredura de portas é usada para tentar identificar vulnerabilidades conhecidas de

serviços em portas ativas. Tanto administradores de redes quanto atacantes usam ferramentas

de scanner de portas para investigação de servidores e hosts, mas com diferentes finalidades.

39

O objetivo do administrador é verificar e garantir que as políticas de segurança são

aplicadas. Os atacantes têm como objetivo comprometer os serviços em execução. (NAZEER,

DAIMI, 2008, p. 2).

Um sistema detector de serviços e versões de aplicativos faz uma varredura de portas

que se encontram no estado aberto. Assim que a conexão é feita, o sistema escuta a porta por

alguns segundos. Muitos serviços comuns identificam-se com uma mensagem de boas-vindas

inicial. Essa identificação é conhecida como probe NULL, pois o sistema apenas escuta as

respostas sem o envio de quaisquer dados de requisição. Se o serviço for totalmente

identificado, o processo é finalizado. (LYON, 2013).

Em alguns casos, a informação da versão não é recebida pelo probe Null. Quando isso

acontece, o sistema detector envia requisições baseada no nome do serviço para que o serviço

responda com uma substring a versão do aplicativo. (LYON, 2013).

Se o sistema detector não conseguir reconhecer o serviço através do probe NULL, é

aplicada a técnica de GetRequest para solicitar informações para o serviço. (LYON, 2013).

Cada envio da técnica de GetRequest possuí uma sequência de interrogação (que pode

ser em texto ASCII ou binária). Baseado na resposta que são devolvidas pelo serviço, é

executada uma comparação em uma lista de expressões regulares previamente populada a fim

de determinar a versão e o nome do serviço (LYON, 2013).

2.4.1 NMAP

Nmap é uma ferramenta de código aberto para exploração de rede e auditoria de

segurança. Nmap utiliza pacotes IP de forma inovadora para determinar quais hosts estão

disponíveis na rede, quais serviços (nome da aplicação e versão) os anfitriões estão

oferecendo, quais sistemas operacionais (e versões de SO) eles estão executando, qual tipo de

filtros de pacotes / firewalls estão em uso, e dezenas de outras características. Na Figura 9 é

apresentado um exemplo da utilização do Nmap, retornando informações sobre os sistemas-

alvo (scanme.nmap.org e d0ze), como serviços disponíveis e informações do sistema

operacional. (LYON, 2013).

Figura 9. Processo de varredura de portas do NMAP

Fonte: Nmap (2013)

Nmap é um programa que permite aos administradores de sistemas e curiosos a

explorar grandes redes para determinar quais computadores estão ativos e quais serviços são

fornecidos. (MCCLURE, p. 40,

Segundo Dostoyevsky (2000, p.

portas, acompanhada do nome do serviço, o número, estado, e o protocolo das “portas bem

conhecidas”.

2.4.1.1 NMAP4J

Processo de varredura de portas do NMAP

é um programa que permite aos administradores de sistemas e curiosos a


p. 40, 2000).

Segundo Dostoyevsky (2000, p. 57) o resultado da execução do Nmap é uma lista de


40

é um programa que permite aos administradores de sistemas e curiosos a


o do Nmap é uma lista de


41

NMAP4J é uma biblioteca JAVA que permite a execução, coleta e persistência de

dados de saída do NMAP. (SOURCEFORGE, 2014).

2.4.2 Metasploit Framework

Metasploit tem o como objetivo principal prover um conjunto de ferramentas para

especialistas em penetração de redes desenvolverem exploits (MAYNOR; WILHELM, 2007,

p. 2).

O Metasploit é um open source desenvolvido pela Rapid7, porém desenvolvedores

autônomos tem parte do processo de desenvolvimento. Utiliza um próprio banco de dados de

vulnerabilidades, portanto é possível executar uma variedade de testes, conforme

exemplificado na Figura 10, que demarca que 113 exploits e 74 payloads estão disponíveis

para uso. (TOLEDO, 2012, p. 168).

O Metasploit utiliza o Nmap para identificar serviços em uma rede de dados, porém

também inclui uma larga variedade de varreduras para diferentes tipos de serviços, ajudando a

determinar vulneráveis em potenciais sendo executados em computadores. (AHARONI et al.,

2013).

42

Figura 10. Processo de varredura de portas do NMAP

Fonte: Zumrut (2013)

2.4.3 Wireshark

O Wireshark é um programa que analisa o tráfego de rede, e classificado por

protocolos. Sendo assim se torna um sniffer. É muito eficiente, no qual faz captura e

monitoramento dos dados transmitidos pelos protocolos. Esse monitoramento também é feito

para detectar problemas e visualizar em mais detalhes o funcionamento de cada protocolo

(BASTOS, NEVES, 2008, p. 2).

43

Figura 11. Exemplo de captura de portas

Orebaugh (2006, p. 9) comenta que o Wireshark é um dos melhores sniffers gratuito

desenvolvidos disponível no mercado. O sistema possui inúmeros recursos, uma boa interface

gráfica para o usuário, decodifica mais de 400 protocolos e seu ciclo de desenvolvimento e

manutenção continua ativo.

Segundo Farruca (2009, p. 9)

Wireshark permite capturar e examinar pacotes de dados que passam por determinada interface. Reconhece muitos dos protocolos mais comuns na internet, permite construção de filtros para selecionar a informação mais relevante assim como permite gerar estatísticas e gráficos dos resultados da captura..

2.5 FERRAMENTAS SIMILARES

Scanners de vulnerabilidades são ferramentas automatizadas usadas para identificar

falhas de segurança que afetam um determinado sistema ou aplicação.

Esse tipo de scanner tipicamente trabalha utilizando a técnica de fingerprinting no

sistema operacional do alvo, que identifica a sua versão e tipo, como também todos os

serviços que estão sendo executados.

Uma vez que o processo é executado em um alvo específico, o scanner executa

checagens específicas para determinar se vulnerabilidades existem. (AHARONI et al., 2013).

44

2.5.1 Mcafee Foundstone

O Fondstone Enterprise é um produto baseado em plataforma web e gerenciamento

unificado. Foundstone é rápido, preciso e possui milhares de assinaturas de vulnerabilidades e

checagens. Possui também modulo de escaneamento para aplicações web, mapeamento de

rede e possui a capacidade de identificar problemas em plataformas Windows como patchs de

correção não instalados, bem como a configuração do sistema de antivírus e softwares de

spywares instalados. Um relatório de vulnerabilidade gerado pelo McAfee Foundstone é

demonstrado na Figura 12. (BAYLES et al., 2005, p. 409).

(BAYLES et al., 2005, p. 409).

Figura 12. Relatório de vulnerabilidades gerado pelo McAfee Foundstone

O McAfee Foundstone é projetado para permitir a detecção automática de

vulnerabilidades conhecidas em um determinado conjunto de hosts. A ferramenta também

fornece uma lista atualizada automaticamente de vulnerabilidades para permitir a detecção de

novas vulnerabilidades (OIT, 2010).

A ferramenta fornece uma interface baseada na web, conforme ilustrado na Figura 13,

que permite a criação de um ou mais escaneamentos. A varredura é uma seleção de

vulnerabilidades definida pelo usuário para testar em uma rede escolhida. As varreduras

45

podem ser salvas para serem executadas em um intervalo periódico, permitindo a visualização

de históricos e resultados de exames adicionais executados (OIT, 2010).

Figura 13. Painel de controle do McAfee Foundstone.

Fonte: Pietrofere e Camanaro (2012)

�

A McAfee oferece vários níveis de suporte aos clientes para atender às necessidades

de vários tipos de ambiente. A um preço de pouco menos de 12 mil dólares pelo servidor,

licenças de software, a digitalização de 1.000 IPs e um ano do programa de suporte ouro.

Algumas características incluem suporte técnico por telefone e e-mail, garantia de hardware e

suporte interativo online (STEPHENSON, 2012).

2.5.2 eEye Retina CS

eEye Retina CS é o principal competidor do Mcafee Foundstone. O mesmo oferece

diversas funcionalidades para avaliação de vulnerabilidades como se pode observar na Figura

14, porém em geral é considerado voltado para empresas de pequeno e médio porte. No

entanto, é considerado um produto forte no segmento (BAYLES et al., 2005, p. 409).

Figura 14. Painel de controle central do eEye Retina CS

Fonte: Bushnaq (2009)

A função de eEye é varrer

vulnerabilidades encontradas. (CYBER SECURITY, 2013).

O eEye Retina CS apenas comercializa o software, portanto é nece

equipamentos para a instalação do produto. Por três mil dólares é possível adquirir a licença

anual para varrer até 512 IPs, com suporte básico por telefone, email e online. (WIDE EYE

SECURITY, 2013).

O eEye Retina possuí uma versão comu

com suporte via fórum no site do fabricante. (BEYOUNDTRUST, 2013).

2.5.3 SAINT

nel de controle central do eEye Retina CS

A função de eEye é varrer todos os hosts em uma rede e reportar sobre as

vulnerabilidades encontradas. (CYBER SECURITY, 2013).

O eEye Retina CS apenas comercializa o software, portanto é nece


até 512 IPs, com suporte básico por telefone, email e online. (WIDE EYE

O eEye Retina possuí uma versão comunitária, no qual é possível


46

todos os hosts em uma rede e reportar sobre as

O eEye Retina CS apenas comercializa o software, portanto é necessário a compra de


até 512 IPs, com suporte básico por telefone, email e online. (WIDE EYE

nitária, no qual é possível varrer até 128 hosts,


47

SAINT (Security Administrator’s Integrated Network Tool, ou Ferramenta de Rede

Integrada de Administradores de Segurança) é uma ferramenta de avaliação de

vulnerabilidade comercial como o eEye Retina. Ao contrário dos sistemas que rodam

exclusivamente em ambiente Windows, SAINT só funciona em ambiente UNIX. SAINT foi

desenvolvido para ser livre e em código aberto, porém tornou-se um produto comercial.

(CYBER SECURITY, 2013).

Durante a verificação, o processo de varredura é exibido em tempo real. Quando a

varredura é concluída, os resultados podem ser facilmente visualizados e exportados para um

relatório, conforme ilustrado na Figura 15.

Figura 15. Exemplo de relatório gerado pelo aplicativo SAINT

Fonte: SAINT (2010)

48

SAINT fornece suporte 8/5 por telefone sem nenhum custo adicional. Para suporte

24/7 pode ser adquirido por 10% do valor total da licença anual do software. A um preço de

19 mil dólares por ano para uma licença de varredura de IPs classe C, SAINT fornece uma

série de funcionalidades, incluindo testes de penetração e relatórios de qualidade.

(STEPHENSON, 2011).

2.5.4 Nessus

Nessus é o mais popular produto de avaliação de vulnerabilidades do mundo, com

mais de 75 mil downloads efetuados e não somente por ser um software de código aberto

(BAYLES et al., 2005, p. 409).

Essa ferramenta tem uma instalação bem simples. O pequeno componente de servidor

pode ser instalado em uma máquina de médio porte, com pelo menos 2GB de memória.

Depois do servidor instalado, licenciado e iniciado, o mesmo baixa instantaneamente as

últimas atualizações de vulnerabilidades e o sistema fica disponível para iniciar as

verificações. Pelo console WEB que pode ser acessado de qualquer máquina da rede, a

varredura pode ser iniciada, conforme demonstrado na Figura 16. (STEPHENSON, 2012)

Figura 16. Resultado da varredura do Nessus

Fonte: Mohit (2012)

A licença comercial por 1 ano é vendida por 3.600 dólares e conta com suporte do

fabricante. Essa modalidade de licenciamento não possui limitação de varreduras por IP. A

versão gratuita permite apenas

(TENABLE, 2013).

2.5.5 Análise Comparativa

Verifica-se no Quadro

vulnerabilidades disponíveis no mercado:

Quadro 1. Análise Comparativa de Ferramentas Nome Licenciamento

McAfee Foundstone

Comercial

eEye Retina CS Comercial

Resultado da varredura do Nessus



versão gratuita permite apenas varrer até 16 IPs por vez, e não conta com suporte.

Análise Comparativa

no Quadro 1, uma breve análise comparativa dos principais scanners de

vulnerabilidades disponíveis no mercado:

Análise Comparativa de Ferramentas Similares. Licenciamento Requisitos N. de IP por

scan Suporte

1 Servidor com Processador 2.4Ghz Memória 2GB

Ilimitado EmailTelefoneOnline

1 Servidor com Processador 2.4Ghz

512 EmailTelefoneOnline

49



por vez, e não conta com suporte.

1, uma breve análise comparativa dos principais scanners de

Suporte Custo Anual

Email Telefone Online

$12.000,00

Email Telefone Online

$3.000,00

50

Memória 1GB eEye Retina Community

Gratuito 1 Servidor com Processador 2.4Ghz Memória 1GB

128 Fórum Nenhum

SAINT Comercial 1 Servidor com Processador 1.6 Ghz Memória 2GB

Ilimitado Email Telefone

$8.500,00

Nessus Comercial 1 Servidor com Processador 2.0 Ghz Memória 2GB

Ilimitado Email Telefone

$3.600,00

Nessus Home Gratuito 1 Servidor com Processador 2.0 Ghz Memória 2GB

16 Nenhum Nenhum

51

3 DESENVOLVIMENTO

As seções seguintes destinam-se à especificação das ferramentas desenvolvidas, a fim

de possibilitar uma visão amplificada sobre o produto construído, contemplando a explicação

detalhada do processo de varredura e detecção de vulnerabilidades de redes e atualização do

banco de dados de vulnerabilidades, além dos requisitos e regras de negócio e a elaboração do

diagrama de casos de uso, diagrama entidade-relacionamento e diagrama de sequência.

3.1 ESPECIFICAÇÃO DAS FERRAMENTAS

3.1.1 Especificação de requisitos do Servidor

A análise dos requisitos da ferramenta proposta foi realizada através do levantamento

de ferramentas similares e pelos fundamentos teóricos apresentados na seção Fundamentação

Teórica, disponibilizada ao longo do artigo.

3.1.1.1 Requisitos funcionais (RF)

Para a ferramenta Servidor, os seguintes requisitos funcionais são propostos:

• RF01: deverá realizar o download de arquivo XML.

• RF02: a ferramenta deverá realizar a análise de novas vulnerabilidades a partir

de um arquivo XML.

• RF03: a ferramenta deverá inserir, atualizar e excluir informações de

vulnerabilidades através da análise do arquivo XML.

3.1.1.2 Requisitos não funcionais (RNF)

Os requisitos não-funcionais são listados a seguir:

• RNF01: a ferramenta deverá se comunicar com o banco de dados Mysql.

• RNF02: a ferramenta deverá possuir capacidade para ser executada em

ambientes Linux.

• RNF03: a ferramenta deverá ser desenvolvida em linguagem JAVA.

52

• RNF04: a ferramenta deverá fazer uso de API para ler o arquivo XML.

• RNF05: para o funcionamento da ferramenta, o host deve possuir acesso a

internet para download de novas informações.

• RNF06: a ferramenta não realizará a identificação de vulnerabilidades não

cadastradas no arquivo XML.

3.1.1.3 Regras de negócio (RN)

As regras de negócio da ferramenta proposta são:

• RN01: O arquivo XML deverá ao menos possuir uma entrada.

• RN02: O arquivo XML deverá possuir as seguintes informações:

o Código de referência;

o Data de publicação;

o Fabricante;

o Nome do produto;

o Página de referência;

o Versão do produto;

o Gravidade;

o Descrição;

o Impacto.

3.1.2 Modelagem da ferramenta Servidor

Nesta seção são informados os diagramas produzidos durante a modelagem da

ferramenta proposta no ambiente Servidor.

3.1.2.1 Casos de uso

53

O modelo de casos de uso da ferramenta proposta possui três casos de uso e um ator,

conforme ilustrado na Figura 17.

Figura 17. Modelo de casos de uso da ferramenta Servidor

O objeto denominado servidor é responsável pela importação dos registros do NVD.

Ele também é responsável pela classificação da importação, criterizando as informações que

devem ser inseridas, atualizados ou removidas do banco de dados.

Os casos de uso ilustrados na Figura 17 serão descritos a seguir, juntamente com seus

respectivos vínculos com os requisitos funcionais, regras de negócios, pré-condições e pós-

condições.

Caso de Uso: Insere registro (UC01.01)

Trata-se da importação de novos dados de vulnerabilidades que não foram importadas

previamente no banco de dados da ferramenta servidor. Sendo assim, é feito uma comparação

entre o código de referência a ser importado com os códigos de referência presentes no banco

de dados. Caso o código de referência ainda não exista, as novas informações são inseridas.

Relações:

uc uc uc UC01 - Utilização da ferramenta serv idor

UC01.01 - InsereRegistros

UC01.02 - AtualizaRegistro

UC01.03 - Remov eRegistro

54






o Fabricante;

o Nome do produto;



o Gravidade;

o Descrição;

o Impacto.

Condições:

• Pré-condição: o registro não existe no banco de dados.

• Pós-condição: o código de referência foi validado, e as informações inseridas

no banco de dados.

Caso de Uso: Atualiza Registro (UC01.02)

Responsável pela atualização dos dados existentes no banco de dados com base nas

informações providas pelo arquivo XML.

Baseado pelo código de referência da vulnerabilidade, uma rotina de comparação

encontra o registro e atualiza as informações do banco de dados.

55

Relações:






o Fabricante;

o Nome do produto;



o Gravidade;

o Descrição;

o Impacto.

Condições:

• Pré-condição: o registro já existe no banco de dados.

• Pós-condição: o código de referência foi encontrado no banco de dados, e os

atributos foram atualizados.

Caso de Uso: Exclui Registro (UC01.03)

Caso o arquivo XML sinalize que uma vulnerabilidade contém inconformidades, o

sistema recebe a informação e remove do banco de dados.

Relações:


56





o Fabricante;

o Nome do produto;



o Gravidade;

o Descrição;

o Impacto.

Condições:

• Pré-condição: o registro já existe no banco de dados.

• Pós-condição: o código de referência foi encontrado no banco de dados, e os

atributos foram removidos.

3.1.2.2 Diagrama entidade relacionamento

O diagrama entidade relacionamento(DER) descreve o modelo dados da ferramenta

servidor com alto nível de abstração. O DER da ferramenta servidor pode ser verificado na

Figura 18.

57

Figura 18. Diagrama Entidade Relacionamento do banco de dados.

3.1.3 Processo de importação de novas vulnerabilidades no banco de dados

O processo de importação de novos dados na base de dados de vulnerabilidades é

descritos em seguida.

• Download do arquivo XML de vulnerabilidades do National Vulnerability

Database;

• Análise do arquivo, ou seja, importar novos dados, atualizar informações

existentes, excluir marcações incorretas sinalizadas pelo NVD;

• Importação no banco de dados.

A Figura 19 demonstra o fluxo de tarefas do processo de importação de novos dados.

58

Figura 19. Fluxo de importação de novas informações no banco de dados local.

Através de uma rotina diária, a ferramenta servidor faz uma conexão no website do

NVD. Em seguida, o mesmo faz o download do arquivo XML mais recente disponibilizado

pelo site, conforme apresentado na Figura 20.

Figura 20. Parametrização da URL do website NVD.

Uma das rotinas internas da ferramenta é responsável por analisar o arquivo XML,

através do coletando as informações necessárias para a importação dos dados. A análise

inicial permite decidir se uma vulnerabilidade será adicionada ou apenas atualizada, caso

exista, conforme ilustrado na Figura 21.

59

Figura 21. Análise do arquivo XML.

Após a análise do arquivo, os atributos necessários para importação no banco de dados

é escrita em memória, para posteriormente ser enviada ao banco de dados, como pode ser

visto na Figura 22.

Figura 22. Armazenamento dos atributos em memória.

Por fim, a rotina ainda é responsável por atualizar dados existentes e/ou excluir

informações sinalizadas pelo NVD.

60

Figura 23. Rotina de inserção ou atualização das informações no banco de dados.

3.1.4 Especificação de requisitos do Cliente

A análise dos requisitos da ferramenta proposta foi realizada através do levantamento

de ferramentas similares e pelos estudos apresentados na seção Fundamentação Teóricos,

disponibilizada ao longo do artigo.

3.1.4.1 Requisitos funcionais (RF)

Para a ferramenta proposta, foram definidos os seguintes requisitos funcionais:

• RF01: deverá ser possível configurar o escopo da rede a ser varrida.

• RF02: a ferramenta deverá realizar a análise de vulnerabilidades em uma

determinada rede lógica.

• RF03: a ferramenta deverá retornar ao usuário um relatório com o resultado da

análise.

3.1.4.2 Requisitos não funcionais (RNF)

Os requisitos não-funcionais podem ser apresentados como segue:

• RNF01: a ferramenta deverá se comunicar com o banco de dados Mysql.

• RNF02: a ferramenta deverá possuir capacidade para ser executada em

ambientes Windows e Linux.

61


• RNF04: a ferramenta deverá utilizar o aplicativo NMAP para identificar os

serviços ativos.

• RNF05: a ferramenta deverá fazer uso de API para integrar os resultados do

NMAP dentro da ferramenta proposta.

3.1.4.3 Regras de negócio (RN)

As regras de negócio da ferramenta proposta são:

• RN01: para o funcionamento da ferramenta, deverá ser parametrizado o escopo

da rede para a execução da varredura.

• RN02: a identificação dos serviços de rede deverá ser realizada pelo NMAP.

• RN03: o resultado da análise deverá conter o código de referencia, a data da

publicação da vulnerabilidade, as informações do produto, a severidade da

falha, descrição da vulnerabilidade e o impacto da mesma.

3.1.5 Modelagem da ferramenta Cliente

Nesta seção são informados os diagramas produzidos durante a modelagem da

ferramenta proposta no ambiente Cliente.

3.1.5.1 Casos de uso

O modelo de casos de uso da ferramenta proposta possui três casos de uso e um ator,

conforme ilustrado na Figura 24.

62

Figura 24. Modelo de casos de uso da ferramenta cliente

O ator chamado usuário corresponde ao operador do sistema cliente, que através da

janela principal da aplicação, fará a interação com a ferramenta. O outro ator, denominado

Servidor representa o sistema que proverá a informação das vulnerabilidades descobertas pelo

sistema cliente.

Os casos de uso ilustrados na Figura 24 serão descritos a seguir, juntamente com seus

respectivos vínculos com os requisitos funcionais, regras de negócios, pré-condições e pós-

condições.

Caso de Uso: Parametriza ferramenta (UC01.01)

Trata-se da definição da parametrização do ambiente lógico da ferramenta. Através da

parametrização do escopo de IP que o usuário definir, será possível iniciar a varredura e

identificação dos serviços ativos na rede.

Relações:

• RF01: deverá ser possível configurar o escopo da rede a ser varrida.

• RN01: para o funcionamento da ferramenta, deverá ser parametrizado o escopo

da rede para a execução da varredura.

uc uc UC01 - Utilização da ferramenta Cliente

Usuário

UC01.01 - Parametriza ferramenta

UC01.02 - Solicita varredura

UC01.03 - Descoberta de Vulnerabilidades

63

Condições:

• Pós-condição: o escopo de IP foi definido na ferramenta e a varredura foi

iniciada.

Caso de Uso: Solicita varredura (UC01.02)

Responsável pelo recebimento da informação do escopo do IP, além da inicialização e

requisição da varredura na rede especificada.

A requisição da varredura irá dar o comando de inicialização do NMAP para que esse

possa iniciar a pesquisa dos serviços ativos na rede. Durante a execução da varredura, os

resultados serão armazenados em memória, para comparação com o banco de dados das

vulnerabilidades e finalmente retornar o relatório de vulnerabilidades encontradas.

Relações:




análise.

• RN02: a identificação dos serviços de rede deverá ser realizada pelo NMAP.

• RN03: o resultado da análise deverá conter o código de referencia, a data da

publicação da vulnerabilidade, as informações do produto, a severidade da

falha, descrição da vulnerabilidade e o impacto da mesma.

Condições:

• Pré-condição: o ambiente deverá ter sido devidamente parametrizado com o

escopo de ips a ser varrido.

• Pós-condição: a varredura foi iniciada com sucesso e os dados obtidos foram

armazenados em memória.

64

Caso de Uso: Descoberta de vulnerabilidades (UC01.03)

Consiste na comparação dos resultados obtidos pela varredura com os dados presentes

no banco de dados de vulnerabilidades descobertas.

Sua atuação depende exclusivamente do caso de uso UC01.02, ou seja, sua execução

será dada após a execução do caso de uso UC01.02, como também o resultado das

vulnerabilidades presentes na rede lógica.

Relações:




análise.

• RNF01: a ferramenta deverá se comunicar com o banco de dados Mysql para

comparação dos dados obtidos pela varredura com os dados de

vulnerabilidades importados no banco.


• RNF04: a ferramenta deverá utilizar o aplicativo NMAP para identificar os

serviços ativos.

• RNF05: a ferramenta deverá fazer uso de API para integrar os resultados do

NMAP dentro da ferramenta proposta.

• RNF06: a ferramenta não realizará a identificação de vulnerabilidades não

cadastradas previamente no banco de dados de vulnerabilidades.

Condições:

• Pré-condição: o ambiente deverá ter sido devidamente parametrizado.

• Pós-condição: a varredura foi realizada com sucesso e o relatório foi exibido ao

usuário no fim da execução da tarefa.

65

3.1.6 Processo de varredura e detecção de vulnerabilidades de redes

Através dos estudos realizados na Fundamentação Teórica, ficou definido que a

enumeração de serviços ativos seria efetuada pelo software NMAP.

A integração dos dados obtidos pelo NMAP com a interface cliente foi desenvolvida

com base na API Nmap4j, abordado na etapa de Fundamentação Teórica, em NMAP4J.

Os processos de análise de vulnerabilidades em uma rede lógica serão compostos pelas

seguintes atividades:

• Verificação se o aplicativo NMAP está instalado;

• Verificação de acesso à internet;

• Verificação de acesso ao servidor de vulnerabilidades;

• Usuário faz especificação da rede lógica IPv4 a ser varrida;

• Varredura de dispositivos de redes ativos;

• Detecção e enumeração de serviços sendo executados pelos dispositivos;

• Análise dos dados coletados com as informações identificadas pelo banco

de dados de vulnerabilidades descobertas;

• Exibição de relatório de vulnerabilidades presentes na rede especificada.

As atividades listadas acima são desempenhadas pela interface cliente. As atividades

que serão executadas para a importação das informações de vulnerabilidades na interface

servidor serão demonstradas posteriormente.

A Figura 25 ilustra o fluxo de tarefas do processo de varredura da rede lógica.

66

Figura 25. Fluxo de varredura e identificação de vulnerabilidades.

O usuário deverá executar o programa em sua estação de trabalho. Após os requisitos

necessários forem checados pelo programa através da classe Loading.java; no caso verificar

se o aplicativo NMAP está instalado, se o computador possui acesso à internet e se o servidor

está disponível; o mesmo deve informar na janela da aplicação o escopo da rede que deseja

fazer a varredura. O processo de análise de requisitos pode ser verificado na Figura 26.

67

�

Figura 26. Detecção do aplicativo NMAP.

Após o usuário inserir a informação do escopo de IPs e acionar o botão de início, o aplicativo

iniciará a varredura mediante a definição do escopo da rede.

68

Figura 27. Tela principal da ferramenta cliente.

O aplicativo cliente faz inicialmente o escaneamento para identificar os dispositivos de

rede ativos na rede. Após a etapa de verificação de ativos na rede, o aplicativo inicia a

sequência de algoritmos para identificar e enumerar os serviços sendo executados no

dispositivo.

Os dados coletados da rede são armazenados em memória até que a varredura seja

concluída através da classe ThScanner.java.

69

Figura 28. Processo de levantamento de serviços da classe ThScanner.java.

Uma vez que a varredura esteja completada, os dados dos serviços de rede são

comparados com o banco de dados de vulnerabilidades descobertas, conforme a Figura 29.

Figura 29. Rotina de comparação da descoberta com o banco de dados.

Caso algum serviço possua a mesma identificação do cadastro do banco de dados, um

relatório será exibido para o usuário, com a descrição da vulnerabilidade, bem como dados

para a resolução do problema.

As instruções SQL utilizadas para comparação com o banco de dados encontram-se na

classe controle.ControllerVuln.java, conforme Figura 30.

70

Figura 30. Instruções SQL para comunicação com o banco de dados.

3.2 TESTES E VALIDAÇÕES

A seção de testes e validações foi dividida em duas partes, para maior facilidade de

compreensão.

3.2.1 Ferramenta Servidor

Para os testes e validações da ferramenta servidor foram utilizados os seguintes

requisitos:

• Computador com acesso a internet;

• Sistema Operacional Fedora Linux 20 64 bits;

• Oracle Java Versão 7 Atualização 55;

Primeiramente, o banco de dados foi populado com dados iniciais. Na Figura 31 pode-

se observar a instrução SQL de contagem de registros inseridos na tabela de vulnerabilidades.

Figura 31. Contagem de registros no banco de dados

Após a definição de

servidor, através de linha de comando, para que uma atualização na base de dados

iniciada.

A sintaxe da linha do comando é definida para chamada pela máquina virtual java,

seguido do comando –cp, o caminho da API do conector Mysql, separado por : e o caminho

da ferramenta servidor.

Figura 32. Sintaxe de chamada da aplicação em modo texto.

Após alguns instantes, o download do arquivo XML é efetuado e a leitura das

vulnerabilidades é iniciada. O

deve ser importada caso seja nova, ou atualizada caso essa seja antiga. As vulnerabilidades

que foram revisadas pelo NVD e rejeitadas, ou seja, não devem mais ser consideradas,

também é determinado nesse momento

referência é mostrado na tela, conforme demonstrado na Figura

Contagem de registros no banco de dados antes da importação

Após a definição de 61055 vulnerabilidades cadastradas, foi executada

linha de comando, para que uma atualização na base de dados

da linha do comando é definida para chamada pela máquina virtual java,

cp, o caminho da API do conector Mysql, separado por : e o caminho

Sintaxe de chamada da aplicação em modo texto.


vulnerabilidades é iniciada. O algoritmo faz a verificação para determinar se a vul

caso seja nova, ou atualizada caso essa seja antiga. As vulnerabilidades


nesse momento. A cada iteração na vulnerabilidade, o código de

referência é mostrado na tela, conforme demonstrado na Figura 33.

71

antes da importação.

executada a ferramenta

linha de comando, para que uma atualização na base de dados fosse

da linha do comando é definida para chamada pela máquina virtual java,

cp, o caminho da API do conector Mysql, separado por : e o caminho

Sintaxe de chamada da aplicação em modo texto.


algoritmo faz a verificação para determinar se a vulnerabilidade

caso seja nova, ou atualizada caso essa seja antiga. As vulnerabilidades


. A cada iteração na vulnerabilidade, o código de

Figura 33. Código de referência é exibido a cada importação no banco de dados.

Ao final do processo, o

Figura 36.

Figura 34. Resumo final das entradas no banco de dados.

Para mensurar a efetividade da importação, a instrução de contagem do SQL é

novamente executada, exibindo o total de

acordo com o resumo apresentado pela ferramenta servidor.

Código de referência é exibido a cada importação no banco de dados.

Ao final do processo, o resumo de importações é exibido, conforme ilustrado na

Resumo final das entradas no banco de dados.


novamente executada, exibindo o total de 61229 vulnerabilidades, sendo essa numeração de

apresentado pela ferramenta servidor.

72

Código de referência é exibido a cada importação no banco de dados.

de importações é exibido, conforme ilustrado na


vulnerabilidades, sendo essa numeração de

Figura 35. Contagem de registros no banco de dados após a importação.

3.2.2 Ferramenta Cliente

Os testes efetuados na ferramenta cliente seguiram os padrões

• Computador com acesso a internet;

• Sistema operacional Fedora 20;

• 1 servidor com Apache vulnerável instalado;

• 1 servidor com Mysql vulnerável instalado;

• 1 servidor com Microsoft IIS vulnerável instalado;

• Roteador de rede com capacidade

• Modem ADSL com SSH vulnerável ativado;

Após a inicialização de todos os

executada. A tela de carregamento da aplicação faz as verificações necessárias para que o

escaneamento seja possível. Para que todos os requisitos sejam atendidos as seguintes regras

são verificadas:

• NMAP deve estar instalado no computador;

Contagem de registros no banco de dados após a importação.

Ferramenta Cliente

Os testes efetuados na ferramenta cliente seguiram os padrões estabelecidos abaixo:

Computador com acesso a internet;

Sistema operacional Fedora 20;

1 servidor com Apache vulnerável instalado;

1 servidor com Mysql vulnerável instalado;

1 servidor com Microsoft IIS vulnerável instalado;

Roteador de rede com capacidade de servir endereços IPs para clientes;

Modem ADSL com SSH vulnerável ativado;

Após a inicialização de todos os componentes do teste, a ferramenta cliente foi

A tela de carregamento da aplicação faz as verificações necessárias para que o


deve estar instalado no computador;

73

Contagem de registros no banco de dados após a importação.

estabelecidos abaixo:

de servir endereços IPs para clientes;

, a ferramenta cliente foi

A tela de carregamento da aplicação faz as verificações necessárias para que o


• Acesso à internet;

• Servidor disponível;

Caso algum desses requisitos não seja atendido, o usuário

faça os ajustes necessários. A Figura 3

Figura 36. Checagem inicial no carregamento da aplicação.

Após as checagens necessárias

No teste executado, foi escolhida a rede

foi pressionado o botão iniciar. Como se pode observar na Figura 3

canto direito inferior da janela exibe a mensagem “executando” o que significa que a

aplicação iniciou a varredura.

Acesso à internet;

Servidor disponível;

Caso algum desses requisitos não seja atendido, o usuário é notif

faça os ajustes necessários. A Figura 36 demonstra uma das verificações sendo efetuada

Checagem inicial no carregamento da aplicação.

as checagens necessárias, foi informado o escopo de IP para iniciar a varredura.

No teste executado, foi escolhida a rede IP 10.1.1.1 até 10.1.1.20. Após a inserção do mesmo,

foi pressionado o botão iniciar. Como se pode observar na Figura 37, o status da varredura, no

ito inferior da janela exibe a mensagem “executando” o que significa que a

aplicação iniciou a varredura.

74

é notificado para que esse

demonstra uma das verificações sendo efetuada.

, foi informado o escopo de IP para iniciar a varredura.

10.1.1.20. Após a inserção do mesmo,

, o status da varredura, no

ito inferior da janela exibe a mensagem “executando” o que significa que a

75

Figura 37. Varredura da ferramenta cliente em execução.

Ao final do processo, a lista de serviços e vulnerabilidades é exibida na tabela da

janela principal da ferramenta, bem como o resumo é apresentado no quadro no canto

esquerdo inferior da aplicação, como se pode verificar na Figura 38.

Figura 38. Janela principal da ferramenta cliente populada após escaneamento.

Para determinar mais detalhes em cada host

do mouse uma dos dispositivos na rede foi selecionado, e logo em seguida o botão “+

Detalhes” foi clicado.

No teste executado, o host 10.1.1.1 foi selecionado, e detalhes da verificação foram

exibidos em uma nova janela nomeada Detalhes da Descoberta, conforme demonstrado na

Figura 39.

Janela principal da ferramenta cliente populada após escaneamento.

Para determinar mais detalhes em cada host encontrado pelo sistema, através do clique



janela nomeada Detalhes da Descoberta, conforme demonstrado na

76

Janela principal da ferramenta cliente populada após escaneamento.

encontrado pelo sistema, através do clique



janela nomeada Detalhes da Descoberta, conforme demonstrado na

Figura 39. Janela exibindo os serviços detectados pela ferramenta.

Nesse teste, o botão “+ Detalhes” fica indisponível, visto que o host não apresentou

vulnerabilidades.

Retrocedendo o teste para a janela principal, um segundo host foi selecionado. O host

10.1.1.2, com o serviço Apache 2.0.59 instalado, foi selecionado para avaliar a eficácia do

escaneamento.

A Figura 40 ilustra a lista de serviç

Apache na versão 2.0.59 sendo escutada em uma porta não convencional, no caso na porta 81.

Janela exibindo os serviços detectados pela ferramenta.


o teste para a janela principal, um segundo host foi selecionado. O host


ilustra a lista de serviços encontrado no host 10.1.1.2, bem com


77


o teste para a janela principal, um segundo host foi selecionado. O host


os encontrado no host 10.1.1.2, bem como o


Figura 40. Janela com vulnerabilidades da ferramenta cliente.

Na aba vulnerabilidades da janela Detalhes da Descoberta é possível identificar as

falhas de segurança do produto, exibidos pelas colunas Produto, Código de Referência, Data

de Publicação da Vulnerabilidade e a Severid

Figura 41. Lista de vulnerabilidades encontradas no host de teste.

Janela com vulnerabilidades da ferramenta cliente.


produto, exibidos pelas colunas Produto, Código de Referência, Data

de Publicação da Vulnerabilidade e a Severidade da mesma, conforme Figura 4

Lista de vulnerabilidades encontradas no host de teste.

78


produto, exibidos pelas colunas Produto, Código de Referência, Data

ade da mesma, conforme Figura 41.

É possível encontrar mais detalhes da vulnerabilidade, selecionando uma entrada na

tabela, e pressionando o botão “+ Detalhes”.

2007-3304.

Figura 42. Detalhamento da vulnerabilidade selecionada

Na janela Descrição da

falha, importado previamente do banco de dados da NVD. Um placar em formato de sinaleira

informa visualmente a severidade da vulnerabilidade, podendo ser vermelha para grave,

amarelo para média e verde para baixa.

No caso acima, o computador possuía a versão do apache 2.0.59, no qual possui uma

vulnerabilidade em relação ao modulo Prefork MPM, que permite que usuários locais utilizem

um ataque de negação de serviço.

Os testes demonstraram que a f

mediante aos serviços que foram detectados pelo NMAP


tabela, e pressionando o botão “+ Detalhes”. A Figura 42 mostra a vulnerabilidade CVE

Detalhamento da vulnerabilidade selecionada.

anela Descrição da Vulnerabilidade é possível encontrar um texto da descrição da


visualmente a severidade da vulnerabilidade, podendo ser vermelha para grave,

e verde para baixa.

computador possuía a versão do apache 2.0.59, no qual possui uma


um ataque de negação de serviço.

Os testes demonstraram que a ferramenta é eficaz na descoberta de vulnerabilidades

mediante aos serviços que foram detectados pelo NMAP.

79


stra a vulnerabilidade CVE-

Vulnerabilidade é possível encontrar um texto da descrição da


visualmente a severidade da vulnerabilidade, podendo ser vermelha para grave,

computador possuía a versão do apache 2.0.59, no qual possui uma


erramenta é eficaz na descoberta de vulnerabilidades,

80

4 CONCLUSÕES

O principal objetivo desse trabalho foi utilizar recursos gratuitos para encontrar

vulnerabilidades em uma determinada rede e contribuir com administradores de rede para

identificar possíveis falhas de segurança na rede.

O estudo realizado demonstrou que é possível utilizar recursos gratuitos para

identificar vulnerabilidades de forma prática e rápida. O entendimento sobre redes de

computadores, modelo OSI e TCP/IP possibilitou o embasamento técnico para entender o

funcionamento de uma rede de computadores, e efetivamente como iniciar uma varredura de

portas abertas em uma rede de computadores.

O conhecimento abordado da arquitetura cliente-servidor permitiu elucidar a teoria

sobre sistemas distribuídos que utilizam servidores e clientes trocando informações na rede de

dados. Com base no conhecimento adquirido, o processo de identificação de serviços tornou-

se claramente simples.

Após o estudo sobre o conceito de sistemas distribuídos, foi definido que seria

abstraído o processo de identificação de serviços, e com isso, iniciou-se um levantamento

sobre ferramentas que fazem esse tipo de serviço. Todas as informações coletadas permitiram

identificar qual aplicação poderia se enquadrar no projeto.

O conceito de vulnerabilidades foi de extrema importância para o desenvolvimento do

trabalho, pois permitiu o fundamento técnico sobre como as vulnerabilidades acontecem,

como os ataques mais comum acontecem, e como podem comprometer uma organização de

pequeno ou grande porte.

Posteriormente após obter as informações necessárias para o desenvolvimento do

trabalho, foi iniciada a modelagem do projeto. A solução apontada foi à utilização da UML

para especificar os requisitos do produto. Na modelagem do projeto, foram incluídos os

requisitos funcionais, requisitos não funcionais bem como as regras de negócio. Também

explicado brevemente o funcionamento de cada componente do sistema, bem como cada

processo é empregado no contexto final.

Dentre as dificuldades encontradas durante a elaboração do trabalho, destacam-se a

dificuldade em encontrar comparativos de sistemas que efetuam trabalho semelhante ao que

81

se pretende desenvolver, para facilitar uma comparação imparcial das ferramentas disponíveis

atualmente no mercado.

Além disso, o processo de importação do banco de dados consumiu inúmeras

tentativas e validações, pois apesar da disponibilidade do arquivo de estrutura do NVD, certas

particularidades foram apresentadas durante o processo de verificação dos arquivos.

A facilidade do recurso NMAP4j, que integra as funcionalidades do NMAP ao Java

foram de extrema importância para o sucesso do trabalho, pois permitiu uma comunicação

simples e funcional entre o Vulscanner e o NMAP.

4.1 TRABALHOS FUTUROS

• Introduzir uma API de tradução da descrição das vulnerabilidades para outros

idiomas;

• Isolar o servidor de banco de dados através de uma camada de webservices,

tornando o repositório mais seguro;

• Tornar a normatização dos termos do NVD mais compatíveis com os termos

usados pelo NMAP;

• Implementar um processo de sinalização para detecções falso-positivos;

• Possibilitar a utilização de vários repositórios de vulnerabilidades;

• Aumentar o número de serviços detectáveis, com a utilização de outro software

que execute a mesma função do NMAP;

• Implementar um barra de progresso durante a varredura de rede;

82

REFERÊNCIAS

AHARONI, M.; COPPOLA, W.; HAND, P.; HERNANDEZ, A.; KEARNS, D.; KENNEDY, D.; MCELREA, S.; MEMELLI, M.; GORMAN, J.; OVITZ, D.; PEREZ, C. Metasploit unleashed: mastering the framework. Disponível em: <http://www.offensive-security.com/metasploit-unleashed>. Acesso em: 10 out. 2013.

ALMEIDA, Aléxis Rodrigues de. Como funcionam os Exploits. São Paulo, 2008. Disponível em: <http://www.invasao.com.br/2008/12/12/como-funcionam-os-exploits/>. Acesso em: 08 ago. 2013.

ALMEIDA, B. M.; Uma introdução ao XML, sua utilização na Internet e alguns conceitos complementares. Ci. Inf., Brasília, v. 31, n. 2, p. 5-13, maio/ago. 2002.

ANLEY, C. The shellcoder's handbook: discovering and exploring security holes. 2.ed. Indianapolis, IN: Wiley Publishing, 2007.

BASTOS, F. A. S.; NEVES, R. O. Mysql com segurança na rede utilizando um túnel criptográfico. Disponível em: <http://www3.iesam-pa.edu.br/ojs/index.php/sistemas/article/viewFile/553/413>. Acesso em: 10 out. 2013.

BAYLES, A. W.; HURLEY, C. LONG, JOHNNY, BRINDLEY, ED. InfoSec career hacking: sell your skillz, Not Your Soul. Disponível em: <http://run.unl.pt/bitstream/10362/2288/1/Farruca_2009.pdf>. Acesso em: 24 out. 2013.

BERNSTEIN, T.; BHIMANI, A. B; Internet security for business. New York: Wiley, 1996.

BEYOUNDTRUST. Retina CS threat management console. 2009. Disponível em: <http://www.beyondtrust.com/Products/RetinaCSThreatManagementConsole/>. Acesso em: 24 out. 2013.

BURNETT, Steve; PAINE, Stephen. Criptografia e segurança: o guia oficial RSA. Rio de Janeiro, RJ: Campus, 2002.

BUSHNAQ, Firas. Boxador collaborates with eEye on Retina CS. 2013. Disponível em: <http://www.boxador.com/blog/2009/11/boxador-collaborates-with-eeye-on-retina-cs/>. Acesso em: 24 out. 2013.

CARISSIMI, Alexandre da Silva; ROCHOL, Juergen; GRANVILLE, Lisandro Zambenedetti. Redes de computadores. Porto Alegre, RS: Bookman, 2009.

CARUSO, C. A. A.; STEFFEN, F. D. Segurança em informática e de informações. São Paulo: SENAC, 1999.

COMER, Douglas. Redes de computadores e internet: abrange transmissão de dados, ligação inter-redes, Web e aplicações. 4. ed. Porto Alegre, RS: Bookman, 2007.

COULOURIS, George F; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas distribuídos: conceitos e projeto. 4. ed. Porto Alegre, RS: Bookman, 2007.

CVE. Common Vulnerabilities and Exposures Home Page. EUA, 2013. Disponível em: <http://cve.mitre.org/>. Acesso em: 08 ago. 2013.

83

CYBER SECURITY. Security tools. 2013. Disponível em: <http://www.gov.mu/portal/sites/cybersecurity/securitytools.html>. Acesso em: 24 out. 2013

DIÓGENES, Yuri; MAUSER, Daniel. Certificação security +: da prática para o exame SY0 - 301. Rio de Janeiro, RJ: Novaterra, c2011.

DOSTOYEVSKY, F., METASPLOIT: um cenário de intrusão. 2013. Disponível em: <http://www.phrack.org/phrack/51/P51-11>. Acesso em: 10 out. 2013

FARRUCA, N. M. G.; Wireshark para sistemas distribuídos. 2009. Disponível em: <http://run.unl.pt/bitstream/10362/2288/1/Farruca_2009.pdf>. Acesso em: 24 out. 2013

FERNANDES, Daniel Batista. Metodologia dinâmica para o desenvolvimento de sistemas versáteis. São Paulo: Erica, 1999.

F-SECURE. F-Secure Deems 2012 the Year of the Exploit Kit. Finlândia, 2012. Disponível em: <http://www.f-secure.com/en/web/corporation_global/news-info/product-news-offers/view/story/832126/F-Secure%20Deems%202012%20the%20Year%20of%20the%20Exploit%20Kit>. Acesso em: 04 ago. 2013.

GOULART, Ademir. Avaliação de mecanismos de comunicação em grupo para aAmbiente WAN. 169p. Tese (Mestrado em Ciência da Computação) –Universidade Federal de Santa Catarina, 2002.

GROSS, Jan Charles. Sistemas distribuídos. Indaial: Asselvi, 2008.

JANKE, A. R. Busca distribuída utilizando comunicação em grupo para a resolução do problema 8-Puzzle, Blumenau, BR, 2004. p. 16.

JENKOV, Jacob. Java StAX: XMLStreamReader - The Cursor API. 2012. Disponível em: < http://tutorials.jenkov.com/java-xml/stax-xmlstreamreader.html>. Acesso em: 22 set. 2013.

LAZILHA, R. F.; Um estudo sobre os métodos de varredura utilizados em Portscans. Jul.Dez. 2005, Vol. 07, n.02, p. 147 - 156.

LYON, Gordon. Nmap reference guide. 2013. Disponível em: <http://nmap.org/book/man.html>. Acesso em: 22 set. 2013.

KUMAR, Mohit. Tenable Release Nessus 5.0 vulnerability scanner. 2012. Disponível em: < http://thehackernews.com/2012/02/tenable-release-nessus-50-vulnerability.html>. Acesso em: 22 set. 2013.

MALERBA, Cesar. Vulnerabilidades e exploits: técnicas, detecção e prevenção. Porto Alegre, 2010. Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/26337/000757768.pdf?sequence=1>. Acesso em: 22 set. 2013.

MAYNOR, D.; WILHELM, T. Metasploit toolkit for penetration testing, exploit development, and vulnerability research. Bulrlington: Syngress Publishing, 2007.

84

MCCLURE, Stuart; SCAMBRAY, Joel; KURTZ, George. Hackers expostos. Sao Paulo: Makron Books, 2000.

MENDES, Douglas Rocha. Redes de computadores: teoria e prática. São Paulo, SP: Novatec, 2007.

MOHIT, K. Tenable Release Nessus 5.0 vulnerability scanner. 2012. Disponível em: <http://thehackernews.com/2012/02/tenable-release-nessus-50-vulnerability.html>. Acesso em: 28 out. 2013.

NAZEER, N. E.; DAIMI, K.. Evaluation of netowork port scanning Tools. 2013. Disponível em: <http://world-com.org/p2011/SAM3839.pdf >. Acesso em: 22 set. 2013.

NVD. About NVD. EUA, 2012. Disponível em: <http://nvd.nist.gov/about.cfm>. Acesso em: 08 ago. 2013.

OIT. McAfee foundstone vulnerability assessment service. 2013. Disponível em: <http://www.oit.uci.edu/security/vulnassess/foundstone.html>. Acesso em: 24 out. 2013.

ORACLE. Interface XMLStreamReader. 2013. Disponível em: <http://docs.oracle.com/javaee/5/api/javax/xml/stream/XMLStreamReader.html>. Acesso em: 28 out. 2013.

OREBAUGH, A. Wireshark & ethereal network protocol analyzer tooklkit. Rockland, MA. Syngress. 2006.

PETERSON, Larry L; DAVIE, Bruce S. Redes de computadores: uma abordagem de sistemas. Rio de Janeiro: Campus: Elsevier, 2004.

PIETROFERE, Janet; CAMPANARO, Donald. MS SQL Database Auditing. 2012. Disponível em: < http://www.isaca.org/Education/Upcoming-Events/Documents/2012-NACACS-Presentations/222-nac2012.pdf>. Acesso em: 24 out. 2013.

RAUSTIN, R. D. Footprinting and Finderprinting. Georgia, 2011. Disponível em: < http://cse.spsu.edu/raustin2/coursefiles/id/IDLab2v2.pdf>. Acesso em: 14. ago. 2013.

SAINT. SAINT Scanner has Successfully Completed the PCI Scanning Vendor compliance Testing. Mayland, 2010. Disponível em: <http://www.saintcorporation.com/company/press/press09-10.html>. Acesso em: 14. ago. 2013.

SCRIMGER, Rob et al. TCP/IP: a bíblia. Rio de Janeiro, RJ: Campus: Elsevier, 2002.

SILVA, Pedro Tavares; CARVALHO, Hugo; TORRES, Catarina Botelho. Segurança dos sistemas de informação. Lisboa, PT: Centro Atlântico, 2003.

SOBRAL, João Bosco Mangueira. Footprint e fingerprint. Santa Catarina, 2006. Disponível em: <http://www.inf.ufsc.br/~bosco/extensao/material-seg-redes/Cap4-Footprint-Fingerprint.pdf>. Acesso em: 02 ago. 2013.

SOURCEFORGE. Nmap4j. EUA, 2013. Disponível em: <https://sourceforge.net/projects/nmap4j/ >. Acesso em: 08 ago. 2013.

85

STEPHENSON, Peter. McAfee vulnerability manager. 2012. Disponível em: <http://www.scmagazine.com/mcafee-vulnerability-manager/review/3606/>. Acesso em: 24 out. 2013.

STEPHENSON, Peter. SAINT integrated vulnerability assessment. 2011. Disponível em: <http://www.scmagazine.com/saint-integrated-vulnerability-assessment/review/3411/>. Acesso em: 24 out. 2013.

STEPHENSON, Peter. Tenable nessus 3. 2007. Disponível em: http://www.scmagazine.com//tenable-nessus-3/review/819/>. Acesso em: 24 out. 2013.

STEPHENSON, Peter. Tenable network security nessus vulnerability scanner. 2010. Disponível em: <http://www.scmagazine.com//tenable-network-security-nessus-vulnerability-scanner/review/3088/>. Acesso em: 24 out. 2013.

TANENBAUM, Andrew S. Redes de computadores. Rio de Janeiro, RJ: Campus, 1997.

TANENBAUM, Andrew S.; STEEN, Edla van. Sistemas distribuídos: princípios e paradigmas. 2.ed. São Paulo: Pearson Prentice Hall, 2007.

TANENBAUM, Andrew S.; GOODMAN, James R. Organização estruturada de computadores. 4.ed. Rio de Janeiro, RJ: Livros Técnicos e Científicos, 2001.

TENABLE. Nessus vulnerability scanner. 2013. Disponível em: <http://www.tenable.com/products/nessus>. Acesso em: 24 out. 2013.

TOLEDO, A. S. O.; SOUZA, V. A. C, METASPLOIT: um cenário de intrusão. 2012. Disponível em: <http://issuu.com/publicanewton/docs/pos_em_revista_numero_5>. Acesso em: 10 out. 2013.

TORRES, Gabriel. Redes de computadores: curso completo. Rio de Janeiro: Axcel Books, 2001.

WIDE EYE SECURITY. Retina CS Management Console | WideEyeSecurity.com. 2013. Disponível em: <http://www.wideeyesecurity.com/Retina-CS.asp>. Acesso em: 24 out. 2013

YOUNAN, Yerman. 25 Years of vulnerabilities: 1988-2012. Columbia, 2012. Disponível em: <https://info.sourcefire.com/25yearsof_security_vulnerabilities_preregister.htm>. Acesso em: 08 ago. 2013.

ZUMRUT, Furkan. How can I use anyone metasploit exploit?. Instambul, 2012. Disponível em: < http://www.furkanzumrut.com/how-can-i-use-anyone-metasploit-exploit>. Acesso em: 08 ago. 2013.

GLOSSÁRIO

86

Cracker Indivíduo que pratica a quebra de um sistema de segurança, de forma ilegal ou sem ética.

Denial of Service Tentativa de tomar os recursos de um sistema indisponíveis para seus utilizadores.

Gateway É uma máquina intermediária geralmente destinada a interligar redes, separar domínios de colisão, ou mesmo traduzir protocolos.

Hacker É um indivíduo que se dedica, com intensidade incomum, a conhecer e modificar os aspectos mais internos de dispositivos, programas e redes de computadores.

Host É qualquer máquina ou computador conectado a uma rede, podendo oferecer informações, recursos, serviços e aplicações aos usuários ou outros nós na rede.

Modelo OSI É um conjunto de padrões ISO relativo à comunicação de dados. Patch É um programa criado para atualizar ou corrigir um software. Sniffer Ferramenta capaz de interceptar e registrar o tráfego de dados em uma

rede de computadores. WHOIS É um protocolo TCP específico para consultar informações de contato

e DNS sobre entidades na internet.