quarta-feira, 18 de maio de 2016

LDAP: Teste de Performance com JMETER

O LDAP é um protocolo de acesso a Diretórios, que por sua vez é uma organização de dados em árvore com objetivo de responder rapidamente uma consulta.
Muitos sistemas trabalham com Diretório e disponibilizam interface LDAP: Windows com Active Directory, OpenLDAP, etc.
Um Serviço de Diretório é utilizado por todos os outros serviços da rede, por exemplo: para verificar a autenticação. Portanto, é natural questionar se um determinado servidor LDAP irá suportar a carga.
A ferramenta utilizada para checar a performance do serviço será o JMETER. No link mostra como instalar.

O servidor testado foi Ubuntu Linux, virtualizado (1GB RAM e 2 CPUs), com OpenLDAP 2.4.44. Mas, o mesmo teste poderia ser executado em um servidor Windows com AD ou outro servidor de Diretório.

Plano de teste

O plano de teste foi desenvolvido para simular 500 usuários acessando o Diretório ao mesmo tempo. Cada usuário realizará 25 requisições de pesquisa (SEARCH) no servidor LDAP, ou seja totalizando 12.500 requisições. A figura abaixo mostra a configuração do plano de teste:

LDAP: Simulando 500 usuário simultaneamente.
Configuração de pesquisa LDAP.
Cada requisição irá representar um SEARCH com o filtro (uid=fulano1) na base LDAP.

Resultado

O Servidor LDAP começou falhar na requisição de número 954:

Depois, entrou em colapso e não respondeu mais nada depois da requisição de número 1150:

Trinta minutos depois o teste ainda não tinha sido concluído, veja o resultado sumarizado:
Teste final parcial
Fiquei curioso para saber o que havia ocorrido com o servidor LDAP, então visualizei os logs:

May 14 20:47:39 ldapsrv slapd[1150]: warning: cannot open /etc/hosts.allow: Too many open files
May 14 20:47:39 ldapsrv slapd[1150]: daemon: accept(8) failed errno=24 (Too many open files)
May 14 20:47:39 ldapsrv slapd[1150]: warning: cannot open /etc/hosts.deny: Too many open files
May 14 20:47:39 ldapsrv slapd[1150]: fd=1023 DENIED from unknown (192.168.0.102)

...

Segundo o Log acima, é possível concluir que uma das limitações foi a configuração do número máximo que um arquivo pode ser aberto por processo, no Sistema Operacional, isto limitou o servidor LDAP. O sistema operacional do servidor estava limitado a abrir apenas 1024 vezes um arquivo.

Obs.:  O arquivo /etc/hosts.deny é utilizado para checar se uma máquina(IP) pode ou não utilizar determinado serviço, análogo a um firewall. O arquivo é lido a cada nova solicitação de conexão.

Após o OpenLDAP ser reiniciado no servidor, o teste concluiu rapidamente. Segue resultado final:
Teste final.

Considerando a limitação de abertura de arquivos do servidor, foi proposto um novo plano de teste mais simples, apenas 200 usuários com 10 requisições cada. Veja abaixo o gráfico da latência (tempo de resposta) das requisições conforme o tempo de execução do teste: 

Gráfico Latência Requisições LDAP.
O OpenLDAP fez seu papel, manteve o tempo de resposta constante após o inicio das conexões.

Conclusão

O primeiro ponto a destacar é que o TUNNING do Sistema Operacional do Servidor é importantíssimo para o desempenho da Aplicação. No plano de teste executado, o OpenLDAP teve seu desempenho comprometido pelas limitações do Sistema Operacional Linux.
Segundo ponto, o JMETER é uma ferramenta sensacional para testes de performance de servidores: Em 15 minutos é possível desenvolver e executar um plano de teste no Serviço de Diretório LDAP.

segunda-feira, 16 de maio de 2016

JMETER Apache – Teste de Carga em Servidores Web

JMETER é uma ferramenta utilizada para realizar teste de carga em servidores, ele é grátis e 100% desenvolvido em Java.
Teste em servidores WEB é a funcionalidade mais conhecida, mas testes em outros servidores/protocolos também são possíveis, segue lista completa:
  • Web - HTTP, HTTPS
  • SOAP
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail - SMTP(S), POP3(S) e IMAP(S)
  • MongoDB (NoSQL)
  • Comandos de Shell Scripts
  • TCP
