auditd捕获失败安全事件的关键是使用-a always,exit配合-f success=no过滤，而非-s all；需聚焦execve、openat、ptrace等高风险调用的拒绝行为（如eacces/eperm），并绑定-k标签与上下文（auid、comm、path）以支持精准溯源和ausearch检索。
auditd 默认只记录系统调用的“入口”或“出口”，但要捕获失败的安全事件（如权限不足导致的 execve 失败、open 拒绝、ptrace 被拒），关键不是加 -S all，而是明确指定 exit 链路 + success=no 过滤，并结合高风险调用与上下文精准锁定。
只监控 exit 事件并过滤失败结果
系统调用在内核中分 entry（进入）和 exit（退出）两个阶段。失败信息（如 EACCES、EPERM、EACCES）只在 exit 阶段返回。因此所有规则必须用 -a always,exit，再加 -F success=no 精准捕获失败动作：
-
sudo auditctl -a always,exit -F arch=b64 -S execve -F success=no -k failed_exec→ 记录所有执行失败（如普通用户尝试运行 /usr/bin/passwd 但被 SELinux 或 DAC 拦截） -
sudo auditctl -a always,exit -F arch=b64 -S openat,open -F path=/etc/shadow -F success=no -k denied_shadow_access→ 只当有人试图打开 /etc/shadow 却被拒绝时才记日志 -
sudo auditctl -a always,exit -F arch=b64 -S ptrace -F success=no -k failed_ptrace→ 捕获调试/注入尝试失败（例如非目标进程 PID、无权限 attach）
聚焦真正高风险的失败行为
不是所有失败都值得记录。应优先覆盖攻击链中“试探性失败”环节，这些往往预示横向移动或提权尝试：
- 权限提升类失败：setuid、setgid、setreuid、capset —— 攻击者常反复试错绕过限制
- 敏感文件访问失败：对 /etc/shadow、/proc/*/mem、/sys/module/*/parameters 的 open/openat/mmap 失败
- 调试与内存操作失败：ptrace（尤其 PTRACE_ATTACH/PTRACE_PEEKDATA）、mprotect（尝试改写不可写内存页）
- 网络监听失败：socket、bind（如非 root 用户尝试 bind 到 80 端口）
确保失败事件能被检索和识别
仅记录不够，还要让日志可读、可定位。失败事件常伴随完整上下文，但需正确配置才能解析：
- 必须带
-k 标签名，否则ausearch -k failed_exec -i无法快速过滤；不加-i会看到 raw uid=1001、comm=12345，无法还原命令名 - 失败事件仍含
comm（触发命令名）、exe（实际执行路径）、auid（原始登录用户）、cwd（当前目录），可用于溯源 - 若
comm="(unknown)"，说明进程已退出，需结合ppid（父进程 ID）和exe向上追溯调用链 - 避免混用
-F perm=x或-p r：失败通常不涉及“读取成功”，这类过滤反而漏掉真实拒绝事件
生产环境注意事项
失败事件虽比成功事件少，但高频试探（如爆破 sudo 密码、遍历 /proc/*/mem）仍可能引发日志激增：
- 禁用全局失败监控：
-a always,exit -S all -F success=no会导致海量无关失败（如 cron 定时任务查不到文件） - 限制用户范围：对非必要账户（如服务账号、批量脚本用户）加
-F uid>=1000或排除-F uid=999 - 配合 auditd.conf 控制输出：设置
admin_space_left = 50M和max_log_file_action = ROTATE，防止磁盘写满中断审计 - 规则须落盘：临时
auditctl规则重启即失，务必写入/etc/audit/rules.d/fail.rules并执行sudo augenrules --load
