然而，在進行診斷分析時發現，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。
同理分析得到，上圖紅色矩形框選的地址都存在這種問題。
數據包分析
對事件深入分析，雙擊上圖高亮事件，查看相關數據解碼信息。通過下圖分析到，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地址都是從廣域網發送過來。
四、分析總結
分析結論
從上面的分析看到，客戶遇到的網絡問題其實是正在遭遇虛假源地址攻擊，大量的假冒地址對內部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，問題解決。
【想看更多互聯網新聞和深度報道請關注樂購網官方微信。（微信號：樂購網）】
推薦閱讀
云計算安全問題究竟是什么問題？ 人們常把云計算服務比喻成電網的供電服務。《哈佛商業評論》前執行主編Nick Carr在新書“The Big Switch”中比較了云計算和電力網絡的發展，他認為“云計算對技術產生的作用就像電力>>>詳細閱讀
本文標題：網絡安全虛假源地址網絡攻擊分析案例
地址：http://www.brh9h.cn/a/11/20130425/267133.html
網友點評
精彩導讀
科技快報
品牌展示