L’essentiel de la collecte centralisée de logs avec WEF et WEC

La semaine dernière, nous avons abordé les essentiels de la journalisation des événements : s’assurer que tous vos systèmes écrivent des journaux sur les événements ou activités importants qui s’y déroulent. Cette semaine, nous aborderons les éléments essentiels de la collecte centralisée de ces journaux d’événements sur un serveur Windows Event Collector (WEC), qui transmet ensuite tous les journaux à Elastic Security.

WEF et WEC

Les versions modernes de Windows intègrent les services de gestion à distance Windows (WinRM) qui implémentent le protocole WS-Management (WSman). Pour compliquer encore les choses, tout cela fait partie de l’instrumentation de gestion Windows (WMI). L’un des composants de WinRM est le service de transfert d’événements Windows (WEF), d’où la nécessité d’activer WinRM et les services associés. WEF peut transférer les journaux d’événements Windows vers un serveur Windows exécutant le service de collecte d’événements Windows (WEC).

Il existe deux modes de transmission :

1. Initiation de la source : Le service WEF se connecte au serveur WEC
2. Collecte initiée : Le service WEC se connecte au service WEF

Les deux utilisent WSman pour transférer les logs et nécessitent que WinRM soit en cours d’exécution.

Il y a plusieurs pièges et obstacles lors de la mise en place du WEF et du WEC. En suivant notre livre de recettes WEC, vous pouvez éviter ces pièges. Cependant, pour une vision plus large avec un contexte plus riche, nous allons les aborder ici, ainsi que la solution proposée dans le livre de recettes.

Fichier log des « événements transférés »

Le système de log des événements Windows utilise des canaux. Ces canaux sont associés à un fichier log qui stocke tous les événements enregistrés dans le canal concerné. Un système Windows est fourni avec un ensemble de canaux prédéfinis, et les applications peuvent ajouter leurs propres canaux en enregistrant de nouveaux « fournisseurs ».

Cela signifie que, dès la sortie de l’emballage, un serveur WEC ne possède que les chaînes d’un serveur Windows normal pour ses propres logs. Alors, où faut-il stocker tous les journaux qui sont transmis au serveur du WEC ? Il y a trois options ; passons-les en revue :

1. Enregistrer sur la chaîne locale correspondant à la chaîne distante (c’est-à-dire que les événements de la chaîne « Security » distante sont enregistrés sur la chaîne « Security » locale du WEC)

.

Pièges :

• Tous vos logs distants sont mélangés à vos logs locaux.
• Le serveur WEC peut envoyer ses propres logs d’événements à ce canal.
• La gestion des logs et le contrôle d’accès sont rendus très difficiles.

2. Stockez tous les logs distants dans le canal local « Événements transférés ».

Pièges :

• Performances d’écriture médiocres, car toutes les écritures se font dans un seul fichier.
• Performances de recherche/lecture médiocres, car les événements ne sont pas répartis dans des fichiers séparés.
• Mauvaise gestion du cycle de vie des données, car celle-ci est effectuée par fichier log. Par conséquent, tous les événements transférés sont traités de la même manière.
• Mauvaise utilisation des ressources du serveur WEC, car tout le travail est concentré sur un seul fichier.
• Une mauvaise gestion des accès, la séparation des fichiers permettrait des contrôles d’accès différenciés.
• Couverture/visibilité insuffisante : en raison des problèmes mentionnés ci-dessus, de nombreuses solutions limitent fortement les logs d’événements transmis, ce qui crée des lacunes dans leur visibilité.

3. Créez de nouveaux canaux pour le serveur WEC. 

Ce n’est pas aussi évident que cela puisse paraître, et la plupart seraient pardonnés de ne pas savoir que c’était une possibilité. 

De nombreux serveurs WEC ont été configurés avec les options 1 ou 2 (ci-dessus), jusqu’à ce que l’équipe de Security interne de Microsoft écrive un article (il y a environ 15 ans) sur la façon dont ils le SDK Windows a été utilisé pour implémenter l’option 3. Voici une révision similaire publiée en 2016.

Nouvelles chaînes d’événements du WEC

