您當前位置：首頁 > php開源 > 綜合技術 > Linux tcpdump命令詳解

Linux tcpdump命令詳解

來源：程序員人生發布時間：2015-07-28 08:08:06 閱讀次數：3783次

轉自：http://blog.csdn.net/gkingzheng/article/details/8892108

簡介

用簡單的話來定義tcpdump，就是：dump the traffic on a network，根據使用者的定義對網絡上的數據包進行截獲的包分析工具。 tcpdump可以將網絡中傳送的數據包的“頭”完全截獲下來提供分析。它支持針對網絡層、協議、主機、網絡或端口的過濾，并提供and、or、not等邏輯語句來幫助你去掉無用的信息。

實用命令實例

默許啟動

tcpdump

普通情況下，直接啟動tcpdump將監視第1個網絡接口上所有流過的數據包。

eg: tcpdump -i any -Xs0 -n udp and host 10.128.65.143

監視指定網絡接口的數據包

tcpdump -i eth1

如果不指定網卡，默許tcpdump只會監視第1個網絡接口，1般是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 

監視指定網絡的數據包

打印本地主機與Berkeley網絡上的主機之間的所有通訊數據包(nt: ucb-ether, 此處可理解為'Berkeley網絡'的網絡地址,此表達式最原始的含義可表達為: 打印網絡地址為ucb-ether的所有數據包)

tcpdump net ucb-ether

打印所有通過網關snup的ftp數據包(注意, 表達式被單引號括起來了, 這可以避免shell對其中的括號進行毛病解析)

tcpdump 'gateway snup and (port ftp or ftp-data)'

打印所有源地址或目標地址是本地主機的IP數據包

(如果本地網絡通過網關連到了另外一網絡, 則另外一網絡其實不能算作本地網絡.(nt: 此句翻譯曲折,需補充).localnet 實際使用時要真正替換本錢地網絡的名字)

tcpdump ip and not net localnet

監視指定協議的數據包

打印TCP會話中的的開始和結束數據包, 并且數據包的源或目的不是本地網絡上的主機.(nt: localnet, 實際使用時要真正替換本錢地網絡的名字))

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

打印所有源或目的端口是80, 網絡層協議為IPv4, 并且含有數據,而不是SYN,FIN和ACK-only等不含數據的數據包.(ipv6的版本的表達式可做練習)

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