O teste pode ser realizado em paralelo, com o uso de “threads”. Seria como uma simulação de acessos simultâneos.
A interface gráfica auxilia no desenvolvimento do plano de teste e na analise dos resultados.

Requisitos mínimos para executar o JMeter

  • Interpretador Java: Compatível com Java 6 ou maior.
  • Arquivos jars Opcionais: Muitos jars não estão inclusos no JMeter. Se necessário, fazer o download e salvar no diretório de bibliotecas (lib).

Download e Execução

O JMeter está disponível em http://jmeter.apache.org/download_jmeter.cgi.
Basta fazer o download e descompactar. Será criado uma árvore de diretórios e o arquivo principal está no diretório “BIN”.
  • Execução no Windows: jmeter.bat
  • Execução no *unix: jmeter
Tela Inicial do JMETER

Plano de Teste

Qualquer teste no JMETER precisa de um plano de teste. Para melhor entendimento vou executar um plano de teste de carga em um servidor WEB. Siga os passos...

Passo 01: Definição dos Grupos

Clique no Plano de Teste com o Botão Direito do Mouse, conforme mostrado abaixo:

JMETER: Adicionando Grupo de Usuários


Configuração de threads (usuários e requisições)


O campo "Número de Usuários Virtuais (threads)" representa a quantidade de usuários que irão acessar o servidor web ao mesmo tempo, no caso 100. Cada usuário fará 10 requisições, representado no campo "Contador de Iteração".

Passo 02: Testador HTTP (WEB)

Clique em "Grupo de Usuários" com o botão direito do Mouse, selecione Adicionar, Testador, Requisição HTTP. Conforme mostrado abaixo:
JMETER: Testador HTTP

Passo 03: Configurando servidor HTTP alvo

Configurar o IP do servidor, no caso 192.168.0.103, e a porta, 80. Conforme mostrado abaixo:
Configurando IP e Porta do servidor HTTP alvo

Passo 04: Adicionando Ouvinte

Afim de facilitar a visualização do resultado do teste, é necessário adicionar alguns ouvintes. Clique com o botão direito do mouse em "Grupo de Usuários" e selecione Adicionar, Ouvinte, Relatório Agregado, conforme mostrado abaixo:
JMETER: Relatório Agregado
Faça o mesmo para Relatório de Sumário, conforme mostrado abaixo:
JMETER: Relatório de Sumário
O plano de teste está definido, agora vamos executar, siga o passo 05.

Passo 05: Iniciando o Teste


Clicar no ícone PLAY (SETA VERDE) para iniciar o teste:
Iniciar o teste no JMETER
Após alguns segundos o teste irá terminar. Será que o servidor web suportou a carga?

Passo 06: Visualizando o resultado do teste

Através dos Ouvintes adicionados no passo 04, podemos observar o resultado do teste:
JMETER: Resultado do teste de carga no Servidor Web





O resultado mostrou que o servidor foi capaz de suportar o teste de 100 usuários, fazendo 10 requisições cada, ao mesmo tempo. Ou seja 1000 requisições.
O servidor Web testado foi o Ubuntu Linux virtualizado com: 1 GB RAM e 3 CPUs. 


Obs.: O servidor não suportou a mesma carga com 1000 usuários, ou seja 10.000 requisições. Cerca de 13% das requisições não foram atendidas.

Conclusão

O JMETER é uma ferramenta poderosa em teste de carga e muito simples de utilizar. Futuramente pretendo testar os outros Testadores da ferramenta: LDAP, SOAP, FTP e MAIL.Há outros relatórios (ouvintes) mais detalhados na ferramenta, que não foram demonstrados aqui. A inserção destes segue o mesmo procedimento dado no passo 04 (Adicionando Ouvinte) deste artigo.

quarta-feira, 11 de maio de 2016

FreeBSD: ISO Padrão ou preparado para Virtualização (Virtual Machine image)

O FreeBSD é um sistema operacional baseado no UNIX, é um "concorrente" do Linux.
Este sistema operacional é conhecido por sua Estabilidade, Robustez, Velocidade e Segurança, se comparado com outros sistemas operacionais (em ambiente não virtualizado). Mas, hoje é raro ambiente que não seja virtualizado.

Quando virtualizado, o FreeBSD perde muita performance, se comparado com o Linux. Então, os desenvolvedores resolveram criar uma imagem personalizada para virtualização, ela é chamada de "FreeBSD Virtual Machine Image".

O objetivo deste post é comparar o desempenho do FreeBSD padrão com o preparado para virtualização em um ambiente Virtualizado. Será que tem vantagens ou é apenas frescura?

