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 aproximadamente 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 ferramenta 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.