用 auditctl -w 监控目录时，如果发现子目录或目录内文件的操作没有被记录，原因其实很明确：-w 只会盯住目标路径本身的 inode，并不会递归追踪下面的子项。也就是说，像 -w /etc 这样的规则，只能捕获类似 chmod /etc 这类直接作用在目录自身的操作；至于 chmod /etc/passwd，默认并不会被这条规则记下来，需要单独补充规则，或者改用 -a always,exit -F dir=/etc 这类方式。
auditctl -w 监控目录时为什么没记录子目录操作
因为 -w 默认只监控目标路径本身，不递归子项。比如 auditctl -w /etc 只捕获对 /etc 目录节点的属性修改（如 chmod /etc），但不会记录 /etc/passwd 的写入。
- 真正要监控整个目录树，必须用
-a always,exit -F dir=/path形式，它基于系统调用过滤，天然覆盖所有子路径 -w是“watch”机制，走的是 inotify 类路径监听，内核限制多、开销低，但粒度粗-a always,exit -F dir=是 syscall 级审计，每条 open/write/bind 都匹配路径前缀，更准但性能开销略高- 验证是否生效：执行
sudo touch /etc/testfile后，运行sudo ausearch -k etc_access -i | grep "touch"，若无输出，大概率是用了-w而非-F dir=
/etc/audit/rules.d/ 下规则文件名后缀必须是 .rules 吗
是，augenrules 只扫描 .rules 结尾的文件。写成 10-security.conf 或 audit.cfg 会被忽略，重启 auditd 后规则完全不加载。
- 规则文件权限应为
640，属主 root:root，否则augenrules加载时会报错并跳过 - 文件内每行一条规则，空行和以
#开头的注释行会被忽略 - 多个规则文件按字母序加载，
00-default.rules会比99-custom.rules先处理，冲突时后者覆盖前者（取决于规则匹配逻辑） - 加载后可用
sudo auditctl -l查看实际生效的规则列表，确认你的规则在其中
如何让审计日志包含具体操作的用户和命令参数
默认情况下，execve 系统调用的审计日志通常只会记下调用者的 UID 和可执行文件路径，argv 参数并不会一并带上。也就是说，如果想看到像 rm -rf /tmp/* 这样完整的命令行，光靠默认记录是不够的，必须明确启用 -F exe=，或者借助 aureport -f -i 做反向解析。不过后者能不能还原出来，关键还得看 audit.log 里当时有没有保存足够的相关字段。
- 加
-F auid!=4294967295过滤掉 kernel thread，保留真实登录用户行为 - 用
-F arch=b64（或b32）限定架构，避免同一条规则在双架构系统里重复触发 - 对敏感目录，推荐组合写法：
-a always,exit -F dir=/root -F perm=wa -F auid>=1000 -k root_write，这样既限用户范围，又明确权限类型 - 注意
ausearch -k root_write -i输出中exe="/bin/rm"和cmd="rm -rf /root/test"字段是否出现——没出现说明 auditd 配置里log_format不是ENRICHED，需检查/etc/audit/auditd.conf中该选项
audit.log 日志被轮转后旧文件权限不对怎么办
logrotate 默认用 root 身份创建新日志，但旧日志可能残留为 root:root 600，导致普通审计分析脚本无法读取，且不符合最小权限原则。
- 在
/etc/logrotate.d/auditd中添加create 640 root adm行，确保新日志属组为adm，权限收紧但允许日志分析工具访问 - 手动修复已有日志：
sudo chmod 640 /var/log/audit/audit.log.* && sudo chgrp adm /var/log/audit/audit.log.* - 不要直接
chmod 644—— 其他用户可读审计日志等于泄露敏感操作痕迹 - 检查
/var/log/audit/目录权限是否为750，否则即使日志文件权限正确，目录可遍历也会导致风险
审计规则不是设完就完事。真正难的是在 -F dir= 和 -w 之间选对模式，在 .rules 文件名和 logrotate 权限上不出错，以及确认 ausearch -i 能吐出你想要的命令参数——这三处最容易被跳过验证。
