Windows 上的 Wazuh Whodata：修复错误 6955

如何修复 Windows 上的 Wazuh Whodata：使用审计 GUID 的本地化变通方案

src/syscheckd/src/whodata/win_whodata.c 中的 set_policies() 函数遵循以下流程：

• auditpol /backup → 创建一个包含“子类别名称”、“成功”、“失败”等表头的 CSV 文件
• 解析该 CSV 文件以确定当前状态
• auditpol /restore → 尝试应用已保存的设置

问题在于，自 Windows 10/11 1809 版本起，auditpol /restore 要求子类别名称完全匹配。如果 CSV 中指定的是“File System”，而 auditpol 预期的是“File System”，则命令会因错误代码 0x134c（5004）而失败，Wazuh 将其解释为 6955。这一行为已在 Microsoft 文档中明确说明：“/restore 命令对区域设置敏感，如果备份文件是在语言设置不同的系统上创建的，则可能失败。”

关键洞察：所有审计子类别都具有与操作系统语言无关的硬编码 GUID。例如：

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

这些标识符可通过 auditpol /list /subcategory:* 获取，并且从 Windows Vista 到 Windows 11 均保持稳定。

如何重写 set_policies() 函数而不依赖区域设置

重写 win_whodata.c 中的 set_policies() 函数是核心技术步骤。新实现摒弃了整个 CSV 处理流程，仅通过直接调用带有 GUID 的 auditpol /set 来完成配置。以下是补丁的关键要求：

• 最少系统调用：每次 system() 调用后必须检查返回值是否为非零
• 原子性：若某一子类别配置失败，其他子类别仍应继续执行
• 调试信息：每次出错时均需记录具体涉及的子类别
• 兼容 Windows Server 2016 及以上版本：所有指定的 GUID 在 Server Core 和桌面版中均受支持

该实现避免使用 popen() 或 CreateProcessA，以防止控制台编码问题。直接调用 system() 确保在系统的代码页下执行，从而使 auditpol 能正确解析 GUID。

构建 WinAgent 时针对 WIN_WHODATA 的额外补丁

构建适用于 Windows 的 Wazuh 代理需要在构建过程中进行三项关键修改：

• 启用预处理器定义 — 在 Makefile 的 DEFINES 部分添加 -DWIN_WHODATA，以激活 syscheckd 中对应的代码块
• 向 CMake 传递标志 — 修改 syscheckd/build 构建字符串，将 -DWIN_WHODATA 传入 CFLAGS 编译行
• 链接 wevtapi.lib — 这是调用 EvtSubscribe、EvtNext 等 Event Log API 函数所必需的依赖项，这些函数在 whodata 模式下使用。

若缺少第三点，构建将因链接错误而失败：“未定义引用‘EvtSubscribe’”。wevtapi.lib 库随 MinGW-w64（mingw-w64-dev 包）提供，无需外部 SDK。

此外，还需修正 buffer.c：将 dispatch_buffer() 函数中的 return NULL; 替换为 return 0;，因为该函数的返回类型为 int 而非 void*。此缺陷会导致在 whodata 模式下处理事件缓冲区时出现未定义行为。

测试与生产环境部署

成功编译后（make TARGET=winagent），生成的 wazuh-agent.exe 包含完整的独立 whodata 实现。验证方法如下：

• 在 ossec.conf 中启用 whodata 启动代理：

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

• 确保日志中无 6955、6915 或 6916 错误
• 验证 Kibana 或通过 wazuh-logtest 是否存在带有 type="whodata" 属性的 FIM 事件
• 确认在 Windows 的 ru-RU、zh-CN、es-ES 等不同区域设置下均可正常运行——所有测试结果应完全一致

在企业环境中部署时，需使用 EV 代码签名证书对可执行文件进行签名，因为 auditpol /set 需要管理员权限，若无可信签名，可能会被 Windows Defender 应用程序控制（WDAC）阻止。

关键要点

• 错误 6955 并非由 Wazuh Bug 引发，而是由于非英语 Windows 区域设置下 auditpol /restore 的局限性所致
• 使用 GUID 替代子类别名称是确保跨区域设置兼容性的唯一方法，且无需修改系统设置
• wevtapi.lib 是 whodata 必备依赖：缺少它将无法实时订阅审计事件
• buffer.c 补丁对稳定性至关重要：返回类型不匹配会导致事件缓冲区溢出时发生段错误
• 编译后的代理无需安装额外组件——所有必要内容均已内置在 wazuh-agent.exe 中

所有更改均向后兼容 Wazuh 官方 4.14.x 版本，并可通过补丁文件和构建后脚本集成到 CI/CD 流水线中。为实现自动化，建议使用 git apply 并配合预先验证的 diff 文件及源码哈希校验。

— Editorial Team