(nt: 可理解為, ip[2:2]表示全部ip數據包的長度, (ip[0]&0xf)<<2)表示ip數據包包頭的長度(ip[0]&0xf代表包中的IHL域, 而此域的單位為32bit, 要換算

成字節數需要乘以4,　即左移2.　(tcp[12]&0xf0)>>4 表示tcp頭的長度, 此域的單位也是32bit,　換算成比特數為 ((tcp[12]&0xf0) >> 4)　<<　２,　
即 ((tcp[12]&0xf0)>>2).　((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0　表示: 全部ip數據包的長度減去ip頭的長度,再減去
tcp頭的長度不為0, 這就意味著, ip數據包中確切是有數據.對ipv6版本只需斟酌ipv6頭中的'Payload Length' 與 'tcp頭的長度'的差值, 并且其中表達方式'ip[]'需換成'ip6[]'.)

打印長度超過576字節, 并且網關地址是snup的IP數據包

tcpdump 'gateway snup and ip[2:2] > 576'

打印所有IP層廣播或多播的數據包，但不是物理以太網層的廣播或多播數據報

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

打印除'echo request'或'echo reply'類型之外的ICMP數據包( 比如,需要打印所有非ping 程序產生的數據包時可用到此表達式 .
(nt: 'echo reuqest' 與 'echo reply' 這兩種類型的ICMP數據包通常由ping程序產生))

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

tcpdump 與wireshark

Wireshark(之前是ethereal)是Windows下非常簡單易用的抓包工具。但在Linux下很難找到1個好用的圖形化抓包工具。
還好有Tcpdump。我們可以用Tcpdump + Wireshark 的完善組合實現：在 Linux 里抓包，然后在Windows 里分析包。

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第1個參數的位置，用來過濾數據報的類型
(2)-i eth1 : 只抓經過接口eth1的包
(3)-t : 不顯示時間戳
(4)-s 0 : 抓取數據包時默許抓取長度為68字節。加上-S 0 后可以抓到完全的數據包
(5)-c 100 : 只抓取100個數據包
(6)dst port ! 22 : 不抓取目標端口是22的數據包
(7)src net 192.168.1.0/24 : 數據包的源網絡地址為192.168.1.0/24
(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

使用tcpdump抓取HTTP包

tcpdump  -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745 為"GET"前兩個字母"GE",0x4854 為"HTTP"前兩個字母"HT"。

tcpdump 對截獲的數據并沒有進行完全解碼，數據包內的大部份內容是使用106進制的情勢直接打印輸出的。明顯這不利于分析網絡故障，通常的解決辦法是先使用帶-w參數的tcpdump 截獲數據并保存到文件中，然后再使用其他程序(如Wireshark)進行解碼分析。固然也應當定義過濾規則，以免捕獲的數據包填滿全部硬盤。

輸出信息含義

首先我們注意1下，基本上tcpdump總的的輸出格式為：系統時間來源主機.端口 > 目標主機.端口數據包參數

tcpdump 的輸出格式與協議有關.以下扼要描寫了大部份經常使用的格式及相干例子.

鏈路層頭

對FDDI網絡, '-e' 使tcpdump打印出指定數據包的'frame control' 域, 源和目的地址, 和包的長度.(frame control域
控制對包中其他域的解析). 1般的包(比如那些IP datagrams)都是帶有'async'(異步標志)的數據包，并且有取值0到7的優先級;
比如 'async4'就代表此包為異步數據包，并且優先級別為4. 通常認為,這些包們會內含1個 LLC包(邏輯鏈路控制包); 這時候,如果此包
不是1個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⑴144中找到相干的蛛絲馬跡.)

對SLIP網絡(nt:SLIP links, 可理解為1個網絡, 即通過串行線路建立的連接, 而1個簡單的連接也可看成1個網絡),
數據包的'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'表示被賦予新的值, +/-表示增加或減少.

比如, 以下顯示了對1個外發緊縮TCP數據包的打印, 這個數據包隱含1個連接標識(connection identifier); 應對號增加了6,
順序號增加了49, 包ID號增加了6; 包數據長度為3字節(octect), 緊縮頭部為6字節.(nt:如此看來這應當不是1個特殊的緊縮數據包).

ARP/RARP 數據包

tcpdump對Arp/rarp包的輸出信息中會包括要求類型及該要求對應的參數. 顯示格式簡潔明了. 以下是從主機rtsg到主機csam的'rlogin'
(遠程登錄)進程開始階段的數據包樣例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第1行表示:rtsg發送了1個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, 則可以清晰的看到第1個數據包是全網廣播的, 而第2個數據包是點對點的:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
第1個數據包表明:以arp包的源以太地址是RTSG, 目標地址是全以太網段, type域的值為16進制0806(表示ETHER_ARP(nt:arp包的類型標識)),
包的總長度為64字節.

TCP 數據包

(注意:以下將會假定你對 RFC⑺93所描寫的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)描寫了此包中數據所對應序列號空間中的1個位置(nt:全部數據被分段,
每段有1個順序號, 所有的順序號構成1個序列號空間)(可參考以下例子). Ack 描寫的是同1個連接,同1個方向,下1個本端應當接收的
(對方應當發送的)數據片斷的順序號. Window是本端可用的數據接收緩沖區的大小(也是對方發送數據時需根據這個大小來組織數據).
Urg(urgent) 表示數據包中有緊急的數據. options 描寫了tcp的1些選項, 這些選項都用尖括號來表示(如 <mss 1024>).

src, dst 和 flags 這3個域總是會被顯示. 其他域的顯示與否依賴于tcp協議頭里的信息.

這是1個從trsg到csam的1個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
第1行表示有1個數據包從rtsg主機的tcp端口1023發送到了csam主機的tcp端口login上(nt:udp協議的端口和tcp協議的端
口是分別的兩個空間, 雖然取值范圍1致). S表示設置了SYN標志. 包的順序號是768512, 并且沒有包括數據.(表示格式
為:'first:last(nbytes)', 其含義是'此包中數據的順序號從first開始直到last結束，不包括last. 并且總共包括nbytes的
用戶數據'.) 沒有捎帶應對(nt:從下文來看，第2行才是有捎帶應對的數據包), 可用的接受窗口的大小為4096bytes, 并且要求端(rtsg)
的最大可接受的數據段大小是1024字節(nt:這個信息作為要求發向應對端csam, 以便雙方進1步的協商).

Csam 向rtsg 回復了基本相同的SYN數據包, 其區分只是多了1個' piggy-backed ack'(nt:捎帶回的ack應對, 針對rtsg的SYN數據包).

rtsg 一樣針對csam的SYN數據包回復了1ACK數據包作為應對. '.'的含義就是此包中沒有標志被設置. 由于此應對包中不含有數據, 所以
包中也沒有數據段序列號. 提示! 此ACK數據包的順序號只是1個小整數1. 有以下解釋:tcpdump對1個tcp連接上的會話, 只打印會話兩真個
初始數據包的序列號,其后相應數據包只打印出與初始包序列號的差異.即初始序列號以后的序列號,　可被看做此會話上當前所傳數據片斷在全部
要傳輸的數據中的'相對字節'位置(nt:雙方的第1個位置都是1, 即'相對字節'的開始編號).　'-Ｓ'將覆蓋這個功能,　
使數據包的原始順序號被打印出來.

第6行的含義為:rtsg 向 csam發送了19字節的數據(字節的編號為2到20，傳送方向為rtsg到csam). 包中設置了PUSH標志. 在第7行,
csam 喊到，她已從rtsg中收到了21以下的字節, 但不包括21編號的字節. 這些字節寄存在csam的socket的接收緩沖中, 相應地,
csam的接收緩沖窗口大小會減少19字節(nt:可以從第5行和第7行win屬性值的變化看出來). csam在第7行這個包中也向rtsg發送了1個
字節. 在第8行和第9行, csam 繼續向rtsg 分別發送了兩個只包括1個字節的數據包, 并且這個數據包帶PUSH標志.

如果所抓到的tcp包(nt:即這里的snapshot)太小了，以致tcpdump沒法完全得到其頭部數據, 這時候, tcpdump會盡可能解析這個不完全的頭,
并把剩下不能解析的部份顯示為'[|tcp]'. 如果頭部含有虛假的屬性信息(比如其長度屬性其實比頭部實際長度長或短), tcpdump會為該頭部
顯示'[bad opt]'. 如果頭部的長度告知我們某些選項(nt | rt:從下文來看，指tcp包的頭部中針對ip包的1些選項, 回頭再翻)會在此包中,
而真實的IP(數據包的長度又不夠容納這些選項, tcpdump會顯示'[bad hdr length]'.

抓取帶有特殊標志的的TCP包(如SYN-ACK標志, URG-ACK標志等).

在TCP的頭部中, 有8比特(bit)用作控制位區域, 其取值為:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:從表達方式上可推斷:這8個位是用或的方式來組合的, 可回頭再翻)

現假定我們想要監控建立1個TCP連接全部進程中所產生的數據包. 可回想以下:TCP使用3次握手協議來建立1個新的連接; 其與此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 |
-----------------------------------------------------------------

1個TCP頭部,在不包括選項數據的情況下通常占用20個字節(nt | rt:options 理解為選項數據，需回譯). 第1行包括0到3編號的字節,
第2行包括編號4⑺的字節.

如果編號從0開始算, TCP控制標志位于13字節(nt:第4行左半部份).

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號.

提示1下自己, 我們只是要得到包括SYN標志的數據包. 讓我們看看在1個包的包頭中, 如果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的字節是1個8位的無符號字符型,并且依照網絡字節號排序(nt:對1個字節來講，網絡字節序同等于主機字節序), 其2進制值
以下所示:
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就是我們想要的). 讓我們來看看當1個含有
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號位被置位, 其2進制的值為:
00010010

轉換成10進制就是:

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標志的數據包, 其他的都被拋棄.
提示1下自己, 我們的目標是: 只要包的SYN標志被設置就行, 其他的標志我們不理睬.

為了到達我們的目標, 我們需要把13號字節的2進制值與其他的1個數做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發送了1個udp數據包(nt: actinide和broadcast都是指Internet地址).
這個數據包承載的用戶數據為84個字節.

1些UDP服務可從數據包的源或目的端口來辨認，也可從所顯示的更高層協議信息來辨認. 比如, Domain Name service requests(DNS 要求,
在RFC⑴034/1035中), 和Sun RPC calls to NFS(對NFS服務器所發起的遠程調用(nt: 即Sun RPC)，在RFC⑴050中有對遠程調用的描寫).

UDP 名稱服務要求

(注意:以下的描寫假定你對Domain Service protoco(nt:在RFC⑴03中有所描寫), 否則你會發現以下描寫就是天書(nt:希臘文天書,
沒必要理睬, 嚇嚇你的, 接著看就行))

名稱服務要求有以下的格式:
src > dst: id op? flags qtype qclass name (len)
(nt: 從下文來看, 格式應當是src > dst: id op flags qtype qclass? name (len))
比如有1個實際顯示為:
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'以后.

異常檢查會在方括中顯示出附加的域:　如果1個查詢同時包括1個回應(nt: 可理解為, 對之前其他1個要求的回應), 并且此回應包括權威或附加記錄段,　
ancount, nscout, arcount(nt: 具體字段含義需補充) 將被顯示為'[na]', '[nn]', '[nau]', 其中n代表適合的計數. 如果包中以下
回應位(比如AA位, RA位, rcode位), 或字節2或3中任何1個'必須為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)

第1行表示: helios 對h2opolo 所發送的3號查詢要求回應了3條回答記錄(nt | rt: answer records), 3條名稱服務器記錄,
和7條附加的記錄. 第1個回答記錄(nt: 3個回答記錄中的第1個)類型為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類型記錄默許取值)

第2行表示: helios 對h2opolo 所發送的2號查詢要求做了回應. 回應中, rcode編碼為NXDomain(nt: 表示不存在的域)), 沒有回答記錄,
但包括1個名稱服務器記錄, 不包括權威服務器記錄(nt | ck: 從上文來看, 此處的authority records 就是上文中對應的additional
records). '*'表示權威服務器回答標志被設置(nt: 從而additional records就表示的是authority records).
由于沒有回答記錄, type, class, data字段都被疏忽.

