Quels journaux collecter : Windows, Sysmon, Linux et pfSense

Collecter des journaux avec Wazuh, c'est dire à chaque agent quels fichiers ou canaux d'événements lire (balise <localfile>), et dire au serveur quels équipements sans agent il peut écouter en syslog. Le bon choix part des menaces à détecter : chaque journal collecté doit servir une détection précise, sinon il coûte du stockage, noie les alertes utiles et conserve des données personnelles pour rien. Ce chapitre passe en revue les sources de l'infrastructure de Sorbier, la façon de les brancher sur Wazuh et la grille pour décider.

Partir des menaces, pas des sources

La tentation est de « tout collecter, on verra bien ». C'est une erreur pour trois raisons : un contrôleur de domaine peut écrire des centaines d'événements par seconde, le serveur Wazuh et son disque ne sont pas infinis, et une alerte utile se perd au milieu de milliers d'autres. La bonne méthode tient en trois questions :

1. Que veux-tu détecter ? Une force brute, un compte créé, un script malveillant, un fichier modifié, un flux bloqué.
2. Quel événement en est la trace ? Le 4625 du contrôleur de domaine, le 4720, le 4104, une modification de fichier, une ligne filterlog du pare-feu.
3. Quelle source l'écrit, et faut-il régler quelque chose pour qu'elle l'écrive ? Une stratégie d'audit à activer, une journalisation PowerShell à allumer, Sysmon à installer.

Le cours Réponse à incident détaille ce qu'il faut journaliser en général. Ici, on branche ces journaux sur Wazuh.

Les journaux Windows

Sur Windows, l'agent lit les canaux d'événements (format eventchannel), ceux que tu vois dans l'Observateur d'événements. Sa configuration par défaut en lit trois :

Le journal Sécurité ne contient que ce que la stratégie d'audit demande d'enregistrer. Sur les contrôleurs de domaine, une partie est active par défaut ; sur les serveurs membres et les postes, beaucoup moins. Le cours Windows Server détaille la configuration avancée de la stratégie d'audit par GPO et la liste des événements à connaître. Pour Wazuh, retiens les sous-catégories dont dépendent les détections de ce cours :

Ajouter PowerShell et Sysmon

Deux sources manquent à la configuration par défaut, et ce sont elles qui révèlent un script malveillant.

Le journal PowerShell. Avec la journalisation des blocs de script, Windows enregistre dans l'événement 4104 le code PowerShell réellement exécuté, même quand l'attaquant l'a masqué (encodé en Base64, découpé, téléchargé en mémoire) : c'est le code déchiffré qui est écrit. Active-la par GPO : Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Windows PowerShell > Activer la journalisation de blocs de scripts PowerShell. L'événement arrive dans le canal Microsoft-Windows-PowerShell/Operational.

Sysmon. System Monitor est un service de Microsoft qui enregistre ce que le journal Sécurité voit mal : chaque création de processus avec sa ligne de commande complète, son processus parent et l'empreinte du programme, les connexions réseau de chaque programme, les fichiers créés, les modifications du registre, les requêtes DNS. Sysmon n'analyse rien et ne bloque rien : il produit de la matière pour le SIEM.

Depuis 2026, Sysmon est une fonctionnalité facultative intégrée à Windows 11 et Windows Server 2025, mise à jour par Windows Update. Sur ces systèmes :

Enable-WindowsOptionalFeature -Online -FeatureName Sysmon
sysmon -i C:\Sysmon\sysmonconfig.xml

Sur un système plus ancien, on installe la version autonome, téléchargée depuis le site Sysinternals de Microsoft (Sysmon64.exe -accepteula -i sysmonconfig.xml). Les deux versions ne cohabitent pas : il faut désinstaller la version autonome avant d'activer la version intégrée. Le fichier de configuration décide de ce qui est enregistré ; sans lui, Sysmon est soit muet, soit bavard à l'excès. On part d'une configuration publique et maintenue, comme celles de SwiftOnSecurity (sysmon-config) ou d'Olaf Hartong (sysmon-modular), recommandées par la documentation de Microsoft, puis on l'ajuste.

Une fois PowerShell et Sysmon actifs sur les machines, l'agent doit lire leurs canaux. C'est le rôle du agent.conf du groupe windows-serveurs vu au chapitre 4 :

<agent_config>
  <localfile>
    <location>Microsoft-Windows-PowerShell/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
</agent_config>

Wazuh fournit des règles toutes prêtes pour ces deux canaux : plusieurs dizaines pour les blocs de script PowerShell et plus de quatre-vingts pour les seules créations de processus Sysmon (chapitre 11).

Filtrer un canal. Une balise <query>, en syntaxe XPath, limite ce que l'agent envoie. Pour ne garder, sur les postes, que les ouvertures de session interactives (type 2) et à distance (type 10) :

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event[System/EventID = 4624 and (EventData/Data[@Name='LogonType'] = 2 or EventData/Data[@Name='LogonType'] = 10)]</query>
</localfile>

Deux précautions. Un seul bloc par canal : pour filtrer le canal Sécurité, modifie la requête du bloc existant plutôt que d'en ajouter un second pour le même canal ; l'agent signale alors un journal en double, et ce qui est réellement envoyé devient difficile à prévoir. Ne filtre jamais au point de perdre les événements des tableaux ci-dessus : sur un poste, l'exemple suffit peut-être ; sur un contrôleur de domaine, il serait désastreux.

Les journaux Linux

Sur Debian 13, la plupart des services écrivent dans journald et rsyslog n'est plus installé par défaut : le fichier /var/log/auth.log n'existe pas. Ubuntu 24.04 garde rsyslog et auth.log, mais tout passe aussi par journald. L'agent Wazuh 4.14 lit journald directement, et sa configuration par défaut contient déjà ce bloc :

