Wazuh 配置体系解析从 ossec.conf 到模块化配置vulnerability-detection 与 indexer 源码级解读【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh导读本文围绕 Wazuh 开源安全平台中配置如何被管理、解析并分发给各模块/系统组件这一核心机制展开重点深入讲解 src/config/README.md 所定义的两大配置区块vulnerability-detection漏洞检测与indexer索引器。读者将掌握 ossec.conf 配置节的 XML 解析入口、cJSON 转换与 wmodule 数据结构的分发链路并理解新旧配置vulnerability-detectorvsvulnerability-detection的兼容处理方式从而能够在生产环境中正确配置并排障漏洞检测与索引器通信。一、配置体系总览每个模块各有一套配置节Wazuh manager 与 agent 的配置统一存放于ossec.confmanager 端与ossec-agent.confagent 端但每个模块的配置节会被以不同的方式管理并分发到对应的系统组件这正是 src/config/README.md 开篇强调的核心观点。从仓库目录结构看配置解析的实现集中在 src/config/src 与 src/config/include 两个目录传统配置解析器按功能域划分client-config.cclient、remote-config.cremote、syscheck-config.c、rootcheck-config.c、authd-config.c、localfile-config.c、wazuh_db-config.c、global-config.c等Wazuh 模块wmodule配置解析器wmodules-config.c及wmodules-*.c系列aws、azure、gcp、github、ms-graph、office365、sca、syscollector、command、task-manager、vulnerability-detection 等由独立配置源驱动的特殊组件indexer-config.c。其中config.c是总调度入口ReadConfig遍历ossec.conf的根节点按 XML 元素名将每个子节点分发给对应的Read_*函数config.c。正是这张元素名 → 解析函数的调度表构成了 Wazuh 配置体系的骨架。二、Vulnerability Detection 配置XML → cJSON → wmodule data2.1 配置来源与处理文件vulnerability-detection配置节位于ossec.conf的根级由src/config/src/wmodules-vulnerability-detection.c负责管理。其默认模板可在 etc/templates/config/generic/wodle-vulnerability-detection.manager.template 中查看vulnerability-detection enabledyes/enabled feed-update-interval60m/feed-update-interval /vulnerability-detection2.2 解析函数 Read_Vulnerability_Detection解析入口是Read_Vulnerability_Detection函数签名声明于 src/config/include/config.hint Read_Vulnerability_Detection(const OS_XML *xml, XML_NODE nodes, void *d1, const bool old_vd);其职责是把 XML 节点解析并转换为 cJSON 对象供后续的vulnerability_scanner模块使用wmodules-vulnerability-detection.c。核心流程如下查找/创建 wmodule 节点遍历已有的wmodule链表若不存在WM_VULNERABILITY_SCANNER_CONTEXT.name对应的节点则分配一个新的wmodule并为其分配wm_vulnerability_scanner_t结构初始化 pod 结构在wm_vulnerability_scanner_t内创建 cJSON 对象vulnerability_detection并把它挂到cur_wmodule-data字段——这正是 README 中所说的 pod structure is stored in the data field of the vulnerability-detection wmodule递归解析子节点调用wm_vulnerability_detection_subnode_read递归遍历 XML 子树将配置项写入 cJSON。2.3 白名单校验与数组归并逻辑wm_vulnerability_detection_subnode_readwmodules-vulnerability-detection.c实现了两个值得注意的行为未知元素白名单过滤只有以下 key 会被接受其余元素会触发XML_INVELEM警告并被跳过static const char * valid_paths[] { enabled, feed-update-interval, pageSize, numSlices, NULL };同名元素的归并策略当同一层级出现同名 key 时若目标已是 cJSON 数组则把新值追加进数组否则删除旧值、写入新值覆盖语义在old_vd兼容模式下则直接忽略避免旧配置覆盖新配置。这解释了 README 提到的 hosts / certificate_authorities 数组字段 的同构处理思路——Wazuh 的 XML 解析器天然把重复标签合并为数组。2.4 旧配置兼容vulnerability-detector 的降级处理从 config.c 可以看到调度器同时识别两个根元素vulnerability-detection调用Read_Vulnerability_Detection(..., old_vdfalse)vulnerability-detector旧版已弃用打印弃用警告后以old_vdtrue调用同一函数。在old_vdtrue时只有enabled字段会被采纳其余旧字段一律忽略见wm_vulnerability_detection_subnode_read中if (old_vd !config_enabled) continue;。此外两个配置节均受#if !defined(WIN32) !defined(CLIENT)保护即仅 manager 端有效agent/Windows 端会打印 configuration is only set in the manager 警告。三、Indexer 配置独立配置源与全局 cJSON 变量3.1 与模块配置不同的分发方式indexer配置节同样位于ossec.conf默认模板见 etc/templates/config/generic/wodle-indexer.manager.templateindexer hosts hosthttps://127.0.0.1:9200/host /hosts ssl certificate_authorities caetc/certs/root-ca.pem/ca /certificate_authorities certificateetc/certs/manager.pem/certificate keyetc/certs/manager-key.pem/key /ssl /indexer与 vulnerability-detection 将结果装入wmodule-data不同indexer 的解析输出是一个全局 cJSON 变量indexer_config声明于 src/config/include/indexer-config.hextern cJSON * indexer_config;。3.2 解析函数 Read_IndexerRead_Indexerindexer-config.c的实现非常精简若indexer_config已有值先cJSON_Delete释放保证重复加载时无内存泄漏调用get_indexer_cnf(config_file, error_buffer, ...)从配置文件提取 indexer 子树的字符串用cJSON_Parse将其解析为全局 cJSON 树。注意其入参是const char* config_file调用时传入宏WAZUHCONF即ossec.conf的路径由get_indexer_cnf内部定位indexer元素这与 vulnerability-detection 直接接收已解析的XML_NODE的方式形成鲜明对比——README 中每个模块采用不同管理方式在此得到印证。3.3 数组语义hosts 与 certificate_authoritiesREADME 特别指出 indexer 配置中有两个特殊的数组字段hosts和certificate_authorities它们在存储为 cJSON 数组时忽略内部子元素的名称。也就是说hostshost.../host/hosts中内部元素名host被忽略只保留其内容值certificate_authoritiesca.../ca/certificate_authorities中内部元素名ca被忽略只保留路径值。因此最终得到的 cJSON 数组形如hosts: [https://127.0.0.1:9200]、certificate_authorities: [etc/certs/root-ca.pem]。这种设计使得 indexer 配置天然支持多 host 与多 CA 的扩展多个host或多个ca会依次并入数组也便于消费方直接遍历数组而无需关心 XML 元素命名。3.4 全局变量的消费方从源码看indexer_config全局变量被vulnerability_scanner与inventory_sync两个模块消费wm_vulnerability_scanner.c当indexer_config NULL时给出错误处理否则通过cJSON_Duplicate(indexer_config, TRUE)把 indexer 配置深拷贝进模块自身的配置 JSONwm_inventory_sync.c同样的模式将 indexer 配置复制进config_json。这种全局解析一次、多模块深拷贝消费的模式保证了连接 Wazuh indexerOpenSearch 集群所需的 host、TLS 证书与私钥等敏感配置只被解析一遍同时避免模块间共享可变 cJSON 树带来的并发风险。四、配置分发链路总结综合以上源码分析可归纳出 Wazuh 配置体系的三种分发形态配置节管理文件解析函数输出载体消费方vulnerability-detectionwmodules-vulnerability-detection.cRead_Vulnerability_Detectionwm_vulnerability_scanner_t挂载于wmodule-datavulnerability_scanner 模块vulnerability-detector已弃用同上同上old_vdtrue同上仅enabled生效vulnerability_scanner 模块indexerindexer-config.cRead_Indexer全局 cJSONindexer_configvulnerability_scanner、inventory_sync整体链路为ossec.confXML→config.c的ReadConfig按元素名分发 → 各Read_*函数 → cJSON 中间表示 → 模块运行时消费。五、实操要点与排障建议启用漏洞检测在ossec.conf根级加入vulnerability-detectionenabledyes/enabled/vulnerability-detectionfeed-update-interval控制漏洞库更新周期默认模板为60m模块白名单还支持pageSize与numSlices漏洞库分页/分片读取相关参数。迁移旧配置若仍在使用vulnerability-detector启动时会出现弃用警告且只有enabled会被沿用其余旧参数需手工迁移到新节名下。配置 indexer 连接确保hosts指向可访问的 indexer 地址默认https://127.0.0.1:9200ssl下的certificate_authorities、certificate、key三个路径指向实际存在的证书文件如etc/certs/下的 root-ca.pem、manager.pem、manager-key.pem若配置缺失Read_Indexer会返回OS_INVALID并通过merror输出解析错误。验证配置生效重启 wazuh-manager 后可在日志中观察 vulnerability_scanner / inventory_sync 是否成功加载 indexer 配置配置解析失败时config.c的fail路径会让ReadConfig返回OS_INVALID。需要说明的是README 中指向的在线配置文档为外部链接仓库内部的相关参考文档位于 docs/ref/configuration/manager 与 docs/ref/configuration/agent可结合阅读以获得各配置节的完整参数参考。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考