flag字段還有可能出現其他1些字符, 比如'-'(nt: 表示可遞歸地查詢, 即RA 標志沒有被設置), '|'(nt: 表示被截斷的消息, 即TC 標志
被置位). 如果應對(nt | ct: 可理解為, 包括名稱服務應對的UDP數據包, tcpdump知道這類數據包該怎樣解析其數據)的'question'段1個條
目(entry)都不包括(nt: 每一個條目的含義, 需補充),'[nq]' 會被打印出來.

要注意的是:名稱服務器的要求和應對數據量比較大, 而默許的68字節的抓取長度(nt: snaplen, 可理解為tcpdump的1個設置選項)可能不足以抓取
數據包的全部內容. 如果你真的需要仔細查看名稱服務器的負載, 可以通過tcpdump 的-s 選項來擴大snaplen值.

SMB/CIFS 解碼

tcpdump 已可以對SMB/CIFS/NBT相干利用的數據包內容進行解碼(nt: 分別為'Server Message Block Common', 'Internet File System'
'在TCP/IP上實現的網絡協議NETBIOS的簡稱'. 這幾個服務通常使用UDP的137/138和TCP的139端口). 原來的對IPX和NetBEUI SMB數據包的
解碼能力仍然可以被使用(nt: NetBEUI為NETBIOS的增強版本).

