1
防火墙——友好 FTP
本备忘录状态
本备忘录提供了 Internet community 的信息,但不说明任何一种类型
的 Internet 标准。发布本备忘录不受限制。
概要
本备忘录描述了改变 FTP 程序的行为的建议。没有协议需要修改,虽
然我们大致描述了一些可能的应用。
总的看法
在实际传输文件时,FTP 协议[1]使用了二级 TCP 连接。缺省的情况下,
这个连接是从 FTP 服务器主动到 FTP 客户端建立的。不过,这样设计不能
在基于过滤的防火墙中以包的形式很好地工作,一般情况下还不允许调用
任意的端口号。
从另一方面来讲,如果客户端使用 PASV 指令,数据信道在穿过防火
墙时会变为外部调用。这样的调用更容易掌握,也不容易引起问题。
详细描述
FTP 规范提到,在缺省的情况下,所有的数据传输都是建立在一个单
一连接上的。对于控制连接,服务器主动开放它的 20 号端口到客户端机器
的相同端口,客户端是被动开放的。
因为效果时好时坏,大多数的 FTP 客户端不采用这种方式。每次传输
都建立一个新的连接,为了避免 TCP 的 TIMEWAIT 状态的冲突,客户端每
次选取一个端口号然后给服务器发一个 PORT 命令,把这个端口号告诉服
务器。
这两种情况都不是友好的防火墙。如果使用一个信息包过滤器(比如,
大多数的先进路由器都提供),数据信道在流入到未知端口时要求获悉。大
多数的防火墙的构建只允许流入到确定的安全可信的端口,比如 SMTP。
通常危及“服务器”安全的区域是 1024 号以下的端口。但是这个策略也是
危险的,比如 X windows 开放更高的端口号就是危险的服务。
另一方面,不管是对防火墙的管理员还是对信息包过滤器来说,流出
的信息包带来的问题少一些。任何含有 ACK 位的 TCP 信息包都不能利用
信息包进行初始化 TCP 连接。过滤器能设置流出外界的信息包的规则。我
们之所以想改变这个操作是因为数据信道执行了一个从客户端到服务器端
的调用。
幸运的是,必要的机制已经存在于协议中。如果客户端发送了一个
PASV 指令,服务器将被动地打开在一些随机的端口,并把端口号通知客户
端。客户端能主动地打开一个端口来建立连接。
实际上有少数 FTP 服务器不承认 PASV 指令。这样做并不合适(因为
不符合 STD 3, RFC 1123 [2]),不过它确实不会引起问题。对于一个不被承
认的操作将返回“500 指令不明”的消息,它用简单的办法使当前的操作
失败。虽然攻击不可能通过防火墙,但是 PASV 在这样的情况下也失效了。