>>1.0<< FTP和TCP端口號
根據(jù)是使用Port模式還是Passive模式，F(xiàn)TP使用不同的TCP端口號，在詳細(xì)描述FTP前，我們來 簡單討論一下TCP端口號的一些基本概念。TCP使用端口號來標(biāo)識所發(fā)送和接收的應(yīng)用，端口號 可以幫助TCP來分離字節(jié)流并且?guī)拖鄳?yīng)字節(jié)傳遞給正確的應(yīng)用程序。?

TCP端口號可以是半永久的和暫時的。服務(wù)器端監(jiān)聽在半永久的端口上來讓客戶端訪問。客戶 端使用暫時的端口在本地標(biāo)識一個對話，客戶端端口只在使用TCP服務(wù)時候才存在，而服務(wù)器 端口只要服務(wù)器在運行就一直在監(jiān)聽。

TCP端口可以歸為3類：
1、眾所周知的端口來標(biāo)識在TCP上運行的標(biāo)準(zhǔn)服務(wù)，包括FTP、HTTP、TELNET、SMTP等，這些 端口號碼范圍為0-1023；
2、注冊端口號用來標(biāo)識那些已經(jīng)向IANA（Internet Assigned Numbers Assigned Numbers Authority）注冊的應(yīng)用，注冊端口號為1024-49151；
3、私有端口號是非注冊的并且可以動態(tài)地分配給任何應(yīng)用，私有端口為49152-65535； 注冊的端口號本來打算只給注冊的應(yīng)用使用，可近年來端口號已經(jīng)陷入了到達極限的困境，你可能會看到本來應(yīng)該是給注冊應(yīng)用使用的注冊端口被非注冊應(yīng)用用做暫時的端口。RFC1700詳 細(xì)標(biāo)注了眾所周知的和注冊的端口號。

>>2.0<< FTP Port模式和FTP Passive模式
當(dāng)你對一個FTP問題進行排錯時候，你首先要問的一個問題是使用的是port模式的還是passive 模式。因為這兩種行為迥異，所以這兩種模式引起的問題也不同；在過去，客戶端缺省為acti ve(port)模式；近來，由于Port模式的安全問題，許多客戶端的FTP應(yīng)用缺省為Passive模式。

>>2.1 FTP Port模式
Port模式的FTP步驟如下：
1、 客戶端發(fā)送一個TCP SYN（TCP同步）包給服務(wù)器段眾所周知的FTP控制端口21，客戶端 使用暫時的端口作為它的源端口；
2、 服務(wù)器端發(fā)送SYN ACK（同步確認(rèn)）包給客戶端，源端口為21，目的端口為客戶端上使用的暫時端口；
3、 客戶端發(fā)送一個ACK（確認(rèn)）包；客戶端使用這個連接來發(fā)送FTP命令，服務(wù)器端使用這個連接來發(fā)送FTP應(yīng)答；
4、 當(dāng)用戶請求一個列表(List)請求或者發(fā)起一個要求發(fā)送或者接受文件的請求，客戶端軟件使用PORT命令，這個命令包含了一個暫時的端口，客戶端希望服務(wù)器在打開一個數(shù)據(jù)連接時候使用這個暫時端口；PORT命令也包含了一個IP地址，這個IP地址通常是客戶自己的IP地址，而且FTP也支持第三方（third-party）模式，第三方模式是客戶端告訴服務(wù)器端打開與另臺主機的連接；
5、 服務(wù)器端發(fā)送一個SYN包給客戶端的暫時端口，源端口為20，暫時端口為客戶端在PORT命令中發(fā)送給服務(wù)器端的暫時端口號；
6、 客戶端以源端口為暫時端口，目的端口為20發(fā)送一個SYN ACK包；
7、 服務(wù)器端發(fā)送一個ACK包；
8、 發(fā)送數(shù)據(jù)的主機以這個連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務(wù)器段發(fā)送數(shù)據(jù)），這些TCP段都需要對方進行ACK確認(rèn)（注：因為TCP協(xié)議是一個面向連接的協(xié)議）
9、 當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機以一個FIN命令來結(jié)束數(shù)據(jù)連接，這個FIN命令需要另一臺主機以ACK確認(rèn)，另一臺主機也發(fā)送一個FIN命令，這個FIN命令同樣需要發(fā)送數(shù)據(jù)的主機以ACK確認(rèn)；
10、 客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時候客戶端結(jié)束后，客戶端以FIN命令來關(guān)閉一個控制連接，服務(wù)器端以ACK包來確認(rèn)客戶端的FIN，服務(wù)器同樣也發(fā)送它的FIN，客戶端用ACK來確認(rèn)。

