使用FileZilla进行加密的FTP协议的认证

FileZilla是一个遵循GPL许可协议的开源软件，之所以选择它来做描述，主要是因为这是一个GPL协议下的软件，我可以提供下载，而不必担 心 传播它带来的后果，另处，它在功能上也不失为一个不错的FTP客户端工具，支持多任务下载、断点续传等先进的FTP客户端功能，当然也支持FTP协议的安 全扩展。
需要说明的是使用SSL/TSL加密FTP协议是需要服务端支持的，目前大部分常见的FTP服务端程序都支持这个扩展，比如ServU……

其实使用FTP的安全扩展非常简单，在FileZilla的站点管理器中将服务器类型中默认为FTP，我们改为“FTP over SSL（显式加密）”，或者“FTP over TSL（显式加密）”。日前我们的服务器只支持这两种类型。


需要说明的是，FileZilla在安装的时候,有一个选择是“使用安全安装”还是“不使用安全安装”，假如选择了“使用安全安 装”，那么，在站点管理器里就不能保存密码，需要登录的时候输入。虽然我建议使用安全安装（安全安装，就不会给入侵者以窃取你的本地配置文件——解密你的 密码的机会），我想也不会有多少人愿意照办。
------------------------------------------------------------------------------------------

FTP的安全扩展

