SSRF端口扫描：一个被低估的漏洞内网渗透入口

某次攻防演练中，目标站点的端口图片预览功能成了突破口。攻击者将URL参数改为`http://127.0.0.1:3306`，扫描响应时间瞬间多了3秒——数据库端口开着。漏洞更致命的端口是，内网某台Redis服务直接返回了`-ERR wrong number of arguments`，扫描这行错误信息让攻击者确认了服务版本。漏洞整个过程没触发任何WAF告警，端口因为请求看起来只是扫描"普通的外链预览"。

SSRF（服务端请求伪造）的漏洞核心问题在于：服务器替攻击者发起了网络请求。端口扫描只是端口它的常规操作，但很多人低估了它的扫描精准度。与传统的漏洞SYN扫描不同，SSRF扫描不直接触碰目标，端口而是扫描借刀杀人——流量来自受信任的服务器，防火墙规则形同虚设。你可以用`dict://`协议探测内网Redis，用`gopher://`构造完整TCP包，甚至用`file://`读取本地文件配合报错信息判断端口状态。

判断端口是否开放有个笨但有效的土办法：看响应时间。开放端口通常立即返回错误或握手数据，关闭端口则要等TCP超时。某次测试中，我向目标内网IP的8000-9000端口段发送请求，通过记录每个端口的响应延迟，半小时内画出了内网服务拓扑图——某个管理后台的8080端口暴露了，而它本不该出现在公网可达路径上。

更棘手的是协议混淆。当目标服务器支持`http://`和`dict://`时，你可以对同一端口发送不同协议请求。比如对6379端口发`dict://host:6379/info`，如果返回Redis版本信息，就能直接确认服务类型。这比单纯判断端口开放更有价值——扫描结果直接关联到攻击路径。曾经有人用这个方法发现内网Jenkins的8080端口不仅开放，还允许未授权访问，后续直接拿到了构建服务器的shell。

但别高兴太早。现代应用普遍会做内网IP过滤，比如检查URL中的host是否为公网地址。绕过手段也不少：用`127.0.0.1`的十六进制形式`0x7f000001`，或者用短域名解析到内网IP，甚至利用跳转协议——如果应用跟随302重定向，你可以让外网域名重定向到内网地址。某次测试中，我通过`http://redirect.example.com/?url=http://192.168.1.1:22`成功触发了SSRF，因为应用只校验了初始URL，没检查重定向后的地址。

端口扫描只是SSRF的第一步。真正危险的是将扫描结果与后续攻击结合：发现8080端口开放后，尝试访问`/actuator/env`获取环境变量；发现3306端口后，用`gopher://`构造MySQL握手包暴力破解弱口令。这些操作都隐藏在正常HTTP请求中，日志审计很难察觉异常。

防护角度有个常被忽略的点：出站流量监控。多数团队只关注入站攻击，却忘了服务器主动发起的连接也需要管控。在服务器上限制出站协议和端口，远比在应用层过滤参数更有效。比如仅允许`http://`和`https://`出站，禁止`dict://`、`gopher://`等危险协议——这能直接掐断大部分SSRF攻击路径。

最后说点个人看法：SSRF端口扫描的威胁被很多人低估了，因为它不像SQL注入那样直接返回数据，但它是内网渗透的"地图测绘工具"。一次成功的扫描能让你了解内网结构、服务类型、版本信息，这些情报的价值远超单个漏洞利用。下次看到应用里有URL预览或文件下载功能时，不妨想想：这个请求到底会去向哪里？