下圖圖示了FTP PORT模式前幾步步驟：
/====================================================================/
| |
| [ ftp Client ] [ ftp Server ] |
| |
| (TCP:21 連接初始化,控制端口) |
| SYN |
| Port xxxx ----------------------> Port 21 [TCP] |
| SYN+ACK |
| Port xxxx <---------------------- Port 21 |
| ACK |
| Port xxxx ----------------------> Port 21 |
| |
| (控制操作: 用戶列目錄或傳輸文件) |
| |
| Port, IP, Port yyyy |
| Port xxxx <---------------------- Port 21 |
| Port Seccussful |
| Port xxxx <---------------------- Port 21 |
| List, Retr or Stor |
| Port xxxx ----------------------> Port 21 |
| |
| |
| (TCP:20 連接初始化,數(shù)據(jù)端口) |
| SYN |
| Port yyyy <---------------------- Port 20 |
| SYN+ACK |
| Port yyyy ----------------------> Port 20 |
| ACK |
| Port yyyy <---------------------- Port 20 |
| |
| |
| (數(shù)據(jù)操作: 數(shù)據(jù)傳輸) |
| Data + ACK |
| Port yyyy

?

s: %000010 |
| 0. .... (No Urgent pointer) |
| .0 .... (No Ack) |
| .. 0... (No Push) |
| .. .0.. (No Reset) |
| .. ..1. SYN |
| .. ...0 (No FIN) |
| |
| Window: 3731 |
| Checksum: 0x8A4C |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| TCP Options |
| Options Type: 2 Maxinum Segment Size |
| Length: 4 |
| MSS: 1460 |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0x5A1BD023 |
/====================================================================/

當(dāng)使用FTP時候，網(wǎng)絡(luò)中的防火墻必須要聲明相應(yīng)的端口，防火墻必須要跟蹤FTP對話然后檢查PORT命令，防火墻必須要參與從服務(wù)器端到客戶端在PORT命令中指定的端口連接的建立過程。
如果網(wǎng)絡(luò)中使用了NAT（注：網(wǎng)絡(luò)地址翻譯），那么NAT的網(wǎng)關(guān)同樣也需要聲明相應(yīng)的端口，網(wǎng)關(guān)需要把在PORT命令中指定的IP地址翻譯成分配給客戶的地址，然后重新計算TCP的Checksum；如果網(wǎng)關(guān)沒有正確地執(zhí)行這個操作，F(xiàn)TP就失敗了。

黑客可能會利用FTP支持第三方特性這一特點，在PORT命令中設(shè)置IP地址和端口號參數(shù)來指定一臺目標(biāo)主機的地址和端口號（有時候稱這種攻擊為FTP反彈攻擊），例如黑客可以讓一臺FTP服務(wù)器不斷地從它的源端口20發(fā)送TCP SYN包給一系列目的端口，讓FTP服務(wù)器看起來正在進行
端口掃描，目的主機不知道攻擊來自黑客的主機，看起來攻擊象是來自FTP服務(wù)器。一些常用的FTP應(yīng)用在PORT命令中設(shè)置地址為0.0.0.0，這樣做的意圖是讓FTP服務(wù)器只需要與打開控制連接的相同客戶進行數(shù)據(jù)連接，設(shè)置地址為0.0.0.0可能會讓防火墻不知所措。例如，CISCO PIX IOS 6.0以上版本的PIX（注：CISCO硬件防火墻設(shè)備，6.0以上版本為其修正了相關(guān)的FTP協(xié)議）要求數(shù)據(jù)連接的IP地址與已經(jīng)存在的控制連接的IP地址必須相同。這樣做的原因是防止黑客用PORT命令來攻擊別的機器，雖然一些FTP應(yīng)用設(shè)置IP地址為0.0.0.0不是有意圖的攻擊，但在PIX修正協(xié)議環(huán)境下的確引起了一些問題，同時對其他不允許第三方模式和避免FTP反彈攻擊的防火墻來說，這也會引起相同的問題。

>>2.2 FTP Passive模式
下面的列表描述了Passive模式的FTP的步驟，步驟1到3和Port模式FTP相同，步驟9到11同樣與Port模式FTP最后三步相同。

