2001年，预测我还在用一台二手ThinkPad T20拨号上网。漏洞那台机器跑着Windows 2000，预测装了个Serv-U FTP Server，漏洞用来给几个朋友传文件。预测有天晚上我翻日志，漏洞发现一个陌生IP在反复连接，预测每次连上来只做一件事：发PASV命令，漏洞然后立刻断开。预测我数了一下，漏洞两小时内它试了将近四百次。预测

当时我没意识到，漏洞这就是预测后来被安全圈翻来覆去讲的FTP PASV端口可预测问题。那个陌生IP不是漏洞在攻击我，它在扫描——它在根据我服务器返回的预测被动模式端口号，推算下一次可能开放的端口范围。

PASV到底干了什么

FTP协议有两个通道：控制通道走21端口，数据通道另开。主动模式（PORT）下，是服务器主动连客户端，客户端告诉服务器“你来连我某个端口”。被动模式反过来，客户端发PASV，服务器回一句“你来连我某个端口”，然后客户端去连。

问题出在服务器那句回复里。服务器得从自己的端口池里挑一个空闲端口，告诉客户端。Serv-U、ProFTPD、vsftpd、IIS FTP这些实现，早期版本挑端口的方式非常“规律”——要么从某个基准端口开始顺序递增，要么按固定步长跳。比如vsftpd早期默认从1024往上扫，找到一个空闲的就用。ProFTPD有些配置里端口范围是连续的，用过的端口释放后很快会被下一个连接复用。

这意味着什么？攻击者不需要猜几万个端口。他知道你上次用了50000，下次大概率是50001，再下次50002。他只需要在控制通道上不断发PASV，观察返回的端口号，就能把可预测的窗口缩到很小。

那个年代的真实利用方式

最直接的玩法是FTP bounce攻击的变种。攻击者连上你的FTP服务器，发PASV拿到一个端口号，然后利用PORT命令让服务器去连第三方主机的某个端口。因为端口可预测，他可以精确地把数据连接导向目标主机的特定服务。Nmap里有个ftp-bounce脚本，就是干这个的。

更隐蔽的一种是端口扫描。攻击者控制一台FTP服务器，让它去连目标IP的某个端口。如果端口开放，FTP数据连接会建立或返回特定错误码；如果关闭，返回另一个错误码。因为PASV端口可预测，攻击者能稳定地复用同一条控制连接做多次扫描，不用每次重新握手。

我当年那台Serv-U日志里反复出现的PASV，事后回想，大概率就是某个脚本小子在用FTP bounce扫内网。他每次只发PASV不传数据，是在探测我服务器返回端口的规律。

为什么现在还在提这件事

FTP本身已经边缘化了，但PASV端口可预测的逻辑没有消失。很多IoT设备、老旧的工控系统、甚至一些云服务的内网文件传输组件，还在跑FTP或类FTP协议。更关键的是，这个漏洞的本质——服务器在分配临时端口时使用可预测的算法——在NAT穿透、P2P打洞、RTP/RTCP端口分配里反复出现。

2019年有个CVE（CVE-2019-……具体编号我记不清了）就是某款企业级FTP网关的PASV端口池用线性同余生成器分配，被安全研究员用几百次采样就重建了完整端口序列。厂商的修复方式也很直接：换成加密安全的随机数生成器，或者干脆让端口池足够大且随机化步长。

我自己现在的做法很简单：内网FTP只走SSH隧道，公网FTP直接关掉。如果非要开，在防火墙层面限制PASV端口范围，并且确保这个范围足够大、分配算法不连续。Serv-U后来的版本加了个选项叫“随机化被动端口”，我试过，抓包看确实不再线性递增了。

那个2001年的夜晚，我最后做的事是把Serv-U的PASV端口范围从默认的1024-65535改成了50000-50100，然后重启服务。陌生IP又试了几次，没再找到规律，走了。我当时不知道自己在修什么，只是觉得“别让它猜得太容易”。现在回头看，那大概是我第一次凭直觉做对了一件事。