簡介
網絡抓包工具。用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網絡上的數據包進行截獲的包分析工具。 tcpdump可以將網絡中傳送的數據包的“頭”完全截獲下來提供分析。它支持針對網絡層、協議、主機、網絡或端口的過濾，並提供and、or、not等邏輯語句來幫助你去掉無用的信息。
實用命令實例
默認啓動
普通情況下，直接啓動tcpdump將監視第一個網絡接口上所有流過的數據包。
tcpdump
監視指定網絡接口的數據包
tcpdump -i eth1
如果不指定網卡，默認tcpdump只會監視第一個網絡接口，一般是eth0，下面的例子都沒有指定網絡接口。
監視指定主機的數據包
打印所有進入或離開主機爲sundown的數據包.
tcpdump host sundown
也可以指定ip,例如截獲所有210.27.48.1 的主機收到的和發出的所有的數據包
tcpdump host 210.27.48.1
打印helios 與 hot 或者與 ace 之間通信的數據包
tcpdump host helios and \( hot or ace \)
截獲主機210.27.48.1 和主機210.27.48.2 或210.27.48.3的通信
tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 \)
打印ace與任何其他主機之間通信的IP 數據包, 但不包括與helios之間的數據包.
tcpdump ip host ace and not helios
如果想要獲取主機210.27.48.1除了和主機210.27.48.2之外所有主機通信的ip包，使用命令：
tcpdump ip host 210.27.48.1 and ! 210.27.48.2
截獲主機hostname發送的所有數據
tcpdump -i eth0 src host hostname
監視所有送到主機hostname的數據包
tcpdump -i eth0 dst host hostname
監視指定主機和端口的數據包
如果想要獲取主機210.27.48.1接收或發出的telnet包，使用如下命令
tcpdump tcp port 23 host 210.27.48.1
對本機的udp 123 端口進行監視 123 爲ntp的服務端口
tcpdump udp port 123
輸出信息含義
首先我們注意一下，基本上tcpdump總的的輸出格式爲：系統時間 來源主機.端口 > 目標主機.端口 數據包參數
tcpdump 的輸出格式與協議有關.以下簡要描述了大部分常用的格式及相關例子.
鏈路層頭
對於FDDI網絡, '-e' 使tcpdump打印出指定數據包的'frame control' 域, 源和目的地址, 以及包的長度.(frame control域
控制對包中其他域的解析). 一般的包(比如那些IP datagrams)都是帶有'async'(異步標誌)的數據包，並且有取值0到7的優先級;
比如 'async4'就代表此包爲異步數據包，並且優先級別爲4. 通常認爲,這些包們會內含一個 LLC包(邏輯鏈路控制包); 這時,如果此包
不是一個ISO datagram或所謂的SNAP包，其LLC頭部將會被打印(nt:應該是指此包內含的 LLC包的包頭).
對於Token Ring網絡(令牌環網絡), '-e' 使tcpdump打印出指定數據包的'frame control'和'access control'域, 以及源和目的地址,
外加包的長度. 與FDDI網絡類似, 此數據包通常內含LLC數據包. 不管 是否有'-e'選項.對於此網絡上的'source-routed'類型數據包(nt:
意譯爲:源地址被追蹤的數據包,具體含義未知,需補充), 其包的源路由信息總會被打印.
對於802.11網絡(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定數據包的'frame control域,
包頭中包含的所有地址, 以及包的長度.與FDDI網絡類似, 此數據包通常內含LLC數據包.
(注意: 以下的描述會假設你熟悉SLIP壓縮算法 (nt:SLIP爲Serial Line Internet Protocol.), 這個算法可以在
RFC-1144中找到相關的蛛絲馬跡.)
對於SLIP網絡(nt:SLIP links, 可理解爲一個網絡, 即通過串行線路建立的連接, 而一個簡單的連接也可看成一個網絡),
數據包的'direction indicator'('方向指示標誌')("I"表示入, "O"表示出), 類型以及壓縮信息將會被打印. 包類型會被首先打印.
類型分爲ip, utcp以及ctcp(nt:未知, 需補充). 對於ip包,連接信息將不被打印(nt:SLIP連接上,ip包的連接信息可能無用或沒有定義.
reconfirm).對於TCP數據包, 連接標識緊接着類型表示被打印. 如果此包被壓縮, 其被編碼過的頭部將被打印.
此時對於特殊的壓縮包,會如下顯示:
*S+n 或者 *SA+n, 其中n代表包的(順序號或(順序號和應答號))增加或減少的數目(nt | rt:S,SA拗口, 需再譯).
對於非特殊的壓縮包,0個或更多的'改變'將會被打印.'改變'被打印時格式如下:
'標誌'+/-/=n 包數據的長度 壓縮的頭部長度.
其中'標誌'可以取以下值:
U(代表緊急指針), W(指緩衝窗口), A(應答), S(序列號), I(包ID),而增量表達'=n'表示被賦予新的值, +/-表示增加或減少.
比如, 以下顯示了對一個外發壓縮TCP數據包的打印, 這個數據包隱含一個連接標識(connection identifier); 應答號增加了6,
順序號增加了49, 包ID號增加了6; 包數據長度爲3字節(octect), 壓縮頭部爲6字節.(nt:如此看來這應該不是一個特殊的壓縮數據包).
ARP/RARP 數據包
tcpdump對Arp/rarp包的輸出信息中會包含請求類型及該請求對應的參數. 顯示格式簡潔明瞭. 以下是從主機rtsg到主機csam的'rlogin'
(遠程登錄)過程開始階段的數據包樣例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第一行表示:rtsg發送了一個arp數據包(nt:向全網段發送,arp數據包）以詢問csam的以太網地址
Csam（nt:可從下文看出來, 是Csam）以她自己的以太網地址做了迴應(在這個例子中, 以太網地址以大寫的名字標識, 而internet
地址(即ip地址)以全部的小寫名字標識).
如果使用tcpdump -n, 可以清晰看到以太網以及ip地址而不是名字標識:
arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
如果我們使用tcpdump -e, 則可以清晰的看到第一個數據包是全網廣播的, 而第二個數據包是點對點的:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
第一個數據包表明:以arp包的源以太地址是RTSG, 目標地址是全以太網段, type域的值爲16進制0806(表示ETHER_ARP(nt:arp包的類型標識)),
包的總長度爲64字節.
TCP 數據包
(注意:以下將會假定你對 RFC-793所描述的TCP熟悉. 如果不熟, 以下描述以及tcpdump程序可能對你幫助不大.(nt:警告可忽略,
只需繼續看, 不熟悉的地方可回頭再看.).
通常tcpdump對tcp數據包的顯示格式如下:
src > dst: flags data-seqno ack window urgent options
src 和 dst 是源和目的IP地址以及相應的端口. flags 標誌由S(SYN), F(FIN), P(PUSH, R(RST),
W(ECN CWT(nt | rep:未知, 需補充))或者 E(ECN-Echo(nt | rep:未知, 需補充))組成,
單獨一個'.'表示沒有flags標識. 數據段順序號(Data-seqno)描述了此包中數據所對應序列號空間中的一個位置(nt:整個數據被分段,
每段有一個順序號, 所有的順序號構成一個序列號空間)(可參考以下例子). Ack 描述的是同一個連接,同一個方向,下一個本端應該接收的
(對方應該發送的)數據片段的順序號. Window是本端可用的數據接收緩衝區的大小(也是對方發送數據時需根據這個大小來組織數據).
Urg(urgent) 表示數據包中有緊急的數據. options 描述了tcp的一些選項, 這些選項都用尖括號來表示(如 <mss 1024>).
src, dst 和 flags 這三個域總是會被顯示. 其他域的顯示與否依賴於tcp協議頭裏的信息.
這是一個從trsg到csam的一個rlogin應用登錄的開始階段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
第一行表示有一個數據包從rtsg主機的tcp端口1023發送到了csam主機的tcp端口login上(nt:udp協議的端口和tcp協議的端
口是分別的兩個空間, 雖然取值範圍一致). S表示設置了SYN標誌. 包的順序號是768512, 並且沒有包含數據.(表示格式
爲:'first:last(nbytes)', 其含義是'此包中數據的順序號從first開始直到last結束，不包括last. 並且總共包含nbytes的
用戶數據'.) 沒有捎帶應答(nt:從下文來看，第二行纔是有捎帶應答的數據包), 可用的接受窗口的大小爲4096bytes, 並且請求端(rtsg)
的最大可接受的數據段大小是1024字節(nt:這個信息作爲請求發向應答端csam, 以便雙方進一步的協商).
Csam 向rtsg 回覆了基本相同的SYN數據包, 其區別只是多了一個' piggy-backed ack'(nt:捎帶回的ack應答, 針對rtsg的SYN數據包).
rtsg 同樣針對csam的SYN數據包回覆了一ACK數據包作爲應答. '.'的含義就是此包中沒有標誌被設置. 由於此應答包中不含有數據, 所以
包中也沒有數據段序列號. 提醒! 此ACK數據包的順序號只是一個小整數1. 有如下解釋:tcpdump對於一個tcp連接上的會話, 只打印會話兩端的
初始數據包的序列號,其後相應數據包只打印出與初始包序列號的差異.即初始序列號之後的序列號, 可被看作此會話上當前所傳數據片段在整個
要傳輸的數據中的'相對字節'位置(nt:雙方的第一個位置都是1, 即'相對字節'的開始編號). '-Ｓ'將覆蓋這個功能,
使數據包的原始順序號被打印出來.
第六行的含義爲:rtsg 向 csam發送了19字節的數據(字節的編號爲2到20，傳送方向爲rtsg到csam). 包中設置了PUSH標誌. 在第7行,
csam 喊到， 她已經從rtsg中收到了21以下的字節, 但不包括21編號的字節. 這些字節存放在csam的socket的接收緩衝中, 相應地,
csam的接收緩衝窗口大小會減少19字節(nt:可以從第5行和第7行win屬性值的變化看出來). csam在第7行這個包中也向rtsg發送了一個
字節. 在第8行和第9行, csam 繼續向rtsg 分別發送了兩個只包含一個字節的數據包, 並且這個數據包帶PUSH標誌.
如果所抓到的tcp包(nt:即這裏的snapshot)太小了，以至tcpdump無法完整得到其頭部數據, 這時, tcpdump會盡量解析這個不完整的頭,
並把剩下不能解析的部分顯示爲'[|tcp]'. 如果頭部含有虛假的屬性信息(比如其長度屬性其實比頭部實際長度長或短), tcpdump會爲該頭部
顯示'[bad opt]'. 如果頭部的長度告訴我們某些選項(nt | rt:從下文來看， 指tcp包的頭部中針對ip包的一些選項, 回頭再翻)會在此包中,
而真正的IP(數據包的長度又不夠容納這些選項, tcpdump會顯示'[bad hdr length]'.
抓取帶有特殊標誌的的TCP包(如SYN-ACK標誌, URG-ACK標誌等).
在TCP的頭部中, 有8比特(bit)用作控制位區域, 其取值爲:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:從表達方式上可推斷:這8個位是用或的方式來組合的, 可回頭再翻)
現假設我們想要監控建立一個TCP連接整個過程中所產生的數據包. 可回憶如下:TCP使用3次握手協議來建立一個新的連接; 其與此三次握手
連接順序對應，並帶有相應TCP控制標誌的數據包如下:
1) 連接發起方(nt:Caller)發送SYN標誌的數據包
2) 接收方(nt:Recipient)用帶有SYN和ACK標誌的數據包進行迴應
3) 發起方收到接收方迴應後再發送帶有ACK標誌的數據包進行迴應
0 15 31
-----------------------------------------------------------------
| source port | destination port |
-----------------------------------------------------------------
| sequence number |
-----------------------------------------------------------------
| acknowledgment number |
-----------------------------------------------------------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
-----------------------------------------------------------------
| TCP checksum | urgent pointer |
-----------------------------------------------------------------
一個TCP頭部,在不包含選項數據的情況下通常佔用20個字節(nt | rt:options 理解爲選項數據，需回譯). 第一行包含0到3編號的字節,
第二行包含編號4-7的字節.
如果編號從0開始算, TCP控制標誌位於13字節(nt:第四行左半部分).
0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | rsvd |C|E|U|A|P|R|S|F| window size |
----------------|---------------|---------------|----------------
| | 13th octet | | |
讓我們仔細看看編號13的字節:
| |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
這裏有我們感興趣的控制標誌位. 從右往左這些位被依次編號爲0到7, 從而 PSH位在3號, 而URG位在5號.
提醒一下自己, 我們只是要得到包含SYN標誌的數據包. 讓我們看看在一個包的包頭中, 如果SYN位被設置, 到底
在13號字節發生了什麼:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
在控制段的數據中, 只有比特1(bit number 1)被置位.
假設編號爲13的字節是一個8位的無符號字符型,並且按照網絡字節號排序(nt:對於一個字節來說，網絡字節序等同於主機字節序), 其二進制值
如下所示:
00000010
並且其10進制值爲:
0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2(nt: 1 * 2^6 表示1乘以2的6次方, 也許這樣更
清楚些, 即把原來表達中的指數7 6 ... 0挪到了下面來表達)
接近目標了, 因爲我們已經知道, 如果數據包頭部中的SYN被置位, 那麼頭部中的第13個字節的值爲2(nt: 按照網絡序, 即大頭方式, 最重要的字節
在前面(在前面,即該字節實際內存地址比較小, 最重要的字節,指數學表示中數的高位, 如356中的3) ).
表達爲tcpdump能理解的關係式就是:
tcp[13] 2
從而我們可以把此關係式當作tcpdump的過濾條件, 目標就是監控只含有SYN標誌的數據包:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 指網絡接口, 如eth0)
這個表達式是說"讓TCP數據包的第13個字節擁有值2吧", 這也是我們想要的結果.
現在, 假設我們需要抓取帶SYN標誌的數據包, 而忽略它是否包含其他標誌.(nt:只要帶SYN就是我們想要的). 讓我們來看看當一個含有
SYN-ACK的數據包(nt:SYN 和 ACK 標誌都有), 來到時發生了什麼:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
13號字節的1號和4號位被置位, 其二進制的值爲:
00010010
轉換成十進制就是:
0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18(nt: 1 * 2^6 表示1乘以2的6次方, 也許這樣更
清楚些, 即把原來表達中的指數7 6 ... 0挪到了下面來表達)
現在, 卻不能只用'tcp[13] 18'作爲tcpdump的過濾表達式, 因爲這將導致只選擇含有SYN-ACK標誌的數據包, 其他的都被丟棄.
提醒一下自己, 我們的目標是: 只要包的SYN標誌被設置就行, 其他的標誌我們不理會.
爲了達到我們的目標, 我們需要把13號字節的二進制值與其他的一個數做AND操作(nt:邏輯與)來得到SYN比特位的值. 目標是:只要SYN 被設置
就行, 於是我們就把她與上13號字節的SYN值(nt: 00000010).
00010010 SYN-ACK 00000010 SYN
AND 00000010 (we want SYN) AND 00000010 (we want SYN)
-------- --------
= 00000010 = 00000010
我們可以發現, 不管包的ACK或其他標誌是否被設置, 以上的AND操作都會給我們相同的值, 其10進製表達就是2(2進製表達就是00000010).
從而我們知道, 對於帶有SYN標誌的數據包, 以下的表達式的結果總是真(true):
( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13, 即13號字節的值)
靈感隨之而來, 我們於是得到了如下的tcpdump 的過濾表達式
tcpdump -i xl0 'tcp[13] & 2 2'
注意, 單引號或反斜杆(nt: 這裏用的是單引號)不能省略, 這可以防止shell對&的解釋或替換.
UDP 數據包
UDP 數據包的顯示格式，可通過rwho這個具體應用所產生的數據包來說明:
actinide.who > broadcast.who: udp 84
其含義爲:actinide主機上的端口who向broadcast主機上的端口who發送了一個udp數據包(nt: actinide和broadcast都是指Internet地址).
這個數據包承載的用戶數據爲84個字節.
一些UDP服務可從數據包的源或目的端口來識別，也可從所顯示的更高層協議信息來識別. 比如, Domain Name service requests(DNS 請求,
在RFC-1034/1035中), 和Sun RPC calls to NFS(對NFS服務器所發起的遠程調用(nt: 即Sun RPC)，在RFC-1050中有對遠程調用的描述).
UDP 名稱服務請求
(注意:以下的描述假設你對Domain Service protoco(nt:在RFC-103中有所描述), 否則你會發現以下描述就是天書(nt:希臘文天書,
不必理會, 嚇嚇你的, 接着看就行))
名稱服務請求有如下的格式:
src > dst: id op? flags qtype qclass name (len)
(nt: 從下文來看, 格式應該是src > dst: id op flags qtype qclass? name (len))
比如有一個實際顯示爲:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
主機h2opolo 向helios 上運行的名稱服務器查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等於A). 此查詢本身的id號爲'3'. 符號
'+'意味着遞歸查詢標誌被設置(nt: dns服務器可向更高層dns服務器查詢本服務器不包含的地址記錄). 這個最終通過IP包發送的查詢請求
數據長度爲37字節, 其中不包括UDP和IP協議的頭數據. 因爲此查詢操作爲默認值(nt | rt: normal one的理解), op字段被省略.
如果op字段沒被省略, 會被顯示在'3' 和'+'之間. 同樣, qclass也是默認值, C_IN, 從而也沒被顯示, 如果沒被忽略, 她會被顯示在'A'之後.
異常檢查會在方括中顯示出附加的域: 如果一個查詢同時包含一個迴應(nt: 可理解爲, 對之前其他一個請求的迴應), 並且此迴應包含權威或附加記錄段,
ancount, nscout, arcount(nt: 具體字段含義需補充) 將被顯示爲'[na]', '[nn]', '[nau]', 其中n代表合適的計數. 如果包中以下
迴應位(比如AA位, RA位, rcode位), 或者字節2或3中任何一個'必須爲0'的位被置位(nt: 設置爲1), '[b2&3]=x' 將被顯示, 其中x表示
頭部字節2與字節3進行與操作後的值.
UDP 名稱服務應答
對名稱服務應答的數據包，tcpdump會有如下的顯示格式
src > dst: id op rcode flags a/n/au type class data (len)
比如具體顯示如下:
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
第一行表示: helios 對h2opolo 所發送的3號查詢請求迴應了3條回答記錄(nt | rt: answer records), 3條名稱服務器記錄,
以及7條附加的記錄. 第一個回答記錄(nt: 3個回答記錄中的第一個)類型爲A(nt: 表示地址), 其數據爲internet地址128.32.137.3.
此迴應UDP數據包, 包含273字節的數據(不包含UPD和IP的頭部數據). op字段和rcode字段被忽略(nt: op的實際值爲Query, rcode, 即
response code的實際值爲NoError), 同樣被忽略的字段還有class 字段(nt | rt: 其值爲C_IN, 這也是A類型記錄默認取值)
第二行表示: helios 對h2opolo 所發送的2號查詢請求做了迴應. 迴應中, rcode編碼爲NXDomain(nt: 表示不存在的域)), 沒有回答記錄,
但包含一個名稱服務器記錄, 不包含權威服務器記錄(nt | ck: 從上文來看, 此處的authority records 就是上文中對應的additional
records). '*'表示權威服務器回答標誌被設置(nt: 從而additional records就表示的是authority records).
由於沒有回答記錄, type, class, data字段都被忽略.
flag字段還有可能出現其他一些字符, 比如'-'(nt: 表示可遞歸地查詢, 即RA 標誌沒有被設置), '|'(nt: 表示被截斷的消息, 即TC 標誌
被置位). 如果應答(nt | ct: 可理解爲, 包含名稱服務應答的UDP數據包, tcpdump知道這類數據包該怎樣解析其數據)的'question'段一個條
目(entry)都不包含(nt: 每個條目的含義, 需補充),'[nq]' 會被打印出來.
要注意的是:名稱服務器的請求和應答數據量比較大, 而默認的68字節的抓取長度(nt: snaplen, 可理解爲tcpdump的一個設置選項)可能不足以抓取
數據包的全部內容. 如果你真的需要仔細查看名稱服務器的負載, 可以通過tcpdump 的-s 選項來擴大snaplen值.
轉自 http://www.cnblogs.com/ggjucheng/archive/2012/01/14/2322659.html