Dotées de la possibilité de créer des chaînes d’événements arbitraires, que devons-nous créer ? Comment organiser et concevoir le serveur WEC ? Il existe de nombreuses écoles de pensée. Le livre de recettes du WEC regroupe les actifs de l’entreprise afin que vous puissiez gérer le contrôle d’accès et le cycle de vie des données de votre log en conséquence.

Avant d’aller plus loin, examinons une autre approche. Certains d’entre vous connaissent peut-être l’architecture et les recommandations WEC de Palantir. Palantir crée un canal par type de log d’événements : PowerShell, WMI, DNS, pare-feu, etc. Ces canaux regroupent les logs de tous les types de ressources (contrôleurs de domaine, serveurs de domaine, postes de travail de domaine) et des départements, unités métier ou unités d’organisation. Ils ne sont pas organisés hiérarchiquement ; ils apparaissent donc sous forme d’une longue liste dans l’Observateur d’événements. Chaque canal possède son propre abonnement WEC. Palantir propose également une politique d’audit recommandée. 

Je tiens à souligner d’autres approches, comme celle de Palantir, car il n’existe pas de solution universelle et leur approche pourrait mieux convenir à votre organisation que celle présentée dans notre livre de recettes.

Si vous avez consulté la liste des canaux de Palantir, vous aurez remarqué le format « WEC#-Quelque chose », où le numéro « # » augmente tous les sept canaux. En effet, dans le système de journalisation des événements Windows, les canaux sont définis par un « fournisseur » et celui-ci ne peut définir que huit canaux au maximum.

Cependant, un bug dans l’outil « ecmangen » que nous, les développeurs de sécurité non-Windows-SDK, utilisions, rendait difficule d’y avoir plus de sept canaux par fournisseur.

Au lieu de corriger les nombreux bugs, il semblerait que Microsoft ait retiré ecmangen du SDK Windows. Vous devez donc soit utiliser un SDK plus ancien, soit créer vous-même le fichier XML Manifest, par exemple avec votre éditeur XML préféré.

Comme tout le monde, j’ai utilisé ecmangen (à l’origine) et je me suis limité à sept canaux pour faciliter la vie. Le Cookbook actuel est basé sur des scripts PowerShell qui génèrent le XML. Ecmangen n’est plus nécessaire, donc vous pouvez avoir huit canaux si vous le souhaitez, même si le Cookbook utilise toujours seulement sept canaux recommandés.

Remarque : considérez un fournisseur comme une boîte de huit canaux, chaque canal étant en fin de compte un fichier log distinct.

Organiser par ressource

Puisque vous pouvez avoir autant de fournisseurs que vous le souhaitez, nous pouvons organiser les ressources par type. Dans votre environnement Active Directory, vous avez probablement déjà regroupé les membres du domaine par type de ressource (par exemple, serveurs de domaine, contrôleurs de domaine, postes de travail, etc.) et/ou par service (voire unité organisationnelle) auquel ces ressources appartiennent.

Ainsi, dans le Cookbook , vous pouvez facilement créer des fournisseurs adaptés à l’organisation de votre AD, dans le sens des fournisseurs par département (unité d’affaires ou OU) et/ou par type d’actif et/ou par critique d’actif (laboratoire/test/production).

Lorsque vous séparez par type d’actif, vous bénéficiez de l’avantage supplémentaire de mieux gérer le contrôle d’accès et le cycle de vie des logs. Si vous devez consulter les logs d’un type d’actif spécifique, vous savez où ils se trouvent.

Pour simplifier, tous les fournisseurs reçoivent le même ensemble de canaux (jusqu’à huit). Ensuite, les systèmes sont associés à un fournisseur (via une unité organisationnelle) et les logs d’événements de ce système Maps sur les canaux de ce fournisseur.

Le script « wec_config.ps1 » utilisé pour configurer le serveur WEC en fonction de votre architecture AD est prêt à l’emploi et contient déjà certains fournisseurs et affectations de ressources définis :

