摘要
文件傳輸協議(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 |. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data || Authenticated ||
| \ / |
| \_/ |
| | |
| | 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原文翻譯。;)
Jan 14, 2000.
------------ 完 ----------------
——摘自：http://www.linuxaid.com.cn
