Firewalld 富规则不支持 --set-description，因其语法无元数据字段；可行方案为：1. 日志 prefix 嵌入工单号；2. XML 文件添加注释；3. 外部登记表记录哈希与工单映射。
Firewalld 的 --set-description 不支持直接为富规则（rich rule）添加描述，这是关键前提。
firewalld 当前（截至 2026 年）的 rich rule 机制本身不提供元数据字段（如 description、ticket_id、comment、tag 等），其语法结构严格限定在 rule [...] action 范围内，所有元素都参与匹配或执行逻辑（如 source, port, log, accept），没有预留用于标注、注释或审计标识的语法位置。
这意味着：
- ❌ 你不能用
firewall-cmd --add-rich-rule='rule ... accept' --set-description="TICKET-2026-12345"—— 这个命令会报错：--set-description不是--add-rich-rule的有效选项。 - ❌ 富规则不会被写入任何带描述字段的配置文件（如
/etc/firewalld/zones/public.xml中只存 raw rule 字符串，无注释区）。 - ❌
firewall-cmd --list-rich-rules输出纯规则文本，无法关联工单号。
✅ 可行的合规审计替代方案（生产推荐）
1. 在规则字符串中嵌入工单号作为日志前缀（最常用、最可靠）
利用 log prefix= 将工单号“软注入”到规则行为中，既不影响功能，又可被 auditd/syslog 捕获，形成可追溯的操作证据。
firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="192.168.10.50" service name="ssh" \
log prefix="AUDIT-TICKET-2026-78901 " level="info" limit value="1/m" \
reject'
✅ 效果：
- 所有匹配该规则的拒绝事件，syslog 中将出现类似：
... AUDIT-TICKET-2026-78901 REJECT IN=ens3 OUT= MAC=... SRC=192.168.10.50 ... - 工单号与实际拦截行为强绑定，满足“操作即留痕”审计要求。
- 支持全文检索（
grep "TICKET-2026-78901" /var/log/messages）。
? 提示：prefix 建议统一格式（如
AUDIT--），避免空格/特殊字符导致解析异常；长度建议 ≤ 32 字符。
2. 在 zone 配置文件中手动添加 XML 注释（需 reload，适合归档）
编辑 /etc/firewalld/zones/public.xml（或其他目标 zone 文件），在
<!-- AUDIT-TICKET-2026-78901: Block legacy SSH client from PCI zone --> <rule family="ipv4"><source address="10.20.30.0/24"></source><service name="ssh"></service><reject></reject></rule><!-- END TICKET-2026-78901 -->
✅ 效果：
- 文件版本化后（如 Git 管理
/etc/firewalld/zones/），每次变更附带工单上下文； -
firewall-cmd --reload后生效，规则内容不变，但人工/自动化审计工具可提取注释； - 符合 SOC2、等保2.0 中“配置变更须可追溯”的要求。
⚠️ 注意：必须用 --permanent 添加规则后再手动编辑 XML，否则 firewall-cmd --runtime-to-permanent 会覆盖注释。
3. 建立独立的规则登记表（推荐搭配使用）
维护一个轻量 CSV 或 Markdown 表格（如 /etc/firewalld/rich-rules-audit.csv）：
ticket_id,zone,rule_hash,added_by,timestamp,description TICKET-2026-78901,public,sha256:abc123...,ops-team,2026-05-22T14:30:00Z,"Block SSH from 10.20.30.0/24 per PCI-DSS req"
配合脚本自动生成 rule_hash（对 rich rule 字符串做 sha256），实现规则内容 → 工单号的双向映射。
✅ 效果：
- 审计时可校验当前运行规则是否与登记表一致；
- 支持批量导出、对接 CMDB 或 ITSM 系统；
- 无 firewalld 版本兼容性风险。
不复杂但容易忽略：富规则本身是“执行指令”，不是“文档载体”。合规审计真正需要的不是“规则里写着工单号”，而是“哪条规则对应哪个审批依据、谁在何时为何启用它”。把工单号放进日志前缀 + 配置文件注释 + 外部登记表，三者结合，就能扎实闭环。
