用auditctl快速验证目录监控是否生效，需执行临时规则sudo auditctl -a always,exit -F dir=/root -F perm=r -k root_read，再以普通用户运行ls /root或stat /root，最后用sudo ausearch -k root_read -m openat,statx,getdents64 -i | head -5检查输出是否含uid、success及对应系统调用；若无输出，常见原因包括路径不存在、缺少perm=r/x或未覆盖openat等关键系统调用。
怎么用 auditctl 快速验证目录监控是否生效
直接跑一条临时规则，比改配置再重启更快验证逻辑是否通。比如想确认对 /root 的访问能否被捕获，先执行：
sudo auditctl -a always,exit -F dir=/root -F perm=r -k root_read
然后用普通用户（非 root）执行 ls /root 或 stat /root，再立刻查日志：
sudo ausearch -k root_read -m openat,statx,getdents64 -i | head -5
如果输出里有 uid=1001、success=yes/no 和对应系统调用，说明内核已捕获；没输出常见原因有三个：
-
dir=/root路径必须真实存在且拼写完全一致（不能是软链接路径） - 没加
-F perm=r或-F perm=x—— 仅-p wa监控写和属性变更，进目录需要读或执行权限 - 用户实际触发的是
openat(AT_FDCWD, "/root", ...)，但规则没覆盖openat系统调用，此时需补-S openat
为什么 /etc/audit/rules.d/ 里的规则要分文件、带数字前缀
auditd 加载 /etc/audit/rules.d/ 下所有 .rules 文件时，按文件名字母序读取，不是按内容顺序。如果多个文件定义了冲突规则（比如一个禁用、一个启用同一路径），后加载的会覆盖前者。
所以生产环境必须控制加载顺序，典型做法是：
- 基础规则放
00-base.rules（如全局execve监控） - 业务敏感目录放
10-web.rules（如-w /var/www/html -p rwxa -k web_access） - 高危目录放
20-critical.rules（如-w /etc/shadow -p wa -k shadow_mod） - 所有文件末尾加
# end of rules注释，避免因换行缺失导致后续规则被注释吞掉
写完别直接 systemctl restart auditd，要用 sudo augenrules --load —— 它会合并所有 .rules 文件并去重，再推送到内核；而 restart 可能漏加载部分文件。
-w 和 -a always,exit -F dir= 的根本区别在哪
-w /path 是路径监控快捷语法，底层自动展开为一组固定系统调用（open、openat、stat 等），但它只监控该路径自身，不递归子目录，也不捕获符号链接解析后的实际目标。
而 -a always,exit -F dir=/path -S openat,statx,getdents64 是显式声明要监听哪些系统调用，并强制匹配 dir= 字段——这个字段在内核中表示“本次系统调用操作的目标路径是否以该值为前缀”，因此能覆盖 /path/sub/file，也能捕获 cd /path && ls 触发的 getdents64。
实际选型建议：
- 监控静态配置文件（如
/etc/passwd）用-w足够，简洁不易错 - 监控整个目录树或需要区分“进入”和“读内容”行为（如审计
/root非授权访问），必须用-a ... -F dir=... -S ...组合 - 混用时注意：同一路径同时存在
-w和-a规则，-a优先级更高，但日志字段可能不一致（-w日志含path=，-a含dir=和name=）
审计日志里看不到 UID 或组信息？检查这三点
auditd 默认记录 auid（登录时分配的审计 UID）、uid（当前进程 UID）、euid（有效 UID），但不会直接存组名。如果你用 ausearch -k xxx 查不到预期用户，大概率是：
-
auid为4294967295（即-1）：表示该事件来自未登录会话（如 cron、systemd service），此时uid才是真实身份，需用ausearch -ui 0查 root 进程 - 规则里漏了
-F arch=b64或-F arch=b32：64 位系统上，32 位程序（如某些旧版工具）触发的open不会被 b64 规则捕获，必须双架构都写 - 日志被轮转或清空：
/var/log/audit/audit.log默认只保留最新一份，查历史得翻audit.log.1、audit.log.2，或确认max_log_file_action = rotate在/etc/audit/auditd.conf中已启用
真正麻烦的是跨架构混用场景：容器里跑 32 位 busybox、宿主机是 x86_64，这时只配 b64 规则会漏掉一半访问，必须两条规则都写死。
