auditd规则需精确到文件而非目录，权限变更须用-s系统调用规则，-k关键字须唯一且小写，日志文件权限必须设为0600并确保auditd以root运行。
auditd 规则必须用 -w 指向具体路径，不能只写目录名
直接写 /etc 会监控整个目录树，但实际审计中常需精确到某个文件。比如改 /etc/sudoers 才算高危操作，而读 /etc/hosts 通常无需记录。若规则写成 -w /etc -p wa，会导致大量低价值日志刷屏，掩盖真正异常。
实操建议：
- 敏感配置文件必须单独加
-w：如-w /etc/sudoers -p wa -k sudo_mod、-w /etc/shadow -p w -k shadow_write - 目录监控要限制深度：对
/etc/ssh/这类子目录多的路径，优先监控关键文件（sshd_config、sshd_config.d/），而非整个/etc/ssh - 避免通配符：auditd 不支持
*.conf这类 shell 通配，必须逐个列出或用-w /etc/ssh/sshd_config.d/ -p wa监控整个子目录
权限变更（chmod/chown）必须用 -S 系统调用规则，不是 -w
-w 只能捕获对某个路径的访问事件，但用户执行 chmod 644 /tmp/test 时，auditd 并不“看到”这个文件被改权限——它看到的是进程调用了 chmod 系统调用。所以仅靠 -w /tmp/test 无法记录该行为。
实操建议：
- 监控权限修改必须用
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -k perm_change - 同时补上属主变更：
-a always,exit -F arch=b64 -S chown,fchown,fchownat -k owner_change - 注意架构参数：x86_64 系统必须同时加
-F arch=b64和-F arch=b32，否则 32 位程序（如某些旧版工具）的调用会漏掉
audit.rules 中 -k 关键字不能重复，否则 ausearch 会混搜
多个规则共用同一个 -k 值（比如都写 -k security），后续用 ausearch -k security 查日志时，会把 sudo 执行、shadow 修改、crontab 编辑全混在一起，根本没法定位问题源头。
实操建议：
- 按行为类型区分关键字：
-k sudo_exec、-k shadow_write、-k cron_mod - 关键字尽量短且唯一，避免空格和特殊字符；
ausearch -k对大小写敏感，统一用小写 - 验证是否生效：
sudo touch /tmp/test && sudo chmod 777 /tmp/test后，运行ausearch -k perm_change | grep chmod应能精准匹配
auditd 日志权限必须设为 0600，且 /var/log/audit/ 目录为 0700
audit.log 文件默认权限常是 0644，普通用户可读。一旦攻击者拿到低权限 shell，就能直接 cat /var/log/audit/audit.log 看到所有 root 操作，等于审计形同虚设。
实操建议：
- 立即修复：
sudo chmod 0600 /var/log/audit/audit.log、sudo chmod 0700 /var/log/audit/ - 检查是否被绕过：如果 auditd 进程由非 root 用户启动（极少见但可能），日志文件权限再严也没用——务必确认
ps aux | grep auditd的 USER 列是 root - 轮转后权限丢失：logrotate 默认不保留权限，需在
/etc/logrotate.d/auditd中显式加create 0600 root root
/etc/passwd 写入，必须同时防住直接编辑、cp 覆盖、sed -i 替换这三种路径——而这需要组合 -w + -S execve + -S openat 多层规则，缺一不可。
