FTP 安全扩展 摘 要 本文档是对FTP 规范 STD 9, RFC 959, "文件传输协议 (FTP)" (October 1985)的扩展 。这一扩展为传输控制和数据信道提供了强大的认证，完整性验证， 以及保密机制，同时介绍了与这些机制相关的新的可选命令及其回应和文件传输 编码方式。 关键字：FTP；安全性；数据信道 FTP 说明 文件传输协议 （FTP）目前是在 STD 9, RFC 959 中定义的。并且在互联网 上， 客户是通过透明文本传送它的用户名及密码（使用 USER 和 PASS 命令） 从而完成 服务器端所要求的认证的。除非服务器提供匿名登录服务，否则这意 味着客户正在冒着自己被局域网或广域网上的其他人监听，从而密码被窃取的危 险。这也帮助了这些潜在的别有用心的人通过窃取的密码并且通过不能接受内部 安全隐患的 FTP 服务器修改文件。 除了需要以某种安全的方式验证用户的问题外，还有验证服务器、保护敏感 数 据以及校验其完整性等问题。攻击者通过监听网络便可访问到有价值的或敏 感的数据，也能够通过此方法删除或更改正被传送的数据从而破坏其完整性。某 些活跃的 攻击者甚至能假冒其选定的某个站点向另一个其选定的站点进行文件 传输活动，并 且会调用这个服务器上的命令。FTP 协议当前还没有提供加密或 命令、回应、以及被传输的数据的真实性的验证机制。而这些安全机制对匿名方 式的文件访问也是很有价值。 当然，telnet 协议的用于认证及加密的选项 没有提供数据完整性的保护，（没 有机密性）并且没有强调对数据信道的保护。 FTP 安全概述 FTP 协议的安全扩展部分从最高的起点上探寻，为用户认证（authenticating） 以及核准（authorizing）连接、数据完整性以及机密性保护命令与其相关的回应、 数据传输等提供了一种抽象的机制。 在 FTP 的安全问题中，认证是一种以安全方式对客户端与服务器端身份的 

确认，通常采用密码的机制，基本的ＦＴＰ协议中没有认证的概念。认证的过程 即确认一个正在登录的用户的过程，基本的认证过程包括 USER, PASS, 和 ACCT 命令。就 FTP 的安全扩展来说，由某种安全机制构建起来的认证机制可 以用来做出是否接纳正在登录的用户的决定。 FTP 安全认证的交互过程首先由客户端使用 AUTH 命令告诉服务器端他想 使用哪种认证机制开始。服务器端则接受或拒绝这种认证机制，也有可能服务器 端还没有实现安全扩展协议规定的功能，从而完全拒绝客户端的命令。客户端也 可能尝试其他的认证机制，直到有一个被服务器端接受为止。这样才可以允许进 行最基本的连接协商。（如果希望进行更复杂一些的协商的话，那只能由服务器 端的安全机制提供了。）服务器端的回应会指明客户是否必须对它所提出的安全 认证机制作进一步的解释。如果不需要的话，这意味着此种机制将会对口令（由 PASS 命令指定）进行与以往不同的解释，比如标志（token）或一次性（one-time） 口令系统。 本文档不是在制订某些一成不变的政策。特别是在协议实现方面，客户端和 服务器端可以根据双方建立的安全关联有选择的限制那些可以被实现的活动。例 如，服务器端会要求客户端通过某安全机制而不是口令方式进行登录认证，也会 要求客户端从信令（token）中提供一个一次性口令，还有会要求命令信道的保 护或对某文件编码后传输。为确保被下载文件的有效性，如果没有数据完整性保 护机制的话，与匿名服务器连接的客户端会拒绝用户对文件传输的请求。 FTP Security Extensions Abstract This document defines extensions to the FTP specification STD 9, RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. Keyword: FTP; Security ;data channels 

FTP Introduction The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 and in place on the Internet uses usernames and passwords passed in cleartext to authenticate clients to servers (via the USER and PASS commands). Except for services such as "anonymous" FTP archives, this represents a security risk whereby passwords can be stolen through monitoring of local and wide-area networks.This either aids potential attackers through password exposure and/or limits accessibility of files by FTP servers who cannot or will not accept the inherent security risks. Aside from the problem of authenticating users in a secure manner, there is also sensitive data and/or verifying its the problem of authenticating servers, protecting able to access valuable or sensitive data merely by integrity. An attacker may be monitoring a network, or through active means may be able to delete or modify the data being transferred so as to corrupt its integrity. An active attacker may also initiate spurious file transfers to and from a site attacker may also initiate spurious file transfers to and from a site of the attacker's choice, and may invoke other server. FTP does not currently have any provision for the commands on the encryption or verification of the authenticity of commands, replies, or transferred data. Note that these security services have value even to anonymous file access. Also, the Telnet authentication and encryption option does not provide for integrity protection only (without confidentiality), and does not address the protection of the data channel. FTP Security Overview At the highest, the FTP security extensions seek to provide an abstract mechanism for authenticating and/or authorizing connections,and integrity and/or confidentiality protecting commands, replies,and data transfers. In the context of FTP security, authentication is the establishment of a client's identity and/or a server's identity in a secure way,usually using cryptographic techniques. The basic FTP protocol does not have a concept of authentication. Authorization is the process of validating a user for login. The basic authorization process involves the USER, PASS, and ACCT commands. With the FTP security 

extensions, authentication established using a security mechanism may also be used to make the authorization decision. An FTP security interaction begins with a client telling the server what security mechanism it wants to use with the AUTH command. The server will either accept this mechanism, reject this mechanism, or, in the case of a server which does not implement the security extensions, reject the command completely. The client may try multiple security mechanisms until it requests one which the server accepts. This (If more complex allows a rudimentary form of negotiation to take place. negotiation is desired, this may be implemented as a security mechanism.) The server's reply will indicate if the client must respond with additional data for the security mechanism to interpret. If none is needed, this will usually mean that the mechanism is one where the password (specified by the PASS command) is to be interpreted differently, such as with a token or one-time password system. Policy is not specified by this document. In particular, client and server implementations may choose to implement restrictions on what operations can be performed depending on the security association which exists. For example, a server may require that a client authorize via a security mechanism rather than using a password, require that the client provide a one-time password from a token, require at least integrity protection on the command channel, or require that certain files only be transmitted encrypted. An anonymous ftp client might refuse to do file transfers without integrity protection in order to insure the validity of files downloaded.