web-dev-qa-db-fra.com

Comment savoir qu'un NIC est en mode promiscuous sur un LAN?

Comment savoir qu'un NIC est en mode promiscuous sur un LAN?

30
LanceBaynes

test DNS - de nombreux outils de reniflage de paquets effectuent des recherches d'adresse IP pour nommer des noms DNS à la place des adresses IP. Pour tester cela, vous devez placer votre carte réseau en mode promiscuous et envoyer des paquets sur le réseau destiné aux faux hôtes. Si des recherches de nom à partir des hôtes fictifs sont visibles, un renifleur peut être en action sur l'hôte effectuant les recherches.

Test ARP - En mode promiscuous, le pilote de la carte réseau vérifie que l'adresse MAC est celle de la carte réseau pour les paquets unicast, mais vérifie uniquement le premier octet de l'adresse MAC par rapport à la valeur 0xff pour déterminer si le paquet est diffusé ou non. Notez que l'adresse d'un paquet de diffusion est ff: ff: ff: ff: ff: ff. Pour tester cette faille, si vous envoyez un paquet avec une adresse MAC de ff: 00: 00: 00: 00: 00 et l'adresse IP de destination correcte de l'hôte. Après avoir reçu un paquet, le système d'exploitation Microsoft utilisant le pilote défectueux répondra en mode promiscuité. Cela se produit probablement avec le pilote MS par défaut.

test Ether Ping - Dans les noyaux Linux plus anciens lorsqu'une carte réseau est placée en mode promiscuous, chaque paquet est transmis au système d'exploitation. Certains noyaux Linux n'ont regardé que l'adresse IP dans les paquets pour déterminer s'ils devaient être traités ou non. Pour tester cette faille, vous devez envoyer un paquet avec une adresse MAC fausse et une adresse IP valide. Les noyaux Linux vulnérables avec leurs cartes réseau en mode promiscuité ne regardent que l'adresse IP valide. Pour obtenir une réponse, un message de demande d'écho ICMP est envoyé dans le faux paquet conduisant les hôtes vulnérables en mode promiscuité à répondre.

Il y en a peut-être plus, le test DNS pour moi est le plus fiable

33
VP.

@vp a donné la théorie, je vais vous donner quelques outils.

Pour une utilisation dans les systèmes Linux:

  • SniffDet: Celui-ci utilise 4 tests différents: test ICMP, test ARP; Test DNS et également un test LATENCY (que VP01 n'a pas mentionné). L'outil a été récemment mis à jour et je le recommande.

Aussi:

  • nmap: Il existe un script NSE pour nmap appelé sniffer-detect.nse qui fait exactement cela.
  • nast : Il détecte les autres PC en mode promiscuité en effectuant le test ARP.
  • ptool : Teste ARP et ICMP. Dernier commit était en 2009 .

Pour les systèmes Windows:

  • Cain & Abel peut faire un scan à grande vitesse en utilisant de nombreux types de tests ARP.
  • Promqry et PromqryUI Les outils Microsoft à cet effet aussi, mais je ne sais pas vraiment comment ils fonctionnent.

Quant aux techniques de détection générales, il en existe une autre, appelée détection de pot de miel. Des détails sur le test de latence et la technique du pot de miel peuvent être trouvés dans documentation de sniffdet.

25
john

Vous ne pouvez pas garantir que vous serez en mesure de le détecter.

Par exemple, vous pouvez facilement créer un câble Ethernet en lecture seule en bouclant le TX + (broche 1) et TX broche 2) de l'ordinateur renifleur, puis réglez TX + (broche 1) sur RX + (broche 3 du renifleur) et TX- (broche 2) à RX- (broche 6 du renifleur). Il sera alors impossible pour l'ordinateur reniflant d'affecter tout trafic de données sur le réseau.

Il peut être possible de détecter une chute de tension ou des émissions RF (le long de --- (phreaking Van Eck ), mais je ne connais aucun matériel COTS qui le détecter.

15
Jon Bringhurst

Bien qu'il ne soit pas toujours possible d'identifier si le réseau local renifle de manière promiscuité le trafic du réseau local - il peut être possible de faire planter la plupart ou toutes les applications de capture de paquets en le faisant.

Consultez le script http://samy.pl/killmon.pl de Samy pour un point de départ. Sachez que la plupart des applications fonctionnant en 2011 sont vulnérables à au moins une attaque par crash DoS, même si le crash n'est pas vulnérable en tant que violation d'accès à la mémoire (ou exception en lecture/écriture qui entraîne un débordement de tampon).

2
atdre

Je crois qu'il existe un outil qui détecte cela de manière fiable en examinant la différence de temps de réponse ping. L'outil envoie des pings et envoie en même temps un grand nombre de pings à la même adresse IP mais avec des adresses MAC différentes.

L'outil fonctionne parce que les cartes en mode promiscuité renverront tout le trafic vers le CPU, donc quand il y a beaucoup de paquets frappant le CPU, cela ralentira la réponse aux pings authentiques. Une carte en mode normal ignorerait tous les paquets avec des adresses MAC différentes, il n'y aurait donc aucune différence dans le temps de réponse.

Quelqu'un insère le nom de l'outil

2
Stuart