網(wǎng)絡(luò)分析方法與實例

“網(wǎng)絡(luò)分析方法與實例”

9月9日@合肥——網(wǎng)絡(luò)分析技術(shù)交流1方法篇對比分析法對比分析法就是在中間設(shè)備兩端（數(shù)據(jù)包的進口、數(shù)據(jù)包轉(zhuǎn)發(fā)口）同時抓包，并對進出口處所抓取到的數(shù)據(jù)包做相應(yīng)的對比，從而發(fā)現(xiàn)中間設(shè)備對相應(yīng)數(shù)據(jù)包的處理情況，包括更改、丟棄、轉(zhuǎn)發(fā)以及經(jīng)過中間設(shè)備后的延時等。關(guān)聯(lián)分析法關(guān)聯(lián)分析法是指，一個數(shù)據(jù)包或數(shù)據(jù)流在經(jīng)過一個中間設(shè)備時，被中間設(shè)備做了更改，我們利用數(shù)據(jù)包的IP標(biāo)識、應(yīng)用層字段、數(shù)據(jù)流的五元組等特性，將中間設(shè)備前后的數(shù)據(jù)包、數(shù)據(jù)流對應(yīng)起來的方法。TIPS:另外一種對比分析法除了我們這里描述的對比分析法外，還有另外一個較為常用的對比分析方式，那就是將異常時的數(shù)據(jù)交互過程跟正常時的數(shù)據(jù)交互過程進行對比分析，從而發(fā)現(xiàn)異常時數(shù)據(jù)交互的問題所在

2對比分析法-原理當(dāng)一個目的地址不是中間設(shè)備的數(shù)據(jù)包進入一個中間設(shè)備時，它必然會被中間設(shè)備轉(zhuǎn)發(fā)到其某一個出口

3對比分析法-應(yīng)用范圍1分析設(shè)備轉(zhuǎn)發(fā)延時4對比分析法-應(yīng)用范圍2分析設(shè)備是否丟包5對比分析法-應(yīng)用范圍3分析中間設(shè)備對數(shù)據(jù)包的更改當(dāng)一個數(shù)據(jù)包進入一個中間設(shè)備之后，中間設(shè)備可能對該數(shù)據(jù)包做相應(yīng)的改動后，再將其向外轉(zhuǎn)發(fā)出去，很多情況下，這種改動對網(wǎng)絡(luò)數(shù)據(jù)交互是沒有什么影響的，如路由對數(shù)據(jù)包的NAT處理，但是有的時候，某些更改就有可能給網(wǎng)絡(luò)數(shù)據(jù)交互帶來某些難以預(yù)料的后果，如將數(shù)據(jù)包的TCP窗口改小、修改TCP的選項等。我們在分析的過程中，主要關(guān)注中間設(shè)備對數(shù)據(jù)包做了哪些更改以及這些更改可能給網(wǎng)絡(luò)數(shù)據(jù)交互帶來的后果，主要包括數(shù)據(jù)包源IP地址、目的IP地址、IP標(biāo)識、源端口、目的端口、數(shù)據(jù)包窗口大小、TCP選項、數(shù)據(jù)包有效載荷大小等。6對比分析法-應(yīng)用范圍4分析異常時與正常時的差異（基于基線）時間下班期間衡量參數(shù)值上班期間正常行為基線異常行為結(jié)合各種網(wǎng)絡(luò)或業(yè)務(wù)系統(tǒng)的運行基線，我們通過將異常時的網(wǎng)絡(luò)交互情況與正常時的網(wǎng)絡(luò)交互基線參數(shù)數(shù)值進行對比分析，可以幫助我們快速發(fā)現(xiàn)業(yè)務(wù)異常以及可能的原因。另外，還有基于網(wǎng)絡(luò)行為基線的對比分析方式7關(guān)聯(lián)分析法-原理1

IP標(biāo)識關(guān)聯(lián)很多中間設(shè)備在處理數(shù)據(jù)包的過程中，一般不會修改數(shù)據(jù)包的IP標(biāo)識字段，那么，我們就可以通過分析進出中間設(shè)備數(shù)據(jù)包的IP標(biāo)識字段是否一致來判斷是否屬于同一個數(shù)據(jù)包