在传统的ftp通讯和传输过程中可以看出，ftp协议提供了一种简单实用的网络文件传输方法，但是缺陷也是显而易见的。传统ftp服务缺乏对数 据的机密性和完整性保护，对通讯双方也没有可靠的认证措施，同时还存在着明文信息传输的弱点——在同一个网络上的任何用户都可能窃取到重要的信息。虽然近 年来出现了很多种ftp的替代服务，例如ssh加密通道的sftp/scp，或使用IPSEC协议的VPN通道等等，但是在大多数情况下，ftp的通用性 和易用性使得它在很长一段时间内必然无法被完全取代。所以如同其他一系列古董服务(例如SMTP/HTTP)一样，近年来也出现了一些不需要对ftp协议 自身做完全更改的协议扩展模块，能够良好的完成兼容性和功能扩展。ftp SSL/TLS Extension就是其中一种方式。
FTP安全扩展:
http://www.ietf.org/rfc/rfc2228.txt
http://www.ietf.org/rfc/rfc2246.txt
FTP安全扩展，SSL接口草案:
http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-13.txt
　　1、SSL/TLS简介
　　先说一下SSL/TLS协议，SSL(Secure Socket Layer)最早是netscape公司设计的用于HTTP协议加密的安全传输协议，SSL工作于TCP协议的传输层(TCP层)和应用程序之间。作为一 个中间层，应用程序只要采用SSL提供的一套SSL套接字API来替换标准的Socket套接字，就可以把程序转换为SSL化的安全网络程序，在传输过程 中将由SSL协议实现数据机密性和完整性的保证。SSL协议的当前版本为3.0，当SSL取得大规模成功后，IETF(www.ietf.org)将SSL作了标准化，规范为RFC2246，并将其称为TLS（Transport Layer Security）。从技术上讲，TLS1.0与SSL3.0的差别非常微小，SSL由于其历史应用的原因在当
前的商业应用程序之中使用得更多一些。
TLS协议，RFC 2246: http://www.ietf.org/rfc/rfc2246.txt
　　2 、数据机密性和完整性
　　前面多次提到了数据的机密性和完整性两个方面，在此略微解释一下。数据的机密性确保数据信息机密可靠，不会被没有权限的对象所访问和浏览到，基 本的机密性保护手段就是数据加密；而数据的完整性则是指数据在传输和存储过程中将保证数据的唯一和完整，不会被恶意篡改着所修改，保证数据完整性的基本手 段主要有数字签名。
　　这里就牵扯到数据加密领域的两类算法，加密算法和散列算法。加密算法从数学原理上看可以分为对称加密和非对称加密，从数据处理方法上可以分为流 加密和分组加密，本文重点不在此，不再赘述，只举例几种常用的加密算法: DES, 3DES, AES, BlowFish,RC2-RC6等等。数据签名算法是加密领域的另一套方法，又叫数据散列算法，用于对数据进行处理生成一个唯一的等长签名字符串，原数 据的长度可能是任意的，而任意两个相似但哪怕只有少许细微差别的数据集，都将产生差别非常大的等长签名字符串，这个字符串在一般意义下被认为是极少会发生 空间冲突(重复)的，因此数据散列算法对于确保数据的唯一性是一种必要的手段；常见的数字散列算法有MD5，SHA-1，CAST-256等等。
　　可以看出，面对如此多种类的加密算法，应用程序处理起来是很繁琐的。SSL在这个层次中就提供了一种自动的算法协商，密钥交换和数据加密过程。SSL协议分为两部分：Handshake Protocol和Record
Protocol，HandShake部分用于处理通讯双方的算法协商和密钥交换过程，Record部分用于对数据进行加密传输。
　　整个的SSL基本通讯过程如下:
/====================================================================\
| |
| [ SSL Client ] [ SSL Server ] |
| |
| (TCP三步握手) |
| (SSL套结字连接) |
| . |
| . SSLSocket() |
| . Bind() |
| SSLSocket() -------------------> |
| <------------------- Connect |
| (连接加密算法协商) |
| ClientHello() -------------------> |
| (服务器端算法确认和证书发送)|
| ServerHello |
| Certificate* |
| ServerKeyExchange* |
| CertificateRequest* |
| <------------------- ServerHelloDone |
| (客户端证书验证与密钥交换) |
| Certificate* |
| ClientKeyExchange |
| CertificateVerify* |
| [ChangeCipherSpec] |
| Finished -------------------> (数据加密算法协商) |
| [ChangeCipherSpec] |
| <------------------- Finished |
| (应用数据加密传输) |
| Application Data <------------------> Application Data |
| ... |
\====================================================================/
　　SSL套结字通讯过程如下:
1, Client和Server双方程序通过ssl socket系列函数替换BSD Socket系列函数；
2, Client通过TCP协议连接到Server端应用程序；
3, Client发起连接质询，发送自身所能实现的"安全集合"，其中包含加密和签名算法协商；
4, Server回应连接，包含本次通讯所使用的算法集合，以及Server端证书；
5, Client收到证书后，使用Server端协商的算法，用Server端证书中包含的Server公钥加密一个随机序列，作为一个挑战质询发回Server；
6, Server收到加密密文，使用自身的私钥进行数据解密，如果成功，代表SA协商匹配，可以开始通讯；
7, 可选过程，继续发起Client端验证过程，Client端发出Client证书，进行Client端验证过程；
8, 可选过程，数据传输过程加密算法协商；
9, 协商完毕，开始加密数据传输；
　　可以看出，SSL Socket通讯过程相比正常的BSD Socket，只不过多了一个安全集合交换协商的过程，这个过程由SSL实现自身来完成，相对于应用程序，只要采用了SSL Socket，其他的过程都是
透 明的。SSL通讯过程中的第3-6步是必须操作，包含了Server端验证过程和加密算法协商，类似于TCP协议的三步握手过程，这个过程中通过公钥加密 算法加密密钥(公钥)和解密秘钥(私钥)不同的功能，巧妙地实现了密钥交换和算法协商，并且由于解密秘钥不需要在网络上传输，这样就同时实现了数据通讯过 程的保密性和内部应用程序协议的保密性。在第7步进行Client端证书的验证过程中，由于当前网络环境下PKI和CA体系尚不完善，并且由于SSL设计 的工作环境相对对Client端的安全需求并不很高，所以Client端验证一般作为一种可选手段来实现，取决于应用程序的安全等级需求。
　　SSL数据通讯的机密性特性就是由上面的过程完成的，在算法协商过程中除了加密算法的协商外还会交换一个数据签名算法，用于对数据生成一个唯一的散列校验码，防止在传输过程中数据被篡改，数据签名过程实现了通讯过程的完整性保证。
　　对应于SSL所提供的两种安全特性，机密性和保密性，ssl定义了四个安全级别，分别是这两种特性的状态组合:
'C' - Clear - 没有任何保护
'S' - Safe - 完整性实现，但是没有机密性
'E' - Confidential - 机密性实现，但是没有完整性
'P' - Private - 同时实现机密性和完整性
ftp的ssl扩展使用了其中的两种状态
1)Clear (requested by 'PROT C')
2)Private (requested by 'PROT P')
在连接过程中通过ftp扩展指令PROT来完成状态的切换。
　　3 、ssl FTP扩展
　　在RFC 2228中，ftp协议扩展了如下指令:
AUTH (Authentication/Security Mechanism),
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), and
ENC (Privacy Protected Command). 　　其中和SSL扩展相关的主要指令有以下几条:
AUTH (协商扩展验证): 指定扩展认证方法,SSL或TLS；
PBSZ (协商保护缓冲区): 制定保护缓冲区,SSL/TLS模式中必须为0；
PROT (切换保护级别): 切换保护级别，可以为"C"无保护，或"P"保护级别；
在一个典型的ftp ssl通讯过程中指令序列如下:
/====================================================================\
| Client Server |
| control data data control |
|====================================================================|
| |
| socket() |
| bind() |
| socket() |
| connect() -------------------------------------------> accept() |
| <------------------------------------------- 220 |
| AUTH TLS -------------------------------------------> |
| <------------------------------------------- 234 |
| TLSneg() <------------------------------------------> TLSneg() |
| PBSZ 0 -------------------------------------------> |
| <------------------------------------------- 200 |
| PROT P -------------------------------------------> |
| <------------------------------------------- 200 |
| USER elly -------------------------------------------> |
| <------------------------------------------- 331 |
| PASS **** -------------------------------------------> |
| <------------------------------------------- 230 |
| |
\====================================================================/
一个SSL FTP的连接过程实例:
/====================================================================\
| |
| WinSock 2.0 -- OpenSSL 0.9.7d 17 Mar 2004 |
| [R] Connecting to 192.168.21.3 -> IP=192.168.21.3 PORT=2121 |
| [R] Connected to 192.168.21.3 |
| [R] 220 Please enter your login name now. |
| [R] AUTH TLS (认证方法)|
| [R] 234 AUTH Command OK. Initializing SSL connection. |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] SSL/TLS negotiation successful... (协商关联)|
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits)
| [R] PBSZ 0 (PBSZ设置)|
| [R] 200 PBSZ Command OK. Protection buffer size set to 0. |
| [R] USER elly (ftp传统认证)|
| [R] 331 Password required for elly . |
| [R] PASS (hidden) |
| [R] 230 User elly logged in. |
| [R] SYST |
| [R] 215 UNIX Type: L8 , CP:936 |
| [R] FEAT (扩展指令测试)|
| [R] 211-Extensions supported: |
| [R] SIZE |
| [R] MDTM |
| [R] MDTM YYYYMMDDHHMMSS filename |
| [R] LIST -laT |
| [R] STAT -laT |
| ... |
| [R] AUTH SSL |
| [R] AUTH TLS |
| [R] PROT |
| [R] PBSZ |
| [R] SSCN |
| [R] UTF8 |
| [R] 211 END |
| [R] CLNT FlashFXP 2.2.985 |
| [R] 213 client type set to FlashFXP 2.2.985. |
| [R] PWD (传统通讯过程)|
| [R] 257 "/" is current directory |
| [R] TYPE A |
| [R] 200 Type set to ASCII. |
| [R] PROT P (切换到保护模式)|
| [R] 200 PROT P accepted. |
| [R] PASV |
| [R] 227 Entering Passive Mode (192,168,21,3,5,122) |
| [R] Opening data connection IP: 192.168.21.3 PORT: 1402 |
| [R] LIST -al |
| [R] Connected. Negotiating SSL/TLS session.. (加密通讯过程)|
| [R] 150 Opening ASCII data connection for ls / using SSL/TLS. |
| [R] SSL/TLS negotiation successful... |
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits)
| [R] 226-free disk space under this directory : 101 mb |
| [R] 226 Transfer finished successfully. Data connection closed . |
| [R] List Complete: 181 bytes in 0.14 seconds (1.26 KBps) |
| |
\====================================================================/
　　在ssl ftp中，有以下几个特殊点:
1, AUTH是可选指令，因为ssl ftp实现的方式不同而存在，详见下一节explicit SSL与implicit SSL；
2, PBSZ和PROT是必须指令，用于切换到保护通道模式；
3, AUTH，PBSZ和PROT指令是实现SSL认证方式的必须方法，但可以与传统的User/Password 模式共存，或只取其一；
4, SSL认证方法的SSL认证过程(AUTH/PBSZ)和传统模式认证并无严格的先后顺序关联，可能在用户名和密码之前，也可能在之后；但出于安全因素，最好在User/Password传输之前切换到安全模式，可以确保User/Password的传输安全；
5, 在explicit SSL模式中，可以在任何时间切换到保护模式，如第四条所述；在implicit SSL模式中，初始化连接将直接采用SSL Socket建立，不需要AUTH指令切换。
　　4 、Explicit SSL和Implicit SSL
　　由于历史和软件兼容性因素，ssl FTP的实现有两种方式，分别是Explicit SSL和Implicit SSL，上面的大部分数据都是以explicit SSL为范例。
　　Explicit SSL(外部SSL)，又被称为AUTH SSL方式；Explicit SSL保持了与传统ftp服务的良好兼容性，以一个ftp服务扩展指令的方式存在。初始化连接可以采用与传统ftp兼容的连接模式，当需要传输加密信息时 使用AUTH SSL指令切换到保护模式。使用Explicit SSL时
Server必须完整地实现AUTH/PBSZ/PROT等指令。
　　Implicit SSL(隐含SSL)，是一个全新的ftp实现方式，在TCP三步握手完成之后就直接使用SSL Socket进行协商和通讯，之后将全程采用SSL加密连接。在这种模式中一般ftp server将监听在一个新的服务端口，IANA指定ftps:tcp:990为implicit SSL ftp的默认端口。因为在连接初始阶段就自动由SSL实现完成了协商，因此implicit模式中AUTH指令是可选的。
　　在不考虑兼容性的因素下，在服务期端最好优先使用implicit SSL模式，可以获得更好的保密特性。
比较两种ssl ftp实现模式区别如下:
/======================================================================\
| explicit implicit |
| client server client server |
|======================================================================|
| | |
| connect() ------> -+-明文 | sslConnect() ------> 加密 |
| <------ 220 | | <------ 220 -+ |
| AUTH SSL ------> | | USER *** ------> | |
| <------ 234 -+ | <------ 331 | |
| TLSneg() <-----> TLSneg() -+-加密 | PASS *** ------> | |
| <------ 200 | | <------ 230 | |
| USER *** ------> | | LIST <-----> ... | |
| <------ 331 | | RETR <-----> ... | |
| PASS *** ------> | | ... | |
| <------ 230 | | | |
| LIST/RETR <-----> ... | | sslClose() <-----> ... -+ |
| close() <-----> ... -+ | |
| | |
\======================================================================/

