最可靠方式是用find -type l -exec test ! -e {} \; -print定位失效软链接，再人工筛查是否指向/etc/shadow等敏感路径；但仅指向敏感路径不构成攻击，风险取决于是否被可信程序访问及目标是否真实可读。
直接用
find -type l -exec test ! -e {} \; -print
定位所有真正失效的软链接，再结合路径特征人工筛查是否指向敏感位置（如
、
、
等），是识别潜在软链接攻击陷阱最可靠的方式。Linux 原生命令无需额外工具，也不依赖非标准参数。
为什么“指向敏感路径”本身不等于攻击？
软链接只是存储路径字符串，它是否构成风险，取决于两点：一是该链接是否被可信程序或用户主动访问；二是目标路径是否真实存在且可被当前上下文读取/执行。
例如：
创建后，只要没人用
或程序自动读取它，就只是个普通死链，不触发权限泄露；
但若某 Web 应用配置了
，而你又在
下创建了指向
的软链接，外部请求
就可能绕过预期限制——这才是真正的攻击面。
快速筛查可疑软链接的实操命令
在关键目录（如
、
、
）中运行以下组合命令，聚焦高风险线索：
CentOS Linux 7.9.2009
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
下载
列出所有软链接及其目标：
筛选出目标含敏感关键词的链接（不区分大小写）：
定位“存在但指向危险路径”的链接（非死链，需重点审计）：
修复前必须验证的三件事
发现可疑链接后，切勿直接删除或覆盖。先确认：
谁创建的？
用
查看 ctime/mtime 和属主，判断是否为运维行为还是异常写入；
谁在用它？
用
或检查 Web 日志、定时任务、启动脚本中是否引用该链接名；
目标是否真敏感？
比如
类链接常出现在调试场景，而
被硬链接到 Web 可读目录则必须立即处理。
安全修复策略（按风险等级推荐）
根据链接用途与环境，选择对应方式：
确认为恶意或误配：
先备份再移除：
（禁用比删除更利于溯源）；
属业务所需但路径暴露：
改用受限跳转，如 Nginx 中用
替代软链接，或加
；
开发测试残留：
统一清理并加入 CI 检查项，例如在部署前运行：
。
/etc/shadow/root/.ssh/proc/self/fdln -s /etc/shadow ~/myconfcat ~/myconfAlias /backup /var/www/backup/var/www/backup/etc/backup/passwd/var/www/tmp/homefind /var/www -type l -ls 2>/dev/nullfind /var/www -type l -exec readlink {} \; 2>/dev/null | grep -iE "(etc|root|proc|sys|\.ssh|\.pgpass)" | sort -ufind /var/www -type l -exec test -e {} \; -exec readlink -f {} \; 2>/dev/null | grep -iE "(\/etc\/shadow|\/root\/\.ssh|\/proc\/[0-9]+\/fd)"stat 链接名lsof +D /path/to/dir/proc/self/fd/3/etc/shadowmv suspicious_link suspicious_link.bak && chmod 000 suspicious_link.bakaliaslocation ~ \.shad?ow$ { deny all; }find $APP_ROOT -type l -exec readlink -f {} \; 2>/dev/null | grep -qE "^/(etc|root|proc)" && echo "FAIL: sensitive symlink found" && exit 1