8關(guān)聯(lián)分析法-原理2五元組關(guān)聯(lián)我們在一個交換或純路由（無NAT）的環(huán)境下做對比分析時，可以利用五元組來快速的將不同位置處抓取的數(shù)據(jù)流關(guān)聯(lián)起來，因為在交換或純路由的環(huán)境下，數(shù)據(jù)報頭的五元組信息不會被更改9關(guān)聯(lián)分析法-原理3應(yīng)用層關(guān)鍵字段關(guān)聯(lián)由于應(yīng)用層數(shù)據(jù)是端系統(tǒng)來處理的，因此絕大多數(shù)的中間設(shè)備在轉(zhuǎn)發(fā)數(shù)據(jù)包時，僅僅會針對數(shù)據(jù)包的鏈路層、網(wǎng)絡(luò)層和傳輸層的信息進行更改一般不會對應(yīng)用層的數(shù)據(jù)進行修改。我們可以利用這個應(yīng)用層數(shù)據(jù)的一些特征進行關(guān)聯(lián)。10關(guān)聯(lián)分析法-應(yīng)用范圍對比分析前應(yīng)用交互的關(guān)聯(lián)多層架構(gòu)的業(yè)務(wù)應(yīng)用中的關(guān)聯(lián)分析11案例案例1-國稅防火墻案例2-地稅網(wǎng)上申報業(yè)務(wù)系統(tǒng)故障12案例1-故障環(huán)境說明：1、客戶端的默認網(wǎng)關(guān)是主路由器2、主路由上設(shè)置了相應(yīng)的策略，凡是的應(yīng)用均交由備路由處理3、備路由上會將訪問國家局的網(wǎng)段指向國家局路由4、核心與路由間均部署防火墻，防火墻工作在透明模式下5、客戶端訪問服務(wù)器的數(shù)據(jù)流走向比較復(fù)雜，看演示思考：服務(wù)器回包的數(shù)據(jù)流走向是如何的？13案例1-故障現(xiàn)象省局到國家局的FTP服務(wù)很慢，一般需要40多秒才可以登陸上去，有時根本登陸不上去Ping測試延時很小省局到國家局的HTTP應(yīng)用正常14案例1-前期簡單分析Ping延時很小，說明網(wǎng)絡(luò)層的延時很正常網(wǎng)絡(luò)環(huán)境復(fù)雜，數(shù)據(jù)流走向復(fù)雜，數(shù)據(jù)包來回路徑不一致，中間經(jīng)過2臺防火墻，可能存在狀態(tài)檢測的問題HTTP的數(shù)據(jù)流走向跟FTP的數(shù)據(jù)流走向應(yīng)該是一樣的，HTTP正常，F(xiàn)TP不正常，說明這個跟TCP的狀態(tài)檢測無關(guān)，應(yīng)該是FTP應(yīng)用層的問題暫時沒什么頭緒，只能先從客戶端下手，進行抓包分析，看看大體的情況15案例1-登陸不上時的數(shù)據(jù)包分析TCP三次握手建立連接S響應(yīng)：winsockreadyC輸入用戶名C用戶名第一次重傳2.9S的延時S的第一次重傳S的第二次重傳C用戶名第二次重傳C用戶名第三次重傳S的第三次重傳C用戶名第四次重傳S：用戶名ok，需密碼C輸入密碼S：超時關(guān)閉S“需密碼”重傳C重傳密碼5.9S的延時12S的延時23.9S的延時23.9S的延時6S的延時15.8S的延時C對”S第一次重傳“的確認C對”S第二次重傳“的確認C對”S第三次重傳“的確認16案例1-登陸成功，但是很慢的數(shù)據(jù)包分析TCP三次握手建立連接S響應(yīng)：winsockreadyC輸入用戶名C用戶名第一次重傳C用戶名第二次重傳C對”S第一次重傳“的確認C對”S第二次重傳“的確認S的第一次重傳S的第二次重傳S：用戶名ok，需密碼S“需密碼”第一次重傳C輸入密碼C密碼第一次重傳C密碼第二次重傳S“需密碼”第二次重傳C密碼第三次重傳S：登陸成功29.9S的延時23.9S的延時11.9S的延時5.8S的延時2.8S的延時17案例1-交互過程示意圖用戶名請求用戶名請求用戶名用戶名請求用戶名請求用戶名用戶名請求用戶名請求用戶名請求用戶名請求用戶名S：winsockreadyC輸入用戶名C用戶名第一次重傳C用戶名第二次重傳S的第一次重傳S的第二次重傳S的第三次重傳結(jié)論：客戶端傳輸用戶的數(shù)據(jù)包被中間設(shè)備丟掉了！18定位是什么設(shè)備丟包對比分析法：通過抓取中間設(shè)備進出口的數(shù)據(jù)包，結(jié)合數(shù)據(jù)包內(nèi)IPID、五元組、內(nèi)容等信息來判斷是否屬于同一會話，是否有數(shù)據(jù)包被丟棄雙網(wǎng)卡筆記本安裝科來開啟兩個工程，分別針對中間設(shè)備進出口抓包TAPTAP其實我們也可以利用中間設(shè)備本身自帶的抓包功能進行分析和定位，具體可以參考我以前寫的PPT：《疑難故障解決實例》通過此種方法，我們定位出是防火墻丟包！19案例1-防火墻丟包原因分析TIPS:防火墻中的兩個概念狀態(tài)檢測：深度檢測：原因分析：1，數(shù)據(jù)包來回路徑肯定是不一致的，那么對于基于狀態(tài)檢測的防火墻，是不會建立TCP連接的但是HTTP應(yīng)用正常，抓包顯示FTP三次握手的過程也很正常，說明跟TCP狀態(tài)檢測無關(guān)2，抓包分析我們可以發(fā)現(xiàn)被丟棄的包都是FTP傳輸用戶名和密碼的包，這個肯定屬于FTP應(yīng)用層的包，防火墻丟棄FTP應(yīng)用層的數(shù)據(jù)包，那么問題應(yīng)該就出在防火墻的FTP應(yīng)用層檢測上20案例1-故障解決故障解決：1，在防火墻上取消FTP應(yīng)用綁定，讓防火墻不要對FTP的數(shù)據(jù)包進行深度的過濾和檢測2，測試，F(xiàn)TP登陸正常思考：除了在防火墻上取消針對FTP應(yīng)用的應(yīng)用層深度檢測功能外，還有其他的解決方式嗎？提示：大家注意數(shù)據(jù)包中的ICMP重定向報文21案例2-故障環(huán)境說明:1，網(wǎng)上申報服務(wù)器的地址是，經(jīng)過網(wǎng)閘后轉(zhuǎn)換為X.X.16.73；2，前置機的IP地址為X.X.16.56，征管服務(wù)器的IP地址為X.X.16.200。業(yè)務(wù)訪問流程：1，納稅人通過互聯(lián)網(wǎng)登陸網(wǎng)上申報服務(wù)器，提交相關(guān)納稅信息；2，網(wǎng)上申報服務(wù)器將這些納稅信息轉(zhuǎn)發(fā)給前置機的同時，將相關(guān)信息寫入征管服務(wù)器數(shù)據(jù)庫；3，網(wǎng)上申報服務(wù)器與前置機的數(shù)據(jù)交互出現(xiàn)問題，那么網(wǎng)上申報服務(wù)器會將征管服務(wù)器數(shù)據(jù)庫相關(guān)的信息鎖死拓撲：22案例2-故障現(xiàn)象故障現(xiàn)象：1，網(wǎng)上申報業(yè)務(wù)系統(tǒng)運行時，每天總有一部分納稅人的申報表單數(shù)據(jù)無法正常上傳，可以通過征管服務(wù)器的業(yè)務(wù)軟件看到這些用戶的申報數(shù)據(jù)處于鎖狀態(tài)；2，在沒有網(wǎng)閘的情況下，網(wǎng)上申報服務(wù)器與前置機直接通訊，則故障現(xiàn)象消失，網(wǎng)上納稅全部正常。23案例2-故障分析前期分析1，結(jié)合故障現(xiàn)象與業(yè)務(wù)流程，我們可以清晰的發(fā)現(xiàn)，問題應(yīng)該就是出現(xiàn)在網(wǎng)上申報服務(wù)器經(jīng)過網(wǎng)閘的地址轉(zhuǎn)換后與前置機交互的過程。2，在網(wǎng)上申報服務(wù)器不通過網(wǎng)閘的地址轉(zhuǎn)換而是直接與前置機交互的時候，業(yè)務(wù)應(yīng)用一切正常，那么，是網(wǎng)閘在做地址轉(zhuǎn)換的時候?qū)δ承?shù)據(jù)報文做了修改或者是網(wǎng)閘直接丟棄了某些業(yè)務(wù)報文導(dǎo)致的故障嗎？3，網(wǎng)閘是最為可疑的故障關(guān)鍵點，我們決定在網(wǎng)閘前后部署網(wǎng)絡(luò)分析系統(tǒng)（在此環(huán)境下，可直接在申報服務(wù)器上和前置機上分別安裝網(wǎng)絡(luò)分析系統(tǒng)），對網(wǎng)上申報業(yè)務(wù)數(shù)據(jù)交互過程分別進行抓包，如下圖所示：

