auditctl -w监控敏感目录时路径必须真实存在，否则静默失效；-w仅监控目录自身属性变更，不递归子文件；需用-p wa标记权限、-k指定关键词；永久规则须写入/etc/audit/rules.d/并运行augenrules加载；避免监控/var/log/audit等审计日志自身路径以防循环；ausearch查询必须加-i参数还原可读信息。
auditctl临时监控敏感目录时，-w参数路径必须真实存在
如果目录不存在，auditctl -w会静默失败，不报错也不生效，但auditctl -l仍显示该规则——这容易让人误以为监控已启用。比如对/etc/ssh加规则前，先执行ls /etc/ssh确认路径存在；对/root监控时，注意普通用户默认无法进入，但auditd仍能捕获root用户的操作。
-
-w只监控目录自身属性变更（如chmod、chown），不递归监听子文件——要捕获/etc/ssh/sshd_config修改，得单独加一条-w /etc/ssh/sshd_config - 权限标记用
-p wa足够：写入（w）和属性变更（a）覆盖绝大多数篡改场景；加r或x会显著增加日志量，且通常无实际审计价值 - 每条规则必须配
-k关键词，例如-k sshd_config，否则后续用ausearch -k无法精准过滤
永久规则写入/etc/audit/rules.d/后，必须用augenrules加载
直接systemctl restart auditd不一定生效——现代发行版（RHEL 8+/Ubuntu 20.04+）默认启用augenrules机制，它会合并/etc/audit/rules.d/下所有.rules文件并生成统一规则集到/etc/audit/rules.d/audit.rules。手动改audit.rules会被覆盖。
- 文件名建议带数字前缀（如
10-sensitive-dir.rules），确保加载顺序可控 - 规则行末不能有空格或注释符
#混在规则后面，否则augenrules解析失败，整条规则被跳过 - 加载后务必验证：
sudo augenrules --load && sudo auditctl -l | grep "sshd_config"，看到匹配才说明成功
监控/root和/var/log时，需避开auditd自身日志干扰
/var/log/audit/audit.log本身在/var/log下，若对整个/var/log设-w -p wa，auditd写日志的动作会触发自身审计事件，形成循环日志风暴，迅速撑爆磁盘。
- 正确做法是分路径精确监控：
-w /var/log/messages -p wa -k log_messages、-w /var/log/secure -p wa -k log_secure，避开/var/log/audit/ -
/root目录监控要配合-F auid!=unset过滤条件，避免记录systemd或内核线程的伪操作（这些进程auid为-1） - 若发现
ausearch -k root_access返回大量type=SYSCALL msg=audit(…): arch=c86 syscall=259 …（即openat调用），大概率是auditd轮转日志时触发的，需检查是否误监了/var/log/audit
权限审计规则生效后，ausearch查询必须带-i参数
ausearch -k sshd_config输出的是原始二进制UID/GID/路径，全是数字（如auid=1001、name="/etc/ssh/sshd_config"），根本看不出是谁干的。不加-i等于白查。
-
ausearch -k sshd_config -i才能把UID转用户名、GID转组名、路径还原为可读字符串 - 时间范围要用
-ts yesterday -te now而非模糊词（recent可能漏数据），尤其排查凌晨发生的异常 - 查不到结果时，先确认
sudo systemctl status auditd是否active，再检查/var/log/audit/audit.log是否有新写入（tail -n 5 /var/log/audit/audit.log）
ausearch -k查出具体用户、时间、命令那一刻——此前所有步骤，都只是让这个查询成为可能。
