关键不是监控所有.so，而是精准识别非标准路径加载、高风险上下文调用、绕过机制触发三类行为；需聚焦/tmp、/dev/shm、cwd等高危路径，结合openat/mmap/execve调用链与comm/exe/cwd/auid等上下文字段联合判定异常。
要让 Auditd 真正捕获系统库文件加载路径异常，关键不是“监控所有 .so”，而是精准识别 非标准路径加载、高风险上下文调用、绕过机制触发 这三类行为。盲目加 -w /usr/lib/ -p r 会淹没日志，反而漏掉真正的异常。
聚焦三类高危加载路径
系统库正常加载集中在 /lib、/lib64、/usr/lib、/usr/lib64；任何偏离这些路径的 .so 加载都需标记为可疑：
- /tmp、/dev/shm、/var/tmp 下的 .so 文件：攻击者常在此释放恶意库并 LD_PRELOAD 注入
- 当前工作目录（cwd）下的相对路径或点号路径：如 ./evil.so、../lib/exploit.so，常见于提权后本地执行
- 用户主目录或 /opt/*/lib 等非系统管理路径：除非明确白名单，否则应视为潜在侧载入口
审计规则必须覆盖核心系统调用链
仅监控 open 不够，.so 加载是“打开 + 可读可执行映射”两步动作。规则需同时捕获：
-
openat/open 调用中路径含 .so 且不在白名单目录：
-a always,exit -F arch=b64 -S openat,open -F path=/tmp/ -F perm=r -k lib_load_suspicious-a always,exit -F arch=b64 -S openat,open -F path=/dev/shm/ -F perm=r -k lib_load_suspicious -
mmap 映射含 PROT_READ|PROT_EXEC 的非标路径文件：
-a always,exit -F arch=b64 -S mmap -F a2&0x5==0x5 -F path=/tmp/ -k lib_map_suspicious
（a2&0x5==0x5 表示 prot 同时含 0x1 和 0x4） -
execve 启动时携带 LD_PRELOAD 或 LD_LIBRARY_PATH：
-a always,exit -F arch=b64 -S execve -F argc>=2 -F a2&0x7fff -F a2&0x8000 -k preload_injection
（捕获环境变量地址高位被置位，典型 LD_* 注入特征）
配合上下文字段过滤真实异常
单条 openat 日志无法定性，必须结合 comm、exe、auid、cwd 判断是否异常：
- comm 值异常：sh、python3、perl、bash —— 非标准 loader 进程名
- exe 路径非常规：指向 /tmp/xxx、/dev/shm/yyy 或无签名二进制
- cwd 在临时目录：cwd="/tmp" 或 cwd="/dev/shm" 是典型攻击现场
- auid 与 uid 不一致且 uid=0：提示可能通过 su/sudo 提权后加载，需关联前序事件
落地建议：分阶段启用 + 白名单收敛
避免一上来全量开启导致性能抖动或日志溢出：
- 先启用
/etc/ld.so.preload和LD_PRELOAD监控（低开销、高价值） - 再上线 mmap + openat 规则，但只针对 /tmp、/dev/shm、当前目录三个路径
- 运行 24 小时后用
ausearch -k lib_load_suspicious | aureport -f -i统计真实命中路径，逐步扩充白名单（如允许 /opt/app/lib/） - 所有规则统一打 -k lib_path_anomaly 标签，便于 ELK 中聚合告警和建仪表盘
