Partager via

Catégorisation des fournisseurs de services et des applications en couches

  • Article

Remarque

Les fournisseurs de service en couche sont déconseillés. À compter de Windows 8 et Windows Server 2012, utilisez la Plateforme de filtrage Windows.

 

Winsock 2 prend en charge les protocoles en couches. Un protocole en couches est celui qui met en œuvre uniquement des fonctions de communication de niveau supérieur, tout en s’appuyant sur une pile de transport sous-jacente pour l’échange réel de données avec un point de terminaison distant. Un exemple de protocole en couches ou de fournisseur de services en couches serait une couche de sécurité qui ajoute le protocole au processus d’établissement de connexion afin d’effectuer l’authentification et d’établir un schéma de chiffrement mutuellement convenu. Un tel protocole de sécurité nécessite généralement les services d’un protocole de transport fiable sous-jacent tel que TCP ou SPX. Le terme « protocole de base mis en œuvre par le fournisseur de base » fait référence à un fournisseur Winsock qui met en œuvre un protocole tel que TCP ou SPX capable d’effectuer des communications de données avec un point de terminaison distant. Le terme protocole en couches est utilisé pour décrire un protocole qui ne peut pas être autonome. Ces protocoles en couches sont installés en tant que fournisseurs de services de couche (LSP) Winsock.

Un des exemples de LSP est le fournisseur de service client de pare-feu Microsoft installé dans le cadre du serveur ISA (Internet Security and Authentication Server) sur les clients. Le fournisseur de services Client de pare-feu Microsoft s’installe par-dessus les fournisseurs de base Winsock pour TCP et UDP. Une bibliothèque de liens dynamiques (DLL) dans le logiciel client de pare-feu ISA devient un fournisseur de services en couches Winsock que toutes les applications Winsock utilisent de manière transparente. Ainsi, le LSP du client de pare-feu ISA peut intercepter les appels de fonctions Winsock à partir d’applications clientes, puis acheminer une requête vers le fournisseur de services de base sous-jacent d’origine si la destination est locale ou vers le service de pare-feu sur un ordinateur ISA Server si la destination est distante. Un LSP similaire est installé dans le cadre du service Microsoft Forefront Firewall et du client Threat Management Gateway (TMG) sur les clients.

Pendant l’initialisation du LSP, celui-ci doit fournir des pointeurs vers un certain nombre de fonctions de l’interface SPI Winsock. Ces fonctions seront appelées pendant le traitement normal par la couche directement au-dessus du LSP (un autre LSP ou Ws2_32.DLL).

Il est possible de définir des catégories LSP en fonction du sous-ensemble de fonctions SPI qu’un LSP met en œuvre et de la nature du traitement supplémentaire effectué pour chacune de ces fonctions. En classifiant les LSP, ainsi qu’en classifiant les applications qui utilisent des sockets Winsock, il devient possible de déterminer de manière sélective si un LSP doit être impliqué dans un processus donné au moment de l’exécution.

Sur Windows Vista et versions ultérieures, une nouvelle méthode est fournie pour catégoriser à la fois les fournisseurs de services en couches Winsock et les applications, de sorte que seuls certains LSP seront chargés. Il existe plusieurs raisons d’ajouter ces fonctionnalités.

L’une des principales raisons est que certains processus critiques du système tels que winlogon et lsass créent des sockets, mais ces processus n’utilisent pas ces sockets pour envoyer du trafic sur le réseau. La plupart des LSP ne doivent donc pas être chargés dans ces processus. Un certain nombre de cas ont également été documentés où des LSP défectueux peuvent provoquer le blocage de lsass.exe. Si lsass se bloque, le système force un arrêt. Un effet secondaire de ces processus système chargeant des LSP est que ces processus ne se terminent jamais. Ainsi, lorsqu’un LSP est installé ou supprimé, un redémarrage est nécessaire.

Une autre raison est qu’il existe certains cas où les applications ne souhaitent peut-être pas charger certains LSP. Par exemple, certaines applications peuvent ne pas vouloir charger des LSP de chiffrement qui peuvent empêcher l’application de communiquer avec d’autres systèmes qui n’ont pas installé le LSP de chiffrement.