• Contrôleurs de domaine : l’attribution des membres me semble claire ici.
• Serveurs de domaine : Les serveurs de votre domaine
• Clients du domaine : postes de travail des utilisateurs (ordinateurs de bureau/portables)
• Privilèges de domaine : Systèmes plus privilégiés (par exemple, serveurs de rebond ou serveur WEC)
• Membres du domaine : Catégorie fourre-tout pour les membres normaux du domaine ; n’appartenant pas aux autres groupes
• Domaine divers : Divers, pour les hôtes qui ne correspondent pas.

Nous vous encourageons à affiner et à modifier la liste afin qu’elle corresponde à votre environnement Active Directory.

Ensuite, la liste des chaînes prête à l’emploi est la suivante :

• Application : « Application » et logs du même type
• Sécurité : « Security » et logs du même type
• Sysmon : « Microsoft-Windows-Sysmon/Operational »
• Système : « System », « HardwareEvents », client DNS, client DHCP, « Configuration » et logs du même type
• Script : « Windows PowerShell » et logs du même type
• Service : serveur DNS, serveur DHCP et autres logs de service
• Missus C : Tous les autres logs divers

Encore une fois, vous êtes libre de le modifier en fonction de vos besoins.

Abonnements WEC

Un abonnement WEC définit les éléments suivants :

• Filtre de journal d’événements (XPath) permettant de sélectionner les événements à transférer.
• Un canal de destination indiquant où stocker les événements reçus sur le serveur WEC
• Type :
  • À l’initiative du collecteur, le WEC se connecte au service WEF
    • Ordinateurs cibles, une liste d’ordinateurs auxquels se connecter
  • À l’initiative de la source, le WEF se connecte au serveur WEC
    • Groupes d’ordinateurs, les groupes AD dont les membres (ordinateurs) peuvent accéder à cet abonnement
• Options de diffusion d’événements permettant de contrôler la bande passante/la latence et/ou HTTP/HTTPS
• Type de format : RenderedText ou simplement le XML de l’événement

Les scripts du guide de configuration (notamment setup_subscriptions.ps1) configurent le format XML des événements. Ces scripts étant beaucoup plus petits, le débit est accru, le volume de journaux stockés augmente, la charge est réduite et la bande passante consommée est moindre. Cependant, si le fournisseur source (sur le système distant) n’est pas enregistré localement sur le système de journalisation des événements du serveur WEC, l’Observateur d’événements ne pourra pas afficher de description textuelle du message dans votre langue. Néanmoins, l’envoi d’événements au format texte rendu est tellement gourmand en ressources qu’il est difficile de le justifier.

J’ai mentionné au début que WEF est une fonction de WinRM. Or, ce composant WinRM s’exécute avec le compte utilisateur « Service réseau » du système local. Par conséquent, WEF ne peut pas lire la plupart des journaux système et votre serveur WEC recevra un message d’événement 111 très générique, sans aucun autre journal. C’est pourquoi ce guide vous explique comment créer une stratégie de groupe (GPO) pour ajouter « Service réseau » au groupe local « Lecteurs de journaux d’événements ».

Comment se fait la configuration de WinRM pour le WEF ? Dans le même GPO que celui mentionné plus haut, nous publions également une URL WSMan qui répertorie tous les abonnements au WEC sur ce serveur. En fait, nous pouvons répertorier plusieurs URL d’abonnements WSMan provenant de plusieurs serveurs WEC, et le service WEF essaiera de toutes les obtenir et de les exécuter, permettant ainsi la redondance des serveurs WEC.

Tous les abonnements ? Je ne veux pas que mon poste de travail envoie les logs d’événements vers les fichiers logs de mon contrôleur de domaine ! Les entrées WSman qui représentent un abonnement ont des permissions de groupe AD appliquées comme configuré dans la configuration d’abonnement. Si l’ordinateur sur lequel WEF fonctionne n’est pas membre d’un groupe AD ayant la permission de lire l’abonnement, il ne peut donc pas obtenir ni exécuter l’abonnement. De même, si vous n’êtes pas prudent et qu’un ordinateur est membre de plus d’un groupe AD par abonnement WEC, vous recevrez plusieurs logs d’événements identiques de ce WEF sur votre WEC !

