tcpdump採用命令行方式，它的命令格式爲：
tcpdump [ -adeflnNOpqStvx ] [ -c 次數 ] [ -F 文件名 ]
[ -i 網絡接口 ] [ -r 文件名] [ -s snaplen ]
[ -T 類型 ] [ -w 存儲文件名 ] [表達式 ]
(1). tcpdump的選項介紹
-a 將網絡地址和廣播地址轉變成名字；
-nn 直接以IP及port Number顯示，而非主機名與服務名稱
-d 將匹配信息包的代碼以人們能夠理解的彙編格式給出；
-dd 將匹配信息包的代碼以c語言程序段的格式給出；
-ddd 將匹配信息包的代碼以十進制的形式給出；
-e 在輸出行打印出數據鏈路層（OSI二層）的頭部信息；
-f 將外部的Internet地址以數字的形式打印出來；
-l 使標準輸出變爲緩衝行形式；
-n 不把網絡地址轉換成名字；
-t 在輸出的每一行不打印時間戳；
-v 輸出一個稍微詳細的信息，例如在ip包中可以包括ttl和服務類型的信息；
-vv 輸出詳細的報文信息；
-c 在收到指定的包的數目後，tcpdump就會停止；
-F 從指定的文件中讀取表達式,忽略其它的表達式；
-i 指定監聽的網絡接口；
-r 從指定的文件中讀取包(這些包一般通過-w選項產生)；
-w 直接將包寫入文件中，並不分析和打印出來；
-T 將監聽到的包直接解釋爲指定的類型的報文，常見的類型有rpc （遠程過程 調用）和snmp（簡單 網絡管理協議；）
-X 可以列出十六進制以及ASCII的數據包的內容，對於監聽數據包內容很有用
(2). tcpdump的表達式介紹
表達式是一個正則表達式，tcpdump利用它作爲過濾報文的條件，如果一個報文滿足表達式的條件，則這個報文將會被捕獲。如果沒有給出任何條件，則網絡上所有的信息包將會被截獲。在表達式中一般如下幾種類型的關鍵字。
第一種是關於類型的關鍵字，主要包括host，net，port, 例如 host 210.27.48.2，指明 210.27.48.2是一臺主機，net 202.0.0.0 指明 202.0.0.0是一個網絡地址，port 23 指明端口號是23。如果沒有指定類型，缺省的類型是host.
第二種是確定傳輸方向的關鍵字，主要包括src , dst ,dst or src, dst and src ,這些關鍵字指明瞭傳輸的方向。舉例說明，src 210.27.48.2 ,指明ip包中源地址是210.27.48.2 , dst net 202.0.0.0 指明目的網絡地址是202.0.0.0 。如果沒有指明方向關鍵字，則缺省是src or dst關鍵字。
第三種是協議的關鍵字，主要包括fddi,ip,arp,rarp,tcp,udp等類型。Fddi指明是在FDDI(分佈式光纖數據接口網絡)上的特定的網絡協議，實際上它是"ether"的別名，fddi和ether具有類似的源地址和目的地址，所以可以將fddi協議包當作ether的包進行處理和分析。其他的幾個關鍵字就是指明瞭監聽的包的協議內容。如果沒有指定任何協議，則tcpdump將會監聽所有協議的信息包。
除了這三種類型的關鍵字之外，其他重要的關鍵字如下：gateway, broadcast,less,greater,還有三種邏輯運算，取非運算是 'not ' '! ', 與運算是'and','&&';或運算 是'or' ,'││'；這些關鍵字可以組合起來構成強大的組合條件來滿足人們的需要，下面舉幾個例子來說明。
A想要截獲所有210.27.48.1 的主機收到的和發出的所有的數據包：
#tcpdump host 210.27.48.1
B想要截獲主機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 )
C如果想要獲取主機210.27.48.1除了和主機210.27.48.2之外所有主機通信的ip包，使用命令：
#tcpdump ip host 210.27.48.1 and ! 210.27.48.2
D如果想要獲取主機210.27.48.1接收或發出的telnet包，使用如下命令：
#tcpdump tcp port 23 host 210.27.48.1
(3). tcpdump的輸出結果介紹
下面我們介紹幾種典型的tcpdump命令的輸出信息
A,數據鏈路層頭信息
使用命令
#tcpdump --e host ice
ice 是一臺裝有linux的主機，她的MAC地址是0：90：27：58：AF：1A
H219是一臺裝有SOLARIC的SUN工作站，它的MAC地址是8：0：20：79：5B：46；上一條命令的輸出結果如下所示：
21:50:12.847509 eth0 ＜ 8:0:20:79:5b:46 0:90:27:58:af:1a ip 60: h219.33357 ＞ ice.telne
t 0:0(0) ack 22535 win 8760 (DF)
分析：21：50：12是顯示的時間， 847509是ID號，eth0 ＜表示從網絡接口eth0 接受該數據包，eth0 ＞表示從網絡接口設備發送數據包, 8:0:20:79:5b:46是主機H219的MAC地址,它表明是從源地址H219發來的數據包. 0:90:27:58:af:1a是主機ICE的MAC地址,表示該數據包的目的地址是ICE . ip 是表明該數據包是IP數據包,60 是數據包的長度, h219.33357 ＞ ice.telnet 表明該數據包是從主機H219的33357端口發往主機ICE的TELNET(23)端口. ack 22535 表明對序列號是222535的包進行響應. win 8760表明發送窗口的大小是8760.
B,ARP包的TCPDUMP輸出信息
使用命令
#tcpdump arp
得到的輸出結果是：
22:32:42.802509 eth0 ＞ arp who-has route tell ice (0:90:27:58:af:1a)
22:32:42.802902 eth0 ＜ arp reply route is-at 0:90:27:12:10:66 (0:90:27:58:af:1a)
分析: 22:32:42是時間戳, 802509是ID號, eth0 ＞表明從主機發出該數據包, arp表明是ARP請求包, who-has route tell ice表明是主機ICE請求主機ROUTE的MAC地址。 0:90:27:58:af:1a是主機ICE的MAC地址。
C,TCP包的輸出信息
用TCPDUMP捕獲的TCP包的一般輸出信息是：
src ＞ dst: flags data-seqno ack window urgent options
src ＞ dst:表明從源地址到目的地址, flags是TCP包中的標誌信息,S 是SYN標誌, F (FIN), P (PUSH) , R (RST) "." (沒有標記); data-seqno是數據包中的數據的順序號, ack是下次期望的順序號, window是接收緩存的窗口大小, urgent表明數據包中是否有緊急指針. Options是選項.
D,UDP包的輸出信息
用TCPDUMP捕獲的UDP包的一般輸出信息是：
route.port1 ＞ ice.port2: udp lenth
UDP十分簡單，上面的輸出行表明從主機ROUTE的port1端口發出的一個UDP數據包到主機ICE的port2端口，類型是UDP， 包的長度是lenth
三、利用網絡數據採集分析工具TcpDump分析網絡安全
作爲IP網絡的系統管理員，經常會遇到一些網絡連接方面的故障，在排查這些接故障時，除了憑藉經驗外，使用包分析軟件往往會起到事半功倍的效果。
常用的包分析軟件非常多，常見的如tcpdump，sniffer，windump，ettercap等。
1、網絡數據採集分析工具TcpDump分析
(1)網絡的數據過濾
不帶任何參數的TcpDump將搜索系統中所有的網絡接口，並顯示它截獲的所有數據，這些數據對我們不一定全都需要，而且數據太多不利於分析。所以，我們應當先想好需要哪些數據，TcpDump提供以下參數供我們選擇數據：
-b在數據-鏈路層上選擇協議，包括ip、arp、rarp、ipx都是這一層的。例如：
server#tcpdump -b arp
將只顯示網絡中的arp即地址轉換協議信息。
-i選擇過濾的網絡接口，如果是作爲路由器至少有兩個網絡接口，通過這個選項，就可以只過濾指定的接口上通過的數據。例如：
server#tcpdump -i eth0
只顯示通過eth0接口上的所有報頭。src、dst、port、host、net、ether、gateway這幾個選項又分別包含src、dst、port、host、net、ehost等附加選項。他們用來分辨數據包的來源和去向，src host 192.168.0.1指定源主機IP地址是192.168.0.1，dst net 192.168.0.0/24指定目標是網絡192.168.0.0。以此類推，host是與其指定主機相關無論它是源還是目的，net是與其指定網絡相關的，ether後面跟的不是IP地址而是物理地址，而gateway則用於網關主機。可能有點複雜，看下面例子就知道了：
server#tcpdump src host 192.168.0.1 and dst net 192.168.0.0/24
過濾的是源主機爲192.168.0.1與目的網絡爲192.168.0.0的報頭。
server#tcpdump ether src 00:50:04:BA:9B and dst......
過濾源主機物理地址爲XXX的報頭(爲什麼ether src後面沒有host或者net？物理地址當然不可能有網絡嘍)。
server#Tcpdump src host 192.168.0.1 and dst port not telnet
過濾源主機192.168.0.1和目的端口不是telnet的報頭。
ip icmp arp rarp和tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型。例如：
server#tcpdump ip src......
只過濾數據-鏈路層上的IP報頭。
server#tcpdump udp and src host 192.168.0.1
只過濾源主機192.168.0.1的所有udp報頭。
抓報文：tcpdump -i bond1 -s 0 -w /aaa.cap
tcpdump -i bond1 -s 0 port 1812 or port 1813 -w /aaa.cap host xx
Solaris系統用：snoop -d hme0 -t a -x 54 port 19999 //這是Solaris的內部命令，只能用於Solaris
(2)網絡的數據顯示/輸入輸出
TcpDump提供了足夠的參數來讓我們選擇如何處理得到的數據，如下所示：-l可以將數據重定向。
如tcpdump -l＞tcpcap.txt將得到的數據存入tcpcap.txt文件中。
-n不進行IP地址到主機名的轉換。
如果不使用這一項，當系統中存在某一主機的主機名時，TcpDump會把IP地址轉換爲主機名顯示，就像這樣：eth0＜ntc9.1165＞router.domain.net.telnet，使用-n後變成了：eth0＜192.168.0.9.1165＞192.168.0.1.telnet。
-nn不進行端口名稱的轉換。
上面這條信息使用-nn後就變成了：eth0＜ntc9.1165＞router.domain.net.23。
-N不打印出默認的域名。
還是這條信息-N後就是：eth0＜ntc9.1165＞router.telnet。
-O不進行匹配代碼的優化。
-t不打印UNIX時間戳，也就是不顯示時間。
-tt打印原始的、未格式化過的時間。
-v詳細的輸出，也就比普通的多了個TTL和服務類型。
2、網絡數據採集分析工具TcpDump分析詳細例子
(1)網絡郵件服務器(mail)在排障
我們先來看看故障現象，在一局域網中新安裝了後臺爲qmail的郵件服務器server，郵件服務器收發郵件等基本功能正常，但在使用中發現一個普遍的怪現象：pc機器上發郵件時連接郵件服務器後要等待很久的時間才能開始實際的發送工作。我們來看，從檢測來看，網絡連接沒有問題，郵件服務器server和下面的pc性能都沒有問題，問題可能出在哪裏呢？爲了進行準確的定位，我們在pc機client上發送郵件，同時在郵件服務器server上使用tcpdump對這個client的數據包進行捕獲分析，如下：
server#tcpdump host client
tcpdump: listening on hme0
23:41:30.040578 client.1065 ＞ server.smtp: S 1087965815:1087965815(0) win 64240 (DF)
23:41:30.040613 server.smtp ＞ client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 (DF)
23:41:30.040960 client.1065 ＞ server.smtp: . ack 1 win 64240 (DF)
順利的完成，到目前爲止正常，我們再往下看：
23:41:30.048862 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:33.411006 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:40.161052 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:56.061130 server.33152 ＞ client.113: R 99370917:99370917(0) win 8760 (DF)
23:41:56.070108 server.smtp ＞ client.1065: P 1:109(108) ack 1 win 10136 (DF)
看出問題了，問題在：我們看到server端試圖連接client的113identd端口，要求認證，然而沒有收到client端的迴應，server端重複嘗試了3次，費時26秒後，才放棄認證請求，主動發送了reset標誌的數據包，開始push後面的數據，而正是在這個過程中所花費的26秒時間，造成了發送郵件時漫長的等待情況。問題找到了，就可以修改了，我們通過修改服務器端的qmail配置，使它不再進行113端口的認證，再次抓包，看到郵件server不再進行113端口的認證嘗試，而是在三次檢測後直接push數據，問題得到完美的解決。
(2)網絡安全中的ARP協議的故障
先看故障現象，局域網中的一臺採用solaris操作系統的服務器A-SERVER網絡連接不正常，從任意主機上都無法ping通該服務器。排查：首先檢查系統，系統本身工作正常，無特殊進程運行，cpu，內存利用率正常，無掛接任何形式的防火牆，網線正常。此時我們藉助tcpdump來進行故障定位，首先我們將從B-CLIENT主機上執行ping命令，發送icmp數據包給A-SERVER，如下：
[root@redhat log]# ping A-SERVER
PING A-SERVER from B-CLIENT : 56(84) bytes of data.
此時在A-SERVER啓動tcpdump，對來自主機B-CLIENT的數據包進行捕獲。
A-SERVER# tcpdump host B-CLIENT
tcpdump: listening on hme0
16:32:32.611251 arp who-has A-SERVER tell B-CLIENT
16:32:33.611425 arp who-has A-SERVER tell B-CLIENT
16:32:34.611623 arp who-has A-SERVER tell B-CLIENT
我們看到，沒有收到預料中的ICMP報文，反而捕獲到了B-CLIENT發送的arp廣播包，由於主機B-CLIENT無法利用arp得到服務器A-SERVER的地址，因此反覆詢問A-SERVER的MAC地址，由此看來，高層的出問題的可能性不大，很可能在鏈路層有些問題，先來查查主機A-SERVER的arp表：
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 S 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00
請注意A-SERVER的Flags位置，我們看到了只有S標誌。我們知道，solaris在arp實現中，arp的flags需要設置P標誌，才能響應ARP requests。
手工增加p位
A-SERVER# arp -s A-SERVER 00:03:ba:08:b2:83 pub
此時再調用arp -a看看
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00
我們看到本機已經有了PS標誌，此時再測試系統的網絡連接恢復正常，問題得到解決。
(3)netflow軟件的問題
先看故障現象,在新裝的網管工作站上安裝cisco netflow軟件對路由設備流量等進行分析，路由器按照要求配置完畢，本地工作上軟件安裝正常，無報錯信息，但是啓動netflow collector卻收不到任何路由器上發出的流量信息，導致該軟件失效。 排查現象，反覆檢查路由和軟件，配置無誤。採用逐步分析的方法，首先先要定位出有問題的設備，是路由器根本沒有發送流量信息還是本地系統接收出現了問題？突然想到在路由器上我們定義了接收的client端由udp端口9998接收數據，可以通過監視這個端口來看路由器是否確實發送了udp數據，如果系統能夠接收到來自路由的數據包，那麼路由方面的問題可能行不大，反之亦然。
在網管工作站上使用tcpdump來看看：
nms#tcpdump port 9995
tcpdump: listening on hme0
18:15:34.373435 routea ＞ nms.9995: udp 1464
18:15:34.373829 routea.50111 ＞ nms.9995: udp 1464
18:15:34.374100 routea.50111 ＞ nms.9995: udp 1464
馬上我們就看到數據包確實從路由器上發過來了，問題出在路由器的可能性基本排除，重新覈查系統，果然，網管工作站上安裝了防火牆，udp端口9998是被屏蔽的，調整工作站上的防火牆配置，netflow工作恢復正常，故障得以排除。
linux常用示例：
tcpdump -i bond1 -s 0 -w /aaa.cap
tcpdump -i bond1 -s 0 port 1812 or port 1813 -w /aaa.cap //抓取本機1812或者是1813的來訪數據
Solaris系統用：snoop -d hme0 -t a -x 54 port 19999 //這是Solaris的內部命令，只能用於Solaris
tcpdump -i bond0 -nn -X 'port 21' //可以抓取來訪問我21號端口的客戶端、用戶名、密碼等信息
AIX常用示例：
IBM小型機抓包命令：
tcpdump -i en0 -w spadap_ceshi.cap -s 2000 host 10.0.0.101
tcpdump -i en0 -w spadap_ceshi.cap -s 2000 host 10.0.0.101
tcpdump -i en0 -w tcpdump.cap -s 0 port 5019 and host 10.71.101.11
tcpdump -D
iptrace -u