5 、一些杂乱图示
在3中引用了一个Explicit SSL连接指令序列，这里是对应的Implicit SSL连接过程:
/======================================================================\
| WinSock 2.0 -- OpenSSL 0.9.7d 17 Mar 2004 |
| [R] Connecting to 192.168.21.3 -> IP=192.168.21.3 PORT=9909 |
| [R] Connected to 192.168.21.3 |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] SSL/TLS negotiation successful... |
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits) |
| [R] 220 Please enter your login name now. |
| [R] PBSZ 0 |
| [R] 200 PBSZ Command OK. Protection buffer size set to 0. |
| [R] USER elly |
| [R] 331 Password required for elly . |
| [R] PASS (hidden) |
| [R] 230 User elly logged in. |
| [R] SYST |
| [R] 215 UNIX Type: L8 , CP:936 |
| [R] PROT P |
| [R] 200 PROT P accepted. |
| [R] PASV |
| [R] 227 Entering Passive Mode (192,168,21,3,5,122) |
| [R] Opening data connection IP: 192.168.21.3 PORT: 1402 |
| [R] LIST -al |
| [R] Connected. Negotiating SSL/TLS session.. |
| [R] 150 Opening ASCII data connection for ls / using SSL/TLS. |
| [R] SSL/TLS negotiation successful... |
| [R] TLSv1/SSLv3 encrypted session using cipher AES256-SHA (256 bits) |
| [R] List Complete: 181 bytes in 0.17 seconds (1.04 KBps) |
\======================================================================/
Explicit SSL模式下ftp client <-- server的通讯数据，可以看到AUTH SSL之后的指令全部都已经加密，无法看到。对应2.3节中的传统通讯过程，这确保了传输过程中数据无法被窃听到。
在Implicit SSL模式中，从初始化连接开始的数据将全部加密，无法分析，因此此处不摘录。
----------------------------------------------------------------------------------------------
FTP的安全问题