1. Host (máquina física) utilizado no teste

A máquina utilizada para realizar os testes possui as seguintes características:
Memória RAM: 8 GB
Processador: Intel i5
Disco: 1TB SATA2

É um desktop convencional. Nada de mais!

2. Imagens

O FreeBSD pode ser baixado AQUI. As máquinas virtuais dos testes possuem as seguintes características:
Memória RAM: 1 GB
Processador: 4 CPUs


São dois tipos de imagem:

2.1. Virtual Machine Image

A versão preparada para virtualização só está disponível para as arquiteturas: i386 e AMD64.
Está disponível para vários tipos de hypervisors e formatos de arquivos:
vhd: VirtualPC, Hyper-V, Xen, VirtualBox
vmdk: VMWare
qcow2: Qemu, KVM, VirtualBox
raw: bhyve, ou outro hypervisors com suporte ao formato "raw disk image".

No caso do teste, foi selecionado o "FreeBSD-10.3-RELEASE-i386.vhd.xz". Basta descompactar e criar uma nova máquina virtual no VirtualBox, e selecionar o arquivo baixado com o disco da VM, conforme mostrado abaixo:
VirtualBox: FreeBSD Virtual Machine image
A máquina virtual já vem instalada, mas está zerada. É necessários executar alguns comandos:

Ativar IP na máquina:
# dhclint em0

Baixar os pacotes para instalação de outros softwares:
# portsnap fetch
# portsnap extract

Instalar as ferramentas de teste:
# cd /usr/ports/security/john
# make install
# cd /usr/ports/benchmark/iperf
# make install

2.2. Imagem padrão do FreeBSD

Este é o tipo mais comum de se instalar o FreeBSD. É tão simples que não entrarei em detalhes. Também é necessário instalar as ferramentas de teste, conforme mostrado no item anterior.

3. Teste de performance

O Teste consiste em testar a velocidade de Gravação em disco, Processamento com openssl (criptografia) e rede com Iperf.

3.1. Teste de Gravação em disco

O comando "dd" foi utilizado para testar a performance de gravação do disco. O comando utilizado para gerar um arquivo de 5GB:

# dd if=/dev/zero of=dados.dat bs=10000000 count=512

FreeBSD preparado para Virtualização. Teste gravação em disco.
FreeBSD padrão. Teste de gravação em disco.
O teste foi realizado três vezes seguidas, e o resultado foi a média dos valores.
Resultado final de gravação:


Gravação em Disco com o DD FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 47,3 MB/s 51,3 MB/s
Tentativa 02 48,5 MB/s 51,2 MB/s
Tentativa 03 49,8 MB/s 50,8 MB/s
Média Final 48,5 MB/s 51,1 MB/s

Diferente do resultado esperado, a VM com FreeBSD padrão teve performance de gravação 5% superior a VM com FreeBSD preparada para virtualização.

Obs.: No host, máquina utilizada para virtualizar as MV acima, o mesmo comando fez a gravação em 110MB/s.

3.2. Teste Processamento com openssl - rsa 4096

Para testar o processamento das máquinas virtuais foi utilizado a ferramenta "openssl". O teste consiste em identificar a quantidade de verificação RSA de 4096 bits as MVs fazem por segundo. Isto é criptografia pura e usa muito CPU. Comando executado:
# openssl speed rsa4096

FreeBSD preparada para Virtualização. Teste de processamento com openssl.
FreeBSD padrão. Teste de processamento com openssl.

Resultado final do teste de processamento:


Processamento com o openssl – RSA 4096 FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 1771,8 1855,2
Tentativa 02 1844,6 1783,0
Tentativa 03 1774,1 1770,3
Média Final 1796,8 1802,8

No teste de processamento, também teve resultado inesperado: A VM com FreeBSD padrão teve desempenho de CPU levemente superior a VM preparada para virtualização.

Obs.: No host, a medida foi de: 1820,3.

3.3. Teste de velocidade de Rede

O "iperf" é uma ferramenta simples para testar a velocidade de rede entre duas máquinas, para saber mais leia aqui. A versão é a 2.0.5.
O ambiente de teste foi montado em cima de rede gigabit Ethernet.
Neste caso, o teste também foi repetido três vezes e o resultado final é a média dos testes.
A máquina virtual assumiu o lado client do iperf, comando:
# iperf -c IP_SERVIDOR_IPERF
Outra máquina, identificado por IP_SERVIDOR_IPERF acima, não é virtualizada. Ela está na rede e fez papel de servidor, nos dois casos.
FreeBSD preparado para Virtualização. Teste de rede com IPERF.
FreeBSD padrão. Teste de rede com IPERF.

