sniffer

[Visitante gnoo]

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:

 

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 :

 

alguém sabe o porque disso?

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

 

Obrigado.

[Visitante gnoo]

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. 

[fredericopissarra]

Sem saber o que o código em python faz não dá pra dizer pq...

[Visitante gnoo]

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.

 

 

[fredericopissarra]

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?

[fredericopissarra]

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

[Visitante gnoo]

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. 

[fredericopissarra]

Dê uma olhada em 'man 7 packet' para a combinação AF_PACKET, SOCK_RAW e ETH_P_ALL para a syscall socket().

[Visitante gnoo]

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

https://wiki.wireshark.org/CaptureSetup/WLAN#Turning_on_monitor_mode

 

 

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. 

[fredericopissarra]

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...