auditd服务默认不启动且不自启，需手动启用并重载规则；规则文件须以.rules结尾，修改后执行augenrules --load生效；监控命令需指定arch和key；日志轮转权限需通过log_group配置调整。
auditd 服务没启动，日志根本不会写
auditd 不是开机默认启用的服务，哪怕装好了也处于 inactive 状态。不手动启动并设为开机自启，auditctl 加的规则、/etc/audit/rules.d/ 里的配置全都没用——日志文件 /var/log/audit/audit.log 会一直为空或只含启动失败记录。
- 检查状态：
systemctl status auditd，看到inactive (dead)就得动手 - 立即启用：
sudo systemctl start auditd - 设为开机自启：
sudo systemctl enable auditd - 注意：RHEL/CentOS 8+ 和 Fedora 默认用
auditd，但某些精简镜像（如部分 Docker 基础镜像）压根没装，先确认rpm -q audit或dpkg -l auditd
规则加在 /etc/audit/rules.d/ 但不生效
规则文件放对位置只是第一步，auditd 启动时只读取 /etc/audit/rules.d/*.rules 并加载进内核，但不会自动 reload。改完文件后必须显式重载，否则旧规则继续跑，新规则躺在磁盘上“吃灰”。
- 重载命令不是
systemctl restart auditd（它会清空当前规则），而是：sudo augenrules --load -
augenrules会合并所有.rules文件，生成/etc/audit/audit.rules，再用auditctl -R加载 - 验证是否生效：
sudo auditctl -l查看当前已加载规则；sudo ausearch -m SYSCALL -ts recent看有没有捕获到操作 - 常见坑：文件名没以
.rules结尾（比如叫myaudit.conf），augenrules直接忽略
想监控用户执行的命令，但只看到 execve，看不到具体参数
audit 默认只记录系统调用入口（如 execve），不解析参数内容。要看到完整命令行（比如 rm -rf /tmp/*），必须开启 -F arch=b64（或 b32）并配合 -F key= 标记，否则日志里只有地址和长度，没法审计真实行为。
- 正确规则示例（监控所有 execve 调用并记录参数）：
## /etc/audit/rules.d/cmd.rules -a always,exit -F arch=b64 -S execve -k command -a always,exit -F arch=b32 -S execve -k command
-
-F arch=b64必须明确指定，否则 64 位系统可能只匹配到部分调用；混合架构服务器（如带 32 位兼容库）建议两条都加 -
-k command是关键标签，后续用ausearch -k command才能快速过滤 - 性能影响：高频命令（如 shell 循环中反复调用
ls）会显著增加日志量，生产环境慎用全局execve监控
日志轮转后 audit.log 消失或权限异常
auditd 自带日志轮转（通过 auditd.conf 中的 max_log_file 和 num_logs 控制），但轮转后的压缩文件（audit.log.1.gz）默认属主是 root:root，且权限为 600。如果审计分析脚本或 SIEM 工具用非 root 用户读取，会直接失败。
- 修改轮转行为：编辑
/etc/audit/auditd.conf，调整compress（是否 gzip）、max_log_file（单文件上限）、num_logs（保留份数） - 若需放宽读取权限，不能直接改文件 umask，而应在
auditd.conf中设置：log_group = adm，再把分析用户加入adm组 - 轮转触发时机：达到
max_log_file或每日零点（取决于flush配置），不是按时间滚动，别误以为“每天一个新文件” - 重要提醒：
audit.log被轮转后，ausearch默认只查当前文件，查历史得加-if /var/log/audit/audit.log.1显式指定路径
audit 规则一旦加载进内核就脱离配置文件独立运行，重启 auditd 会清空规则再重载，但内核模块本身不支持热更新——这意味着线上临时加一条规则，必须走 auditctl -a，而不是只改文件。这点和 systemd 或 nginx 完全不同，容易误判“改了配置就生效”。
