tcpdump命令的使用方法

　　UDP 數(shù)據(jù)包

　　UDP 數(shù)據(jù)包的顯示格式，可通過rwho這個具體應(yīng)用所產(chǎn)生的數(shù)據(jù)包來說明:

　　actinide.who > broadcast.who: udp 84

　　其含義為:actinide主機上的端口who向broadcast主機上的端口who發(fā)送了一個udp數(shù)據(jù)包(nt: actinide和broadcast都是指Internet地址).

　　這個數(shù)據(jù)包承載的用戶數(shù)據(jù)為84個字節(jié).

　　一些UDP服務(wù)可從數(shù)據(jù)包的源或目的端口來識別，也可從所顯示的更高層協(xié)議信息來識別. 比如, Domain Name service requests(DNS 請求,

　　在RFC-1034/1035中), 和Sun RPC calls to NFS(對NFS服務(wù)器所發(fā)起的遠程調(diào)用(nt: 即Sun RPC)，在RFC-1050中有對遠程調(diào)用的描述).

　　UDP 名稱服務(wù)請求

　　(注意:以下的描述假設(shè)你對Domain Service protoco(nt:在RFC-103中有所描述), 否則你會發(fā)現(xiàn)以下描述就是天書(nt:希臘文天書,

　　不必理會, 嚇嚇你的, 接著看就行))

　　名稱服務(wù)請求有如下的格式:

　　src > dst: id op? flags qtype qclass name (len)

　　(nt: 從下文來看, 格式應(yīng)該是src > dst: id op flags qtype qclass? name (len))

　　比如有一個實際顯示為:

　　h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

　　主機h2opolo 向helios 上運行的名稱服務(wù)器查詢ucbvax.berkeley.edu 的地址記錄(nt: qtype等于A). 此查詢本身的id號為'3'. 符號

　　'+'意味著遞歸查詢標(biāo)志被設(shè)置(nt: dns服務(wù)器可向更高層dns服務(wù)器查詢本服務(wù)器不包含的地址記錄). 這個最終通過IP包發(fā)送的查詢請求

　　數(shù)據(jù)長度為37字節(jié), 其中不包括UDP和IP協(xié)議的頭數(shù)據(jù). 因為此查詢操作為默認(rèn)值(nt | rt: normal one的理解), op字段被省略.

　　如果op字段沒被省略, 會被顯示在'3' 和'+'之間. 同樣, qclass也是默認(rèn)值, C_IN, 從而也沒被顯示, 如果沒被忽略, 她會被顯示在'A'之后.

　　異常檢查會在方括中顯示出附加的域:　如果一個查詢同時包含一個回應(yīng)(nt: 可理解為, 對之前其他一個請求的回應(yīng)), 并且此回應(yīng)包含權(quán)威或附加記錄段,

　　ancount, nscout, arcount(nt: 具體字段含義需補充) 將被顯示為'[na]', '[nn]', '[nau]', 其中n代表合適的計數(shù). 如果包中以下

　　回應(yīng)位(比如AA位, RA位, rcode位), 或者字節(jié)2或3中任何一個'必須為0'的位被置位(nt: 設(shè)置為1), '[b2&3]=x' 將被顯示, 其中x表示

　　頭部字節(jié)2與字節(jié)3進行與操作后的值.

　　UDP 名稱服務(wù)應(yīng)答

　　對名稱服務(wù)應(yīng)答的數(shù)據(jù)包，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 所發(fā)送的3號查詢請求回應(yīng)了3條回答記錄(nt | rt: answer records), 3條名稱服務(wù)器記錄,

　　以及7條附加的記錄. 第一個回答記錄(nt: 3個回答記錄中的第一個)類型為A(nt: 表示地址), 其數(shù)據(jù)為internet地址128.32.137.3.

　　此回應(yīng)UDP數(shù)據(jù)包, 包含273字節(jié)的數(shù)據(jù)(不包含UPD和IP的頭部數(shù)據(jù)). op字段和rcode字段被忽略(nt: op的實際值為Query, rcode, 即

　　response code的實際值為NoError), 同樣被忽略的字段還有class 字段(nt | rt: 其值為C_IN, 這也是A類型記錄默認(rèn)取值)

　　第二行表示: helios 對h2opolo 所發(fā)送的2號查詢請求做了回應(yīng). 回應(yīng)中, rcode編碼為NXDomain(nt: 表示不存在的域)), 沒有回答記錄,

　　但包含一個名稱服務(wù)器記錄, 不包含權(quán)威服務(wù)器記錄(nt | ck: 從上文來看, 此處的authority records 就是上文中對應(yīng)的additional

　　records). '_表示權(quán)威服務(wù)器回答標(biāo)志被設(shè)置(nt: 從而additional records就表示的是authority records).

　　由于沒有回答記錄, type, class, data字段都被忽略.

　　flag字段還有可能出現(xiàn)其他一些字符, 比如'-'(nt: 表示可遞歸地查詢, 即RA 標(biāo)志沒有被設(shè)置), '|'(nt: 表示被截斷的消息, 即TC 標(biāo)志

　　被置位). 如果應(yīng)答(nt | ct: 可理解為, 包含名稱服務(wù)應(yīng)答的UDP數(shù)據(jù)包, tcpdump知道這類數(shù)據(jù)包該怎樣解析其數(shù)據(jù))的'question'段一個條

　　目(entry)都不包含(nt: 每個條目的含義, 需補充),'[nq]' 會被打印出來.

　　要注意的是:名稱服務(wù)器的請求和應(yīng)答數(shù)據(jù)量比較大, 而默認(rèn)的68字節(jié)的抓取長度(nt: snaplen, 可理解為tcpdump的一個設(shè)置選項)可能不足以抓取

