auditd 捕获 root 敏感命令需三重监控：root 启动的 bash/python/perl、敏感文件写入、含 chmod 777 等参数的 execve；须用 -a always,exit -F arch=b64 -S execve -F euid=0 精准捕获，并补 b32 规则防 32 位绕过。
auditd 捕获 root 权限下的敏感命令执行Linux 自带的 auditd 是最轻量、最可靠的内核级审计手段，比 shell history 或 sudo 日志更难绕过。关键不是“开了 auditd”，而是要精准匹配真实攻击链中常被滥用的操作路径。
必须监控的三类行为：/bin/bash、/usr/bin/python*、/usr/bin/perl 被 root 启动；/etc/shadow、/etc/passwd、/root/.ssh/authorized_keys 被写入；execve 系统调用中出现 chmod 777、chown root:root 等危险参数。
-w /etc/shadow -p wa：这会漏掉通过 dd、cp --no-preserve=all 等绕过权限检查的修改-a always,exit -F arch=b64 -S execve -F euid=0 捕获所有 root 进程的启动，再配合 -F exe=/usr/bin/python3 等细化过滤/etc/audit/rules.d/sensitive.rules，加载前先 augenrules --load，避免重启后失效ausearch 查不到刚执行的命令？时间与缓冲区陷阱ausearch 默认只查已落盘的日志，而 auditd 有内存缓冲和异步写入机制。刚执行的命令可能还在 ring buffer 里，或因磁盘 I/O 延迟未刷到 /var/log/audit/audit.log。
ausearch -m execve -ts recent（recent 表示最近 10 分钟）比 -ts today 更可靠
区状态：auditctl -s | grep "backlog"，若 backlog_limit 被设为 0 或过小，高频操作会丢日志auditctl -e 0 && auditctl -e 1（禁用再启用 auditd，触发 flush）flush 设为 sync（/etc/audit/auditd.conf 中 flush = sync），但会轻微增加系统调用延迟sudo 记录的是用户发起请求的时间，auditd 记录的是内核真正执行系统调用的时间，两者差值可能达数百毫秒——尤其当命令触发 SELinux 策略检查、PAM 模块阻塞或磁盘繁忙时。
不能靠“同一秒”来关联，得用上下文字段交叉验证：
ausearch -m execve -ui id -u username 找该用户的全部 execve 事件sudo 日志里的 TTY 和 auditd 事件中的 acct 字段（如 acct="root" + exe="/usr/bin/sudo"）定位 sudo 进程本身ausearch -m execve -p pid_of_sudo，这才是真实执行的命令sudo -i 或 sudo su -，后续所有命令都属于新 shell 的子进程，需递归追踪 ppid
auditctl -l 显示规则，但 ausearch 无结果？最常见原因是规则没生效，或匹配条件过于严格导致根本没触发。audit 规则不是“通配符模糊匹配”，而是精确字段比对，一个字段错就静默跳过。
auditctl -s | grep enabled 输出应为 enabled 1，不是 2（immutable mode 下无法动态加规则）strace -e trace=execve,openat,writev sudo ls /root 验证目标操作是否真触发了你要监控的系统调用ausearch -m execve -i | tail -10 看真实日志里 exe、cwd、comm 字段长什么样，再照抄进规则-F arch=b32 规则，否则完全捕获不到审计不是开个服务就完事，真正难的是让每条规则都命中真实行为，又不被绕过、不被淹没。最容易被忽略的是子进程继承和跨架构执行这两个盲区，一不留神就漏掉横向移动的关键痕迹。
