Análise passiva (parte 2)

Nesta segunda parte do artigo sobre análise passiva, iremos conhecer técnicas para passar por filtros de pacotes e entender alguns conceitos de pacotes como payload e padrões para transmissão.

[ Hits: 39.891 ]

Por: Anderson L Tamborim em 22/06/2004 | Blog: http://y2h4ck.wordpress.com


Técnicas contra filtros



Neste tópico veremos algumas técnicas básicas para passar por filtros no momento em que estamos recolhendo informações de um determinado host. Para estes testes iremos utilizar dois softwares muito interessantes:
  • hping2
  • netcat
O hping2 e o netcat você pode baixar em http://freshmeat.net/, o netcat em geral já vem instalado na maioria das distribuições Linux. Procure pelo comando: "nc" ou "netcat".

As versões envolvidas neste teste são: netcat-1.10-764 e hping2.0.0-rc2. Vamos lá, para um primeiro contato com as ferramentas vamos ver um pouco sobre cada uma delas.

Netcat: É um software extremamente valioso apesar do pequeno tamanho, e considerada o canivete suíço do TCP/IP, com ele você pode manipular conexões, utilizá-lo como cliente ftp/telnet, ouvir portas, criar túneis e direcionar fluxos de dados, pois o netcat não tem um protocolo padrão, você pode configurá-lo tanto para TCP, como UDP, SYN, telnet, FTP, etc.

Hping2: É um software que envia requisições de pacotes utilizando diferentes tipos de payloads e headers, uma ferramenta extremamente útil para spoof de pacotes e packet injection em redes. Ele utiliza libpcap para operar e consegue jogar pacotes por trás de filtros, tornando-se assim extremamente interessante, merece uma análise posterior.

Vamos fazer um pequeno teste simples com o hping2. Usaremos a sintaxe mais básica dele:

$ hping2 localhost
RootSec:/ # hping2 localhost
HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 0 data
bytes
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=1.4 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=1.0 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms

Bom a primeira vista ele nos retornou respostas normais como um ping faria. Mas ele nos retorna algumas informações preciosas: flags. Como falávamos de payload logo acima, também devemos acrescentar que no TCP/IP, quando estamos realizando o ThreeWay-Handshake (se não conhece pesquise), as portas do sistemas retornam flags junto ao payload indicando se estão disponíveis ou não pra conexão, flag=SA significa disponível, flag=RA indisponível.

Para o primeiro teste vamos utilizar o iptables barrando comunicação ICMP no nosso host:

# iptables -A INPUT -p icmp -j DROP
$ ping localhost

PING localhost (127.0.0.1) 56(84) bytes of data.

--- localhost ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Como vimos acima, enviamos 3 pacotes e não recebemos nenhum de volta, ou seja os pacotes foram filtrados.

Agora entra em cena o hping, onde não precisamos obrigatoriamente enviar requisições ICMP para pingar o host, podemos usar pacotes SYN:

# hping --icmp localhost
HPING localhost (lo 127.0.0.1): icmp mode set, 28 headers + 0 data bytes

--- localhost hping statistic ---
2 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms /* Foi bloqueado */ # hping --syn localhost
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=11.1
ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=0.4 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms

--- localhost hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/4.0/11.1 ms

WooOooW. Obtivemos êxito, o host que estava bloqueando requisições ping com echo_request agora não pode fazer nada contra nossa requisição usando pacotes --syn.

Vamos mais além agora, vamos usar o hping para verificar portas filtradas em nosso sistema alvo. Iremos utilizar o mesmo princípio usado acima. Como exemplo usaremos a porta 25.

tcp    0   0 127.0.0.1:25      0.0.0.0:*          LISTEN


Se conectarmos com telnet nela teremos a resposta do servidor de email que configuramos no em nossa máquina:

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 unsekurity.local ESMTP Postfix
quit

Muito bem, tendo em vista que a porta esta aberta normalmente vamos verificá-la usando o hping:

# hping2 --syn localhost -p 25
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=25 flags=SA seq=0 win=32767 rtt=3.1 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=25 flags=SA seq=1 win=32767 rtt=0.6 ms

--- localhost hping statistic ---
2 packets tramitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.6/1.9/3.1 ms

Ele nos retornou a flag SA, significa que a porta está aberta e esperando conexão. Agora iremos filtrá-la com o iptables:

# iptables -A INPUT -p tcp --dport 25 -j DROP

Seria esse o método que a maioria de nós usaria não é?

Ok, vamos agora tentar obter alguma informação usando o hping:

# hping --syn localhost -p 25
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
ICMP Packet filtered from ip=127.0.0.1 name=localhost port=25
ICMP Packet filtered from ip=127.0.0.1 name=localhost port=25
ICMP Packet filtered from ip=127.0.0.1 name=localhost port=25

Hum, interessante, ele nos mostrou que a porta estava sendo "filtrada", portanto o que podemos concluir? Que a porta está aberta do outro lado, e que o serviço provavelmente está on-line.

