1. 程式人生 > >轉:tcpdump抓包分析(強烈推薦)

轉:tcpdump抓包分析(強烈推薦)

logs win 18C 所有 網絡數據 括號 auto -s shu

轉自:https://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=2666539134&idx=1&sn=5166f0aac718685382c0aa1cb5dbca45&scene=5&srcid=0527iHXDsFlkjBlkxHbM2S3E#rd

轉自:http://www.jianshu.com/p/8d9accf1d2f1

1 起因

前段時間,一直在調線上的一個問題:線上應用接受POST請求,請求body中的參數獲取不全,存在丟失的狀況。這個問題是偶發性的,大概發生的幾率為5%-10%左右,這個概率已經相當高了。在排查問題的過程中使用到了tcpdump和Wireshark進行抓包分析。感覺這兩個工具搭配起來幹活,非常完美。所有的網絡傳輸在這兩個工具搭配下,都無處遁形。

為了更好、更順手地能夠用好這兩個工具,特整理本篇文章,希望也能給大家帶來收獲。為大家之後排查問題,添一利器。

2 tcpdump與Wireshark介紹

在網絡問題的調試中,tcpdump應該說是一個必不可少的工具,和大部分linux下優秀工具一樣,它的特點就是簡單而強大。它是基於Unix系統的命令行式的數據包嗅探工具,可以抓取流動在網卡上的數據包。

默認情況下,tcpdump不會抓取本機內部通訊的報文。根據網絡協議棧的規定,對於報文,即使是目的地是本機,也需要經過本機的網絡協議層,所以本機通訊肯定是通過API進入了內核,並且完成了路由選擇。【比如本機的TCP通信,也必須要socket通信的基本要素:src ip port dst ip port】

如果要使用tcpdump抓取其他主機MAC地址的數據包,必須開啟網卡混雜模式,所謂混雜模式,用最簡單的語言就是讓網卡抓取任何經過它的數據包,不管這個數據包是不是發給它或者是它發出的。一般而言,Unix不會讓普通用戶設置混雜模式,因為這樣可以看到別人的信息,比如telnet的用戶名和密碼,這樣會引起一些安全上的問題,所以只有root用戶可以開啟混雜模式,開啟混雜模式的命令是:ifconfig en0 promisc, en0是你要打開混雜模式的網卡。

Linux抓包原理:

Linux抓包是通過註冊一種虛擬的底層網絡協議來完成對網絡報文(準確的說是網絡設備)消息的處理權。當網卡接收到一個網絡報文之後,它會遍歷系統中所有已經註冊的網絡協議,例如以太網協議、x25協議處理模塊來嘗試進行報文的解析處理,這一點和一些文件系統的掛載相似,就是讓系統中所有的已經註冊的文件系統來進行嘗試掛載,如果哪一個認為自己可以處理,那麽就完成掛載。

當抓包模塊把自己偽裝成一個網絡協議的時候,系統在收到報文的時候就會給這個偽協議一次機會,讓它來對網卡收到的報文進行一次處理,此時該模塊就會趁機對報文進行窺探,也就是把這個報文完完整整的復制一份,假裝是自己接收到的報文,匯報給抓包模塊。

Wireshark是一個網絡協議檢測工具,支持Windows平臺、Unix平臺、Mac平臺,一般只在圖形界面平臺下使用Wireshark,如果是Linux的話,直接使用tcpdump了,因為一般而言Linux都自帶的tcpdump,或者用tcpdump抓包以後用Wireshark打開分析。

在Mac平臺下,Wireshark通過WinPcap進行抓包,封裝的很好,使用起來很方便,可以很容易的制定抓包過濾器或者顯示過濾器,具體簡單使用下面會介紹。Wireshark是一個免費的工具,只要google一下就能很容易找到下載的地方。

所以,tcpdump是用來抓取數據非常方便,Wireshark則是用於分析抓取到的數據比較方便。

3 tcpdump使用

3.1 語法

類型的關鍵字

