| VB 源码 | VC 源码 | ASP源码 | JSP源码 | PHP源码 | CGI源码 | FLASH源码 | 素材模板 | C 源程序 | 站长工具 | 站长教程 |

邮件服务

数据库
邮件服务
Linux
Win9x/ME
Win2000/NT
WinXP/Server

本类阅读TOP10

·让Hotmail和Yahoo支持POP3
·邮件原文详细介绍--邮件编码介绍
·IEEE 802标准 IEEE 802 Standards
·如何查看邮件信头
·nslookup工具的使用方法
·文件传输协议(FTP)
·Email邮件头揭密(1)
·邮件原文详细介绍--神奇的MIME
·Email邮件头揭密(2)
·在Linux系统上安装和配置Domino服务器

站内搜索

文件传输协议(FTP)
   文件传输协议(File Transfer Protocol,FTP)是一个被广泛应用的协议,它使得 我们能够在网络上方便地传输文件。早期FTP并没有涉及安全问题,随着互连网应用的快速增长,人们对安全的要求也不断提高。本文在介绍了FTP协议的基本特征后,从两个方面探讨了FTP安全问题的解决方案:协议在安全功能方面扩展;协议自身的安全问题以及用户如何防范之。


1. 简介

1.1 FTP的一些特**
    早期对FTP的定义指出,FTP是一个ARPA计算机网络上主机间文件传输的用户级协议。其主要功能是方便主机间的文件传输,并且允许在其他主机上进行方便的存储和文件处理。[BA72]而现在FTP的应用范围则是Internet。

  根据FTP STD 9定义,FTP的目标包括:[PR85]
    1) 促进文件(程序或数据)的共享
    2) 支持间接或隐式地使用远程计算机
    3) 帮助用户避开主机上不同的
    4) 可靠并有效地传输数据

  关于FTP的一些其他**质包括:FTP可以被用户在终端使用,但通常是给程序使用的。FTP中主要采用了传输控制协议(Tran**ission Control Protocol,TCP)[PJ81],和Telnet 协议[PJ83]。

1.2 重要历史事件[PR85]

  1971年,第一个FTP的RFC(RFC 114)由A.K. Bhushan在1971年提出,同时由MIT与 Harvard实验实现。

  1972年,RFC 172 提供了主机间文件传输的一个用户级协议。

  1973年2月,在长期讨论(RFC 265,RFC 294,RFC 354,RFC 385,RFC 430)后,出现了一个官方文档RFC 454。

  1973年8月,出现了一个修订后的新官方文档 RFC 542。确立了FTP的功能、目标和基本模型。当时数据传输协议采用NCP。

  1980年,由于底层协议从NCP改变为TCP,RFC 765 定义了采用TCP的FTP。

  1985年,一个作用持续至今的官方文档RFC 959(STD 9)出台。

1.3 FTP模型[PR85]

  就模型而言,从1973年以来并没有什么变化。下图是FTP使用模型:

                      -------------
                      |/---------\|
                      ||  User ||  --------
                      ||Interface|<--->| User |
                      |\----^----/|  --------
         ----------        |   |   |
         |/------\| FTP Commands |/----V----\|
         ||Server|<---------------->|  User ||
         || PI ||  FTP Replies ||  PI  ||
         |\--^---/|        |\----^----/|
         |  |  |        |   |   |
   --------  |/--V---\|   Data   |/----V----\|  --------
   | File |<--->|Server|<---------------->| User  |<--->| File |
   |System|  || DTP ||  Connection  ||  DTP  ||  |System|
   --------  |\------/|        |\---------/|  --------
         ----------        -------------

         Server-FTP          USER-FTP

   注: 1. data connection 可以双向使用(双工)
     2. data connection 不需要一直存在.

           图一  FTP使用模型
  术语
    User PI(user-protocol interpreter): 用户协议解释器
    Server PI(Server-protocol interpreter): 服务协议解释器
    control connection:控制连接
    Data connection:数据连接
    FTP Commands:FTP命令。描述Data connection的参数,文件操作类型
    FTP Replies:FTP命令

  在图一描述的模型中,User PI创建control connection。control connection遵从Telnet协议。在用户初始化阶段,标准FTP命令被User PI生成并通过control connection 传到服务器处理。Server PI将相应的标准FTP应答通过control connection回传给User PI。数据传输由Data connection完成。
  User DTP 在特定端口监听,由Server DTP 用指定参数初始化连接。

  另一种情形是用户希望在两台非本地的主机上传递文件。用户与两个服务器建立control connection,安排两个服务器间的文件传输。下图描述了这样的模型。

          Control   ------------  Control
          ---------->| User-FTP |<-----------
          |     | User-PI |      |
          |     |  "C"  |      |
          V     ------------      V
      --------------            --------------
      | Server-FTP |  Data Connection   | Server-FTP |
      |  "A"   |<---------------------->|  "B"   |
      -------------- Port (A)   Port (B) --------------
   

               图二 服务器间交互模型

 

