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 能吐出你想要的命令参数——这三处最容易被跳过验证。