24數(shù)據(jù)分析-發(fā)現(xiàn)異常TCP會話我們通過科來網(wǎng)絡(luò)分析系統(tǒng)捕獲前置機交互的數(shù)據(jù)包，一段時間后，我們在“TCP會話”視圖中，發(fā)現(xiàn)有幾個TCP會話持續(xù)的時間比一般的TCP會話長很多，如下圖所示：

這幾個TCP會話持續(xù)的時間均超出其他的會話很多25異常會話交互過程分析網(wǎng)閘地址73首先發(fā)送RESET報文網(wǎng)閘地址向前置機發(fā)送（重傳）報文，前置機直接發(fā)送RESET報文重置連接。這個過程，導(dǎo)致了該TCP會話持續(xù)時間很長。26第一個reset報文解碼這個數(shù)據(jù)報文的源MAC地址并非網(wǎng)閘的MAC，真實的網(wǎng)閘MAC地址是00:40:63:EF:43:DF

為什么網(wǎng)閘的MAC發(fā)生了變化？難道網(wǎng)內(nèi)存在會話劫持？27查看整個交互過程的MAC變化網(wǎng)閘源MAC為00:40:63:EF:43:DF前置機發(fā)往網(wǎng)閘的確認數(shù)據(jù)報文，封裝的目的MAC卻是00:21:5E:82:AF:86MAC為00:21:5E:82:AF:86的設(shè)備以網(wǎng)閘的IP向前置機發(fā)送RESET報文在交互的過程中，前置機將發(fā)給網(wǎng)閘地址的確認報文，封裝了一個非網(wǎng)閘的MAC地址00:21:5E:82:AF:86，為什么會突然出現(xiàn)了這種改變呢？28前置機封裝錯誤目的MAC的原因InternetAddressPhysicalAddressTypeX.X.16.7300-21-5E-82-AF-86dynamicTIPS：ARP表的更新實際環(huán)境中，只有同時滿足以下兩個條件時，設(shè)備的ARP表項才會更新：1，設(shè)備收到來自某IP的ARP請求包或免費ARP包；2，設(shè)備的現(xiàn)有ARP表項中已經(jīng)存在該IP對應(yīng)的ARP表項。其他的非ARP報文不會對設(shè)備的ARP表項產(chǎn)生影響。一般而言，主機是根據(jù)其ARP表項來封裝要發(fā)送的數(shù)據(jù)報文的目的MAC地址，那么，這里前置機發(fā)往網(wǎng)閘數(shù)據(jù)報文的目的MAC地址出現(xiàn)改變是否是因為前置機的ARP表項內(nèi)容變化了呢？我們在前置機的DOS窗口下，使用arp–a命令查看異常時的arp表項內(nèi)容，發(fā)現(xiàn)網(wǎng)閘IP對應(yīng)的MAC地址的確變成了00:21:5E:82:AF:86。29前置機ARP表更新的原因我們在科來網(wǎng)絡(luò)分析系統(tǒng)的“數(shù)據(jù)包”視圖查看交互過程的所有數(shù)據(jù)報文

來自MAC地址為00-21-5E-82-AF-86的ARP響應(yīng)到達了前置機，前置機更新其ARP表項

前置機向網(wǎng)絡(luò)中發(fā)送ARP請求，請求網(wǎng)閘IP對應(yīng)的MAC前置機在收到來自網(wǎng)閘的數(shù)據(jù)報文之后，都向00-21-5E-82-AF-86地址發(fā)送確認報文30網(wǎng)閘、前置機以及未知設(shè)備的數(shù)據(jù)交互情況和狀態(tài)變化31網(wǎng)絡(luò)分析學(xué)習(xí)相關(guān)資料《TCP/IP詳解卷1》《Advanced.Network.Analysis.Techniques》LauraChappell《snifferuniversity》sniffer大學(xué)培訓(xùn)課程