2.FTP协议的安全扩展[HL97]

2.1 一些安全地进行文件传输实践

  a. 通过FTP传输预先被加密的文件
  b. 通过E-mail传输预先被加密的文件
  c. 通过PEM消息
  d. 通过使用Kerberos的rcp命令.

2.2 在RFC 2228 之前的FTP并不安全
  虽然FTP采用 TELNET 协议执行connection control操作,而且 TELNET 协议后来又增补了认证和加密选项,但在RFC 1123 中禁止在connection control中进行 TELNET 选项协商。另外 TELNET 协议也没有提供完整**保护,而且也没有data connection 的保护。

2.3 扩展命令
  AUTH (Authentication/Security Mechani**),认证与安全机制
  ADAT (Authentication/Security Data),认证与安全数据
  PROT (Data Channel Protection Level),数据通道保护层次
  PBSZ (Protection Buffer Size),保护缓冲大小
  CCC (Clear Command Channel),清空命令通道
  MIC (Integrity Protected Command),完整**保护命令
  CONF (Confidentiality Protected Command), 保密保护命令
  ENC (Privacy Protected Command),私有**保护命令

  一种新的返回类型(6yz)也被引入以保护返回值。

2.4 协议状态图

  下图描述了在一个提高了安全**的FTP实现中认证和和授权的流程。方形的块表示客户端需要发出的命令的状态,菱形的块表示服务器需要发出响应的状态。


     ,------------------, USER
    __\| Unauthenticated |________\
   | /| (new connection) |       /|
   |  `------------------'       |
   |      |             |
   |      | AUTH          |
   |      V             |
   |      / \              |
   | 4yz,5yz /  \  234        |
   |<--------<   >------------->. |
   |     \  /           | |
   |      \_/            | |
   |      |            | |
   |      | 334          | |
   |      V            | |
   | ,--------------------,      | |
   | | Need Security Data |<--. | |   |
   | `--------------------'      | | |
   |      |           | | |
   |      | ADAT        | | |
   |      V          | | |
   |      / \           | | |
   | 4yz,5yz /  \  335      | | |
   `<--------<   >-----------'  | |
         \  /          | |
         \_/          | |
          |            | |
          | 235         | |
          V           | |
      ,---------------.        | |
   ,--->| Authenticated |<--------'| |当客户与服务器
   |  `---------------'       | 完成了认证,如
   |      |           | 果存在完整**就
   |      | USER         | 必须对命令进行
   |      |           | 完整**保护。CCC
   |      |<-------------------' 命令可以用来放松
   |      V            这个限制。
   |      / \
   | 4yz,5yz /  \  2yz
   |<--------<   >----------->.
   |     \  /        |
   |      \_/        |
   |      |         |
   |      | 3yz       |
   |      V         |
   |  ,---------------.     |
   |  | Need Password |     |
   |  `---------------'     |
   |      |         |
   |      | PASS      |
   |      V         |
   |      / \        |
   | 4yz,5yz /  \  2yz     |
   |<--------<   >----------->|
   |     \  /        |
   |      \_/        |
   |      |         |
   |      | 3yz       |
   |      V         |
   |  ,--------------.     |
   |  | Need Account |     |
   |  `--------------'     |
   |      |         |
   |      | ACCT      |
   |      V         |
   |      / \        |
   | 4yz,5yz /  \  2yz     |
   `<--------<   >----------->|
         \  /        |
         \_/        |
          |         |
          | 3yz       |
          V         |
       ,-------------.     |
       | Authorized |/______|
       | (Logged in) |\
       `-------------'


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]中,所**谕缟媳淮偷氖莺涂刂菩畔⒍嘉幢患用堋N吮U螰TP传输数据的******,应尽可能使用强壮的加密系统。


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的安全问题  。





相关文章
  • 自己电脑做SMTP服务器不求人
  • 自定Exchange2000 OWA的登录界面
  • 子网掩码和ip地址的关系
  • 重新配置Domino服务器
  • 怎样实现EXCHANGA备份
  • 在局域网中实现MSN通讯服务
  • 在rhas3.0上建立一个完整的邮件系统
  • 在REDHAT9.0下安装igenus
  • 在R5邮件中如何方便地监控邮件的返回回执?
  • 在Linux系统上安装和配置Domino服务器
  • 域名和邮件服务器FAQ
  • 语音邮件传真情-Pure Voice使用小技巧
  • 与垃圾邮件说再见(3)
  • 与垃圾邮件说再见(2)
  • 与垃圾邮件说再见(1)
  • 邮箱防垃圾邮件功能评测!
  • 邮坛多面手MDaemon
  • 邮来邮去-Foxmail初级应用问答
  • 邮件原文详细介绍--邮件编码介绍
  • 邮件原文详细介绍--神奇的MIME
  • 相关软件

  • 邮件服务器支持SMTP/POP3/IMA  

  • 下载首页关于我们广告服务联系方式常见问题隐私声明法律条款本站声明下载帮助发布软件站点地图谷歌卫星地图