Windows Filtering Plateform

Contrairement à ce que le nom peut laisser à penser, Windows Filtering Plateform (WFP) n’est pas un pare-feu. Il s’agit d’un ensemble de services et d’API utiles pour le développement de pare-feux, par Microsoft ou une autre entreprise. Le pare-feu intégré dans Vista, nommé Windows Firewall et successeur de l’Internet Connection Firewall (ICF) de Windows XP (ou Windows Firewall pour Windows XP SP2), utilisera WFP. Mais WFP n’est pas destiné exclusivement aux applications de Microsoft, contrairement à ce qu’on a pu lire récemment ; tous les éditeurs de solutions de sécurité ont accès à la documentation permettant de se servir de cet outil afin de développer leur propre produit.

Observons comment s’articulent WFP et la pile réseau grâce à l’image ci-dessous :

• Le Generic Filtering Engine est un composant en espace noyau intégré à la nouvelle pile réseau et qui stocke les filtres créés. A la réception d’un paquet, ce composant vérifie, grâce aux filtres et à des modules, si le paquet peut être traité ou au contraire rejeté.
• Les Callout modules sont utilisés par le Generic Filtering Engine à la réception d’un paquet. Ainsi, en plus des règles basiques de filtrage, le flux peut être analysé par un antivirus, par un NAT ou par un logiciel de contrôle parental.
• Le Base Filtering Engine est un composant s’exécutant en espace utilisateur et qui implémente les requêtes demandes de filtrage des applications en connectant les filtres au Generic Filter Engine.
• Les API, placées au dessus du Base Filtering Engine qui permettent aux applications d’utiliser ce moteur de filtrage. Une application peut utiliser WPF de deux façons :
• En implémentant une simple application en espace utilisateur. Ce moyen est préconisé dans le cas où l’application ne fait que filtrer les paquets.
• Dans le cas où l’application doit analyser le paquet en profondeur, Microsoft préconise la création d’une application en espace utilisateur, mais aussi d’un ou plusieurs modules qui effectueront les analyses supplémentaires.

À propos des antivirus

Depuis quelques semaines, on a pu lire que certains éditeurs de solutions de sécurité n’étaient pas du tout convaincus par la Kernel Patch Protection (PatchGuard) puisque leurs produits ont besoin d’avoir un accès à l’espace noyau pour fonctionner. Certains sont même allés jusqu’à considérer que Microsoft essayait de leur nuire en empêchant leurs produits de faire leur travail. Microsoft, de son côté, a toujours assuré que l’accès au noyau était désormais impensable, qu’il avait mis des solutions alternatives en place et que les éditeurs n’avaient pas besoin d’accéder au noyau pour que leurs produits fonctionnent. De là est née la polémique dont nous vous avons parlé sur Presence PC et Infos-du-Net. Microsoft a fini par céder en divulguant les sources du noyau pour la version 64 bits de son système. Mais si Symantec et McAfee continuaient de blâmer l’éditeur jusqu’à très récemment, on peut signaler que d’autres éditeurs de solutions de sécurité, tels Kaspersky, Trend et ALWIL Software, ont développé leur propre solution sans recevoir plus d’aide que les autres.

Dès lors, on peut s’interroger sur les motivations des différents camps. Est-ce une tentative de déstabilisation de la part d’un camp ou une tentative de nuisance de la part de l’autre camp ? Microsoft prépare-t-il le terrain pour sa suite sécuritaire ? Nous n’avons pas toutes les informations pour y répondre, mais vous devez savoir que Microsoft est censé se servir des mêmes API que les autres éditeurs, comme c’est le cas pour son nouveau pare-feu qui utilise WFP.