tcpdump抓包分析案例

找了很久抓包分析的一些例子，可以就是那麼幾個在不停的重複。抓包分析起來才覺得基本功太不夠了，涉及到的東西太多，要瞭解的東西也太多。發這個貼的目的是有  希望我們有幸一起分享您的勞動汗水和結晶  
建議大家多舉些例子，謝謝大家。

tcpdump抓包分析詳解 http://blog.csdn.net/yeqihong/archive/2007/01/08/1477050.aspx

用tcpdump分析traceroute的工作原理［原創］
http://www.0ginr.com/bbs/viewthread.php?tid=184&extra=page%3D1

例1：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標誌，此時再測試系統的網路連接恢複正常，問題解決！

例2：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工作恢複正常，故障排除！
例3：郵件伺服器排障

故障現象：區域網路新安裝了後台為qmail的郵件伺服器server，郵件伺服器收發郵件等準系統正常，但在使用中發現一個普遍的怪現象

：pc機器上發郵件時串連郵件伺服器後要等待很久的時間才能開始實際的發送工作。

排查：網路連接沒有問題，郵件伺服器server和下面的pc效能都沒有問題，問題可能出在哪裡呢？為了進行準確的定位，我們在pc機

client上發送郵件，同時在郵件伺服器server上使用tcpdump對這個client的資料包進行捕獲分析，如下：
server#tcpdump host client
tcpdump: listening on hme0
19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) win 64240 <mss 1460,nop,wscale

0,nop,nop,timestamp[|tcp]> (DF)
19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 <nop,nop,timestamp 20468779

0,nop,[|tcp]> (DF)
19:04:30.040960 client.1065 > server.smtp: . ack 1 win 64240 (DF)
順利的完成三向交握，目前為止正常，往下看
19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 <mss 1460> (DF)
19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF)
19:04:56.070108 server.smtp > client.1065: P 1:109(10 ack 1 win 10136 <nop,nop,timestamp 20471382 167656> (DF)

這裡有問題了，我們看到server端試圖串連client的113 identd連接埠，要求認證，然而沒有收到client端的回應，server端重複嘗試了3

次，費時26秒後，才放棄認證請求，主動發送了reset標誌的資料包，開始push後面的資料，而正是在這個過程中所花費的26秒時間，造

成了發送郵件時漫長的等待情況。
問題找到了，就可以對症下藥了，通過修改伺服器端的qmail配置，使它不再進行113連接埠的認證，再次抓包，看到郵件server不再進行

113連接埠的認證嘗試，而是在三向交握後直接push資料，問題解決！

總結：上面我們通過實際的例子示範了包分析軟體在故障解決中起到的作用，通過這些例子，我們不難發現，用好包分析軟體，對系統

管理員快速準確定位網路故障，分析網路問題有不可替代的作用
轉自  http://chinabeta.cn/wgjs/pmsj/200704/15695.html

使用Ethereal的過濾器處理某學校網路問題中的大致過程
http://bbs.chinaunix.net/viewthread.php?tid=874452&highlight=使用Ethereal的過濾器處理某學校網路問題中的大致過程

一個學校發現其中有ARP欺騙,衝擊波病毒,蠕蟲王病毒,需要處理.

處理過程:
在核心交換器上配置連接埠鏡像分別抓各個網段的資料包,(分別抓各個網段的資料包的目的是減小核心交換器壓力,也方便縮小分析量)

1.ARP欺騙
使用下列過濾法則:
arp.opcode==1 or arp.opcode==2
發現ARP欺騙包後,以其MAC為過濾條件即:
eth.scr ==.....
分析其相關IP資訊,找到具體使用者.如果使用者修改了IP和MAC地址就只有一根一根去拔線了!

2.衝擊波病毒
分析資料包,使用下列過濾法則:
tcp.port == 135
tcp.port == 139
分析過濾後的資料包,察看發現全是TCP三向交握中的第一個syn包,檢查其佔總體資料的比率遠高於正常水平.
通過IP尋找源頭!

3.蠕蟲王病毒
tcp.port == 1433
分析過濾後的資料包,察看發現全是TCP三向交握中的第一個syn包,檢查其佔總體資料的比率遠高於正常水平.
通過IP尋找源頭!

4.使用下列過濾法則:
!(tcp.port ==5900 or tcp.port ==135 or tcp.port==139)
先儲存過濾後的資料包,再分析.
發現:
tcp.port == 5900佔用的資料比率也比較高
VNC TCP port: 5900) 5900/tcp open vnc VNC (protocol 3.
追蹤相關IP!

由於其教室中的PC都是有硬體還原卡的,而它PC也是管理較為混亂.於是決定決定在核心交換器上添加訪問列表.

具體訪問列表的方案參考:
網路裝置配置中經常使用的訪問列表或rule(華為裝置中使用)

freebsd用tcpdump的參數順序有嚴格限制
如： #tcpdump -i eth1 -w c.cap -s 0  host 192.168.2.1 and host 23.33.22.56
能在freebsd下執行，如果把-w c.cap放到末尾就會出錯，可是在linux還是能執行的。