auditctl -w 是唯一靠谱的起点，因其基于 inode 精确捕获文件写入和属性变更；-p wa 覆盖关键篡改行为，-k 提供高效日志过滤，永久规则须写入 /etc/audit/rules.d/ 并用 augenrules --load 加载。
直接用 auditctl -w 监控文件绝对路径，配合 -p wa 和 -k，否则日志根本没法查、规则大概率不生效。
为什么 auditctl -w 是唯一靠谱的起点
监控配置文件篡改，核心是捕获 write 和 attribute change（比如 chmod、chown），而 -w 是 auditd 中唯一能精确绑定到文件 inode 层级变更的机制。用 -a always,exit 配 -F path=... 会失效——它只匹配 execve 或 open 等调用的参数字符串，路径被软链接、重命名或通过 fd 传递时就漏掉了。
-
-w /etc/shadow -p wa能捕获所有写入和权限/属主变更，哪怕调用方是perl -e 'open...'这类绕过命令行记录的方式 - 必须用
ls -i /etc/shadow确认真实路径，别写成/etc/passwd或软链接名（如/etc/shadow-） - 如果路径含空格或特殊字符，
auditctl不支持转义，直接换行或报错；此时应改用永久规则文件 +augenrules
-p wa 足够了，别乱加 x 或 r
对 /etc/shadow、/etc/sudoers 这类文件，读操作本身不是篡改行为，且高频触发（如 getpwent 调用），加 r 会导致日志爆炸、掩盖真正修改。执行权限 x 对配置文件无意义，内核也不会触发对应事件。
-
-p wa：覆盖写入（新增/覆盖用户）、属性变更（提权后改权限、隐藏文件）两类关键篡改 - 加
a很重要：攻击者常先chmod 600 /etc/shadow再写入，没a就看不到这步前置动作 - 不要写
-p rwa：在生产环境跑一天，ausearch -k shadow_mod -m SYSCALL | wc -l可能轻松破万，真正篡改藏在里面极难定位
-k 不是可选标签，是日志过滤的生命线
audit.log 是二进制格式，没有 -k 就只能靠 ausearch -f /etc/shadow，但这个命令会扫描全量日志、忽略上下文字段（如 auid），且无法区分是 root 手动改还是某个 cron 脚本误操作。加了 -k 后，ausearch -k shadow_mod 能秒出结果，还能和 aureport -f -i 组合生成可读报表。
- 关键字要语义明确：
-k shadow_mod比-k file1强十倍，避免后期 grep 错误路径 - 多个文件共用一个 key（如
-k identity_files）方便统一告警，但排查时得靠ausearch -k identity_files -f /etc/shadow二次过滤 - key 名称不能含空格或斜杠，否则
ausearch解析失败，报错类似Invalid key name format
永久生效必须走 /etc/audit/rules.d/ + augenrules --load
临时规则 auditctl -w ... 在 reboot、systemctl restart auditd 后全部丢失。生产环境必须写进规则文件，否则某天发现被篡改，第一反应是“我明明配了”，结果查 auditctl -l 发现空空如也。
- 新建
/etc/audit/rules.d/10-identity.rules，内容为：## Monitor critical identity files<br>-w /etc/shadow -p wa -k shadow_mod<br>-w /etc/passwd -p wa -k passwd_mod<br>-w /etc/sudoers -p wa -k sudoers_mod
- 运行
augenrules --load（不是systemctl restart auditd） - 验证：执行
auditctl -l | grep shadow_mod，确认规则已载入；再手动echo test > /etc/shadow 2>/dev/null（需 root），立刻ausearch -k shadow_mod -m SYSCALL -i | tail -2应见完整上下文 - 常见失败点：
/etc/audit/rules.d/目录权限不是640、SELinux 拦截规则加载（restorecon -Rv /etc/audit/）、ProtectSystem=strict导致 systemd 忽略该目录
真正容易被忽略的是：规则生效后，ausearch 默认只查最近 15 分钟，查历史得显式加 --start yesterday；另外，auid 字段才是登录用户 ID，比 uid 可靠得多——脚本里 sudo -u nobody 改文件，uid 是 nobody，但 auid 还是原始管理员，这才是溯源关键。
