Centralisation des évènements avec les outils natif de Microsoft

Dans l’arsenal de la cybersécurité et de l’administration système, la centralisation des journaux d’événements est souvent perçue comme un mal nécessaire : complexe, lourde et difficile à maintenir. Bien souvent, le premier réflexe consiste à se tourner vers des solutions tierces ou à installer des agents propriétaires (Splunk, Winlogbeat, NXLog…) sur chaque serveur et poste de travail.

Pourtant, une solution robuste, performante et entièrement native existe au cœur de l’écosystème Windows depuis des années : le couple WEC (Windows Event Collector) et WEF (Windows Event Forwarding).

Dans cet article, nous expliquons comment notre équipe a simplifié et fiabilisé la gestion des journaux d’un client en s’appuyant exclusivement sur les outils fournis par Microsoft.

Notre client disposait d’une infrastructure Windows composée d’une cinquantaine de serveurs et de postes de travail. Son objectif était clair : centraliser les journaux Windows sans déployer d’agents tiers, afin de :

• améliorer la visibilité sur son système d’information
• renforcer ses capacités de détection d’incidents
• collecter les événements critiques sur un serveur existant
• tout en maîtrisant les coûts et la complexité opérationnelle

La réponse apportée a consisté à mettre en œuvre Windows Event Forwarding (WEF) couplé à un Windows Event Collector (WEC) comme point central de collecte.

WEC – « Windows Event Collector » – du service du même nom (ou « Collecteur d’évènements de Windows » en français) et qui a pour nom court WECSvc : il remplit une fonction de centralisation des évènements du SI en collectant les évènements journalisés par les systèmes. Le service WECSvc est ainsi exécuté sur un ou plusieurs serveurs de collecte.

WEF – « Windows Event Forwarding » – porté par le service « Windows Event Log » (ou « Journal d’évènements de Windows » en français) qui a pour nom court EventLog : il transfère les évènements aux serveurs de collecte configurés. Chaque système du SI, qu’il soit un poste de travail ou un serveur, est donc considéré comme un client WEF dès lors qu’il transfère ses évènements à un ou plusieurs serveurs WEC.

Avant toute mise en place, il est essentiel de prendre du recul sur l’architecture du SI. Une mauvaise préparation peut entraîner une surcharge du serveur collecteur, une saturation réseau ou la collecte de données inutiles.

La structure du système d’information conditionne la stratégie de collecte :

• Répartition géographique : les machines sont-elles centralisées ou réparties sur plusieurs sites ?
• Capacité réseau : les journaux représentent un flux continu qu’il faut anticiper, notamment sur les liens inter-sites
• Synchronisation horaire : un point critique. Tous les systèmes doivent être synchronisés via une source NTP fiable afin de garantir la cohérence des événements et le bon fonctionnement de l’authentification.

Le service WEC est fiable, mais il doit être correctement dimensionné :

• Volume d’événements générés chaque jour
• Nombre de machines sources
• Tolérance aux pannes : il est possible de déployer plusieurs collecteurs et de répartir la charge afin d’éviter toute perte de journaux en cas d’incident

Cette approche permet également d’assurer une continuité de service sans point de défaillance unique.

Avant de collecter, encore faut-il produire des événements pertinents :

• Activation des journaux critiques : Par défaut, Windows ne logue pas tout (ex: lignes de commande PowerShell, accès aux fichiers). Il faut configurer vos politiques d'audit via GPO pour générer les événements qui ont une réelle valeur de sécurité.
• Stockage local et rotation : Si le collecteur est indisponible, les événements attendent dans le journal local de la source. Assurez-vous que la taille maximale de vos journaux locaux (Security, System, etc.) est suffisante pour ne pas écraser les données avant qu'elles ne soient expédiées.

Les journaux contiennent des informations sensibles :

• Chiffrement : Privilégiez le HTTPS (port 5986) pour les équipements qui ne sont pas membres de l’AD au lieu du HTTP (port 5985) pour chiffrer les échanges WinRM.

À noter que, le trafic réseau échangé par WinRM est encapsulé dans le protocole HTTP, dont le mécanisme de chiffrement TLS n’est pas activé par défaut. Il est néanmoins à noter que l’authentification des ordinateurs auprès des contrôleurs de domaine de l’AD aboutit à la génération de clés de session qui sont uniques entre chaque client et chaque serveur collecteur d’évènements. Ces clés de session sont réutilisées pour assurer la confidentialité, l’intégrité et l’authentification du trafic réseau échangé par WinRM, sans recourir à TLS. Ce fonctionnement apporte donc nativement une authentification mutuelle et permet d’assurer un transfert fiable et sécurisé des évènements.

