具体编写audit.rules需每条规则明确监控目标、触发条件和可追溯标签：如-w /etc/shadow -p wa -k identity_change监控关键文件写与属性变更，-a always,exit -f arch=b64 -s execve -f auid!=0 -k privileged_cmd绑定架构、会话uid和事件标签，避免空泛规则。
audit.rules 文件里怎么写才算“具体”
所谓“具体”，不是堆规则，而是每条规则必须有明确监控目标、触发条件和可追溯标签。空泛的 -a always,exit -S execve 会记录所有命令执行，但无法区分正常运维和可疑行为；真正有用的规则要绑定 auid、arch、路径或系统调用参数。
实操建议：
- 敏感文件监控必须用
-w+-p wa（写+属性变更），不能只写-p w——改属主、改权限这些操作不会触发纯w - 监控
/bin/ls这类二进制时，规则写成-w /bin/ls -p x -k binary-exec，否则只监写不监执行，毫无意义 - 排除 root 用户的日常操作干扰：加
-F auid!=0（注意不是uid!=0，auid是登录会话初始 UID） - 64 位系统必须显式指定
-F arch=b64，否则execve规则在混架构环境里可能漏掉一半调用
为什么 auditctl 临时加的规则重启就丢
因为 auditctl 只操作内核审计子系统的运行时规则链表，不触碰磁盘配置。服务重启后，内核规则清空，auditd 启动时只加载 /etc/audit/rules.d/ 下的 .rules 文件。
常见错误现象：
- 执行
auditctl -w /etc/shadow -p wa -k shadow-mod后立刻能搜到日志，但 reboot 后ausearch -k shadow-mod返回空 -
auditctl -l显示规则存在，systemctl restart auditd后再查就没了
正确做法：
- 把规则写进
/etc/audit/rules.d/immutable.rules（文件名任意，但必须以 .rules 结尾） - 规则末尾加
-D清空旧规则再加载新规则，避免重复叠加（例如-D -w /etc/passwd -p wa -k passwd-change） - 不要直接改
/etc/audit/rules.d/audit.rules—— 它常被包管理器覆盖，用独立文件更稳妥
ausearch 查不到刚发生的事件？先看这三件事
ausearch 不是实时 tail，它查的是已刷入 /var/log/audit/audit.log 的记录。如果刚触发事件却搜不到，大概率卡在缓冲或格式环节。
排查步骤：
- 检查
auditd是否真在运行：systemctl status auditd，状态为active (running)才算生效 - 确认日志是否被刷盘：
sudo cat /proc/sys/kernel/audit_backlog_limit，值太小（如默认 64）会导致高并发时丢事件 - 验证规则是否命中：
sudo ausearch -m CONFIG_CHANGE -i | grep "key=.*your-key"，没输出说明规则根本没加载成功 - 别用
ausearch -f /path查文件访问——它查的是 path 字段匹配，而实际日志中路径常带name=或item=前缀，应优先用-k your-key
auditd 日志轮转后搜索失效怎么办
默认 max_log_file_action = ROTATE，日志滚动后旧文件变成 audit.log.1、audit.log.2.gz 等，ausearch 默认只查当前 audit.log。
解决方法很直接：
- 查历史日志必须指定文件：
ausearch -i -f /var/log/audit/audit.log.1 -k passwd-change - gzip 压缩的日志需先解压再查，
zcat /var/log/audit/audit.log.2.gz | aureport -f -i比硬解压更省事 - 长期归档场景下，别依赖本地轮转——
auditd.conf中配log_format = ENRICHED并搭配audispd-plugins转发到远程 SIEM，避免本地磁盘撑爆后丢失关键窗口
最易被忽略的一点：规则里的 -k 标签一旦写错（比如拼写不一致、大小写混用），后续所有 ausearch -k 都查不到对应事件——它不模糊匹配，也不报错，只是静默失败。
