摘要

  • 1985 年的 FTP 把控制会话与文件数据连接分开，客户端可以用 PORT 安排两台服务器直接传文件，并指定数据连接的另一端。
  • 1999 年的 RFC 2577 指出，同一机制也能让 FTP 服务器向无关服务发起连接，替真正下指令的人送出数据。

假设你只有一条慢网线，却要把甲仓库的箱子送进乙仓库。先把箱子运回家，再送去乙地，未免像故意增加搬家公司的营业额。FTP 的办法很聪明：客户在两边下单，仓库之间自己开车。聪明到某个地步，司机才发现客户给他填的地址可以是第三家根本没下单的店。

1985 年 10 月的 FTP 规范 RFC 959 明确区分命令通道和传数据的连接。客户端分别控制两台 FTP 服务器，让一方等待，另一方连接，再把文件直接送过去。PORT 命令允许客户端指定另一个数据端点。规范甚至举了第三方主机与远程打印机这样的用途。对拨号、慢速链路上的用户来说，绕开自己的机器中转，确实省时间和流量。

这项便利把两种权力拆开了。选择目的地的是客户端，真正从网络上发起连接的是服务器。在正常的服务器对服务器传输中，目的地就是另一台参与传文件的机器。如果服务器照单全收，客户端也能写上别的服务的地址和端口。对被联系的服务而言，敲门者是 FTP 服务器；决定敲哪扇门的人仍坐在远处的控制通道上。

1994 年，Steve Bellovin 的 RFC 1579 从防火墙的角度看到了这套双通道设计的另一面。主动模式里，服务器要反过来连接客户端的某个端口，包过滤防火墙很难轻松放行。Bellovin 建议客户端改用 PASV：服务器先监听，客户端向外发起数据连接。他也提出过 APSV 的设想，并说明当时据他所知还没有实现。连接由谁主动建立，不再只是协议图上的箭头，而是防火墙管理员每天要处理的门禁问题。

地址格式也在变。1998 年 9 月的 RFC 2428 为 IPv6 和地址转换补上 EPRT、EPSV。EPRT 把网络协议族、地址和 TCP 端口写进扩展后的目的地说明。EPSV ALL 则让本次会话承诺只做两方传输；后来若要做三方传输，必须重新开会话。纸张换大了，表格也更清楚了，客户填写的终点究竟由谁把关，仍是旧问题。

1999 年 5 月的 RFC 2577《FTP Security Considerations》 直接给这个问题取名：弹跳攻击。客户端可以把第三台机器上某个服务的地址与端口写进 PORT，再让 FTP 服务器把一份文件送过去。若文件内容恰好是那个服务能理解的命令，服务器就成了替人出面的信使。RFC 举的例子是把 SMTP 命令存成文件，再借 FTP 服务器去联系第三台机器的邮件服务。真正准备内容的人无需直接连接目标机器；从目标看到的网络来客是 FTP 服务器。

防护方案没有免费的午餐。RFC 2577 建议服务器拒绝连接到 1024 以下的 TCP 端口，并对这样的 PORT 请求回答 504。高端口的服务仍可能受影响。限制文件权限，可以堵住先上传命令文件、再指使服务器转送的路径。彻底停用 PORT 也行，但服务器间直传这项功能会一起失去。作者认为大多数普通传输可走 PASV。要不要保留三方搬运，得由承担风险的服务器运营者作决定。

这一串文件讲的其实是运单上的一行字。1985 年，它帮慢连接省了大麻烦。1994 年，它碰到了防火墙。1998 年，它适配了新地址。1999 年，它终于被当成一项需要授权的行动：服务器可以替客户运文件，但不能把自己的网络身份当作一张无限目的地的车票。