Penetration Testing Lab - por Backtrack Brasil - parte 1

[firebits]

1. laboratorio em testes de penetração
1. descrição
2. propósito
3. objetivo
4. 1o perspectiva
5. 2o perspectiva
6. requisitos
7. hardware
8. software
9. outros dispositivos
10. design
11. descrição
12. desenvolvendo um lab (virtual lab / cenário economico)
13. diagrama
14. cenários de ataques
15. segurança de lab
16. segurança em lab physical
17. controle de acesso lógico
18. apêndice

1. Penetration Testing Lab
Em todo lugar na Internet você encontra códigos liberados e ferramentas, destinados a ajudar a fazer cracking de software ou hardware. O software crakeado poderia ser uma tentativa de um hacker Black Hat em tentar obter o acesso não autorizado a alguma rede, o que não é coberto aqui. Alternativamente, o trabalho de pentesting poderia estar tentando revelar falhas críticas em servidores ou redes corporativas, a pedido dos proprietários. A maneira mais fácil é fazer é usar ferramentas, e procurar as vítimas vulneráveis, mas um vamos ter apenas resultados simples. O primeiro é "Bingo! Estou em ... ", eo segundo é" Ah, merda, ele não funcionou. Vamos tentar outra coisa ... ". É fácil, mas altamente arriscado. E se as ferramentas / código malicioso fazer algo diferente do que se esperava!

Muitas vezes se lê de worms, vírus que infectam a internet e causam danos. Deve-se esperar até que um deles bate na rede e em seguida, tentar analisá-lo e ver o que ele faz? Certamente não, porque aí já é tarde demais.

Estas não são as únicas utilizações para este tipo de Lab, no caso um Pentest Lab.

Por exemplo, se uma empresa está tentando implementar uma solução de segurança na rede, algo como em um novo cliente baseado em pacote de segurança contendo IDS / IPS / Antivirus / Firewall, o habitual maneira é fazer o download da versão trial e instalá-lo em algum lugar e ver como funciona. Mas onde é que "em algum lugar"?

Este é um caso de uso para um Lab de Testes também.

1.1 Descrição
Um Lab de Testes é geralmente uma parte isolada da própria rede. Ele inclui servidores, clientes e dispositivos com os seus serviços, para simular uma rede completa de trabalho. Esses computadores e redes podem ser completamente simulados, como aqueles executados em produção com a ajuda de ferramentas, ou a cada nó único deste Lab de Testes a uma máquina real. Praticamente seus superiores não vai dar um orçamento ilimitado para comprar um número de dispositivos para teste de um worm ou exploração obscura. Portanto, é melhor para a concepção do Lab de Testes para ser o mais econômico possível, o uso de dispositivos e
capacidades existentes, tanto quanto possível e comprar algumas máquinas de maior capacidade e utilização de múltiplos sistemas operacionais neles, como em Virtualização.

1.2 Propósito
O objetivo deste documento é contribuir para um projeto de um teste próprio em laboratório, instalar os sistemas operacionais e dispositivos necessários, instalar os serviços necessários e começar a trabalhar neles. Desta forma, pode-se executar tarefas de risco, tais como implantação de novos softwares ou soluções, analisando worms da Internet e novas ameaças ou explorar um ensaio próprio ou de códigos e observar os resultados antes de utilizá-los em uma situação real (ambiente de produção). Isso mantém a rede de danificar os sistemas reais e, portanto, se alguma coisa der errado, pode começar a partir de primeiros princípios, sem qualquer repercussão.

1.3 Objetivo
O foco deste documento será sobre o processo de simulação de testes de penetração e os métodos de ataque / ferramentas / códigos a ser utilizado. O documento irá descrever todos os passos necessários, como instalar e configurar a rede e analisar os métodos pertinentes, ferramentas e códigos. Deverá ainda analisar o cenário do ponto de vista de ambos, do atacante e do administrador.