<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
</localfile>

C'est par là qu'arrivent les connexions SSH (y compris les lignes de sshd-session, le processus qui gère chaque connexion depuis OpenSSH 9.8), les commandes sudo, les ouvertures de session. Les règles de Wazuh reconnaissent ces lignes comme celles de l'ancien auth.log. Un filtre peut restreindre un bloc à une unité systemd, par exemple le seul service SSH :

<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^ssh.service$</filter>
</localfile>

Les fichiers d'une application. Apache écrit toujours ses propres fichiers. Pour srv-web, l'agent.conf du groupe serveurs-web ajoute ses deux journaux, avec le format apache que les décodeurs de Wazuh savent lire :

<agent_config>
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/access.log</location>
  </localfile>
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/error.log</location>
  </localfile>
</agent_config>

Une application qui écrit en JSON (un journal par ligne) se collecte avec <log_format>json</log_format> : chaque clé devient un champ utilisable dans les règles, sans décodeur à écrire. C'est le format à demander aux développeurs de l'application de gestion (chapitre 7 pour le cas où le format est imposé).

Le pare-feu pfSense en syslog

pfSense n'accepte pas d'agent Wazuh : il envoie son journal en syslog. Deux réglages, un de chaque côté (le cours pfSense montre la même chaîne vue du pare-feu : superviser pfSense et envoyer ses journaux à Wazuh).

Côté pfSense (CE 2.8, menus identiques dans pfSense Plus) : Status > System Logs, onglet Settings, section des options de journalisation à distance.

1. Coche Send log messages to remote syslog server.
2. Source Address : l'interface SERVEURS, celle qui porte l'adresse 192.168.10.190, dans le même réseau que srv-journaux. Avec deux pare-feu en grappe CARP, chacun envoie depuis son adresse propre (.188 et .189) : ce sont elles qu'il faut autoriser.
3. IP Protocol : IPv4.
4. Remote log servers : 192.168.10.180:514.
5. Remote Syslog Contents : coche Firewall Events, System Events, General Authentication Events (connexions à l'interface d'administration), VPN Events et DHCP Events (le DHCP de pfSense ne sert que la DMZ et le Wi-Fi invité ; celui des salariés est celui de l'annuaire).
6. Laisse le format des messages sur BSD (RFC 3164), que les décodeurs de Wazuh attendent, et clique sur Save.

Vérifie aussi que le pare-feu journalise ce qui t'intéresse : les paquets rejetés par la règle de blocage par défaut le sont (option cochée d'origine), mais une règle d'autorisation ne journalise que si sa case Log est cochée.

Côté Wazuh, la réception syslog est désactivée tant qu'on ne la déclare pas. Ajoute dans /var/ossec/etc/ossec.conf un second bloc <remote>, à côté de celui des agents (<connection>secure</connection>) qu'il ne faut pas toucher :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.10.190</allowed-ips>
  <local_ip>192.168.10.180</local_ip>
</remote>

sudo systemctl restart wazuh-manager

<allowed-ips> est obligatoire : sans lui, la configuration n'est pas prise en compte. Il limite la réception aux adresses autorisées, ici le seul pare-feu ; pour les switchs, ajoute une ligne <allowed-ips> par adresse ou par réseau (192.168.10.208/28).

Ce que tu verras. Wazuh décode les lignes filterlog de pfSense (adresses, ports, protocole, action). Par choix, un blocage isolé ne crée pas d'alerte (la règle 87701, niveau 5, est marquée pour ne pas être enregistrée) : un pare-feu bloque des milliers de paquets par jour, ce serait du bruit. En revanche, 18 blocages en 45 secondes depuis la même source déclenchent la règle 87702 « Multiple pfSense firewall blocks events from same source », de niveau 10 : un balayage de ports ou une machine infectée qui cherche à sortir.

Les switchs et les bornes. Les équipements Cisco du cours Routage et commutation envoient leur syslog de la même façon (commande logging host), vers 192.168.10.180 : violations de sécurité des ports, interfaces qui tombent, connexions à la console d'administration. Ajoute leur réseau de gestion dans <allowed-ips>.

La grille de décision

Commence par les lignes « Indispensable », vérifie que les alertes arrivent et sont lisibles, puis élargis.

Volume, bruit et RGPD

Le volume. Chaque agent limite son débit (500 événements par seconde par défaut, avec un tampon de 5 000 messages) pour ne pas saturer le réseau ni le serveur. Le serveur, lui, n'enregistre que les alertes, c'est-à-dire les événements qui atteignent le niveau 3. L'archivage de tous les événements reçus (<logall_json>yes</logall_json>) est désactivé par défaut : il multiplie le stockage et ne s'active que pour une enquête ou pour mettre au point une règle, puis se désactive.

Le bruit. Une source qui produit cent fausses alertes par jour finit par être ignorée, et la vraie alerte avec elle. Le chapitre 7 montre comment éteindre un faux positif précis sans aveugler toute une règle.

Le RGPD. Les journaux contiennent des données personnelles : identifiants, adresses IP, heures de connexion, sites consultés. Leur collecte a une finalité (la sécurité du système d'information), doit être proportionnée, connue des salariés (charte informatique) et inscrite au registre des traitements ; leur durée de conservation est limitée. La CNIL recommande, pour les journaux de sécurité, une conservation de six mois à un an. Le chapitre 13 applique cette durée aux alertes de Wazuh ; le cours Droit et RGPD détaille le registre et les obligations.

Exercices

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
</remote>

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event[System/EventID = 4624 or System/EventID = 4625]</query>
</localfile>