auditd是Linux唯一能追溯“谁、何时、用什么进程修改文件”的工具，工作在内核系统调用层，需用-p w显式启用写入监控，永久规则须存于/etc/audit/rules.d/并执行augenrules --load加载。
Linux 默认不记录文件被哪些进程修改过，stat、ls -l 或 inotifywait 都无法回溯历史操作；真正能查到“谁、何时、用什么进程改了文件”的，只有 auditd ——它工作在内核系统调用层，能捕获 write、openat、renameat 等真实写入行为，并附带 pid、comm（命令名）、exe（可执行路径）、uid、cwd 等完整上下文。
auditctl 添加文件写入监控规则时，-p 参数必须包含 w 才能捕获修改
只加 -p a（属性变更）或 -p r（读取）不会记录内容修改。写入类操作必须显式启用 w 权限位，否则日志里根本不会出现对应事件。
-
-p wa：最常用组合，覆盖写入 + chmod/chown 等属性变更 -
-p w：仅捕获写入（如echo > file、vim :w保存、cp覆盖），不包括touch或chmod -
-p wax：额外捕获执行权限变更（如chmod +x）和执行行为（较少用于文件监控） - 注意：
-p不支持rwxa全开滥用——尤其在高 IO 目录下，r会爆炸式产生日志，生产环境慎用
临时规则 vs 永久规则：auditctl 生效但重启即丢，/etc/audit/rules.d/ 才可靠
用 sudo auditctl -w /path/to/file -p w -k myfile 立刻生效，适合调试；但一旦 systemctl restart auditd 或机器重启，规则就消失。生产环境必须落盘为永久规则。
- 把规则写进
/etc/audit/rules.d/myfile.rules，格式严格：每行一条，开头无空格，例如：-w /etc/hosts -p wa -k hosts_mod - 不能直接编辑
/etc/audit/audit.rules——该文件由augenrules自动生成，手动改会被覆盖 - 写完后运行
sudo augenrules --load（或重启auditd），再用sudo auditctl -l确认是否加载成功 - CentOS 7 用户注意：
service auditd restart会清空所有临时规则，但不影响永久规则加载结果
ausearch 查日志时，-f 和 -k 必须配合 -i 才能看懂进程名和路径
ausearch -f /etc/hosts 只输出原始审计事件，字段全是数字 ID（如 uid=1001、pid=12345）；不加 -i 就等于白查。
- 正确命令：
sudo ausearch -k hosts_mod -i | head -20（用-k过滤比-f更准，避免路径软链干扰） - 关键字段含义：
comm="bash"是触发命令名，exe="/usr/bin/vim.basic"是实际执行文件，cwd="/root"是当前工作目录，name="/etc/hosts"是操作的目标路径 - 如果看到
comm="(unknown)"，说明进程已退出，内核无法反查命令名——这时要靠exe和ppid（父进程 ID）向上追溯 - 时间戳是 epoch 秒数，
-i会自动转成可读时间；不用-i的话得自己算：date -d @1745496789
auditd 日志体积增长快，/var/log/audit/audit.log 不清理会撑爆磁盘
auditd 默认日志不轮转，单个 audit.log 文件达到 max_log_file = 8 MB（默认值）就停止写入，后续审计事件全部丢失——你不是没监控到，而是日志早停了。
- 务必提前修改
/etc/audit/auditd.conf：max_log_file = 50（单位 MB）num_logs = 10（保留 10 个归档）space_left_action = email（磁盘不足时发邮件告警） - 改完必须
sudo systemctl restart auditd，否则配置不生效 - 已有日志过大？别用
rm或truncate——auditd 会拒绝写入。应使用sudo logrotate -f /etc/logrotate.d/auditd（如有配置）或sudo systemctl kill --signal=SIGUSR1 auditd手动切日志 - 高频监控场景（如
/tmp）建议单独配-k tmp_writes并定期ausearch -k tmp_writes --start today | aureport -f统计，避免全量日志淹没关键线索
真正难的不是加一条 auditctl 命令，而是想清楚：你要监控的是瞬时篡改（比如半夜改配置），还是长期行为分析（比如追踪某个服务反复覆盖日志）；前者靠 -k 标签快速定位，后者依赖 ausearch 时间范围筛选和 aureport 聚合——漏掉 -i 或忽略 max_log_file 设置，查到的日志要么看不懂，要么根本不存在。
