Criando um cluster de alta performance para quebrar senhas

Este artigo mostra como criar um cluster de alta performance, utilizando Debian Squeeze com 3 máquinas para quebra de senhas utilizando o John the Ripper, com cada nó (servidor) do cluster executando de maneira síncrona o mesmo algoritmo para quebra de senhas.

[ Hits: 62.127 ]

Por: Tarcisio Gambin em 10/08/2012


Configuração do servidor master



Para este modelo de cluster, será necessário um nó que seja o 'Master', ou seja, responsável por todas as atividades em execução nos demais nós do cluster.

Configuração

Nesta etapa, serão feitas as configurações do sistema, tais como atualização, instalação e configuração dos pacotes básicos.

Também serão configurados usuários responsáveis pela execução dos serviços do cluster e também a preparação do ambiente.

É válido lembrar que, o servidor responsável por iniciar os serviços cluster é o host (nó) principal (master), e todos os demais serão os hosts (nós) secundários (slaves).

Configuração do servidor master

Esta configuração será feita com a instalação dos pacotes/ serviços: NFS, SSH, MPICH2 e John the Ripper, que serão utilizados por todo o cluster através da rede.

Configuração do repositório

Acesse o terminal, como root, e edite o seguinte arquivo para configuração de repositórios:

# vi /etc/apt/sources.list

Configure conforme as informações abaixo:

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main
deb http://ftp.br.debian.org/debian/ squeeze-updates main
deb-src http://ftp.br.debian.org/debian/ squeeze-updates main
deb http://ftp.br.debian.org/debian squeeze main


Em seguida, atualize repositório e os pacotes do sistema, através dos seguintes comandos:

# apt-get update
# apt-get upgrade all


Configuração de Rede

Acesse o terminal como root

Edite o seguinte arquivo, para configuração de endereços de rede:

# vi /etc/network/interfaces

Configure conforme as informações abaixo:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 10.1.1.1
netmask 255.255.255.0


Inicie a segunda interface de rede através do seguinte comando:

# ifup eth1

Agora, iremos desabilitar o IPv6 em nosso servidor para garantir uma melhor compatibilidade com os serviços utilizados.

Também serão configurados os IPs dos servidores utilizados no cluster, uma vez que não será utilizada a resolução de nomes DNS.

Portanto, edite o seguinte arquivo para desabilitar o uso local do IPv6 e configurar os IPs dos servidores do cluster:

# vi /etc/hosts/

Configure conforme as informações abaixo:

127.0.0.1 localhost
10.1.1.1 deb01 # master
10.1.1.2 deb02 # slave
10.1.1.3 deb03 # slave


Agora será necessário desabilitar o IPv6 na inicialização do sistema, portanto será necessário editar o seguinte arquivo:

# vi /etc/sysctl.conf

Basta adicionar a seguinte linha, no final do arquivo:

net.ipv6.conf.all.disable_ipv6 = 1


Agora, iremos desativar o IPv6 utilizado pelo Exim, para evitar que o serviço comece a gravar mensagens de erro nos logs do sistema, pois o IPv6 está desativado.

Pare reconfigurar o Exim, basta executar o seguinte comando:

# dpkg-reconfigure exim4-config

Será exibida a tela de configuração do serviço. Basta configurá-lo conforme o seguinte procedimento:
  1. Clique em Ok para prosseguir;
  2. Selecione Sem configuração no momento e clique em Ok para prosseguir;
  3. Clique em Sim para deixar o sistema de mensagens não configurado;
  4. Clique em Não para não dividir os arquivos de configuração;
  5. Reinicie o servidor para que todas as alterações tenham efeito.

Configuração de usuários e permissões

Para utilização do cluster com MPICH2, é necessário que todos os usuários tenham o mesmo UID e GUID em todas as estações utilizadas, uma vez que não estamos utilizando nenhum serviço de diretório.

Para isso, iremos configurar um usuário e grupo para utilização deste serviço.

Crie o usuário através do seguinte comando:

# groupadd -–gid 1100 mpigroup
# adduser –-home /cluster -–uid 1100 -–gid 1100 mpiuser --disabled-password --quiet


Apenas confirme todas as informações sobre o usuário.

Configuração do servidor NFS

O servidor NFS será utilizado para compartilhar todos os arquivos (binários, bibliotecas e senhas) utilizados durante a utilização do cluster.

Para isso, entre no terminal como root. Digite o seguinte comando para a instalação do serviço NFS

# apt-get install nfs-kernel-server

Após a instalação, será necessário compartilhar o diretório /cluster que será acessado por todos os servidores do cluster.

Como o foco deste artigo é um ambiente de cluster de alta performance, não serão aplicadas técnicas de hardening. Portanto o compartilhamento estará acessível por todos os computadores da rede.

