quarta-feira, 20 de junho de 2012

Teste de Instrusão [ 40 - 50 ]


Durante dias estivemos recorrendo ás ferramentas que vão desde de a recolha da informação que oferece um sistema informático até como funciona o ciclo de bug, exploits, scanner de vulnerabilidades. Esta vez nos centramos nas ferramentas principais para a realização de um teste de intrusão.
Os scanners de Vulnerabilidades:
Este tipo de ferramentas são a peça principal quando se vai realizar uma auditoria de segurança, tanto de whitebox, como de blackbox. Englobam o conjunto de ações necessárias para identificar os IPS activos, as portas e serviços oferecidos, a identificação do sistema operativo, o nível de actualizações de segurança aplicadas e inclusive a detecção e exploração das vulnerabilidades encontradas. Dentro dos múltiplos scanners de vulnerabilidades existem mais ou menos amigáveis, isto é, os que é preciso não executam nunca a fase de tentativa de exploração dos erros achados e outros que os provam como forma normal de trabalho. Isto pode levar a que a realização de uma auditoria com um scanner pouco “friendly” possa “derrubar” algum serviço ou servidor.
Se estas ferramentas realizam todas as fases do processo, isto quer dizer que todas as ferramentas anteriores não são necessárias? Não, as ferramentas anteriores são muito mais específicas na sua função e permitem ser afinadas muito além do que permitirá uma scanner de vulnerabilidades completo.
Outra das características dos scanners de vulnerabilidades é que não são todos iguais, nem na detecção, nem na avaliação dos riscos, nem na profundidade das análises, por tanto sempre é recomendável a utilização de, pelo menos, um par deles em um bom estudo.
Satã, Santa e Nessus:
Mesmo que previamente tinham aparecido muitos scanners de uma vulnerabilidade ou um exploit, talvez o primeiro scanner de vulnerabilidades completo que se achou foi S.A.T.A.N. (Security Administrator Tool for Analyzing Networks). Seu nome gerou muita controvérsia por tanto o modificaram e apareceu a versão SAINT “SANTA” (Security Administrator’s Integrated Network Tool) que hoje em dia se comercializa.
No relevo destes surgiu o Nessus, aparecendo no ano 1998, da mão de Renaud Deraison, a primeira versão pública do produto. Na sua origem e até ao ano 2005 todas as versões saíram sob a forma GPL, mas no final do ano 2005 anunciaram que a versão 3 seria gratuita mas não GPL. As últimas versões do Nessus se podem obter do site http://www.nessus.org mas pertencem à empresa Tenable Network Security, a empresa que Renaud criou no ano 2002.
Nessus:
Nessus é uma das ferramentas preferidas por todos na hora de realizar um teste de penetração em uma rede devido a algumas de suas características.
Actualização e funcionamento mediante Plugins: Todos os scanners de vulnerabilidades devem oferecer um sistema de actualizações rápido para detectar as novas vulnerabilidades, que aparecem constantemente. No Nessus funciona mediante plugins, podemos e devemos actualizar o banco de dados antes de cada execução para ter sempre actualizado o repositório. Para fazer o sistema muito mais flexível na criação de plugins, e para poder ser alimentado com conhecimento próprio, podemos criar nossos próprios plugins acrescentados utilizando a linguagem NASL (Nessus Attack Scripting Language).
Imagem: Detecção de Plugins
Imagem
Imagem: Actualização de Plugins


