Linux audit 怎样按路径监控文件变化

想监控 Linux 上某个配置文件或目录的变化，最小可用方案是让 auditd 记录文件系统访问，再用 ausearch 按路径或规则 key 查询。单个文件用 path，目录用 dir，通常只记录写入和属性变化，也就是 perm=wa，这样比把整个文件系统的系统调用都记下来更容易控制日志量。

先把监控目标缩到一个绝对路径

路径审计最先要确定的是“要解释哪一次变化”，而不是先写一条很宽的规则。比如只关心应用配置，可以监控 /etc/myapp/app.conf；如果应用会在同一目录下轮换多个配置文件，再把范围扩大到 /etc/myapp/。不要直接从 / 或整个 /etc 开始，否则事件量会掩盖真正的修改来源。

可以先记录三个基线指标：规则数量、指定时间窗口内的事件数量，以及一次查询耗时。它们比“日志很多”更容易比较调整前后的差异。审计记录本身写入 /var/log/audit/，具体文件由系统的 audit 配置决定；本文不假定某个发行版的轮转策略。

用 path 或 dir 写出最小规则

单个文件和目录的规则写法不同，但核心字段一致：动作、架构、路径范围、文件访问类型和查询 key。下面的命令只关心写入与属性变化；a 表示属性变化，例如权限、所有者或时间属性发生改变。

# 先确保目标目录存在，避免把路径拼写错误当成审计规则问题
sudo install -d -m 0755 /etc/myapp

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

# 目录：递归关注目录树中的写入与属性变化，目录范围要尽量小
sudo auditctl -a always,exit -F arch=b64 -F dir=/etc/myapp/ -F perm=wa -F key=myapp-config

上面两条规则不要同时照抄到同一台机器：如果目录规则已经覆盖了 app.conf，再加单文件规则可能导致重复记录。path 和 dir 不能使用通配符；目录规则适合一组相关文件，单文件规则适合需要明确归因的关键配置。

arch=b64 让规则明确作用于 64 位系统调用。若机器需要同时审计 32 位程序，应根据实际兼容需求补充对应架构规则，而不是盲目复制；不同架构下系统调用编号不能想当然地共用。

加载规则后先看规则本身

临时规则加载后，先列出内核当前规则。这个动作是低成本的“配置基线”：能确认路径是否为绝对路径、权限是否写成预期的 wa，也能发现测试过程中重复添加的规则。

# 列出内核当前规则，只检查配置是否进入 audit 子系统
sudo auditctl -l

# 用规则 key 快速缩小输出，确认 myapp-config 是否存在
sudo auditctl -l | grep -- 'myapp-config'

如果规则加载失败，先看命令返回的错误并修正路径、字段或权限，再重试同一条规则。不要把“查询不到事件”和“规则没有加载”混为一谈：前者需要制造一次明确变更，后者要回到 auditctl -l 排查。

用一次小变更建立可识别样本

为了确认规则确实能捕获目标动作，测试时只做一项变化，例如追加一行注释，再修改一次文件权限。命令中的注释说明每个动作的目的，实际环境应使用测试配置或维护窗口，避免覆盖真实业务内容。

# 追加一行可回滚的标记，触发一次写入事件
printf '# audit path probe\n' | sudo tee -a /etc/myapp/app.conf >/dev/null

# 单独触发属性变化，便于观察 perm=wa 中的 a
sudo chmod 0640 /etc/myapp/app.conf

测试动作完成后，记下大致时间和操作者账号。审计事件中的时间、auid、uid、进程名和路径，应该能与这次动作对应；如果只看到服务启动时产生的旧记录，查询时要缩小时间范围。

用 ausearch 按 key 和路径查询

key 是最方便的第一层过滤器。它能把由同一安全需求产生的记录归到一起；需要进一步确认具体文件时，再追加 -f。-i 会把 UID、系统调用等字段尽量解释成人类可读形式。

# 先按 key 查询最近事件，并把数字字段解释为可读值
sudo ausearch -k myapp-config -i

# 再按绝对路径缩小范围，适合目录规则覆盖多个文件的情况
sudo ausearch -k myapp-config -f /etc/myapp/app.conf -i

# 只看今天的目标事件，减少历史轮转日志带来的噪声
sudo ausearch -k myapp-config -ts today -i

一个文件操作不一定只对应一行输出。审计系统通常会把同一事件拆成 SYSCALL、PATH、PROCTITLE 等记录，并用同一个事件序列号关联它们。判断“谁改了什么”时，先看 PATH 的文件名，再结合 SYSCALL 的 comm、exe、auid 和 success；不要只凭一行 PROCTITLE 下结论。

把规则持久化，并按指标控制开销

命令行加载的规则通常只适合验证。正式使用时，把规则写进发行版启用的 /etc/audit/rules.d/ 文件，再按系统方式重新加载。文件名可以表达用途，例如 50-myapp-config.rules；规则内容仍然保持最小范围。

# 写入持久化规则文件；这里用单目录规则覆盖同一类配置文件
sudo tee /etc/audit/rules.d/50-myapp-config.rules >/dev/null 

旧式 auditctl -w /path -p wa 仍常见于旧资料，但 -w watch 形式已被标记为兼容用途，性能较差；新的配置优先使用上面的 syscall 形式。目录规则会递归到目录树底部，但遇到挂载点会停止，因此跨挂载点的目录不能简单理解成“所有后代目录”。

调整范围时可以连续记录一段固定窗口内的事件数、audit backlog 是否增长，以及 ausearch 查询耗时。若事件数随着业务流量线性上升，先缩小目录或把 perm 从 rwa 收紧到实际需要的 wa；若 backlog 持续增长，还要结合审计队列和磁盘写入能力处理，不能只靠增加查询过滤器补救。

常见问题

只想监控一个文件，应该用 path 还是 dir？

只关心一个固定文件时用 path；同一目录下的配置文件会轮换或新增时用 dir。范围越小，事件归因和日志量越容易控制。

perm=wa 中的 a 是什么？

a 表示属性变化，常见于权限、所有者或时间属性修改；它不是普通 Linux 文件权限字符串中的“追加”含义。

为什么同一次修改会看到多行审计日志？

审计事件会拆成不同类型的记录。用事件序列号把它们合并理解，再从 PATH、SYSCALL 和 PROCTITLE 交叉判断，不能把每一行当成一次独立修改。

目录规则会自动跨文件系统递归吗？

目录规则会递归目录树，但遇到挂载点会停止。需要跨挂载点时，应为实际挂载后的目标路径分别设计规则，并重新评估事件数量。