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