第39章某供電局內(nèi)部網(wǎng)絡(luò)分析39.1故障描述 39.2故障分析39.3總結(jié) 213

某供電局網(wǎng)絡(luò)負(fù)責(zé)人向我們求助，說供電局下面的鄉(xiāng)鎮(zhèn)訪問網(wǎng)絡(luò)中服務(wù)器時(shí)時(shí)斷時(shí)續(xù)，Ping核心層設(shè)備也有延遲和丟包，同時(shí)他們網(wǎng)絡(luò)中的其他網(wǎng)段訪問服務(wù)器也出現(xiàn)此類情況。這種情況已持續(xù)數(shù)天，使用許多辦法還是沒找到發(fā)生問題的故障點(diǎn)。由于客戶急于交電費(fèi)，該負(fù)責(zé)人直接將捕獲的數(shù)據(jù)包傳給我們，讓我們馬上分析。39.1故障描述

39.2.1分析故障思路

根據(jù)當(dāng)前已了解的情況還無法確定是否有病毒、攻擊等造成的影響。抓包點(diǎn)部署在核心層，然后按照診斷提示從底層到高層一步一步地分析。39.2故障分析39.2.2解決步驟

抓包時(shí)間不到4分鐘，總流量為176MB，如圖39-1所示的流量趨勢(shì)圖，峰值時(shí)達(dá)到20Mbps，流量偏大，對(duì)網(wǎng)絡(luò)有一定影響。

圖39-1選中該流量峰值時(shí)間段的數(shù)據(jù)包下載分析，查看“概要”統(tǒng)計(jì)，如圖39-2所示。

從圖中可以看到，廣播流量偏多，可能存在大量ARP廣播；數(shù)據(jù)包大于1518B的占多數(shù)，說明當(dāng)前網(wǎng)絡(luò)中存在大量的數(shù)據(jù)傳輸；另外，小于64B的數(shù)據(jù)包也較多，說明網(wǎng)絡(luò)可能存在掃描等現(xiàn)象。

我們?cè)俨榭础癟CP統(tǒng)計(jì)”，如圖39-3所示。

圖39-2

圖39-3從圖39-3中可以看出，TCP同步發(fā)送與TCP同步確認(rèn)發(fā)送比例將近10∶1，我們懷疑網(wǎng)絡(luò)中可能存在TCP泛洪。

通過“概要”統(tǒng)計(jì)數(shù)據(jù)推斷網(wǎng)絡(luò)中可能存在大量ARP廣播和TCP泛洪，為了驗(yàn)證這一推斷，我們來查看“診斷”選項(xiàng)，如圖39-4所示。

圖39-4從圖中可以看到，網(wǎng)絡(luò)在“診斷”中確實(shí)有相應(yīng)的提示，但是從數(shù)據(jù)鏈路層到傳輸層故障診斷都很多，從何處下手呢？不妨按部就班，從底層到高層逐一進(jìn)行排查。39.2.3對(duì)數(shù)據(jù)鏈路層進(jìn)行分析

我們?cè)凇霸\斷”界面中發(fā)現(xiàn)，ARP格式違規(guī)，然后診斷事件提示以太網(wǎng)頭部的源MAC與ARP頭部的源MAC不相同，見圖39-5。憑經(jīng)驗(yàn)我們判斷可能是ARP攻擊，為了確定判斷，定位到問題數(shù)量多的地址，分析其數(shù)據(jù)包。

圖39-5查看數(shù)據(jù)包才得知，原來核心層開啟了HSRP(Cisco的熱備份路由協(xié)議)，如圖39-6所示。這樣的環(huán)境下Cisco設(shè)備發(fā)送的ARP應(yīng)答報(bào)文的源MAC地址是其真實(shí)的MAC，而ARP消息中的源物理地址是HSRP的虛擬MAC地址，從而會(huì)導(dǎo)致科來“ARP格式違規(guī)”的診斷，并非ARP攻擊等異常通信行為。

在數(shù)據(jù)鏈路層我們也看到了ARP掃描行為，如圖39-7所示。

圖39-6

圖39-7從圖39-7中可以看到，大多是172.169.65.1這個(gè)地址在掃描172.169.65.0網(wǎng)段。與網(wǎng)管溝通得知該網(wǎng)段是監(jiān)控用的，同時(shí)172.169.65.1是網(wǎng)關(guān)地址，因此此行為屬正常。

對(duì)數(shù)據(jù)鏈路層并沒有分析出什么問題，于是接著分析網(wǎng)絡(luò)層。39.2.4對(duì)網(wǎng)絡(luò)層進(jìn)行分析

從圖39-8中可以看到，IPTTL太小，可以立刻判斷出網(wǎng)絡(luò)中存在路由環(huán)路。為了進(jìn)一步確認(rèn)這一點(diǎn)，查看具體數(shù)據(jù)包，如圖39-9所示。

圖39-8