1.3.1 - 1a perspectiva
Como Assessor de Segurança / Tester em Penetração (ou Pentester) será necessiário um laboratório para gerar através de ferramentas, códigos e métodos de ataque. Em uma penetração real ou tentativa de ataque, não há lugar para erros, falhas e deve ser evitado na medida do possível. Por exemplo, um servidor detecta uma versão vulnerável em um servidor de prdoução e, em seguida, uma instala a mesma versão de um servidor de teste. Agora pode-se explorar as falhas no servidor de teste, sem comprometer o servidor de produção.

1.3.2 - 2a perspectiva
Um laboratório de testes é um sonho de todos administradores do sistema. Não terá que testar aplicativos em uma rede corporativa (ou de produção), com resultados desconhecidos. Numa rede corporativa (ou de produção) não se pode seguir um plano personalizado projetado em rede de testes e ver como ele funciona, sem estar preocupado com danos que essa curiosidade ou teste, podem causar. Além disso, não se deve esperar que a rede seja infectada por um worm para estudar o que ele faz e que tipo de dano que ele faz a um de sistemas, como por exemplo, tornar totalmente fora de controle. Em vez disso, tais perigos (worms, virus e outros) devem ser soltos em uma prisão do virtual, observando suas reações e analisá-la em todos os sentidos possíveis.

1.4 Requisito
Quase 80% dos equipamentos necessários para o Lab de Testes, depende dos requisitos de orçamento (verbal). O Lab de Testes pode ser um laboratório de 100% virtual, composto por dois ou três estações com diferentes sistemas operacionais, dentro de uma instalação do Vmware, VirtualBox ou outro Virtualizador, ou pode ser um laboratório de físico (até melhor em alguns aspectos), composto por três ou mais estações, mais um conjunto completo de tais dispositivos de iredes como roteadores, switches, hubs, ou mesmo um firewall em hardware. Todos esses dispositivos devem ser colocados em um rack dedicado ou algum outro local da mesma forma dedicada, ou seja, apenas para este uso e nada mais. Alternativamente pode-se construir um laboratório que é uma mistura de ambientes físicos e virtuais de rede e dispositivos. Esta é uma abordagem mais econômica e proporciona a mais simples e fácil de recuperar / reconstruir laboratório da maneira inicial, pronto para novos testes.

Independentemente do tipo de laboratório há alguns dispositivos e softwares que são essenciais para construir um laboratório de segurança mínima. Os requisitos são divididos em seções de hardware e software como istadas aqui. Os itens marcados com "*" são necessários para uma configuração mínima.

Leia também sobre a distribuição especial de Pentesting Backtrack http://www.backtrack.com.br

1.4.1Hardware
1 Cisco 2600 series Router with two Ethernet interfaces or any device act as Routersuch as a multi-
interface station.
1 Switch 16 ou 24 portas
1 Firewall or Firewall appliance
2 Hubs 10/100
4 workstations. Baseados em Intel (x86/i686)
2 Servidores Baseados em Intel (x86/i686) ou XEN
2 Laptop com Ethernet e 802.11 a/b/g interfaces

1.4.1 software
x “VMware Server” ou “VirtualBox”
x Instaladores dos Sistemas Operacionais que serão alvo, baseado na servidores em Produção
x MS Windows XP Professional + service-Pack 1 e 2
x Backtrack 4 Final
x MetaSploit Framework ultima versão

(continua parte 2)

Artigo Próprio por firebits
http://www.backtrack-linux.org/forum.../firebits.html

[firebits]

1.4.3Outros Dispositivos
Outros dispositivos são necessários nesta versão do projeto de teste de laboratório. Pode haver alguns dispositivos exclusivos que são necessárias, tais como DSL ou ISDN e equipamentos podem ser adicionados quando necessário.

1.5Design
Esta seção irá discutir formas comuns de concepção de um laboratório, com base nos recursos disponíveis e restrições orçamentárias. Uma pessoa pode ter laboratório de diferentes cenários de design, por exemplo, um plano econômico, um plano virtual, um plano físico ou um plano de perito. A primeira versão do projeto de testes de laboratório serão simples e econômica.

