直接查看文件内容可快速判断：cat /etc/ld.so.preload，若非空（如含/tmp/.x.so）即被篡改；该文件默认不存在或为空，且权限不应开放写入，属主应为root，否则属异常。
怎么确认 /etc/ld.so.preload 被篡改了
直接查看文件内容是最快速的判断方式：cat /etc/ld.so.preload。如果输出非空（比如出现类似 /tmp/.x.so 或 /var/tmp/libhook.so 的路径），基本可断定已被植入。该文件本应为空或根本不存在——Linux 默认不创建它，任何内容都属于异常。
还要注意权限和属主：ls -l /etc/ld.so.preload。正常情况不该有写权限（尤其对 non-root 用户），若看到 -rw-rw-rw- 或属主是 daemon/nobody，就是强信号。
- 该文件被读取时机极早：在
main()执行前，由动态链接器ld-linux.so加载，所有用户态进程（包括ls、ps甚至bash）都会强制加载其中指定的 so - 恶意 so 常驻内存后，可能绕过常规进程检测（
ps看不到独立进程，但lsof -nP -p 1可能暴露异常库） - 有些后门会用绝对路径指向已删除文件（
/dev/shm/.a.so (deleted)），这时cat看不到内容，但readlink /proc/1/map_files/...或gdb -p 1 -ex 'info sharedlibrary' -ex quit才能发现
ld.so.preload 里写的路径为什么能生效
因为 glibc 的动态链接器硬编码了这个路径查找逻辑：只要文件存在且格式合法（ELF shared object）、有执行权限、符号表可解析，就会在每个进程启动时优先 dlopen() 它。它不校验签名，不检查是否在 LD_LIBRARY_PATH 中，也不受 secure-execution 模式限制（除非系统启用了 AT_SECURE 且 preloaded so 不满足 setuid 安全要求）。
这意味着哪怕你用 strace -e trace=openat,openat64 /bin/true，也看不到对那个 so 的 open 调用——它是链接器内部行为，不是用户代码发起的。
- 相对路径无效：必须是绝对路径，否则加载失败（
ld直接报cannot open shared object file） - 路径中不能含空格或特殊 shell 字符，否则解析中断，整行被跳过（但其他行仍有效）
- 多行支持：每行一个 so，空行和以
#开头的行会被忽略
清理时要同步处理的三个关键点
删掉 /etc/ld.so.preload 只是第一步。攻击者往往配套部署多个落点，只清文件等于留后门。
- 检查对应 so 文件是否还在磁盘：
ls -la $(cat /etc/ld.so.preload 2>/dev/null | head -n1)；若显示(deleted)，说明已被 rm 但句柄仍被进程占用，需找出处（lsof | grep deleted）并 kill 相关进程 - 检查 cron、systemd timer、
/etc/init.d/脚本里是否有自动恢复该文件的逻辑（常见于定时任务里echo "/tmp/x.so" > /etc/ld.so.preload） - 查 rootkit 是否已 hook
open()或stat()系统调用：用静态编译的busybox ls或从 Live CD 挂载根分区再检查，避免被运行时劫持干扰判断
如何防止再次被写入
最直接有效的是加不可变属性：chattr +i /etc/ld.so.preload。这样即使 root 用户也无法修改或删除，除非先执行 chattr -i。注意：该操作要求文件系统支持 ext2/3/4/xfs 等，btrfs 不支持 +i，zfs 需用 chmod A- 或设置 readonly=on。
如果系统不允许加锁（如容器环境或某些云主机），至少确保文件不存在且父目录权限收紧：rm -f /etc/ld.so.preload && chmod 755 /etc，并加入定期校验（例如用 sha256sum /etc/ld.so.preload 2>/dev/null || echo "missing"）。
真正难防的是攻击者已获得 root 权限——此时他可以卸载文件系统、绕过 chattr、甚至 patch 内核。所以重点不在“怎么锁死”，而在“怎么早发现”：把 /etc/ld.so.preload 加入 HIDS（如 aide、samhain）监控列表，或用 inotifywait -m -e create,modify /etc 做实时告警。
别忘了检查 /etc/ld.so.cache 和 /etc/ld.so.conf.d/ 下的配置，它们虽不等同于 preload，但也可被用来持久化恶意库路径，且更隐蔽。
