《CSNA網(wǎng)絡(luò)分析認證專家實戰(zhàn)案例》課件-第29章

第29章虛假源地址網(wǎng)絡(luò)攻擊分析案例29.1故障描述29.2分析方案及思路29.3分析過程29.4分析總結(jié)

29.1.1故障現(xiàn)象

某政府用戶求助，其網(wǎng)絡(luò)出現(xiàn)不明問題。由于該用戶承擔(dān)重要的業(yè)務(wù)系統(tǒng)運營，因此該問題對其業(yè)務(wù)穩(wěn)定性有較大影響，需要盡快定位問題原因并作出相應(yīng)對策。29.1故障描述從業(yè)務(wù)操作層面來講，無論是內(nèi)部用戶還是外部用戶，在訪問其Web或其他服務(wù)器時，感覺較慢；從技術(shù)層面做簡單的Ping測試，出現(xiàn)如圖29-1所示的現(xiàn)象。

圖29-1從上面的內(nèi)網(wǎng)Ping測試結(jié)果來看，訪問目標確實存在間歇性丟包現(xiàn)象。從丟包結(jié)果明顯看到，這與常見的網(wǎng)絡(luò)擁塞等情況下的丟包狀況不太一樣。

以上信息證明，該網(wǎng)絡(luò)的確存在問題，需要進一步分析原因。29.1.2網(wǎng)絡(luò)與應(yīng)用結(jié)構(gòu)

在進行分析前，通過與技術(shù)負責(zé)人簡單的交流，得知其網(wǎng)絡(luò)大致結(jié)構(gòu)如圖29-2所示。

圖29-2上面的拓撲結(jié)構(gòu)簡明地描述了用戶的網(wǎng)絡(luò)和應(yīng)用部署結(jié)構(gòu)，需要說明的有

(1)

IPS沒有過多的策略定制。

(2)

FW對所有流量均透明。

(3)流控設(shè)備僅對內(nèi)部用戶啟用NAT，外網(wǎng)用戶訪問DMZ或DMZ流向外網(wǎng)數(shù)據(jù)均未配置NAT。

(4)用戶擁有103.16.80.0/129的公網(wǎng)IP地址，除了路由器和流控設(shè)備使用了2個外，其他的都用在DMZ區(qū)域。29.1.3內(nèi)網(wǎng)用戶訪問方式

由于本次故障分析是在內(nèi)網(wǎng)進行，所以有必要說明一下內(nèi)網(wǎng)用戶在訪問DMZ區(qū)域的數(shù)據(jù)變化及流經(jīng)過程，如圖29-3所示。

假如用戶A要訪問OA服務(wù)器E，其訪問途徑為圖29-3中標記的1和4。其中，流控設(shè)備作為A的NAT設(shè)備，同時A的數(shù)據(jù)會從流控B發(fā)送到C，然后再返回到B，再到交換機D和E。用戶A在內(nèi)網(wǎng)的訪問IP地址變化如下：

(1)發(fā)送數(shù)據(jù)包：A:IP——>B:103.16.80.131——>E:103.16.80.189。

(2)返回數(shù)據(jù)包：E:103.16.80.189——>B:103.16.80.131——>A:IP。

其中，用戶A的IP為私有IP地址(內(nèi)網(wǎng)用戶均使用私有IP)。

圖29-3

29.2.1基本分析思路

無論是外網(wǎng)還是內(nèi)網(wǎng)，對DMZ區(qū)域的主機Ping操作都出現(xiàn)相同現(xiàn)象，而內(nèi)網(wǎng)用戶區(qū)域相互Ping測試則不存在問題。所以，建議先在DMZ區(qū)域交換機D上設(shè)置端口鏡像并采集數(shù)據(jù)和分析。如果在D設(shè)備上，根據(jù)流量可以分析到相關(guān)問題原因或有新的發(fā)現(xiàn)，則根據(jù)發(fā)現(xiàn)再進一步部署分析策略。29.2分析方案及思路29.2.2分析設(shè)備部署

如圖29-4所示，將科來網(wǎng)絡(luò)分析系統(tǒng)接入到交換機D的流量鏡像端口。由于未知丟包原因或目標(幾乎所有DMZ主機都丟包)，建議不設(shè)置任何過濾器，即捕獲所有數(shù)據(jù)包。29.2.3分析檔案與方案選擇

在使用科來網(wǎng)絡(luò)分析系統(tǒng)前，選擇正確的分析檔案和分析方案對分析效率及數(shù)據(jù)處理性能都有極大的優(yōu)化作用，這一步不可忽視。根據(jù)用戶的實際網(wǎng)絡(luò)情況以及對應(yīng)的問題特性，在進行數(shù)據(jù)捕獲時采用如圖29-5所示的網(wǎng)絡(luò)檔案和分析方案，且不進行任何過濾器設(shè)置。

圖29-4

圖29-5

分析過程包括數(shù)據(jù)捕獲后的總體分析和問題分析，主要是針對DMZ區(qū)域交換機D上捕獲的數(shù)據(jù)。29.3分析過程29.3.1總體分析

1.數(shù)據(jù)包基本信息

采集時間約55.5秒，包含25003個數(shù)據(jù)包，未設(shè)置任何過濾器。

2.統(tǒng)計信息

