Ordine di attraversamento dei filter drivers nello stack di rete di Windows

Ciao a tutti, oggi andiamo ad esplorare in profondità il kernel di Windows.

Nello specifico ci interessa capire, tra il TCP/IP di Windows e la scheda di rete fisica, in che ordine i pacchetti di rete attraversano i diversi driver dello stack. Questa informazione può essere preziosissima in fase di troubleshooting, ad esempio per capire se la perdita di un pacchetto di rete può essere causata da uno di tali driver intermedi.

Nota bene 1: quando elencherò una sequenza di driver lo farò sempre dall’alto (vicino al livello applicativo) verso il basso (verso il media fisico) dello stack - vedi Modello OSI .

Nota bene 2: L’implementazione dello stack di rete è diversa in Windows Server 2003 e in Windows Server 2008. Parleremo brevemente del modello in 2003 (più semplice) per poi arrivare al modello 2008. Le versioni attuali del sistema operativo (Windows 2012 (R2) e Windows 8 e 8.1) fanno riferimento al modello già esistente in Windows 2008.

Nota bene 3: su alcuni punti semplificherò molto perché altrimenti il blog post diventa un libro di mille pagine :)

 

  

Il punto chiave dell’architettura è NDIS.

NDIS è il componente che si occupa di gestire l’interazione tra i driver di basso livello della scheda di rete e quelli di alto livello del sistema operativo, fra tutti tcpip.sys

Tutti gli ulteriori driver di rete che vi possono venire in mente (antivirus, firewall, packet scheduler, network monitoring) sono implementati a livello NDIS.

Windows 2003 fa riferimento all’architettura NDIS 5.x
http://msdn.microsoft.com/en-us/library/windows/hardware/ff556938(v=vs.85).aspx 

Sostanzialmente possiamo dividere i drivers in tre tipi:

1) Protocol Drivers sono i driver NDIS che si occupano direttamente di interfacciarsi con i protocolli di trasporto come ad esempio il TCP/IP.

2) Intermediate Drivers come dice il nome sono i driver che si pongono a metà tra i miniport e i protocol, con lo scopo di monitorare, modificare, filtrare il traffico.

3) Miniport drivers sono i driver responsabili di “parlare” con la scheda di rete e gestire il flusso di dati verso la stessa.

Il concetto chiave è quello di binding. Se c’è un binding tra un protocollo e un miniport significa che lo specifico traffico di rete può passare, nell’ordine, da quel protocollo e da quel miniport. Più protocolli possono essere ovviamente associati allo stesso miniport (e viceversa). La stessa cosa vale per gli intermediate: se c’è un binding tra protocol e intermediate e tra intermediate e miniport, o anche fra due driver intermediate, possiamo ricostruire l’albero di dipendenze e quindi la sequenza dei driver attraversati nello stack NDIS 5.x

L’analisi di un memory dump è necessaria per effettuare questa operazione:

il comando !ndiskd.miniport mostra i miniport installati

il comando !ndiskd.protocol mostra i protocolli installati ( e il loro binding ai diversi miniport)

il comando !ndiskd.mopen mostra i binding correntemente attivi tra tutti i drivers NDIS.

Nota bene: Windbg non vi mostrerà una lista di intermediate drivers, ma potete individuare la presenza di un intermediate driver dal fatto che ha sia una interfaccia di tipo miniport (per parlare con i protocols) che una interfaccia di tipo protocol (per parlare con i miniports)

Ad esempio:

kd> !ndiskd.mopen Open ba9055c0 Miniport: ba932ae8 - WAN Miniport (Network Monitor) Protocol: ba14dcf8 - NM Open ba0c5008 Miniport: ba882ab0 - Microsoft Virtual Machine Bus Network Adapter - Network Load Balancing Filter Device Protocol: ba14dcf8 - NM Open ba3717d0 Miniport: ba882ab0 - Microsoft Virtual Machine Bus Network Adapter - Network Load Balancing Filter Device Protocol: ba43e008 - TCPIP Open bab005f0 Miniport: ba93dab0 - Microsoft Virtual Machine Bus Network Adapter Protocol: ba7503f0 - WLBS

