在Ethereal（Wireshark）出現(xiàn)之前大家都用Tcpdump，而且很多人現(xiàn)在還在一直使用。它也許沒有Wireshark那么多花里胡哨的東西（比如漂亮的圖形界面，亦或數(shù)以百計的應用協(xié)議邏輯分析），但它能出色的完成很多任務，并且漏洞非常少，消耗系統(tǒng)資源也非常少。它很少添加新特性了，但經(jīng)常修復一些bug和維持較小的體積。它能很好的跟蹤網(wǎng)絡問題來源，并能監(jiān)控網(wǎng)絡活動。其Windows下的版本叫做WinDump。Libpcap/WinPcap的包捕獲庫就是基于TCPDump，它也用在Nmap等其它工具中。記得以前TsutomuShimomura（應該叫下村侵吧）就是使用他自己修改過的TCPDUMP版本來記錄了KEVINMITNICK攻擊他系統(tǒng)的記錄，后來就配合FBI抓住了KEVINMITNICK。
 

下載鏈接：http://down.51cto.com/data/146156

1、網(wǎng)絡數(shù)據(jù)采集分析工具TcpDump分析

(1)網(wǎng)絡的數(shù)據(jù)過濾

不帶任何參數(shù)的TcpDump將搜索系統(tǒng)中所有的網(wǎng)絡接口，并顯示它截獲的所有數(shù)據(jù)，這些數(shù)據(jù)對我們不一定全都需要，而且數(shù)據(jù)太多不利于分析。所以，我們應當先想好需要哪些數(shù)據(jù)，TcpDump提供以下參數(shù)供我們選擇數(shù)據(jù)：

-b在數(shù)據(jù)-鏈路層上選擇協(xié)議，包括ip、arp、rarp、ipx都是這一層的。例如：

server#tcpdump -b arp

將只顯示網(wǎng)絡中的arp即地址轉(zhuǎn)換協(xié)議信息。

-i選擇過濾的網(wǎng)絡接口，如果是作為路由器至少有兩個網(wǎng)絡接口，通過這個選項，就可以只過濾指定的接口上通過的數(shù)據(jù)。例如：

server#tcpdump -i eth0

只顯示通過eth0接口上的所有報頭。src、dst、port、host、net、ether、gateway這幾個選項又分別包含src、dst、port、host、net、ehost等附加選項。他們用來分辨數(shù)據(jù)包的來源和去向，src host 192.168.0.1指定源主機IP地址是192.168.0.1，dst net 192.168.0.0/24指定目標是網(wǎng)絡192.168.0.0。以此類推，host是與其指定主機相關(guān)無論它是源還是目的，net是與其指定網(wǎng)絡相關(guān)的，ether后面跟的不是IP地址而是物理地址，而gateway則用于網(wǎng)關(guān)主機?？赡苡悬c復雜，看下面例子就知道了：

server#tcpdump src host 192.168.0.1 and dst net 192.168.0.0/24

過濾的是源主機為192.168.0.1與目的網(wǎng)絡為192.168.0.0的報頭。

server#tcpdump ether src 00:50:04:BA:9B and dst......

過濾源主機物理地址為XXX的報頭(為什么ether src后面沒有host或者net？物理地址當然不可能有網(wǎng)絡嘍)。

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這些選項等都要放到第一個參數(shù)的位置，用來過濾數(shù)據(jù)報的類型。例如：

server#tcpdump ip src......

只過濾數(shù)據(jù)-鏈路層上的IP報頭。

server#tcpdump udp and src host 192.168.0.1

只過濾源主機192.168.0.1的所有udp報頭。

(2)網(wǎng)絡的數(shù)據(jù)顯示/輸入輸出

TcpDump提供了足夠的參數(shù)來讓我們選擇如何處理得到的數(shù)據(jù)，如下所示：

-l可以將數(shù)據(jù)重定向。

如tcpdump -l＞tcpcap.txt將得到的數(shù)據(jù)存入tcpcap.txt文件中。

-n不進行IP地址到主機名的轉(zhuǎn)換。

如果不使用這一項，當系統(tǒng)中存在某一主機的主機名時，TcpDump會把IP地址轉(zhuǎn)換為主機名顯示，就像這樣：eth0＜ntc9.1165＞router.domain.net.telnet，使用-n后變成了：eth0＜192.168.0.9.1165＞192.168.0.1.telnet。

-nn不進行端口名稱的轉(zhuǎn)換。

上面這條信息使用-nn后就變成了：eth0＜ntc9.1165＞router.domain.net.23。

-N不打印出默認的域名。

還是這條信息-N后就是：eth0＜ntc9.1165＞router.telnet。

