risque lié à l'utilisation WinPCAP en place de la prise

Question

Ce que j'ai lu jusqu'à présent, WinPCAP vous permet de contourner l'application du système d'exploitation et by-pass et le traitement de la couche de transport TCP et offre un accès direct à la couche de liaison.

Je prévois d'utiliser winpcap pour faire des trucs application utilisateur et non pas seulement renifler. Je vais recevoir et envoyer des informations critiques en utilisant pcap que je fais actuellement via des sockets.

Est-OS sans passer, et selon ma demande de compréhension et de couches de transport de mon côté, impliquent des risques? Comme une question secondaire, la documentation de winpcap que j'ai trouvé jusqu'à maintenant parle de la façon de l'implémenter par programmation mais ne dit pas en détail ce qu'il contournement et comment il le fait. Tout lien vers cela sera utile.

Aussi, je voudrais savoir si quelqu'un utilise winpcap à des fins autres que le réseau renifler pour des raisons de surveillance et msn.

Answer 1

Bien sûr, il y a beaucoup de risques:

• Le système d'exploitation ne connaîtra pas vos connexions TCP privées gérées, il ne sait que le port (s) que vous avez choisi est/sont en cours d'utilisation. Cela signifie qu'il pourrait essayer d'utiliser le même port pour la connexion d'une autre application, conduisant au chaos.
• Le système d'exploitation ne saura pas sur vos connexions TCP privées gérées, donc à moins que vous l'empêcher de voir ces paquets, il envoie des paquets RST pour réinitialiser la connexion apparemment faux.
• Votre application ne sera pas automatiquement avertie des modifications apportées aux données gérées par le système d'exploitation, aux adresses IP configurées et aux tables de routage. Vous devrez probablement rechercher des mises à jour.
• La mise en œuvre correcte du protocole TCP est non triviale. La plupart des implémentations, même très bien utilisées, avaient des bogues dormants qui n'ont pas été trouvés pour années. Toutes les informations nécessaires ne sont pas non plus dans les RFC; il existe des endroits où la pratique établie diffère du comportement documenté, habituellement pour de bonnes raisons. Il y a aussi beaucoup de code dans les piles TCP modernes spécifiquement pour gérer le comportement buggé historique dans d'autres piles, et la réplication de tout ce travail n'est pas simple.
• Il y a un risque important de mauvaises interactions avec les logiciels de sécurité réseau tiers installé sur l'hôte, qui attendront toutes les connexions TCP à effectuer via le système d'exploitation.

Cela me semble être un cauchemar de soutien.