把自定义规则送进 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 ATTCK 或厂商文档都行。匹配条件放在field或location里。group namecustom_detection, rule id300101 level8 field nameevent_data.command_line typepcre2procdump.*-ma.*4/field descriptionLSASS memory dump attempt via procdump/description referencehttps://attack.mitre.org/techniques/T1003/001//reference groupcredential_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 社区贡献的文件组织逻辑很简单目录即数据源。放对位置评审快一半。规则类型所在目录典型检测场景Windows Sysmon 与事件日志Windows_Sysmon/进程创建、镜像加载、LSASS 访问Linux Auditd 与 Sysmon for LinuxAuditd/、Sysmon Linux/内核审计事件、Linux 进程行为云平台与 SaaS 日志云安全AWS/、Office 365/CloudTrail、O365 审计日志威胁情报接入MISP/、OpenCTI/、AbuseIPDB/情报源告警解析与富化你的规则不属于以上任何一类按数据源自建一个目录就好这是这个仓库一直沿用的惯例。资深贡献者的三条建议注释写给半年后的自己规则的注释和 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考