Faça o compartilhamento através do seguinte comando:

# echo '/cluster *(rw,sync,no_subtree_check)' >> /etc/exports

Reinicie o serviço do NFS através do seguinte comando:

# invoke-rc.d nfs-kernel-server restart

Instalação do SSH e libssl-dev

O SSH será utilizado para comunicação entre o servidor master e os servidores slaves, e a biblioteca "libssl-dev" será responsável pela implementação do suporte ao MD5.

Para instalar o SSH e a biblioteca "libssl-dev", acesse o terminal como root.

Digite o seguinte comando para iniciar a instalação:

# apt-get install openssh-server libssl-dev

Agora, será necessário entrar com o usuário "mpiuser" (que irá executar o serviço de cluster), para a configuração do SSH afim de realizar a conexão através das chaves que serão criadas.

Acesse com o usuário mpiuser através do seguinte comando:

# su - mpiuser

Execute os seguintes comandos para gerar as chaves:

ssh-keygen –t dsa

Pressione ENTER 3 vezes, para gerar uma chave em branco.

Agora, digite os seguintes comandos para prosseguirmos com a configuração das chaves:

cd ~/.ssh
$ cat id_dsa.pub >> authorized_keys


Como todos os servidores irão montar o /cluster como diretório home do usuário "mpiuser", não será necessário configurá-las novamente.

Instalação e configuração do MPICH2

O MPICH será instalado através da compilação manual, para que possamos, desta forma, utilizar a versão estável mais atualizada e também para que o diretório destino dos binários e bibliotecas, seja acessível para todos os servidores do cluster, através da montagem do /cluster.

Para isso, acesse o terminal como root.

Será necessário instalar os compiladores necessários através do seguinte comando:

# apt-get install build-essential gfortran

Após a instalação, acesse o terminal como mpiuser através do seguinte comando:

# su - mpiuser

Acesse o /cluster e crie os diretórios "src" e "mpich" através do seguinte comando:

mkdir mpich2 src

Acesse o /src e faça o download da última versão estável do MPICH2 (1.4.1p1), através do seguinte comando:

wget http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.4.1p1/mpich2-1.4.1p1.tar.gz

Após o download, descompacte o seguinte arquivo:

tar -zxf mpich2-1.4.1p1.tar.gz

Após a descompactação, acesse o diretório: mpich2-1.4.1p1

Agora, será necessário configurar o MPICH2 através do seguinte comando:

./configure -prefix=/cluster/mpich2 --with-pm=hydra

Concluindo este procedimento, configuramos o MPICH2 para ser instalado em /cluster/mpich2, e juntamente com o Hydra, que fará o gerenciamento dos processos nos servidores do cluster.

Execute a instalação através dos seguintes comandos:

make
$ make install


Após a instalação, será necessário adicionar os binários e bibliotecas através da edição do seguinte arquivo:

vi ~/.bashrc

Insira as seguintes linhas, no final do arquivo:

export PATH=/cluster/mpich2/bin:$PATH
LD_LIBRARY_PATH=/cluster/mpich2/lib:$LD_LIBRARY_PATH


Recarregue as novas variáveis no bash, através do seguinte comando:

source ~/.bashrc

Execute os seguintes comandos, para verificar se as variáveis foram carregadas com sucesso no bash:

which mpiexec

Se forem exibidos os paths dos binários e bibliotecas, significa que eles já estão disponíveis no PATH do bash sem a necessidade de digitar o caminho completo durante sua próxima execução.

Agora, será necessário configurar o arquivo hosts, que será responsável por identificar ao Hydra os servidores que fazem parte do cluster.

Crie o arquivo através do seguinte comando:

vi /cluster/hosts

Adiciones as seguintes linhas no arquivo:

deb01
deb02
deb03


Estas linhas representam, respectivamente, o servidor master e os servidores slaves do cluster.

Instalação e configuração do John the Ripper

O John the Ripper será instalado através dos últimos pacotes estáveis disponíveis no site oficial, para que seja compilado de maneira otimizada e esteja acessível a todos os usuários através do /cluster.

Para isso, acesse o terminal como mpiuser:

# su - mpiuser

Acesse o /cluster. Faça o download do código fonte do John the Ripper, através do seguinte comando:

wget http://www.openwall.com/john/g/john-1.7.9.tar.gz

Após o download, descompacte os arquivos através do seguinte comando:

tar -zxf john-1.7.9.tar.gz

Acesse agora a pasta com o conteúdo dos arquivos através do seguinte comando:

cd john-1.7.9/src

Agora, basta compilar através do seguinte comando:

make linux-x86-any

Este comando compila o John the Ripper otimizado para uma arquitetura 32 bits comum.

Para outros tipos de arquitetura, basta compilá-lo utilizada qualquer uma das arquiteturas listadas através do seguinte comando:

