Realizando um teste com Tenable Nessus 3:
Após haver descarregado, activado e instalado o
produto o primeiro que temos que fazer é actualizar o banco de dados
de plugins do produto. Se é a primeira vez que o arrancamos o
perguntará ele mesmo, se não, temos uma ferramenta para invocar a
actualização em qualquer momento. Depois configuramos o servidor,
escolhendo a direcção IP e a porta pelo que vai escutar o serviço
Nessus. Eventualmente, para conexões remotas, deveríamos gerar a lista de usuários aos que se lhes permite a conexão com este servidor.
Imagem: Gestão de políticas
Imagem: Configuração de Settings de uma política
A outra parte a afinar são directamente os plugins, para isso, quando achemos uma política deveremos escolher que é o que queremos buscar. Não faz sentido realizar busca de erros locais em Gentoo, quando estamos testando remotamente um Windows Server 2003 R2. Para facilitar esta gestão todos os plugins estão agrupados em categorias e poderemos acrescentar ou tirar categorias ou directamente plugins. A execução de muitos dos plugins se realizará levando em conta as configurações definidas previamente na política.
Imagem: Configuração de Plugins
De todos e cada um dos plugins que acompanham Nessus há uma ficha de informação acessível no programa e que se mantém online no site da companhia. Com simplesmente clicar sobre o plugin poderemos saber que é o que olha, qual é o factor de risco e se o plugin pode afectar ou não a nosso servidor.
Imagem: Informação de um Plugin
Uma vez definida as políticas do teste podemos proceder já a realizar o scaneamento do servidor. Para isso seleccionamos NewScan, escolhemos a política e o motor Nessus desde o que desejamos que se realize, não se pode esquecer que a arquitectura de Nessus é cliente/servidor, graças ao que poderemos configurar múltiplos testes desde múltiplos servidores.
O processo completo se pode ver na imagem seguinte:
Imagem: Processo de scan
Relatório de Auditoria
Agora a receber os deveres. Cada vez que se termina um scaneamento, o Nessus gera um relatório do teste completo que se armazena em um arquivo xml. O Dito relatório permite que se realizem diferentes visualizações do mesmo para reflectir a informação que tirou o scaner. Nos relatórios se poderá ver desde os dados que são puramente informativos até a informação que é substancialmente importante para a segurança e deve ser corregida.
Imagem: Relatório de auditoria
Bom, uma vez que você tem o relatório, o que se deve fazer? Bem, em um teste de intrusão completo de uma companhia se avaliam todas as vulnerabilidades tentando chegar no final, isto é, sim com um exploit pode-se conseguir o controle de uma equipe da empresa, pois a seguir antecipe para ver até que nível de risco se estaria em um caso de uma vulnerabilidade similar e realizar um teste de intrusão do sistema completo. Isto permitirá descobrir erros na política de segurança da rede.
Se o que queremos é simplesmente corrigir o servidor então deveremos seguir as recomendações para a solução de cada um dos erros, estas as vamos encontrar nos expedientes de segurança. Uma vez aplicadas as medidas de correcção para todas as vulnerabilidades deveremos voltar a scanear o mesmo servidor e obter um novo relatório. O processo deve repetir-se até que o relatório fique totalmente “limpo”. Uma das características do Nessus que podemos utilizar para este processo é a comparação de relatórios, com o qual poderemos comparar as mudanças sofridos na segurança do servidor em cada mudança que apliquemos ao servidor.
Imagem: Gestão de Relatórios
Hoje em dia Nessus é o scaner de vulnerabilidades mais utilizado em nível mundial mesmo que não é o único e existem outras alternativas/complementos muito interessantes. Mesmo que há bastantes scanners de vulnerabilidades, neste artigo veremos algumas das melhores soluções profissionais. O processo de testes em qualquer destas soluções é similar ao explicado com Nessus.
Para terminar:
Um último ponto sobre o qual é preciso reflectir antes de dar por terminado este artigo é o teste das próprias aplicações, isto é, os desenvolvimentos pessoais. Uma aplicação web configurada para a Internet, com https, com seu firewall protegendo-a e assim por diante, com seus testes de segurança feitos com scanners de vulnerabilidades, pode ter um lindo SQL Injection em um rádio button e se acabou o conto de fadas. No caso dos desenvolvimentos pessoais é necessário contar com uma aproximação diferente, com ferramentas diferentes e com mais uns testes destros, já que não só devem conhecer o uso das ferramentas mas também os erros no desenvolvimento de tecnologias. Para aqueles que lhes interesse este tema brevemente vou lhes mostrar como se realiza um processo de testes numa aplicação web e quais são as ferramentas que se podem utilizar.
Dou por terminado este teste de intrusão simplificado, espero que tenham gostado, e abraços a todos.
Fim do 6o e ultimo capitulo
Imagem: Gestão de políticas
Imagem: Configuração de Settings de uma política
A outra parte a afinar são directamente os plugins, para isso, quando achemos uma política deveremos escolher que é o que queremos buscar. Não faz sentido realizar busca de erros locais em Gentoo, quando estamos testando remotamente um Windows Server 2003 R2. Para facilitar esta gestão todos os plugins estão agrupados em categorias e poderemos acrescentar ou tirar categorias ou directamente plugins. A execução de muitos dos plugins se realizará levando em conta as configurações definidas previamente na política.
Imagem: Configuração de Plugins
De todos e cada um dos plugins que acompanham Nessus há uma ficha de informação acessível no programa e que se mantém online no site da companhia. Com simplesmente clicar sobre o plugin poderemos saber que é o que olha, qual é o factor de risco e se o plugin pode afectar ou não a nosso servidor.
Imagem: Informação de um Plugin
Uma vez definida as políticas do teste podemos proceder já a realizar o scaneamento do servidor. Para isso seleccionamos NewScan, escolhemos a política e o motor Nessus desde o que desejamos que se realize, não se pode esquecer que a arquitectura de Nessus é cliente/servidor, graças ao que poderemos configurar múltiplos testes desde múltiplos servidores.
O processo completo se pode ver na imagem seguinte:
Imagem: Processo de scan
Relatório de Auditoria
Agora a receber os deveres. Cada vez que se termina um scaneamento, o Nessus gera um relatório do teste completo que se armazena em um arquivo xml. O Dito relatório permite que se realizem diferentes visualizações do mesmo para reflectir a informação que tirou o scaner. Nos relatórios se poderá ver desde os dados que são puramente informativos até a informação que é substancialmente importante para a segurança e deve ser corregida.
Imagem: Relatório de auditoria
Bom, uma vez que você tem o relatório, o que se deve fazer? Bem, em um teste de intrusão completo de uma companhia se avaliam todas as vulnerabilidades tentando chegar no final, isto é, sim com um exploit pode-se conseguir o controle de uma equipe da empresa, pois a seguir antecipe para ver até que nível de risco se estaria em um caso de uma vulnerabilidade similar e realizar um teste de intrusão do sistema completo. Isto permitirá descobrir erros na política de segurança da rede.
Se o que queremos é simplesmente corrigir o servidor então deveremos seguir as recomendações para a solução de cada um dos erros, estas as vamos encontrar nos expedientes de segurança. Uma vez aplicadas as medidas de correcção para todas as vulnerabilidades deveremos voltar a scanear o mesmo servidor e obter um novo relatório. O processo deve repetir-se até que o relatório fique totalmente “limpo”. Uma das características do Nessus que podemos utilizar para este processo é a comparação de relatórios, com o qual poderemos comparar as mudanças sofridos na segurança do servidor em cada mudança que apliquemos ao servidor.
Imagem: Gestão de Relatórios
Hoje em dia Nessus é o scaner de vulnerabilidades mais utilizado em nível mundial mesmo que não é o único e existem outras alternativas/complementos muito interessantes. Mesmo que há bastantes scanners de vulnerabilidades, neste artigo veremos algumas das melhores soluções profissionais. O processo de testes em qualquer destas soluções é similar ao explicado com Nessus.
Para terminar:
Um último ponto sobre o qual é preciso reflectir antes de dar por terminado este artigo é o teste das próprias aplicações, isto é, os desenvolvimentos pessoais. Uma aplicação web configurada para a Internet, com https, com seu firewall protegendo-a e assim por diante, com seus testes de segurança feitos com scanners de vulnerabilidades, pode ter um lindo SQL Injection em um rádio button e se acabou o conto de fadas. No caso dos desenvolvimentos pessoais é necessário contar com uma aproximação diferente, com ferramentas diferentes e com mais uns testes destros, já que não só devem conhecer o uso das ferramentas mas também os erros no desenvolvimento de tecnologias. Para aqueles que lhes interesse este tema brevemente vou lhes mostrar como se realiza um processo de testes numa aplicação web e quais são as ferramentas que se podem utilizar.
Dou por terminado este teste de intrusão simplificado, espero que tenham gostado, e abraços a todos.
Fim do 6o e ultimo capitulo
0 comentários:
Postar um comentário