auditd默认不启动、规则为空、内核模块未加载，三者缺一则日志为空；必须先启用服务（systemctl start/enable auditd），再将.rules文件存入/etc/audit/rules.d/并执行augenrules --load重载，同时指定-f arch=b64/b32才能捕获完整execve参数。
auditd 不是装上就自动审计文件的，它默认不启动、规则为空、内核模块未加载——三者缺一，/var/log/audit/audit.log 就只会空着或只写启动失败记录。
确认 auditd 服务真正在运行且已启用
很多“加了规则没日志”的问题，根源就是服务根本没活过来。别跳过这步直接写规则。
-
systemctl status auditd必须显示active (running)；如果看到inactive (dead)或failed，先执行sudo systemctl start auditd并sudo systemctl enable auditd - CentOS 7 不支持
systemctl restart auditd：重启会清空所有临时规则，必须用永久规则 +augenrules --load - 某些精简镜像（如部分 Docker 基础镜像）压根没装
auditd，先确认：rpm -q auditd（RHEL/CentOS）或dpkg -l | grep auditd（Debian/Ubuntu）
规则必须写进 /etc/audit/rules.d/ 并显式重载
把规则写进 /etc/audit/rules.d/99-identity.rules 只是存盘，auditd 启动时不会自动读取变更——必须手动触发合并与加载。
- 文件名必须以
.rules结尾，比如99-identity.rules；audit.conf或myaudit这类名字会被augenrules完全忽略 - 规则内容不能带
auditctl命令前缀，直接写规则行：-w /etc/passwd -p wa -k identity - 改完后必须执行：
sudo augenrules --load（它会合并所有.rules文件，生成/etc/audit/audit.rules，再调用auditctl -R加载） - 验证是否生效：
sudo auditctl -l | grep identity能看到对应规则，才算真正进内核
监控文件时 -p 和 -k 参数决定你能查到什么
-w 本身不记录内容，只捕获事件；查日志靠 -k 标签，而能捕获哪些动作全看 -p 权限位组合。
-
-p wa：推荐用于敏感配置文件（如/etc/passwd、/etc/shadow），覆盖写入（w）和属性变更（a，含chmod/chown/chattr） -
-p r慎加：读操作高频且无上下文，极易刷爆日志；除非明确需要追踪谁读了密钥文件 -
-k identity是关键：多个路径共用同一个-k值（如/etc/passwd和/etc/shadow都标identity），后续才能用ausearch -k identity -i一次性关联查出全部操作 - 路径必须真实存在且不能是虚拟文件系统：
/proc、/sys下的路径无效，auditd直接拒绝加载该规则
查不到 execve 日志？缺 -F arch 是最常见原因
想审计命令执行（比如谁运行了 sudo 或 rm -rf），只写 -S execve 不够——64 位系统必须显式指定架构，否则内核根本不匹配。
- 正确写法（必须两条都加，兼容混合环境）：
-a always,exit -F arch=b64 -S execve -k command_exec-a always,exit -F arch=b32 -S execve -k command_exec - 不加
-F arch=b64的后果：日志里只有execve系统调用入口，参数字段是地址+长度，看不到实际命令；加上后ausearch -k command_exec -i才能输出可读的完整命令行 - 性能提醒：全局监控
execve会产生海量日志，生产环境建议缩小范围，比如只监-F path=/usr/bin/sudo或按 UID 过滤（-F uid=0）
auditd 的核心陷阱不在语法多难，而在“看起来配好了”和“真正在工作”之间隔着三层检查：服务状态、规则加载、内核模块。漏掉任意一层，日志就静默消失——尤其 augenrules --load 这一步，被跳过的频率远高于其他操作。
