文件傳輸協議(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中主要採用了傳輸控制協議(Transmission 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 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), 保密保護命令
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]中，所有在網路上被傳送的數據和控制信息都未被加密。為了保障FTP傳輸數據的私密性，應儘可能使用強壯的加密系統。
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的安全問題。
參考文獻
[BA72] Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.
[PJ81] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September
1981.
[PJ83] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC 854, ISI, May 1983.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[PR85] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[AO99] M. Allman, S. Ostermann, "FTP Security Considerations", RFC
2577, May 1999.
終於寫完了，談談感想
為寫作本文，主要閱讀了一些RFC文檔。原來對FTP一點也不了解，想不到在二十多年前竟然有那麼多關於它的討論，它也算是Internet上的元老了，能生存至今還是與它良好的結構分不開的。
讀RFC文檔有兩個感受，其一是知識更新很快，1999年就能發出近300篇RFC，資料相當豐富。其二，讀文檔好辛苦，而找文檔更辛苦，幸好RFC組織得好，資料又全又不要錢，而且具有較強權威性。這是一個關於Internet的不可多得的知識庫。
這個文檔也想盡量向RFC靠靠，就只有來點格式方面的靠近了。另外，內容也全是貨真價實的RFC原文翻譯。
