auditd日志未记录事件的首要原因是服务或内核审计功能未启用：需确认systemctl status auditd显示active(running)，auditctl -s显示enabled 1，且lsmod | grep audit有输出。
auditd 日志没记录到你期待的事件，通常不是规则写错了，而是整个审计链路中某个环节断了。排查要从底层服务状态开始，一层层往上验证，而不是直接翻日志。
确认 auditd 服务和内核模块是否真在运行
这是最常被跳过的一步，但却是90%“没记录”的根源。
- 执行 systemctl status auditd，必须看到 active (running)；如果显示 inactive 或 failed，服务根本没起来
- 运行 auditctl -s | grep enabled，输出应为 enabled 1；若为 0 表示审计功能被禁用，2 表示失败模式（只记录关键内核错误）
- 检查内核模块是否加载：lsmod | grep audit；没有输出说明 audit.ko 未载入，auditd 就无法工作
- CentOS 7 用户注意：不能用 systemctl restart auditd，它会清空所有临时规则；改用 service auditd reload 或走永久规则
验证规则是否真正生效
加了 auditctl -w 或 -a 规则，不等于它就被内核接受了。规则可能被忽略或拒绝。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 列出当前所有已加载规则：auditctl -l；如果刚加的规则不在里面，说明加载失败
- 检查路径是否存在且非符号链接终点：ls -ld /path/to/monitored；auditd 不跟踪软链目标，监控
/etc/passwd可以，但监控指向它的软链（如/etc/passwd.link）就无效 - 避免监控虚拟文件系统路径：
/proc、/sys、/dev/shm等都不支持-w；对/dev/sda这类块设备可监控 open/write，但无法记录扇区号 - 查看规则加载时的报错：ausearch -m CONFIG_CHANGE -ts recent，有时内核会明确提示 “Invalid argument” 或 “Permission denied”
检查事件是否真的触发了对应系统调用
auditd 只捕获内核系统调用，不是所有“操作”都会触发它。你以为改了文件，其实可能绕过了 audit 能感知的路径。
- 修改文件不等于触发
write()：用echo "x" > /etc/passwd会记录；但用vim编辑后保存，实际是创建新文件 + rename，主要触发的是openat、renameat，不是write - 挂载行为必须捕获
mount和umount2系统调用，而不是mount命令本身；规则里漏掉-F arch=b64（或b32）会导致 64 位系统下完全不匹配 - 执行命令要抓
execve，但某些容器或沙箱环境（如 firejail、gVisor）会拦截或重定向该调用，auditd 就收不到 - 特权操作（如 root 修改 shadow）可能被 SELinux 拦截在 syscall 前，auditd 根本看不到；可临时设 setenforce 0 测试是否 SELinux 干扰
日志检索方式是否匹配事件类型
找不到记录，有时是因为用了错误的查询命令，不是没发生。
- ausearch -k mykey 只查带该 key 的事件；但一个完整操作（如编辑文件）会产生多条记录（SYSCALL、PATH、CWD），需加 -i 人性化解析，并配合 -m SYSCALL,PATH 显式指定消息类型
- 查挂载行为不能只用 ausearch -m mount，因为 mount 系统调用成功后还会生成 PATH 记录（含设备路径），漏掉它就看不出挂了哪个盘
- 时间范围要写准：-ts today 是从 00:00 开始，不是“最近两小时”；怀疑刚发生的，用 -ts recent 更可靠
- 日志默认存在 /var/log/audit/audit.log，但有些系统启用了 logrotate 或远程转发，实际内容可能已被归档或发走；先确认 ls -lt /var/log/audit/
