Wazuh Whodata unter Windows: Fehler 6955 beheben

Wazuh Whodata unter Windows: Lokalisierungsworkaround mit Audit-GUIDs

Die Funktion set_policies() in src/syscheckd/src/whodata/win_whodata.c folgt dieser Abfolge:

• auditpol /backup → erstellt eine CSV-Datei mit Überschriften wie „Subkategorie-Name“, „Erfolg“, „Fehler“
• Parst diese CSV, um den aktuellen Zustand zu ermitteln
• auditpol /restore → versucht, die gespeicherten Einstellungen anzuwenden

Das Problem ist, dass ab Windows 10/11 Version 1809 der Befehl auditpol /restore eine exakte Übereinstimmung der Subkategorienamen verlangt. Wenn die CSV „File System“ angibt, auditpol jedoch „File System“ erwartet, schlägt der Befehl mit dem Fehlercode 0x134c (5004) fehl – ein Fehler, den Wazuh als 6955 interpretiert. Dieses Verhalten ist in den Microsoft-Dokumenten dokumentiert: „Der /restore-Befehl ist lokalitätssensitiv und kann fehlschlagen, wenn die Sicherungsdatei auf einem System mit anderen Spracheinstellungen erstellt wurde.“

Der entscheidende Einblick: Alle Audit-Subkategorien haben fest codierte GUIDs, die unabhängig von der Betriebssystemsprache sind. Zum Beispiel:

• File System: {0CCE921D-69AE-11D9-BED3-505054503030}
• Handle Manipulation: {0CCE9223-69AE-11D9-BED3-505054503030}
• Registry Changes: {0CCE9227-69AE-11D9-BED3-505054503030}

Diese Kennungen sind über auditpol /list /subcategory:* zugänglich und bleiben vom Windows Vista bis hin zu Windows 11 stabil.

Wie man set_policies() ohne Locale-Abhängigkeit neu schreibt

Die Neuschreibung der Funktion set_policies() in win_whodata.c ist der zentrale technische Schritt. Die neue Implementierung eliminiert den gesamten CSV-Stack und stützt sich ausschließlich auf direkte Aufrufe von auditpol /set mit GUIDs. Hier sind die wichtigsten Anforderungen für den Patch:

• Minimaler Systemaufruf: Jeder system()-Aufruf muss auf einen Nicht-Null-Exit-Code geprüft werden
• Atomarität: Wenn eine Subkategorie fehlschlägt, sollen die anderen weiter konfiguriert werden
• Debugging-Informationen: Jeder Fehler muss mit der betroffenen Subkategorie protokolliert werden
• Kompatibilität mit Windows Server 2016+: Alle angegebenen GUIDs werden sowohl in Server Core als auch in der Desktop-Edition unterstützt

Die Implementierung verzichtet auf popen() oder CreateProcessA, um Konsole-Kodierungsprobleme zu vermeiden. Der direkte Aufruf von system() gewährleistet die Ausführung in der Systemsprachcodierung, in der auditpol die GUIDs korrekt interpretiert.

Zusätzliche Patches für den Build von WinAgent mit WIN_WHODATA

Der Build des Wazuh-Agenten für Windows erfordert drei kritische Änderungen im Build-Prozess:

• Aktivieren der Präprozessor-Definition — fügen Sie -DWIN_WHODATA zum DEFINES-Abschnitt der Makefile hinzu, um die entsprechenden Codeblöcke in syscheckd zu aktivieren
• Übergeben des Flags an CMake — modifizieren Sie den Build-String syscheckd/build, um -DWIN_WHODATA in die CFLAGS-Kompilierungszeile zu übergeben
• Linken gegen wevtapi.lib — eine zwingende Abhängigkeit für Aufrufe von EvtSubscribe, EvtNext und anderen Event-Log-API-Funktionen, die im Whodata-Modus verwendet werden

Ohne den dritten Punkt schlägt der Build wegen eines Linking-Fehlers fehl: undefined reference to 'EvtSubscribe'. Die Bibliothek wevtapi.lib ist im Lieferumfang von MinGW-w64 (dem Paket mingw-w64-dev) enthalten und erfordert keine externen SDKs.

Zusätzlich muss buffer.c korrigiert werden: Ersetzen Sie in der Funktion dispatch_buffer() return NULL; durch return 0;, da ihre Signatur int statt void* zurückgibt. Dieser Bug führt zu undefiniertem Verhalten bei der Verarbeitung von Event-Puffern im Whodata-Modus.

Testen und Deployment in der Produktion

Nach erfolgreichem Kompilieren (make TARGET=winagent) enthält die resultierende wazuh-agent.exe eine vollständig eigenständige Whodata-Implementierung. Zur Validierung:

• Starten Sie den Agenten mit aktiviertem whodata in ossec.conf:

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

• Stellen Sie sicher, dass in den Logs keine Fehler 6955, 6915 oder 6916 auftreten
• Überprüfen Sie das Vorhandensein von FIM-Events mit dem Attribut type="whodata" in Kibana oder über wazuh-logtest
• Bestätigen Sie den Betrieb unter Windows mit den Locales ru-RU, zh-CN, es-ES — alle Tests sollten identisch bestehen

Das Deployment in Unternehmensumgebungen erfordert die Signierung der ausführbaren Datei mit einem EV-Code-Signing-Zertifikat, da auditpol /set Administratorrechte benötigt und ohne vertrauenswürdige Signatur von Windows Defender Application Control (WDAC) blockiert werden kann.

Was wirklich zählt

• Fehler 6955 wird nicht durch einen Wazuh-Bug verursacht, sondern durch die Einschränkung von auditpol /restore in nicht-englischen Windows-Locales
• Die Verwendung von GUIDs statt Subkategorienamen ist der einzige Weg, um plattformübergreifende Kompatibilität zu gewährleisten, ohne Systemeinstellungen zu ändern
• wevtapi.lib ist eine zwingende Abhängigkeit für Whodata: Ohne sie ist ein Echtzeit-Abonnement von Audit-Ereignissen unmöglich
• Der Patch für buffer.c ist entscheidend für die Stabilität: Eine Abweichung im Rückgabetyp führt zu einem Segmentation Fault, wenn der Event-Puffer überläuft
• Der kompilierte Agent erfordert keine Installation zusätzlicher Komponenten — alles Notwendige ist in wazuh-agent.exe integriert

Alle Änderungen sind abwärtskompatibel mit den offiziellen Wazuh-Releases 4.14.x und können über Patch-Dateien sowie Post-Build-Skripte in CI/CD-Pipelines integriert werden. Für die Automatisierung empfiehlt es sich, git apply mit vorab verifizierten Diff-Dateien und Quellhash-Validierung zu verwenden.

— Editorial Team