能为规则补齐 msg、sid、rev、classtype、reference 元数据，使每条告警可检索、可修订、可溯源。
上一课，你用 suricata -T 校验了规则语法，用 suricata -r 离线回放了 PCAP，在 fast.log 里核对了首条告警，也理清了配置、规则、日志三类默认路径的差异。现在你已经看到：规则命中流量后，Suricata 只做一件事——写一条告警。分析师的第一个问题永远是“这条告警在说什么”。没有元数据的规则答不上来。
把告警想成一张快递单。msg 是备注栏，sid 是运单号，rev 是打印次数，classtype 是快递类型，reference 是随附发票。只有地址没有单号的快递单，无法查询，无法改签，无法证明来源。规则同理。
你会写七段结构的规则，也在 fast.log 里见过首条告警。接下来补齐五块元数据，让每条告警可读、可查、可溯源。
核心概念
msg：给告警贴一张可读标签
生活类比：快递单上的备注栏。收件人不必打开箱子，只看备注，就知道里面大概是什么，该不该签收。msg 就是规则写给分析师的那行备注。
技术定义：msg（message）是规则体里的元数据关键字，用一句话描述这条规则检测到什么。流量命中规则时，这段文本会写进告警日志，供分析师快速判断。官方快速上手文档的示例这样写：msg:"GPL ATTACK_RESPONSE id check returned root"。你在自己的规则里，把这段话换成你的检测意图。
写 msg 的要点：简洁、具体、一眼看懂。避免“可疑流量”这类空话；示例规则实际想说的是“检测到 root 权限回显”，就把话说清楚。
核心概念
sid：规则唯一的身份证号
生活类比：图书证号。一座图书馆里，每本书只有一个证号。查书、还书、盘点都靠证号，不靠书名。书名可以重复，证号不能。
技术定义：sid（signature ID）是规则体里的数字编号，唯一标识这一条规则。日志、统计、规则集都靠它定位规则。官方快速上手文档的示例规则使用 sid:2100498。
你新建规则时，要给一个全库不重复的编号。sid 代表规则的身份。身份不变，就沿用同一个 sid；检测的是全新行为，就开一个新 sid。官方文档把引擎事件规则的 sid 单独划段，说明编号空间有规划，自定义规则不要随意占号。
核心概念
rev：规则的修订版本号
生活类比：App 的版本号。1.0 修完 bug 变成 1.1。用户用的还是同一个 App，但你知道自己装的是哪一版。
技术定义：rev（revision）是规则体里的修订版本号，从 1 开始。你每次修改规则内容，就把 rev 加一。它与 sid 配合回答两个问题：sid 回答“是哪条规则”，rev 回答“是第几版”。
官方快速上手文档的示例规则带 rev:7，说明它被修订过 6 次。你改自己的规则时，把 rev:1 改成 rev:2。这样后来的人一看就知道，这条规则不是最初版本。rev 只增不减：就算回滚到旧写法，也继续加一，不要改回旧数字。
核心概念
classtype：给告警分门别类
生活类比：医院分诊台。病人进门，先被分到内科、外科或急诊。分诊决定优先级，也决定送哪个科室。
技术定义：classtype 把规则归入官方分类表中的一个类别。它支撑告警优先级、统计与报表。官方快速上手示例使用 classtype:bad-unknown，这个类别名直译就是“可疑但未知”。Coralogix 的规则解析文章同样把 classtype 列为常用指令。
你在规则里写 classtype 时，取值必须来自官方分类表。拿不准就先用 bad-unknown 这类通用类别，后面课程再谈优先级与误报治理。
核心概念
reference：把规则挂到外部证据上
生活类比：论文末尾的参考文献。读者看到引用，就知道结论依据来自哪篇文献，可以翻原文核实。
技术定义：reference 是规则体里关联外部依据的元数据关键字。依据可以是漏洞编号（如 CVE），也可以是厂商公告链接。分析师顺着 reference 就能核实：这条规则为什么存在，依据是什么。
官方文档在 Meta Keywords 章节收录了 reference。结合 sid、rev 与 reference，一条告警可以从日志文本反查到规则，再反查到漏洞依据。这就是可溯源的完整链路。
reference 的具体取值语法，以官方 Meta Keywords 章节为准。
元数据不是写给引擎看的，是写给三个月后的你、值班的分析师和审计人员看的。
fast.log 里每一条告警行都带着 msg 文本。看到文本，分析师就知道该不该继续深挖。在规则文件里搜 sid 编号，就能从告警反查到规则原文。classtype 让告警按类别汇总，一周下来哪些类别最多，优先级一目了然。reference 回答“为什么信它”。
四者合起来，是一条告警从出现到核实的完整线索。下次写规则前，先问自己三句：msg 让人看懂吗？sid 全库唯一吗？reference 有人核实过吗？
把五块元数据放进一条真实规则里看。官方快速上手文档给出了一条用于测试的示例规则：
alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)逐段拆解元数据：
- msg：分析师在日志里第一眼看到的话，说明“检测到 root 权限回显”。
- classtype：bad-unknown，归入“可疑但未知”类别。
- sid：2100498，全库唯一的规则编号。
- rev：7，这条规则已经修订到第 7 版。
- 末尾的 metadata 记录创建与更新时间，本课不展开。
content 关键字负责载荷匹配，属于后续课程内容。注意书写顺序习惯：规则体括号内先写检测条件，再写元数据；sid 通常靠近末尾。每条规则以右括号和分号收尾。
第一，sid 一旦发布，尽量不回收。删掉规则也别立刻把编号给别的规则用。
第二，改规则就递增 rev。改完忘了，两个版本就无法区分。
第三，reference 写下依据来源。三个月后，你还能看懂自己为什么写这条规则。
官方文档把引擎事件规则的 sid 单独划段，说明编号空间是有管理的。自定义规则要避开保留段，也避开已拉取规则集占用的编号。
reference 把规则挂到外部依据上，前提是依据本身可靠。只引用你核实过的 CVE 编号或厂商公告，不要引用二手转述。
本课程的实验只用本地 PCAP 与授权靶场流量；不要拿未授权流量验证规则，也不要为测试规则扫描未经授权的目标。
溯源能力越强，误报越难藏身。
动手：补齐元数据并验证
- 1
打开上一课保存自定义规则的文件，路径沿用上一课。若需要新建，可在 suricata-update 管理的 /var/lib/suricata/rules 之外单独建一个 .rules 文件，避免被更新工具覆盖。
- 2
在规则体括号内补齐元数据。模板如下，把内容换成你自己的检测意图：
suricataalert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TEST 元数据练习"; classtype:bad-unknown; sid:99000001; rev:1;) - 3
reference 的取值语法以官方文档 Meta Keywords 章节为准。有依据就按文档写法补上；暂时没有依据，可以先不写，但要知道它存在。
- 4
用上一课学到的测试模式校验规则文件：
bashsuricata -T -c /etc/suricata/suricata.yaml -S <你的规则文件> - 5
回放上一课的测试 PCAP，让流量真正命中这条规则：
bashsuricata -r /path/to/test.pcap -c /etc/suricata/suricata.yaml -S <你的规则文件> - 6
查看 fast.log（上一课已用过；日志目录为 /var/log/suricata），找到包含你 msg 文本的告警行。
bashtail -n 20 /var/log/suricata/fast.log - 7
修改规则内容（例如改动 msg 措辞），把 rev 从 1 改为 2，再跑一次第 4 步的校验。
你应该看到
suricata -T 校验通过，无语法错误。回放测试 PCAP 后，fast.log 中出现包含你设置的 msg 文本的告警行。修改后 rev 递增，再次校验仍通过。此时你能说出：sid 记录身份，rev 记录版本，msg 让分析师一眼看懂告警。把这条规则交给同事，只凭 fast.log 里的告警行，对方也能说出规则意图与依据——这就是元数据存在的意义。
遇到问题：suricata -T 校验报错，你新写的规则加载不进去，告警也看不到。
可能原因
- 元数据关键字拼写或取值不合法，比如 classtype 写了一个分类表里不存在的类别。
- msg 的双引号或规则体的括号没有闭合。
- sid 与已有规则重复。
排查步骤
- 先看报错信息指向的规则行号，缩小范围。
- 把规则简化到只剩 msg、sid、rev 三个关键字，校验通过后再逐个加回 classtype、reference，定位是哪个关键字出了问题。
- 对照官方文档 Meta Keywords 章节，逐字核对写法与取值。
- 确认是 sid 冲突就换一个未使用的编号，重新校验。
自检：你维护两条规则。规则 A 已上线，现在要修改它的检测逻辑；规则 B 是为了检测一种全新行为而写。分别说说 A 和 B 的 sid、rev 该怎么处理，为什么。
规则 A：sid 保持不变，rev 递增。sid 是规则身份，修改逻辑不等于换身份；rev 记录修订，让两个版本可区分。规则 B：分配一个全新的 sid，rev 从 1 开始，因为它是不同行为、不同规则，需要新身份。同理，回滚到旧检测逻辑时，rev 依然递增，而不是退回旧编号。核心一句话：sid 回答“是哪条规则”，rev 回答“是第几版”，两者配合，告警才能精确溯源。