本文是对文件传输协议（FTP）的说明，它包含了一些用来缓解网络安全问题的机制。
本FTP规范允许客户端命令一台服务器传输文件到第三方机器。这种“三方”机制，我们
称它为“代理FTP”，带来了一个著名的安全问题。本FTP规范还允许无数次的尝试输入用
户密码，这带来了强力“密码猜测”攻击。本文档给系统管理员和那些实现FTP服务器的
人提供了一些建议来减少跟FTP有关的安全问题。

1．简介 1
2．跳转攻击（BounceAttack） 2
3．避免跳转攻击 2
4．受限制的访问 3
5．保护密码 3
6．私密性 3
7．保护用户名 3
8．端口盗用 4
9．基于软件的安全问题 4
10．结论 4
11．安全考虑 4

1．简介
文件传输协议规范（FTP）[PR85]提供了一种允许客户端建立FTP控制连接并在两台
FTP服务器间传输文件的机制。这种“代理FTP”机制可以用来减少网络的流量，客户端命
令一台服务器传输文件给另一台服务器，而不是从第一台服务器传输文件给客户端，然后从
客户端再传输给第二台服务器。当客户端连接到网络的速度特别慢时，这是非常有用的。但
同时，代理FTP还带来了一个安全问题——“跳转攻击（bounceattack）”[CERT97:27]。除
了“跳转攻击”，FTP服务器还可以被攻击者通过强力来猜测密码。
本文档并不考虑当FTP和一些强壮的安全协议（比如IP安全）联合使用的情况。虽然
这些安全关注并不在本文档的考虑范围内，但是它们也应该被写成文档。
本文给FTP服务器的实现者和系统管理员提供了一些信息，如下所示。第二章描述了
FTP“跳转攻击”。第三章提供了减少“跳转攻击”的建议。第四章给基于网络地址限制访
问的服务器提供了建议。第五章提供了限制客户端强力“猜测密码”的建议。接着，第六章
简单的讨论了改善保密性的机制。第七章给出了阻止猜测用户身份的机制。第八章讨论了端
口盗用。最后，第九章讨论了其它跟软件漏洞有关而跟协议本身无关的FTP安全问题。
2．跳转攻击（BounceAttack）
RFC959[PR85]中规定的FTP规范提供了一种攻击知名网络服务器的一种方法，并且使
攻击者很难被跟踪。攻击者发送一个FTP"PORT"命令给目标FTP服务器，其中包含该主机
的网络地址和被攻击的服务的端口号。这样，客户端就能命令FTP服务器发一个文件给被
攻击的服务。这个文件可能包括根被攻击的服务有关的命令（如SMTP,NNTP等）。由于是
命令第三方去连接到一种服务，而不是直接连接，就使得跟踪攻击者变得困难，并且还避开
了基于网络地址的访问限制。
例如，客户端上载包含SMTP命令的报文到FTP服务器。然后，使用正确的PORT命
令，客户端命令服务器打开一个连接给第三方机器的SMTP端口。最后，客户端命令服务
器传输刚才上载的包含SMTP命令的报文给第三方机器。这就使得客户端不建立任何直接
的连接而在第三方机器上伪造邮件，并且很难跟踪到这个攻击者。
3．避免跳转攻击
原来的FTP规范[PR85]假定使用TCP进行数据链接，TCP端口号从0到1023时报留给
一些众所周知的服务的，比如邮件，网络新闻和FTP控制链接。FTP规范对数据链接没有
限制TCP端口号。因此，使用代理FTP，客户端就可以命令服务器去攻击任何机器上众所
周知的服务。
为了避免跳转攻击，服务器最好不要打开数据链接到小于1024的TCP端口号。如果服
务器收到一个TCP端口号小于1024的PORT命令，那么可以返回消息504（对这种参数命
令不能实现）。但要注意这样遗留下那些不知名服务（端口号大于1023）易受攻击。
一些建议（例如[AOM98]和[Pis94]）提供了允许使用除了TCP以外的其他传输协议来
建立数据连接的机制。当使用这些协议时，同样要注意采用类似的防范措施来保护众所周知
的服务。
另外，我们注意到跳转攻击一般需要攻击者首先上载一个报文到FTP服务器然后再下
载到准备攻击的服务端口上。使用适当的文件保护措施就可以阻止这种情况发生。然而攻击
者也可能通过从远程FTP服务器发送一些能破坏某些服务的数据来攻击它。
禁止使用PORT命令也是避免跳转攻击的一种方法。大多数文件传输可以仅通过PASV
命令来实现。但这样做的缺点就是丧失了使用代理FTP的能力，当然代理FTP并不是在所
有场合都需要的。
4．受限制的访问
一些FTP服务器希望有基于网络地址的访问控制。例如，服务器可能希望限制来自某
些地点的对某些文件的访问（例如为了某些文件不被传送到组织以外）。在这种情况下，服
务器在发送受限制的文件之前应该首先确保远程主机的网络地址在本组织的范围内，不管是
控制连接还是数据连接。通过检查这两个连接，服务器就被保护避免了这种情况：控制连接
用一台可信任的主机连接而数据连接不是。同样的，客户也应该在接受监听模式下的开放端
口连接后检察远程主机的IP地址，以确保连接是由所期望的服务器建立的。
注意，基于网络地址的受限访问留下了FTP服务器易受“地址盗用(spoof)”攻击。在
spoof攻击中，攻击机器可以冒用在组织内的机器的网络地址，从而将文件下载到在组织之
外的未授权的机器上。只要可能，就应该使用安全鉴别机制，比如在[HL97]中列出的安全鉴
别机制。
5．保护密码
为了减少通过FTP服务器进行强力密码猜测攻击的风险，建议服务器限制尝试发送正
确的密码的次数。在几次尝试（3~5次）后，服务器应该结束和该客户的控制连接。在结束
控制连接以前，服务器必须给客户端发送一个返回码421（“服务不可用，关闭控制连接”
[PR85]）。另外，服务器在相应无效的“PASS”命令之前应暂停几秒来消减强力攻击的有效
性。若可能的话，目标操作系统提供的机制可以用来完成上述建议。
攻击者可能通过与服务器建立多个、并行的控制连接破坏上述的机制。为了搏击多个并
行控制连接的使用，服务器可以限制控制连接的最大数目，或探查会话中的可疑行为并在以
后拒绝该站点的连接请求。然而上述两种措施又引入了“服务否决”攻击，攻击者可以故意
的禁止有效用户的访问。
标准FTP[PR85]在明文文本中使用“PASS”命令发送密码。建议FTP客户端和服务器
端使用备用的鉴别机制，这种鉴别机制不会遭受窃听。比如，IETF公共鉴别技术工作组开
发的机制[HL97]。
6．私密性
在FTP标准中[PR85]中，所有在网络上被传送的数据和控制信息（包括密码）都未被
加密。为了保障FTP传输数据的私密性，应尽可能使用强壮的加密系统。在[HL97]中定义
了一个这样的机制。
7．保护用户名
当“USER”命令中的用户名被拒绝时，在FTP标准中[PR85]中定义了相应的返回码530。
而当用户名是有效的但却需要密码，FTP将使用返回码331。为了避免恶意的客户利用USER
操作返回的码确定一个用户名是否有效，建议服务器对USER命令始终返回331，然后拒绝
对无效用户名合并用户名和密码。
8．端口盗用
许多操作系统以递增的顺序动态的分配端口号。通过合法的传输，攻击者能够观察当前
由服务器端分配的端口号，并“猜”出下一个即将使用的端口号。攻击者可以与这个端口建
立连接，然后就剥夺了下一个合法用户进行传输的能力。或者，攻击者可以盗取给合法用户
的文件。另外，攻击者还可能在从授权用户发出的数据流中插入伪造的文件。通过使FTP
客户和服务器随机的给数据连接分配端口号，或者要求操作系统随机分配端口号，或者使用
与系统无关的机制都可以减少端口盗用的发生。
9．基于软件的安全问题
本文档的重点是和协议相关的安全问题。另外还有一些成文的FTP安全问题是由于不
完善的FTP实现造成的。虽然这种类型的问题的细节超出本文档的范围，还是有必要指出
以下那些过去曾被误用，今后的实现应该慎重考虑的FTP特性。
? 匿名FTP
匿名FTP服务使客户端用最少的证明连接到FTP服务器分享公共文件。如果这样的用
户能够读系统上所有的文件或者能建立文件，那么问题就产生了。[CERT92:09][CERT93:06]

