一、故障描述
問題描述
某政府用戶求助，其網絡正在遭遇不明問題。由于該用戶承擔重要的業務系統運營，因此，該問題對其業務穩定性有較大影響，需要盡快定位問題原因并做出相應對策。
從業務操作層面來講，無論是內部用戶還是外部用戶，在訪問其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)。
二、分析方案及思路
基本分析思路
無論是外網還是內網對DMZ區域的主機Ping操作都呈現相同現象，而內網用戶區域相互Ping測試則不存在問題，所以，建議先在DMZ區域交換機D上設置端口鏡像并采集和分析。
如果在D設備上流量可以分析到相關問題原因或有所新的發現，則根據發現再進一步部署分析策略。
分析設備部署
如下圖，將科來網絡分析系統接入到交換機D的流量鏡像端口。由于未知丟包原因或目標(幾乎所有DMZ主機都丟包)，建議不設置任何過濾器，即捕獲所有數據包。
分析檔案與方案選擇
在使用科來網絡分析系統前，選擇正確的分析檔案和分析方案，這對分析效率及數據處理性能方面都有極大的優化作用。這一步不可忽視。
根據用戶的實際網絡情況，以及對應問題特性，在進行數據捕獲時，采用如下網絡檔案和分析方案，且不進行任何過濾器設置。
三、分析過程
分析過程包括數據捕獲后的總體分析，異常發現和分析。此部分對DMZ區域交換機D上捕獲的數據進行分析。
總體分析
數據包基本信息
如下圖，采集時間約55.5秒的數據包，包含25,003個數據包，未設置任何過濾器。
統計信息
從下圖的統計信息可以查看到，流量分布基本正常;數據包大小分布中，64-127字節的數據包數約為1024-1518字節數據包個數的3倍，這說明網絡中小包數據過多。
從會話及應用信息的統計中看到，在55.5秒時間內，DNS查詢和響應次數分別超過1400個，從數量來說較偏大。
故障信息統計
采用分析系統默認診斷定義，提示共有6658個診斷，分布在應用層到物理層不等，其中最多的是傳輸層的數據包重傳和重復確認，超過了6000個，這說明網絡質量情況不佳。
另外，系統提示存在ARP請求風暴，通過分析，確認所有的ARP請求數據包均為正常數據包，且頻率不高，不會對網絡內主機造成影響或欺騙。
問題分析
問題分析部分，主要針對發現的異常現象進行分析和驗證。
異常發現
在進行內部用戶訪問方式描述時曾提到，網關103.16.80.129的MAC地址為00:13:7F:71:DD:91，這個MAC只有當數據流經路由器時才會使用到。見下圖：
推薦閱讀
云計算安全問題究竟是什么問題？ 人們常把云計算服務比喻成電網的供電服務。《哈佛商業評論》前執行主編Nick Carr在新書“The Big Switch”中比較了云計算和電力網絡的發展，他認為“云計算對技術產生的作用就像電力>>>詳細閱讀
本文標題：網絡安全虛假源地址網絡攻擊分析案例
地址：http://www.zcgs360.cn/a/11/20130425/267133.html
網友點評
精彩導讀
科技快報
品牌展示