ftp pasv 端口可预测漏洞 解决

FTP的预测PASV模式端口可预测问题，本质上是漏洞服务器端在被动模式下开放端口范围过于固定且可被轻易枚举。很多运维人员以为只要把被动端口范围限制在某个区间就安全了，解决实际上攻击者根本不需要扫描全部65535个端口——只要连续观察几次数据连接，预测就能推算出端口分配规律。漏洞我见过最离谱的解决案例，某银行内部FTP服务器把被动端口固定死在50000-50010这11个端口上，预测防火墙规则倒是漏洞写得漂亮，但攻击者用脚本每秒发20个连接请求，解决五分钟就能把整个端口池摸透。预测

问题出在vsftpd这类主流FTP服务的漏洞实现上。默认配置下，解决被动端口分配往往是预测顺序递增的，比如第一次连接用了40000，漏洞第二次就40001，解决第三次40002。这种线性分配策略让端口预测变得极其简单，配合FTP协议本身是明文传输的特性，攻击者完全可以在数据连接建立前就预判端口号，然后抢先发送伪造的RST包切断合法传输，或者更阴险的——在端口上静默监听，等着窃取传输中的文件内容。

解决思路分三个层面。第一层是治标，把被动端口范围调大，比如从1024到65535全开，但这会让防火墙规则变得形同虚设，运维人员看到日志里海量的端口放行记录会疯掉。第二层是治本，改用随机端口分配策略。Linux内核2.6.24之后支持在sysctl里设置net.ipv4.ip_local_port_range为随机范围，但FTP服务本身还要配合修改。vsftpd有个参数叫port_promiscuous，默认NO时严格检查端口匹配，改成YES后允许非标准端口，但这又引入了新风险——等于告诉攻击者“我不校验端口来源了”。

真正靠谱的做法是放弃PASV模式，改用EPSV。EPSV是RFC 2428定义的扩展被动模式，服务器只告诉客户端一个端口号，客户端连接时不会像PASV那样暴露整个端口范围。但现实很骨感，很多老旧的嵌入式设备、银行核心系统的FTP客户端根本不支持EPSV，强行切换会导致业务中断。我去年帮一家物流公司迁移FTP服务，他们用的还是2005年买的扫描枪，固件里的FTP客户端只认PASV，最后只能妥协。

那怎么办？折中方案是给FTP服务加一层反向代理。用HAProxy或nginx的stream模块做TCP层转发，客户端连接代理的21端口，代理再跟后端FTP服务器通信。这样客户端看到的永远是代理的端口，后端FTP服务器的被动端口范围哪怕固定在某几个端口，只要防火墙只对代理IP放行就行。但注意，代理必须开启proxy protocol v2才能让后端服务器获取到客户端真实IP，否则vsftpd的日志里全是代理的地址，排查问题会想骂人。

还有个容易被忽略的细节——FTP服务器的端口分配算法。vsftpd从2.3.5版本开始支持port_allocate_random参数，设为YES时用随机端口分配替代顺序分配。但实测发现，这个随机性依赖内核的熵池，如果服务器熵值不足（比如没有装硬件随机数生成器），端口分配依然可预测。我建议在/etc/sysctl.conf里加上kernel.randomize_va_space=2，同时用haveged守护进程补充熵源，双管齐下才能让随机端口真正随机。

最后说个真实教训。去年某云厂商的FTP托管服务爆出漏洞，就是因为默认配置下被动端口范围是30000-30100，且按顺序分配。攻击者利用这个漏洞，先登录FTP获取到被动端口号，然后用TCP窗口欺骗技术劫持了数据连接，窃取了某电商平台的订单备份文件。事后复盘发现，如果运维人员当时把port_allocate_random设成YES，哪怕端口范围不调整，攻击也没那么容易得手——因为随机化之后，攻击者无法预判下一个端口号，劫持的成功率会从90%骤降到不足5%。

别迷信防火墙策略能兜底。FTP的PASV模式设计于上世纪70年代，当时压根没考虑过网络攻击场景。现在要做的是在兼容性和安全性之间找平衡——要么升级客户端支持EPSV，要么用随机端口分配打乱规律，要么用反向代理隔离真实端口。三个方法里至少选一个，别裸奔。

(责任编辑：探索)