最简有效写法是auditctl -w /etc/shadow -p w -k shadow_write，必须用ls -i /etc/shadow确认真实路径，-k为日志过滤唯一高效手段，-w比-a更可靠捕获所有写入行为。
auditctl -w /etc/shadow -p w 是最简有效写法
直接监控文件路径比监控符号链接或别名更可靠。/etc/shadow 的真实 inode 和路径必须用 ls -i /etc/shadow 确认，规则中必须写这个绝对路径，不能写 /etc/passwd 或其他软链目标。
只监控“写”操作，用 -p w 即可。不要加 -p rwxa 或 -p wa —— 除非你明确需要属性变更（如 chmod）或读取行为。纯写监控场景下，多加权限标记只会引入无关日志，干扰排查。
-
auditctl -w /etc/shadow -p w -k shadow_write是推荐的最小可行命令 -
-k参数不是装饰：后续必须靠它过滤，否则ausearch -f /etc/shadow会混入大量非关键事件（比如内核自身访问） - 执行后立刻用
auditctl -l | grep shadow验证规则是否生效，确保输出里有完整匹配行
为什么不能用 -a always,exit -F path=/etc/shadow -F perm=w
这种系统调用规则写法看似底层，实际在 shadow 场景下反而容易漏事件。原因在于：很多修改 shadow 的操作（如 usermod、passwd）并不直接对 /etc/shadow 执行 open(O_WRONLY)，而是先 open(..., O_RDWR) 或通过临时文件重写再 rename —— 这些都会绕过 -F perm=w 的精确匹配。
而 -w 是内核 vfs 层的路径级监控，只要最终写入落到该 inode 对应的文件路径上，就一定会被捕获，兼容性更强。
- 别迷信“系统调用规则更底层”，对文件写入这类行为，
-w更稳 -
-a ... -F path=更适合监控特定 syscall（如execve）或无法用路径定位的场景（如所有openat调用） - 若真要用
-a形式，至少补上-F perm=wa并配-k，但依然不如-w直观可靠
规则加了却看不到日志？先查这三件事
常见现象是规则已加载，但 ausearch -k shadow_write 返回空。这不是配置问题，而是审计链路卡在某个环节。
- 运行
auditctl -s | grep enabled，确认enabled是1，且pid非零；如果enabled是0，用auditctl -e 1启用 - 检查
systemctl status auditd是否为active (running)；若失败，日志通常在/var/log/audit/audit.log或journalctl -u auditd - 确认没被其他规则屏蔽：
auditctl -l查看是否有一条-a never,exit -F path=/etc/shadow类似禁用规则，有的话用auditctl -d删除
临时规则够用，但重启后失效
auditctl 添加的是运行时规则，系统重启或 auditd 重载后自动清空。生产环境必须固化到配置文件。
把规则写进 /etc/audit/rules.d/shadow.rules（文件名任意，但需以 .rules 结尾），内容只写一行：-w /etc/shadow -p w -k shadow_write
- 不要写成 shell 命令格式（比如去掉
auditctl前缀） - 写完执行
augenrules --load加载，它会合并所有.rules文件并写入/etc/audit/audit.rules - 验证是否生效：重启
auditd后再跑auditctl -l，规则应仍在列表中
-k 标签和路径真实性里。auditd 不会帮你猜你想要什么，它只忠实地记录你告诉它监控的那个 inode 上发生的那个动作。写错路径、漏掉 -k、或者混淆临时与永久规则，是 90% 的“监控不到”问题的根源。 