Enfin, les catégories LSP peuvent être utilisées par d’autres LSP pour déterminer où, dans la chaîne de protocole Winsock, ils doivent s’installer eux-mêmes. Depuis des années, différents développeurs LSP ont voulu savoir comment un LSP se comportera. Par exemple, un LSP qui inspecte le flux de données doit être au-dessus d’un LSP qui chiffre les données. Bien sûr, cette méthode de catégorisation des LSP n’est pas infaillible car elle repose sur le fait que les LSP tiers se catégorisent correctement eux-mêmes.

La catégorisation des LSP et d’autres améliorations de sécurité dans Windows Vista et versions ultérieures sont conçues pour empêcher les utilisateurs d’installer involontairement des LSP malveillants.

Catégories de LSP

Sur Windows Vista et versions ultérieures, un LSP peut être catégorisé en fonction de sa manière d'interagir avec les appels et données de Windows Sockets. Une catégorie de LSP est un groupe identifiable de comportements sur un sous-ensemble de fonctions WINSock SPI. Par exemple, un filtre de contenu HTTP est classé comme inspecteur de données (catégorie LSP_INSPECTOR). La catégorie LSP_INSPECTOR inspecte (mais ne modifie pas) les paramètres des fonctions SPI de transfert de données. Une application peut interroger la catégorie d’un LSP et choisir de ne pas charger le LSP en fonction de la catégorie du LSP et de l’ensemble des catégories LSP autorisées pour l’application.

Le tableau suivant répertorie les catégories dans laquelle un LSP peut être catégorisé.

Catégorie de LSP Description
LSP_CRYPTO_COMPRESS Le LSP est un fournisseur de chiffrement ou de compression de données.
LSP_FIREWALL Le LSP est un fournisseur de pare-feu.
LSP_LOCAL_CACHE Le LSP est un fournisseur de cache local.
LSP_INBOUND_MODIFY Le LSP modifie les données entrantes.
LSP_INSPECTOR Le LSP inspecte ou filtre les données.
LSP_OUTBOUND_MODIFY Le LSP modifie les données sortantes.
LSP_PROXY Le LSP agit en tant que proxy et redirige les paquets.
LSP_REDIRECTOR Le LSP est un redirecteur de réseau.
LSP_SYSTEM Le LSP est acceptable pour une utilisation dans les services et les processus système.

 

Un LSP peut appartenir à plusieurs catégories. Par exemple, un LSP de sécurité/pare-feu peut appartenir aux catégories d’inspecteur (LSP_INSPECTOR) et de pare-feu (LSP_FIREWALL).

Si un LSP n'a pas de catégorie définie, il est considéré comme appartenant à la catégorie « Tous les autres ». Cette catégorie de LSP ne sera pas chargée dans les services ou les processus système (par exemple, lsass, winlogon et de nombreux processus svchost).

Catégorisation des LSP

Plusieurs nouvelles fonctions sont disponibles sur Windows Vista et versions ultérieures pour catégoriser un LSP :

Pour catégoriser un LSP, la fonction WSCSetProviderInfo ou WSCSetProviderInfo32 est appelée avec un GUID pour identifier l’entrée masquée du LSP, la classe d’informations à définir pour cette entrée de protocole LSP et un ensemble d’indicateurs utilisés pour modifier le comportement de la fonction.

La fonction WSCGetProviderInfo ou WSCGetProviderInfo32 est également utilisée pour récupérer les données associées à une classe d’informations pour un LSP.

Catégorisation des applications

Plusieurs nouvelles fonctions sont disponibles sur Windows Vista et versions ultérieures pour catégoriser une application :

Pour catégoriser une application, la fonction WSCSetApplicationCategory est appelée avec le chemin de chargement de l’image exécutable pour identifier l’application, les arguments de ligne de commande utilisés lors du démarrage de l’application et les catégories LSP autorisées pour toutes les instances de cette application.

La fonction WSCGetApplicationCategory est également utilisée pour récupérer les catégories de fournisseur de services en couches associées à une application.

Détermination des LSP qui sont chargés

