在使用 auditctl -w 监控 Linux 目录时，如果发现子目录或目录中文件的操作没有出现在审计日志里，原因其实很清楚：-w 只会监视目标路径自身的 inode，并不会递归跟踪其下级目录和文件。换句话说，像 -w /etc 这样的 auditctl 规则，只能捕获类似 chmod /etc 这种直接作用于目录本身的操作；而像 chmod /etc/passwd 这样的文件变更，默认不会被这条规则记录下来，必须额外添加针对文件的规则，或者改用 -a always,exit -F dir=/etc 这类可覆盖目录树的 Linux 审计规则。
auditctl -w 监控目录时为什么没记录子目录操作
原因在于 -w 默认只监听目标路径本身，不会递归监控子目录和文件。比如 auditctl -w /etc 只能捕获对 /etc 目录节点本身的属性变更，例如 chmod /etc，但不会记录对 /etc/passwd 的写入、修改或删除操作。
- 如果要真正监控整个目录树，必须使用
-a always,exit -F dir=/path这种写法，它基于系统调用过滤，天然可以覆盖目录下所有子路径，适合做 Linux 目录递归审计 -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查看当前实际生效的 auditctl 规则列表，确认自定义规则是否已经成功启用
如何让审计日志包含具体操作的用户和命令参数
默认情况下，execve 系统调用生成的审计日志通常只会记录调用者的 UID 以及可执行文件路径，argv 命令参数并不会自动完整展示。也就是说，如果你希望看到类似 rm -rf /tmp/* 这样的完整命令行，仅靠默认的 auditd 配置通常不够，还需要明确启用 -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，否则即便日志文件权限正确，目录如果可被遍历，同样会带来信息泄露隐患
Linux 审计规则并不是配置完成就万事大吉。真正容易出问题的地方，往往在于是否正确区分了 -F dir= 和 -w 的使用场景，是否把规则文件正确保存为 .rules 后缀，以及是否在 logrotate 和 ausearch -i 验证环节中确认日志权限与命令参数输出都符合预期——这几处正是最容易被忽略、却最影响审计效果的关键点。
