Linux 怎样为文件变更建立审计规则

Linux 上要记录某个文件或目录的变更，建议从“对象 + 事件类型 + 可检索标识”三个维度建立最小规则，而不是直接对所有系统调用做全量审计。对单个文件可以使用 -F path=...，对目录可以使用 -F dir=...，再用 -F perm=wa 关注写入和属性变化，并通过 -k 给记录加上业务可读的 key。

官方手册：https://man7.org/linux/man-pages/man8/auditctl.8.html

下面的命令是配置示例，不代表已经在本文环境执行。正式落地前要结合发行版的 auditd 配置、日志保留策略和变更审批流程。

先把要审计的对象和动作说清楚

“监控文件变化”不是一个足够精确的需求。你需要先决定是单个敏感文件、一个配置目录，还是某类程序访问某个目录；还要决定关注写入、属性变化、执行，还是包含读取。审计范围越宽，事件量和排查成本越高。

如果只想知道谁改了配置，通常先从 wa 开始；若还要分析读取行为，再单独评估 r 是否会产生过多记录。不要把“想看一切”直接翻译成 -S all，这会把问题从一个文件扩大成全机事件流。

用 path 或 dir 建立最小审计规则

对现代 auditctl 配置，优先考虑 syscall 规则形式。单文件和目录分别使用 path、dir，同时明确架构和权限过滤。下面以 x86_64 常见的 b64 为例；如果目标机器是其他架构，应按机器实际支持的 syscall 架构调整。

# 单文件：只记录配置文件的写入与属性变化
sudo auditctl -a always,exit -F arch=b64 -F path=/etc/example/app.conf -F perm=wa -k example-config

# 目录：递归覆盖目录树中的文件变化
sudo auditctl -a always,exit -F arch=b64 -F dir=/etc/example/ -F perm=wa -k example-config

# 查看内核当前已经加载的规则
sudo auditctl -l

这里的 always,exit 表示在系统调用退出阶段生成审计记录；path 绑定单个文件，dir 绑定目录树，perm=wa 让内核按文件操作意图筛选写入与属性变化。一个 key 可以让多条同类规则在查询时聚合到一起，但 key 只负责检索，不替代规则本身的边界设计。

官方手册仍保留 -w /path -p wa 的示例，但同时说明这种 watch 写法是兼容形式，性能较差，建议转换为基于 syscall 的规则。不要把旧命令和新命令同时长期写入同一台机器，否则可能重复记录，排查时也不容易判断到底是哪条规则命中。

临时调整与持久化加载要分开

直接使用 auditctl 适合验证一条规则的边界：它改变的是当前运行中的内核审计配置，重启后是否保留取决于发行版的规则文件和加载服务。确认规则稳定后，再把等价配置写进 /etc/audit/audit.rules 或发行版约定的规则目录，并按该发行版的方式重新加载。

# /etc/audit/audit.rules：示例规则，按发行版的规则加载机制部署
# 只关注应用配置目录的写入与属性变化，避免全机 syscall 审计
-a always,exit -F arch=b64 -F dir=/etc/example/ -F perm=wa -k example-config

# 若团队要求锁定配置，-e 2 应放在规则文件最后
# -e 2

-e 2 会锁定审计配置，之后的修改要等重启才能生效，因此不能把它当作普通调试步骤。先确认规则加载、事件查询和回滚路径，再在有明确变更窗口时启用。规则文件由 auditctl -R 读取时，手册还要求文件由 root 拥有且不能被其他用户读取；不要把它当成可由普通账号随意修改的脚本。

用规则列表、状态和 key 查询形成闭环

建立规则后，至少要确认三件事：规则是否真的在内核中、审计子系统是否处于工作状态、目标操作是否能按 key 找到记录。下面的检查命令只读取状态和日志索引，不改变规则。

# 列出当前规则，确认 path/dir、perm 和 key 没有写错
sudo auditctl -l

# 查看 enabled、backlog、lost 等审计子系统状态
sudo auditctl -s

# 按 key 查询规则关联的事件；时间范围按现场需要补充
sudo ausearch -k example-config

如果 auditctl -l 没有目标规则，先处理加载问题，不要急着改查询命令；如果规则存在但 ausearch 查不到事件，再区分“没有发生匹配操作”和“事件没有送到用户态”两类情况。auditctl -s 中的 lost 与 backlog 值尤其值得关注：前者提示曾有记录丢失，后者反映当前排队压力。

不命中或变慢时按边界排查

1. 先看是否被 never,task 影响：某些系统默认规则会让新进程跳过审计处理。先用 auditctl -l 查是否存在该规则，再按发行版文档调整加载配置。
2. 再看路径和权限：path 必须是实际文件对象，dir 要带目录边界；perm 不是普通 Unix 文件权限位，而是触发审计的访问类型。
3. 检查架构与 syscall：双架构系统中不要只凭习惯写一条架构规则；手册提醒不同架构的 syscall 编号可能不同，必要时分别写 b32 和 b64。
4. 最后看规则数量和事件量：多个过滤条件和动作相同的 syscall 规则可以合并，优先使用文件系统审计范围，避免对每个程序的每次系统调用都重复评估。

排查时不要先执行 -D 清空全部规则再“重新开始”，除非你已经有完整备份、维护窗口和回滚方案。清空规则会影响同机其他安全策略；更稳妥的做法是先记录 auditctl -l 输出，再针对目标规则做精确调整。

常见问题

可以直接使用 -w 吗？ 可以用于兼容旧配置，但新建规则更适合使用 path/dir + perm 的 syscall 形式。旧 watch 规则不应与新规则无计划地重复部署。

为什么只写 perm=w 仍看不到 chmod？ 内容写入和属性变化是不同的审计意图，权限、属主或时间变化通常需要把 a 一并纳入，例如 perm=wa。

auditctl 规则重启后消失怎么办？ 运行时加载和持久化文件是两层配置。把确认过的规则放入发行版实际读取的 audit 规则文件，并在重启前按服务文档确认加载顺序。

文件变更审计的关键不是堆更多规则，而是让每条规则都有清楚的对象、动作和查询 key。先用小范围规则确认记录闭环，再决定是否扩大目录、权限或留存周期，通常更容易控制噪声和性能。