- Arquitectura cliente/servidor: O sistema está desenhado para funcionar desde diferentes clientes contra diferentes objectivos, assim, Nessus corre como serviço na máquina que você deseje e pode ser utilizado desde qualquer cliente. Esta arquitectura é independente de plataforma e permite instalar, tanto os clientes como os servidores em arquitecturas Microsoft e *NIX. Isto vai permitir fazer esforços económicos para ter um melhor servidor que vai ser produtivo para muitos clientes. Além disso, os objectivos podem ser quase de qualquer tipo já que sua base de conhecimento detecta vulnerabilidades em Servidores, clientes e dispositivos de rede correndo Windows, *NIX ou MacOS.
Imagem
Imagem: Configuração de Serviço Servidor
- Políticas de auditoria: É importante que qualquer scanner de vulnerabilidades permita afinar a política a aplicar, poder escolher os serviços e as vulnerabilidades a testar (não é o mesmo testar um servidor de correio que e um servidor FTP), que se integre com os diferentes protocolos de comunicações (alguns scanners têm problemas com os protocolos SSL) e que se possa decidir se queremos um scaneamento amigável ou um até as últimas consequências, isto é, que prove tudo ainda assumindo que podemos realizar uma denegação de serviço em alguns serviços ou no sistema. Para isso no Nesus, quando achemos ou editamos uma política definiremos se queremos uma Segura ou não é depois os plugins que queremos que prove no processo de auditoria.
GfI Languard Network Security Scanner:
A empresa GFI tem uma ampla gama de ferramentas de segurança, desde ferramentas para a protecção de servidores, ferramentas para a gestão e correlação de eventos de segurança e como não um scanner de vulnerabilidades, LanGuard Network Security Scanner. Esta solução foi tradicionalmente uma das mais utilizadas em ambientes Microsoft e teve uma grande aceitação em Portugal. Além de uma política de preços muito acessível. O produto não só é um scanner de vulnerabilidades mas além disso é uma solução que permite desdobrar remendos. Da mesma forma que Nessus e a maioria das soluções equivalentes permite o afilado das políticas. Para escrever este artigo se utilizou a versão 8 do produto que actualmente está em versão beta. Na hora de scannear e testar uma plataforma Microsoft esta é uma das melhores soluções, é a solução que mais informação oferece e melhores resultados amostra. Nas políticas por defeito expande algumas vulnerabilidades, isto é, as aproveita, sempre que não sejam daninhas. Muito recomendada.
Imagem
Imagem: GFI Languard Network Security Scanner
Shadow Security Scanner:
Esta ferramenta, de Safety-Lab, foi uma das minhas preferidas durante muito tempo porque era “pouco friendly”, de fato a chamávamos carinhosamente “a besta parda”. Esta forma de trabalhar a ferramenta lhe vinha herdado de seu predecessor Shadow Scanner, uma ferramenta que não se vendia e que estava pensada não como Scanner de Vulnerabilidades mas como um Scanner para atacar, com opções de bombardeio inclusive. Este perfil da companhia se nota com outras ferramentas como Shadow Instant Message, ferramenta que se usa para “testar a segurança” das conexões dos sistemas de mensagem instantânea como MSN Messenger ou Yahoo Messenger. Ainda é possível encontrar a primeira ferramenta nos “para conversar” de Internet. A dia de hoje a manutenção e actualização de Shadow Security Scanner decaiu ligeiramente e pessoalmente acho que está atrás de suas competidoras. Não tem suporte em castelhano mas sim em catalão. Você pode descarregar uma versão de avaliação completamente funcional durante 15 dias desde o site da companhia http://www.safety-lab.com.
Imagem
Imagem: Shadow Security Scanner
E-eye Retina:
A empresa E-eye, famosa por seu sniffer IRIS, tem a solução Retina para a auditoria de vulnerabilidades em software. Pode-se conseguir uma versão totalmente funcional de 15 dias do site da empresa: http://www.e-eye.com
Imagem: E-eye Retina Network Security Scanner
Outros scanners:
Existem outros muitos scanners de vulnerabilidades, tanto pagos, como livres, realizados por comunidades de programadores, talvez alguns de vocês joguem em falta o ISS (Internet Security Scanner), NetBrute ou XScan ou qualquer outro, mas no final as ideias são similares. Minha recomendação como sempre é contar com um par deles pelo menos em qualquer teste de intrusão que se vá realizar.
Resumo do processo:
Se tivéssemos que resumir brevemente qual é o processo que é preciso seguir para a realização de um teste de intrusão seria o seguinte:
Citar:
1.- Identificar o que se quer testar: Utilizando as técnicas de Footprinting e FingerPrinting vistas na primeira parte.
2.- Procurar as vulnerabilidades desses produtos: Utilizando os expedientes de segurança ou os scanners de vulnerabilidades vistos na segunda e terceira parte.
3.- Procurar os exploits para essas vulnerabilidades como vimos na segunda parte deste artigo.
4.- Patchear para deixar o sistema corregido e feito como recomenda o fabricante do software nos expedientes de segurança da vulnerabilidade.
Este processo deve ser parte do plano de manutenção dos serviços/servidores e deve estar igual de planeado como o processo de cópia de backup ou de actualização de software, no entanto, nos dia de hoje, isto se realiza em poucas empresas ou não tantas como devessem, em um claro sintoma de distracção para seu sistema informático.
Isso é tudo?
Pois não, em primeiro lugar é preciso levar em conta que um teste de intrusão realizado por dois auditores diferentes pode obter resultados díspares dependendo da destreza de um auditor na hora de configurar as políticas dos scanners para saltar os mecanismos de segurança intermédios ou afinar os plugins a executar. Além de tudo isto é preciso levar em conta que uma auditoria de segurança só tem validade para o ponto de execução desde onde se executa, isto é, imaginemos que realizamos um teste de intrusão a partir da Internet e há uma vulnerabilidade que está sendo protegida pelo firewall de perímetro em nível de aplicação. Através da Internet poderemos ter um sistema que aparentemente não é vulnerável, enquanto um acesso desde a intranet ou desde uma conexão VPN pode detectar a vulnerabilidade.
← Postagem mais recente Postagem mais antiga → Página inicial

0 comentários:

Postar um comentário

Copyright © Hacking & Security | Powered by Xandao Design by Xandao86 | Xandao86