201.htm

unix高级编程原吗

　　| ,--------------. | <br>
　　| | Need Account | | <br>
　　| `-------------- | <br>
　　| | | <br>
　　| | ACCT | <br>
　　| V | <br>
　　| / | <br>
　　| 4yz,5yz / 2yz | <br>
　　`------------->| <br>
　　 / | <br>
　　_/ | <br>
　　| | <br>
　　| 3yz | <br>
　　V | <br>
　　,-------------. | <br>
　　| Authorized |/________| <br>
　　| (Logged in) | <br>
　　`------------- <br>
  <br>
  <br>
  <br>
　　3. 协议的安全问题及防范措施[AO99] <br>
  <br>
3.1 防范反弹攻击(The Bounce Attack) <br>
  <br>
a. 漏洞 <br>
  <br>
FTP规范[PR85]定义了“代理FTP”机制,即服务器间交互模型。支持客户建 <br>
　　立一个FTP控制连接，然后在两个服务间传送文件。同时FTP规范中对使用TCP的端口号 <br>
没有任何限制，而从0－1023的TCP端口号保留用于众所周知的网络服务。所以，通过“代理 <br>
FTP”，客户可以命令FTP服务器攻击任何一台机器上的众所周知的服务。 <br>
  <br>
b. 反弹攻击 <br>
  <br>
客户发送一个包含被攻击的机器和服务的网络地址和端口号的FTP“PORT” <br>
　　命令。这时客户要求FTP服务器向被攻击的服务发送一个文件，这个文件中应包含与被 <br>
攻击的服务相关的命令（例如:SMTP、NNTP）。由于是命令第三方去连接服务，而不是直接 <br>
连接，这样不仅使追踪攻击者变得困难，还能避开基于网络地址的访问限制。 <br>
  <br>
  <br>
　　c. 防范措施 <br>
  <br>
最简单的办法就是封住漏洞。首先，服务器最好不要建立TCP端口号在1024 <br>

　　以下的连接。如果服务器收到一个包含TCP端口号在1024以下的PORT命令，服务器可以 <br>
返回消息504([PR85]中定义为“对这种参数命令不能实现”)。 <br>
　　其次，禁止使用PORT命令也是一个可选的防范反弹攻击的方案。大多数的文件传输只需 <br>
要PASV命令。这样做的缺点是失去了使用“代理FTP”的可能性，但是在某些环境中并不需 <br>
要“代理FTP”。 <br>
  <br>
d. 遗留问题 <br>
  <br>
光控制1024以下的连接，仍会使用户定义的服务（TCP端口号在1024以上） <br>
　　遭受反弹攻击。 <br>
  <br>
3.2 有限制的访问(Restricted Access) <br>
  <br>
a. 需求 <br>
  <br>
对一些FTP服务器来说，基于网络地址的访问控制是非常渴望的。例如，服 <br>
　　务器可能希望限制来自某些地点的对某些文件的访问（例如为了某些文件不被传送到组 <br>
织以外）。另外，客户也需要知道连接是有所期望的服务器建立的。 <br>
  <br>
b. 攻击 <br>
  <br>
攻击者可以利用这样的情况，控制连接是在可信任的主机之上，而数据连接却不是。 <br>

  <br>
c. 防范措施 <br>
  <br>
在建立连接前，双方需要同时认证远端主机的控制连接，数据连接的网络 <br>
　　地址是否可信（如在组织之内）， <br>
  <br>
d. 遗留问题 <br>
  <br>
基于网络地址的访问控制可以起一定作用，但还可能受到“地址盗用 <br>
　　(spoof)”攻击。在spoof攻击中，攻击机器可以冒用在组织内的机器的网络地址，从而 <br>
将文件下载到在组织之外的未授权的机器上。 <br>
  <br>
3.3 保护密码(Protecting Passwords) <br>
  <br>
a. 漏洞 <br>
  <br>
第一、在FTP标准[PR85]中，FTP服务器允许无限次输入密码。 <br>
第二、“PASS”命令以明文传送密码 <br>
  <br>
b. 攻击 <br>
  <br>
强力攻击有两种表现：在同一连接上直接强力攻击；和服务器建立多个、 <br>

　　并行的连接进行强力攻击。 <br>
  <br>
c. 防范措施 <br>
  <br>
对第一种中强力攻击，建议服务器限制尝试输入正确口令的次数。在几次 <br>
　　尝试失败后，服务器应关闭和客户的控制连接。在关闭之前，服务器可以发送返回码42 <br>
1（服务不可用，关闭控制连接”）。另外，服务器在相应无效的“PASS”命令之前应暂停 <br>
几秒来消减强力攻击的有效性。若可能的话，目标操作系统提供的机制可以用来完成上述建 <br>
议。 <br>
  <br>
对第二种强力攻击，服务器可以限制控制连接的最大数目，或探查会话中 <br>
　　的可疑行为并在以后拒绝该站点的连接请求。 <br>
  <br>
密码的明文传播问题可以用FTP扩展中防止窃听的认证机制解决。 <br>
  <br>
d. 遗留问题 <br>
  <br>
然而上述两种措施的引入又都会被“业务否决”攻击，攻击者可以故意的 <br>
　　禁止有效用户的访问。 <br>
  <br>
  <br>
　　3.4 私密性(Privacy) <br>

  <br>
在FTP标准中[PR85]中，所有在网络上被传送的数据和控制信息都未被加密。为了保障FTP传 <br>
输数据的私密性，应尽可能使用强壮的加密系统。 <br>
  <br>
  <br>
　　3.5 保护用户名Usernames <br>
  <br>
a. 漏洞 <br>
  <br>
当“USER”命令中的用户名被拒绝时，在FTP标准中[PR85]中定义了相应的 <br>
　　返回码530。而当用户名是有效的但却需要密码，FTP将使用返回码331。 <br>
  <br>
b. 攻击 <br>
  <br>
攻击者可以通过利用USER操作返回的码确定一个用户名是否有效 <br>
  <br>
c. 防范措施 <br>
  <br>
不管如何，两种情况都返回331。 <br>
  <br>
3.6 端口盗用Port Stealing <br>
  <br>
  <br>
a. 漏洞 <br>
  <br>
当使用操作系统相关的方法分配端口号时，通常都是按增序分配。 <br>
  <br>
b. 攻击 <br>
  <br>
攻击者可以通过规律，根据当前端口分配情况，确定要分配的端口。他就 <br>
　　能做手脚：预先占领端口，让合法用户无法分配；窃听信息；伪造信息。 <br>
  <br>
c. 防范措施 <br>
  <br>
由操作系统无关的方法随机分配端口号，让攻击者无法预测。 <br>
  <br>
4. 结论 <br>
　　FTP被我们广泛应用，自建立后其主框架相当稳定，二十多年没有什么变化，但是在Int <br>
ernet迅猛发展的形势下，其安全问题还是日益突出出来。上述的安全功能扩展和对协议中 <br>
安全问题的防范也正是近年来人们不懈努力的结果，而且在一定程度上缓解了FTP的安全问 <br>
题。 <br>
  <br>
参考文献 <br>
  <br>
[BA72] Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 <br>

　　(NIC 6794), MIT-Project MAC, 23 June 1971. <br>
  <br>
[PJ81] Postel, Jon, "Transmission Control Protocol - DARPA Internet <br>
　　Program Protocol Specification", RFC 793, DARPA, September <br>
　　1981. <br>
  <br>
[PJ83] Postel, Jon, and Joyce Reynolds, "Telnet Protocol <br>
　　Specification", RFC 854, ISI, May 1983. <br>
  <br>
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC <br>
　　793, September 1981. <br>
  <br>
[PR85] Postel, J. and J. Reynolds, "File Transfer Protocol <br>
　　(FTP)", STD 9, RFC 959, October 1985. <br>
  <br>
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC <br>
　　2228, October 1997. <br>
  <br>
[AO99] M. Allman, S. Ostermann, "FTP Security Considerations", RFC <br>
　　2577, May 1999. <br>
  <br>
  <br>

终于写完了，谈谈感想 <br>
　　为写作本文，主要阅读了一些RFC文档。原来对FTP一点也不了解，想不到在二十多年前 <br>
竟然有那么多关于它的讨论，它也算是Internet上的元老了，能生存至今还是与它良好的结 <br>
构分不开的。 <br>
  <br>
读RFC文档有两个感受，其一是知识更新很快，1999年就能发出近300篇RFC，资料相当丰富 <br>
。其二，读文档好辛苦，而找文档更辛苦，幸好RFC组织得好，资料又全又不要钱，而且具 <br>
有较强权威性。这是一个关于Internet的不可多得的知识库。 <br>
  <br>
这个文档也想尽量向RFC靠靠，就只有来点格式方面的靠近了。另外，内容也全是货真价实 <br>
的RFC原文翻译。;) <br>
  <br>
  <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="185.htm">上一层</a>][<a href="202.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>