1.5.1Descrição
O Lab de Testes pode ser:

- Lab 100% fisicamente disponível.
- Um Lab Semi virtual, contendo alguns físicos e alguns hosts virtuais e dispositivos.
- Um laboratório 100% virtual, projetado sobre VMWare ou VirtualBox, sobre uma base forte de hardware.

Para economizar em semi-laboratório virtual a necessidade de análise e documentação do que será analisado. Este será composto por alguns hosts conetados a uma rede corporativa com a sua real DNS, DHCP e outros servidores. Esses servidores não serão alvos de um ataque e não serão utilizados para configurar e gerenciar as estações virtuais e simular uma rede completa.

1.5.1.1Designing do LAB (Virtual Lab / Cenario Econômico)

Custo do Hardware ~R$1700 (Desktop)
Custo do Software : ~U$160$(Vmware depende da versão ou grátis Vmware Server) +U$250(MS Win XP Pro)
+U$1200(MS Win 2K ou 2003 Srv.)
Total Estimado de Custo: U$1610 + R$1700 = **
**Os preços são muito dependia de uma escolha de hardware e software, neste país e outros países
. Esta é apenas uma estimativa. O autor declara que é o cliente irá obter licenças para tudo;)

Hardware: (minimo)
- Intel x86 based station
- Intel Pentium 4, 2800 MHz Processor
- 2 Gigs of RAM
- 40 Gigs HDD
- 2 Network Interfaces

Sistemas Operacionais:
- Microsoft Windows 2003 Server edition ou Microsoft Windows 2000 Server edition
- Microsoft Windows XP Professional Edition ou Vista
- Red Hat Linux 9.0, 80 ou outro Linux

Software:
- Backtrack 4 final http://www.backtrack.com.br
- VMware ou Virtualbox

Este cenário, que é também a mais econômica, irá utilizar um laboratório construído sobre as capacidades do Vmware ou Virtualbox. A estação HOST poderia executar ou sistemas operacionais Linux ou Windows, desde que tenha capacidade em recursos. As versões Windows e Linux do VMware ou Virtualbox são idênticos e a configuração em ambos os casos serão idênticos. A versão do Windows é recomendado para a simplicidade de sua interface de usuário.

O hardware utilizado para o host do sistema, em que o Vmware ou Virtualbox está instalado, deve ser poderoso o suficiente para manter todas as máquinas virtuais online ao mesmo tempo. Normalmente, cada Guest do Sistema Operacional precisa de pelo menos do valor ideal de cada fabricante (consulte o site do fabricante) + 30% de RAM para funcionar sem problemas, ou seja, se o ideal é 2GB, sem virtualizar o Guest, virtualizando seria num total de 2Gb+30% dos 2Gb. Portanto pode-se calcular a memória RAM exigida pela estimativa do
número de servidores necessários. Adicionando a quantidade de RAM necessária para os sistemas de GUEST para o montante necessário para o host do sistema irá decidir a quantidade de RAM que precisa ser instalado.

Os laboratórios descritos neste documento exigem um mínimo de 2 GB para funcionar sem problemas. Os requisitos de armazenamento pode ser calculado da mesma forma. É importante para minimizar o tamanho das instalações GUEST. Por exemplo, um padrão Red Hat 9.0 instalar, com pacotes desnecessárias como ambientes gráficos de trabalho, pacotes relacionados, ou mesmo ferramentas gráficas não utilizadas, vai exigir 4 GB, porém de forma otimizada exigirá 1,2 GB para instalação. Se um design de uma rede com 4 ou 5 sistemas de clientes, esta otimização irá resultar em uma economia de aproximadamente 15 GB no total.
As instalações do sistema operacional deve ser otimizada para a tarefa pretendida. Serviços não utilizados ou daemons não devem ser instalados. Por exemplo, se no teste não incluem a exploração do Apache, então não deve ser instalado nos sistemas GUEST.