從圖29-6所示的統(tǒng)計信息可以看到，流量分布基本正常；數(shù)據(jù)包大小分布中，64～127B的數(shù)據(jù)包數(shù)約為1024～1518B數(shù)據(jù)包個數(shù)的3倍，這說明網(wǎng)絡(luò)中小包數(shù)據(jù)過多。

圖29-6從圖29-7所示的會話及應(yīng)用信息的統(tǒng)計中看到，在55.5秒時間內(nèi)，DNS查詢和回應(yīng)次數(shù)均超過1400個，數(shù)量偏大。

圖29-7

3.故障信息統(tǒng)計

采用分析系統(tǒng)默認診斷定義，提示共有6658個診斷，分布在應(yīng)用層到物理層不等，其中最多的是傳輸層的數(shù)據(jù)包重傳和重復(fù)確認，超過了6000個，這說明網(wǎng)絡(luò)質(zhì)量不佳。另外，系統(tǒng)提示存在ARP請求風(fēng)暴，通過分析，確認所有的ARP請求數(shù)據(jù)包均為正常數(shù)據(jù)包，且頻率不高，不會對網(wǎng)絡(luò)內(nèi)主機造成影響或欺騙，見圖29-8。

圖29-829.3.2問題分析

問題分析部分主要是針對發(fā)現(xiàn)的異?，F(xiàn)象進行分析和驗證。

1.異常發(fā)現(xiàn)

在圖29-3中可以看到，網(wǎng)關(guān)103.16.80.129的MAC地址為00:13:7F:71:DD:91，這個MAC只有當(dāng)數(shù)據(jù)流經(jīng)路由器時才會使用到，見圖29-9。

圖29-9然而，在進行診斷分析時發(fā)現(xiàn)，DMZ內(nèi)部服務(wù)器發(fā)送給本應(yīng)在DMZ區(qū)域內(nèi)IP的流量竟發(fā)送到了00:13:7F:71:DD:91，甚至有些不存在的103.16.80.0段地址的流量也發(fā)送到了這個MAC。這與分析前了解到的情況并不一樣，如圖29-10所示。

圖29-10圖29-10中高亮部分證明了上面提到的MAC問題。另外，高亮部分只是從診斷發(fā)生地址中隨機選擇的一個地址的2個事件，該事件說明103.16.80.130(DNS服務(wù)器)發(fā)向103.16.80.107的流量被發(fā)送到00:13:7F:71:DD:91。

同理分析可知，上圖黑色矩形框選中地址都存在這種問題。

2.數(shù)據(jù)包分析

對事件進行深入分析，雙擊圖29-10中的高亮事件，查看相關(guān)數(shù)據(jù)解碼信息。通過圖29-11可以分析得知，103.16.80.107向DNS服務(wù)器103.16.80.130發(fā)送域名解析請求，后者對前者響應(yīng)，內(nèi)容為“查詢錯誤”。

圖29-11且不管DNS應(yīng)答錯誤原因，單從源IP的MAC來看，可知其來源于廣域網(wǎng)。而經(jīng)過確認，某些屬于DMZ區(qū)域的IP也同樣存在這種問題，其作為源IP地址從廣域網(wǎng)來連接內(nèi)部DNS服務(wù)器，且DNS服務(wù)器全部作了應(yīng)答。

3.

DNS訪問行為分析

上面的分析發(fā)現(xiàn)，存在疑問的IP地址基本都向內(nèi)部DNS發(fā)起域名解析請求，這里對DNS服務(wù)器的訪問情況進行分析。

如圖29-12所示，5.5秒時間內(nèi)共有與DNS服務(wù)器同段的224個IP向DNS服務(wù)器發(fā)起解析請求，而這些IP地址都是從廣域網(wǎng)發(fā)送過來。

圖29-12

29.4.1分析結(jié)論

從上面的分析看到，客戶遇到的網(wǎng)絡(luò)問題其實是正在遭遇虛假源地址攻擊，大量的假冒地址對內(nèi)部DNS發(fā)起大量的請求。然而這并不能解釋客戶網(wǎng)絡(luò)慢、Ping包丟失的原因，即這種網(wǎng)絡(luò)攻擊為什么會造成故障存在？29.4分析總結(jié)假設(shè)用戶A正在對DMZ服務(wù)器103.16.80.189進行Ping操作，這時，虛假地址103.16.80.189經(jīng)過Router和FW訪問DNS103.16.80.130，同時DNS服務(wù)器對該虛假地址作出響應(yīng)，造成的影響是防火墻會在其接口地址列表中記錄103.16.80.189地址是從源MAC地址為00:13:7F:71:DD:91的接口轉(zhuǎn)發(fā)過來的。這時，發(fā)往103.16.80.189的ICMP數(shù)據(jù)包被轉(zhuǎn)發(fā)到了路由器，接著轉(zhuǎn)發(fā)到廣域網(wǎng)，結(jié)果石沉大海，如圖29-13所示。當(dāng)Ping包無法到達目的地時(會返回來錯誤的ICMP協(xié)議報文)，路由器更新新的路由信息后，則再發(fā)往路由器的Ping包會被重定向到正確位置，防火墻更新新的端口地址列表信息，Ping操作成功。

圖29-1329.4.2問題驗證

為了進一步驗證分析結(jié)果，以及確認問題是由于虛假源IP訪問內(nèi)部DNS帶來的網(wǎng)絡(luò)攻擊造成的，在IPS和FW之間串接一個Hub，從圖29-14所示位置捕獲數(shù)據(jù)并進行分析。

圖29-14