java實現FTP協議:wireshark抓包解析

本節我們看看ftp協議的數據包格式,同時使用代碼加以實現。首先我們現在機器上安裝ftp服務器,我在自己的機器上安裝了QuickFTP Server,它是我隨便找來的一款Mac ftp服務器,如下圖所示,我將連接端口設置爲2100,同時設置了用戶名和密碼,如此我們就可以通過抓包的方式瞭解協議的數據包格式:

屏幕快照 2020-02-20 上午10.32.01.png

然後打開wireshark,在過濾條件中輸入tcp.port==2100,接着開始監聽,如此就能抓取相應ftp數據包。接着我從手機上使用ftp客戶端連接到服務器,同時使用設置好的用戶名密碼登陸,在wireshark上抓包結果如下:

屏幕快照 2020-02-20 上午10.41.06.png

注意到前3條是tcp連接的三次握手,第四條是雙方溝通tcp數據傳輸一些參數可以忽略,真正屬於ftp協議數據的是第5條服務器發送給客戶端的信息,點擊查看內如如下:
屏幕快照 2020-02-20 上午10.43.14.png
我們注意看它的數據部分,那纔是ftp協議的專有內如,首先開始對應回覆碼220,上一節我們描述過回覆碼三位數字的作用,該數值表示服務器已經準備好接收客戶端的請求,接下來的字符串時服務器對該回復碼的文字解釋,在協議實現是不用關心。這裏要注意的是,所有包含協議數據的數據包都對應[PSH,ACK],如果僅僅含有[ACK]那就是對上一次接收到數據包的應答而已,所以點擊下一條[PSH,ACK]就可以看ftp協議的下一個數據包內容,於是我們點擊查看下一條包含ftp數據的協議包:

屏幕快照 2020-02-20 上午10.49.22.png

數據內容以字符串"USER"開始,這表示客戶端向服務器端提交用戶名,而且用戶名以明文字符串"chenyi"來表示。然後繼續看下一條[PSH,ACK]數據包,其內容如下:
屏幕快照 2020-02-20 上午10.52.13.png
數據以331開頭,該回復碼在前幾節解釋過,它表示客戶端的請求被接受,同時請求正在處理中,還需要執行後續步驟,它表示用戶名正確但還需要提交密碼,於是我們繼續查看客戶端發給服務器的下一條[PSH,ACK]數據包,其內容如下:

屏幕快照 2020-02-20 上午10.56.12.png

在數據部分以字符串"PASS"開始,這是操作命令,表示客戶端向服務器提供密碼,而且可以明確看到密碼爲1111,繼續看服務器回覆給客戶端的[PSH,ACK]數據包:

屏幕快照 2020-02-20 上午10.58.23.png

數據部分以回覆碼230開始,該數值表示用戶登錄成功,所有操作將繼續進行,再看下一個客戶端發送給服務器的[PSH,ACK]數據包,可以看到數據內容僅僅是字符串"PWD"這是客戶端在向服務器請求當前文件目錄,由此查看服務器返回的[PSH,ACK]數據包:
屏幕快照 2020-02-20 上午11.02.35.png
回覆數據首先是回覆碼257,它表示路徑名確立,接着是”\“表示當前處於根目錄,繼續看下一條客戶端回覆給服務器的[PSH,ACK]數據包:
屏幕快照 2020-02-20 上午11.08.18.png
回覆的數據只有操作命令”FEAT",它表示讓服務器列舉當前目錄下的文件內容,接下來看服務器回覆的[PSH,ACK]數據包內容:
屏幕快照 2020-02-20 上午11.10.44.png
數據包含的回覆碼爲211,他表示服務器將返回包含系統信息的內容,繼續看客戶端回覆的[PSH,ACK]數據包:
屏幕快照 2020-02-20 上午11.15.41.png
客戶端回覆給服務器的數據爲"PASV"它表示客戶端將以被動模式接收服務器數據,也就是讓服務器等待客戶端發起的數據請求,由此我們看下一條服務器回覆的[PSH,ACK]:
屏幕快照 2020-02-20 上午11.17.34.png
數據起始以227開始,它是對上一條"PASV"請求的迴應,它表示傳輸進入被動模式,特別需要注意的是數據中包含了用於數據傳輸的ip和端口號,其中ip就是192.168.2.243,這是服務器地址,接下來的兩個字節數據用於計算數據傳輸端口,計算方法是17*256+222結果爲4574,也就是客戶端要連接服務器的4574端口去獲取數據,下一次客戶端將通過該端口號獲得數據內容,繼續往下看客戶端發送的[PSH,ACK]數據包:

屏幕快照 2020-02-20 上午11.21.34.png

數據內容爲"TYPE A",這是客戶端向服務器設定數據的傳輸格式,前面我們提到過ftp主要有兩種數據傳輸格式,一種是基於ASCII的文本模式,另一種是基於二進制的模式,該命令表示數據傳輸使用ASCII文本模式,我們看下一條服務器返回的[PSH,ACK]:
屏幕快照 2020-02-20 上午11.24.49.png
數據的回覆碼爲220,它表示命令請求完成,同時在解釋字符串中它表明數據傳輸將使用ASCII嗎模式,繼續看客戶端發送給服務器的下一條[PSH,ACK]:
屏幕快照 2020-02-20 上午11.27.23.png

客戶端向服務器發送的請求命令爲"LIST",它要求枚舉當前路徑下的文件信息,於是我們繼續看服務器返回的[PSH,ACK]:

屏幕快照 2020-02-20 上午11.29.29.png
服務器返回的回覆碼是150,它表示請求被接受,數據通道已經打開,此時我們要監聽端口4574才能獲得客戶端和服務器通訊的數據,因此在wireshark上將過濾條件改爲tcp.port==4574,這時可以看到雙方tcp三次握手,接着就是服務器推送給客戶端的信息:

屏幕快照 2020-02-20 下午4.57.35.png

內容顯示的是當前路徑下的文件信息,它採用了unix的文件列舉格式,首先第一個字節表示文件類型,’-'表示普通文件,'s’表示socket等,接下來rw-------表示文件的權限,前三個字符表示用戶權限,接下來三個字符表示羣權限,最後表示其他用戶權限,‘-’表示不允許任何操作。接下來是數值表示鏈接數,繼續下來的字符串表示文件所屬用戶及所在羣,接下來的數字是文件大小,單位爲字節,接下來是修改時間和文件名,格式具體內容可以搜索。

數據內容傳輸結束後tcp連接關閉,我們重新回到命令傳輸通道,可以看到服務器發來如下[PSH,ACK]數據包:

屏幕快照 2020-02-20 下午5.17.20.png
回覆碼爲226,對應含義爲數據傳輸連接關閉,從它附帶的文本信息也得知,它表示數據傳輸完成。

以上就是對ftp協議的抓包分析,下一節我們研究如何進行代碼實現。

更詳細的講解和代碼調試演示過程,請點擊鏈接

更多技術信息,包括操作系統,編譯器,面試算法,機器學習,人工智能,請關照我的公衆號:
這裏寫圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章