O HOST máquina no laboratório está ligado, através de NIC 1, com a rede corporativa da empresa com um endereço IP estático que está reservado no servidor da rede corporativa de DHCP. NIC 2 da máquina host está reservada para sistemas operacionais convidados (GUEST). Essa interface é obtida no Vmware ou VirtualBox e sistemas operacionais convidados utilizar a interface praticamente ponte (brigde) para ligar a rede "diretamente".

1.5.2 Diagrama
Um diagrama de um laboratório de teste com base no cenário Virtual/Econômico deverá ser desenvolvido. Neste diagrama, apenas uma estação está reservada para a construção de todo o laboratório. O DHCP Real e servidores DNS pode ser ignorados e atribuição de IP pode ser configurado manualmente.

1.5.3Cenarios de Ataques
Vários cenários de ataque são dadas em Penetration Testing, na NSEC http://www.nsec.com.br, que é a empresa que suporta corporativamente o projeto open-source Backtrack no Brasil http://www.backtrack.com.br Use sua imaginação, explorar vários cenários e aprimorar suas competências neste domínio. Cenários de ataque devem ser classificadas com base em vários sistemas operacionais, serviços e outros.

1.6 Lab de Segurança
Devido à natureza das atividades realizadas em um teste de laboratório é muito importante para proteger outras partes das redes para que eles não podem ser danificadas por acidente, mediante a testes. O nível de segurança aplicado a um teste de laboratório depende da organização. As melhores práticas ditam uma concepção de laboratório que totalmente isolados, por qualquer meio, do Lab de testes do resto da rede corporativa (produção).

Pode ser necessário preparar um link de internet para um laboratório, em situações que a definição de um firewall controlado / ou com regras severas e onde as ACLs são fundamentais e tudo deve ser planejado com cuidado. Com um design nada cuidadosamente planejado de rede pode escapar do teste da rede de laboratório para a rede de produção, ou vice-versa, ai teremos grandes problemas e muito stress.

1.6.1 Segurança Física do Lab
Ao Desenvolver um Lab de Ataques, deve-se garantir que as máquinas, equipamentos e localização não deve ser confundida com a rede em tempo real e produção da organização. Medidas de segurança física pode incluir uma localização específica, dedicada, cabos e identificações em etiquetas, garantem as diferenças.

Local: O Lab de Ataques dos principais sistemas devem ser colocados em uma sala separada com chave / rack, longe de todos os outros sistemas e equipamentos de rede corporativa.

Cabeamento: Qualquer máquina ou dispositivo relacionado ao Lab de Ataque deve ser cabeado com cabos de coloração única. As identificações utilizadas deve ter uma cor brilhante e única, como a laranja ou magenta.

Isso vai ajudar a distinguir facilmente equipamentos de ataque dos laboratórios de outros equipamentos de rede corporativa (produção) localizado na mesma área. Isso impede os usuários de acidentalmente se ligar à rede Lab de Ataque.

Identificação: Qualquer máquina ou dispositivo relacionado ao Lab de Ataques deve ser claramente marcado com as etiquetas devem ser coloridas e colocados em um local óbvio, permitindo que qualquer peça de equipamento de laboratório de ataque seja facilmente identificadas. Cada etiqueta deve indicar algo semelhante a seguinte descrição:

"Este sistema é restrito a: uso autorizado Lab de Ataque, sem nenhum outro fim" ou em inglês "This system is restricted to:Authorized Use of Attack Lab “

(continua parte 3)

Traduzido e Adaptado por firebits
http://www.backtrack-linux.org/forum.../firebits.html

[firebits]

Os usuários devem ser informados antecipadamente sobre o laboratório de ataque antes de serem autorizados a utilizar este sistema. Alterar o Manual de cabos de rede, hubs e dispositivos é ESTRITAMENTE PROIBIDA.

Regras gerais de segurança física devem ser seguidas. Etiquetas sobre os dispositivos não deve conter informações específicas sobre o uso da máquina como:

"Este sistema é restrito a: Autorizado Apenas para uso de Lab de Ataque Win2k-ADS (172.16.1.1)" ou em inglês "This system is restricted to:Authorized Use Only of Attack Lab Win2k-ADS (172.16.1.1) “