1、客戶端發(fā)送一個TCP SYN（TCP同步）包給服務(wù)器段眾所周知的FTP控制端口21，客戶端使用暫時的端口作為它的源端口；
2、服務(wù)器端發(fā)送SYN ACK（同步確認(rèn)）包給客戶端，源端口為21，目的端口為客戶端上使用的暫時端口；
3、客戶端發(fā)送一個ACK（確認(rèn)）包；客戶端使用這個連接來發(fā)送FTP命令，服務(wù)器端使用這個連接來發(fā)送FTP應(yīng)答；
4、當(dāng)用戶請求一個列表(List)或者發(fā)送或接收文件時候，客戶端軟件發(fā)送PASV命令給服務(wù)器端表明客戶端希望進入Passive模式；
5、服務(wù)器端進行應(yīng)答，應(yīng)答包括服務(wù)器的IP地址和一個暫時的端口，這個暫時的端口是客戶端在打開數(shù)據(jù)傳輸連接時應(yīng)該使用的端口；
6、客戶端發(fā)送一個SYN包，源端口為客戶端自己選擇的一個暫時端口，目的端口為服務(wù)器在PASV應(yīng)答命令中指定的暫時端口號；
7、服務(wù)器端發(fā)送SYN ACK包給客戶端，目的端口為客戶端自己選擇的暫時端口，源端口為PASV應(yīng)答中指定的暫時端口號；
8、客戶端發(fā)送一個ACK包；
9、發(fā)送數(shù)據(jù)的主機以這個連接來發(fā)送數(shù)據(jù)，數(shù)據(jù)以TCP段(注：segment，第4層的PDU)形式發(fā)送（一些命令，如STOR表示客戶端要發(fā)送數(shù)據(jù)，RETR表示服務(wù)器段發(fā)送數(shù)據(jù)），這些TCP段都需要對方進行ACK確認(rèn)；
10、當(dāng)數(shù)據(jù)傳輸完成以后，發(fā)送數(shù)據(jù)的主機以一個FIN命令來結(jié)束數(shù)據(jù)連接，這個FIN命令需要另一臺主機以ACK確認(rèn)，另一臺主機也發(fā)送一個FIN命令，這個FIN命令同樣需要發(fā)送數(shù)據(jù)的主機以ACK確認(rèn)；
11、客戶端能在控制連接上發(fā)送更多的命令，這可以打開和關(guān)閉另外的數(shù)據(jù)連接；有時候客戶端結(jié)束后，客戶端以FIN命令來關(guān)閉一個控制連接，服務(wù)器端以ACK包來確認(rèn)客戶端的FIN，服務(wù)器同樣也發(fā)送它的FIN，客戶端用ACK來確認(rèn)。

下圖圖示了Passive模式FTP的開始幾個步驟：
/====================================================================/
| |
| [ ftp Client ] [ ftp Server ] |
| |
| (TCP:21 連接初始化,控制端口) |
| SYN |
| Port xxxx ----------------------> Port 21 [TCP] |
| SYN+ACK |
| Port xxxx <---------------------- Port 21 |
| ACK |
| Port xxxx ----------------------> Port 21 |
| |
| (PASV操作: 被動連接數(shù)據(jù)端口初始化) |
| |
| PASV |
| Port xxxx ----------------------> Port 21 |
| PASV OK, IP, Port yyyy |
| Port xxxx <---------------------- Port 21 |
| SYN |
| Port zzzz ----------------------> Port yyyy |
| SYN+ACK |
| Port zzzz <---------------------- Port yyyy |
| ACK |
| Port zzzz ----------------------> Port yyyy |
| |
| |
| (數(shù)據(jù)操作: 數(shù)據(jù)傳輸) |
| List, Retr or Stor |
| Port xxxx ----------------------> Port 21 |
| Data + ACK |
| Port zzzz

. ...0 (No FIN) |
| |
| Window: 8192 |
| Checksum: 0x1A57 |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| TCP Options |
| Options Type: 2 Maxinum Segment Size |
| Length: 4 |
| MSS: 1460 |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0x5A1BD023 |
/====================================================================/

大多數(shù)人認(rèn)為在防火墻網(wǎng)絡(luò)環(huán)境中Passive模式比Port模式的問題小，但我們注意到在Passive模式下，客戶端打開一個暫時的目的端口連接，一些防火墻或者CISCO設(shè)備的訪問列表(ACL)可能會阻止這種連接，同樣服務(wù)器的回應(yīng)也是從一個暫時的端口到一個暫時的端口，防火墻或者CISCO的訪問列表也會阻止這種連接。在CISCO路由器上你可以用訪問列表關(guān)鍵字"established"來避免第二個問題，"established"關(guān)鍵字告訴路由器允許帶ACK字端的包通過，服務(wù)器端的SYN ACK包帶有ACK字端。在新版本PIX IOS中也可以通過fixit關(guān)鍵字建立針對ftp協(xié)議的深層狀態(tài)檢測過濾，其他大多數(shù)狀態(tài)檢測防火墻例如LinuxNetfilters也支持ftp協(xié)議的狀態(tài)檢測，進行準(zhǔn)確的PASV動態(tài)端口過濾。