Groupes informatiques ? Mais je veux cartographier les ordinateurs en fonction de l’OU dans laquelle ils sont placés ! Malheureusement, ce n’est pas ainsi que fonctionnent WEF/WEC/WinRM/WSman. Cependant, le Cookbook fournit un mécanisme pour synchroniser la composition d’un groupe donné avec les emplacements spécifiés de l’OU. Ainsi, vous pouvez faire comme si tout se faisait via

Tout rassembler de OU!

Il y a beaucoup de complexité et d’éléments à bien gérer lors de la configuration de WEF et WEC pour une bonne observabilité ou des cas d’utilisation en sécurité.

N’ayez crainte, notre guide pratique est là, accompagné d’un ensemble de scripts PowerShell pour automatiser la plupart des étapes. Ainsi, les risques d’erreurs sont réduits, les actions sont reproductibles et les erreurs sont donc plus faciles à corriger.

Tout commence par le script wec_config.ps1, que vous pouvez modifier à votre guise. Tous les scripts suivants s’appuieront sur celui-ci. Vous pouvez donc facilement, par exemple, modifier le filtre du journal des événements utilisé pour sélectionner les journaux d’événements à transférer dans wec_config.ps1, puis exécuter à nouveau setup_subscriptions.ps1 pour appliquer la modification.

Jetons un œil à ce que font les scripts (le Cookbook explique beaucoup plus en détail comment les utiliser) :

• wec_config.ps1 - La configuration de votre serveur WEC, sourcée par les autres scripts
• gen_manifest.ps1 - Cela créera le XML Manifest qui décrit tous vos fournisseurs et leurs canaux pour le SDK Windows (plus besoin d’utiliser ecmangen !)
• build_man2dll.ps1 - En prenant votre manifeste, cela construira le DLL du module de sous-système d’événements Windows qui implémente tous vos nouveaux fournisseurs et canaux sur n’importe quel système que vous installez (généralement le serveur WEC)
• install_channels.ps1 - Prend les DLL et le manifeste et les installe sur le système local
• configure_channels.ps1 - Appliquera la configuration du chemin de log et de la taille du log (depuis wec_config.ps1) à tous vos nouveaux canaux installés
• setup_subscriptions.ps1 - Configurera (créera ou reconfigurera) tous les abonnements pour votre fournisseur/chaînes sur le serveur WEC
• map_ou2group.ps1 - Vous voudrez probablement utiliser les unités d’exploitation de vos AD, mais les abonnements WEC sélectionnent les ordinateurs via les groupes AD. Ce script synchronisera l’appartenance de groupes donnés aux ordinateurs sous des OU spécifiées, en utilisant à nouveau la configuration dans wec_config.ps1
• gen_winlogbeat_config.ps1 - La configuration transférée avec Winlogbeat ne sera pas au courant de tous vos canaux d’abonnement WEC supplémentaires, donc cela mettra à jour cette configuration pour vous
• beat_cmd.ps1 - Un script d’aide pour interagir avec les commandes Beat sur PowerShell

Malheureusement, toutes les configurations côté AD, comme les Politiques de Groupe, doivent toujours être faites manuellement — mais le Cookbook propose des guides étape par étape avec captures d’écran. Je pourrais écrire des scénarios pour ça un jour, restez à l’écoute.

Enfin, Winlogbeat doit être configuré pour envoyer tous les journaux WEC à Elastic Security. Le Cookbook vous guidera aussi dans ce domaine.

Conclusion

J’espère qu’après avoir lu cet article, et peut-être le Cookbook lui-même, vous avez une bonne idée des décisions à prendre avant de commencer, ainsi que tous les conseils et outils nécessaires pour créer ce serveur WEC parfait pour votre entreprise.

Maintenant que vous avez mis en place les politiques d’audit appropriées, configuré WEF et configuré un serveur WEC pour transférer les journaux d’événements de votre domaine AD vers Elastic Security, nous verrons dans notre prochain article ce qu’il est possible de faire avec ces données de journal extrêmement importantes et utiles dans Elastic Security.

Si vous débutez avec Elastic Security, vous pouvez découvrir notre dernière version du service Elasticsearch sur Elastic Cloud. Profitez également de notre formation Quick Start pour vous préparer à réussir.

Voir d’autres guides de Cookbook que j’ai écrits : https://ela.st/tjs-cookbook-lib