Resultado final do teste de rede:


Velocidade de rede com o iperf FreeBSD Preparado para Virtualização FreeBSD Padrão
Tentativa 01 407 Mbits/s 403 Mbits/s
Tentativa 02 409 Mbits/s 409 Mbits/s
Tentativa 03 413 Mbtis/s 421 Mbits/s
Média Final 409,66 Mbits/s 411 Mbtis/s

Mais uma vez, a VM padrão do FreeBSD se mostrou mais performática que a VM preparada para Virtualização.

Obs.: No host, o teste chegou a 821 Mbits/s.

4.0 Resultado final dos testes

A tabela abaixo apresenta o resumo dos testes nos dois FreeBSD:


Teste \ VM FreeBSD Preparado para Virtualização FreeBSD Padrão Diferença
Gravação em Disco 48,5 MB/s 51,1 MB/s 5,09%
Performance de Rede 409,66 Mbits/s 411 Mbtis/s 0,33%
Velocidade de Processamento 1796,8 1802,8 0,22%

Os três testes mostraram que o desempenho da Máquina Virtual de FreeBSD padrão é mais performático com a VM preparada para virtualização.

5.0 Conclusão

O FreeBSD é um Sistema Operacional muito apreciado pelos usuários tradicionais, ele não aparece muito na mídia, igual o Linux.
Ambientes não virtualizados é praticamente impossível nos dias de hoje. E, geralmente, o Linux é superior ao FreeBSD em ambientes Virtualizados. Isto fez com que o uso do FreeBSD caísse ainda mais.
Os testes mostraram que o FreeBSD preparado para virtualização NÃO aumenta o desempenho, pelo contrário: nos três testes (gravação de disco, Rede e Processamento) ele possui performance inferior.
Infelizmente o FreeBSD irá continuar a perder espaço para o Linux.

quarta-feira, 4 de maio de 2016

Quantas cifras por segundo meu PC consegue testar?

Com o Hash de uma senha é possível encontrar, depois de muito processamento, o texto equivalente através de força bruta. O ataque por força bruta consiste em testar todas as possibilidades até encontrar a senha correta.
O Hash pode ser em MD5, LM, SHA, CRYPT, etc. Cada um deste possui dificuldade distinta.

Objetivo do teste

Identificar quantas cifras o PC i7 com 8GB de RAM, com Linux, consegue gerar em apenas 1 segundo.

Atividade

A ferramenta "John the Ripper" oferece um parâmetro "-test" que gera um benchmark das cifras mais conhecidas. Veja o resultado:

root@info:/home# john -test
Created directory: /root/.john
Benchmarking: descrypt, traditional crypt(3) [DES 128/128 SSE2]... DONE
Many salts: 3772K c/s real, 3772K c/s virtual
Only one salt: 3573K c/s real, 3580K c/s virtual

Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [DES 128/128 SSE2]... DONE
Many salts: 122649 c/s real, 122649 c/s virtual
Only one salt: 119680 c/s real, 119919 c/s virtual

Benchmarking: md5crypt [MD5 32/32]... DONE
Raw: 9279 c/s real, 9279 c/s virtual

Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/32 X2]... DONE
Raw: 683 c/s real, 683 c/s virtual

Benchmarking: LM [DES 128/128 SSE2]... DONE
Raw: 48577K c/s real, 48577K c/s virtual

Benchmarking: AFS, Kerberos AFS [DES 48/64 4K MMX]... DONE
Short: 422297 c/s real, 422297 c/s virtual
Long: 1268K c/s real, 1268K c/s virtual

Benchmarking: tripcode [DES 128/128 SSE2]... DONE
Raw: 3327K c/s real, 3334K c/s virtual

Benchmarking: dummy [N/A]... DONE
Raw: 59150K c/s real, 59150K c/s virtual

Benchmarking: crypt, generic crypt(3) [?/32]... DONE
Many salts: 250867 c/s real, 250867 c/s virtual
Only one salt: 244665 c/s real, 244665 c/s virtual

Logotipo da ferramenta John "The Ripper".

Problema: Força Bruta no crypt

O crypt é o algoritmo utilizado pela maioria dos Linux para armazenar as senhas dos usuários. Segundo o comando john, o PC testado acima, consegue testar aproximadamente 250mil senhas por segundo.