? 执行远程命令
FTP扩展命令"SITEEXEC"允许客户端执行服务器上任意的命令。这种特性显然需要非
常小心的实现。已经有几个成文的例子说明攻击者利用FTP“SITEEXEC”命令可以破坏服
务器的安全性。[CERT94:08][CERT95:16]

? 调试代码
前面的一些跟FTP有关危及安全的问题是由于置入了调试特性的软件造成的。
[CERT88:01]

本文建议有这些功能的FTP服务器的实现者在发布软件之前参阅所有的CERT有关这
些问题的攻击以及类似机制的忠告。
10．结论
使用以上建议可以减少和FTP服务器有关的安全问题的发生，而不用删除其功能。
11．安全考虑
本备忘录通篇讨论了安全问题。

致谢
WewouldliketothankAlexBelits,JimBound,WilliamCurtin,RobertElz,PaulHethmon,
AlunJonesandStephenTihorfortheirhelpfulcommentsonthispaper.Also,wethankthe
FTPEXTWGmemberswhogavemanyusefulsuggestionsattheMemphisIETFmeeting.

参考书目

[AOM98]Allman,M.,Ostermann,S.andC.Metz,"FTPExtensions
forIPv6andNATs",RFC2428,September1998.

[Bel94]Bellovin.S.,"Firewall-FriendlyFTP",RFC1579,February
1994.