>>2.3 用戶名和口令的明文傳輸
FTP另一個聲名狼藉的問題是它以明文方式發(fā)送用戶名和口令，也就是不加密地發(fā)送。任何人只要在網(wǎng)絡(luò)中合適的位置放置一個協(xié)議分析儀就可以看到用戶名和口令；FTP發(fā)送的數(shù)據(jù)也是以明文方式傳輸，通過對ftp連接的監(jiān)控和數(shù)據(jù)收集就可以收集和重現(xiàn)ftp的數(shù)據(jù)傳輸并實現(xiàn)協(xié)議連接回放。事實上很多用戶把相同的用戶名和口令用在不同的應(yīng)用中，這樣這個問題可能看起來更為糟糕；如果黑客收集到FTP口令，他們也可能就得到了你在線帳號或者其他一些機密數(shù)據(jù)的口令。

下面是通過tcpdump -- 一個著名的網(wǎng)絡(luò)協(xié)議分析程序抓取的ftp的完整通訊過程。
/=================================================================/
21:55:36.682402 IP 192.168.0.1.2323 > 192.168.0.3.21: S 2047626269:2047626269(0)
win 65535

等等，但是在大多數(shù)情況下，ftp的通用性和易用性使得它在很長一段時間內(nèi)必然無法被完全取代。所以如同其他一系列古董服務(wù)(例如SMTP/HTTP)一樣，近年來也出現(xiàn)了一些不需要對ftp協(xié)議自身做完全更改的協(xié)議擴展模塊，能夠良好的完成兼容性和功能擴展。ftp SSL/TLS Extension就是其中一種方式。

>>3.1 SSL/TLS簡介
先說一下SSL/TLS協(xié)議，SSL(Secure Socket Layer)最早是netscape公司設(shè)計的用于HTTP協(xié)議加密的安全傳輸協(xié)議，SSL工作于TCP協(xié)議的傳 輸層(TCP層)和應(yīng)用程序之間。作為一個中間層，應(yīng)用程序只要采用SSL提供的一套SSL套接字API來替換標(biāo)準(zhǔn)的Socket套接字，就可以把程序轉(zhuǎn)換為SSL化的安全網(wǎng)絡(luò)程序，在傳輸過程中將由SSL協(xié)議實現(xiàn)數(shù)據(jù)機密性和完整性的保證。SSL協(xié)議的當(dāng)前版本為3.0，當(dāng)SSL取得大規(guī)模成功后，IETF(www.ietf.org)將SSL作了標(biāo)準(zhǔn)化，規(guī)范為RFC2246，并將其稱為TLS（Transport Layer Security）。從技術(shù)上講，TLS1.0與SSL3.0的差別非常微小，SSL由于其歷史應(yīng)用的原因在當(dāng)前的商業(yè)應(yīng)用程序之中使用得更多一些。

>>3.2 數(shù)據(jù)機密性和完整性
前面多次提到了數(shù)據(jù)的機密性和完整性兩個方面，在此略微解釋一下。數(shù)據(jù)的機密性確保數(shù)據(jù)信息機密可靠，不會被沒有權(quán)限的對象所訪問和瀏覽到，基本的機密性保護手段就是數(shù)據(jù)加密；而數(shù)據(jù)的完整性則是指數(shù)據(jù)在傳輸和存儲過程中將保證數(shù)據(jù)的唯一和完整，不會被惡意篡改著所修改，保證數(shù)據(jù)完整性的基本手段主要有數(shù)字簽名。