Esta conclusão é importante, vejamos por exemplo quem em nosso servidor tem um filtro de portas liberando apenas algumas portas como 80, 21 e 25. Existe um software chamado barricade que mediante determinado pacote ICMP de tamanho de flags determinadas, desativa o filtro e libera a porta e quando o cliente fecha ele volta a travar a porta.

Imaginem o perigo desse tipo de ferramenta em nossa rede, então devemos não apenas filtrar, mas controlar o quê está sendo usado em nosso servidor.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução: pequena explicação sobre payload
   2. Verificando padrões
   3. Técnicas contra filtros
   4. Considerações finais
Outros artigos deste autor

Libsafe: Protegendo Linux contra Smashing Overflow

Seguraça extrema com LIDS

PaX: Solução eficiente para segurança em Linux

Jails em SSH: Montando sistema de Shell Seguro

Security Hacks: Linux & BSD

Leitura recomendada

Uma breve abordagem sobre Criptografia

Instalando e configurando o BackupPC

VPN entre servidores CentOS 6 e Windows 7

Criando VPN com o PFSense

Aquisição Estática de Dados em Computação Forense

  
Comentários
[1] Comentário enviado por fabio em 22/06/2004 - 10:09h

Excelente artigo! Curti bastante o hping2, esse eu não conhecia.

[]'s

[2] Comentário enviado por Ragen em 22/06/2004 - 12:41h

Muito massa seu texto =]

Tem um texto que foi escrito por um amigo meu (Sr. dmr) que se encontra disponivel em http://www.frontthescene.com.br/artigos/http_tunnel.txt isso é, acaba sendo mais uma fonte de estudo pra quem quer se aprofundar no assunto

[]'s

Ragen

[3] Comentário enviado por jllucca em 22/06/2004 - 14:05h

Muito bom o artigo, expos varias coisas que nao conhecia ou que lembrava com outro nome :)

[4] Comentário enviado por agk em 22/06/2004 - 14:12h

Parabéns, excelente artigo, muito útil para abrir os olhos que quem pensa que é só colocar um firewall na rede e estará 100% protegido.

[5] Comentário enviado por y2h4ck em 22/06/2004 - 19:00h

Obrigado Pessoal so acrescentando algo que "faltou". Eu iria utilizar o netcat para abrir algumas portas e deixar como listen ... porem decidi usar um exemplo mais real world portanto descarte o netcat para essa função.

Para quem se interessou e muito bom procurar sobre o netcat...
para colocar uma porta como listen:

$nc -l -p porta -vv

:)

Abraços a todos

[6] Comentário enviado por jeffestanislau em 23/06/2004 - 08:32h

y2h4ck

Novamente torno a parabenizá-lo.... suas explicações são simples e objetivas.... muito bom mesmo!!!

[]´s

[7] Comentário enviado por n1nj4 em 23/06/2004 - 23:04h

Mais um artigo de qualidade, hein?!
Parabéns, Anderson... Apreciei bastante dessa vez!
;-)

[]'s

n1nj4

[8] Comentário enviado por Estorb em 24/06/2004 - 23:35h

Mas a Roda já foi inventada!!!

[9] Comentário enviado por y2h4ck em 25/06/2004 - 08:41h

Estorb é mesmo ?

[10] Comentário enviado por birilo em 25/06/2004 - 22:35h

Novamente, mandou muito bem...

[11] Comentário enviado por PgDn em 26/06/2004 - 23:53h

quando vc for lançar um livro sobre analise e segurança .. conte comigo para comprar o primeiiro exemplar... vc é o cara que conhece de proteçao ....
e tem mais..além disso tudo eh uma grande pessoa...abraço

[12] Comentário enviado por estorb em 27/06/2004 - 13:33h

Milagre!!!! o RE.TAR..DO do wrochal não apareceu aqui falando absurdos!!!!!!!

[13] Comentário enviado por msmadela em 11/11/2008 - 02:28h

Oi y2h4ck, fiz o teste no meu Fedora C8 e o hping não indicou que a porta estava filtrada, mas o nmpa indica. Minha pergunta é: como o sniffer sabe que uma porta está sendo filtrada? O firewall devolve alguma informação mesmo usando um target DROP no iptables?

[14] Comentário enviado por y2h4ck em 11/11/2008 - 10:28h

msmadela,

O que acontece é o seguinte, quando você filtra uma porta ... significa que você esta colocando a tag "REJECT" nela e não DROP.
Quando um pacote --tcp-syn encontra uma porta filtrada com REJECT, o firewall devolve para o host que acessa um pacote --icmp-type3
que significa "destination unreachable". Com isso ele consegue deduzir que a porta esta filtered. Caso esteja como DROP, o host não envia nada, dai é necessario efetuar alguma varredura adicional para ajudar você confirmar se esta Down ou esta DROP, um bom exemplo seria uma varredura UDP + ACK. :)

[]s

Bons estudos.


Contribuir com comentário