-O不進行匹配代碼的優(yōu)化。

-t不打印UNIX時間戳，也就是不顯示時間。

-tt打印原始的、未格式化過的時間。

-v詳細的輸出，也就比普通的多了個TTL和服務類型。#p#

2、網(wǎng)絡數(shù)據(jù)采集分析工具TcpDump分析詳細例子

(1)網(wǎng)絡郵件服務器(mail)在排障

我們先來看看故障現(xiàn)象，在一局域網(wǎng)中新安裝了后臺為qmail的郵件服務器server，郵件服務器收發(fā)郵件等基本功能正常，但在使用中發(fā)現(xiàn)一個普遍的怪現(xiàn)象：pc機器上發(fā)郵件時連接郵件服務器后要等待很久的時間才能開始實際的發(fā)送工作。我們來看，從檢測來看，網(wǎng)絡連接沒有問題，郵件服務器server和下面的pc性能都沒有問題，問題可能出在哪里呢？為了進行準確的定位，我們在pc機client上發(fā)送郵件，同時在郵件服務器server上使用tcpdump對這個client的數(shù)據(jù)包進行捕獲分析，如下：

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秒后，才放棄認證請求，主動發(fā)送了reset標志的數(shù)據(jù)包，開始push后面的數(shù)據(jù)，而正是在這個過程中所花費的26秒時間，造成了發(fā)送郵件時漫長的等待情況。問題找到了，就可以修改了，我們通過修改服務器端的qmail配置，使它不再進行113端口的認證，再次抓包，看到郵件server不再進行113端口的認證嘗試，而是在三次檢測后直接push數(shù)據(jù)，問題得到完美的解決。

(2)網(wǎng)絡安全中的ARP協(xié)議的故障

先看故障現(xiàn)象，局域網(wǎng)中的一臺采用solaris操作系統(tǒng)的服務器A-SERVER網(wǎng)絡連接不正常，從任意主機上都無法ping通該服務器。排查：首先檢查系統(tǒng)，系統(tǒng)本身工作正常，無特殊進程運行，cpu，內(nèi)存利用率正常，無掛接任何形式的防火墻，網(wǎng)線正常。此時我們借助tcpdump來進行故障定位，首先我們將從B-CLIENT主機上執(zhí)行ping命令，發(fā)送icmp數(shù)據(jù)包給A-SERVER，如下：

[root@redhat log]# ping A-SERVER

PING A-SERVER from B-CLIENT : 56(84) bytes of data.

此時在A-SERVER啟動tcpdump，對來自主機B-CLIENT的數(shù)據(jù)包進行捕獲。

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發(fā)送的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實現(xiàn)中，arp的flags需要設(shè)置P標志，才能響應ARP requests。

手工增加p位

A-SERVER# arp -s A-SERVER 00:03:ba:08:b2:83 pub

此時再調(diào)用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

我們看到本機已經(jīng)有了PS標志，此時再測試系統(tǒng)的網(wǎng)絡連接恢復正常，問題得到解決。

(3)netflow軟件的問題

先看故障現(xiàn)象,在新裝的網(wǎng)管工作站上安裝cisco netflow軟件對路由設(shè)備流量等進行分析，路由器按照要求配置完畢，本地工作上軟件安裝正常，無報錯信息，但是啟動netflow collector卻收不到任何路由器上發(fā)出的流量信息，導致該軟件失效。 排查現(xiàn)象，反復檢查路由和軟件，配置無誤。采用逐步分析的方法，首先先要定位出有問題的設(shè)備，是路由器根本沒有發(fā)送流量信息還是本地系統(tǒng)接收出現(xiàn)了問題？突然想到在路由器上我們定義了接收的client端由udp端口9998接收數(shù)據(jù)，可以通過監(jiān)視這個端口來看路由器是否確實發(fā)送了udp數(shù)據(jù)，如果系統(tǒng)能夠接收到來自路由的數(shù)據(jù)包，那么路由方面的問題可能行不大，反之亦然。

在網(wǎng)管工作站上使用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

馬上我們就看到數(shù)據(jù)包確實從路由器上發(fā)過來了，問題出在路由器的可能性基本排除，重新核查系統(tǒng)，果然，網(wǎng)管工作站上安裝了防火墻，udp端口9998是被屏蔽的，調(diào)整工作站上的防火墻配置，netflow工作恢復正常，故障得以排除。

【編輯推薦】

1. 淺析局域網(wǎng)監(jiān)聽技術(shù)
2. 淺析如何預防DDOS攻擊
3. 如何防止網(wǎng)絡監(jiān)聽與端口掃描
4. ARP病毒攻擊原理及破解方案解析
5. 無線路由器ARP攻擊故障排除方法共享