host(缺省類型): 指明一臺主機,如:host 210.27.48.2

net: 指明一個網絡地址,如:net 202.0.0.0

port: 指明端口號,如:port 23

確定方向的關鍵字

src: src 210.27.48.2, IP包源地址是210.27.48.2

dst: dst net 202.0.0.0, 目標網絡地址是202.0.0.0

dst or src(缺省值)

dst and src

協議的關鍵字:缺省值是監聽所有協議的信息包

fddi

ip

arp

rarp

tcp

udp

其他關鍵字

gateway

broadcast

less

greater

常用表達式:多條件時可以用括號,但是要用轉義

非 : ! or “not” (去掉雙引號)

且 : && or “and”

或 : || or “or”

3.2 選項

技術分享圖片

3.3 命令實踐

1、直接啟動tcpdump,將抓取所有經過第一個網絡接口上的數據包

技術分享圖片

2、抓取所有經過指定網絡接口上的數據包

技術分享圖片

3、抓取所有經過 en0,目的或源地址是 10.37.63.255 的網絡數據:

技術分享圖片

4、抓取主機10.37.63.255和主機10.37.63.61或10.37.63.95的通信:

技術分享圖片

5、抓取主機192.168.13.210除了和主機10.37.63.61之外所有主機通信的數據包:

技術分享圖片

6、抓取主機10.37.63.255除了和主機10.37.63.61之外所有主機通信的ip包

技術分享圖片

7、抓取主機10.37.63.3發送的所有數據:

技術分享圖片

8、抓取主機10.37.63.3接收的所有數據:

技術分享圖片

9、抓取主機10.37.63.3所有在TCP 80端口的數據包:

技術分享圖片

10、抓取HTTP主機10.37.63.3在80端口接收到的數據包:

技術分享圖片

11、抓取所有經過 en0,目的或源端口是 25 的網絡數據

技術分享圖片

12、抓取所有經過 en0,網絡是 192.168上的數據包

技術分享圖片

13、協議過濾

技術分享圖片

14、抓取所有經過 en0,目的地址是 192.168.1.254 或 192.168.1.200 端口是 80 的 TCP 數據

技術分享圖片

15、抓取所有經過 en0,目標 MAC 地址是 00:01:02:03:04:05 的 ICMP 數據

技術分享圖片

16、抓取所有經過 en0,目的網絡是 192.168,但目的主機不是 192.168.1.200 的 TCP 數據

技術分享圖片

17、只抓 SYN 包

技術分享圖片

18、抓 SYN, ACK

技術分享圖片

19、抓 SMTP 數據,抓取數據區開始為”MAIL”的包,”MAIL”的十六進制為 0x4d41494c

技術分享圖片

20、抓 HTTP GET 數據,”GET “的十六進制是 0x47455420

技術分享圖片

21、抓 SSH 返回,”SSH-“的十六進制是 0x5353482D

技術分享圖片

22、高級包頭過濾如前兩個的包頭過濾,首先了解如何從包頭過濾信息:

技術分享圖片

23、抓 DNS 請求數據

技術分享圖片

24、其他-c 參數對於運維人員來說也比較常用,因為流量比較大的服務器,靠人工 CTRL+C 還是抓的太多,於是可以用-c 參數指定抓多少個包。

技術分享圖片

3.4 抓個網站練練

想抓取訪問某個網站時的網絡數據。比如網站 http://www.baidu.com/ 怎麽做?

1、通過tcpdump截獲主機www.baidu.com發送與接收所有的數據包

技術分享圖片

2、訪問這個網站

技術分享圖片

3、想要看到詳細的http報文。怎麽做?

技術分享圖片

4、分析抓取到的報文

技術分享圖片

4 tcpdump抓取TCP包分析

TCP傳輸控制協議是面向連接的可靠的傳輸層協議,在進行數據傳輸之前,需要在傳輸數據的兩端(客戶端和服務器端)創建一個連接,這個連接由一對插口地址唯一標識,即是在IP報文首部的源IP地址、目的IP地址,以及TCP數據報首部的源端口地址和目的端口地址。TCP首部結構如下:

技術分享圖片

註意:通常情況下,一個正常的TCP連接,都會有三個階段:1、TCP三次握手;2、數據傳送;3、TCP四次揮手

其中在TCP連接和斷開連接過程中的關鍵部分如下:

源端口號:即發送方的端口號,在TCP連接過程中,對於客戶端,端口號往往由內核分配,無需進程指定;

目的端口號:即發送目的的端口號;

序號:即為發送的數據段首個字節的序號;

確認序號:在收到對方發來的數據報,發送確認時期待對方下一次發送的數據序號;

SYN:同步序列編號,Synchronize Sequence Numbers;

ACK:確認編號,Acknowledgement Number;

FIN:結束標誌,FINish;

4.1 TCP三次握手

三次握手的過程如下:

技術分享圖片

step1. 由客戶端向服務器端發起TCP連接請求。Client發送:同步序列編號SYN置為1,發送序號Seq為一個隨機數,這裏假設為X,確認序號ACK置為0;

step2. 服務器端接收到連接請求。Server響應:同步序列編號SYN置為1,並將確認序號ACK置為X+1,然後生成一個隨機數Y作為發送序號Seq(因為所確認的數據報的確認序號未初始化);

step3. 客戶端對接收到的確認進行確認。Client發送:將確認序號ACK置為Y+1,然後將發送序號Seq置為X+1(即為接收到的數據報的確認序號);

為什麽是三次握手而不是兩次對於step3的作用,假設一種情況,客戶端A向服務器B發送一個連接請求數據報,然後這個數據報在網絡中滯留導致其遲到了,雖然遲到了,但是服務器仍然會接收並發回一個確認數據報。但是A卻因為久久收不到B的確認而將發送的請求連接置為失效,等到一段時間後,接到B發送過來的確認,A認為自己現在沒有發送連接,而B卻一直以為連接成功了,於是一直在等待A的動作,而A將不會有任何的動作了。這會導致服務器資源白白浪費掉了,因此,兩次握手是不行的,因此需要再加上一次,對B發過來的確認再進行一次確認,即確認這次連接是有效的,從而建立連接。

對於雙方,發送序號的初始化為何值有的系統中是顯式的初始化序號是0,但是這種已知的初始化值是非常危險的,因為這會使得一些黑客鉆漏洞,發送一些數據報來破壞連接。因此,初始化序號因為取隨機數會更好一些,並且是越隨機越安全。

tcpdump抓TCP三次握手抓包分析:

sudotcpdump-n-S-ilo0host10.37.63.3andtcpport8080

# 接著再運行:

curlhttp://10.37.63.3:8080/atbg/doc

控制臺輸出:

技術分享圖片

每一行中間都有這個包所攜帶的標誌:

S=SYN,發起連接標誌。

P=PUSH,傳送數據標誌。

F=FIN,關閉連接標誌。

ack,表示確認包。

RST=RESET,異常關閉連接。

.,表示沒有任何標誌。

第1行:16:00:13.486776,從10.37.63.3(client)的臨時端口61725向10.37.63.3(server)的8080監聽端口發起連接,client初始包序號seq為1944916150,滑動窗口大小為65535字節(滑動窗口即tcp接收緩沖區的大小,用於tcp擁塞控制),mss大小為16344(即可接收的最大包長度,通常為MTU減40字節,IP頭和TCP頭各20字節)。【seq=1944916150,ack=0,syn=1】

第2行:16:00:13.486850,server響應連接,同時帶上第一個包的ack信息,為client端的初始包序號seq加1,即1944916151,即server端下次等待接受這個包序號的包,用於tcp字節流的順序控制。Server端的初始包序號seq為1119565918,mss也是16344。【seq=1119565918,ack=1944916151,syn=1】

