U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
PROCURA E AN ´ALISE AUTOMATIZADA DE
SUPERF´ICIES EXPOSTAS E PASS´IVEIS DE ATAQUE
A PARTIR DA INTERNET
R´uben Miguel Meneses
Trabalho de Projeto
MESTRADO EM ENGENHARIA INFORM ´ATICA
Especializac¸˜ao em Arquitetura, Sistemas e Redes de Computadores
2015
Trabalho de Projecto orientado pelo Prof.António Casimiro
Ferreira da Cosa e co-orientado pelo Eng. José António dos
Santos Alegria
U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciˆencias
Departamento de Inform´atica
PROCURA E AN ´ALISE AUTOMATIZADA DE
SUPERF´ICIES EXPOSTAS E PASS´IVEIS DE ATAQUE
A PARTIR DA INTERNET
R´uben Miguel Meneses
Trabalho de Projeto orientado pelo Prof. Ant´onio Casimiro
Ferreira da Costa e co-orientado pelo Eng. Jose Ant´onio dos
Santos Alegria
Mestrado em Engenharia Inform´atica
Especializac¸˜ao em Arquitetura, Sistemas e Redes de Computadores
2015
Agradecimentos
No desenvolvimento deste trabalho, foram diversas as pessoas que contribu´ıram para a sua concretizac¸˜ao. A todas quero dirigir um agradecimento:
Ao Professor Ant´onio Casimiro Ferreira da Costa, como orientador deste trabalho, por ter aceite este desafio, pelos conselhos, pela orientac¸˜ao no planeamento e concretizac¸˜ao deste trabalho, pela alegria, entusiasmo, determinac¸˜ao e empenho que sempre transmitiu, pela sua disponibilidade, apoio, incentivo e paciˆencia em todos os momentos, a ele, o meu mais sentido agradecimento.
Ao Engenheiro Jos´e Ant´onio dos Santos Alegria, como co-orientador deste trabalho, por ter estado sempre presente desde o planeamento at´e `a concretizac¸˜ao deste trabalho, em todos os momentos de d´uvida, por nos ter brindado com a sua sabedoria e conhecimento, pela colaborac¸˜ao e disponibilidade, pela referˆencia a seguir e pelo rigor cient´ıfico, a ele, um agradecimento muito especial.
A toda a equipa do SOC e DCY, em especial ao Pedro In´acio, Paulo Serr˜ao e Luis Costa, pela recepc¸˜ao amistosa e colaborac¸˜ao no desenvolvimento deste trabalho, tornando o ambiente de trabalho num ambiente extremamente acolhedor e familiar.
A todos os meus colegas da faculdade que me acompanharam nos ´ultimos anos e fo-ram quase uma fam´ılia em todos os momentos complicados do meu percurso acad´emico, pela amizade, pelos sorrisos com que me contagiaram e pela vossa paciˆencia.
A toda a minha fam´ılia, que ao longo da minha vida acad´emica foram um alicerce para alcanc¸ar os meus objetivos, pelo amor, forc¸a, paciˆencia e incentivo.
`A M´onica, por toda a forc¸a que me transmitiu nos momentos de maior fraqueza, pelo carinho, forc¸a, paciˆencia e incentivo em todos os momentos.
Aos meus colegas e amigos do “Grupo de Jovens Os Mensageiros”, pela sua forc¸a, apoio e alegria que me transmitiram ao longo do meu percurso.
A todas as pessoas que de forma direta ou indireta contribu´ıram para a realizac¸˜ao deste trabalho e de toda a minha vida com o seu apoio e sabedoria.
O meu muito obrigado a todos aqueles que contribu´ıram para a realizac¸˜ao deste projeto, tenha sido de forma direta ou indireta, todos foram importantes. iii
Resumo
Num mundo cada vez mais digital onde os casos de ataques inform´aticos aparecem com maior frequˆencia, ´e de extrema relevˆancia para as empresas manter os seus dados, bem como os dados dos seus clientes, em reposit´orios que sejam seguros. No ˆambito deste est´agio, foi feita uma proposta de criac¸˜ao de uma ferramenta que seja capaz de per-correr e analisar de forma automatizada toda a rede empresarial, incluindo as sub-redes, em busca de superf´ıcies que se encontrem expostas e passiveis de serem atacadas atrav´es da Internet. Este projeto est´a integrado num cluster de projetos da DCY “IntelSources” (Departamento de CyberSecurity Information Discovery and Intelligence Sources) da em-presa PTC (Portugal Telecom Comunicac¸˜oes).
Este relat´orio descreve o trabalho realizado para a criac¸˜ao da ferramenta HAS (Hound Attack Surface) capaz de satisfazer os requisitos iniciais, nomeadamente a identificac¸˜ao de superf´ıcies expostas. Esta ferramenta realiza diversas atividades que s˜ao executadas de forma consecutiva. Numa primeira fase ´e realizado um levantamento das m´aquinas que est˜ao ligadas, com base em listas de IPs ou mascaras de rede ou nomes de m´aquinas e dos portos que as mesmas apresentam como estando abertos. Numa segunda fase s˜ao realizadas pesquisas a portos espec´ıficos das m´aquinas para determinar o servic¸o a que as mesmas est˜ao associadas. Em fases posteriores, depois de confirmado o servic¸o asso-ciado a cada porto, s˜ao feitos acessos aos servic¸os para obter informac¸˜oes que permitam determinar se os mesmos est˜ao vulner´aveis a ataques que poder˜ao ser tanto externos como internos.
Com a criac¸˜ao desta ferramenta pretende-se aumentar o n´ıvel de seguranc¸a da infra-estrutura de dados da empresa, controlando melhor os pontos de entrada de poss´ıveis ataques inform´aticos contra a mesma.
Palavras-chave: vulnerabilidades, seguranc¸a, servic¸os, pesquisas especificas. v
Abstract
In an increasingly digital world where computer attacks appear with higher frequency, it is really important for enterprises to ensure the security of repositories that keep their data, as well as their client’s data. In this project, the proposal was to create an automated software tool capable of automatically scanning the enterprise network, including their subnets, searching for exposed surfaces that are vulnerable to attacks from the Internet. This project is part of DCY “IntelSources” (Cybersecurity Information Discovery and Intelligence Sources Department) cluster, from PTC (Portugal Telecom Comunicac¸˜oes).
This report describes the work done for the creation of a tool that addresses the initial requirements, namely the identification of exposed surfaces. The tool performs several activities, executed in consecutive stages. The initial stage involves a survey of connected machines based on a list, which can be from IP’s, netmasks or hostnames. This survey includes the open ports from the same machines. In a second stage the tool searches on specific ports to determine the services they are associated with. In further stages it then collects specific service information by directly accessing the services which may tell us if that service is vulnerable, either to internal or external attacks.
This tool will increase the security level of PTC infrastructure by providing greater control and predictability for the entry points of possible cyber attacks.
Keywords: vulnerabilities, security, services, specific searches vii
Conte´udo
Lista de Figuras xiv
Lista de Tabelas xvii
1 Introduc¸˜ao 1
1.1 Desafios . . . 2
1.2 Objetivos . . . 3
1.3 Planeamento e Contribuic¸˜oes . . . 3
1.4 Estrutura do Documento . . . 7
2 Contexto e Soluc¸˜oes Alternativas 9 2.1 Seguranc¸a Distribu´ıda . . . 9
2.2 Ataques e vulnerabilidades . . . 11
2.3 Soluc¸˜oes para detecc¸˜ao de vulnerabilidades . . . 13
2.3.1 Nessus . . . 13
2.3.2 openVas . . . 14
2.3.3 Discuss˜ao . . . 16
2.4 Outras Ferramentas de seguranc¸a . . . 16
2.4.1 Nmap . . . 16 2.4.2 SSLyze . . . 17 2.4.3 Nikto . . . 17 2.4.4 ElasticSearch . . . 18 2.4.5 Kibana . . . 18 2.4.6 Hidra Broker . . . 19 3 Arquitetura do HAS 21 3.1 Definic¸˜ao do Problema . . . 21 3.2 Requisitos do Sistema . . . 22
3.3 Arquitetura gen´erica da soluc¸˜ao . . . 23
4 Concretizac¸˜ao do sistema HAS 25 4.1 Definic¸˜ao dos componentes da arquitetura . . . 25
4.4 Componentes da Arquitetura . . . 29
4.4.1 Plugins de parametrizac¸˜ao e orquestrac¸˜ao . . . 30
4.4.1.1 Has . . . 30
4.4.1.2 Maestro . . . 31
4.4.2 Plugins de colec¸˜ao e an´alise de dados . . . 32
4.4.2.1 ptScan . . . 32
4.4.2.2 niktoScan . . . 33
4.4.2.3 sslScan . . . 34
4.4.2.4 httpScan . . . 36
4.4.3 Plugin de visualizac¸˜ao: excelGenerator . . . 37
4.4.4 Armazenamento dos dados . . . 41
5 Avaliac¸˜ao 43 5.1 Definic¸˜ao de Testes . . . 43
5.1.1 Testes de Efic´acia da Ferramenta . . . 43
5.1.2 Testes de Desempenho . . . 44
5.2 Resultados e Discuss˜ao . . . 46
5.2.1 Testes de Efic´acia da Ferramenta . . . 46
5.2.2 Testes de Desempenho . . . 51
5.3 Aplicac¸˜ao do HAS `a rede p´ublica da PT . . . 58
6 Conclus˜ao e trabalho futuro 63 Abreviaturas 66 Bibliografia 68 Apˆendices 68 A Modelos de dados 69 A.1 ptScan . . . 69 A.1.1 XML inicial . . . 69 A.1.2 XML transformado . . . 70
A.1.3 JSON gerado . . . 70
A.2 niktoScan . . . 71
A.2.1 XML inicial . . . 71
A.2.2 XML transformado . . . 71
A.2.3 JSON gerado . . . 72
A.3 sslScan . . . 73 x
A.3.1 XML inicial . . . 73
A.3.2 XML transformado . . . 75
A.3.3 JSON gerado . . . 76
A.4 httpScan . . . 77
A.4.1 XML inicial . . . 77
A.4.2 XML transformado . . . 77
A.4.3 JSON gerado . . . 77
Lista de Figuras
2.1 Modelo Ataque-Vulnerabilidade-Intrus˜ao. . . 11
2.2 Aplicac¸˜ao do paradigma Cliente-Servidor. . . 13
2.3 Arquitetura OpenVAS. . . 15
2.4 Distribuic¸˜ao geogr´afica dos servidores. . . 17
3.1 Distribuic¸˜ao geogr´afica dos servidores. . . 21
3.2 Arquitetura gen´erica da soluc¸˜ao. . . 23
4.1 Arquitetura do HAS. . . 26
4.2 Vis˜ao estrutural do sistema. . . 28
4.3 Plugins e scripts do sistema. . . 29
4.4 Diagrama “Has”. . . 30 4.5 Diagrama “Maestro”. . . 31 4.6 Diagrama ptScan. . . 32 4.7 Diagrama “niktoScan”. . . 34 4.8 Diagrama “sslScan”. . . 35 4.9 Diagrama “httpScan”. . . 36 4.10 Diagrama “excelGenerator”. . . 37
4.11 Escolha do tipo de enderec¸o a ser visualizado. . . 38
4.12 Escolha da quantidade de enderec¸os a serem analisados. . . 38
4.13 Escolha de datas dos dados. . . 38
4.14 Escolha da informac¸˜ao espec´ıfica a visualizar. . . 39
4.15 Separadores da folha de c´alculo gerada. . . 40
4.16 Arquitetura de armazenamento. . . 41
5.1 Detec¸˜ao de plugin lento. . . 51
5.2 Comparac¸˜ao tempos m´edios de execuc¸˜ao dos plugins. . . 54
5.3 Tempos de execuc¸˜ao do “niktoScan” com e sem replicac¸˜ao. . . 54
5.4 Ganhos na execuc¸˜ao do “niktoScan” com replicac¸˜ao. . . 55
5.5 Tempos de execuc¸˜ao do “sslScan” com e sem replicac¸˜ao. . . 55
5.6 Ganhos na execuc¸˜ao do “sslScan” com replicac¸˜ao. . . 55
5.7 Tempos de execuc¸˜ao do “httpScan” com e sem replicac¸˜ao. . . 56
5.8 Ganhos na execuc¸˜ao do “httpScan” com replicac¸˜ao. . . 56 xiii
5.11 Ganhos no tempo de execuc¸˜ao da ferramenta . . . 57
5.12 Top 10 dos portos encontrados como estando abertos pelo “ptScan”. . . . 59
A.1 Ficheiro XML correspondente ao scan dos portos TCP. . . 69
A.2 Ficheiro XML correspondente ao scan dos portos UDP. . . 69
A.3 Ficheiro XML resultante da junc¸˜ao da informac¸˜ao. . . 70
A.4 Documento JSON com os dados convertidos. . . 70
A.5 Ficheiro XML gerado na recolha de informac¸˜ao. . . 71
A.6 Ficheiro XML com a informac¸˜ao importante. . . 71
A.7 Documento JSON com os dados convertidos. . . 72
A.8 Ficheiro XML gerado na recolha de informac¸˜ao pelos certificados. . . 73
A.9 Ficheiro XML gerado na recolha de informac¸˜ao pelas cifras. . . 74
A.10 Ficheiro XML gerado apenas com informac¸˜ao relevantes. . . 75
A.11 Documento JSON com os dados convertidos. . . 76
A.12 Ficheiro XML inicialmente gerado pelo httpScan. . . 77
A.13 Ficheiro XML apenas com os dados relevantes. . . 77
A.14 Documento JSON com os dados convertidos. . . 77
Lista de Tabelas
1.1 Tabela do plano de trabalho . . . 6
2.1 Correspondˆencia entre BD tradicional e ElasticSearch . . . 18
5.1 Resultados obtidos na execuc¸˜ao de testes ao plugin httpScan . . . 46
5.2 Resultados dos testes realizados `a vulnerabilidade Heartbleed. . . 47
5.3 Resultados dos testes realizados `a vulnerabilidade FREAK. . . 48
5.4 Resultados dos testes realizados `a vulnerabilidade POODLE. . . 49
5.5 Tabela com quantidade de “alarmes” detetados pelo Nikto. . . 50
5.6 Tempos de execuc¸˜ao dos plugins em segundos . . . 51
5.7 Tempo de execuc¸˜ao de cada r´eplica dos plugins, em segundos. . . 53
5.8 Tempo m´edio de execuc¸˜ao de cada plugin, em segundos. . . 53
5.9 Quantidade de hosts analisados e que responderam a cada plugin. . . 59
5.10 Resultados resumidos do niktoScan. . . 60
5.11 Resultados do “sslScan”. . . 60
Cap´ıtulo 1
Introduc¸˜ao
Nos dias que correm, ´e cada vez mais comum a dependˆencia, tanto nas empresas como na vida pessoal, de dispositivos e tecnologias inform´aticas. Embora seja do conhecimento geral, nunca ´e demais relembrar que ´e quase imposs´ıvel garantir que estas ferramentas sejam cem por cento seguras. Estamos a falar de ferramentas e equipamentos que podem ir desde um simples smartphone pessoal, com o qual passamos grande parte dos dias, at´e a servic¸os de cloud. Embora estes sejam considerados bastante seguros, por toda a tecnologia de seguranc¸a que incorporam, s˜ao v´arios os exemplos de ataques realizados com sucesso `as clouds e at´e mesmo a smartphones, nomeadamente o recente ataque `a iCloud em que fotos intimas de v´arias celebridades foram expostas por toda a Internet. [1]
Muitas vezes estes ataques surgem relacionados com a falta de cuidado dos utiliza-dores que n˜ao se mostram suficientemente preocupados com a seguranc¸a dos seus dados. Esta falta de preocupac¸˜ao, por vezes, vem do facto dos produtos, tal como s˜ao vendidos e publicitados, transmitirem um elevado grau de confianc¸a aos clientes/utilizadores. A falta de preocupac¸˜ao com a seguranc¸a, est´a assim relacionada com a confianc¸a que os utilizadores tˆem nas empresas que lhes vendem/fornecem servic¸os.
Para garantir que este voto de confianc¸a, por vezes cega, n˜ao ´e quebrado, ´e do maior interesse e responsabilidade de quem fornece estes servic¸os garantir que os dados dos seus clientes est˜ao armazenados de forma segura, e que estes est˜ao dispon´ıveis sempre que o cliente necessitar dos mesmos. Assim sendo, ´e de suma importˆancia garantir que estes dados n˜ao est˜ao dispon´ıveis para acessos indevidos, ou seja, quanto maior o n´ıvel de seguranc¸a dos dados e da infraestrutura que os armazena, menor o n´ıvel de vulnerabi-lidade a que os mesmos est˜ao sujeitos.
De forma a evitar este tipo de ataques, tem sido realizado um enorme esforc¸o por parte das empresas para que os seus servic¸os sejam cada vez mais seguros, o que implica que estes devem ter capacidade para tolerar faltas, remover vulnerabilidades e prever ataques. No caso deste projeto, e da empresa onde se realiza, a seguranc¸a ´e um aspeto fulcral n˜ao s´o pelo facto da Portugal Telecom (PT) ser uma das maiores empresas do pa´ıs, como
pelo n´umero de clientes que confiam nos servic¸os que esta presta e na confidencialidade esperada dos seus dados, mas tamb´em pelo facto desta empresa ser uma referˆencia no desenvolvimento de novas tecnologias em sistemas de comunicac¸˜ao.
Dada a dimens˜ao da PT as consequˆencias de uma intrus˜ao nos sistemas da empresa podem ser altamente prejudiciais. Da´ı a necessidade do desenvolvimento deste projeto com o objetivo de aumentar a capacidade de detecc¸˜ao de potenciais pontos vulner´aveis a ataques.
Neste projeto pretendeu-se concretizar uma ferramenta de pesquisa e an´alise automa-tizada de superf´ıcies expostas e pass´ıveis de ataque a partir da Internet, com o intuito de diminuir as probabilidades de haver um ataque atrav´es de um ponto desconhecido do sis-tema. A importˆancia deste projeto tem como fundamento o facto de na empresa n˜ao se encontrar implementada nenhuma ferramenta de software com capacidade para realizar este tipo de an´alise.
Para percebermos melhor este projeto, apresentam-se de seguida os desafios que este apresenta. S˜ao depois descritos os objetivos espec´ıficos que foram definidos. Posteri-ormente ´e realizada uma an´alise ao planeamento e contribuic¸˜ao que este trabalho repre-sentou para o funcionamento da empresa. Por fim, descreve-se a forma como o restante documento se encontra estruturado.
1.1 Desafios
A realizac¸˜ao deste projeto apresentou diversos desafios, um dos quais est´a relacionado com o simples facto de n˜ao existir na empresa, de momento, nenhuma ferramenta com capacidade total para realizar este tipo de an´alise.
Outro dos desafios, talvez o maior deste trabalho, prende-se com o n´umero de m´aquinas que suportam e armazenam todos os servic¸os p´ublicos que s˜ao disponibilizados pela PT Comunicac¸˜oes. A ferramenta deve, portanto, ser capaz de lidar facilmente com o pro-blema da escalabilidade do sistema, apresentando um desempenho naturalmente vari´avel consoante o n´umero de m´aquinas definidas como alvo dos scans, mas sendo capaz de realizar a sua tarefa dentro de um intervalo de tempo considerado aceit´avel.
A necessidade de obter resultados fi´aveis ´e outro dos grandes desafios apresentados neste projeto, dada a dimens˜ao das redes a serem analisadas, visto que os resultados ob-tidos implicar˜ao a alterac¸˜ao da configurac¸˜ao de alguns elementos da rede que devem ser realizadas com precauc¸˜ao.
Por fim, a integrac¸˜ao desta ferramenta na infraestrutura existente da PT, bem como a sua integrac¸˜ao com as ferramentas de alarme existentes, apresentam tamb´em elas um desafio interessante a ser ultrapassado.
Cap´ıtulo 1. Introduc¸˜ao 3
1.2 Objetivos
Este trabalho consistiu no desenvolvimento de uma “Soluc¸˜ao de procura e an´alise automatizada de superf´ıcies expostas e pass´ıveis de ataque a partir da Internet”, a ser integrado na Direc¸˜ao de Cyber Security, Privacy e Business Continuity (DCY) da PT Comunicac¸˜oes.
Com este projeto pretende-se dotar a DCY dos mecanismos necess´arios para melhorar a sua efic´acia na ´area de detecc¸˜ao de vulnerabilidades nas suas superf´ıcies expostas `a Internet de forma adaptada `as necessidades da empresa e sem prejudicar o desempenho dos seus sistemas.
Para a realizac¸˜ao deste projeto foi estabelecido como principal objetivo desenhar,
desenvolver e testar uma ferramenta capaz de resolver o problema que nos foi apre-sentado.
Assim, definiram-se os seguintes objetivos espec´ıficos no desenvolvimento da ferra-menta:
1. Assegurar funcionalidade; 2. Permitir distribuic¸˜ao; 3. Assegurar escalabilidade;
4. Permitir expans˜ao da ferramenta;
5. Assegurar capacidade para analisar toda a rede p´ublica de servic¸os da PT; 6. Assegurar a integrac¸˜ao na infraestrutura existente;
Do ponto de vista funcional, pretende-se especificamente que numa primeira fase seja realizado um levantamento das m´aquinas que est˜ao ligadas, com base em listas de IPs/ mascaras de rede/ nomes dessas m´aquinas. Al´em do levantamento das m´aquinas que se encontram ligadas, ´e tamb´em realizado o levantamento dos portos que as mesmas apre-sentavam como estando abertos bem como o servic¸o a que as mesmas est˜ao associadas. Em fases posteriores, depois de confirmado o servic¸o associado a cada porto, ser˜ao fei-tas pesquisas por informac¸˜oes dos servic¸os que permitam determinar se os mesmos est˜ao vulner´aveis a ataques.
1.3 Planeamento e Contribuic¸˜oes
Para a realizac¸˜ao deste projeto, foi desenvolvido um plano de trabalho que contribuiu para que nos consegu´ıssemos orientar durantes as diferentes fases pelas quais o projeto passou.
Planeamos para uma primeira fase do trabalho estudar e testar as tecnologias que s˜ao utilizadas pela PT Comunicac¸˜oes para o armazenamento dos dados. Nesta fase foi-nos permitido adquirir conhecimento dobre este software com o objetivo de nos familiarizar-mos com as funcionalidades do mesmo, ou seja, inserir e eliminar dados, especificar o modelo de dados a serem inseridos e realizar de pesquisas sobre estes mesmos dados.
Seguiu-se, numa segunda fase, a interac¸˜ao com v´arias ferramentas de recolha de informac¸˜oes sobre os hosts que foram utilizados para testes. Neste per´ıodo tivemos opor-tunidade de adquirir conhecimento sobre as v´arias formas de execuc¸˜ao das ferramentas que nos permitiram obter diferentes informac¸˜oes, tamb´em para adaptar e uniformizar o output gerado pelas diferentes ferramentas para um formato semelhante entre todas.
Depois desta fase de ambientac¸˜ao `as ferramentas a serem utilizadas, foi elaborado o relat´orio preliminar com informac¸˜ao de contexto sobre o trabalho e algum do trabalho desenvolvido at´e ao momento em que o mesmo foi escrito. Nesta tarefa um ligeiro atraso devido a melhoramentos que foram aplicados ao relat´orio.
Ap´os a escrita sobre aquela que foi a nossa ideia inicial, foram realizados v´arios testes com vista `a correc¸˜ao de erros, melhoramento da uniformizac¸˜ao dos dados recolhidos pelas ferramentas e tamb´em para melhorar a definic¸˜ao dos modelos de dados, ou seja, a forma segundo a qual os dados ser˜ao armazenados.
De seguida planeamos implementar um algoritmo de automatizac¸˜ao para an´alise de m´ultiplos enderec¸os. Nesta fase foi criado um script que executava as v´arias pequisas de forma sequencial e cujos dados eram todos armazenados e transmitidos recorrendo `a utilizac¸˜ao de ficheiros. Esta tarefa e a seguinte (realizac¸˜ao de tetes) acabaram por se misturar visto que `a medida que o script foi desenvolvido foram realizados testes.
Planeamos de seguida uma per´ıodo para realizar atualizac¸˜oes ao relat´orio preliminar. Esta tarefa acabou por n˜ao ser cumprida rigorosamente visto que o projeto estava a mudar e que v´arias das atualizac¸˜oes foram realizadas no decorrer do projeto.
Nas fases que se seguiram o projeto comec¸ou a ganhar a estrutura e forma que apre-sentamos neste relat´orio. Comec¸amos a pensar na facilidade transmitida pela existˆencia dos diferentes plugins para as diferentes pesquisas e restantes tarefas. Foi tamb´em nesta fase que as datas das tarefas planeadas acabaram por “escorregar” e o projeto acabou por atrasar um pouco um relac¸˜ao ao previsto. Dada a nova estrutura adotada nesta fase foi necess´aria a atualizac¸˜ao de todo o trabalho at´e `a data realizado.
T´ınhamos planeado de seguida a implementac¸˜ao de um script de visualizac¸˜ao, seguido da implementac¸˜ao dos plugins de scan e an´alise, seguido de uma fase de integrac¸˜ao, de testes `a ferramenta e da escrita do relat´orio final.
Na verdade, com a alterac¸˜ao da estrutura e arquitetura do projeto, comec¸amos por alterar por completo os plugins de scan e an´alise, estes tinham sido desenvolvidos para serem executados de forma sequencial e recorrendo a ficheiros para que os dados fossem passados de script em script. Nesta fase os scripts foram adaptados para comunicarem
Cap´ıtulo 1. Introduc¸˜ao 5 atrav´es da infraestrutura utilizada na empresa e foram tamb´em adaptados para serem ca-pazes de executar em paralelo para diminuir o tempo total de execuc¸˜ao da ferramenta e melhorar o seu desempenho.
S´o depois de conclu´ıda a criac¸˜ao destes scripts ´e que nos debruc¸amos sobre o desen-volvimento do plugin de visualizac¸˜ao dos dados, s´o fazia sentido ser desenvolvido depois de termos os dados armazenados de forma correta.
O desenvolvimento destes plugins acabou por demorar mais tempo do que o previsto, n˜ao s´o pela necessidade constante de corrigir problemas que surgiram durante a execuc¸˜ao da ferramenta, mas tamb´em por terem sido introduzidos novos plugins para procurar e analisar diferentes superf´ıcies.
Por ´ultimo veio a fase de testes que foi realizada j´a com toda a ferramenta a funcionar corretamente e que nos permitir´a tirar conclus˜oes quanto ao trabalho que desenvolvemos. Quanto `a escrita deste relat´orio final, foi um processo continuo que constantemente sofreu alterac¸˜oes e correc¸˜oes acompanhando as incidˆencias do projeto.
Com a concretizac¸˜ao deste projeto contribu´ımos para o aumento do n´ıvel de prevenc¸˜ao e detec¸˜ao, de situac¸˜oes an´omalas, existente na PT Comunicac¸˜oes disponibilizando uma ferramenta com capacidade para detetar superficies expostas a ataques a partir da Internet de forma automatizada e capaz de escalar.
Tarefas Durac¸˜ao/per´ıodo Estudo e teste das tecnologias a utilizar para armazenamento e
visualizac¸˜ao dos dados [1/10 a 17/10](2 semanas)
Estudo, configurac¸˜ao e teste de diferentes ferramentas de
“scanning” (1 mˆes)14/11][20/10 a
Elaborac¸˜ao do relat´orio preliminar [17/11 a 28/11](2 semanas)
Realizac¸˜ao de testes com n´umero reduzido de enderec¸os (1 mˆes)
- Definic¸˜ao do modelo de dados [1/12 a 5/12]
- Adaptac¸˜ao dos resultados ao modelo [8/12 a 12/12]
- Correc¸˜ao de erros [15/12 a 9/1]
Implementac¸˜ao de algoritmo de automatizac¸˜ao para an´alise de
m´ultiplos enderec¸os (1 semana)a 16/1][12/1
Realizac¸˜ao de novos testes e avaliac¸˜ao dos resultados obtidos [19/1 a 30/1](2 semanas)
Atualizac¸˜ao do relat´orio preliminar (1 semana)6/2] [1/2 a
Avaliac¸˜ao da escalabilidade e efic´acia dos testes em subnets (2 semanas)a 20/2] [9/2
Implementac¸˜ao de ferramenta de visualizac¸˜ao de resultados (1 semana)a 27/2][23/2
Investigac¸˜ao e desenvolvimento de componente de detecc¸˜ao de
vulnerabilidades (1 mˆes)3/4][2/3 a
Realizac¸˜ao de testes, e correc¸˜ao de poss´ıveis erros, aplicado
redes p´ublicas da PT (1 mˆes)1/5][6/4 a
Integrac¸˜ao / automac¸˜ao da implementac¸˜ao do modelo
desenvolvido (1 mˆes)29/5][4/5 a
Elaborac¸˜ao do relat´orio final (1 mˆes)30/6][1/6 a
Cap´ıtulo 1. Introduc¸˜ao 7
1.4 Estrutura do Documento
O documento est´a estruturado em 6 secc¸˜oes da seguinte forma.
Na secc¸˜ao 2 comec¸amos por abordar quais seriam algumas das alternativas `a criac¸˜ao da ferramenta para detec¸˜ao de superf´ıcies expostas, seguindo-se uma explicac¸˜ao de outras ferramentas auxiliares usadas para o desenvolvimento e concretizac¸˜ao do projeto.
Na secc¸˜ao 3 abordamos o problema que levou `a criac¸˜ao deste projeto, de um ponto de vista gen´erico. Apresentamos os requisitos que uma soluc¸˜ao para este problema deve satisfazer, bem como a soluc¸˜ao gen´erica que consideramos ser a mais correta para resolver este mesmo problema.
De seguida apresentamos na secc¸˜ao 4, a nossa concretizac¸˜ao da soluc¸˜ao proposta, explicando o ambiente onde o mesmo foi desenvolvido, as decis˜oes que foram tomadas, a vis˜ao funcional e estrutural da soluc¸˜ao e todos os componentes de software que esta soluc¸˜ao envolve.
Na secc¸˜ao 5 descreve-se o trabalho de avaliac¸˜ao que foi realizado, nomeadamente os testes realizados com a ferramente e os resultados obtidos em cada teste.
Por fim, na secc¸˜ao 6, apresenta-se uma conclus˜ao onde iremos avaliar o nosso trabalho com base nos objetivos que foram cumpridos e com base nos resultados obtidos pela ferramenta. Indicam-se ainda poss´ıveis extens˜oes ao trabalho que lhe trariam uma maior robustez e maior capacidade de an´alise.
Cap´ıtulo 2
Contexto e Soluc¸˜oes Alternativas
A ferramenta neste projeto tem como objetivo a descoberta de superf´ıcies expostas a ataques atrav´es da Internet, ou seja, descobrir elementos da rede que estejam vulner´aveis a ataques conhecidos atrav´es da Internet. Para tal, ´e importante analisar as ferramentas que existem no mercado e perceber as raz˜oes pelas quais ´e prefer´ıvel desenvolver esta ferramenta de forma interna em detrimento da utilizac¸˜ao ou compra de licenc¸as desses mesmos softwares.
Neste cap´ıtulo ser´a feita uma introduc¸˜ao a alguns conceitos relacionados com a seguranc¸a distribu´ıda que nos ajudar˜ao a entender os desafios apresentados neste projeto. Falaremos tamb´em de algumas ferramentas que ser˜ao utilizadas para ajudar a concretizar o projeto, sendo que estas servir˜ao para a realizac¸˜ao de scans, armazenamento e visualizar dados.
2.1 Seguranc¸a Distribu´ıda
Uma vez que este projeto se insere na ´area da seguranc¸a inform´atica, introduzimos nesta secc¸˜ao alguns dos conceitos mais importantes nesta ´area descrevendo, a motivac¸˜ao geral por tr´as das ac¸˜oes perpetradas por utilizadores maliciosos, os tipos de ataques nor-malmente realizados e ainda as consequˆencias provocadas por estes ataques quando s˜ao bem sucedidos e resultam numa intrus˜ao.
A relac¸˜ao das pessoas com os computadores tem sofridos alterac¸˜oes nas ´ultimas d´ecadas de uma forma quase absurda, passando de uma, falta de confianc¸a inicial para a crenc¸a cega nos computadores chegando ao ponto de se tornarem demasiado dependentes dos mesmos e armazenar neles toda a informac¸˜ao que lhes ´e importante.
Muitas vezes as pessoas n˜ao d˜ao a devida importˆancia `a informac¸˜ao que armazenam nos seus computadores. Tanto informac¸˜ao de cariz pessoal como a de cariz profissional, relacionado com o seu trabalho, s˜ao muitas vezes deixadas de forma descuidada sem que estes se preocupem com a privacidade desta informac¸˜ao.
Este tipo de comportamento est´a associado `a falta de formac¸˜ao das pessoas para este tipo de cuidados (preservac¸˜ao da privacidade dos dados armazenados em computadores),
uma vez que a inform´atica tem avanc¸ado a um ritmo t˜ao r´apido e que a generalidade das sociedades n˜ao a tem acompanhado.
Esta falta de cuidado ´e muitas vezes aproveitada por utilizadores mal intencionados para invadir os computadores de outras pessoas, roubar passwords ou espiar a rede para observac¸˜ao de informac¸˜ao alheia, sendo estas ac¸˜oes muitas vezes realizadas como uma simples “brincadeira” para mostrar o poder que estes utilizadores possuem comparativa-mente aos que n˜ao se preocupam com a preservac¸˜ao dos seus dados.
Contudo, n˜ao nos podemos esquecer que mesmo que muitas destas ac¸˜oes sejam rea-lizadas por divers˜ao, em alguns casos existem utilizadores com verdadeiras intens˜oes de “arrombar” a seguranc¸a dos nossos computadores e de provocar algum tipo de incidente. As motivac¸˜oes por tr´as destas ac¸˜oes est˜ao muitas vezes relacionadas com curiosidade de quem as realiza, a sua vontade de “colecionar trof´eus”, obter acesso a recursos de comunicac¸˜ao ou computac¸˜ao, danificar ou sabotar sistemas e roubo de informac¸˜oes.
Para prevenir que estes incidentes acontec¸am devemos estar atentos ao que se passa no mundo inform´atico e garantir que nos prevenimos minimamente dado que muitas veze es-tes incidenes-tes podem ser devastadores, sobretudo nos casos das empresas onde para al´em dos seus dados s˜ao tamb´em respons´aveis pelos dados dos seus clientes, que se pretende sejam mantidos em privado.
A ´area da seguranc¸a deve ent˜ao ser abordada pelas empresas da mesma forma que muitas outras ´areas o s˜ao e como tal devem ter planos de seguranc¸a, ou seja, deve ser realizada uma an´alise ao problema, uma lista de requisitos e/ou politicas de seguranc¸a, definic¸˜ao das funcionalidades do sistema e uma selec¸˜ao das tecnologias que s˜ao permiti-das. A realizac¸˜ao destes planos implica um investimento na infraestrutura de seguranc¸a das mesmas, sendo que o custo associado a este investimento deve ser inferior ao valor das consequˆencias de um poss´ıvel incidente relacionado com a seguranc¸a.
Numa perspectiva formal, existem alguns conceitos e terminologia b´asica na ´area da
seguranc¸a que importa referir e descrever. Assim, diz-se que umavulnerabilidade ´e uma
fragilidade ou falta apresentada por um sistema de computac¸˜ao ou de comunicac¸˜ao, que pode ser explorada com intenc¸˜oes maliciosas. Devido `as vulnerabilidades apresentadas por um sistema, o mesmo apresenta uma elevada probabilidade de ser alvo de um ataque,
`a qual damos o nome deameac¸a. Nestas condic¸˜oes um ataque pode ser definido como
a activac¸˜ao intencional e maliciosa de uma falta no sistema, ou seja, com a intenc¸˜ao de explorar uma vulnerabilidade.
Estes ataques podem ser realizados de duas formar distintas, ou seja, podem ser
rea-lizados de forma ativa ou passiva. Umataque ativo caracteriza-se pelas tentativas
agres-sivas do utilizador malicioso para conseguir penetrar no sistema e perturbar o seu normal
funcionamento e roubar ou modificar dados. Os ataques passivos caracterizam-se por
n˜ao necessitarem de ac¸˜oes explicitas contra a seguranc¸a dos sistemas ou a integridade da informac¸˜ao contida nestes. Geralmente estes ataques s˜ao realizados atrav´es da leitura
Cap´ıtulo 2. Contexto e Soluc¸˜oes Alternativas 11 de ficheiros disponibilizados erroneamente para a Internet, fazendo login nos sistemas atrav´es da utilizac¸˜ao de credenciais predefinidas ou intersetando pacotes na rede para ob-ter algum tipo de informac¸˜ao.
A um ataque bem sucedido que resulta no estado erroneo de um sistema de comunicac¸˜ao
ou computac¸˜ao damos o nome de intrus˜ao. Se nada for feito contra as intrus˜oes, estas
podem levar `a falha da seguranc¸a do sistema. Assim, ´e importante dotar o sistema de mecanismos que permitam tolerar situac¸˜oes de intrus˜ao no sistema, de modo a que este se mantenha seguro. Por exemplo, estes mecanismos podem ser baseados na detec¸˜ao de intrus˜oes e na introduc¸˜ao de redundˆancia, que permita mascarar o comportamento in-correto do componente afetado. Estas intrus˜oes podem resultar na intercepc¸˜ao e fraude de pagamentos eletr´onicos ou sistemas de home banking, na realizac¸˜ao de transferˆencias banc´arias eletr´onicas indevidas, em espionagem industrial ou no roubo de informac¸˜oes.
Para nos ajudar a compreender melhor a ligac¸˜ao entre todos os conceitos que aqui foram introduzidos, apresentamos de seguida a Figura 2.1 [2] [3] [4].
Erro Tolerância Intrusões Prevenção Intrusões Utilizador malicioso Programador Falha Vulnerabilidade (falta) Ataque (falta) Intrusão (falta)
Figura 2.1: Modelo Ataque-Vulnerabilidade-Intrus˜ao.
O nosso projeto enquadra-se na prevenc¸˜ao de intrus˜oes uma vez que desenvolvemos uma ferramenta que descobre superf´ıcies expostas a vulnerabilidades a partir da Internet com o intu´ıdo de as eliminar o que reduz o n´umero de poss´ıveis pontos de ataque .
2.2 Ataques e vulnerabilidades
Depois da introduc¸˜ao anteriormente realizada aos conceitos de ataque e de vulnera-bilidade, nesta secc¸˜ao abordamos os ataques e as vulnerabilidades concretas que procu-ramos detetar e evitar que acontec¸am nos sistemas da empresa, fazendo de seguida uma separac¸˜ao entre os mesmos.
Neste trabalho procuramos detetar superficies expostas a partir da Internet que repre-sentem uma vulnerabilidade a determinados ataques, nomeadamente aos seguintes:
• DoS: “Denial of Service” ´e um ataque que se foca em perturbar os recursos de computac¸˜ao fazendo com que os mesmos fiquem indispon´ıveis para satisfazer as ne-cessidades para as quais foram criados. Estes ataques podem ser realizados atrav´es
da execuc¸˜ao de m´ultiplos pedidos direcionados a um determinado host tornando-o lento o que acaba por resultar na interrupc¸˜ao dos servic¸os que o mesmo disponibi-liza;
• SQLi: Um ataque “SQL injection” consiste em injetar query SQL em campos de texto (input) da aplicac¸˜ao. Se for bem realizado estes ataques podem modificar (inserir, atualizar ou remover) ou revelar informac¸˜oes sens´ıveis contidas nas bases de dados;
• XSS: Cross-Site Scripting ´e um ataque realizado atrav´es da injec¸˜ao de scripts mali-ciosos em web sites que n˜ao validam ou codifiquem os seus campos de input. Estes scripts s˜ao geralmente direcionados a outros utilizadores do mesmo web site e s˜ao executados no browser do “alvo” porque este n˜ao tˆem forma de saber se o script ´e confi´avel ou n˜ao uma vez que este vem de uma, suposta, fonte segura. Estes scripts podem aceder a informac¸˜oes retidas nas cookies ou outro tipo de informac¸˜ao sens´ıvel armazenada no browser.
No que diz respeito a vulnerabilidades, as que consider´amos no contexto particular deste trabalho foram as seguintes:
• Http.Sys: ´E uma vulnerabilidade existente na pilha do protocolo HTTP que permite a execuc¸˜ao remota de c´odigo. Esta vulnerabilidade ´e causada quando o HTTP.sys analisa de forma incorreta um pedido (malicioso) HTTP especialmente criado. Esta vulnerabilidade afeta essencialmente sistemas Windows da Microsoft.
• Heartbleed: ´E uma vulnerabilidade das bibliotecas de criptografia do OpenSSL e permite o roubo de informac¸˜ao (supostamente protegida) atrav´es da leitura de zo-nas protegidas da mem´oria. Ficam assim comprometidas as chaves secretas que s˜ao utilizadas para identificar fornecedores de servic¸os e cifrar o tr´afego, nomes de uti-lizadores e as suas passwords bem como conte´udos associados a esses utiuti-lizadores. • FREAK: ´E uma vulnerabilidade que existe em algumas das implementac¸˜oes dos
protocolos SSL/TLS e permite a utilizadores mal intencionados decifrar comunicac¸˜oes seguras entre clientes vulner´aveis e servidores. Esta vulnerabilidade pode ser facil-mente identificada nos casos em que os servidores web aceitam cifras RSA EXPORT. • POODLE: ´E uma vulnerabilidade que foi introduzida no desenho das vers˜oes 2.0
e 3.0 do protocolo SSL que permite que um utilizador malicioso consiga observar uma ligac¸˜ao segura de forma “limpa”, ou seja, texto normal. Apesar de existirem os protocolos TLS 1.0/1.1/1.2 utilizados para colmatar esta vulnerabilidade um uti-lizador mal intencionado consegue provocar a falha deste protocolo fazendo com que o sistema recorra `a vers˜ao 3.0 do protocolo SSL para conseguirem explorar a
Cap´ıtulo 2. Contexto e Soluc¸˜oes Alternativas 13 vulnerabilidade e observar a comunicac¸˜ao entre outro utilizador e o servic¸o a que este est´a a aceder.
2.3 Soluc¸˜oes para detecc¸˜ao de vulnerabilidades
Tendo em conta o principal objetivo deste trabalho, a soluc¸˜ao do mesmo poderia re-correr `a utilizac¸˜ao de ferramentas cuja funcionalidade ´e tamb´em a descoberta de portos abertos, servic¸os associados a essas portas e vulnerabilidades associadas a esses servic¸os. Nesta secc¸˜ao abordamos duas dessas ferramentas, cuja func¸˜ao ´e tamb´em a da desco-berta de vulnerabilidades dentro de sistemas inform´aticos. Falamos das suas funcionali-dades, do desempenho e explicamos a raz˜ao pela qual optamos por n˜ao utilizar nenhuma destas ferramentas no decorrer da concretizac¸˜ao deste projeto. Contudo n˜ao rejeitamos por completo a integrac¸˜ao de algumas das funcionalidades por estas realizadas num futuro pr´oximo, uma vez que s˜ao ferramentas cuja qualidade e efic´acia na detecc¸˜ao de vulnera-bilidades est´a bem comprovada.
2.3.1 Nessus
Esta ferramenta foi criada em 1998 como uma alternativa open-source ao software comercial existente. ´E usado, sobretudo, para descobrir vulnerabilidades, quer seja numa s´o m´aquina quer seja numa rede de computadores. Esta ferramenta utiliza uma linguagem pr´opria, chamada Nessus Attack Scripting Language (NASL) para criar os seus plugins. Cada plugin pode ser visto como um teste a uma determinada vulnerabilidade.
Esta ferramenta pode ser utilizada com v´arios objetivos, nomeadamente justificar in-vestimentos em tecnologias de seguranc¸a perante terceiros, ou mesmo antes que um ata-cante o fac¸a e assim poupar tempo e custos [5][6].
O funcionamento do Nessus ´e baseada num paradigma Cliente/Servidor, como mostra a Figura 2.2, onde o cliente e o servidor podem estar em qualquer s´ıtio da rede, desde que ligados `a Internet. Cliente Nessus Servidor Nessus Sistemas Alvo SSL
Assim o Cliente Nessus faz o pedido ao Servidor Nessus que ir´a de seguida proceder `a an´alise nas m´aquinas definidas como alvo. Esta comunicac¸˜ao entre cliente e servidor ´e realizada atrav´es de um canal seguro que utiliza Secure Socket Layer SSL com o intuito de proteger os dados referentes `as pesquisas realizadas. Os clientes devem ser, preferen-cialmente, em windows por terem uma melhor interface que, consequentemente, permite uma melhor leitura dos dados recolhidos.
Por sua vez o servidor corre em qualquer sistema Unix, faz as an´alises pedidas pelo cliente e guarda os resultados correspondentes em relat´orios. Esta ferramenta apresenta dois modos de utilizac¸˜ao: comercial ou “caseira”. Para ambas as vers˜oes existem 68402 plugins dispon´ıveis que cobrem 27455 Computer Vulnerabilities and Exposures (CVEs) e 20118 identificadores ´unicos de bugs [7].
Na vers˜ao caseira os relat´orios resultantes das pesquisas s˜ao armazenados em servi-dores para ser lidos mais tarde pelo cliente, que necessita de criar uma conta para poder aceder aos mesmos. E o facto mais importante neste modo de utilizac¸˜ao, a realizac¸˜ao de scans est´a limitada a um total de 16 enderec¸os IP. Outro aspeto a salientar neste modo ´e que o modo “caseiro” ´e gr´atis.
Na vers˜ao comercial os resultados s˜ao enviados aos clientes sob a forma de relat´orio onde constam as vulnerabilidades encontradas e algumas soluc¸˜oes para resolver esses mesmos problemas. Esta vers˜ao, tal como o nome indica, por ser comercial tem um custo associado de 2.190,00 USD$ por ano e por licenc¸a.
Os maiores desafios apresentados por esta ferramenta relacionam-se com o facto de lidar com falsos positivos que podem consumir demasiado tempo a determinar o verda-deiro resultado. Outro dos problemas consiste em lidar com o facto de que pode provocar a falha do sistema (routers, firewalls, outros componentes do sistema). Estas falhas po-dem ocorrer independentemente do cuidado que se possa ter a preparar a execuc¸˜ao destes scans, pelo que o utilizador/cliente deve estar preparado para o pior.
Outro desafio relaciona-se com o tempo necess´ario para executar os scans, que de-pende do n´umero de m´aquinas, portos abertos, servic¸os a correrem nesses portos, tipo de sistema operativo, quantidade de firewalls, velocidade da Internet, quantidade de tr´afego, quantidade de vulnerabilidades encontradas e ainda da possibilidade da m´aquina falhar. Por norma esta ferramenta demora algumas horas a executar um scan a uma m´aquina, 2 a 3 dias se for uma sub-rede da classe C (256 enderec¸os), podendo demorar semanas nos casos em que tem de analisar redes de classe B (65.536 enderec¸os)[7][8][5][6].
2.3.2 openVas
O OpenVAS ´e uma ferramenta open-source criada para dar continuidade ao Nessus a partir de 2008, quando este deixou de ser open-source.
Cap´ıtulo 2. Contexto e Soluc¸˜oes Alternativas 15 Nesta arquitetura podemos notar que os clientes se ligam a um gestor que ´e respons´avel pelos scans solicitados pelos mesmos. Toda a comunicac¸˜ao entre estes “m´odulos”, tal como tamb´em podemos observar no Nessus, ´e efetuada atrav´es de SSL [9].
Sistemas Alvo Cliente OpenVAS Greenbone Security Assistent Analisador OpenVAS Gestor OpenVAS Configurador Resultados NVT S er vi ços D ados C li ent es
Figura 2.3: Arquitetura OpenVAS.
Como mostra a Figura 2.3, o n´ucleo desta ferramenta orientada a servic¸os ´e o seu analisador (analisador OpenVAS), conhecido por executar de forma muito eficiente os testes armazenados na Network Vulnerabiity Tests (NVT) e que s˜ao atualizados diaria-mente (existem aproximadadiaria-mente 35 000 plugins). Utiliza um protocolo pr´oprio para transferˆencia de dados, o OpenVAS Tranfer Protocol (OTP) que por sua vez utiliza SSL para garantir seguranc¸a nessas mesmas comunicac¸˜oes [9].
O ‘Gestor OpenVAS” ´e o servic¸o central que consolida os dados dos scans realizados, para tornar esta soluc¸˜ao mais fi´avel. Toda a inteligˆencia est´a centralizada no gestor, pelo que podem facilmente ser criados clientes que sejam simples e consistentes.
´E tamb´em o gestor que ´e respons´avel por controlar as Bases de Dados (BDs) SQL onde est˜ao armazenados todos os dados e configurac¸˜oes dos scans, pela gest˜ao dos utili-zadores, por escalonar os scans, por gerir falsos positivos, e por suportar a realizac¸˜ao dos scans concorrentes, acabando por funcionar num modelo Master-Slave para controlar, num ponto central, as v´arias instˆancias de scans criadas [9].
Por sua vez, apresenta duas soluc¸˜oes diferentes para os seus clientes. O OpenVAS CLI e o Greenbone Security Assistant (GSA). O OpenVAS CLI ´e executado em linha de comandos e permite criar processos batch para controlar os scans a realizar, e pode ser executado em qualquer sistema operativo. O GSA oferece um servic¸o com interface web “slim fit” para browsers [9].
Uma vez que esta ferramenta ´e a continuac¸˜ao do Nessus de 2008, podemos ent˜ao concluir que os seus modos de atuac¸˜ao s˜ao semelhantes. Assim, as dificuldade/desafios encontrados no OpenVAS s˜ao semelhantes `as encontradas no Nessus, ou seja, a gerac¸˜ao de falsos positivos, a falta de garantias de que os scans mais completas/agressivas n˜ao ir˜ao afetar o desempenho do sistema alvo, ou at´e a falha do mesmo e ainda os problemas
relacionados com os tempos de execuc¸˜ao que j´a foram apresentados quando falamos sobre o Nessuss.
2.3.3 Discuss˜ao
As ferramentas que foram anteriormente apresentadas apresentam uma vasta capacidade de scan e an´alise. Contudo optamos por n˜ao as utilizar.
No caso do Nessus esta decis˜ao baseou-se no facto de este ter um custo associado `a sua utilizac¸˜ao e tamb´em devido ao facto de que este ferramenta n˜ao garante que os servic¸os, servidores e m´aquinas que s˜ao analisadas n˜ao ir˜ao sofrer perturbac¸˜oes no seu normal funcionamento [10].
No caso do OpenVas a nossa decis˜ao prendeu-se com o facto de esta ser uma ferra-menta derivada do Nessus e embora seja uma ferraferra-menta open-source, esta tamb´em n˜ao garante que n˜ao ir´a perturbar o normal funcionamento das m´aquinas a serem analisadas.
Assim optamos pela incorporac¸˜ao de outras ferramentas cujas funcionalidades v˜ao de encontro ao que necessitamos para realizar este projeto e tamb´em para garantir que o fun-cionamento das m´aquinas analisadas n˜ao ´e alterado. Essas ferramentas ser˜ao abordadas e descritas na secc¸˜ao seguinte.
2.4 Outras Ferramentas de seguranc¸a
Para o desenvolvimento da nossa ferramenta comec¸amos por pesquisar sobre algumas ferramentas cuja funcionalidade se enquadra dentro das carater´ısticas que pretendemos implementar no nosso projeto. Uma vez que se trata de um projeto maioritariamente virado para a an´alise de servidores web, decidimo-nos por pesquisar sobre ferramentas com capacidade para detetar servic¸os, portos e vulnerabilidades em servidores web.
Nesta secc¸˜ao falamos sobre as ferramentas que foram pesquisadas e que foram utiliza-das para dar vida a este projeto. A escolha destas ferramentas tem por base os resultados que as mesmas nos permitem obter bem como as tecnologias que s˜ao utilizadas pela em-presa onde o projeto foi desenvolvido e onde se deve integrar.
2.4.1 Nmap
O Nmap ´e uma ferramenta open-source vastamente utilizada por administradores de sistemas como uma forma de controlar a seguranc¸a dos seus sistemas atrav´es da informac¸˜ao que ´e recolhida.
Optamos por utilizar esta ferramenta devido `a necessidade que temos de descobrir quais os portos e os servic¸os que est˜ao a ser disponibilizados pelas m´aquinas que s˜ao analisadas.
Cap´ıtulo 2. Contexto e Soluc¸˜oes Alternativas 17 ´E uma ferramente que por norma ´e r´apida a realizar as suas tarefas e oferece ainda a possibilidade de execuc¸˜ao de scripts que nos podem ajudar a testar/descobrir vulnerabili-dades no sistema. Conta tamb´em com a possibilidade de apresentar os resultados obtidos em ficheiros XML, que nos poder´a ser ´util para tratamento e correlac¸˜ao de dados.
´E tradicionalmente utilizada atrav´es da linha de comandos, embora exista uma Graphi-cal User Inteface (GUI), denominada Zenmap que facilita a visualizac¸˜ao dos resultados obtidos [10][11].
2.4.2 SSLyze
O SSLyze ´e uma ferramenta, em python, que tem capacidade para analisar servidores web atrav´es das suas configurac¸˜oes de SSL. Foi utilizada para analisarmos os servidores que apresentem o porto 443 aberto. Este porto est´a, geralmente, associado ao servic¸o HTTPS.
Esta ferramenta tem capacidade para obter informac¸˜ao, se dispon´ıvel, sobre os certifi-cados do servidor (o pr´oprio certificado, datas de validade, etc...), sobre a possibilidade do servidor estar vulner´avel ao Heartbleed e permite obter informac¸˜ao sobre todas as cifras tanto SSL como TLS suportadas pelo servidor [12].
Tal como o Nmap, tamb´em o SSLyze suporta a extrac¸˜ao dos dados resultantes das suas pesquisas para v´arios formatos de ficheiros, nomeadamente para o formato XML.
2.4.3 Nikto
O Nikto ´e uma ferramenta Open Source, utilizada na an´alise a servidores web. Esta ferramenta foi concebida para realizar uma grande quantidade de testes sobre esses servi-dores, com o exclusivo intuito de ajudar `a sua protec¸˜ao.
Os plugins desta ferramenta s˜ao frequentemente atualizados e podem ser atualizados na ferramenta de forma autom´atica. Para tal, basta alterar o ficheiro de configurac¸˜ao da ferramenta. Nem todas as verificac¸˜oes feitas com esta ferramenta representam vul-nerabilidades do servidor. Alguns dos resultados dos testes realizados, tˆem uma func¸˜ao meramente informativa [13].
O Nikto tem capacidade para realizar milhares de testes, cerca de 10 mil. A Figura 2.4 mostra um pequeno excerto de um dos ficheiros que cont´em parte dos testes que esta realiza. Podemos observar nesta figura que apenas neste ficheiro existem 6608 testes.
De entre os v´arios testes realizados a ferramenta tem capacidade para testar vulnera-bilidades: a) `a possibilidade de injec¸˜oes (XSS, Scripts, HTML); b) `a possibilidade de ataque DoS; c) `a identificac¸˜ao de vers˜oes desatualizadas de software; d) links que possam conter informac¸˜ao importante; ou e) a injec¸˜oes de SQL. [14][15]
A ferramenta oferece ainda v´arias possibilidades de armazenar o seu output (“.htm”, “.xml”, “csv” e “txt”). Como as ferramentas que estamos a utilizar (Nmap e SSLyze) geram ouputs em ficheiros “.xml”, opt´amos tamb´em utilizar esse formato de output para esta ferramenta.
2.4.4 ElasticSearch
O ElasticSearch ´e uma ferramenta que neste projeto tem como func¸˜ao armazenar os dados que ser˜ao recolhidos, em cada scan realizado pelas ferramentas anteriormente refe-ridas, associados a um determinado enderec¸o. De forma gen´erica podemos dizer que esta ferramenta ´e semelhante `as bases de dados tradicionais, como demonstrado na Tabela 2.1.
BD Tradicional ElasticSearch
Base de dados Indice
Tabela Tipo
Entrada da tabela Documento
Tabela 2.1: Correspondˆencia entre BD tradicional e ElasticSearch
Com base na tabela anterior, podemos ent˜ao perceber que os dados recolhidos pelas ferramentas de scan explicadas anteriormente, ser˜ao guardadas como um documento que conter´a determinada informac¸˜ao de determinado host e dever´a ser apresentado em JSON ( JavaScript Object Notation). A cada documento ´e atribu´ıdo um identificador (id). Este id pode ser atribu´ıdo manualmente, tomando o valor que o utilizador lhe passar, ou pode ser atribu´ıdo automaticamente, caso em que o seu valor ser´a totalmente aleat´orio [16] [17].
Cada documento estar´a associado a um determinado “Tipo”. Para cada “Tipo” dever´a existir um mapeamento de dados, ou seja, tal como uma tabela de uma base de dados tradicional deve ter os campos e os tipos dos dados associados definidos, caso contr´ario os dados ser˜ao interpretados e armazenados como strings. Por sua vez, cada “Tipo” est´a associado a um “Indice” [16] [17].
2.4.5 Kibana
O Kibana ´e uma interface gr´afica, open source, que nos permite interagir e observar os dados que se encontram armazenados no ElasticSearch. Uma das grandes vantagens na utilizac¸˜ao desta ferramenta est´a no facto desta apresentar informac¸˜ao em tempo real.
Cap´ıtulo 2. Contexto e Soluc¸˜oes Alternativas 19 Al´em disso ´e uma ferramenta de f´acil acesso e, ap´os alguns minutos, de f´acil utilizac¸˜ao [18].
Oferece ao utilizar um leque variado de apresentac¸˜ao dos dados. Possibilita a visualizac¸˜ao dos dados em bruto e tem capacidade para gerar gr´aficos (barras, linhas, circulares) com base nesses mesmos dados para uma melhor percepc¸˜ao [18].
Permite ainda ao utilizar a criac¸˜ao de dashboards com diferentes gr´aficos, onde o utilizador pode visualizar diferentes dados em simultˆaneo. Estes dashboards podem ser editados a qualquer momento. Podem tamb´em ser guardados e carregados mais tarde, caso o utilizador necessite de criar outros dashboards com diferentes representac¸˜oes de dados [18].
2.4.6 Hidra Broker
O Broker ´e utilizado neste projeto como um canal de comunicac¸˜ao ao qual est´a as-sociada uma interface para a concretizac¸˜ao, quer entre as diferentes aplicac¸˜oes que se encontram em execuc¸˜ao na rede, como tamb´em para a comunicac¸˜ao com a infraestrutura do armazenamento de dados. Todas as mensagens transmitidas por este canal s˜ao auten-ticadas e consequentemente identificadas pelas credenciais de quem as transmite [19].
As comunicac¸˜oes realizadas por este canal de comunicac¸˜ao recorrem `a utilizac¸˜ao de queues que funcionam segundo o paradigma produtor/consumidor. Estas queues ofere-cem a possibilidade de v´arias aplicac¸˜oes, distribu´ıdas, comunicarem atrav´es de um mesmo canal, neste caso atrav´es do mesmo Broker[19].
Esta forma de comunicac¸˜ao ´e a utilizada pela empresa em que o projeto se inseriu e, por esta raz˜ao, o projeto foi desenvolvido de forma a que este se adaptasse facilmente `a estrutura existente.
Cap´ıtulo 3
Arquitetura do HAS
Neste capitulo abordamos o problema da detec¸˜ao de vulnerabilidades no contexto da PT Comunicac¸˜oes e introduzimos a arquitetura HAS concebida para lidar com este problema, para o qual trabalhamos com base numa soluc¸˜ao gen´erica. Associado a este problema, existem alguns requisitos espec´ıficos que o caracterizam e que tamb´em s˜ao aqui explicados.
3.1 Definic¸˜ao do Problema
O problema que nos foi exposto, apresentava como principal objetivo dotar a Direc¸˜ao de Cyber Security, Privacy e Business Continuity (DCY) da PT Comunicac¸˜oes, de uma ferramenta que oferec¸a capacidade para procurar e analisar, de forma automatizada, su-perf´ıcies expostas a ataques a partir da internet.
Este problema surge do facto de que at´e ao momento n˜ao existe, na empresa, ne-nhuma ferramenta com capacidade para realizar este tipo de procura e an´alise. Sabendo da dimens˜ao que a empresa apresenta, sabemos tamb´em que o n´umero de servidores que suportam toda a infraestrutura de rede p´ublica tamb´em ´e muit´ıssimo elevado.
Figura 3.1: Distribuic¸˜ao geogr´afica dos servidores. 21
Quanto maior um sistema for, maior ´e tamb´em a probabilidade de que o mesmo se encontre suscept´ıvel a alguma vulnerabilidade, quer por falha de quem administra os ser-vidores, ou porque quase todos os dias s˜ao descobertas novas vulnerabilidades em muitos sistemas.
Estas vulnerabilidades podem ser aproveitadas por utilizadores maliciosos que depois as conseguem explorar e ganhar acesso privilegiado aos servidores, ou roubar informac¸˜ao confidencial, quer da empresa quer dos clientes.
Outro ponto, interessante de referir, neste problema tem a ver com o facto das m´aquinas se encontrem espalhadas geograficamente, o que complica ainda mais a gest˜ao que deve ser feita regularmente para garantir que os servidores estejam sempre atualizados e segu-ros.
A criac¸˜ao de uma ferramenta para este tipo de an´alise facilitar´a o trabalho das equipas respons´aveis por gerirem estes servidores, que ter˜ao aqui um auxilio importante nos casos em que por alguma raz˜ao alguma atualizac¸˜ao n˜ao tenha sido realizada, ou em casos em que novas vulnerabilidade tenham sido divulgadas.
3.2 Requisitos do Sistema
Para a criac¸˜ao desta ferramenta devemos ter em conta alguns aspectos referidos ante-riormente, tais como o elevado n´umero de m´aquinas e a necessidade que existe de uma ferramenta que seja capaz de fazer esta an´alise `a rede.
De forma a podermos atacar este problema consideramos que a ferramenta deve apre-sentar algumas carater´ısticas que nos ajudem a que a mesma seja implementada com sucesso.
As carater´ısticas que consideramos importantes s˜ao:
• Escalabilidade: a ferramenta deve ser escal´avel uma vez que estamos a lidar com uma rede de dimens˜oes consider´aveis. Os casos em que ´e necess´ario analisar toda a rede devem ser tomados em conta. Com esta carater´ıstica podemos garantir que independentemente do n´umero de servidores analisados, a resposta da ferramenta ser´a sempre semelhante;
• Distribuic¸˜ao: a ferramenta dever´a oferecer a possibilidade de ser executada de forma distribu´ıda. Desta forma a carga de trabalho dos v´arios scans realizados pode ser distribu´ıda por servidores diferentes,a para evitar que os mesmo influenciem em demasia o desempenho das m´aquinas onde se encontram e tamb´em por precauc¸˜ao no caso de algum dos servidores falhar;
• Expans˜ao: a ferramenta deve ser concretizada de forma modular, ou seja, atrav´es de plugins. Desta forma garantimos a facilidade em adicionar ou remover m´odulos `a ferramenta, por serem individuais e n˜ao estarem inter relacionados;
Cap´ıtulo 3. Arquitetura do HAS 23 • Capacidade de an´alise: a ferramenta deve ser capaz de realizar v´arios tipos de an´alise. Para tal deve utilizar diferentes ferramentas para realizar os scans ne-cess´arios;
• Compatibilidade: a ferramenta deve ser compat´ıvel com a infra estrutura existente para garantir a sua total funcionalidade.
3.3 Arquitetura gen´erica da soluc¸˜ao
A figura que se segue (Figura 3.2) apresenta aquela que foi a nossa proposta de soluc¸˜ao para o problema anteriormente apresentado. Como podemos perceber atrav´es da observac¸˜ao da imagem, a nossa soluc¸˜ao baseou-se na modularizar˜ao da soluc¸˜ao identifi-cando as funcionalidades essenciais agrupadas em torno de uma plataforma de comunicac¸˜ao. Genericamente pretende-se que cada m´odulo funcional possa ser concretizado atrav´es da implementac¸˜ao de um conjunto de plugins.
Scan e& análise Inicialização Orquestração Visualização& de& resultados Hidra&Broker Transporte&
dados Armazenamento&de&dados
Figura 3.2: Arquitetura gen´erica da soluc¸˜ao.
Relativamente `a plataforma de comunicac¸˜ao, ficou decido `a partida que seria utilizado o Hidra Broker uma vez que esta ´e a tecnologia utilizada o pela PT Comunicac¸˜oes para a concretizac¸˜ao das comunicac¸˜oes entre as diversas aplicac¸˜oes existentes na empresa com o reposit´orio de dados.
No nosso caso, o Hidra Broker servir´a como meio de intercomunicac¸˜ao entre os nos-sos plugins, e tamb´em entre os plugins e o armazenamento de dados. Desta forma
te-mos garantido a compatibilidade da ferramenta com a infraestrutura existente na PT
Comunicac¸˜oes, satisfazendo assim um dos requisitos apresentados anteriormente.
Atrav´es da utilizac¸˜ao de plugins ficamos com a possibilidade de distribuir a nossa
plugins da ferramenta. Adistribuic¸˜ao da ferramenta ´e, tamb´em, utilizada como garantia de que no caso de falha de um dos plugins os restantes tˆem a possibilidade de manter o seu normal funcionamento, uma vez que estes s˜ao independentes entre si.
Recorrendo `a distribuic¸˜ao dos plugins da ferramenta, esta torna-se facilmente
es-cal´avel atrav´es da criac¸˜ao de v´arias instancias de execuc¸˜ao dos plugins. Este ´e um ponto relevante uma vez que lidamos com uma rede de grandes dimens˜oes.
Dada a func¸˜ao desta ferramenta e a decis˜ao que tom´amos de recorrer `a utilizac¸˜ao de plugins, uma das partes mais importantes da mesma ´e a realizac¸˜ao de scans e an´alise dos dados resultantes dos mesmos. Assim, temos os scans divididos por plugins tornando a
ferramentaexpans´ıvel uma vez que quando for necess´ario realizar um scan diferente, dos
j´a realizados, basta criar um novo plugin que se ligue ao mesmo canal de comunicac¸˜ao. Com a facilidade existente da expans˜ao da ferramenta conseguimos garantir, por fim,
umagrande capacidade de an´alise sendo que basta adicionar novos plugins com
capa-cidade para testarem e detetarem diferentes vulnerabilidades.
Esta ferramenta apresenta distintos grupos de plugins aos quais est˜ao associadas dife-rentes func¸˜oes. Temos ent˜ao um grupo de plugins com a responsabilidade de inicializac¸˜ao da ferramenta, respons´aveis pela parametrizac¸˜ao da mesma, um grupo de plugins com a responsabilidade de orquestrac¸˜ao, ou seja, tem a responsabilidade de tomar decis˜oes quanto ao encaminhamento dos dados dentro da ferramenta, um grupo de plugins para a realizac¸˜ao de scans e an´alise respons´aveis por realizar pesquisar por informac¸˜oes es-pec´ıficas, de acordo com o plugins, sobre determinado host, um grupo de plugins res-pons´avel pela visualizac¸˜ao dos dados recolhidos e, temos por fim um canal de comunicac¸˜ao respons´avel pelo transporte dos dados e por ligar todos os plugins entre si e com o arma-zenamento de dados.
Esta ferramenta ter´a ent˜ao o inicio da sua execuc¸˜ao atrav´es do plugin de parametrizac¸˜ao, respons´avel por tratar do input da ferramenta encaminhando os dados iniciais para o sitio correto, atrav´es da utilizac¸˜ao do Hidra Broker respons´avel pelo transporte dos dados.
De seguida ´e realizado um scan inicial para o levantamento de informac¸˜ao prim´aria dos hosts que ser˜ao analisados. Estes dados ser˜ao encaminhados para o armazenamento de dados (ES) bem como para o plugin de orquestrac¸˜ao que ser´a respons´avel por distribuir os hosts pelos plugins com os testes que devem de ser executados sobre os mesmos. De notar que associado a cada plugin existe uma queue que servir´a para que os plugins possam receber a informac¸˜ao que lhes interessa para a concretizac¸˜ao das suas tarefas.
O plugin de visualizac¸˜ao pode ser utilizado em qualquer momento da realizac¸˜ao dos scans, embora possa apresentar falta de alguns resultados devido `a execuc¸˜ao dos scans.
Cap´ıtulo 4
Concretizac¸˜ao do sistema HAS
Neste cap´ıtulo descrevemos em detalhe o Hound Attack Surface (HAS), caracteri-zando os diversos componentes e plugins que instanciam a estrutura gen´erica apresentada no cap´ıtulo anterior. A concretizac¸˜ao ´e tamb´em descrita numa perspectiva funcional e estrutural.
4.1 Definic¸˜ao dos componentes da arquitetura
De acordo com a arquitetura gen´erica apresentada no cap´ıtulo anterior, a nossa soluc¸˜ao ´e baseada na utilizac¸˜ao de plugins, cada um com uma func¸˜ao especifica. Um plugin ´e constitu´ıdo por um conjunto de scripts que s˜ao programados de acordo com as func¸˜oes que se pretende que este realize.
Atrav´es da Figura 4.1 podemos observar os diferentes plugins que foram desenvolvi-dos na concretizac¸˜ao da nossa soluc¸˜ao. De acordo com a arquitetura gen´erica apresentada anteriormente (Figura 3.2) os plugins est˜ao enquadrados em diversos grupos de acordo com a natureza das func¸˜oes realizadas, nomeadamente func¸˜oes de parametrizac¸˜ao, de orquestrac¸˜ao, de colec¸˜ao e an´alise de dados e visualizac¸˜ao de resultados.
Para aparametrizac¸˜ao da ferramenta foi desenvolvido um plugin denominado “Has”
que ´e constitu´ıdo por dois scripts(a descric¸˜ao detalhada de cada script ´e feita na secc¸˜ao 4.4):
• “has.rb”: respons´avel pela interac¸˜ao com o utilizador;
• “separator.rb”: respons´avel por tratar os dados de input da ferramenta;
Para aorquestrac¸˜ao da ferramenta, ou seja, para a realizac¸˜ao de tarefas de
encaminha-mento de dados para os plugins de scan adequados, foi desenvolvido o plugin “Maestro”, constitu´ıdo tamb´em ele por dois scripts:
• “maestro.rb”: respons´avel por receber e tomar as decis˜oes de encaminhamento dos dados;
• “maestro sender.rb”: respons´avel pela transmiss˜ao dos dados; ES Kibana Internet Separator sslScan httpScan niktoScan
Hidra5
Broker
Internet Maestro ptScan •Lista5hosts; •Marcaras5 de5rede; addrQueuesslQueue httpQueue niktoQueue
excelGenerator Excel5 Report HAS 1 2 3 4 5 6 7 8 7.1 9 10 11 11.1
Figura 4.1: Arquitetura do HAS.
Para a realizac¸˜ao dosscans e da an´alise dos dados, inclu´ımos na arquitetura os
plu-gins “ptScan”, “sslScan”, “niktoScan” e “httpScan”. Dependendo do tipo e variedade de testes a fazer, podem ser adicionados outros plugins deste tipo. Cada um deles ´e cons-titu´ıdo por 2 scripts e poder´a ainda recorrer `a utilizac¸˜ao de um ficheiro de configurac¸˜ao para a configurac¸˜ao dos testes que os mesmos ir˜ao realizar. Os scripts que constituem estes plugins s˜ao, de forma gen´erica:
• “script de scan”: respons´avel por realizar um determinado tipo de scan;
• “script de analis”: respons´avel por analisar os resultados desse scan e encaminhar os dados para o armazenamento;
Para avisualizac¸˜ao dos dados criamos o plugin “excelGenerator”, constitu´ıdo pelos
scripts:
• “generator.rb”: respons´avel pela interac¸˜ao com o utilizador;
• “excelcior.rb”: respons´avel por dar inicio ao processo de criac¸˜ao da folha de c´alculo de acordo com as indicac¸˜oes do utilizador;
Cap´ıtulo 4. Concretizac¸˜ao do sistema HAS 27 • “fillPorts.rb”: respons´avel por preencher a informac¸˜ao referente aos portos
deteta-dos como abertos;
• “fillTests.rb”: respons´avel por dar tratar da separac¸˜ao do preenchimento dos dados referentes aos diferentes scans realizados;
• “sslTests.rb”: respons´avel por preencher os dados referentes ao scan realizado pelo plugin “sslScan”;
• “niktoTests.rb”:respons´avel por preencher os dados referentes ao scan realizado pelo plugin “niktoScan” ;
• “sysTests.rb”: respons´avel por preencher os dados referentes ao scan realizado pelo plugin “httpScan”;
• “formats.rb”: respons´avel por guardar informac¸˜ao referente `a formatac¸˜ao da folha de c´alculo;
• “searcher.rb”: respons´avel pela concretizac¸˜ao das pesquisas no reposit´orio de dados que permitem o preenchimento da folha de c´alculo no seu todo;
4.2 Vis˜ao Estrutural
A organizac¸˜ao dos diversos plugins em grupos distintos n˜ao ´e apenas motivada pela natureza das func¸˜oes, mas est´a tamb´em relacionada com quest˜oes de seguranc¸a, com implicac¸˜oes na estrutura do sistema. Na Figura 4.2 pode observar-se que parte do sistema se encontra numa zona reservada da rede, e apenas um conjunto de scripts se encontram numa zona p´ublica.
Consideramos ser importante manter os plugins de orquestrac¸˜ao, parametrizac¸˜ao e de visualizac¸˜ao dentro de uma zona segura da rede onde o acesso a estes ´e concretizado de forma controlada.
Os plugins de parametrizac¸˜ao, orquestrac¸˜ao e visualizac¸˜ao encontram-se centraliza-dos numa, ou em diferentes m´aquinas, em que o acesso ´e tamb´em realizado de forma controlada. No caso do plugin de visualizac¸˜ao n˜ao queremos que um utilizador malici-oso tenha acesso aos relat´orios gerados ap´os a realizac¸˜ao dos scans ficando na posse de informac¸˜ao privilegiada referente `as vulnerabilidades dos sistemas da empresa. Quando `a parametrizac¸˜ao tamb´em n˜ao queremos que um utilizador malicioso possa aceder aos parˆametros de execuc¸˜ao da ferramenta e alter´a-los para beneficio pr´oprio. Por fim o plu-gin de orquestrac¸˜ao, dado o papel que desempenha, pode ser replicado nos casos em que ´e necess´ario obter um melhor desempenho da ferramenta.
No caso dos plugins com responsabilidades de realizar os scans, que s˜ao os que tˆem a maior carga de trabalho, estes encontram-se replicados em diversas m´aquinas (sondas) do
sistema. Recorremos `a replicac¸˜ao e distribuic¸˜ao destes plugins com o intuito de aumentar o desempenho da nossa ferramenta bem como para distribuir a carga de trabalho por v´arias m´aquinas. Internet ptScan parametrização orquestração visualização ptScan niktoScan niktoScan sslScan sslScan armazena mento Zona7reservada7 da7Rede Zona7pública77 da7Rede httpScan httpScan
Hidra7Broker
Figura 4.2: Vis˜ao estrutural do sistema.
Estes plugins tˆem um requisito especial, devem conseguir estar ligados `a rede interna e `a internet simultaneamente, visto que estes necessitam de realizar scans atrav´es da Inter-net e necessitam de acesso `a rede interna para armazenar a informac¸˜ao que foi recolhida. Para tal recorremos `a definic¸˜ao de rotas em cada m´aquina para que estes plugins possam realizar as comunicac¸˜oes necess´arias com o restante sistema.
4.3 Vis˜ao Funcional
Do ponto de vista funcional, e recorrendo `a Figura 4.1, a ferramenta inicia a sua execuc¸˜ao atrav´es do plugin de parametrizac¸˜ao, respons´avel pela interac¸˜ao com o utilizador e leitura do ficheiro de hosts/ IPs/ m´ascaras de rede que o mesmo lhe passa (1). Ap´os a leitura do ficheiro (2), o plugin publica no canal de comunicac¸˜ao um evento contendo dados para cada um dos enderec¸os indicados pelo ficheiro de configurac¸˜ao (3).
Estes dados s˜ao retidos pela queue associada ao plugin do scan inicial (4), onde ´e rea-lizado um levantamento dos portos abertos bem como dos servic¸os que est˜ao a correr em cada porto (5). Ap´os a realizac¸˜ao do scan, os dados s˜ao analisados, tratados e colocados novamente no canal de comunicac¸˜ao sob a forma de evento (6).
Este evento ser´a retido pela queue associada ao plugin de orquestrac¸˜ao (7), que por sua vez ir´a avaliar estes dados e decidir para onde os mesmos devem ser encaminhados, de acordo com os portos que foram identificados como estando abertos. Este encaminha-mento ´e mais uma vez feito sob a forma de evento para o canal de comunicac¸˜ao (8).
