auditd未启动导致ausearch无记录，需systemctl enable –now auditd并加载内核模块；监控/etc/passwd应改用目录级规则-w /etc/ -p wa；execve不显示需添加对应规则并检查排除配置；日志暴增须精简规则、限制大小并排除容器路径。
auditd 服务没启动，ausearch 查不到任何记录
auditd 是 linux 审计日志的守护进程，不运行它，所有规则都只是纸面配置。很多环境装完系统默认没开 auditd，或者被 systemd 禁用。
实操建议：
- 检查状态：
systemctl status auditd，若为inactive (dead)，直接systemctl enable --now auditd - 确认内核模块已加载：
lsmod | grep audit，缺失时需检查内核是否编译了CONFIG_AUDIT（常见于某些定制或容器宿主机） - 注意：重启 auditd 后旧规则不会自动重载，必须手动
augenrules --load或service auditd restart（后者会 reload 规则）
想监控 /etc/passwd 修改，但 -w /etc/passwd -p wa 不生效
文件写入（w）和属性变更（a）权限监控依赖 inotify 或 fanotify，而 /etc/passwd 常被 pwconv、usermod 等工具间接修改（比如先写临时文件再 mv 覆盖），导致直接监本体失效。
实操建议：
- 改用监控目录级事件：
-w /etc/ -p wa -k etc_passwd_changes，配合ausearch -i -k etc_passwd_changes过滤 - 避免只盯单一路径：
/etc/shadow、/etc/group应一并加入规则 - 注意权限：audit 规则对符号链接无效，
/etc/passwd若是 symlink（如指向/usr/etc/passwd），需监控目标路径
ausearch -m SYSCALL -i 输出里看不到 execve 调用
默认 audit 规则不记录所有系统调用，execve 属于高频 syscall，常被显式排除或因性能考虑未启用。另外，-i 依赖 auditd 配置中 resolve_ids = yes 及本地用户/命令名解析能力。
实操建议：
- 确认规则存在：
auditctl -l | grep execve，若无，加一条：auditctl -a always,exit -F arch=b64 -S execve -k exec_monitor（x86_64） - 检查
/etc/audit/rules.d/*.rules是否含-a never,exclude -F msgtype=EXECVE类排除规则 -
-i解析失败时，先看原始字段：ausearch -m SYSCALL -f /var/log/audit/audit.log | grep execve，再人工对照/etc/passwd和/proc/[pid]/cmdline
审计日志暴增，/var/log/audit/audit.log 几分钟就几百 MB
过度宽泛的规则（如监控整个 /home 目录）、未过滤掉 systemd 或容器 runtime 的高频事件，都会让 audit.log 疯长，甚至拖慢系统响应。
实操建议：
- 禁用非必要 syscall 记录：在
/etc/audit/rules.d/99-noisy.rules中添加-a never,exclude -F msgtype=SYSCALL -F arch=b64 -S openat,read,write（按需删减） - 限制日志大小：
max_log_file = 50和num_logs = 5写入/etc/audit/auditd.conf，避免单文件失控 - 容器环境特别注意：若用 runc 或 containerd，需在 host audit 规则中排除
/run/runc、/var/run/docker.sock等路径，否则每个容器 exec 都打点
真正难的是平衡粒度与开销——监一个 sshd 进程比监全部 execve 稳定得多，但漏掉提权链里的隐蔽子进程；这些取舍没法靠模板解决，得看具体合规条款要求哪类行为必须留痕。