FTP協(xié)議的分析和擴(kuò)展

時(shí)間：2019-04-19 09:04:01

關(guān)鍵字：分析擴(kuò)展 ftp協(xié)議

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]>>1.0<< FTP和TCP端口號根據(jù)是使用Port模式還是Passive模式，F(xiàn)TP使用不同的TCP端口號，在詳細(xì)描述FTP前，我們來簡單討論一下TCP端口號的一些基本

>>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端口號可以是半永久的和暫時(shí)的。服務(wù)器端監(jiān)聽在半永久的端口上來讓客戶端訪問?？蛻?端使用暫時(shí)的端口在本地標(biāo)識一個(gè)對話，客戶端端口只在使用TCP服務(wù)時(shí)候才存在，而服務(wù)器端口只要服務(wù)器在運(yùn)行就一直在監(jiān)聽。

TCP端口可以歸為3類：
1、眾所周知的端口來標(biāo)識在TCP上運(yùn)行的標(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、私有端口號是非注冊的并且可以動(dòng)態(tài)地分配給任何應(yīng)用，私有端口為49152-65535；注冊的端口號本來打算只給注冊的應(yīng)用使用，可近年來端口號已經(jīng)陷入了到達(dá)極限的困境，你可能會(huì)看到本來應(yīng)該是給注冊應(yīng)用使用的注冊端口被非注冊應(yīng)用用做暫時(shí)的端口。RFC1700詳細(xì)標(biāo)注了眾所周知的和注冊的端口號。

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

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

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

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

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

下圖圖示了Passive模式FTP的開始幾個(gè)步驟：
/====================================================================/
| |
| [ ftp Client ] [ ftp Server ] |
| |
| (TCP:21 連接初始化,控制端口) |
| SYN |
| Port xxxx ----------------------> Port 21 [TCP] |
| SYN+ACK |
| Port xxxx <---------------------- Port 21 |
| ACK |
| Port xxxx ----------------------> Port 21 |
| |
| (PASV操作: 被動(dòng)連接數(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模式下，客戶端打開一個(gè)暫時(shí)的目的端口連接，一些防火墻或者CISCO設(shè)備的訪問列表(ACL)可能會(huì)阻止這種連接，同樣服務(wù)器的回應(yīng)也是從一個(gè)暫時(shí)的端口到一個(gè)暫時(shí)的端口，防火墻或者CISCO的訪問列表也會(huì)阻止這種連接。在CISCO路由器上你可以用訪問列表關(guān)鍵字"established"來避免第二個(gè)問題，"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)檢測，進(jìn)行準(zhǔn)確的PASV動(dòng)態(tài)端口過濾。

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

下面是通過tcpdump -- 一個(gè)著名的網(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的通用性和易用性使得它在很長一段時(shí)間內(nèi)必然無法被完全取代。所以如同其他一系列古董服務(wù)(例如SMTP/HTTP)一樣，近年來也出現(xiàn)了一些不需要對ftp協(xié)議自身做完全更改的協(xié)議擴(kuò)展模塊，能夠良好的完成兼容性和功能擴(kuò)展。ftp SSL/TLS Extension就是其中一種方式。

>>3.1 SSL/TLS簡介
先說一下SSL/TLS協(xié)議，SSL(Secure Socket Layer)最早是netscape公司設(shè)計(jì)的用于HTTP協(xié)議加密的安全傳輸協(xié)議，SSL工作于TCP協(xié)議的傳輸層(TCP層)和應(yīng)用程序之間。作為一個(gè)中間層，應(yīng)用程序只要采用SSL提供的一套SSL套接字API來替換標(biāo)準(zhǔn)的Socket套接字，就可以把程序轉(zhuǎn)換為SSL化的安全網(wǎng)絡(luò)程序，在傳輸過程中將由SSL協(xié)議實(shí)現(xiàn)數(shù)據(jù)機(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ù)機(jī)密性和完整性
前面多次提到了數(shù)據(jù)的機(jī)密性和完整性兩個(gè)方面，在此略微解釋一下。數(shù)據(jù)的機(jī)密性確保數(shù)據(jù)信息機(jī)密可靠，不會(huì)被沒有權(quán)限的對象所訪問和瀏覽到，基本的機(jī)密性保護(hù)手段就是數(shù)據(jù)加密；而數(shù)據(jù)的完整性則是指數(shù)據(jù)在傳輸和存儲(chǔ)過程中將保證數(shù)據(jù)的唯一和完整，不會(huì)被惡意篡改著所修改，保證數(shù)據(jù)完整性的基本手段主要有數(shù)字簽名。

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

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

整個(gè)的SSL基本通訊過程如下:
/====================================================================/
| |
| [ SSL Client ] [ SSL Server ] |
| |
| (TCP三步握手) |
| (SSL套結(jié)字連接) |
| . |
| . SSLSocket() |
| . Bind() |
| SSLSocket() -------------------> |
| <------------------- Connect |
| (連接加密算法協(xié)商) |
| ClientHello() -------------------> |
| (服務(wù)器端算法確認(rèn)和證書發(fā)送)|
| ServerHello |
| Certificate* |
| ServerKeyExchange* |
| CertificateRequest* |
| <------------------- ServerHelloDone |
| (客戶端證書驗(yàn)證與密鑰交換) |
| 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)用相似但運(yùn)用SSH（注：Secure Shell）來進(jìn)行驗(yàn)證和加密，如果你使用一臺(tái)基于UNIX的服務(wù)器，你可以在命令方式下調(diào)用SCP或者SFTP。如果你只是用FTP來更新你的Web頁面，有別的替代應(yīng)用，稱為WebDAV的新的協(xié)議，WebDAV是HTTP的擴(kuò)展，它允許多個(gè)用戶共同編輯和維護(hù)遠(yuǎn)程WEB服務(wù)器上的文件。
FTP是在70年代設(shè)計(jì)出來的，那個(gè)時(shí)候互聯(lián)網(wǎng)還是一個(gè)封閉的網(wǎng)絡(luò)，網(wǎng)絡(luò)安全不是一個(gè)大的問題。當(dāng)FTP在使用NAT網(wǎng)關(guān)、防火墻、CISCO訪問列表的現(xiàn)代網(wǎng)絡(luò)環(huán)境中運(yùn)用的時(shí)候，不管你使用Port模式還是Passive模式，都可能產(chǎn)生一些問題。