這里就牽扯到數(shù)據(jù)加密領(lǐng)域的兩類算法，加密算法和散列算法。加密算法從數(shù)學(xué)原理上看可以分為對稱加密和非對稱加密，從數(shù)據(jù)處理方法上可以分為流加密和分組加密，本文重點不在此，不再贅述，只舉例幾種常用的加密算法: DES, 3DES, AES, BlowFish,RC2-RC6等等。數(shù)據(jù)簽名算法是加密領(lǐng)域的另一套方法，又叫數(shù)據(jù)散列算法，用于對數(shù)據(jù)進行處理生成一個唯一的等長簽名字符串，原數(shù)據(jù)的長度可能是任意的，而任意兩個相似但哪怕只有少許細(xì)差別的數(shù)據(jù)集，都將產(chǎn)生差別非常大的等長簽名字符串，這個字符串在一般意義下被認(rèn)為是極少會發(fā)生空間沖突(重復(fù))的，因此數(shù)據(jù)散列算法對于確保數(shù)據(jù)的唯一性是一種必要的手段；常見的數(shù)字散列算法有MD5，SHA-1，CAST-256等等。

可以看出，面對如此多種類的加密算法，應(yīng)用程序處理起來是很繁瑣的。SSL在這個層次中就提供了一種自動的算法協(xié)商，密鑰交換和數(shù)據(jù)加密過程。SSL協(xié)議分為兩部分：Handshake Protocol和Record Protocol，HandShake部分用于處理通訊雙方的算法協(xié)商和密鑰交換過程，Record部分用于對數(shù)據(jù)進行加密傳輸。

整個的SSL基本通訊過程如下:
/====================================================================/
| |
| [ SSL Client ] [ SSL Server ] |
| |
| (TCP三步握手) |
| (SSL套結(jié)字連接) |
| . |
| . SSLSocket() |
| . Bind() |
| SSLSocket() -------------------> |
| <------------------- Connect |
| (連接加密算法協(xié)商) |
| ClientHello() -------------------> |
| (服務(wù)器端算法確認(rèn)和證書發(fā)送)|
| ServerHello |
| Certificate* |
| ServerKeyExchange* |
| CertificateRequest* |
| <------------------- ServerHelloDone |
| (客戶端證書驗證與密鑰交換) |
| Certificate* |
| ClientKeyExchange |
| CertificateVerify* |
| [ChangeCipherSpec] |
| Finished -------------------> (數(shù)據(jù)加密算法協(xié)商) |
| [ChangeCipherSpec] |
| <------------------- Finished |
| (應(yīng)用數(shù)據(jù)加密傳輸) |
| Application Data

----------------------------------------- 234 |
| TLSneg()

程:
/======================================================================/
| 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的通訊數(shù)據(jù)，可以看到AUTH SSL之后的指令全部都已經(jīng)加密，無法看到。對應(yīng)2.3節(jié)中的傳統(tǒng)通訊過程，這確保了傳輸過程中數(shù)據(jù)無法被竊聽到。
在Implicit SSL模式中，從初始化連接開始的數(shù)據(jù)將全部加密，無法分析，因此此處不摘錄。
/======================================================================/
21:34:22.095241 IP 192.168.0.1.2279 > 192.168.0.3.999: S 1727744887:1727744887(0) win 65535

71(866) ack 141 win 65395 (DF)
0x0000 4500 038a 8dad 4000 8006 e86b c0a8 0003 E.....@....k....
0x0010 c0a8 0001 03e7 08e7 d67d 9aa4 66fb 4c04 .........}..f.L.
0x0020 5018 ff73 e356 0000 1603 0100 4a02 0000 P..s.V......J...
0x0030 4603 0140 8283 7da1 8821 775e 7765 a9ee F..@..}..!w^we..
0x0040 18ca e0ab 1b17 461e bf71 515f 6837 5c1a ......F..qQ_h7/.
/======================================================================/


>>4.0<< 總結(jié)
FTP的替代應(yīng)用
如今，如果考慮到其他一些安全的文件傳輸選擇，可能看起來沒有理由再使用FTP了，如SCP或者SFTP，與FTP應(yīng)用相似但運用SSH（注：Secure Shell）來進行驗證和加密，如果你使用一臺基于UNIX的服務(wù)器，你可以在命令方式下調(diào)用SCP或者SFTP。如果你只是用FTP來更新你的Web頁面，有別的替代應(yīng)用，稱為WebDAV的新的協(xié)議，WebDAV是HTTP的擴展，它允許多個用戶共同編輯和維護遠(yuǎn)程WEB服務(wù)器上的文件。
FTP是在70年代設(shè)計出來的，那個時候互聯(lián)網(wǎng)還是一個封閉的網(wǎng)絡(luò)，網(wǎng)絡(luò)安全不是一個大的問 題。當(dāng)FTP在使用NAT網(wǎng)關(guān)、防火墻、CISCO訪問列表的現(xiàn)代網(wǎng)絡(luò)環(huán)境中運用的時候，不管你使用Port模式還是Passive模式，都可能產(chǎn)生一些問題。