深度审计核心.so库非法替换需用auditd监控真实路径的写入与属性变更（-p wa），捕获cp/mv/ln/touch/openat等操作，结合chattr +i、rpm -V校验及临时目录加载监控形成闭环防护。
要深度审计系统核心 .so 动态链接库（如 /lib64/libc.so.6、/usr/lib64/libssl.so.1.1）的非法替换行为，关键不是盯着“谁在用”，而是精准捕获“谁在改”——因为替换必然触发写入或元数据变更，auditd 在内核调用层能如实记录 cp/mv/ln -sf/touch/chmod 等全部操作，且无法被用户空间绕过。
一、锁定高危目标路径，按真实文件监控
核心 .so 库通常位于以下路径，需逐个确认真实路径（避开符号链接干扰）：
-
/lib64/libc.so.6→ 用readlink -f /lib64/libc.so.6获取实际 inode 路径 -
/usr/lib64/libssl.so.*、/usr/lib64/libcrypto.so.*（OpenSSL 核心） -
/lib64/ld-linux-x86-64.so.2（动态链接器本身，极高危） -
/usr/lib64/libsystemd.so.*（systemd 生态依赖）
⚠️ 注意：不能监控 /usr/lib64/libssl.so 这类软链接本身，必须监控 readlink -f 返回的真实文件路径，否则替换操作不会触发日志。
二、配置最小必要审计规则（-p wa），并固化生效
对每个确认后的绝对路径添加独立规则，仅捕获写入与属性变更，避免噪音：
sudo auditctl -w /lib64/libc-2.28.so -p wa -k libc_replacesudo auditctl -w /usr/lib64/libssl.so.1.1 -p wa -k libssl_replacesudo auditctl -w /lib64/ld-2.28.so -p wa -k ld_replace
永久保存至规则文件：
sudo tee /etc/audit/rules.d/20-core-so.rules <p>重载并验证：<code>sudo augenrules --load && sudo auditctl -l | grep -E "(libc|libssl|ld)_replace"</code></p><h3>三、识别替换行为的关键日志特征</h3><p>合法更新（如 <code>yum update glibc</code>）由包管理器触发，日志中 <code>comm=</code> 为 <code>dnf</code>/<code>rpm</code>/<code>dpkg</code>；非法替换则暴露异常模式：</p>
-
comm="cp"或comm="mv"且exe="/bin/cp"，同时uid!=0或auid!=uid（提权痕迹） -
comm="ln"+syscall=265（symlinkat）+path="/lib64/libc.so.6"，说明在硬替换符号链接目标 -
comm="touch"+path="/lib64/libc.so.6"+perm=a，可能为篡改时间戳掩盖行为 -
syscall=257（openat）带O_WRONLY|O_TRUNC标志，是覆盖写入最直接证据
快速筛查命令：sudo ausearch -k libc_replace -m SYSCALL -i | grep -E "(cp|mv|ln|openat.*w|touch)"
四、补充防护闭环，防止审计被绕过
auditd 记录行为但不阻止，需叠加以下机制形成纵深防御：
-
设为不可变：对已知稳定版本的核心库执行
sudo chattr +i /lib64/libc-2.28.so（维护前需chattr -i） -
定期哈希校验：RHEL/CentOS 上运行
sudo rpm -V glibc openssl；Debian/Ubuntu 执行sudo dpkg --verify libc6 openssl -
限制写权限：确保
/lib64/和/usr/lib64/下所有.so文件权限为644或755，非 root 不可写（默认满足） -
监控加载源：额外加一条规则
-a always,exit -F arch=b64 -S openat -F path=/tmp/ -F path=/dev/shm/ -k so_load_tmp，捕获从临时目录加载恶意.so的尝试
不复杂但容易忽略：只加 -p w 会漏掉 chmod 配合 cp --no-preserve=mode 的绕过手法，-p wa 才真正覆盖全部替换路径。
