Windows Event Forwarding à grande échelle

Le socle stratégie d'audit et Sysmon se termine par quatre lignes sur le transfert : exécuter wecutil qc, créer un abonnement, pointer les sources vers le collecteur, accorder l'accès aux journaux. Cela suffit pour un laboratoire. En production, WEF échoue de façon plus discrète : un abonnement qui remonte dix fois plus que prévu, un collecteur qui prend du retard, des contrôleurs de domaine qui ne transfèrent jamais leur journal Sécurité. Ce guide couvre la conception, la configuration et l'exploitation de Windows Event Forwarding pour des milliers d'hôtes.

L'architecture en un paragraphe

Les sources (chaque hôte Windows) exécutent un client de transfert des journaux d'événements qui s'appuie sur le service WinRM. Les collecteurs exécutent le service Windows Event Collector (Wecsvc) et hébergent les abonnements : des requêtes XPath accompagnées de paramètres de livraison. Avec les abonnements initiés par la source, les sources obtiennent l'adresse du collecteur par stratégie de groupe, récupèrent les abonnements qui leur sont destinés et poussent les événements correspondants via WinRM. Les événements collectés arrivent dans ForwardedEvents (ou dans un journal personnalisé), où un agent SIEM les récupère. Le modèle initié par la source est le bon à grande échelle ; les abonnements initiés par le collecteur exigent de lister chaque source individuellement.

Étape 1 : concevoir les abonnements

Regroupez les événements par finalité, pas par journal. Un ensemble type :

Des abonnements petits et ciblés sont plus faciles à dépanner et à dimensionner, et une requête défaillante n'en casse qu'un seul. Appuyez-vous sur la référence des ID d'événements de sécurité pour décider du contenu de chacun.

ForwardedEvents ou journaux personnalisés

Par défaut, chaque abonnement écrit dans ForwardedEvents, un seul journal pour tout. C'est simple, mais un abonnement bruyant peut évincer des événements importants, et l'agent SIEM doit lire un journal très volumineux. L'alternative, ce sont les canaux d'événements personnalisés : une petite DLL de manifeste enregistrée sur le collecteur qui crée des journaux distincts, par exemple un pour Sécurité, un pour Sysmon et un pour PowerShell, chacun avec sa propre taille. Des projets communautaires publient des manifestes de canaux WEF et des jeux d'abonnements prêts à l'emploi que vous pouvez adapter. Les canaux personnalisés ajoutent une étape de construction et de déploiement : commencez donc avec ForwardedEvents et migrez lorsque le volume ou les besoins de rétention l'exigent.

Étape 2 : construire le collecteur

Utilisez des collecteurs dédiés (pas des contrôleurs de domaine), dimensionnés d'abord pour les E/S disque. Sur chaque collecteur :

wecutil qc /q                                        # configure Wecsvc (démarrage automatique différé)
wevtutil sl ForwardedEvents /ms:4294967296           # tampon de 4 Go

Autorisez le trafic entrant TCP 5985 depuis les sous-réseaux des sources dans le pare-feu de l'hôte. Le collecteur est un hôte de journaux à forte valeur ; administrez-le depuis votre tier d'administration et appliquez-lui le durcissement de WinRM comme à n'importe quel autre serveur.

À plus grande échelle, envisagez de donner au service collecteur son propre processus avec sc.exe config Wecsvc type= own, afin qu'il ne partage pas un hôte de service avec WinRM. Microsoft documente les modifications associées des réservations d'URL HTTP pour cette configuration ; suivez les recommandations actuelles sur la montée en charge des collecteurs plutôt que de copier des extraits trouvés sur des forums.

Étape 3 : écrire le XML de l'abonnement