A tabela abaixo demonstra o tempo para quebrar uma senha utilizando o CRYPT, dependendo do tamanho de caracteres utilizado:


Tamanho da Senha Tempo para quebrar a senha
4 caracteres 5 minutos
5 caracteres 8 horas
6 caracteres 1 mês
7 caracteres 8 anos
8 caracteres 8 Séculos
9 caracteres 74 milênios
10 caracteres 6900 milênios

Foi considerado que o usuário utilizou os caracteres imprimíveis (94 caracteres), e que letras maiúsculas e minúsculas são diferentes.
A máquina utilizada é caseira, veja que senhas pequenas são relativamente fáceis de quebrar, em até 1 mês é possível quebrar uma senha com 6 dígitos.

Conclusão

O John the Ripper é a ferramenta mais conhecida para quebrar senhas, ele possui muitas funcionalidades. O texto teve por objetivo checar quantas cifras um PC consegue gerar.
Foi observado que, dependendo do algoritmo de criptografia utilizado, o tempo muda muito. E este tempo que define a força de determinada criptografia.
No teste foi utilizado uma máquina simples, em um Cluster o tempo para quebrar seria muito inferior.
O "John the Ripper" também pode ser utilizado para testar quantas hash um servidor consegue gerar por segundo. Servidores de autenticação são os que mais realizam esta operação.

iperf: Ferramenta para testar velocidade entre duas máquinas

O IPERF é utilizado para testar a velocidade de comunicação entre duas máquinas na rede. Seu funcionamento é no modo Cliente-Servidor:
O mesmo comando é executado nas duas máquinas, mas com parâmetro diferente. No Servidor, o comando é:

iperf -s

Após o comando, o Servidor entra em modo de espera, ele aguarda a conexão de um Cliente.
No Cliente, a linha de comando fica:

iperf -c IP_SERVER

Este é o funcionamento simples do IPERF, veja o resultado:
iperf em servidor público
No caso acima, utilizei um servidor público de iperf, hospedado na França: "debit.k-net.br". A banda medida foi de 5,68 Mbits/s.

Lista de servidores públicos de Iperf 

Servidor Pais Banda
debit.k-net.fr França 1Gbits/s
iperf.it-north.net Cazaquistão 1Gbits/s
iperf.scottlinux.com USA 40Gbits/s
iperf.he.net USA 1Gbits/s

Para testar um destes Servidores públicos de iperf, basta digitar "iperf -c SERVIDOR", veja a saída de uma máquina linux com link rápido:

Iperf Servidor Público
Neste caso, a velocidade medida foi de 73,1Mbtis/s.

Instalação Iperf

O iperf funciona em Windows, Linux, Android, Apple IOS, FreeBSD, etc. Em Windows pode ser baixado no site https://iperf.fr/iperf-download.php. Em Linux, basta instalar com "apt-get install iperf".

É possível baixar o código fonte e compilar:
root@server# wget https://iperf.fr/download/source/iperf-3.1.2-source.tar.gz
root@server# tar -zxvf iperf-3.1.2-source.tar.gz
root@server# cd iperf-3.1.2 
root@server# ./configure ; make ; make install

OBS: Verifique se há nova versão no site do iperf.

Conclusão

O iperf é uma ferramenta muito simples para testar a velocidade de conexões de rede entre duas máquinas, em um determinado momento. Em testes de stress, é aconselhável utilizar ferramentas apropriada, como por exemplo o pkgen.

Teste de Performance de Servidores e Serviços

Este blog tem por objetivo centralizar informações de ferramentas para teste de desempenho (performance) de servidores e de serviços de rede em geral, tais como:

Gravação e Leitura de discos: dd, hdparm, gnome-disks.
Velocidade de rede: iperf, genpack.
Processamento: cpuboss.
Memória RAM:
Servidor WEB: JMeter.
Servidor de Banco de Dados:
Serviço de Diretório LDAP: JMeter, ldapperf.
Serviço de Nomes DNS: dig.
Serviço de Autenticação Radius: radtest, radperf.
Serviço de Email: postal.
Desempenho com Criptografia: John The Ripper, MD5, SHA1, Blowfish, RSA, NT-HASH, OpenSSL etc.


Os posts irão mostrar as ferramentas de teste e os possíveis resultados para servir como base de comparação, benchmark.

Outro assunto abordado no blog é sobre Metodologia de Testes. Que fornece as diretrizes para correta execução dos testes.