圖39-9從圖39-9中可以看到TTL值一直遞減到0，可以確認(rèn)網(wǎng)絡(luò)中出現(xiàn)了路由環(huán)路。與網(wǎng)管溝通后得知192.168.1.0網(wǎng)段不存在，但是經(jīng)核實(shí)確實(shí)存在路由環(huán)路。于是我們寫了一條ACL(AccessControlList，訪問控制列表)，使192.168.1.0網(wǎng)段指向“null0”(偽接口，不能分配地址，這樣就可以有效防止路由環(huán)路問題)。

在網(wǎng)絡(luò)層中也存在大量的地址沖突，查看數(shù)據(jù)包解碼，如圖39-10所示。

圖39-10這種情況可能是因?yàn)闉榱朔乐沟刂窙_突而發(fā)出的ARP請(qǐng)求，對(duì)網(wǎng)絡(luò)不會(huì)造成影響。

通過以上對(duì)數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層的分析，并沒有把當(dāng)前網(wǎng)絡(luò)故障的原因找到，不過問題已基本上定位到了傳輸層。39.2.5對(duì)傳輸層進(jìn)行分析

在“診斷”統(tǒng)計(jì)中可以看到，主要診斷事件是TCP重復(fù)的連接嘗試，見圖39-11。根據(jù)以往的分析經(jīng)驗(yàn)，我們猜想可能是蠕蟲在進(jìn)行TCP泛洪掃描。為了進(jìn)一步驗(yàn)證我們的判斷，查看“IP會(huì)話”，如圖39-12所示。

圖39-11

圖39-12從圖中可以看到，172.169.63.53這個(gè)地址只發(fā)送而不接收數(shù)據(jù)包，同時(shí)網(wǎng)絡(luò)是內(nèi)網(wǎng)，但是該地址在掃描外網(wǎng)地址。再查看“TCP會(huì)話”，如圖39-13所示。

從圖中可得知，172.169.63.53訪問的都是外網(wǎng)地址，它自己的端口是遞增的，目標(biāo)主機(jī)端口都是445，基本上都是發(fā)送數(shù)據(jù)包為4個(gè)，接收數(shù)據(jù)包為0個(gè)，持續(xù)時(shí)間短暫。下面看看“矩陣”視圖，如圖39-14所示。

圖39-13

圖39-14對(duì)方IP地址數(shù)將近4300個(gè)，本地IP接收數(shù)據(jù)也很少。然后我們?cè)俨榭磾?shù)據(jù)包解碼，如圖39-15所示。

可以看到，TCP同步位均為1。至此可以斷定，該主機(jī)中了CIFS蠕蟲并且正在進(jìn)行TCP同步泛洪攻擊。后經(jīng)進(jìn)一步細(xì)查，發(fā)現(xiàn)網(wǎng)絡(luò)中居然有6臺(tái)主機(jī)都出現(xiàn)這樣的情況，這肯定會(huì)對(duì)核心交換機(jī)的性能造成很大影響，同時(shí)也影響網(wǎng)絡(luò)通信，嚴(yán)重時(shí)可能出現(xiàn)網(wǎng)絡(luò)癱瘓。針對(duì)上面這種情況，通過與網(wǎng)管溝通找到這6臺(tái)主機(jī)，最后對(duì)其斷網(wǎng)殺毒處理。就在斷網(wǎng)不到15分鐘，網(wǎng)絡(luò)管理人員Ping服務(wù)器和其他網(wǎng)段便不存在延遲丟包，訪問基本上正常了。由此我們斷定是因?yàn)榫W(wǎng)絡(luò)中出現(xiàn)了大量的CIFS蠕蟲造成網(wǎng)絡(luò)通信異常，但還不可以放松，必須全面考慮，排查一切隱患。

接下來查看“IP端點(diǎn)”流量情況，如圖39-16所示。

圖39-15

圖39-16通過“IP端點(diǎn)”視圖我們發(fā)現(xiàn)，10.140.107.204這個(gè)地址是他們內(nèi)網(wǎng)服務(wù)器的地址，為何TCP的同步發(fā)送與同步確認(rèn)比例這么大呢(64.39、63.53、63.5等地址不用看，因?yàn)槎际侵辛巳湎x的緣故)？馬上進(jìn)行定位分析，查看“TCP會(huì)話”，如圖39-17所示。

地址107.204與107.68的會(huì)話端口是遞增的，目標(biāo)主機(jī)的端口是139，每個(gè)會(huì)話包數(shù)都是48個(gè)。打開“數(shù)據(jù)流”視圖可以看到，107.204地址在利用NETBIOS協(xié)議的139端口不斷嘗試破解地址為107.68的內(nèi)網(wǎng)服務(wù)器用戶密碼。查看內(nèi)網(wǎng)其他服務(wù)器，它們也遭到此地址攻擊。由此斷定此地址中了蠕蟲，趕緊找到網(wǎng)管說明此事。當(dāng)時(shí)網(wǎng)絡(luò)管理人員也十分吃驚，立刻斷網(wǎng)殺毒，幸好沒出大事。最后，我們建議網(wǎng)管人員進(jìn)