Wazuh Whodata sur Windows : correction de l'erreur 6955

Comment résoudre le problème de Wazuh Whodata sous Windows : solution de contournement localisée utilisant les GUID d’audit

La fonction set_policies() dans src/syscheckd/src/whodata/win_whodata.c suit la séquence suivante :

• auditpol /backup → crée un fichier CSV avec des en-têtes comme « Nom de sous-catégorie », « Succès », « Échec »
• Analyse ce CSV pour déterminer l’état actuel
• auditpol /restore → tente d’appliquer les paramètres sauvegardés

Le problème est que, à partir de Windows 10/11 version 1809, auditpol /restore exige une correspondance exacte des noms de sous-catégories. Si le CSV indique « Système de fichiers » mais que auditpol attend « File System », la commande échoue avec le code d’erreur 0x134c (5004), que Wazuh interprète comme 6955. Ce comportement est documenté dans les Docs Microsoft : « La commande /restore est sensible à la locale et peut échouer si le fichier de sauvegarde a été créé sur un système avec des paramètres linguistiques différents. »

L’idée clé : toutes les sous-catégories d’audit ont des GUID codés en dur, indépendants de la langue du système d’exploitation. Par exemple :

• Système de fichiers : {0CCE921D-69AE-11D9-BED3-505054503030}
• Manipulation des handles : {0CCE9223-69AE-11D9-BED3-505054503030}
• Modifications du registre : {0CCE9227-69AE-11D9-BED3-505054503030}

Ces identifiants sont accessibles via auditpol /list /subcategory:* et restent stables depuis Windows Vista jusqu’à Windows 11.

Comment réécrire set_policies() sans dépendre de la locale

Réécrire la fonction set_policies() dans win_whodata.c est l’étape technique centrale. La nouvelle implémentation supprime toute la pile CSV et se base uniquement sur l’appel direct de auditpol /set avec les GUID. Voici les exigences clés du correctif :

• Appels système minimaux : chaque appel à system() doit être vérifié pour un code de sortie non nul
• Atomicité : si une sous-catégorie échoue, les autres doivent continuer à se configurer
• Informations de débogage : chaque erreur doit être enregistrée avec la sous-catégorie concernée
• Compatibilité avec Windows Server 2016+ : tous les GUID spécifiés sont pris en charge à la fois dans Server Core et dans l’édition Desktop

L’implémentation évite d’utiliser popen() ou CreateProcessA pour prévenir les problèmes d’encodage de la console. L’appel direct à system() garantit une exécution dans la page de code du système, où auditpol interprète correctement les GUID.

Correctifs supplémentaires pour la compilation de WinAgent avec WIN_WHODATA

La compilation de l’agent Wazuh pour Windows nécessite trois modifications cruciales dans le processus de build :

• Activer la définition du préprocesseur — ajouter -DWIN_WHODATA à la section DEFINES du Makefile pour activer les blocs de code correspondants dans syscheckd
• Passer le flag à CMake — modifier la chaîne de build syscheckd/build pour transmettre -DWIN_WHODATA dans la ligne de compilation CFLAGS
• Lier contre wevtapi.lib — dépendance obligatoire pour les appels à EvtSubscribe, EvtNext et autres fonctions de l’API du journal des événements utilisées en mode whodata

Sans le troisième point, la compilation échouera en raison d’une erreur de liaison : undefined reference to 'EvtSubscribe'. La bibliothèque wevtapi.lib est incluse avec MinGW-w64 (le paquet mingw-w64-dev) et ne nécessite pas de SDK externes.

De plus, buffer.c doit être corrigé : remplacer return NULL; par return 0; dans la fonction dispatch_buffer(), car sa signature renvoie int plutôt que void*. Ce bug entraîne un comportement indéfini lors du traitement des buffers d’événements en mode whodata.

Tests et déploiement en production

Après une compilation réussie (make TARGET=winagent), le fichier wazuh-agent.exe résultant contient une implémentation whodata entièrement autonome. Pour valider :

• Démarrer l’agent avec whodata activé dans ossec.conf :

<syscheck>
  <whodata>yes</whodata>
</syscheck>

• S’assurer qu’il n’y a pas d’erreurs 6955, 6915 ou 6916 dans les journaux
• Vérifier la présence d’événements FIM avec l’attribut type="whodata" dans Kibana ou via wazuh-logtest
• Confirmer le fonctionnement sur Windows avec les locales ru-RU, zh-CN, es-ES — tous les tests doivent passer de manière identique

Le déploiement dans les environnements d’entreprise requiert la signature de l’exécutable avec un certificat EV Code Signing, car auditpol /set nécessite des privilèges administrateurs et peut être bloqué par Windows Defender Application Control (WDAC) sans signature de confiance.

Ce qui compte

• L’erreur 6955 n’est pas causée par un bug de Wazuh, mais par la limitation de auditpol /restore dans les locales Windows non anglophones
• Utiliser des GUID au lieu des noms de sous-catégories est la seule façon d’assurer la compatibilité interlocale sans modifier les paramètres du système
• wevtapi.lib est une dépendance obligatoire pour whodata : sans elle, l’abonnement en temps réel aux événements d’audit est impossible
• Le correctif de buffer.c est crucial pour la stabilité : une incohérence dans le type de retour provoque une segmentation fault lorsque le buffer d’événements déborde
• L’agent compilé ne nécessite pas d’installation de composants supplémentaires — tout ce dont on a besoin est intégré dans wazuh-agent.exe

Toutes les modifications sont rétrocompatibles avec les versions officielles de Wazuh 4.14.x et peuvent être intégrées dans les pipelines CI/CD via des fichiers de patch et des scripts post-build. Pour l’automatisation, il est recommandé d’utiliser git apply avec des fichiers diff pré-vérifiés et une validation du hash source.

— Editorial Team