Créez les abonnements à partir de fichiers pour qu'ils vivent dans le contrôle de source. Un abonnement initié par la source pour les ordinateurs du domaine :

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Baseline-Security</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Core security events from all domain computers</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>50</MaxItems>
      <MaxLatencyTime>60000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="3600000"/>
    </PushSettings>
  </Delivery>
  <Query><![CDATA[
    <QueryList>
      <Query Id="0" Path="Security">
        <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4672)]]</Select>
        <Select Path="Security">*[System[(EventID=4688 or EventID=4697 or EventID=4698 or EventID=4720 or EventID=4732)]]</Select>
        <Select Path="Security">*[System[(EventID=1102)]]</Select>
        <Select Path="System">*[System[(EventID=7045 or EventID=104)]]</Select>
      </Query>
    </QueryList>
  ]]></Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>HTTP</TransportName>
  <ContentFormat>RenderedText</ContentFormat>
  <Locale Language="en-US"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers>
  <AllowedSourceDomainComputers>O:NSG:BAD:P(A;;GA;;;DC)S:</AllowedSourceDomainComputers>
</Subscription>

wecutil cs .\Baseline-Security.xml
wecutil gs Baseline-Security          # affiche l'abonnement tel que le collecteur le voit

Les choix clés de ce fichier :

