Savez-vous que vous pouvez surveiller presque toutes les actions dans Windows ? Non, vous n’avez pas besoin d’acheter un logiciel sophistiqué. L’infrastructure surveille les événements tels que le démarrage et l’arrêt des services, la création d’un fichier ou d’un dossier, et bien plus encore, grâce aux événements de Windows Management Instrumentation (WMI).
Les événements de WMI ne sont pas une fonctionnalité spécifique à PowerShell, mais l’un des moyens les plus simples de tirer parti des événements de WMI et de créer des outils pratiques est d’utiliser PowerShell. Dans ce tutoriel étape par étape, vous apprendrez comment profiter des événements de WMI avec PowerShell et acquérir les compétences nécessaires pour construire des outils de surveillance pratiques!
Allons-y!
Prérequis
Vous verrez de nombreuses démonstrations dans ce tutoriel pratique. Si vous souhaitez suivre l’une d’entre elles, assurez-vous de disposer des éléments suivants:
- Windows 7+ ou Windows Server 2012+ – Ce tutoriel utilisera Windows Server 2019.
- Connecté en tant qu’utilisateur du groupe des administrateurs locaux.
- Windows PowerShell 5.1 ou PowerShell 6+ – Ce tutoriel utilisera PowerShell v7.1.2.
Comprendre WMI et CIM
Avant de pouvoir vous plonger dans les événements de WMI, il est important de comprendre l’infrastructure sur laquelle ils sont construits. Bien que ce tutoriel n’approfondisse pas WMI, vous pouvez toujours vous référer à la documentation WMI de Microsoft pour en savoir plus.
WMI et son modèle de données associé, le Common Information Model (CIM), sont des modèles intégrés dans Windows qui stockent presque toutes les informations nécessaires sur le fonctionnement interne de Windows et ce qui s’y exécute.
WMI et CIM sont des outils puissants utilisés par les administrateurs pour gérer Windows à la fois localement et à distance. En utilisant WMI ou CIM, les administrateurs peuvent interroger des informations sur un système Windows telles que les applications installées, l’état des services, les fichiers du système de fichiers et bien plus encore.
WMI et CIM sont utilisés par de nombreuses solutions de surveillance d’entreprise pour collecter des informations sur la santé du système d’exploitation et des applications. Mais vous n’avez pas besoin d’acheter un outil de surveillance coûteux pour exploiter WMI ; vous avez PowerShell !
Commençons par les deux éléments de base, et au fur et à mesure, vous apprendrez les autres éléments nécessaires :
- Classes : Les classes sont les événements et les propriétés auxquels l’application, telle que PowerShell, peut accéder pour lire et mettre à jour des données. Les classes se trouvent à l’intérieur d’un espace de noms.
- Espace de noms : L’espace de noms est un conteneur pour les classes liées à WMI. Pensez-y comme à un dossier « Mes images » qui contient du contenu lié aux images. Il existe plusieurs espaces de noms, et le plus courant est CIMv2, qui contient la plupart des classes du système d’exploitation. Mais tous les espaces de noms sont situés sous le grand espace de noms unique Root.
WMI vs. CIM
WMI et CIM sont tous deux des méthodes pour interagir avec le référentiel d’un système Windows contenant une tonne d’informations et pour travailler avec les événements WMI (plus d’informations à ce sujet plus tard). Mais ces deux méthodes ont quelques différences, principalement dans la façon dont les administrateurs interagissent avec elles à distance.
WMI a commencé avec Windows NT4 et était le moyen original (et unique) d’interagir avec le référentiel. Lorsque vous gérez un système Windows avec WMI, Windows utilise le modèle d’objet de composant distribué (DCOM). DCOM est un protocole distant utilisé par WMI pour exposer les informations contenues dans le référentiel de données d’une machine Windows.
Pour fonctionner sur un réseau, DCOM utilise l’appel de procédure distant (RPC). Pour communiquer sur un réseau, RPC utilise des plages de ports dynamiques, ce qui est parfois un défi pour les pare-feu et les dispositifs de traduction d’adresses réseau (NAT).
Si vous rencontrez des problèmes avec RPC, consultez l’article Tester les connexions RPC avec les ports dynamiques.
Microsoft a décidé de tirer parti de CIM pour offrir une approche plus moderne de l’interaction avec le référentiel de données dans Windows. Au lieu de RPC, CIM utilise WS-MAN (Web-Service for Management), un protocole HTTP beaucoup mieux adapté à la gestion à distance.
Tout au long de cet article et d’autres, les termes WMI et CIM peuvent être utilisés de manière interchangeable. Le référentiel de données avec lequel interagissent ces deux méthodes de gestion est généralement appelé référentiel WMI. Presque tous les termes font référence à WMI, tandis que CIM est généralement mentionné dans les cmdlets PowerShell.
WMI vs. CIM et PowerShell
Vous avez de la chance, car vous avez plusieurs options pour travailler avec WMI et CIM dans PowerShell. PowerShell prend en charge les deux façons d’interagir avec le référentiel de données. Lorsque vous exécutez la commande Get-Command dans PowerShell, vous remarquerez divers cmdlets Wmi tels que Get-WmiObject, Invoke-WmiMethod, Remove-WmiObject, Register-WmiEvent, et Set-WmiInstance.
Si vous utilisez Windows PowerShell 3 ou une version ultérieure (ce que vous devriez faire!), vous verrez également des cmdlets de noms similaires tels que Get-CimInstance, Get-CimClass, et Remove-CimInstance.
Quels cmdlets PowerShell devriez-vous utiliser? La réponse est simple ; les cmdlets CIM. CIM est la nouvelle norme sur laquelle Microsoft se concentre. Les cmdlets WMI ne sont même pas disponibles dans PowerShell Core!
Interrogation WMI : Les bases
Avant de pouvoir accéder aux événements WMI, vous devez comprendre comment interroger WMI avec PowerShell. Interroger les informations du référentiel WMI est l’utilisation la plus courante des données WMI.
Pour interroger les données WMI dans le monde PowerShell, la cmdlet Get-CimInstance est votre alliée. Cette cmdlet offre différentes façons d’interroger les données WMI. Mais, ce tutoriel va se concentrer sur le paramètre Query. Le paramètre Query vous permet de fournir une requête Windows Query Language (WQL) pour interroger WMI.
Par exemple, peut-être souhaitez-vous trouver toutes les instances WMI dans la classe Win32_Service. Tout comme SQL, vous utiliseriez la requête Select * from Win32_Service, comme indiqué ci-dessous. L’astérisque (*) indique à WMI de retourner toutes les propriétés de chaque instance trouvée.
Dans l’exemple ci-dessus, vous avez trouvé toutes les instances de chaque service dans la classe Win32_Service, mais que faire si vous voulez seulement en trouver quelques-unes ? Dans ce cas, vous utiliseriez la clause WHERE. La clause WHERE crée un filtre pour ne retourner que les instances correspondant à une condition spécifique.
La clause WHERE indique à Get-CimInstance de ne renvoyer que les instances où la propriété de l’instance correspond à une valeur spécifique. Par exemple, peut-être souhaitez-vous uniquement trouver les instances de service où la propriété State est Running. Si c’est le cas, vous définiriez la clause WHERE Where State='Running', comme indiqué ci-dessous.
Vous pouvez voir ci-dessous que Get-CimInstance n’a renvoyé que les instances de service où la propriété State était égale à Running.
Événements WMI : Les actions de WMI
WMI contient un vaste répertoire d’informations sur des milliers d’éléments dans Windows. Vous pouvez accéder à ces informations en les interrogeant comme vous l’avez fait précédemment, mais il a aussi une fonctionnalité moins connue ; les événements WMI.
À tout moment dans Windows, des centaines d’événements peuvent se produire. Lorsque vous utilisez diverses fonctionnalités de Windows telles que la création de fichiers, l’arrêt et le démarrage de services, l’installation de logiciels, ou autre, un événement WMI est probablement déclenché.
Pratiquement chaque action effectuée sur Windows peut être exposée via un événement WMI. Lorsqu’une action est effectuée sur Windows, Windows déclenche un événement via son infrastructure interne. Par défaut, vous ne pouvez pas voir ces événements ; ils se produisent en arrière-plan. Pour les voir, vous devez vous y abonner.
Construction d’un script de surveillance de service avec PowerShell
Pour illustrer le fonctionnement des événements WMI, plutôt que de vous ennuyer avec des tonnes d’informations, construisons plutôt un outil utile. Comme les événements WMI se produisent lorsqu’un événement se produit dans Windows, vous pouvez créer des outils de surveillance pratiques en les utilisant.
Peut-être souhaitez-vous écrire un message dans un fichier journal lorsque l’état d’un service Windows change sur un serveur critique. Ensuite, vous pouvez vous abonner aux événements WMI déclenchés par ces actions lorsqu’elles se produisent. Lorsque vous vous abonnez à l’événement et que l’événement se déclenche, vous pouvez effectuer une action comme l’enregistrement dans un fichier, l’envoi d’un e-mail ou tout autre chose que vous pouvez faire avec PowerShell.
Au lieu d’acheter une solution de surveillance coûteuse, un simple script PowerShell peut être un excellent outil de surveillance pour les personnes ayant peu de moyens ! Si vous êtes prêt, ouvrez votre console PowerShell et commençons !
Trouver la classe CIM
Dans WMI, tout comme les instances statiques, les événements sont contenus dans des classes. Ces classes contiennent toutes les données statiques que vous avez interrogées précédemment et où les modifications de ces instances sont déclenchées. Vous pouvez trouver une liste de toutes les classes CIM dans la documentation Microsoft.
Pour trouver toutes les classes CIM, exécutez la commande Get-CimClass sans paramètres. La commande Get-CimClass retourne par défaut toutes les classes dans l’espace de noms ROOT/cimv2. L’espace de noms ROOT/cimv2 est l’espace de noms « principal » où sont stockées presque toutes les classes Windows intéressantes.
Vous pouvez voir ci-dessous, cependant, qu’un grand nombre de classes sont renvoyées.
Peut-être avez-vous fait des recherches et enfin réalisé que les services Windows sont tous stockés dans le Win32_Service. Ainsi, lorsque vous connaissez le nom de la classe, utilisez le paramètre ClassName pour spécifier le nom, comme indiqué ci-dessous.
Recherche des propriétés de la classe CIM
Une fois que vous savez dans quelle classe chercher, vous devez ensuite déterminer quelle propriété examiner. Lorsque la valeur d’une propriété d’instance change (ou qu’une instance entière est créée ou supprimée), un événement se déclenche. Vous devez capturer ce changement d’état. Pour ce faire, vous devez savoir quelle propriété vous souhaitez surveiller.
Pour trouver cette propriété, inspectez la propriété d’objet PowerShell CimClassProperties sur l’instance de classe CIM que vous avez interrogée dans la section précédente.
Remarquez ci-dessous qu’une de ces propriétés est la propriété State.
Maintenant que vous savez quelle classe CIM et quelle propriété vous souhaitez surveiller, il est temps de vous abonner à l’événement WMI!
Création d’un abonnement à un événement WMI : Aperçu global
Créer un abonnement à un événement WMI peut être une tâche confuse si vous n’en avez jamais créé auparavant. Pour vous aider à rester sur la bonne voie, commençons par couvrir l’essentiel avant de nous plonger dans les détails et définissons les étapes de base.
La création d’un abonnement à un événement WMI nécessite quatre étapes approximatives :
- Création de la requête WQL – Tout comme lors de la requête de données statiques, vous devez créer une requête WQL qui correspond au type d’événement WMI que vous souhaitez voir. Cependant, contrairement à la requête de la banque de données, vous devez utiliser quelques composants plus complexes dans la requête, tels que les classes système et la vérification des cycles (nous en parlerons plus tard).
- Création du filtre d’événement – Une fois que vous avez créé la requête WQL, vous devez créer le filtre d’événement. Le filtre d’événement enregistre la requête WQL dans CIM.
- Création du consommateur – Le consommateur définit l’action à prendre lorsque la requête du filtre d’événement détecte un changement dans la classe. Par exemple, chaque fois qu’un état de service démarre, s’arrête, est créé ou supprimé, le consommateur déclenche une action.
- Association du filtre d’événement au consommateur – La liaison qui relie la requête WMI Windows au consommateur. La liaison est ce qui informe le consommateur lorsque le filtre d’événement a trouvé une correspondance.
En rassemblant chacun de ces éléments, vous créez une abonnement.
Création de la requête WQL
A WQL query for a WMI event looks a bit different than performing a simple query with Get-CimInstance. Below you’ll find a typical WMI event query.
Comme la requête WQL peut sembler intimidante au début, décomposons-la et comprenons comment chaque composant fonctionne.
La Classe Système
Dans l’exemple de Get-CimInstance, vous aviez découvert que vous souhaitez être informé lorsqu’un changement est apporté à une instance dans la classe Win32_Service. Vous avez toujours besoin de cette classe, mais au lieu d’une requête WQL qui ressemble à ceci:
Au lieu de cela, la requête commencera comme suit. La classe principale que vous interrogez n’est pas la classe qui contient l’instance sur laquelle vous souhaitez être notifié. Au lieu de cela, la classe est une classe système.
Les classes système sont des classes internes qui représentent le type de changement que l’événement entraîne. Un événement WMI a quatre types de classes système :
- InstanceModificationEvent – Vérifie les modifications de valeur de propriété sur une instance dans une classe. C’est cette classe que vous utiliserez car vous souhaitez surveiller une valeur de propriété
Statussur une instance (service) de la classeWin32_Service. - InstanceCreationEvent – Vérifie les nouvelles instances. Par exemple, si vous souhaitez surveiller la création de nouveaux services, vous utiliserez cette classe système.
- InstanceDeletionEvent – Vérifie les instances supprimées. Par exemple, si vous souhaitez surveiller la suppression de services, vous utiliserez cette classe système.
- InstanceOperationEvent – Cette classe système vérifie tous les types d’événements, modification, création et suppression.
Pour notre script de surveillance, le début de la requête WQL ressemblera à ce qui suit :
Les noms de classe système WMI commencent toujours par deux tirets bas (__) suivis du nom de la classe.
Le Cycle de Vérification
Ensuite, vous avez le cycle de vérification. Le cycle de vérification inclut le mot-clé within et une valeur représentant un intervalle de sondage exprimé en secondes.
Les événements WMI ne sont pas en temps réel, donc vous devez définir un intervalle spécifique pour que votre abonnement vérifie les changements. Si, par exemple, vous définissez le cycle de vérification à 10, l’abonnement vérifiera un changement depuis le dernier cycle de sondage toutes les 10 secondes. Si un changement est détecté, il déclenche le consommateur.
Si une instance est modifiée, créée ou supprimée en fonction de la classe système dans l’intervalle de sondage, le changement ne sera pas détecté! Considérez la fréquence dont vous avez besoin, mais assurez-vous qu’elle est adaptée au processeur et à la mémoire!
Pour l’exemple de surveillance de service du tutoriel, définissons le cycle de vérification à 10 pour sonder WMI toutes les 10 secondes pour un changement dans un service Windows. La requête WQL devient complexe!
Le Filtre
Enfin, pour compléter la requête WQL, vous devez définir un filtre pour limiter les instances renvoyées de la classe système. Vous devez définir ce filtre dans le formulaire ci-dessous. Dans ce cas, la classe CIM que vous souhaitez surveiller s’appelle la TargetInstance.
ISAest un opérateur qui applique une requête aux sous-classes d’une classe spécifiée.
Étant donné que le tutoriel construit un abonnement pour surveiller les services Windows, vous créez le filtre comme ci-dessous:
Tel quel, le filtre recherche toutes les instances de Win32_Service. Si vous souhaitez surveiller uniquement une propriété, peut-être un service spécifique, vous utiliserez l’opérateur AND.
Les opérateurs AND ou OR ajoutent d’autres conditions pour obtenir des résultats plus précis.
Le filtre du tutoriel (et l’ensemble de la requête) est maintenant complet comme le montre le code ci-dessous.
Création du filtre d’événements
Maintenant que vous avez le filtre de requête, le reste du processus est beaucoup plus facile à comprendre ! Vous devez maintenant créer le filtre d’événements pour utiliser cette requête. Un filtre d’événements est en fait une autre instance CIM qui fait partie de la classe __EventFilter dans l’espace de noms Root/subscription.
Ci-dessous, vous pouvez voir un extrait de code avec tout ce dont vous avez besoin. Le script ci-dessous attribue la requête WQL à la variable $FilterQuery. Ensuite, il crée une table de hachage contenant chacune des propriétés requises et les valeurs nécessaires pour le filtre d’événements. Ensuite, il exécute la commande New-CimInstance pour créer le filtre d’événements. Enfin, l’objet instance CIM résultant est stocké dans une variable ($CIMFilterInstance) pour une utilisation ultérieure.
L’objet CIM résultant est ensuite stocké dans une variable ($CIMFilterInstance) pour une utilisation ultérieure.
Maintenant, exécutez Get-CimInstance pour vérifier que la nouvelle instance CIM de __EventFilter a été créée.
Création du Consommateur
Ensuite, il est temps de créer le consommateur ou l’action qui se produira lorsque Windows déclenchera l’événement WMI. Lors de la création du consommateur, vous avez plusieurs options en fonction du type d’action que vous souhaitez déclencher.
- ActiveScriptEventConsumer – Exécute un script dans un langage de script arbitraire tel que VBScript.
- CommandLineEventConsumer – Démarre un processus
Assurez-vous que les ACL de l’exécutable sont définies correctement pour empêcher quelqu’un de remplacer le fichier EXE par un binaire malveillant.
- LogFileEventConsumer – Crée un journal texte.
- NTEventLogEventConsumer – Écrit un événement dans le journal des événements Windows.
- SMTPEventConsumer – Envoie un email.
Pour ce tutoriel, utilisons le type de consommateur LogFileEventConsumer pour écrire dans un fichier journal lorsque le service correspondant à la requête WQL est modifié.
Chaque classe de consommateur a ses propres paramètres, donc vérifiez les
CimClassPropertiespour plus de détails sur chaque classe, par exemple(Get-CimClass -ClassName __NTEventLogEventConsumer).CimClassProperties.
Une fois que vous avez créé le consommateur, vérifiez à nouveau son existence avec Get-Ciminstance.
Lier le filtre d’événement et le consommateur ensemble
Enfin, il est temps de terminer cette souscription et de lier le filtre d’événement et le consommateur ensemble ! Comme vous l’avez peut-être deviné, la création de la liaison signifie créer une autre instance CIM. Cette fois, vous devez créer une nouvelle instance dans la classe __FilterToConsumerBinding.
Le fragment de code ci-dessous utilise les deux instances créées précédemment (le filtre et le consommateur) comme une table de hachage qui définit les propriétés nécessaires pour créer une nouvelle instance. Elle est ensuite transmise à New-CimInstance comme précédemment pour créer la liaison.
Comme toujours, confirmez que la liaison a été créée en exécutant à nouveau Get-CimInstance.
Comme vous pouvez le voir, la liaison contient des informations sur à la fois le Filtre et le Consommateur.
Tester la souscription
Vous avez enfin terminé ! Il est temps de tester les fruits de votre travail ! La seule chose que vous devez faire maintenant est de changer l’état du service BITS pour voir si PowerShell écrit une entrée dans le fichier journal à l’emplacement C:\MyCIMMonitoring.txt.
En fonction de l’état du service BITS, arrêtez-le, démarrez-le ou redémarrez-le simplement avec la commande Restart-Service.
Attendez environ 10 secondes et vérifiez le C:\MyCIMMonitoring.txt. Vous devriez maintenant voir le Texte dans le fichier journal que vous avez défini lors de la création du consommateur.
Pour surveiller toutes les activités d’événements WMI, consultez le journal des événements Windows à l’emplacement Applications and Services Log\Microsoft\Windows\WMI-Activity\Operational.
Arrêt et nettoyage de l’abonnement
Une fois que vous avez terminé avec l’abonnement, il est temps de le nettoyer. Pour arrêter et supprimer l’abonnement d’événements WMI, vous devez supprimer le filtre d’événements, le consommateur et les instances de liaison.
Supprimez le filtre d’événements en trouvant d’abord l’instance avec Get-CimInstance.
Ensuite, supprimez le consommateur de la même manière.
Enfin, supprimez la liaison. La propriété pour trouver la liaison est un peu différente. Au lieu de la propriété Name, l’instance de liaison a une propriété Filter qui est en fait un objet avec une propriété Name.
Conclusion
WMI/CIM est un système pratique et puissant pour trouver des informations sur Windows et les surveiller avec des événements WMI. La surveillance des changements avec des événements WMI vous donne une grande visibilité et une réaction plus rapide aux problèmes possibles, ce qui facilite l’automatisation d’une réponse pour chaque événement.
Pour un excellent exemple concret, consultez Comment suivre les modifications de l’Active Directory avec les événements WMI.
Source:
https://adamtheautomator.com/your-goto-guide-for-working-with-windows-wmi-events-and-powershell/