1.6.1.1Controle de Acesso de Logico
A política do laboratório de Ataques deve impedir que usuários não autorizados e redes de acessar os recursos Lab de Ataque, qual nós chamamos de controle de acesso lógico . Esta política de acesso deve incluir itens como os mecanismos de autenticação, como usuário privilegiado Alto acesso (root / administrador de segurança de senha), o compartilhamento de arquivos (NFS / SMB) administração, distribuição, etc

Não se deve usar contas de rede corporativa (produção) para autenticar os usuários sobre a rede de ataques do laboratório. O servidor dedicado da contabilidade, rh e diretoria, geralmente é a tentativa preferida para quem usa o Lab de Ataque com más intensões, então CUIDADO.

O Root / Administrador de senha de segurança das máquinas de laboratório de ataques, devem limitar o número de pessoas que conhecem a senha para alguns usuários essencial.

Os usuários, que tem acesso padrão não devem ter acesso de alto nível para o Lab de Ataques. O uso de senhas fortes para máquinas de principais também deve ser forçado. Uma senha forte exige pelo menos 8 caracteres e inclui tanto caracteres numéricos e caracteres especiais. Devido à natureza do algoritmo Windows para usar e criptografar suas senhas, usando uma senha forte com mais de 12 caracteres recomendados. Os arquivos devem ser compartilhados entre a equipe pelo uso de ACLs e acesso a NFS e SMB partes destes compartimentos devem ser limitada Laboratório de Ataques e seus usuario testadores. Conexões de Internet e redes corporativas (produção) não devem ser permitidas.

Administração Distribuída - controle administrativo das máquinas de principais devem pertencer a um grupo seleto de pessoas e um grupo completamente separado e administrativo, deve ser dado o controle administrativo sobre o firewall Lab do Ataque.

Embora ambos os grupos devem trabalhar juntos para manter a segurança global da Lab de Ataque, nem o grupo deve ter acesso root ao nível de outras máquinas, de modo que nenhum grupo possa desativar todos os mecanismos de segurança.

1.7Apêndice
Aqui estão algumas notas podem ser úteis durante a utilização de um laboratório projetado de Ataques e Testes em uma maquina virtual com VMware ou VirtualBox.

Notas Configurações dos Virtualizadores:

Pare o serviço DHCP da Vmware ou VirtualBox se alguém está usando uma estação de trabalho conectada a uma rede corporativa. Não fazer isso irá causar um DOS em silêncio sobre novos sistemas no domínio. Isso acontece porque o VMWare irá ceder seus escopos padrão IP inválidos às emissões de pedido DHCP.

Desabilite/remova as duas (virtuais) interfaces extras que VMware ou VirtualBox adiciona para ligação direta e capacidades de NAT. O VMware/VirtualBox NAT serviço também deve ser interrompido.

O Vmware/VirtualBox pode usar suas interfaces brigde (ponte) como um HUB. Isto significa que o Host e Guest sistemas estão conectados a um HUB. Sabendo disso podes parar um bridge antes que cometa erros durante a captura de dados.

Alterar os endereços MAC das interfaces virtuais da VMware/VirtualBox no laboratório está ligado a uma rede corporativa e no IDS executando no mesmo, evitando clonagem e autorização devida, como se fosse um usuário autêntico de testes.

Um GUEST com sistema otimizado é altamente recomendável. Dispositivos não utilizados devem ser retiradas de máquinas virtuais que são criados. Remover o cabo USB e Som Drivers é um bom lugar para começar.

GUIs não deve ser utilizado nos GUEST dos sistemas operacionais, se possível. Em sistemas Windows usar uma configuração mínima. Isto irá melhorar o desempenho do laboratório.
Os Snapshots (instantâneo) dos sistemas clientes vão permitir a recuperação rápida se o sistema falhar.

Artigo Próprio por firebits
http://www.backtrack-linux.org/forum.../firebits.html