O que é o procedimento de recebimento e processamento de pacotes Wireshark em uma máquina Windows?

Estou prestes a usar o Wireshark para monitorar o tráfego no meu computador com Windows . Enquanto trabalhava nisso, fiquei pensando como o Wireshark consegue capturar pacotes de rede de baixo nível antes do Windows .

Primeiro de tudo, uma interface de rede na minha NIC recebe um pacote. A NIC faz algumas verificações iniciais (CRC, endereço MAC correto, ... etc.). Supondo que a verificação foi bem-sucedida, a NIC encaminha o pacote. Mas como e onde?

Entendo que os drivers são a cola entre a NIC e o SO ou qualquer outro aplicativo. Suponho ainda que exista um driver separado para Windows e Wireshark ( WinPcap ?). Caso contrário, o Wireshark não seria capaz de receber quadros Ethernet . Existem dois ou mais drivers de NIC coexistindo ao mesmo tempo? Como a NIC sabe qual usar?

networking ethernet wireshark

— Hansi
fonte

Sua premissa está incorreta. A NIC sempre entrega o pacote ao Windows (especificamente, ao driver do dispositivo e depois à pilha da rede), e cabe ao Windows decidir o que fazer com ele. O Windows possui um recurso em que um programa pode solicitar o recebimento de cópias de pacotes "como estavam no fio", talvez aplicando um filtro, e o Wireshark usa esse recurso. O Wireshark não ignora o Windows.

— Zwol

(Existem sistemas operacionais experimentais que tentam melhorar a rede de velocidade extremamente alta, permitindo que os pacotes sejam entregues diretamente da placa de rede para o aplicativo, mas o AFAIK Windows não pode fazer isso: você sempre passa pela camada NDIS.)

— Zwol

Respostas:

O modelo de E / S no Windows é baseado em uma pilha de componentes. Os dados devem fluir através dos vários componentes dessa pilha existentes entre a placa de rede física e o aplicativo que consumirá os dados. Às vezes, esses vários componentes inspecionam os dados (um pacote TCP, por exemplo) à medida que fluem pela pilha e, com base no conteúdo desse pacote, os dados podem ser alterados ou o pacote pode ser descartado completamente.

Este é um modelo simplificado da "pilha de rede" pela qual os pacotes fluem, a fim de passar do aplicativo ao fio e vice-versa.

Um dos componentes mais interessantes mostrados na captura de tela acima é a API de texto explicativo do WFP (Windows Filtering Platform). Se aproximarmos isso, pode ser algo como isto:

Os desenvolvedores são livres para conectar seus próprios módulos nos locais apropriados nesta pilha. Por exemplo, produtos antivírus geralmente usam um "driver de filtro" que se conecta a esse modelo e inspeciona o tráfego de rede ou fornece recursos de firewall. O serviço Firewall do Windows também obviamente se encaixa nesse modelo.

Se você quiser escrever um aplicativo que registre o tráfego de rede, como o Wireshark, a maneira apropriada de fazer isso seria usar um driver próprio e inseri-lo na pilha o mais baixo possível para que ele possa detectar pacotes de rede antes que seu módulo de firewall tenha a chance de eliminá-los.

Portanto, existem muitos "drivers" envolvidos nesse processo. Muitos tipos diferentes de drivers também. Além disso, outras formas de entrada / saída no sistema, como leituras e gravações de unidades de disco rígido, seguem modelos muito semelhantes.

Outra observação: as frases de destaque do WFP não são a única maneira de se insinuar na pilha de rede. O WinPCap, por exemplo, faz interface com o NDIS diretamente com um driver, o que significa que ele tem a chance de interceptar o tráfego antes que qualquer filtragem ocorra.

Drivers NDIS

WinPCap

Referências:

Pilha TCP / IP de próxima geração no Vista +

Arquitetura da plataforma de filtragem do Windows

— Ryan Ries
fonte

Diagramas pendentes. Eles estão publicados em microsoft.com em algum lugar? Se assim for, eu adoraria bisbilhotar e ver que outras informações estão disponíveis ao lado delas.

— EEAA 12/06

Resposta perfeita. Bem e fácil de explicar, incríveis visualizações e fontes fornecidas! Muito obrigado!

— Hansi

+1, vale mencionar que existe um driver de código aberto criado no WFP que torna trivial escrever esses aplicativos chamados WinDivert . Também escrevi um wrapper .NET para ele.

Costumava ser o caso de algo chamado "Provedor de Serviços em Camadas" - onde você podia interceptar e reescrever pacotes - existe algum substituto para essa capacidade? Faz parte da API de "filtragem"? (Oh, espere, não importa: Eu olhei para o link WinDivert de @TechnikEmpire e ver que isso é possível.)

— davidbak

@davidbak sim, o WinDivert é uma espécie de híbrido. As APIs do driver de frase de destaque destinam-se a desenvolvedores criarem drivers específicos que podem fazer qualquer coisa além de simplesmente soltar um pacote (não requer driver). O WinDivert é um driver desse tipo, mas é genérico, fornecendo acesso total aos pacotes, empurrando e colocando pacotes dentro e fora do espaço do kernel e do modo de usuário.

Como a resposta de Ryan Ries diz:

O WinPCap, por exemplo, faz interface com o NDIS diretamente com um driver, o que significa que ele tem a chance de interceptar o tráfego antes que qualquer filtragem ocorra.

e esta é uma descrição, na documentação do WinPcap, de como isso funciona .

Isso teria sido melhor como uma edição da resposta de Ryan. Não é uma resposta por si só.

— Lightness Races com Monica

Na verdade, sim, é uma resposta para sua pergunta - mais do que a resposta de Ryan. A questão era "como o Wireshark faz isso"; A resposta de Ryan fornece muitas informações sobre um mecanismo que o WinPcap (que é o que o Wireshark usa) não usa, portanto é certamente interessante, mas não relevante para a pergunta original. O link que eu publiquei descreve como o WinPcap faz isso, o que é relevante para a pergunta original.

Talvez se você tivesse citado e explicado as passagens relevantes do recurso de terceiros. Se nada mais, uma resposta somente de link não é uma resposta. Essa é a política SE. Toda a sua resposta acrescenta a esta página é, literalmente, "há uma descrição de como a resposta do Ries trabalha em outro lugar na internet"

— Leveza raças com Monica