Ir para conteúdo
  • Cadastre-se
Entre para seguir isso  
gnoo

sniffer

Posts Recomendados

Saudações 

ando a brincar com um sniffer feito em python, a situação é a seguinte, eu consigo ver o meu tráfego que sai da minha máquina e o seu destino, como por exemplo quando acesso o site:

https://www.mentebinaria.com.br 

o resultado é esse:

1495116537_Capturadeecr_2018-06-10_18-26-00.png.6d0b9cdf523407104a49c3628e24bcef.png

 

até ai tudo bem... mas se for um familiar meu que no caso usa Windows  numa outra máquina, eu só consigo ver que o tráfego sai da máquina dele e o destino é sempre 255.255.255.255 :

1446149710_Capturadeecr_2018-06-10_18-17-53.png.e3568d19419a97abde24bb2c67662afc.png

 

alguém sabe o porque disso?

estou a fazer isso como a minha interface de rede sem fio em modo promíscuo.

 

Obrigado.

Editado por gnoo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Já percebi que em principio o 255.255.255.255 tem a ver com o Broadcast, só não percebo é porquê que ele vem com esse endereço e não como o servidor que é feita a requisição. 

Compartilhar este post


Link para o post
Compartilhar em outros sites

Oi @fredericopissarra tudo bem?

Tens razão não foi muito inteligente da minha parte, segue um excerto do programa com o código que trabalha esses dados:

from socket import *
from struct import *
import sys
import binascii





def endereco_mac(mac_em_bytes):
    endereco = binascii.hexlify(mac_em_bytes).decode("ascii")
    return ":".join([endereco[i:i+2] for i in range(0,12,2)])


def ethernet_frame(dados_pacote):

    mac_recebe, mac_envia, protocolo = unpack("! 6s 6s H",dados_pacote[:14])

    return endereco_mac(mac_recebe), endereco_mac(mac_envia), htons(protocolo), dados_pacote[14:]

def IPv4(endereco):
    return '.'.join(map(str,endereco))    
    
def header_IPv4(dados):
    versao_header_tamanho = dados[0]
    versao = versao_header_tamanho >> 4
    tamanho_header = (versao_header_tamanho & 15) * 4
    ttl, protocolo, fonte, target = unpack('! 8x B B 2x 4s 4s', dados[:20])
    return versao, tamanho_header, ttl, protocolo, IPv4(fonte), IPv4(target),dados[tamanho_header:]

    


def main():
    sock = socket(AF_PACKET, SOCK_RAW, ntohs(3))


    while True:
        try:
            dados_pacote, addr = sock.recvfrom(65565)
            mac_recebe, mac_envia, protocolo_ethernet, dados_pacote = ethernet_frame(dados_pacote)
            print("Ethernet :")
            print("\tProtocolo {}".format(protocolo_ethernet))
            print("MAC recebe: {}  MAC envia: {}".format(mac_recebe, mac_envia))
            if protocolo_ethernet == 8:
                (versao, tamanho_header, ttl, protocolo, fonte, target, dados_pacote) = header_IPv4(dados_pacote)
                print("\tPacote IPv4:")
                print("\t\tVersão: {}, Tamanho header: {}, TTL: {}".format(versao, tamanho_header, ttl))
                print("\t\t\tProtocolo: {}, Fonte: {}, Destino: {}".format(protocolo, fonte, target))
                
        except KeyboardInterrupt:
            print("terminado")
            sys.exit(0)
            

if __name__=='__main__':
    main()

No trafego que sai da minha maquina ele detecta o ip da minha maquina e o ip do site que esta sendo feita a requisição, se for uma maquina diferente que esteja na mesma rede ele detecta o ip da maquina  mas o ip do site que e feita a requisição é sempre 255.255.255.255 neste caso maquina a rodar windows ainda tenho outra com linux que devolve tambem o ip 224.0.0.1 salvo erro ... se for trafego a sair do meu smartphone ele detecta o ip do dispositivo mas o site que é feita a requisição mesmo que sites diferente é um ip com 254.0.0.1 se não me engano. 

Obrigado.

 

 

Editado por gnoo

Compartilhar este post


Link para o post
Compartilhar em outros sites

Esses IPs (224.0.0.1 e 254.0.0.1) são de multicast, não?
Dúvida (já que não estou MUITO familiarizado com as libs do python)... O valor em socket.recvfrom é o IP do host destino (não pode ser uma porta, > 16 bits!)? Está em network byte order?