make clean

* Importante: como ele será executado em um dos nós do cluster por hardwares diferentes, é importante que ele seja compilado em uma arquitetura compatível com todos os nós. Neste caso, o linux-x86-any garante essa compatibilidade com as máquinas virtuais utilizadas neste artigo.

Certifique-se que o John the Ripper está funcionando normalmente através dos seguintes comandos:

cd /cluster/john-1.7.9/run
$ ./john -test


Será exibida uma tela com os resultados dos testes de performance de todos os algoritmos utilizados.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Configuração do servidor master
   3. Configuração dos servidores slaves
   4. Quebrando senhas
Outros artigos deste autor

Como configurar um IPTABLES simples e seguro no Slackware!

AnyRemote - o poder em suas mãos!

Leitura recomendada

Integração de servidores Linux com Active Directory

O que é ForceCommand

Segurança SSH com DenyHosts

Protegendo seu Linux de ataques de brute force via ssh

Gerenciando logs do Linux pela WEB com o PHPSYSLOG-NG (parte 1)

  
Comentários
[1] Comentário enviado por asdf2 em 10/08/2012 - 13:11h

muito bem feito, valeu

[2] Comentário enviado por levi linux em 10/08/2012 - 13:16h

Excelente artigo, muito bem escrito e bastante detalhado! Favoritado!

[3] Comentário enviado por cleysinhonv em 10/08/2012 - 17:18h

Olá é um ótimo artigo. Gostaria de saber se você focou especificamente para quebrar senhas ou esse cluster pode ser usado para outras aplicações. Se sim como fazer gerenciamento de filas, "checkpoint" de processos e transferência de jobs. Parabéns pelo artigo.

[4] Comentário enviado por gambin.br em 10/08/2012 - 17:59h

@asdf2 e @levi linux - muito obrigado :D

@cleysinhonv - com certeza!! No momento de execução do comando "mpiexec -n 3 -f hosts ./john" poderia executar qualquer outro processo, desde que o PATH esteja configurado adequadamente!!

Em relação ao gerenciamento de filas, transferência de jobs, não posso afirmar com certeza pois não cheguei implementar diferentes aplicações utilizando este cluster, no entanto acredito que possa implementar através de um job que seja executado pelo próprio mpiexec!

[5] Comentário enviado por fernandoborges em 10/08/2012 - 19:06h

Muito bem escrito e detalhado. Uma excelente fonte de pesquisa! Parabéns.

[6] Comentário enviado por danielsath em 11/08/2012 - 09:07h

Parabéns, uma ótima ideia para quem trabalha com uma grande quantidade de dados. Favorito.

[7] Comentário enviado por emccomputadores em 12/08/2012 - 11:24h

O aws da amazon tem sido bastante utilizado para isso, um ótimo artigo, parabéns.

[8] Comentário enviado por c4rl em 13/08/2012 - 21:58h

Cara muito bom o artigo! Bem explicado e direto ao ponto, sem 'xurumelas'.

O mpich2, como o próprio nome sugere, utiliza a biblioteca MPI (Message Passing Interface), muito conhecida e utilizada por cientistas que necessitam paralelizar a execução de algoritmos complexos e, como bem disse gambin.br, o cluster também pode ser utilizado para execução de outros algoritmos, testes de desempenho podem ser realizados com o mpptest que pode ser encontrado aqui: http://www.mcs.anl.gov/research/projects/mpi/mpptest

Abs

[9] Comentário enviado por gambin.br em 13/08/2012 - 22:19h

Obrigado pelos complementos @c4rl =]

[10] Comentário enviado por edmilsonjnior em 15/08/2012 - 18:26h

Ótimo artigo, bem detalhado e direto.
Reproduzindo o cenário e efetuando testes agora mesmo :)

[11] Comentário enviado por edmilsonjnior em 16/08/2012 - 12:10h

Olá galera :)

Reproduzi o cenário proposto, com 3 máquinas virtuais rodando Debian, os testes que fiz me deixaram curioso.
Para eles, utilizei o John para quebrar senhas de usuários e depois o Pyrit para quebrar senhas de redes sem fio, ambos utilizando wordlists.
Para fazer um comparativo eu rodei isoladamente os programas apenas no master e salvei os resultados, depois fiz o mesmo só que utilizando as 3 máquinas virtuais como um cluster, primeiro o John, depois o Pyrit.
Durante a execução eu rodei o top nas 3 e pude ver que os processos estavam rodando realmente nos 3 nós.
O resultado foi o seguinte:
Teste 1
Apenas um servidor, 10.000 possibilidades com o John, 13 minutos de teste.
Depois, utilizando todo o cluster, cheguei aos mesmos 13 minutos de teste.
Teste 2
Apenas um servidor, 100.000 possibilidades com o pyrit, 3 minutos e 21 segundos de teste.
Depois, utilizando todo o cluster, cheguei ao mesmo resultado em 5 minutos de teste.