第3行:15:46:13.084161,client再次發送確認連接,tcp連接三次握手完成,等待傳輸數據包。【ack=1119565919,seq=1944916151】

4.2 TCP四次揮手

連接雙方在完成數據傳輸之後就需要斷開連接。由於TCP連接是屬於全雙工的,即連接雙方可以在一條TCP連接上互相傳輸數據,因此在斷開時存在一個半關閉狀態,即有有一方失去發送數據的能力,卻還能接收數據。因此,斷開連接需要分為四次。主要過程如下:

技術分享圖片

step1. 主機A向主機B發起斷開連接請求,之後主機A進入FIN-WAIT-1狀態;

step2. 主機B收到主機A的請求後,向主機A發回確認,然後進入CLOSE-WAIT狀態;

step3. 主機A收到B的確認之後,進入FIN-WAIT-2狀態,此時便是半關閉狀態,即主機A失去發送能力,但是主機B卻還能向A發送數據,並且A可以接收數據。此時主機B占主導位置了,如果需要繼續關閉則需要主機B來操作了;

step4. 主機B向A發出斷開連接請求,然後進入LAST-ACK狀態;

step5. 主機A接收到請求後發送確認,進入TIME-WAIT狀態,等待2MSL之後進入CLOSED狀態,而主機B則在接受到確認後進入CLOSED狀態;

為何主機A在發送了最後的確認後沒有進入CLOSED狀態,反而進入了一個等待2MSL的TIME-WAIT主要作用有兩個:

第一,確保主機A最後發送的確認能夠到達主機B。如果處於LAST-ACK狀態的主機B一直收不到來自主機A的確認,它會重傳斷開連接請求,然後主機A就可以有足夠的時間去再次發送確認。但是這也只能盡最大力量來確保能夠正常斷開,如果主機A的確認總是在網絡中滯留失效,從而超過了2MSL,最後也無法正常斷開;

第二,如果主機A在發送了確認之後立即進入CLOSED狀態。假設之後主機A再次向主機B發送一條連接請求,而這條連接請求比之前的確認報文更早地到達主機B,則會使得主機B以為這條連接請求是在舊的連接中A發出的報文,並不看成是一條新的連接請求了,即使得這個連接請求失效了,增加2MSL的時間可以使得這個失效的連接請求報文作廢,這樣才不影響下次新的連接請求中出現失效的連接請求。

為什麽斷開連接請求報文只有三個,而不是四個因為在TCP連接過程中,確認的發送有一個延時(即經受延時的確認),一端在發送確認的時候將等待一段時間,如果自己在這段事件內也有數據要發送,就跟確認一起發送,如果沒有,則確認單獨發送。而我們的抓包實驗中,由服務器端先斷開連接,之後客戶端在確認的延遲時間內,也有請求斷開連接需要發送,於是就與上次確認一起發送,因此就只有三個數據報了。

5 Wireshark分析tcpdump抓包結果

1、啟動8080端口,tcpdump抓包命令如下:

tcpdump-ilo0-s0-n-Shost10.37.63.3andport8080-w./Desktop/tcpdump_10.37.63.3_8080_20160525.cap

# 然後再執行curl

curlhttp://10.37.63.3:8080/atbg/doc

2、使用Wireshark打開tcpdump_10.37.63.3_8080_20160525.cap文件

技術分享圖片

No. 1-4 行:TCP三次握手環節;

No. 5-8 行:TCP傳輸數據環節;

No. 9-13 行:TCP四次揮手環節;

3、順便說一個查看 http 請求和響應的方法:

技術分享圖片

彈窗如下圖所示,上面紅色部分為請求信息,下面藍色部分為響應信息:

技術分享圖片

以上是Wireshark分析tcpdump的簡單使用,Wireshark更強大的是過濾器工具,大家可以自行去多研究學習Wireshark,用起來還是比較爽的。

推薦幾個關於Wireshark的文章:

Wireshark基本介紹和學習TCP三次握手

一站式學習Wireshark




轉:tcpdump抓包分析(強烈推薦)