一、故障描述

問題描述

某政府用戶求助，其網絡正在遭遇不明問題。由于該用戶承擔重要的業務系統運營，因此，該問題對其業務穩定性有較大影響，需要盡快定位問題原因并做出相應對策。

從業務操作層面來講，無論是內部用戶還是外部用戶，在訪問其Web或其他服務器時，感受較慢；從技術層面做簡單的Ping測試，出現如下現象：

 

從上面的內網Ping測試結果來看，訪問目標確實存在間歇性丟包現象。從丟包結果明顯看到，這與常見的網絡擁塞等情況下的丟包狀況不太一樣。

以上信息證明，該網絡的確存在問題，需要進一步分析原因。

網絡與應用結構描述

在進行分析前，通過與技術負責人簡單的交流，得知其網絡大致結構如下：

上面的拓撲結構簡明描述了用戶的網絡和應用部署結構，需要說明的幾點有：

IPS沒有過多的策略定制；

FW對所有流量均透明；

流控設備僅對內部用戶啟用NAT，外網用戶訪問DMZ或DMZ流向外網數據均未做NAT；

用戶擁有103.16.80.0/129的公網IP地址，除了路由器和流控設備使用了2個外，其他的都用在DMZ區域。

內網用戶訪問方式描述

由于本次故障分析是在內網進行，所以有必要說明一下內網用戶在訪問DMZ區域的數據變化及流經過程。

如下圖所示：

假如用戶A要訪問OA服務器E，其訪問途徑為上圖紅色標記的1-4。其中，流控設備作為A的NAT設備，同時，A的數據會從流控B發送到C，然后再返回B到交換機D到E。

用戶A在內網的訪問IP地址變化如下：

發送數據包：A IP——>B:103.16.80.131——>E:103.16.80.189；

返回數據包：E:103.16.80.189——>B:103.16.80.131——> A IP；

其中用戶A的IP為私有IP地址（內網用戶均使用私有IP）。#p#

二、分析方案及思路

基本分析思路

無論是外網還是內網對DMZ區域的主機Ping操作都呈現相同現象，而內網用戶區域相互Ping測試則不存在問題，所以，建議先在DMZ區域交換機D上設置端口鏡像并采集和分析。

如果在D設備上流量可以分析到相關問題原因或有所新的發現，則根據發現再進一步部署分析策略。

分析設備部署

如下圖，將科來網絡分析系統接入到交換機D的流量鏡像端口。由于未知丟包原因或目標（幾乎所有DMZ主機都丟包），建議不設置任何過濾器，即捕獲所有數據包。

分析檔案與方案選擇

在使用科來網絡分析系統前，選擇正確的分析檔案和分析方案，這對分析效率及數據處理性能方面都有極大的優化作用。這一步不可忽視。

根據用戶的實際網絡情況，以及對應問題特性，在進行數據捕獲時，采用如下網絡檔案和分析方案，且不進行任何過濾器設置。

#p#

三、分析過程

分析過程包括數據捕獲后的總體分析，異常發現和分析。此部分對DMZ區域交換機D上捕獲的數據進行分析。

總體分析

數據包基本信息

如下圖，采集時間約55.5秒的數據包，包含25,003個數據包，未設置任何過濾器。

統計信息

從下圖的統計信息可以查看到，流量分布基本正常；數據包大小分布中，64-127字節的數據包數約為1024-1518字節數據包個數的3倍，這說明網絡中小包數據過多。

從會話及應用信息的統計中看到，在55.5秒時間內，DNS查詢和響應次數分別超過1400個，從數量來說較偏大。

故障信息統計

采用分析系統默認診斷定義，提示共有6658個診斷，分布在應用層到物理層不等，其中最多的是傳輸層的數據包重傳和重復確認，超過了6000個，這說明網絡質量情況不佳。

另外，系統提示存在ARP請求風暴，通過分析，確認所有的ARP請求數據包均為正常數據包，且頻率不高，不會對網絡內主機造成影響或欺騙。#p#

問題分析

問題分析部分，主要針對發現的異常現象進行分析和驗證。

異常發現

在進行內部用戶訪問方式描述時曾提到，網關103.16.80.129的MAC地址為00:13:7F:71:DD:91，這個MAC只有當數據流經路由器時才會使用到。見下圖：

然而，在進行診斷分析時發現，DMZ內部服務器發送給應在DMZ區域內的IP的流量，竟發送到了00:13:7F:71:DD:91，甚至對有些不存在的103.16.80.0段地址的流量也發送到了這個MAC。這與分析前了解到的情況并不一樣。

上圖高亮部分證明了上面提到的MAC問題。

另外，高亮部分只是從診斷發生地址中隨機選擇的一個地址的2個事件，該事件說明，103.16.80.130（DNS服務器）發向103.16.80.107的流量被發送到00:13:7F:71:DD:91。

同理分析得到，上圖紅色矩形框選的地址都存在這種問題。#p#

數據包分析

對事件深入分析，雙擊上圖高亮事件，查看相關數據解碼信息。通過下圖分析到，103.16.80.107向DNS服務器103.16.80.130發送域名解析請求，后者對前者響應，內容為“查詢錯誤”。

且不管DNS應答錯誤原因，單從源IP MAC來看，說明其來源于廣域網。而經過確認，某些屬于DMZ區域的IP也同樣存在這種問題，其作為源IP地址從廣域網來連接內部DNS服務器，且DNS服務器全部做了應答。

DNS訪問行為分析

上面的分析發現，存在疑問的IP地址基本都向內部DNS發起域名解析請求，這里對DNS服務器的訪問情況進行分析。

如下圖，5.5秒時間，共有與DNS服務器同段的224個IP向DNS服務器發起解析請求，而這些IP地址都是從廣域網發送過來。

#p#

四、分析總結

分析結論

從上面的分析看到，客戶遇到的網絡問題其實是正在遭遇虛假源地址攻擊，大量的假冒地址對內部DNS發起大量的請求。

然而，這并不能解釋客戶網絡慢，Ping包丟失的原因，即這種網絡攻擊為什么會造成故障存在？

這里對可能的問題原因進行說明。

假設用戶A正在對DMZ服務器103.16.80.189進行Ping操作，這時，虛假地址103.16.80.189經過Router和FW訪問DNS 103.16.80.130，同時DNS服務器對該虛假地址做出響應。造成的影響為，防火墻會在其接口地址列表中記錄：103.16.80.189地址是從源MAC地址為00:13:7F:71:DD:91的接口轉發過來。這時，發往103.16.80.189的ICMP數據包被轉發到了路由器，接著轉發到廣域網，結果石沉大海。如下圖所示：

當Ping包無法到達目的地時（會返回來錯誤的ICMP協議報文），路由器更新新的路由信息后，則再發往路由器的Ping包會被重定向到正確位置，防火墻更新新的端口地址列表信息，Ping操作成功。

問題驗證

為了進一步驗證分析結果，以及確認問題是由虛假源IP訪問內部DNS帶來的網絡攻擊。在IPS和FW之間串接一個Hub，從以下位置捕獲數據進行分析。

通過分析捕獲到的數據，發現實際結果與分析得到的答案一致，如下圖，內網用戶對DMZ區域主機的Ping被發送到了Router。

五、解決方法

分析到問題的原因后，解決方法則變的較為簡單。

在IPS上設置策略，禁止DMZ區域的IP作為源IP訪問DNS服務器的流量通過IPS，問題解決。