tcpdump默許只依照最簡約模式對相應數據包進行解碼, 如果我們想要詳實的解碼信息可使用其-v 啟動選現. 要注意的是, -v 會產生非常詳細的信息,
比如對單1的1個SMB數據包, 將產生1屏幕或更多的信息, 所以此選項, 確有需要才使用.

關于SMB數據包格式的信息, 和每一個域的含義可以參看www.cifs.org 或samba.org 鏡像站點的pub/samba/specs/ 目錄. linux 上的SMB 補釘
(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.

NFS 要求和回應

tcpdump對Sun NFS(網絡文件系統)要求和回應的UDP數據包有以下格式的打印輸出:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results

以下是1組具體的輸出數據
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150

第1行輸出表明: 主機sushi向主機wrl發送了1個'交換要求'(nt: transaction), 此要求的id為6709(注意, 主機名字后是交換
要求id號, 而不是源端口號). 此要求數據為112字節, 其中不包括UDP和IP頭部的長度. 操作類型為readlink(nt: 即此操作為讀符號鏈接操作),
操作參數為fh 21,24/10.73165(nt: 可按實際運行環境, 解析以下, fd 表示描寫的為文件句柄, 21,24 表示此句柄所對應設
備的主/從裝備號對, 10表示此句柄所對應的i節點編號(nt:每一個文件都會在操作系統中對應1個i節點, 限于unix類系統中),
73165是1個編號(nt: 可理解為標識此要求的1個隨機數, 具體含義需補充)).

第2行中, wrl 做了'ok'的回應, 并且在results 字段中返回了sushi想要讀的符號連接的真實目錄(nt: 即sushi要求讀的符號連接實際上是1個目錄).

第3行表明: sushi 再次要求 wrl 在'fh 9,74/4096.6878'所描寫的目錄中查找'xcolors'文件. 需要注意的是, 每行所顯示的數據含義依賴于其中op字段的
類型(nt: 不同op 所對應args 含義不相同), 其格式遵守NFS 協議, 尋求簡潔明了.

如果tcpdump 的-v選項(詳細打印選項) 被設置, 附加的信息將被顯示. 比如:
sushi.1372a > wrl.nfs:
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388

(-v 選項1般還會打印出IP頭部的TTL, ID， length, 和fragmentation 域, 但在此例中, 都略過了(nt: 可理解為,簡潔起見, 做了刪減))
在第1行, sushi 要求wrl 從文件 21,11/12.195(nt: 格式在上面有描寫)中, 自偏移24576字節處開始, 讀取8192字節數據.
Wrl 回應讀取成功; 由于第2行只是回應要求的開頭片斷, 所以只包括1472字節(其他的數據將在接著的reply片斷中到來, 但這些數據包不會再有NFS
頭, 乃至UDP頭信息也為空(nt: 源和目的應當要有), 這將致使這些片斷不能滿足過濾條件, 從而沒有被打印). -v 選項除顯示文件數據信息, 還會顯示
附加顯示文件屬性信息: file type(文件類型, ''REG'' 表示普通文件), file mode(文件存取模式, 8進制表示的), uid 和gid(nt: 文件屬主和
組屬主), file size (文件大小).

如果-v 標志被屢次重復給出(nt: 如-vv)， tcpdump會顯示更加詳細的信息.

必須要注意的是, NFS 要求包中數據比較多, 如果tcpdump 的snaplen(nt: 抓取長度) 取太短將不能顯示其詳細信息. 可以使用
'-s 192'來增加snaplen, 這可用以監測NFS利用的網絡負載(nt: traffic).

NFS 的回應包其實不嚴格的緊隨之前相應的要求包(nt: RPC operation). 從而, tcpdump 會跟蹤最近收到的1系列要求包, 再通過其
交換序號(nt: transaction ID)與相應要求包相匹配. 這可能產生1個問題，如果回應包來得太遲, 超越tcpdump 對相應要求包的跟蹤范圍,
該回應包將不能被分析.

AFS 要求和回應

AFS(nt: Andrew 文件系統, Transarc , 未知, 需補充)要求和回應有以下的答應

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args

elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename

在第1行, 主機elvis 向pike 發送了1個RX數據包.
這是1個對文件服務的要求數據包(nt: RX data packet, 發送數據包 , 可理解為發送包過去, 從而要求對方的服務), 這也是1個RPC
調用的開始(nt: RPC, remote procedure call). 此RPC 要求pike 履行rename(nt: 重命名) 操作, 并指定了相干的參數:
原目錄描寫符為536876964/1/1, 原文件名為 '.newsrc.new', 新目錄描寫符為536876964/1/1, 新文件名為 '.newsrc'.
主機pike 對此rename操作的RPC要求作了回應(回應表示rename操作成功, 由于回應的是包括數據內容的包而不是異常包).

1般來講, 所有的'AFS RPC'要求被顯示時, 會被冠以1個名字(nt: 即decode, 解碼), 這個名字常常就是RPC要求的操作名.
并且, 這些RPC要求的部份參數在顯示時, 也會被冠以1個名字(nt | rt: 即decode, 解碼, 1般來講也是取名也很直接, 比如,
1個interesting 參數, 顯示的時候就會直接是'interesting', 含義拗口, 需再翻).

這類顯示格式的設計初衷為'1看就懂', 但對不熟習AFS 和 RX 工作原理的人可能不是很
有用(nt: 還是不用管, 書面嚇嚇你的, 往下看就行).

如果 -v(詳細)標志被重復給出(nt: 如-vv), tcpdump 會打印出確認包(nt: 可理解為, 與應對包有區分的包)和附加頭部信息
(nt: 可理解為, 所有包, 而不單單是確認包的附加頭部信息), 比如, RX call ID(要求包中'要求調用'的ID),
call number('要求調用'的編號), sequence number(nt: 包順序號),
serial number(nt | rt: 可理解為與包中數據相干的另外一個順信號, 具體含義需補充), 要求包的標識. (nt: 接下來1段為重復描寫,
所以略去了), 另外確認包中的MTU協商信息也會被打印出來(nt: 確認包為相對要求包的確認包, Maximum Transmission Unit, 最大傳輸單元).

如果 -v 選項被重復了3次(nt: 如-vvv), 那

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
程序員人生