Da questo stack possiamo capire che oltre al miniport relativo alla scheda di rete (Microsoft Virtual Machine Bus Network Adapter) e al protocollo TCPIP di Windows ci sono due Intermediate drivers.
Uno è il driver del Network Monitor che ha una interfaccia miniport chiamata WAN Miniport (Network Monitor) e una interfaccia protocollo chiamata NM.
Un altro è il driver del Network Load Balancing (NLB Microsoft) che ha una interfaccia miniport chiamata Microsoft Virtual Machine Bus Network Adapter - Network Load Balancing Filter Device e una interfaccia protocollo chiamata WLBS.

Poiché il protocollo del Network Monitor è Bindato alla interfaccia Miniport che espone NLB, possiamo concludere che l’ordine dei drivers in questo stack Windows 2003 è:

• TCPIP di Windows
• Network Monitor
• Network Load Balancing
• Scheda di rete

Da Windows 2008 invece si è passati a NDIS 6.x

http://msdn.microsoft.com/en-us/library/windows/hardware/ff565453(v=vs.85).aspx

NDIS 6.x introduce il concetto di Filter driver. I Filter Drivers sono, come gli Intermediate, driver che si pongono in mezzo tra i Miniport Drivers e i Protocol drivers. Ci sono però alcune differenze sostanziali:

I Filter drivers possono gestire più di una istanza del “filtro” che viene implementato in separati Filter modules

i Filter drivers possono stare sia sopra che sotto agli intermediate drivers

La facilità di implementazione, e soprattutto la “leggerezza” di gestione e di performance per il sistema operativo ha fatto in modo che la scelta di molti sviluppatori sia stata quella di passare all’utilizzo dei filter drivers invece degli intermediate per moltissimi driver (antivirus, firewall, packet scheduler, network monitoring) da Windows 2008 in poi.

Ma come facciamo a capire, se c’è più di un filter driver, in che ordine sono caricati e quindi in che ordine i pacchetti di rete li attraversano?

Esiste una attributo per i Filter Drivers chiamato FilterClass. In base alla loro classe quindi, i filter driver vengono disposti nel seguente ordine (Dall’alto verso il basso).

· ms_firewall_upper*

· scheduler

· encryption

· compression

· vpn

· loadbalance

· failover

· diagnostic

· custom

· provider_address

*Considerate che la classe più in alto ms_firewall_upper è dedicata esclusivamente al Windows Firewall e non può essere utilizzata da altri drivers.

La lista è contenuta nella seguente chiave di registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\FilterClasses

ed è documentata qui
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545161(v=vs.85).aspx

Se esiste più di un driver della stessa classe, il filter driver che viene installato per primo rimane più sotto nello stack (più vicino alla NIC).

Possiamo visualizzare FilterClass dei driver in due modi:

1) Esplorando le sottochiavi di HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\ alla ricerca della Reg_sz chiamata FilterClass specifica di ogni driverche contiene l’informazione in formato stringa. Questo metodo è un po' complesso perché le sottochiavi sono numerosissime e non facilmente interpretabili in quanto associate a differenti GUID sui diversi computer.

2) Tramite l’analisi di un memory dump con i seguenti comandi:

• !ndiskd.filters per elencare tutti i filtri presenti. Da questo comando possiamo anche vedere a quali miniport driver è bindato lo specifico filter driver.
• !ndiskd.filter <filterblock> per visualizzare gli attributi di uno specifico filtro.

Ad esempio:

kd> !ndiskd.filters fffffa8302a25260 - Network Load Balancing Filter Driver Filter fffffa83037109e0, Miniport fffffa8302e541a0 - Microsoft Virtual Machine Bus Network Adapter #4   fffffa8302c06d50 - Netmon Lightweight Filter Driver Filter fffffa8302d49010, Miniport fffffa8302e541a0 - Microsoft Virtual Machine Bus Network Adapter #4 Filter fffffa83030ae400, Miniport fffffa8302c8a1a0 - WAN Miniport (Network Monitor) Filter fffffa8302cb93f0, Miniport fffffa8302c281a0 - Teredo Tunneling Pseudo-Interface Filter fffffa8302cb6b10, Miniport fffffa8302c261a0 - Microsoft ISATAP Adapter #3 Filter fffffa8302cb4a30, Miniport fffffa8302c0b1a0 - Microsoft 6to4 Adapter   fffffa8302c0a6f0 - QoS Packet Scheduler Filter fffffa8302d8dc90, Miniport fffffa8302e541a0 - Microsoft Virtual Machine Bus Network Adapter #4 Filter fffffa83030d8010, Miniport fffffa8302c8a1a0 - WAN Miniport (Network Monitor) Filter fffffa83030e1c90, Miniport fffffa8302c8c1a0 - WAN Miniport (IP) Filter fffffa83030b8c90, Miniport fffffa8302c8e1a0 - WAN Miniport (IPv6)   fffffa8302c05730 - WFP LightWeight Filter Filter fffffa830286ac90, Miniport fffffa8302e541a0 - Microsoft Virtual Machine Bus Network Adapter #4 kd> !ndiskd.filterdriver fffffa8302a25260   FILTER DRIVER     Network Load Balancing Filter Driver     Ndis Handle fffffa8302a25260 Ndis API Version v6.0 Driver Version v1.0 Driver Object fffffa83032b0e70 Driver Image NLB.sys     Filter Type MODIFYING_FILTER Run Type MANDATORY_FILTER Class loadbalance References 2

Analizzando la FilterClass per tutti i driver del nostro stack, possiamo ricostruirne la sequenza. bbinando questa informazione a quella per miniport e protocols (che è uguale allo scenario 5.x con gli stessi comandi WinDbg) possiamo quindi concludere che l’ordine dei drivers in uno stack Windows 2008+ è:

• TCPIP di Windows
• Protocol drivers:
  • Wireshark
• Filter Drivers:
  • WFP – Windows Filtering Platform (ms_firewall_upper)
  • QoS Packet Scheduler (scheduler)
  • NLB – Network Load Balancing (loadbalance)
  • Network Monitor (failover)
• Miniport Drivers:
  • Driver di interfacce di rete virtuali (Teredo, ISATAP…)
  • Miniport scheda di rete
• Driver scheda di rete fisica

 

Alcune considerazioni:

1) Network Monitor e Network Load Balancing erano intermediate drivers in NDIS 5.x ma sono stati riscritti come Filter Drivers per Windows 2008. I lettori più attenti avranno notato che i due driver sono in posizione invertita nei due stack (2003 e 2008).
Come sapete, i pacchetti ricevuti da un host di un cluster NLB che non verranno gestiti da tale host vengono comunque ricevuti da quell’host, ma droppati dal driver NLB.
Per questi motivi, se effettuate una cattura del traffico di rete con Network Monitor su tale tipo di host NLB vedrete i pacchetti in ricezione tracciati ma non risposti in Windows 2008 (perché ancora non hanno raggiunto, nello stack, il driver NLB) mentre non vedrete nulla in 2003 (perché quando network monitor arriva a catturare, i pacchetti sono già stati droppati dal driver NLB sottostante).
Ulteriori info qui: http://blogs.technet.com/b/nettracer/archive/2010/08/05/is-it-real-or-matrix-some-facts-about-network-traces.aspx

2) Wireshark, seppure è un programma di analisi del traffico di rete come Network Monitor, è stato implementato in maniera completamente diversa, cioè come un semplice Protocol Driver http://www.winpcap.org/misc/faq.htm#Q-26
http://www.winpcap.org/docs/docs_411/html/group__NPF.html
Per questo motivo, se Wireshark e Network monitor sono entrambi attivi in cattura sulla stessa macchina Windows, potreste notare delle differenze nel traffico catturato se questo viene droppato/modificato dai filter driver intermedi presenti tra i due nello stack.

3) il WFP è il componente chiave del Windows Firewall, ma il Windows Firewall è molto più complesso e identificarlo come un semplice filter driver sarebbe troppo riduttivo, in quanto ha componenti e ramificazioni a più livelli nello stack (e anche nell’application layer). Pensate solo al fatto che esistono circa 50 kernel-mode filtering layers. Questo è stato fatto anche per motivi di sicurezza, per evitare che driver malevoli si pongano nella opportuna posizione dello stack e interferiscano con il WFP.
Per approfondimenti: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366509(v=vs.85).aspx

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support