• Authentification : selon le contexte, les échanges reposent sur Kerberos (environnement Active Directory) ou sur des certificats.

Il existe deux modes de collections des journaux d’évènements :

• PUSH : concerne les cas où les évènements sont poussés par les systèmes clients vers les serveurs de collecte. Les flux réseau sont donc initiés par les clients et à destination des serveurs de collecte selon une fréquence définie. (préférable)
  • Suppression du besoin de comptes privilégiés sur tous les endpoints
  • Une gestion efficace des machines hors tension
  • Une réduction de la surface d'attaque
  • Absence d'exposition du port WinRM sur les endpoints et serveurs sensibles (Tier-0)

• PULL : concerne les cas où ce sont les serveurs de collecte qui vont chercher les évènements sur les systèmes clients. Les flux réseau sont dans ce cas initiés par les serveurs de collecte à destination des systèmes clients selon une fréquence définie.
  • Nécessite un compte de service disposant des droits de lecture
  • Maintien d’une liste précise de systèmes clients abbonés
  • Connexion échouée si les serveurs ne sont pas en lignes
  • Connexions intempestives sans connaître l’intérêt
  • Service WinRM en écoute sur le réseau

La journalisation Windows enregistre les évènements significatifs. Il est impératif d’activer et de configurer correctement les politiques d’audit pour capturer les informations pertinentes, sans surcharger les systèmes ni manquer de données cruciales.

À la date de rédaction de cette article, les journaux Windows et des services et applications listés dans le tableau suivant présentent une importance pour les activités de détection et d’analyse :

a* Journaux non activés par défaut

b* Cette ligne fait référence à tous les journaux du service «Terminal Services», incluant «LocalSessionManager», «RemoteConnectionManager», etc.

Par défaut, les paramètres de Microsoft pour les journaux d'événements sont plus restrictifs que les recommandations de sécurité modernes.

La taille par défaut varie selon le type de journal et la version du système («20 Mo»), mais elle est généralement bien inférieure aux recommandations de sécurité.

Voici un paramètre recommandé des stratégies de configuration des journaux d’évènements :

a* La désactivation de ce paramètre indique que les nouveaux évènements remplacent les anciens lorsque le fichier journal a atteint sa taille maximale.

La granularité des stratégies d’audit avancées est nécessaire pour mettre en œuvre les recomman- dations de journalisation de l’ANSSI. Pour des questions de maintenabilité, il est recommandé d’appliquer la même stratégie d’audit avancée sur les différentes catégories de systèmes, qu’il s’agisse de postes de travail ou de serveurs membres d’un domaine AD, ou bien de contrôleurs de domaine. Ces recommandations minimales peuvent être étendues si cela s’avère pertinent au regard des objectifs de sécurité fixés sur des systèmes ayant des rôles très spécifiques, comme par exemple sur des systèmes dédiés à l’administration du SI. Il reste néanmoins recommandé de tester toute stratégie d’audit avant sa mise en production, afin de s’assurer que les journaux ne soient pas saturés trop rapidement.

Voici un tableau récapitulatif des recommandations par l’ANSSI concernant les stratégies d’audit à configurer :

a* Attention : sur un contrôleur de domaine AD, il n’est pas recommandé de journaliser les authentifications réussies, sauf de manière exceptionnelle, car cela génère un important volume d’évènements.

b* Il s’agit d’une mauvaise traduction de Microsoft pour «l’ajustement des privilèges d’un jeton d’authentification».

c* Journaliser les réussites est intéressant mais s’avère trop verbeux au regard de la valeur ajoutée de ces évènements.

Le déploiement de ce service a été conçu spécifiquement pour l’architecture du client, avec une utilisation exclusive du mode Push, privilégié pour sa simplicité et son niveau de sécurité.

La figure suivante présente une vue d’ensemble de l’architecture retenue, en mettant en évidence les différentes configurations mises en place pour la collecte des événements Windows, ainsi que les sections de l’article auxquelles elles se rattachent :

La mise en place de la centralisation des événements avec les outils natifs de Microsoft a permis au client de reprendre le contrôle sur son système d’information.

Elle offre désormais :

• une visibilité centralisée sur l’activité des serveurs et postes de travail
• une détection plus rapide des anomalies et incidents
• un diagnostic accéléré en cas de problème ou de panne
• un renforcement réel de la sécurité, sans complexité supplémentaire

En s’appuyant sur une solution native :

• aucun agent à maintenir
• une architecture plus simple et plus fiable
• des coûts et une charge opérationnelle maîtrisés

Cette approche constitue aujourd’hui un socle durable, à la fois pour améliorer le quotidien des équipes IT et pour préparer des démarches de conformité, de supervision ou de sécurité plus avancées pour une intégration plus facile vers un SIEM.