• AllowedSourceDomainComputers est une chaîne SDDL. DC désigne Domain Computers. Pour l'abonnement DC-Security, accordez plutôt le groupe des contrôleurs de domaine, ou le SID d'un groupe AD dédié, afin que chaque abonnement n'atteigne que les hôtes qui lui sont destinés.
• ReadExistingEvents à false signifie que les sources ne transfèrent que les nouveaux événements. Le passer à true sur un nouvel abonnement pousse chaque source à téléverser d'un coup tout son historique correspondant, ce qui peut écraser un collecteur.
• ContentFormat RenderedText inclut le message rendu, attendu par de nombreux analyseurs SIEM ; Events est plus léger car il n'envoie que le XML brut.
• Livraison. Le mode Custom avec un MaxLatencyTime de 60 secondes est un bon réglage par défaut pour les événements de sécurité. Les modes intégrés sont Normal (par lots, jusqu'à 15 minutes), MinLatency (environ 30 secondes) et MinBandwidth (plusieurs heures, pour les liaisons lentes).
• Taille de la requête. Les expressions XPath très longues peuvent échouer à s'appliquer. Répartissez les ID sur plusieurs éléments Select comme ci-dessus, plutôt qu'une énorme chaîne de or.

Étape 4 : configurer les sources par GPO

Sur les sources, sous Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding :

• Configure target Subscription Manager = Enabled, avec Server=http://wec01.corp.example:5985/wsman/SubscriptionManager/WEC,Refresh=60. Utilisez le FQDN du collecteur pour que Kerberos fonctionne. Vous pouvez lister plusieurs serveurs ; chaque source transfère alors vers chaque collecteur listé, ce qui apporte de la redondance mais double le volume.

Assurez-vous ensuite que les sources peuvent réellement lire et envoyer les journaux :

• Service WinRM en cours d'exécution. Le client de transfert en a besoin, même sur les postes de travail sans écouteur WinRM. Réglez Windows Remote Management (WS-Management) sur Automatic sous Security Settings > System Services si votre référentiel le désactive.
• Accès au journal Sécurité. Le client de transfert s'exécute en tant que Network Service, qui ne peut pas lire le journal Sécurité par défaut. Ajoutez soit NT AUTHORITY\NETWORK SERVICE au groupe local Event Log Readers par stratégie de groupe, soit (A;;0x1;;;NS) à la chaîne d'accès du canal Security avec Windows Components > Event Log Service > Security > Configure log access. Les contrôleurs de domaine n'ont pas de groupes locaux : utilisez-y la méthode par chaîne d'accès ou le groupe intégré Event Log Readers du domaine.

Répartissez les sources entre les collecteurs via la portée des GPO, par exemple une GPO par UO ou par site pointant vers un collecteur différent. WEF n'a pas d'équilibreur de charge intégré.

Ce qui casse

• Des événements Sécurité manquants depuis les DC relèvent presque toujours de l'étape d'accès au journal. Vérifiez la chaîne d'accès du canal avec wevtutil gl Security.
• Un mauvais nom de collecteur (nom court ou IP) signifie pas de Kerberos, donc des sources incapables de s'authentifier.
• L'état d'exécution des abonnements dans le registre grossit avec chaque source ; de très gros abonnements uniques ralentissent le démarrage du collecteur. Plus d'abonnements, plus petits, et davantage de collecteurs règlent le problème.
• Le disque du collecteur se remplit si l'agent SIEM cesse de lire. ForwardedEvents est un tampon, pas une archive.
• Des modifications de pare-feu sur les collecteurs ou un service WinRM désactivé sur les sources arrêtent le transfert en silence.

Étape 5 : dimensionner et superviser

Dimensionnez sur le nombre d'événements par seconde, mesuré, pas sur le nombre d'hôtes. Menez un pilote de chaque abonnement sur un groupe représentatif, puis relevez le débit sur le collecteur et dans votre SIEM. Gardez assez de marge pour que le collecteur absorbe les rafales de rattrapage après une panne, quand chaque source envoie son arriéré.

Contrôlez la santé des abonnements depuis le collecteur :

wecutil gr Baseline-Security    # état d'exécution : chaque source, état, dernier heartbeat

Les sources à l'état inactif, ou dont le dernier heartbeat est plus ancien que l'intervalle de heartbeat, demandent votre attention. Sur une source, les erreurs apparaissent dans Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin > Operational, et la connectivité peut être testée avec Test-WSMan wec01.corp.example.

Créez trois alertes dans le SIEM : un collecteur qui cesse d'envoyer, un abonnement dont le nombre de sources chute brutalement, et des hôtes critiques (contrôleurs de domaine, serveurs Tier 0) qui n'ont transféré aucun événement depuis une heure.

Étape 6 : faire entrer les événements dans le SIEM

N'exécutez l'agent de votre SIEM que sur les collecteurs. Pour Microsoft Sentinel, Azure Monitor Agent peut collecter ForwardedEvents via le connecteur de données Windows Forwarded Events. Pour les autres SIEM, pointez leur agent Windows vers le journal ForwardedEvents (ou vers vos journaux personnalisés). La journalisation des règles de pare-feu décrite dans journalisation et supervision du pare-feu et Sysmon, décrit dans déploiement et ajustement de Sysmon, peuvent emprunter la même chaîne.

Vérifier

1. Sur une source : gpresult /r /scope computer affiche la GPO Event Forwarding ; wevtutil gl Security montre l'accès de Network Service.
2. Générez un événement connu, par exemple un échec d'ouverture de session avec un mauvais mot de passe (4625).
3. Sur le collecteur : Get-WinEvent -LogName ForwardedEvents -MaxEvents 20 l'affiche dans la latence configurée.
4. Dans le SIEM : l'événement est consultable avec le bon nom d'hôte et le bon horodatage.
5. wecutil gr liste le nombre attendu de sources actives.

Pour aller plus loin sur l'ensemble de la chaîne de journalisation, voir la page thématique audit et journalisation.

Liste de contrôle

• Abonnements conçus par finalité et stockés en XML dans le contrôle de source
• Collecteurs dédiés et durcis, avec ForwardedEvents dimensionné comme tampon
• Abonnements initiés par la source restreints via AllowedSourceDomainComputers
• ReadExistingEvents à false sur les nouveaux abonnements ; latence de livraison personnalisée définie
• La GPO Target Subscription Manager utilise le FQDN du collecteur
• Service WinRM actif sur les sources ; journal Sécurité lisible par Network Service, y compris sur les DC
• Charge des collecteurs mesurée en événements par seconde, avec une marge pour les arriérés
• Alertes sur la santé des abonnements, le nombre de sources et les hôtes critiques silencieux