Editado por fredericopissarra

Compartilhar este post


Link para o post
Compartilhar em outros sites
3 horas atrás, fredericopissarra disse:

Esses IPs (224.0.0.1 e 254.0.0.1) são de multicast, não?
Dúvida (já que não estou MUITO familiarizado com as libs do python)... O valor em socket.recvfrom é o IP do host destino (não pode ser uma porta, > 16 bits!)? Está em network byte order?

A função recvfrom() como a documentação oficial diz ela recebe dois tipos de valor , (bytes, address)  onde bytes é um byte object dos dados recebidos, e address é o endereço do socket enviando dados, tal como a documentação sobre a função recvfrom() diz o formato do valor address depende do tipo de socket que é definido se for da forma que o código acima representa    

sock = socket(AF_PACKET, SOCK_RAW, ntohs(3))

Ele "automaticamente" faz um bind na minha interface de rede e fica escutando em todas as portas  ( penso eu de que ),  o que o address me devolve é uma tupla com a minha interface de rede com mais três valores que eu não sei o que é e o endereço mac em bytes order ('wlp3s0', 23346, 4, 1, b'endereço MAC _ bytes') o segundo valor da tupla deve ser a porta em escuta, o que me leva a pensar isso é que esse valor não corresponde ao protocolo da camada de ethernet, (mas também pode ser outra coisa isto sou eu a pensar sozinho)... o terceiro valor da tupla o 4 penso que pode estar relacionado com a versão IP (ipv4)  o quarto valor 1 não sei o que é e o quinto será o meu MAC address.

Se o tipo de socket for 

 sock = socket(AF_INET, SOCK_RAW,IPPROTO_TCP)

ele devolve um tupla com dois valores ('IP', 0), o IP tem vários resultados desde o site onde é feita a requisição, e outros que depois de fazer umas pesquisar com o whois me diz que é da ARIN/IBM fiz umas requisições http com HEAD e dá para ver que são servidores muitos deles Apache, dá-me ideia que será por onde o pacote passa entre o ponto A e o ponto B.

4 horas atrás, fredericopissarra disse:

Esses IPs (224.0.0.1 e 254.0.0.1) são de multicast, não?
 

 

 acho que sim eu estive a ver se relacionava esse endereço com multicast, e realmente uma tabela que vi fazia referencia a 

224.0.0.1 All systems on this subnet.... e acho que é por ai o caminho a explorar vou ver melhor sobre o assunto pode alguma configuração que não está a ser feita mediante esse resultado.

4 horas atrás, fredericopissarra disse:

Ahhhhhhhhh.... a documentação do WinSock2 nos diz que o Windows não lida muito bem com RAW sockets...

https://msdn.microsoft.com/en-us/library/windows/desktop/ms740463(v=vs.85).aspx

 

O socket RAW não está a rodar em windows está a rodar em linux uma distribuição baseada em Arch Linux - Manjaro, o sistema windows é de um familiar meu que está noutro ponto da casa, eu acho que não tem a ver com isso diretamente, até porque eu tenho uma outra maquina com Debian e o resultado é igual e o meu smarthphone acontece o mesmo. 

Compartilhar este post


Link para o post
Compartilhar em outros sites

Olá @fredericopissarra tudo bem?

Eu acho que o problema tem a ver com o modo como eu estou "escutando" os pacotes a passar na rede, andei a ver a documentação do wireshark que pode ser vista aqui:

Citar

 

59721362_Capturadeecr_2018-06-19_12-32-29.thumb.png.025bb86da8f0282a7cd6ad1650e17d2d.png

 

A minha placa de rede não suporta ( monitor mode ), tenho que comprar uma que tenha esse suporte, depois volto a dar novidades para atualizar o post, até lá...

Abraço. 

Compartilhar este post


Link para o post
Compartilhar em outros sites

Obtenha a documentação da python-libpcap (ou, simplesmente da libpcap)... Ela é bem interessante,mas mexer com RAW sockets sempre é dependende de platafforma...
Tive esse problema ao tentar portar o T50 para o Windows, o FreeBSD e o MacOS...

Compartilhar este post


Link para o post
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
Entre para seguir isso  

  • Quem Está Navegando   0 membros estão online

    Nenhum usuário registrado visualizando esta página.

×