auditctl不能用-w直接监控UID，因为-w模式不支持auid过滤字段，必须用-a always,exit搭配-S系统调用和-F auid=N才能精准溯源用户行为，auid是登录会话初始UID，不受sudo提权影响。
auditctl 不能用 -w 直接监控 UID
很多人想写 auditctl -w /home/test -p rwxa -F auid=1000 来抓特定用户操作，结果规则静默失效。因为 -w 是路径监控模式，内核不支持在该模式下使用 auid 过滤字段——它只认 uid、gid 等运行时字段，而 auid 只在系统调用规则（-a）中有效。
真正起作用的是监听系统调用：用户所有文件打开、读写、执行动作，本质都是触发 openat、read、execve 等内核入口。必须用 -a always,exit 搭配 -S 和 -F auid=N 才能锁定“谁发起的”，而不是“当前进程是谁”。
-
auid是登录会话初始 UID，哪怕sudo su -切成 root，auid仍是原始用户 ID；uid和euid在提权后就变成 0，无法溯源 - 64 位系统必须显式加
-F arch=b64，否则可能漏掉部分调用；若机器跑 32 位程序（如旧容器或 i386 工具），还得补一条-F arch=b32规则 - 常用系统调用建议至少覆盖：
open、openat、read、write、execve、unlink、unlinkat
怎么验证 auid 规则真生效了
别等真实业务操作再查日志，容易错过或混淆。用测试账号主动触发 + ausearch 即时验证最可靠：
- 先确认目标用户 UID：
id -u testuser，确保是你要审计的那个数字（比如 1000） - 用该用户身份执行一个简单动作：
sudo -u testuser touch /tmp/audit_test - 立刻查日志：
sudo ausearch -k user_1000_file_ops -i -ts today | grep "auid=1000"（加-ts today防止默认只查 24 小时外的日志） - 关键看输出里有没有
auid=1000，且comm字段是touch、name字段是/tmp/audit_test
如果没结果，检查两件事：sudo auditctl -l 看规则是否加载成功；sudo systemctl is-active auditd 确认服务正在运行。
规则怎么永久保存不丢
临时加的 auditctl -a 规则重启 auditd 或机器重启后就没了。要持久化，必须走 augenrules 流程：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 把规则写进
/etc/audit/rules.d/下的.rules文件，例如：/etc/audit/rules.d/20-uid-1000.rules - 内容格式严格：每行一条规则，不能有空行或注释（# 开头会被忽略），结尾不加换行符
- 写完必须运行：
sudo augenrules --load—— 不是systemctl restart auditd，后者不会重新编译规则文件 - 验证加载：
sudo auditctl -l | grep "auid=1000"，能看到对应规则才算成功
注意：augenrules 会按文件名顺序合并所有 .rules，所以建议用数字前缀控制优先级（如 10-base.rules、20-uid-1000.rules）。
审计用户账号本身也要权限隔离
如果专门建了个 sjyh 或 audituser 账号用于查日志，别忘了限制它只能看，不能改：
- 禁止 shell 登录：
sudo usermod -s /usr/sbin/nologin sjyh - 只授权必要命令：
sjyh ALL=(root) NOPASSWD: /usr/bin/ausearch, /usr/bin/aureport, /usr/bin/tail, /usr/bin/cat，写进/etc/sudoers（用visudo编辑） - 严禁给
ALL或/bin/bash权限，否则审计账号反而成了跳板
真正难的不是加几条 auditctl 命令，而是理解 auid 和 uid 的生命周期差异、规则加载机制、以及审计账号自身的最小权限落地——这三块漏掉任何一块，审计就形同虚设。