[CERT88:01]CERTAdvisoryCA-88:01.ftpdVulnerability.December,
1988ftp://info.cert.org/pub/cert_advisories/

[CERT92:09]CERTAdvisoryCA-92:09.AIXAnonymousFTPVulnerability.
April27,1992.ftp://info.cert.org/pub/cert_advisories/

[CERT93:06]CERTAdvisoryCA-93:06.WuarchiveftpdVulnerability.
September19,1997
ftp://info.cert.org/pub/cert_advisories/

[CERT94:08]CERTAdvisoryCA-94:08.ftpdVulnerabilities.September
23,1997.ftp://info.cert.org/pub/cert_advisories/

[CERT95:16]CERTAdvisoryCA-95:16.wu-ftpdMisconfiguration
Vulnerability.September23,1997
ftp://info.cert.org/pub/cert_advisories/

[CERT97:27]CERTAdvisoryCA-97.27.FTPBounce.January8,1998.
ftp://info.cert.org/pub/cert_advisories/

[HL97]Horowitz,M.andS.Lunt,"FTPSecurityExtensions",RFC
2228,October1997.

[Pis94]Piscitello,D.,"FTPOperationOverBigAddressRecords
(FOOBAR),RFC1639,June1994.

[Pos81]Postel,J.,"TransmissionControlProtocol",STD7,RFC
793,September1981.

[PR85]Postel,J.andJ.Reynolds,"FileTransferProtocol
(FTP)",STD9,RFC959,October1985.

[RP94]Reynolds,J.andJ.Postel,"AssignedNumbers",STD2,
RFC1700,October1994.Seealso:
http://www.iana.org/numbers.html

作者的地址
MarkAllman
NASAGlennResearchCenter/SterlingSoftware
21000BrookparkRd.MS54-2
Cleveland,OH44135

EMail:mallman@grc.nasa.gov


ShawnOstermann
SchoolofElectricalEngineeringandComputerScience
OhioUniversity
416MortonHall
Athens,OH45701

EMail:ostermann@cs.ohiou.edu