Intencionalmente as wordlists não tinham a senha correta, assim, após testar todas as possibilidades da lista o programa fecha, dessa forma eu pude usando o comando time, obter o tempo de execução.
Me estranha o fato de o cluster ter sido mais lento que apenas uma das máquinas virtuais rodando, notei que a saída do programa ao fim da execução é repetida, no caso, com 3 máquinas, no nó master eram exibidas as saídas dos 3 processos criados, não posso garantir, mas fiquei assim com a impressão de que os 3 estavam fazendo todo o trabalho ao invés de dividi-lo.

Mais alguém fez testes? Que resultados obtiveram, foram iguais aos meus?
Ainda não pude criar o cluster um máquinas reais, caso alguém tenha feito, estou curioso para saber se o resultado foi diferente.

Gambin.br, ótimo artigo, continue publicando-os para nós ^^
Vejo que ainda tenho muito a estudar. :)

[12] Comentário enviado por stremer em 16/08/2012 - 14:53h

edmilsonjnior.
Em máquinas virtuais realmente é mais lento... além do processamento... tem todo o trabalho de gerenciar os SOs das VMs... como no final seu poder de processamento não aumenta (pois ele depende da maquina real), fazer 3 VMs consome muito mais do que uma unica...

Cluster em máquina virtual somente para testes....
Ou no caso de varias maquinas host com uma VM cada um delas participando do cluster (nesse caso para não precisar instalar o filho como SO principal)...

[13] Comentário enviado por gambin.br em 16/08/2012 - 23:13h

@edmilsonjnior

Muito obrigado pelo contato! Fico feliz que tenha se empenhado em estudar o artigo e inclusive analisar possíveis falhas! Espero que tenha ajudado em alguma coisa ;p
Pretendo novamente montar o ambiente com máquinas físicas e validar os testes que você realizou.
Obs: você não é o único que tem muito a estudar ;p


@stremer

Obrigado pela contribuição! Também acredito que o problema citado pelo @edmilsonjnior esteja relacionado diretamente com o fato de serem utilizadas máquinas virtuais. Precisava deixar mais claro esta restrição no artigo..


E obrigado a todos que estão testando também, afinal comunidade e software livre de verdade é isso aí - todos colaborando para o bem comum :D


Obs: esse artigo não escrito só por mim - teve um punhado de gente boa envolvida nisso (créditos no meu blog pessoal):

http://tarcisiogambin.net/blog/criando-um-cluster-de-alta-performance-para-quebrar-senhas/

[14] Comentário enviado por fbrabreu em 17/08/2012 - 09:15h

PARABÉNS...depois de ler o artigo deu vontade de colocar em prática.

[15] Comentário enviado por samuca32 em 22/08/2012 - 12:58h

ola gente caso queiram painel tenho plesk free ilimitado versao 9.0;9.5 em portugues,ipsomega,zpanel msn olhar4@msn.com

[16] Comentário enviado por ilopes em 15/08/2013 - 19:08h

pretendo baser meu tcc neste artigo, principalmente as configuraçaoes, claro que tudo citado, gostaria de ter algumas sugestoes de outra aplicabilidade dele principalmente para algo que exiga muito desempenho e se precisaria mexer muito na configuraçao

[17] Comentário enviado por thyago162 em 29/03/2014 - 11:51h

Ola, eu tenho uma duvida, eu segui passo a passo deste artigo e no final acontece o seguinte, em vez do processo ser distribuido para todos os nós, ele está indo apenas para um... já verifiquei a comunicação entre eles, comunicação remota e tudo mais, gostaria que se alguem tiver alguma ideia, por favor.

[18] Comentário enviado por cypersan em 04/06/2014 - 15:23h

Mas pelo que vi, tem que modificar o Makefile para ter suporte paralelo, e isso você não fez, ou só esqueceu de colocar no artigo ?

[19] Comentário enviado por Gabrielscps em 01/01/2016 - 12:56h

Parabéns pelo artigo, bem explicado!! Só um detalhe que aqui comigo deu problema foi na montagem da pasta no slave, porque faltava o pacote nfs-common nos slaves. Vlw

[20] Comentário enviado por lu_kinhas13 em 19/09/2018 - 14:26h


[19] Comentário enviado por Gabrielscps em 01/01/2016 - 12:56h

Parabéns pelo artigo, bem explicado!! Só um detalhe que aqui comigo deu problema foi na montagem da pasta no slave, porque faltava o pacote nfs-common nos slaves. Vlw


Estou usando este artigo para um trabalho da faculdade, fiz tudo certo, como você resolveu seu problema? só instalou os nfs-cammon nos slaves ?


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts