下面的列表描述了Passive模式的FTP的步驟，步驟1到3和Port模式FTP相同，步驟9到11同樣與
Port模式FTP最後三步相同。
1、客戶端發送一個TCP SYN（TCP同步）包給服務器段衆所周知的FTP控制端口21，客戶端使
用暫時的端口作爲它的源端口；
2、服務器端發送SYN ACK（同步確認）包給客戶端，源端口爲21，目的端口爲客戶端上使用
的暫時端口；
3、客戶端發送一個ACK（確認）包；客戶端使用這個連接來發送FTP命令，服務器端使用這個
連接來發送FTP應答；
4、當用戶請求一個列表(List)或者發送或接收文件時候，客戶端軟件發送PASV命令給服務器端
表明客戶端希望進入Passive模式；
5、服務器端進行應答，應答包括服務器的IP地址和一個暫時的端口，這個暫時的端口是客戶端
在打開數據傳輸連接時應該使用的端口；
6、客戶端發送一個SYN包，源端口爲客戶端自己選擇的一個暫時端口，目的端口爲服務器在PASV
應答命令中指定的暫時端口號；
7、服務器端發送SYN ACK包給客戶端，目的端口爲客戶端自己選擇的暫時端口，源端口爲PASV
應答中指定的暫時端口號；
8、客戶端發送一個ACK包；
9、發送數據的主機以這個連接來發送數據，數據以TCP段(注：segment，第4層的PDU)形式發送（
一些命令，如STOR表示客戶端要發送數據，RETR表示服務器段發送數據），這些TCP段都需要
對方進行ACK確認；
10、當數據傳輸完成以後，發送數據的主機以一個FIN命令來結束數據連接，這個FIN命令需要另一
臺主機以ACK確認，另一臺主機也發送一個FIN命令，這個FIN命令同樣需要發送數據的主機以A
CK確認；
11、客戶端能在控制連接上發送更多的命令，這可以打開和關閉另外的數據連接；有時候客戶端結
束後，客戶端以FIN命令來關閉一個控制連接，服務器端以ACK包來確認客戶端的FIN，服務器
同樣也發送它的FIN，客戶端用ACK來確認。
下圖圖示了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操作: 被動連接數據端口初始化) |
| |
| 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 |
| |
| |
| (數據操作: 數據傳輸) |
| List, Retr or Stor |
| Port xxxx ----------------------> Port 21 |
| Data + ACK |
| Port zzzz <---------------------> Port yyyy |
| . |
| . |
| . |
| |
\====================================================================/
一個PASV請求要求服務器在服務器選擇的一個新的端口上接受數據連接，PASV命令沒有任何參
數，服務器端的迴應只是一行顯示服務器IP地址和服務器接受連接的TCP端口號。
下圖顯示了服務器對PASV命令的迴應，服務器告訴客戶端它在端口5365（192,168,179,100,20
,245）上進行監聽，計算端口的方法是20*256+245=5365；
/====================================================================\
| TCP - Transport Control Protocol |
| Source Port: 21 ftp |
| Destination Port: 1249 |
| Sequence Number: 4239887193 |
| Ack Number: 36925357 |
| Offset: 5 (20 bytes) |
| Reserved: %000000 |
| Flags: %011000 |
| 0. .... (No Urgent pointer) |
| .1 .... Ack |
| .. 1... Push |
| .. .0.. (No Reset) |
| .. ..0. (No SYN) |
| .. ...0 (No FIN) |
| |
| Window: 8760 |
| Checksum: 0x3EAB |
| Urgent Pointer: 0 |
| No TCP Options |
| |
| FTP Control - File Transfer Protocol |
| Line 1: PASV 192,168,0,1,100,20,245<CR><LF> |
| |
| FCS - Frame Check Sequence |
| FCS (Calculated): 0xBED4346D |
\====================================================================/
當收到PASV命令的迴應後，客戶端打開一個TCP連接，源端口爲一個暫時的端口，目的端口爲
服務器提供的暫時端口。
下圖顯示了客戶端的TCP連接建立過程，正如上面所說，目的端口爲5365。
/====================================================================\
| TCP - Transport Control Protocol |
| Source Port: 1250 |
| Destination Port: 5365 |
| Sequence Number: 36931503 |
| Ack Number: 0 |
| Offset: 7 (28 bytes) |
| Reserved: %000000 |
| Flags: %000010 |
| 0. .... (No Urgent pointer) |
| .0 .... (No Ack) |
| .. 0... (No Push) |
| .. .0.. (No Reset) |
| .. ..1. SYN |
| .. ...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 |
\====================================================================/
大多數人認爲在防火牆網絡環境中Passive模式比Port模式的問題小，但我們注意到在Passive
模式下，客戶端打開一個暫時的目的端口連接，一些防火牆或者CISCO設備的訪問列表(ACL)可
能會阻止這種連接，同樣服務器的迴應也是從一個暫時的端口到一個暫時的端口，防火牆或者
CISCO的訪問列表也會阻止這種連接。在CISCO路由器上你可以用訪問列表關鍵字"established
"來避免第二個問題，"established"關鍵字告訴路由器允許帶ACK字端的包通過，服務器端的S
YN ACK包帶有ACK字端。在新版本PIX IOS中也可以通過fixit關鍵字建立針對ftp協議的深層狀
態檢測過濾，其他大多數狀態檢測防火牆例如LinuxNetfilters也支持ftp協議的狀態檢測，進行
準確的PASV動態端口過濾。
>>2.3 用戶名和口令的明文傳輸
FTP另一個聲名狼藉的問題是它以明文方式發送用戶名和口令，也就是不加密地發送。任何人
只要在網絡中合適的位置放置一個協議分析儀就可以看到用戶名和口令；FTP發送的數據也是
以明文方式傳輸，通過對ftp連接的監控和數據收集就可以收集和重現ftp的數據傳輸並實現協
議連接回放。事實上很多用戶把相同的用戶名和口令用在不同的應用中，這樣這個問題可能
看起來更爲糟糕；如果***收集到FTP口令，他們也可能就得到了你在線帳號或者其他一些
機密數據的口令。
下面是通過tcpdump -- 一個著名的網絡協議分析程序抓取的ftp的完整通訊過程。
/===============================================================================\
21:55:36.682402 IP 192.168.0.1.2323 > 192.168.0.3.21: S 2047626269:2047626269(0)
win 65535 <mss 1460,nop,nop,sackOK> (DF)
21:55:36.682792 IP 192.168.0.3.21 > 192.168.0.1.2323: S 3917547047:3917547047(0)
ack 2047626270 win 65535 <mss 1460,nop,nop,sackOK> (DF)
21:55:36.682855 IP 192.168.0.1.2323 > 192.168.0.3.21: . ack 1 win 65535 (DF)
<TCP三步握手>
21:55:36.854899 IP 192.168.0.3.21 > 192.168.0.1.2323: P 1:115(114) ack 1 win 65535
(DF)
0x0000 4500 009a d570 4000 8006 a398 c0a8 0003 E....p@.........
0x0010 c0a8 0001 0015 0913 e981 0628 7a0c 4c1e ...........(z.L.
0x0020 5018 ffff cd50 0000 3232 302d 5468 6973 P....P..220-This
0x0030 2073 6572 7665 7220 6973 2066 6f72 2070 .server.is.for.p
0x0040 7269 7661 7465 2075 7365 206f 6e6c 790d rivate.use.only.
0x0050 0a32 .2
21:55:37.016115 IP 192.168.0.1.2323 > 192.168.0.3.21: . ack 115 win 65421 (DF)
0x0000 4500 0028 b8d0 4000 8006 c0aa c0a8 0001 E..(..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c1e e981 069a ........z.L.....
0x0020 5010 ff8d 6f83 0000 P...o...
21:55:37.016471 IP 192.168.0.3.21 > 192.168.0.1.2323: P 115:154(39) ack 1 win
65535 (DF)
<FTP協議連接>
0x0000 4500 004f d586 4000 8006 a3cd c0a8 0003 E..O..@.........
0x0010 c0a8 0001 0015 0913 e981 069a 7a0c 4c1e ............z.L.
0x0020 5018 ffff 074f 0000 3232 3020 506c 6561 P....O..220.Plea
0x0030 7365 2065 6e74 6572 2079 6f75 7220 6c6f se.enter.your.lo
0x0040 6769 6e20 6e61 6d65 206e 6f77 2e0d 0a gin.name.now...
21:55:37.022282 IP 192.168.0.1.2323 > 192.168.0.3.21: P 1:12(11) ack 154 win 65382
(DF)
0x0000 4500 0033 b8d2 4000 8006 c09d c0a8 0001 E..3..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c1e e981 06c1 ........z.L.....
0x0020 5018 ff66 c4eb 0000 5553 4552 2065 6c6c P..f....USER.ell
0x0030 790d 0a y..
<用戶名:elly>
21:55:37.059430 IP 192.168.0.3.21 > 192.168.0.1.2323: P 154:188(34) ack 12 win
65524 (DF)
0x0000 4500 004a d58b 4000 8006 a3cd c0a8 0003 E..J..@.........
0x0010 c0a8 0001 0015 0913 e981 06c1 7a0c 4c29 ............z.L)
0x0020 5018 fff4 b343 0000 3333 3120 5061 7373 P....C..331.Pass
0x0030 776f 7264 2072 6571 7569 7265 6420 666f word.required.fo
0x0040 7220 656c 6c79 202e 0d0a r.elly....
21:55:37.060301 IP 192.168.0.1.2323 > 192.168.0.3.21: P 12:27(15) ack 188 win
65348 (DF)
0x0000 4500 0037 b8db 4000 8006 c090 c0a8 0001 E..7..@.........
0x0010 c0a8 0003 0913 0015 7a0c 4c29 e981 06e3 ........z.L)....
0x0020 5018 ff44 e479 0000 5041 5353 2038 3838 P..D.y..PASS.888
0x0030 3838 3838 380d 0a 88888..
<密碼:88888888>
21:55:37.243954 IP 192.168.0.3.21 > 192.168.0.1.2323: . ack 27 win 65509 (DF)
0x0000 4500 0028 d59d 4000 8006 a3dd c0a8 0003 E..(..@.........
0x0010 c0a8 0001 0015 0913 e981 06e3 7a0c 4c38 ............z.L8
0x0020 5010 ffe5 6ec8 0000 0000 0000 0000 P...n.........
21:55:37.285586 IP 192.168.0.3.21 > 192.168.0.1.2323: . 188:1648(1460) ack 27 win
65509 (DF)
0x0000 4500 05dc d5a4 4000 8006 9e22 c0a8 0003 E.....@...."....
0x0010 c0a8 0001 0015 0913 e981 06e3 7a0c 4c38 ............z.L8
0x0020 5010 ffe5 0300 0000 3233 302d 5765 6c63 P.......230-Welc
0x0030 6f6d 6520 746f 2076 6920 4654 5020 7365 ome.to.vi.FTP.se
0x0040 7276 6572 0d0a 3233 302d 0d0a 3233 302d rver..230-..230-
0x0050 4375 Cu
<明文數據傳輸>
\===============================================================================/
>>3.0<< 改進: ftp安全擴展, SSL/TLS
在傳統的ftp通訊和傳輸過程中可以看出，ftp協議提供了一種簡單實用的網絡文件傳輸方法，
但是缺陷也是顯而易見的。傳統ftp服務缺乏對數據的機密性和完整性保護，對通訊雙方也沒
有可靠的認證措施，同時還存在着明文信息傳輸的弱點 --
在同一個網絡上的任何用戶都可能竊取到重要的信息。雖然近年來出現了很多種ftp的替代服
務，例如ssh加密通道的sftp/scp，或使用IPSEC協議的***通道等等，但是在大多數情況下，f
tp的通用性和易用性使得它在很長一段時間內必然無法被完全取代。所以如同其他一系列古董
服務(例如SMTP/HTTP)一樣，近年來也出現了一些不需要對ftp協議自身做完全更改的協議擴展
模塊，能夠良好的完成兼容性和功能擴展。ftp SSL/TLS Extension就是其中一種方式。
FTP協議的分析
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.