把自定义规则送进 Wazuh-Rules 的新手贡献实战手册

把自定义规则送进 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

你写了一条能抓到 Cobalt Strike beacon 的规则，想让它跑在别人的 Wazuh 集群上。往哪提、怎么提？答案就在 Wazuh-Rules——这个社区贡献驱动的开源安全规则项目。

开工前，把这三样东西备齐

• 一套 Wazuh-Manager 4.x 环境，本地虚拟机或测试集群都行
• 熟练的 Git 基础操作：clone、branch、commit、push 不用卡壳
• 读过一遍 Wazuh 规则 XML 语法文档，知道 rule、field、group 这些标签是干嘛的

从克隆到合并：自定义规则提交的完整路径

拉仓库、建分支：安全规则开源贡献的第一步

先把仓库拉下来，再开一个新分支。分支名按 README 的建议用规则分类/检测目标的格式，别用test这种自己看了都想删掉的名字。

git clone https://gitcode.com/GitHub_Trending/wa/Wazuh-Rules cd Wazuh-Rules git checkout -b sysmon/lsass-credential-dump

写规则：Wazuh 规则怎么写

规则文件就是一个<group>里包着若干<rule>，每个 rule 有四个核心字段：id全局唯一，也是文件名前缀，撞了 manager 直接起不来；level取值 0 到 15，数字越大代表事件越严重；description写清楚这条规则抓的是什么；reference给出证据来源，CVE、MITRE ATT&CK 或厂商文档都行。匹配条件放在field或location里。

<group name="custom_detection,"> <rule id="300101" level="8"> <field name="event_data.command_line" type="pcre2">procdump.*-ma.*4</field> <description>LSASS memory dump attempt via procdump</description> <reference>https://attack.mitre.org/techniques/T1003/001/</reference> <group>credential_access,lsass,</group> </rule> </group>

不确定风格的话，翻一个现成的文件照着写，比如 200920-dnstwist.xml，整个文件就这么几个标签，但每个都得准。

本地验证：你的 Wazuh 规则响起来才算数

把 XML 放进 manager 的 rules 目录，重启服务，然后喂一条命中的样本日志给 agent，看告警到底弹不弹出来。想偷懒也可以直接用仓库自带的 wazuh_socfortress_rules.sh，它把整套规则集一键装进 manager，顺便帮你把文件加载和 ID 冲突这两件事验掉了。


⚠️ 这里要敲一下黑板：重复的 rule ID 会让 manager 服务直接启动失败。所以部署前，务必全库搜一遍你用的 ID，确认没被占。

提交与 PR：走完 Wazuh PR 流程

git add . git commit -m "Add Sysmon rule for LSASS credential dumping" git push origin sysmon/lsass-credential-dump

然后到平台上开 PR。描述里写清三样东西：这条规则检测什么、你选的 ID 段及理由、贴一张真实触发的告警截图。commit message 用英文写明白就行，评审的人第一眼看的也是它。到这里，流程就走完了。

规则该扔进哪个文件夹？

Wazuh-Rules 社区贡献的文件组织逻辑很简单：目录即数据源。放对位置，评审快一半。

你的规则不属于以上任何一类？按数据源自建一个目录就好，这是这个仓库一直沿用的惯例。

资深贡献者的三条建议

注释写给半年后的自己

规则的注释和 description，请按照"半年后看不懂自己代码的人"来写：匹配的是什么日志格式、为什么这么写、已知的误报场景在哪。半年后调告警的人大概率就是你，或者是只能靠你注释吃饭的陌生人。

读 review 比写规则更重要

PR 被拒是常态，别往心里去。review 意见才是这份安全规则开源贡献里最值钱的教材——level 怎么定、field 怎么收窄、description 怎么写规范，逐条读完，你的第二个 PR 会顺得多。

盯新 CVE 比打磨老规则划算

一条已经合并、被优化过三轮的老规则，再磨下去收益递减；而新 CVE 公开后 48 小时内写出的第一条规则，往往最容易被合入也最受关注。平时多关注 CVE 通告和安全厂商的 blog，模板备好，机会来了直接填。

你大概率会卡住的两个问题

规则 ID 冲突，是绝大多数人遇到的第一道坎。提交前把全仓库搜一遍你用的 ID，再参考该分类现有的编号区间——仓库大致按 100xxx、200xxx 这类段划分，在你所在分类的区间里挑一个空号，再确认一下相邻文件。这步跳过，manager 起不来，一切白搭。

另一种是 PR 提出去之后长时间没人理。维护者都是义务劳动的同行，等上一两周很正常；先翻一下 issues 确认不是重复需求，仍没动静就在 PR 评论里礼貌地 bump 一次，不用焦虑，更别反复催。

你的规则，可能正在保护某个你从未见过的 SOC 屏幕

半年后的某个凌晨，某块你从未见过的 SOC 屏幕弹出一条告警：Cobalt Strike beacon 命中。你当时写的那条规则，正在替一个陌生人值班。

【免费下载链接】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