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 日志怎么对上时间戳？
sudo 记录的是用户发起请求的时间，auditd 记录的是内核真正执行系统调用的时间，两者差值可能达数百毫秒——尤其当命令触发 SELinux 策略检查、PAM 模块阻塞或磁盘繁忙时。
不能靠“同一秒”来关联，得用上下文字段交叉验证：
-
ausearch -m execve -ui <code>id -u username找该用户的全部 execve 事件 - 对比
sudo日志里的TTY和auditd事件中的acct字段（如acct="root"+exe="/usr/bin/sudo"）定位 sudo 进程本身 - 再顺藤摸瓜找它的子进程：
ausearch -m execve -p <code>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字段长什么样，再照抄进规则 - 32 位兼容问题：x86_64 系统上运行 32 位程序（如旧版 python2.7），需额外加
-F arch=b32规则，否则完全捕获不到
审计不是开个服务就完事，真正难的是让每条规则都命中真实行为，又不被绕过、不被淹没。最容易被忽略的是子进程继承和跨架构执行这两个盲区，一不留神就漏掉横向移动的关键痕迹。
