《RFCFTP 安全考虑》由会员分享，可在线阅读，更多相关《RFCFTP 安全考虑（10页珍藏版）》请在金锄头文库上搜索。
1、组织：中国互动出版网 :/ china-pub /RFC文档中文翻译方案 :/ china-pub /compters/emook/aboutemook.htmE-mail：ouyangchina-pub 译者：yeemanyeeman 译文发布时间：2022-6-15版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保存本文档的翻译及版权信息。Network Working Group M. AllmanRequest for Comments: 2577 NASA Glenn/Sterling SoftwareCategory: Informational S
2、. Ostermann Ohio University May 1999FTP平安考虑RFC2577 FTP Security Considerations本备忘录的状态 本备忘录给Internet社会提供了一些信息，但不指定任何一种Internet标准。发布本备忘录不受限制。版权声明Copyright C The Internet Society 1999. All Rights Reserved.摘要 本文是对文件传输协议FTP的说明，它包含了一些用来缓解网络平安问题的机制。本FTP标准允许客户端命令一台效劳器传输文件到第三方机器。这种“三方机制，我们称它为“代理FTP，带来了一个著名的平
3、安问题。本FTP标准还允许无数次的尝试输入用户密码，这带来了强力“密码猜测攻击。本文档给系统管理员和那些实现FTP效劳器的人提供了一些建议来减少跟FTP有关的平安问题。1简介12跳转攻击Bounce Attack23防止跳转攻击24受限制的访问35保护密码36私密性37保护用户名38端口盗用49基于软件的平安问题410结论411平安考虑41简介文件传输协议标准FTPPR85提供了一种允许客户端建立FTP控制连接并在两台FTP效劳器间传输文件的机制。这种“代理FTP机制可以用来减少网络的流量，客户端命令一台效劳器传输文件给另一台效劳器，而不是从第一台效劳器传输文件给客户端，然后从客户端再传输给第
4、二台效劳器。当客户端连接到网络的速度特别慢时，这是非常有用的。但同时，代理FTP还带来了一个平安问题“跳转攻击bounce attackCERT97:27。除了“跳转攻击，FTP效劳器还可以被攻击者通过强力来猜测密码。本文档并不考虑当FTP和一些强壮的平安协议比方IP平安联合使用的情况。虽然这些平安关注并不在本文档的考虑范围内，但是它们也应该被写成文档。本文给FTP效劳器的实现者和系统管理员提供了一些信息，如下所示。第二章描述了FTP“跳转攻击。第三章提供了减少“跳转攻击的建议。第四章给基于网络地址限制访问的效劳器提供了建议。第五章提供了限制客户端强力“猜测密码的建议。接着，第六章简单的讨论了
5、改善保密性的机制。第七章给出了阻止猜测用户身份的机制。第八章讨论了端口盗用。最后，第九章讨论了其它跟软件漏洞有关而跟协议本身无关的FTP平安问题。2跳转攻击Bounce AttackRFC959PR85中规定的FTP标准提供了一种攻击知名网络效劳器的一种方法，并且使攻击者很难被跟踪。攻击者发送一个FTPPORT命令给目标FTP效劳器，其中包含该主机的网络地址和被攻击的效劳的端口号。这样，客户端就能命令FTP效劳器发一个文件给被攻击的效劳。这个文件可能包括根被攻击的效劳有关的命令如SMTP,NNTP等。由于是命令第三方去连接到一种效劳，而不是直接连接，就使得跟踪攻击者变得困难，并且还避开了基于网
6、络地址的访问限制。例如，客户端上载包含SMTP命令的报文到FTP效劳器。然后，使用正确的PORT命令，客户端命令效劳器翻开一个连接给第三方机器的SMTP端口。最后，客户端命令效劳器传输刚刚上载的包含SMTP命令的报文给第三方机器。这就使得客户端不建立任何直接的连接而在第三方机器上伪造邮件，并且很难跟踪到这个攻击者。3防止跳转攻击原来的FTP标准PR85假定使用TCP进行数据链接，TCP端口号从0到1023时报留给一些众所周知的效劳的，比方邮件，网络新闻和FTP控制链接。FTP标准对数据链接没有限制TCP端口号。因此，使用代理FTP，客户端就可以命令效劳器去攻击任何机器上众所周知的效劳。为了防止
7、跳转攻击，效劳器最好不要翻开数据链接到小于1024的TCP端口号。如果效劳器收到一个TCP端口号小于1024的PORT命令，那么可以返回消息504对这种参数命令不能实现。但要注意这样遗留下那些不知名效劳端口号大于1023易受攻击。一些建议例如AOM98和Pis94提供了允许使用除了TCP以外的其他传输协议来建立数据连接的机制。当使用这些协议时，同样要注意采用类似的防范措施来保护众所周知的效劳。另外，我们注意到跳转攻击一般需要攻击者首先上载一个报文到FTP效劳器然后再下载到准备攻击的效劳端口上。使用适当的文件保护措施就可以阻止这种情况发生。然而攻击者也可能通过从远程FTP效劳器发送一些能破坏某些
8、效劳的数据来攻击它。禁止使用PORT命令也是防止跳转攻击的一种方法。大多数文件传输可以仅通过PASV命令来实现。但这样做的缺点就是丧失了使用代理FTP的能力，当然代理FTP并不是在所有场合都需要的。4受限制的访问一些FTP效劳器希望有基于网络地址的访问控制。例如，效劳器可能希望限制来自某些地点的对某些文件的访问例如为了某些文件不被传送到组织以外。在这种情况下，效劳器在发送受限制的文件之前应该首先确保远程主机的网络地址在本组织的范围内，不管是控制连接还是数据连接。通过检查这两个连接，效劳器就被保护防止了这种情况：控制连接用一台可信任的主机连接而数据连接不是。同样的，客户也应该在接受监听模式下的开
9、放端口连接后检察远程主机的IP地址，以确保连接是由所期望的效劳器建立的。 注意，基于网络地址的受限访问留下了FTP效劳器易受“地址盗用spoof攻击。在spoof攻击中，攻击机器可以冒用在组织内的机器的网络地址，从而将文件下载到在组织之外的未授权的机器上。只要可能，就应该使用平安鉴别机制，比方在HL97中列出的平安鉴别机制。5保护密码为了减少通过FTP效劳器进行强力密码猜测攻击的风险，建议效劳器限制尝试发送正确的密码的次数。在几次尝试35次后，效劳器应该结束和该客户的控制连接。在结束控制连接以前，效劳器必须给客户端发送一个返回码421“效劳不可用，关闭控制连接PR85。另外，效劳器在相应无效的
10、“PASS命令之前应暂停几秒来消减强力攻击的有效性。假设可能的话，目标操作系统提供的机制可以用来完成上述建议。攻击者可能通过与效劳器建立多个、并行的控制连接破坏上述的机制。为了搏击多个并行控制连接的使用，效劳器可以限制控制连接的最大数目，或探查会话中的可疑行为并在以后拒绝该站点的连接请求。然而上述两种措施又引入了“效劳否决攻击，攻击者可以成心的禁止有效用户的访问。标准FTPPR85在明文文本中使用“PASS命令发送密码。建议FTP客户端和效劳器端使用备用的鉴别机制，这种鉴别机制不会遭受窃听。比方，IETF公共鉴别技术工作组开发的机制HL97。6私密性在FTP标准中PR85中，所有在网络上被传送
11、的数据和控制信息包括密码都未被加密。为了保障FTP传输数据的私密性，应尽可能使用强壮的加密系统。在HL97中定义了一个这样的机制。7保护用户名当“USER命令中的用户名被拒绝时，在FTP标准中PR85中定义了相应的返回码530。而当用户名是有效的但却需要密码，FTP将使用返回码331。为了防止恶意的客户利用USER操作返回的码确定一个用户名是否有效，建议效劳器对USER命令始终返回331，然后拒绝对无效用户名合并用户名和密码。8端口盗用许多操作系统以递增的顺序动态的分配端口号。通过合法的传输，攻击者能够观察当前由效劳器端分配的端口号，并“猜出下一个即将使用的端口号。攻击者可以与这个端口建立连接
12、，然后就剥夺了下一个合法用户进行传输的能力。或者，攻击者可以盗取给合法用户的文件。另外，攻击者还可能在从授权用户发出的数据流中插入伪造的文件。通过使FTP客户和效劳器随机的给数据连接分配端口号，或者要求操作系统随机分配端口号，或者使用与系统无关的机制都可以减少端口盗用的发生。9基于软件的平安问题本文档的重点是和协议相关的平安问题。另外还有一些成文的FTP平安问题是由于不完善的FTP实现造成的。虽然这种类型的问题的细节超出本文档的范围，还是有必要指出以下那些过去曾被误用，今后的实现应该慎重考虑的FTP特性。l 匿名FTP匿名FTP效劳使客户端用最少的证明连接到FTP效劳器分享公共文件。如果这样的
13、用户能够读系统上所有的文件或者能建立文件，那么问题就产生了。CERT92:09 CERT93:06l 执行远程命令FTP扩展命令SITE EXEC允许客户端执行效劳器上任意的命令。这种特性显然需要非常小心的实现。已经有几个成文的例子说明攻击者利用FTP“SITE EXEC命令可以破坏效劳器的平安性。CERT94:08 CERT95:16l 调试代码前面的一些跟FTP有关危及平安的问题是由于置入了调试特性的软件造成的。CERT88:01本文建议有这些功能的FTP效劳器的实现者在发布软件之前参阅所有的CERT有关这些问题的攻击以及类似机制的忠告。10结论使用以上建议可以减少和FTP效劳器有关的平安
14、问题的发生，而不用删除其功能。11平安考虑本备忘录通篇讨论了平安问题。致谢We would like to thank Alex Belits, Jim Bound, William Curtin, Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful comments on this paper. Also, we thank the FTPEXT WG members who gave many useful suggestions at the Memphis IETF meeting.参考书目 AOM98 Allman, M., Ostermann, S. and C. Metz, FTP Extensions for IPv6 and NATs, RFC 2428, September 1998. Bel94 Bellovin. S., Firewall-Friendly FTP, RFC 1579, February 1994.
