¿Cuál es el procedimiento de recepción y procesamiento de paquetes de Wireshark en una máquina con Windows?

Estoy a punto de usar Wireshark para monitorear el tráfico en mi computadora con Windows . Mientras trabajaba en ello, me preguntaba cómo Wireshark logra capturar paquetes de red de bajo nivel antes de que Windows lo haga.

En primer lugar, una interfaz de red en mi NIC recibe un paquete. La NIC realiza algunas comprobaciones iniciales (CRC, dirección MAC correcta, ... etc.). Asumiendo que la verificación fue exitosa, la NIC reenvía el paquete. ¿Pero cómo y dónde?

Entiendo que los controladores son el pegamento entre la NIC y el sistema operativo o cualquier otra aplicación. Además, supongo que hay un controlador separado para Windows y Wireshark ( WinPcap ?). De lo contrario, Wireshark no podría recibir tramas Ethernet . ¿Hay dos o más controladores NIC coexistiendo al mismo tiempo? ¿Cómo sabe la NIC, cuál usar?

networking ethernet wireshark

— Hansi
fuente

Tu premisa es incorrecta. La NIC siempre entrega el paquete a Windows (específicamente, al controlador del dispositivo y luego a la pila de red), y depende de Windows decidir qué hacer con él. Windows tiene una función en la que un programa puede solicitar recibir copias de los paquetes "tal como estaban en el cable", tal vez aplicando un filtro, y Wireshark usa esa función. Wireshark no omite Windows.

— zwol

(Existen sistemas operativos experimentales que intentan mejorar las redes de alta velocidad al permitir que los paquetes se entreguen directamente desde la tarjeta de red a la aplicación, pero AFAIK Windows no puede hacer esto: siempre al menos pasa por la capa NDIS).

— zwol

Respuestas:

El modelo de E / S en Windows se basa en una pila de componentes. Los datos deben fluir a través de los diversos componentes de esa pila que existen entre la tarjeta de red física y la aplicación que consumirá los datos. A veces, esos diversos componentes inspeccionan los datos (un paquete TCP, por ejemplo) a medida que fluyen a través de la pila y, en función del contenido de ese paquete, los datos pueden alterarse o el paquete puede descartarse por completo.

Este es un modelo simplificado de la "pila de red" a través de la cual fluyen los paquetes para pasar de la aplicación al cable y viceversa.

Uno de los componentes más interesantes que se muestran en la captura de pantalla anterior es la API de llamadas del PMA (Plataforma de filtrado de Windows). Si nos acercamos a eso, podría verse más o menos así:

Los desarrolladores son libres de conectar sus propios módulos en los lugares apropiados de esta pila. Por ejemplo, los productos antivirus suelen utilizar un "controlador de filtro" que se conecta a este modelo e inspecciona el tráfico de red o proporciona capacidades de firewall. El servicio de Firewall de Windows también se ajusta obviamente a este modelo también.

Si desea escribir una aplicación que registre el tráfico de red, como Wireshark, entonces la forma adecuada de hacerlo sería utilizar un controlador propio e insertarlo en la pila lo más bajo posible para que pueda detectar paquetes de red antes de que su módulo de firewall tenga la oportunidad de soltarlos.

Así que hay muchos "controladores" involucrados en este proceso. Muchos tipos diferentes de controladores también. Además, otras formas de entrada / salida en el sistema, como las lecturas y escrituras del disco duro, siguen modelos muy similares.

Otra nota: las llamadas del PMA no son la única forma de insinuarse en la pila de la red. WinPCap como ejemplo, interactúa con NDIS directamente con un controlador, lo que significa que tiene la posibilidad de interceptar el tráfico antes de que se haya producido ningún filtrado.

Controladores NDIS

WinPCap

Referencias

Pila TCP / IP de próxima generación en Vista +

Arquitectura de plataforma de filtrado de Windows

— Ryan Ries
fuente

Diagramas sobresalientes. ¿Están publicados en microsoft.com en alguna parte? Si es así, me encantaría hurgar y ver qué otra información está disponible junto con estos.

— EEAA

Respuesta perfecta. Bien y fácil de explicar, ¡visualización y fuentes increíbles proporcionadas! Muchas gracias!

— Hansi

+1, vale la pena mencionar que hay un controlador de código abierto construido sobre WFP que hace que escribir aplicaciones como WinDivert sea trivial . También he escrito un contenedor .NET para ello.

Solía ser el caso de que hubiera algo llamado el "Proveedor de servicios en capas", donde se podía interceptar y reescribir paquetes, ¿hay algún reemplazo para esa capacidad? ¿Es parte de la API de "filtrado"? (Oh, espera, no importa: acabo de mirar el enlace WinDivert de @TechnikEmpire y veo que eso es posible.)

— davidbak

@davidbak sí, WinDivert es una especie de híbrido. Las API de controlador de llamada están destinadas a que los desarrolladores creen controladores específicos que puedan hacer cualquier cosa más allá de simplemente descartar un paquete (no requiere controlador). WinDivert es un controlador de este tipo, pero es genérico y proporciona acceso completo a los paquetes empujando y sacando paquetes dentro y fuera del kernel y el espacio del modo de usuario.

Como dice la respuesta de Ryan Ries:

WinPCap como ejemplo, interactúa con NDIS directamente con un controlador, lo que significa que tiene la posibilidad de interceptar el tráfico antes de que se haya producido ningún filtrado.

y esta es una descripción, en la documentación de WinPcap, de cómo funciona .

Esto habría sido mejor como una edición de la respuesta de Ryan. No es una respuesta en sí misma.

— Lightness compite con Monica el

En realidad, sí, es una respuesta a su pregunta, más que la respuesta de Ryan. La pregunta era "cómo lo hace Wireshark"; La respuesta de Ryan brinda mucha información sobre un mecanismo que WinPcap (que es lo que usa Wireshark) no usa, por lo que es ciertamente interesante, pero no relevante para la pregunta original. El enlace que publiqué describe cómo lo hace WinPcap , que es relevante para la pregunta original.

Tal vez si hubiera citado y explicado los pasajes relevantes del recurso de terceros. Por lo menos, una respuesta de solo enlace no es una respuesta. Esa es la política de SE. Todo lo que su respuesta agrega a esta página es, literalmente, "hay una descripción de cómo funciona la respuesta de Ries en otro lugar en Internet"

— Lightness Races with Monica