\
`-------------
3. 协议的安全问题及防范措施[AO99]
3.1 防范反弹攻击(The Bounce Attack)
a. 漏洞
FTP规范[PR85]定义了“代理FTP”机制,即服务器间交互模型。支持客户建
立一个FTP控制连接，然后在两个服务间传送文件。同时FTP规范中对使用TCP的端口号没有任何限制，而从0－1023的TCP端口号保留用于众所周知的网络服务。所以，通过“代理FTP”，客户可以命令FTP服务器攻击任何一台机器上的众所周知的服务。
b. 反弹攻击
客户发送一个包含被攻击的机器和服务的网络地址和端口号的FTP“PORT”
命令。这时客户要求FTP服务器向被攻击的服务发送一个文件，这个文件中应包含与被攻击的服务相关的命令（例如:SMTP、NNTP）。由于是命令第三方去连接服务，而不是直接连接，这样不仅使追踪攻击者变得困难，还能避开基于网络地址的访问限制。
c. 防范措施
最简单的办法就是封住漏洞。首先，服务器最好不要建立TCP端口号在1024
以下的连接。如果服务器收到一个包含TCP端口号在1024以下的PORT命令，服务器可以返回消息504([PR85]中定义为“对这种参数命令不能实现”)。
其次，禁止使用PORT命令也是一个可选的防范反弹攻击的方案。大多数的文件传输只需要PASV命令。这样做的缺点是失去了使用“代理FTP”的可能性，但是在某些环境中并不需要“代理FTP”。
d. 遗留问题
光控制1024以下的连接，仍会使用户定义的服务（TCP端口号在1024以上）
遭受反弹攻击。
3.2 有限制的访问(Restricted Access)
a. 需求
对一些FTP服务器来说，基于网络地址的访问控制是非常渴望的。例如，服
务器可能希望限制来自某些地点的对某些文件的访问（例如为了某些文件不被传送到组织以外）。另外，客户也需要知道连接是有所期望的服务器建立的。
b. 攻击
攻击者可以利用这样的情况，控制连接是在可信任的主机之上，而数据连接却不是。
c. 防范措施
在建立连接前，双方需要同时认证远端主机的控制连接，数据连接的网络
地址是否可信（如在组织之内），
d. 遗留问题
基于网络地址的访问控制可以起一定作用，但还可能受到“地址盗用
(spoof)”攻击。在spoof攻击中，攻击机器可以冒用在组织内的机器的网络地址，从而将文件下载到在组织之外的未授权的机器上。
3.3 保护密码(Protecting Passwords)
a. 漏洞
第一、在FTP标准[PR85]中，FTP服务器允许无限次输入密码。
第二、“PASS”命令以明文传送密码
b. 攻击
强力攻击有两种表现：在同一连接上直接强力攻击；和服务器建立多个、
并行的连接进行强力攻击。
c. 防范措施
对第一种中强力攻击，建议服务器限制尝试输入正确口令的次数。在几次
尝试失败后，服务器应关闭和客户的控制连接。在关闭之前，服务器可以发送返回码421（服务不可用，关闭控制连接”）。另外，服务器在相应无效的“PASS”命令之前应暂停几秒来消减强力攻击的有效性。若可能的话，目标操作系统提供的机制可以用来完成上述建议。
对第二种强力攻击，服务器可以限制控制连接的最大数目，或探查会话中
的可疑行为并在以后拒绝该站点的连接请求。
密码的明文传播问题可以用FTP扩展中防止窃听的认证机制解决。
d. 遗留问题
然而上述两种措施的引入又都会被“业务否决”攻击，攻击者可以故意的
禁止有效用户的访问。
3.4 私密性(Privacy)
在FTP标准中[PR85]中，所有在网络上被传送的数据和控制信息都未被加密。为了保障FTP传输数据的私密性，应尽可能使用强壮的加密系统。
3.5 保护用户名Usernames
a. 漏洞
当“USER”命令中的用户名被拒绝时，在FTP标准中[PR85]中定义了相应的
返回码530。而当用户名是有效的但却需要密码，FTP将使用返回码331。
b. 攻击
攻击者可以通过利用USER操作返回的码确定一个用户名是否有效
c. 防范措施
不管如何，两种情况都返回331。
3.6 端口盗用Port Stealing
a. 漏洞
当使用操作系统相关的方法分配端口号时，通常都是按增序分配。
b. 攻击
攻击者可以通过规律，根据当前端口分配情况，确定要分配的端口。他就
能做手脚：预先占领端口，让合法用户无法分配；窃听信息；伪造信息。
c. 防范措施
由操作系统无关的方法随机分配端口号，让攻击者无法预测。
4. 结论
FTP被我们广泛应用，自建立后其主框架相当稳定，二十多年没有什么变化，但是在Internet迅猛发展的形势下，其安全问题还是日益突出出来。上述的安全功能扩展和对协议中安全问题的防范也正是近年来人们不懈努力的结果，而且在一定程度上缓解了FTP的安全问题。
参考文献
[BA72] Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.
[PJ81] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September
1981.
[PJ83] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC 854, ISI, May 1983.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[PR85] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[AO99] M. Allman, S. Ostermann, "FTP Security Considerations", RFC
2577, May 1999.
终于写完了，谈谈感想
为写作本文，主要阅读了一些RFC文档。原来对FTP一点也不了解，想不到在二十多年前竟然有那么多关于它的讨论，它也算是Internet上的元老了，能生存至今还是与它良好的结构分不开的。
读RFC文档有两个感受，其一是知识更新很快，1999年就能发出近300篇RFC，资料相当丰富。其二，读文档好辛苦，而找文档更辛苦，幸好RFC组织得好，资料又全又不要钱，而且具有较强权威性。这是一个关于Internet的不可多得的知识库。
这个文档也想尽量向RFC靠靠，就只有来点格式方面的靠近了。另外，内容也全是货真价实的RFC原文翻译。;)
关键词：FTP的安全问题 《转》