Wazuh-Rules 自定义规则贡献指南:从写出第一条规则到被合入(完整路径教程)
【免费下载链接】Wazuh-RulesAdvanced Wazuh Rules for more accurate threat detection. Feel free to implement within your own Wazuh environment, contribute, or fork!项目地址: https://gitcode.com/GitHub_Trending/wa/Wazuh-Rules
以下内容覆盖向 Wazuh-Rules 贡献自定义规则的完整路径:环境准备、写出并本地验证第一条规则、提交 PR、响应审核。看一遍就能动手。
贡献路线一图看懂
| 阶段 | 核心动作 | 常见坑 |
|---|---|---|
| 环境准备 | 本地部署 Wazuh-Manager 4.x,熟悉规则语法 | 管理器版本不达标 |
| 写规则 | 建分支、选对目录、写 XML 规则 | 放错目录 |
| 本地验证 | 规则部署到本地,观察触发、查误报 | 只测 happy path |
| 提交 PR | commit、push、建 PR 并写清改动 | 提交信息含糊 |
| 响应审核 | 逐条回复意见、迭代、跟进新威胁 | 被拒后失联 |
哪一步不熟悉,直接跳到对应小节看细节。
动手之前:环境准备与规则规范要点
环境要求
- 本地部署 Wazuh-Manager 4.x,规则没有管理器加载不会生效
- 会基本 Git 操作
- 动手前过一遍 Wazuh 规则语法文档,不用背,不写错就行
先把仓库克隆下来:
# 克隆 Wazuh-Rules 仓库到本地 git clone https://gitcode.com/GitHub_Trending/wa/Wazuh-Rules规则 ID、命名与级别约定
- ID 唯一性是红线:⚠️ 规则 ID 重复会直接导致 Wazuh-Manager 服务启动失败,写新规则前先查一遍仓库里已占用的 ID 区间
- 文件命名:沿用目录内
NNNNNN-name.xml的格式,名称要能准确描述检测目标 - level 设置:0-15 之间,数字越大越严重,按实际风险定,别为博眼球抬高档位
写出第一条规则并在本地验证
分支命名
fork 项目后,在本地建专用分支,用「规则类别/检测目标」命名:
# 以 Sysmon 进程注入检测规则为例建分支 git checkout -b sysmon/process-injection选对存放目录
| 规则类型 | 存放目录 |
|---|---|
| Windows 端点 | Windows_Sysmon/、Windows Powershell/、Windows Autoruns/ |
| Linux 端点 | Sysmon Linux/、Auditd/ |
| 威胁情报源 | MISP/、AbuseIPDB/、OpenCTI/、Maltrail/ |
| 商业安全产品 | Crowdstrike/、Sophos/、Office Defender/ |
拿不准就看同目录现有文件,比如 Windows Chainsaw/200001-windows_chainsaw_rules.xml 就是不错的格式参照。
XML 写法要点
- 每条规则有唯一
id和清晰的description level按实际风险设置reference里附上 MITRE ATT&CK 或相关参考链接- 检测逻辑复杂的,加注释说明,方便审核者读懂
本地测试验证
把规则集部署到本地 Wazuh-Manager 观察。仓库自带 wazuh_socfortress_rules.sh 可批量部署规则(它会覆盖已有自定义规则,跑之前先备份):

验证时问三个问题:
- 喂入匹配检测目标的样本日志,确认规则能如预期触发
- 跑几天,看日常业务操作是否频繁触发,频繁就收紧匹配条件或降 level
- 带阈值的规则(如 N 次触发才告警),确认阈值有效
最典型的错误:喂一条样本日志能触发,就以为万事大吉。
提交:commit、push 与创建 PR
commit 信息要能说明「这条规则针对什么检测场景」,别写「update」这类含糊词:
# 提交并推送规则分支 git commit -m "Add Sysmon process injection detection rule" git push origin sysmon/process-injectionPR 描述里写清楚四件事:
- 检测目标与适用场景
- 规则 ID 区间,确认与现有规则无冲突
- 验证方式:用什么日志触发、误报多少
- 样本日志或触发截图
响应审核,持续迭代
维护者留评论后逐条回复:意见合理就改完直接 push 更新;有分歧就在评论里说清理由,附上测试数据,别让评论悬着没人接。
被拒不是终点,多数拒绝源于误报率偏高或 ID 冲突。把意见看完,改完重新提交;如果检测思路本身有争议,可以先开 issue 对齐认知,再动手改。
规则合入后也别撒手:新攻击手法出现、日志格式变化,规则都需要跟进,这也是提交新 PR 的机会。
排坑:高频问题快答
Q:日志格式特殊,没有对应 decoder,规则怎么写?
A:先补一个 decoder 把原始日志解析成字段,规则再对这些字段匹配,decoder 和规则可以放进同一个 PR。
Q:误报偏高怎么判断?
A:本地跑一周,日常业务操作反复触发就说明偏多,收紧匹配条件或降 level。
Q:除了规则,接受其他类型的贡献吗?
A:接受。部署脚本、decoder 文件、文档都可以,放进对应集成目录即可。
Q:PR 提了之后一直没人看怎么办?
A:在 PR 里留言顶一下,或到相关 issue 里请维护者再帮看一眼。
从开头那条 git clone 命令开始:fork 仓库、建分支,提交第一条自定义规则。它被合入后,就会成为 Wazuh-Rules 检测集的一部分。
【免费下载链接】Wazuh-RulesAdvanced Wazuh Rules for more accurate threat detection. Feel free to implement within your own Wazuh environment, contribute, or fork!项目地址: https://gitcode.com/GitHub_Trending/wa/Wazuh-Rules
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考