　　數(shù)據(jù)包的全部內(nèi)容. 如果你真的需要仔細查看名稱服務(wù)器的負(fù)載, 可以通過tcpdump 的-s 選項來擴大snaplen值.

　　SMB/CIFS 解碼

　　tcpdump 已可以對SMB/CIFS/NBT相關(guān)應(yīng)用的數(shù)據(jù)包內(nèi)容進行解碼(nt: 分別為'Server Message Block Common', 'Internet File System'

　　'在TCP/IP上實現(xiàn)的網(wǎng)絡(luò)協(xié)議NETBIOS的簡稱'. 這幾個服務(wù)通常使用UDP的137/138以及TCP的139端口). 原來的對IPX和NetBEUI SMB數(shù)據(jù)包的

　　解碼能力依然可以被使用(nt: NetBEUI為NETBIOS的增強版本).

　　tcpdump默認(rèn)只按照最簡約模式對相應(yīng)數(shù)據(jù)包進行解碼, 如果我們想要詳盡的解碼信息可以使用其-v 啟動選現(xiàn). 要注意的是, -v 會產(chǎn)生非常詳細的信息,

　　比如對單一的一個SMB數(shù)據(jù)包, 將產(chǎn)生一屏幕或更多的信息, 所以此選項, 確有需要才使用.

　　關(guān)于SMB數(shù)據(jù)包格式的信息, 以及每個域的含義可以參看www.cifs.org 或者samba.org 鏡像站點的pub/samba/specs/ 目錄. linux 上的SMB 補丁

　　(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.

　　NFS 請求和回應(yīng)

　　tcpdump對Sun NFS(網(wǎng)絡(luò)文件系統(tǒng))請求和回應(yīng)的UDP數(shù)據(jù)包有如下格式的打印輸出:

　　src.xid > dst.nfs: len op args

　　src.nfs > dst.xid: reply stat len op results

　　以下是一組具體的輸出數(shù)據(jù)

　　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

　　第一行輸出表明: 主機sushi向主機wrl發(fā)送了一個'交換請求'(nt: transaction), 此請求的id為6709(注意, 主機名字后是交換

　　請求id號, 而不是源端口號). 此請求數(shù)據(jù)為112字節(jié), 其中不包括UDP和IP頭部的長度. 操作類型為readlink(nt: 即此操作為讀符號鏈接操作),

　　操作參數(shù)為fh 21,24/10.73165(nt: 可按實際運行環(huán)境, 解析如下, fd 表示描述的為文件句柄, 21,24 表示此句柄所對應(yīng)設(shè)

　　備的主/從設(shè)備號對, 10表示此句柄所對應(yīng)的i節(jié)點編號(nt:每個文件都會在操作系統(tǒng)中對應(yīng)一個i節(jié)點, 限于unix類系統(tǒng)中),

　　73165是一個編號(nt: 可理解為標(biāo)識此請求的一個隨機數(shù), 具體含義需補充)).

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

　　第三行表明: sushi 再次請求 wrl 在'fh 9,74/4096.6878'所描述的目錄中查找'xcolors'文件. 需要注意的是, 每行所顯示的數(shù)據(jù)含義依賴于其中op字段的

　　類型(nt: 不同op 所對應(yīng)args 含義不相同), 其格式遵循NFS 協(xié)議, 追求簡潔明了.

　　如果tcpdump 的-v選項(詳細打印選項) 被設(shè)置, 附加的信息將被顯示. 比如:

　　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 選項一般還會打印出IP頭部的TTL, ID， length, 以及fragmentation 域, 但在此例中, 都略過了(nt: 可理解為,簡潔起見, 做了刪減))

　　在第一行, sushi 請求wrl 從文件 21,11/12.195(nt: 格式在上面有描述)中, 自偏移24576字節(jié)處開始, 讀取8192字節(jié)數(shù)據(jù).

　　Wrl 回應(yīng)讀取成功; 由于第二行只是回應(yīng)請求的開頭片段, 所以只包含1472字節(jié)(其他的數(shù)據(jù)將在接著的reply片段中到來, 但這些數(shù)據(jù)包不會再有NFS

　　頭, 甚至UDP頭信息也為空(nt: 源和目的應(yīng)該要有), 這將導(dǎo)致這些片段不能滿足過濾條件, 從而沒有被打印). -v 選項除了顯示文件數(shù)據(jù)信息, 還會顯示

　　附加顯示文件屬性信息: file type(文件類型, ''REG'' 表示普通文件), file mode(文件存取模式, 8進制表示的), uid 和gid(nt: 文件屬主和

　　組屬主), file size (文件大小).

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

　　必須要注意的是, NFS 請求包中數(shù)據(jù)比較多, 如果tcpdump 的snaplen(nt: 抓取長度) 取太短將不能顯示其詳細信息. 可使用

　　'-s 192'來增加snaplen, 這可用以監(jiān)測NFS應(yīng)用的網(wǎng)絡(luò)負(fù)載(nt: traffic).

　　NFS 的回應(yīng)包并不嚴(yán)格的緊隨之前相應(yīng)的請求包(nt: RPC operation). 從而, tcpdump 會跟蹤最近收到的一系列請求包, 再通過其

　　交換序號(nt: transaction ID)與相應(yīng)請求包相匹配. 這可能產(chǎn)生一個問題， 如果回應(yīng)包來得太遲, 超出tcpdump 對相應(yīng)請求包的跟蹤范圍,

　　該回應(yīng)包將不能被分析.