packet sniffing "silenzioso"

[simo.84]

Ciao a tutti, premetto che non intendo utilizzare questa tecnica per scopi illegali, ma solo per scopi di studio (tesi su reti industrial ethernet).

Vi illustro il problema:

Sono connesso a una rete di tipo industriale (non ci sono pc sulla rete ma solo controllori e driver di motori) che utilizza come mezzo fisico di trasmissione Ethernet. Il mio obbiettivo è ascoltare il traffico utilizzando un pc con installato wireshark (modalità promiscua attivata), e questo in effetti riesco a farlo.
Il problema è che oltre ad ascoltare il traffico io spedisco in rete dei pacchetti (nel traffico sniffato vedo i miei pacchetti) e questi pacchetti creano problemi alle mie misure, possono creare collisioni, ritrasmissioni etc, cosa che non succede nella rete che sto ascoltando. (quindi la mia misura influenza la rete...)

Vi chiedo quindi se esiste una procedura (speravo fosse la modalità promiscua...) per impedire questa mia trasmissione di dati in rete e rimanere in ascolto "silenzioso".

Un grazie anticipato a chi vorrà aiutarmi ciao simo

[Rodig]

Originariamente inviato da simo.84

......
Il problema è che oltre ad ascoltare il traffico io spedisco in rete dei pacchetti (nel traffico sniffato vedo i miei pacchetti) e questi pacchetti creano problemi alle mie misure, possono creare collisioni, ritrasmissioni etc, cosa che non succede nella rete che sto ascoltando. (quindi la mia misura influenza la rete...)

E' una legge universale......
Si chiama Principio di indeterminazione di Heisenberg.
Forse ci sono tecniche per limitarlo, ma ci vorrebbe un esperto.

[nebbia88]

Originariamente inviato da Rodig

E' una legge universale......
Si chiama Principio di indeterminazione di Heisenberg.

che tipo di pacchetti spedisci?? se imposti il firewall su "blocca tutto"?

sei su linux vero?

[nuovoUtente86]

l' unica cosa che tu non puoi bloccare sono i keepalive del protocollo ethernet che servono a tenere attiva l' interfaccia. Per il resto puoi bloccare attraverso firewall software.

[Mettiu_]

Originariamente inviato da nuovoUtente86

l' unica cosa che tu non puoi bloccare sono i keepalive del protocollo ethernet che servono a tenere attiva l' interfaccia. Per il resto puoi bloccare attraverso firewall software.

Ciao, scusa ma cosa sono i keep-alive di Ethernet? Non mi risulta che ci sia una sorta di protocollo di Hello in L2, la portante viene rilevata "elettricamente"... L'idea del firewall mi sembra buona. Se sta sotto Linux basta una botta di Iptables

[nuovoUtente86]

Originariamente inviato da Mettiu_

Ciao, scusa ma cosa sono i keep-alive di Ethernet? Non mi risulta che ci sia una sorta di protocollo di Hello in L2, la portante viene rilevata "elettricamente"... L'idea del firewall mi sembra buona. Se sta sotto Linux basta una botta di Iptables

Quello che dici non è perfettamente esatto. Il test elettrico non basta a garantire che l' interfaccia sia up,ma è necessario l' utilizzo di un frame null-data (60bytes) che ha come source e destination mac quello proprio dell' interfaccia.

[Mettiu_]

Sventolo bandiera bianca, non conoscevo l'esistenza di una cosa simile... Comunque sia, dei dati come questi (che di sicuro fanno parte del livello fisico) non daranno problemi in quanto suppongo che anche i sensori inevitabilmente sono collegati ad un apparato fisico che li genera, quindi... Inoltre se è uno switch, questi bit saranno presenti solo lungo il filo che connette il pc alla porta dello switch senza interessare le altre interfacce.

[nuovoUtente86]

Originariamente inviato da Mettiu_

Sventolo bandiera bianca, non conoscevo l'esistenza di una cosa simile... Comunque sia, dei dati come questi (che di sicuro fanno parte del livello fisico) non daranno problemi in quanto suppongo che anche i sensori inevitabilmente sono collegati ad un apparato fisico che li genera, quindi... Inoltre se è uno switch, questi bit saranno presenti solo lungo il filo che connette il pc alla porta dello switch senza interessare le altre interfacce.

Mi spiace neppure questo è giusto. Il test di cui parlavo lavora è implementato su un protocollo(configuration-test-protocolo, ctp) che lavora direttamente sopra L2 , quindi va eventualmente ad essere rilevato da sniffer e analizzatore, indipendentemente che si utilizzi un hub(o qualsiasi altro mezzo condiviso) o uno switch, in quanto nel primo caso si snifferà il canale, nel secondo di simulerà il canale condiviso attraverso porte di mirroring.

[Mettiu_]

Heisenberg mi perdoni per non avergli creduto fin da subito

[simo.84]

Grazie a tutti delle risposte. Appena possibile faccio un tentativo con un firewall.

Lavoro su windows, mi consigliate un firewall (possibilmente free) che permetta di filtrare il traffico in uscita come da voi indicato? (se proprio indispensabile passo sotto linux.)


Alcuni esempi di pacchetti che produco e vedo sulla lista (e vorrei eliminare) sono:

Destination: ff02::16 protocollo ICMPv6 info 90 multicast listener report message v2
e
destination ff02::1:3 protocollo LLMNR info 86 standard query A isatap

Mi sembra di intuire che sono pacchetti che produco per cercare una connessione attiva quando inserisco il cavo ethernet nella dispositivo dove vado in ascolto.

Vi ringrazio ancora delle risposte, vi terrò informati sui futuri sviluppi.