Linux audit.rules 的 -a never,exclude 规则避免高频 syscall 噪声

-a never,exclude 不生效是因为 exclude 仅为 -a 的修饰符，须配合 arch、syscall 等内核字段使用；单独书写被 auditd 忽略且不报错，正确用法如 -a never,exclude -f arch=b64。

为什么 -a never,exclude 不生效？

因为 exclude 不是独立规则类型，而是 -a 的修饰符，必须配合具体 syscall 或事件类型使用；单独写 -a never,exclude 会被 auditd 忽略，且不报错，导致你以为加了却没用。

• exclude 只能用于过滤内核事件流中的特定子类，比如 arch、msgtype、syscall，不能单独存在
• 常见误写：-a never,exclude -F msgtype=1305 —— 错，msgtype 是用户态日志类型，不在 exclude 支持范围内
• 真正可用的组合只有：-a never,exclude -F arch=b64、-a never,exclude -F syscall=openat 等明确指向内核 tracepoint 的字段

高频 syscall 噪声该用什么规则屏蔽？

直接用 -a never,exclude 拦 syscall 效果差，优先走 -a exclude,always 或更精准的 -a exit,never 配合 -F syscall=...。

• -a exclude,always -F arch=b64 -F syscall=epoll_wait：从事件源头过滤，auditd 不解析也不记录，开销最低
• -a exit,never -F arch=b64 -F syscall=read：在 syscall 返回路径拦截，适用于已知调用方（如某进程 PID），但需注意 never 在 exit 链上才有效
• 避免对 clock_gettime、gettimeofday 等高频 syscall 用 -w 监控路径再排除——路径监控粒度太粗，反而放大噪声

audit.rules 加载后规则顺序会影响 exclude 效果吗？

会。audit 规则按加载顺序匹配，exclude 规则必须出现在可能触发它的规则之前，否则已被前面的 -a always,exit 捕获并记录，exclude 就没机会生效。

• 错误顺序：-a always,exit -F arch=b64 -F syscall=openat 写在前，-a never,exclude -F arch=b64 -F syscall=openat 写在后 → 后者无效
• 正确顺序：所有 exclude 规则必须放在最顶部，紧接在 -e 2 之后
• 验证方式：sudo auditctl -l | head -10 看实际加载顺序，别只信 rules 文件顺序

如何确认某个 syscall 确实被 exclude 过滤了？

不能只看日志是否消失，要查 auditd 内部计数器，否则容易误判为“生效”。

• 执行：sudo auditctl -s | grep "excluded"，输出类似 excluded: 12483 才说明规则在起作用
• 如果数字长期为 0，大概率是规则语法错、顺序错，或 syscall 名拼写不匹配（比如 openat vs openat64）
• strace -e trace=openat,read + 对应进程操作，再查 /var/log/audit/audit.log 是否有新事件，双验证更可靠

事情说清了就结束。注意 exclude 不是万能静音键，它只对内核审计路径上的特定字段生效，而很多“高频噪声”其实来自用户态日志或 auditd 自身的 housekeeping 事件，那得另找入口压。