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: 41.728 ]

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


Introdução: pequena explicação sobre payload



Referência


Pequena explicação sobre payload


Bom, em que pode nos ser útil analisar passivamente o tráfego do nosso servidor?
Como sabemos, os esquemas de backdooring vão evoluindo muito com o tempo, temos backdoors que são extremamente furtivas e que não precisam nem bindar portas em servidores, são os casos de wwwtunnels, e túneis de ICMP que são ativados por pacotes de determinados tamanhos.

Quando analisamos um pacote que enviamos na internet, ele teria essa cara:
+---------------+--------------------------+
|  Header       |        Payload           |
+---------------+--------------------------+
Onde o header carrega as informações de onde o pacote vem para onde o pacote vai e o Payload carrega o conteúdo do pacote principal, como por exemplo os dados que estamos transmitindo.

Vamos olhar essa teoria analisando um pacote real, vamos usar um pacote ICMP comum de um ping por exemplo:
14:05:07.647489 localhost > localhost: icmp: echo request (DF) 
(ttl 64, id 0, len 84)
    4500 0054 0000 4000 4001 3ca7 7f00 0001      E..T..@.@.<.....
    7f00 0001 0800 4e26 8407 0001 c3ac dd40      ......N&.......@
    90e0 0900 0809 0a0b 0c0d 0e0f 1011 1213      ................
    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223      ............ !"#
    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233      $%&'()*+,-./0123
    3435 3637                        
    Vamos destrinchar esse pacote ( como diria o esquartejador ):

14:05:07.647489 localhost > localhost: icmp: echo request (DF) 
(ttl 64, id 0, len 84)
Essa linha contém o header do nosso pacote, como podemos ver temos a hora que o pacote foi enviado, de onde foi enviado, > para quem foi enviado, o tipo de pacote (icmp) echo_request, e as informações adicionais como ttl, e uma coisa importante, o id do pacote.
    4500 0054 9a7a 0000 4001 e22c 7f00 0001      E..T.z..@..,....
    7f00 0001 0000 5626 8407 0001 c3ac dd40      ......V&.......@
    90e0 0900 0809 0a0b 0c0d 0e0f 1011 1213      ................
    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223      ............ !"#
    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233      $%&'()*+,-./0123
    3435 3637
Esse é o Payload do nosso pacote contendo as informações que estamos transmitindo, essa saída ao lado:
E..T.z..@..,....
......V&.......@

................
............ !"#
$%&'()*+,-./0123
4567
Foi o que o asctcpdump transformou em ASCII para nos podermos ler. Você entendeu algo? Bom eu também não eheh, mas isso não importa, vamos continuar nossa análise, você verá que esse pequeno conhecimento guardado até agora será muito importante em nossa análise.

    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

Segurança extrema com LIDS: novos recursos

Libsafe: Protegendo Linux contra Smashing Overflow

Seguraça extrema com LIDS

Race condition - vulnerabilidades em suids

SECtool - Análise Local para Linux

Leitura recomendada

Vault: SSH com OneTimePassword

Túneis cifrados com SSH

Consegue guardar um segredo?

Instalando o Nagios

Varredura bruta com NMAP

  
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




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts