最简有效写法是auditctl -w /etc/ -p wa -k etc_changes，必须加-p指定权限、-k设关键字，否则无法捕获事件或难以检索；临时规则需用augenrules --load固化到/etc/audit/rules.d/才永久生效。
auditctl -w 目录监控规则怎么写才有效
直接用 auditctl -w 加目录，不加权限参数或乱设权限，大概率收不到想看的事件。关键不是“监控了”，而是“监控到了什么”。
-
-w /etc/本身只注册路径监听，但默认不捕获任何操作——必须显式指定-p参数 -
-p wa是最常用组合：捕获写入（w）和属性修改（a），比如chmod、chown、新增/覆盖文件；避免用-p rwxa，尤其在/usr/lib这类高频读取目录，会瞬间刷爆日志 - 末尾斜杠
/etc/不影响功能，但加上更明确表示是目录而非同名文件，减少后续排查歧义 - 务必加
-k关键字，例如-k etc_changes，否则查日志时要在海量记录里人工筛name=字段，效率极低
为什么 auditctl 添加的规则重启就没了
因为 auditctl 命令操作的是内核运行时规则表，所有规则都存在内存里，不写磁盘。这是设计使然，不是 bug。
- 临时规则适合验证：改完规则马上
sudo touch /etc/test，再sudo ausearch -k etc_changes看是否出记录 - 生产环境必须固化到文件：写入
/etc/audit/rules.d/*.rules（如sudo vim /etc/audit/rules.d/etc.rules），内容与auditctl命令一致，例如-w /etc/ -p wa -k etc_changes - 不能直接改
/etc/audit/audit.rules：该文件由augenrules自动生成，手动编辑会被覆盖 - 加载新规则必须用
sudo augenrules --load，不是systemctl restart auditd——后者可能跳过规则编译步骤，导致新规则不生效
监控 /root 目录“进入”行为要绕开 shell 内置命令陷阱
cd /root 本身不会触发审计事件，因为它是 shell 内置命令，不调用系统调用。真正能捕获的是底层动作，比如 ls /root 或 stat /root。
- 仅用
-w /root -p r捕获不到“尝试进入”，因为读目录内容实际走的是getdents64系统调用，不是普通文件读 - 正确做法是混用路径监控 + 系统调用监控：
-a always,exit -F dir=/root -F perm=x -k root_access（捕获执行权限访问，如cd后的内部openat） +-a always,exit -F arch=b64 -S getdents64,statx,openat -F dir=/root -k root_access - 注意架构区分：
b64对应 x86_64，b32对应 i386；混合架构服务器必须两条都写，否则 32 位程序访问会漏掉 - 普通用户执行
ls /root失败时仍会生成审计事件——这正是你要的日志，说明有非授权探测行为
日志爆炸和性能卡顿往往源于没做粒度控制
审计不是开得越全越好。内核每拦截一次系统调用都要走完整审计路径，频繁调用（如库文件读取、DNS 查询）会拖慢系统。
- 避免监控整个
/usr或/lib：优先锁定具体子路径，比如只监/usr/bin/sudo而非/usr/bin/ - 排除干扰路径：在规则中用
-F path!=/usr/lib/modules/排除内核模块目录，防止固件更新触发大量误报 - 限制日志容量：检查
/etc/audit/auditd.conf中max_log_file（建议 10–20MB）和num_logs（建议 5–10），避免磁盘被占满 - 日志轮转后记得 reload：修改
auditd.conf后需sudo systemctl kill --signal=SIGHUP auditd或重启服务，否则新配置不生效
-w 规则，而是判断某个行为背后到底触发了哪个系统调用、是否跨架构、会不会被权限模型过滤掉。很多规则看似写了，实则静默失效——得靠 ausearch -i 看原始字段，而不是只信 auditctl -l 的输出列表。