La dernière partie de la catégorisation des LSP détermine quels LSP seront chargés dans quels processus. Lorsqu’un processus charge Winsock, les comparaisons suivantes sont effectuées entre la catégorie d’application et les catégories LSP pour tous les LSP installés :

  • Si l’application n’est pas catégorisée, autorisez le chargement de tous les LSP dans le processus.
  • Si l’application et le LSP ont attribué des catégories, toutes les valeurs suivantes doivent être remplies :
    Au moins une des catégories de LSP est présente dans les catégories spécifiées de l’application.
    Seules les catégories spécifiées dans les catégories spécifiées de l’application sont spécifiées dans les catégories des LSP. Par exemple, si l’application spécifie une catégorie, elle doit se trouver dans la catégorie du LSP.
    Si la catégorie LSP_SYSTEM est présente dans la catégorie de l’application, elle doit être présente dans les catégories du LSP.

Remarque

Si un LSP n’est pas catégorisé, sa catégorie est effectivement égale à zéro. Pour qu’une correspondance se produise, toutes les catégories spécifiées par le LSP doivent être présentes dans les catégories de l’application (les catégories de l’application doivent être un surensemble des catégories du LSP), avec la réserve que si LSP_SYSTEM est présent dans la catégorie de l’application, il doit également être présent dans la catégorie du LSP.

 

Prenons l’exemple suivant :

L’application Foo.exe est catégorisée comme LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS. L’application Bar.exe est catégorisée comme LSP_FIREWALL + LSP_CRYPTO_COMPRESS. Quatre LSP sont installés sur le système :

  • LSP1 a défini une catégorie de LSP_SYSTEM.
  • LSP2 n'a pas de catégorie définie, donc sa catégorie est zéro.
  • LSP3 a défini une catégorie de LSP_FIREWALL.
  • LSP4 a défini des catégories de LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS + LSP_INSPECTOR

Dans cet exemple, l’application Foo.exe charge uniquement LSP1, tandis que l’application Bar.exe charge LSP3.

Détermination des fournisseurs Winsock installés

Le Kit de développement logiciel (SDK) Microsoft Windows inclut un exemple de programme Winsock qui peut être utilisé pour déterminer les fournisseurs de transport Winsock installés sur un ordinateur local. Par défaut, le code source de cet exemple Winsock est installé dans le répertoire suivant du Kit de développement logiciel (SDK) Windows pour Windows 7 :

C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\NetDs\winsock\LSP

Cet exemple est un utilitaire permettant d’installer et de tester des fournisseurs de services en couches. Toutefois, il peut également être utilisé pour collecter par programmation des informations détaillées à partir du catalogue Winsock sur un ordinateur local. Pour répertorier tous les fournisseurs Winsock actuels, y compris les fournisseurs de base et les fournisseurs de services en couche, générez cet exemple Winsock et exécutez la commande de console suivante :

instlsp -p

La sortie sera une liste de fournisseurs Winsock installés sur l’ordinateur local, y compris les fournisseurs de services en couches. La sortie répertorie l’ID du catalogue et le nom de chaîne du fournisseur Winsock

Pour collecter des informations plus détaillées sur tous les fournisseurs Winsock, exécutez la commande de console suivante :

instlsp -p -v

La sortie sera une liste de structures WSAPROTOCOL_INFO prises en charge sur l’ordinateur local.

Pour obtenir la liste des seuls fournisseurs de services en couches installés sur l’ordinateur local, exécutez la commande console suivante :

instlsp -l

Pour afficher sur la carte la structure du LSP, exécutez la commande de console suivante :

instlsp -m

Remarque

La fonctionnalité TDI est déconseillée et sera supprimée dans les futures versions de Microsoft Windows. Selon la façon dont vous utilisez TDI, utilisez soit le Noyau Winsock (WSK), soit la Plateforme de filtrage Windows (WFP). Pour plus d’informations sur les WFP et WSK, consultez la Plateforme de filtrage Windows et le Noyau Winsock. Pour consulter un article de blog sur le réseau principal de Windows (Core Networking) concernant WSK et TDI, accédez à Présentation du Noyau Winsock (WSK).