从SSRF排查到出站访问控制体系

很多团队处理 SSRF 的第一反应是加正则、封掉常见内网段，改完代码以为事情结束了，结果下次排查还是能看到“绕过”两个字。这种尴尬往往不是因为代码写得糙，而是检查的位置放错了：一直盯着用户输入的那串字符，却没看服务器自己到底能走到哪里去。

SSRF 说白了就是服务器替用户跑腿。用户递过来一个链接，服务器真的去访问了，这在业务里是刚需：链接预览、远程图片下载、Webhook 回调、网页转 PDF、远程导入文件，全是这个套路。功能本身没毛病，毛病在于服务器能到达的地方，比普通用户多太多。

所以排查的第一步不是翻漏洞报告，而是把所有“由服务器主动发起请求”的功能列出来。判断标准可以很朴素：用户能不能影响到最终请求的地址、Host、协议或端口。哪怕中间拼接了、编码了、转手存进了数据库，只要用户输入能左右最终目标，就在重点核查范围内。顺着代码里发起请求的调用往下追 URL 来源，比漫无目的地读代码有效得多。

先看服务器站在哪儿

同一个功能，部署位置不同，后果差得很远。放在公有云上又没做安全组限制，攻击者可能借这台机器去访问云元数据地址，顺手拿走临时凭证；放在内网，它就可能变成横向探测其他资产的跳板。这一步要梳理的是服务器自身的可达范围：回环地址、内网保留段、云元数据地址，以及那些解析后指向内网的域名。

这里别迷信黑名单。同一个地址能写成十进制、十六进制、IPv4 映射的 IPv6 形式，单纯做字符串匹配根本挡不住。但凡把限制写在应用层靠“认字符串”的地方，绕过去只是时间问题。

关卡应该挪到出站口

验证环节最好在隔离环境里真跑一遍，不是为了造攻击载荷，而是确认现有校验到底有几斤几两。关注几件事：域名解析后的 IP 会不会变、重定向跟不跟、协议是否只放行 http 和 https、端口有没有收紧。跑完留下一张清单，写清楚哪条有效、哪条能被绕过，后面的加固才有依据。

加固的思路是分层。应用层能做白名单就做白名单，按域名后缀匹配，别按前缀。网络层则默认拒绝服务器的出站访问，只放行必要出口。这两层里，真正靠得住的是网络层：应用层决定“能不能访问”，网络层决定“访问了会怎样”。

还差一环是日志和告警。出站请求的目标、端口、发起来源都记下来，碰到内网地址或元数据地址直接告警。新规则上线前先只记不拦，跑一两周看看会误伤哪些正常流量，再灰度收紧，顺手准备好回滚。

SSRF 没有一劳永逸的方案。真正拉开差距的，是有没有把思路从“检查用户输入”换成“控制服务器能访问什么”，以及每次排查完有没有留下资产清单和网络边界图。下次再遇到，就不是从零开始了。