Qual è la procedura di ricezione ed elaborazione dei pacchetti Wireshark su un computer Windows?

Sto per utilizzare Wireshark per il monitoraggio del traffico sul mio computer Windows . Mentre ci lavoravo, mi chiedevo come Wireshark riuscisse a catturare i pacchetti di rete di basso livello prima di Windows .

Prima di tutto, un'interfaccia di rete sulla mia scheda NIC riceve un pacchetto. La scheda di rete esegue quindi alcuni controlli iniziali (CRC, indirizzo MAC corretto, ... ecc.). Supponendo che la verifica abbia avuto esito positivo, la scheda NIC inoltra il pacchetto. Ma come e dove?

Capisco che i driver sono la colla tra la NIC e il sistema operativo o qualsiasi altra applicazione. Suppongo inoltre che ci sia un driver separato per Windows e Wireshark ( WinPcap ?). Altrimenti, Wireshark non sarebbe in grado di ricevere frame Ethernet . Esistono due o più driver NIC che coesistono contemporaneamente? Come fa la NIC a sapere quale utilizzare?

networking ethernet wireshark

— Hansi
fonte

La tua premessa non è corretta. La scheda NIC consegna sempre il pacchetto a Windows (in particolare, al driver del dispositivo e quindi allo stack di rete), e spetta a Windows decidere cosa farne. Windows ha una funzione in cui un programma può chiedere di ricevere copie dei pacchetti "come erano sul filo", magari applicando un filtro, e Wireshark usa quella funzione. Wireshark non bypassa Windows.

— zwol,

(Esistono sistemi operativi sperimentali che tentano di migliorare la rete ad altissima velocità consentendo di consegnare i pacchetti direttamente dalla scheda di rete all'applicazione, ma AFAIK Windows non può farlo: si passa almeno attraverso il livello NDIS.)

— zwol,

Risposte:

Il modello I / O in Windows si basa su una pila di componenti. I dati devono fluire attraverso i vari componenti di quello stack esistente tra la scheda di rete fisica e l'applicazione che consumerà i dati. A volte questi vari componenti ispezionano i dati (ad esempio un pacchetto TCP) mentre fluiscono attraverso lo stack e, in base al contenuto di quel pacchetto, i dati possono essere modificati o il pacchetto può essere scartato del tutto.

Questo è un modello semplificato dello "stack di rete" che attraversa i pacchetti per passare dall'applicazione al filo e viceversa.

Uno dei componenti più interessanti mostrati nello screenshot sopra è l'API Callout WFP (Windows Filtering Platform). Se lo ingrandissimo, potrebbe essere simile a questo:

Gli sviluppatori sono liberi di collegare i propri moduli nelle posizioni appropriate in questo stack. Ad esempio, i prodotti antivirus in genere utilizzano un "driver filtro" che si collega a questo modello e controlla il traffico di rete o fornisce funzionalità firewall. Ovviamente anche il servizio Windows Firewall si adatta a questo modello.

Se si desidera scrivere un'applicazione che registra il traffico di rete, come Wireshark, il modo appropriato per farlo sarebbe quello di utilizzare un proprio driver e inserirlo nello stack il più basso possibile in modo che possa rilevare i pacchetti di rete prima che il modulo del firewall abbia la possibilità di eliminarli.

Quindi ci sono molti "driver" coinvolti in questo processo. Anche molti tipi diversi di driver. Inoltre, altre forme di input / output sul sistema, come le letture e le scritture del disco rigido, seguono modelli molto simili.

Un'altra nota: i callout del WFP non sono l'unico modo per insinuarsi nello stack di rete. WinPCap, ad esempio, si interfaccia con NDIS direttamente con un driver, il che significa che ha la possibilità di intercettare il traffico prima che abbia avuto luogo qualsiasi filtro.

Driver NDIS

WinPCap

Riferimenti:

Stack TCP / IP di nuova generazione in Vista +

Architettura della piattaforma di filtro di Windows

— Ryan Ries
fonte

Diagrammi eccezionali. Questi sono pubblicati su microsoft.com da qualche parte? Se è così, mi piacerebbe curiosare e vedere quali altre informazioni sono disponibili accanto a queste.

— EEAA,

Risposta perfetta Bene e spiegazione facile, visualizzazione fantastica e fonti fornite! Grazie mille!

— Hansi,

+1, vale la pena ricordare che esiste un driver open source costruito su WFP che rende banale scrivere tali applicazioni chiamate WinDivert . Ho anche scritto un wrapper .NET per questo.

In passato c'era qualcosa chiamato "Layered Service Provider" - dove si potevano intercettare e riscrivere i pacchetti - c'è qualche sostituto per quell'abilità? Fa parte dell'API "filtro"? (Oh aspetta, non importa: ho appena guardato il link WinDivert da @TechnikEmpire e ho visto che è possibile.)

— davidbak,

@davidbak sì, WinDivert è una specie di ibrido. Le API del driver callout sono pensate per gli sviluppatori per creare driver specifici che possono fare qualsiasi cosa oltre alla semplice eliminazione di un pacchetto (non richiede driver). WinDivert è un driver di questo tipo ma è generico, offre pieno accesso ai pacchetti spingendo e facendo scoppiare i pacchetti dentro e fuori dallo spazio del kernel e della modalità utente.

Come dice la risposta di Ryan Ries:

WinPCap, ad esempio, si interfaccia con NDIS direttamente con un driver, il che significa che ha la possibilità di intercettare il traffico prima che abbia avuto luogo qualsiasi filtro.

e questa è una descrizione, nella documentazione di WinPcap, di come funziona .

Sarebbe stato meglio come modifica alla risposta di Ryan. Non è una risposta a sé stante.

— Corse di leggerezza con Monica il

In realtà, sì, è una risposta alla sua domanda - più della risposta di Ryan. La domanda era "come lo fa Wireshark"; La risposta di Ryan fornisce molte informazioni su un meccanismo che WinPcap (che è quello che Wireshark usa) non utilizza, quindi è certamente interessante, ma non pertinente alla domanda originale. Il link che ho pubblicato descrive come lo fa WinPcap , il che è rilevante per la domanda originale.

Forse se avessi citato e spiegato i passaggi pertinenti della risorsa di terze parti. Se non altro, una risposta di solo collegamento non è una risposta. Questa è la politica SE. Tutta la tua risposta aggiunge a questa pagina è, letteralmente, "c'è una descrizione di come la risposta di Ries funziona da qualche altra parte su Internet"

— Lightness Races con Monica,