陳 旖 張美璟 許發(fā)見

(福建警察學(xué)院計算機(jī)與信息安全管理系 福建 福州350007)

0 引 言

近年來，移動互聯(lián)網(wǎng)發(fā)展迅猛，截至2019年2月，中國手機(jī)網(wǎng)民規(guī)模達(dá)8.17億，網(wǎng)民中使用手機(jī)上網(wǎng)人群的占比為98.6%[1]。相比于傳統(tǒng)的桌面計算機(jī)，在使用場景上，手機(jī)更貼近生活環(huán)境，使用頻率高，移動范圍廣；在信息類型上，手機(jī)蘊(yùn)含更多的個人信息；在軟件種類上，手機(jī)以移動應(yīng)用(App)為主。其中，手機(jī)上安裝的移動應(yīng)用App的類型及使用頻率在用戶畫像刻畫[2]、用戶習(xí)慣研究[3]方面具有較高的價值。例如：頻繁使用購物App的用戶往往被打上購買欲強(qiáng)的標(biāo)簽；反復(fù)開啟同類購物軟件，可能反映出某類用戶存在比價習(xí)慣等。因此，對手機(jī)上安裝的App類型與使用頻率進(jìn)行識別和統(tǒng)計，可以為進(jìn)一步的數(shù)據(jù)挖掘提供數(shù)據(jù)，具有很好的參考價值。

然而，移動互聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)量極為龐大，如果采用離線識別的方式進(jìn)行分析，需占用大量的存儲空間并消耗大量的帶寬進(jìn)行文件傳輸。如果采用在線實時分析，則需要在網(wǎng)絡(luò)設(shè)備上直接處理數(shù)據(jù)，而常見的網(wǎng)絡(luò)設(shè)備往往計算能力受限，因此要求識別方法應(yīng)避免占用過多的系統(tǒng)資源。

針對移動App識別的問題，文獻(xiàn)[4]提出了一種通過HTTP報文user-agent字段進(jìn)行識別的方法，但由于多數(shù)應(yīng)用并未遵循規(guī)范，未使用該字段標(biāo)記自身類型，使得該方法目前可用性較低。文獻(xiàn)[5]提出了一種基于視覺感知特性的應(yīng)用識別方法，其采用HTTP報文的頭域和請求信息作為輸入構(gòu)建樣本圖像，再將其輸入二維卷積感知網(wǎng)絡(luò)模型進(jìn)行分類器訓(xùn)練。該方法對流量樣本有較好的適應(yīng)性，但其計算量大，需采樣后再進(jìn)行離線計算。文獻(xiàn)[6]提出了一種基于模式匹配的識別方法，其使用HTTP報文的Host、URI、cookie等字段構(gòu)建樣本庫，并使用模式匹配算法對未知報文進(jìn)行分類。該方案需要進(jìn)行深度包檢測來讀取HTTP字段，然而當(dāng)前App開發(fā)已逐步使用加密的HTTPS協(xié)議來取代HTTP協(xié)議，這使得該方案無法讀取到對應(yīng)的HTTP字段，導(dǎo)致其可用性變?nèi)酢?/p>

基于上述研究，本文提出一種適用于資源受限的網(wǎng)絡(luò)設(shè)備的App識別方法。利用App運行時會訪問特定域名集合的特性來進(jìn)行識別，可支持使用HTTPS的App。該方法設(shè)計了一套輕量級的轉(zhuǎn)換機(jī)制，可將采集到的報文數(shù)據(jù)流轉(zhuǎn)換為對應(yīng)的低維度向量，再將向量作為支持向量機(jī)的輸入進(jìn)行訓(xùn)練和識別。另一方面，為避免占用過多的系統(tǒng)資源，方法使用了布隆過濾器來過濾無關(guān)IP地址，并設(shè)計了背景流量過濾機(jī)制來減少調(diào)用分類器的次數(shù)。這使得方法對系統(tǒng)資源占用小，可實現(xiàn)在運算能力較弱的接入網(wǎng)關(guān)上直接對手機(jī)App進(jìn)行實時在線識別。此外，由于本方法僅使用臨時IP標(biāo)識用戶，可避免App用戶的具體身份信息被泄露。

1 相關(guān)網(wǎng)絡(luò)技術(shù)

隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，當(dāng)前的移動應(yīng)用開發(fā)行業(yè)已經(jīng)形成了較為通用的開發(fā)范式和框架，App使用的網(wǎng)絡(luò)技術(shù)存在普遍的相似性，其典型的訪問過程如圖1所示。

圖1 App訪問服務(wù)器的典型過程

典型場景下，智能手機(jī)安裝有多款A(yù)pp，App在啟動時會主動與遠(yuǎn)程服務(wù)器通信。App代碼中使用域名標(biāo)識服務(wù)器，App會先通過操作系統(tǒng)來訪問DNS服務(wù)器以獲取目標(biāo)服務(wù)器的IP地址，再與其建立TCP連接，最后根據(jù)業(yè)務(wù)邏輯進(jìn)行Web訪問。經(jīng)過對多款主流App報文的深入分析，可以進(jìn)一步總結(jié)出以下特點。

(1) App普遍使用HTTP/HTTPS協(xié)議與遠(yuǎn)程服務(wù)器通信。其中，HTTP使用明文傳輸，而HTTPS使用SSL/TSL協(xié)議對報文進(jìn)行加密，可以抵抗深度報文檢測。隨著安全性需求的提升，目前HTTPS協(xié)議以被廣泛應(yīng)用于App開發(fā)。

(2) App代碼中使用域名來標(biāo)記服務(wù)器，而非IP地址。服務(wù)器使用域名提供服務(wù)地址，可以對外部屏蔽云端服務(wù)器的網(wǎng)絡(luò)IP地址出現(xiàn)變化的情況。例如：服務(wù)器可以提供多個網(wǎng)絡(luò)運營商的IP地址，以優(yōu)化不同網(wǎng)絡(luò)用戶的訪問速度；服務(wù)器也可以主動改變域名/IP地址的映射關(guān)系，來實現(xiàn)對服務(wù)器集群的負(fù)載均衡等。

(3) App依賴操作系統(tǒng)進(jìn)行DNS訪問，可直接使用對應(yīng)API，傳入域名來獲得IP地址，而無須自己維護(hù)域名/IP的映射關(guān)系。操作系統(tǒng)從API收到查詢請求之后，將先在DNS緩存中查找，若存在緩存則直接返回對應(yīng)IP；若未找到，則向DNS服務(wù)器請求目標(biāo)域名的IP地址，再返回給App。DNS服務(wù)器通過DNS響應(yīng)報文來回復(fù)域名相關(guān)的信息，典型響應(yīng)報文結(jié)構(gòu)如圖1所示，其報文中描述了域名“wvcfg.alicdn.com(阿里巴巴緩存服務(wù)器)”的信息，包含該域名的別名、多個可用的IP地址、管理機(jī)構(gòu)數(shù)據(jù)、附加信息等。系統(tǒng)將這些信息加入DNS緩存中，并根據(jù)網(wǎng)絡(luò)變動或超時等策略更新信息。

(4) App與服務(wù)器域名及服務(wù)器IP之間呈現(xiàn)多對多的關(guān)系。一方面，不同App訪問的服務(wù)器域名存在重疊。這是由于App開發(fā)中往往會使用到其他廠商的服務(wù)，例如：打車軟件使用地圖廠商提供的定位與導(dǎo)航SDK；部分App使用了微博、微信的第三方登錄接口等。其結(jié)構(gòu)類似于圖1中App1和App2都訪問了共同的域名。另一方面，域名和IP也并非一一對應(yīng)。第一，大多數(shù)域名存在多個可用的IP地址，如圖1的DNS報文所示；第二，不同域名的服務(wù)器也可能共用相同的IP地址，例如，高并發(fā)的App普遍使用第三方廠商提供的內(nèi)容分發(fā)網(wǎng)絡(luò)(Content Delivery Network,CDN)來加速數(shù)據(jù)傳輸。CDN緩存服務(wù)器雖對不同App提供了不同的域名，但實際指向了相同IP地址的緩存服務(wù)器。其結(jié)構(gòu)類似圖1中App1和App2分別訪問了獨立的域名b和域名c，但實際上都訪問了IP地址B所對應(yīng)的服務(wù)器集群。

根據(jù)上述分析，由于App間訪問的域名存在重合且域名和IP并非一一對應(yīng)，網(wǎng)關(guān)雖然無法直接通過IP地址識別到特定App，但可以根據(jù)App訪問指定域名的特性及域名和IP的關(guān)系，從一系列報文的IP地址中推測出對應(yīng)的App。本文方法基于這一特征進(jìn)行設(shè)計。

2 方法和模型

2.1 系統(tǒng)建模

2.1.1應(yīng)用場景

本文方法典型的應(yīng)用場景如圖2所示。在典型的中大型企業(yè)網(wǎng)及校園網(wǎng)中，往往存在核心層、匯聚層、接入層三層結(jié)構(gòu)。核心層一般使用高吞吐、高性能和高可用的大型核心交換機(jī)構(gòu)成，用于內(nèi)部主干網(wǎng)之間的通信，以及內(nèi)網(wǎng)與外網(wǎng)間的通信；匯聚層主要用于將眾多的接入層設(shè)備連入核心層；接入層直接面向終端設(shè)備提供網(wǎng)絡(luò)接入服務(wù)。由于終端設(shè)備數(shù)量眾多，因此接入層設(shè)備一般數(shù)量較大，且價格低廉、功耗低、運算能力弱。

圖2 典型應(yīng)用場景

本方法適合部署于接入層設(shè)備，其優(yōu)勢在于：① 可充分利用大量輸入層設(shè)備的剩余算力，無須部署獨立的運算服務(wù)器；② 采用分布式運算，避免單點集中式運算中出現(xiàn)運算性能、網(wǎng)絡(luò)吞吐等瓶頸；③ 核心層、匯聚層對性能、可靠性有較高要求，在接入層增加非關(guān)鍵性的功能對網(wǎng)絡(luò)整體的影響較小。

由于接入層設(shè)備的運算和內(nèi)存資源往往受到限制，因此在方法設(shè)計中需要避免占用過多的系統(tǒng)資源。

2.1.2模型訓(xùn)練與應(yīng)用過程

本文方法分為兩個步驟進(jìn)行：第一步采集樣本數(shù)據(jù)，并在計算機(jī)上訓(xùn)練模型并生成參數(shù)；第二步將訓(xùn)練得到的模型及參數(shù)部署到實際的接入層設(shè)備上，并進(jìn)行相應(yīng)指標(biāo)評估。

模型訓(xùn)練的過程如圖3所示。首先需要從環(huán)境中采集目標(biāo)App的通信樣本集合，以及其他無關(guān)App的通信樣本作為背景流量樣本。接著，從通信樣本中過濾出DNS報文，并解析生成域名/IP地址的映射表和域名集合。再根據(jù)樣本報文的IP地址，將App樣本中所有報文映射到域名集合中，從而將一個樣本文件生成一個對應(yīng)的向量。向量的每個維度對應(yīng)一個域名，其大小表示樣本中訪問該域名的次數(shù)。由于生成的向量維度很高，本文方法基于Jaccard包相似度設(shè)計了一種降維算法，用于對樣本向量進(jìn)行降維。經(jīng)過降維后的樣本向量集合再作為訓(xùn)練集輸入支持向量機(jī)(Support vector machine,SVM)進(jìn)行分類訓(xùn)練。另外，本文還設(shè)計了一種背景報文過濾器，以降低方法對系統(tǒng)計算資源的占用。在訓(xùn)練過程結(jié)束之后，將輸出域名/IP映射表、降維算法參數(shù)、背景報文過濾器參數(shù)、SVM分類器模型參數(shù)，供識別過程使用。

圖3 模型訓(xùn)練流程

識別的過程如圖4所示。在接入設(shè)備上，識別程序循環(huán)抓取報文，如果抓取到DNS報文，則解析報文并更新域名/IP映射表。如果抓取到通信報文，則將其IP地址使用布隆過濾器檢查，如果其IP地址屬于某個域名，則將其加入到滑動窗口隊列中。識別程序周期性地將滑動窗口中的報文映射到域名集合，并進(jìn)行降維，得到待檢測的向量。再將向量使用背景報文過濾器進(jìn)行檢查，如果檢查通過再使用SVM分類器進(jìn)行分類，得到分類結(jié)果。

圖4 運行中識別流程

2.2 樣本采集和數(shù)據(jù)變換

2.2.1報文樣本采集

在樣本采集環(huán)境中，存在一臺運行嵌入式Linux系統(tǒng)的無線網(wǎng)關(guān)、一臺安卓智能手機(jī)、一臺通用計算機(jī)。其中，安卓智能手機(jī)通過Wi-Fi連接無線網(wǎng)關(guān)，使用USB線連接計算機(jī)，并開啟USB調(diào)試模式，且禁止后臺App運行；計算機(jī)通過網(wǎng)線連接網(wǎng)關(guān)，可使用SSH協(xié)議登錄網(wǎng)關(guān)的控制臺，并可通過安卓調(diào)試橋(Android Debug Bridge tools，ADB)連接上安卓手機(jī)的開發(fā)調(diào)試服務(wù)。

對App采樣時，計算機(jī)先通過控制臺命令，在網(wǎng)關(guān)上使用抓包工具TCPDUMP對無線接口進(jìn)行抓包，再通過ADB命令觸發(fā)待采樣的App運行。待抓包結(jié)束之后，計算機(jī)通過命令控制TCPDUMP工具停止抓包并生成cap格式的抓包文件，再使用ADB命令控制手機(jī)關(guān)閉App進(jìn)程。對該App的采樣到此結(jié)束，計算機(jī)在進(jìn)行延時等待后，將對下一App進(jìn)行采樣。在對所有App完成報文采樣后，計算機(jī)將把抓包文件下載到本地。

本文針對安卓市場上不同類別且下載量較大的50款A(yù)pp進(jìn)行采樣，在不同的時間點，共采樣40輪。將其中30輪作為訓(xùn)練樣本，其他10輪作為測試樣本。

2.2.2數(shù)據(jù)探索與預(yù)處理

使用分析工具Wireshark對采集的樣本文件進(jìn)行數(shù)據(jù)探索，可以發(fā)現(xiàn)App通信樣本中存在共性。本方法根據(jù)這些共性，制定出如下幾項樣本預(yù)處理的規(guī)則：

(1) 以握手報文數(shù)量作為訪問服務(wù)器頻繁程度的度量。App每次啟動時，TCP的握手報文數(shù)量一般大致相同。這是因為App會與哪些服務(wù)器通信、將創(chuàng)建幾個TCP連接通信，都是程序中固化的。而App的通信報文數(shù)量不穩(wěn)定，這是因為App的緩存更新功能往往是周期性執(zhí)行的，更新周期及數(shù)據(jù)大小差異等原因，都導(dǎo)致通信數(shù)據(jù)量并不穩(wěn)定。

因此，本文方法在統(tǒng)計App與某個服務(wù)器之間的通信報文數(shù)量時，僅統(tǒng)計其中TCP握手報文個數(shù)。

(2) 統(tǒng)計握手報文的時間范圍為10秒。啟動過程中，App往往先顯示啟動圖片，同時與服務(wù)器進(jìn)行頻繁的通信。大部分的TCP握手報文都集中在首個握手報文發(fā)出后的10秒內(nèi)發(fā)出。因此，本方法選取App啟動后，首個握手報文發(fā)出后的10秒內(nèi)的握手報文進(jìn)行統(tǒng)計。

(3) App以一組10個為單位進(jìn)行分組識別?，F(xiàn)實環(huán)境中，App類型繁多。若把所有待測App一起進(jìn)行分類訓(xùn)練，將大大增加訓(xùn)練的難度，影響模型分類質(zhì)量。

為解決上述問題，本文方法將App進(jìn)行分組訓(xùn)練。首先將待分類的App按10個一組進(jìn)行分組，得到數(shù)據(jù)集F={F1,F2,…,FI},共I組數(shù)據(jù)組，若出現(xiàn)App數(shù)量不足一組時，則填充全0的樣本。若使用F1數(shù)據(jù)來訓(xùn)練模型時，則待檢測App組成的數(shù)據(jù)集為FApp={F1}，而其他App樣本則作為無關(guān)的背景報文組成數(shù)據(jù)集FBG={F2,F3，…,FI}。在訓(xùn)練過程中，F(xiàn)1-FI將迭代作為FApp訓(xùn)練模型，最終生成多組模型參數(shù)。在檢測階段，待分類的數(shù)據(jù)可被多組不同參數(shù)的模型進(jìn)行分類，進(jìn)而得到分類結(jié)果。

按上述分組策略，本文方法以組為單位處理數(shù)據(jù)。故可將采集的50款A(yù)pp樣本分為F1-F5共5組。其中F1包含A0-A9共10款應(yīng)用，分別為淘寶、支付寶等常用App。在后續(xù)內(nèi)容中，以F1為例展示一組數(shù)據(jù)的處理效果。即以F1作為FApp，以F2-F5作為FBG。

2.2.3樣本數(shù)據(jù)變換

處理報文樣本時，首先遍歷集合FApp中所有樣本文件，從DNS報文中解析所有域名，再剔除未被訪問域名，從而生成域名集合N={n1,n2,…,nx}，以及域名/IP的映射表。之后，再獨立解析FApp中每個樣本文件，先將文件中首個握手報文出現(xiàn)的10秒內(nèi)的所有握手報文過濾出來，再將握手報文訪問的IP地址輸入域名/IP映射表，得到報文訪問的域名，并將對應(yīng)域名的統(tǒng)計值加1。處理結(jié)束后，每個文件都會生成一個數(shù)據(jù)記錄。定義向量d=(Cn1,Cn2,…,Cnx)來表示該數(shù)據(jù)記錄。其中，Cnx表示該樣本中App向域名nx發(fā)出的握手報文個數(shù)。如果將每個域名nx看作一個軸，則Cn1-Cnx可以看作樣本在各個軸上投影的值。故可以將樣本文件生成的記錄用向量d來表示，其維度等于域名集合N的元素個數(shù)。

由于FApp中包含十類不同App，可將App按類別使用A0-A9進(jìn)行編號，并使用DA0來表示A0類樣本生成的向量d組成的集合。則FApp中所有文件處理完成之后，最終將生成集合DApp={DA0,DA1,…,DA9}。

圖5直觀地展示了DApp中數(shù)據(jù)的分布特點，其數(shù)據(jù)來源于淘寶、支付寶等10款常見的App。其中，橫軸上的每個點分別對應(yīng)集合N中的一個域名nx；縱軸上的一個點分別對應(yīng)DA0-DA9中的一個向量d；橫軸與縱軸交匯點的灰度值表示樣本向量d在域名nx上的映射值Cnx，也反映出該樣本對域名nx訪問的頻繁程度。

圖5 App訪問域名的分布特點

可以看出，同類型App生成的向量d相似度高，而不同類型App生成的向量d差異較大。不同類型App訪問的域名存在少量重合。

2.3 降維與過濾背景流量

2.3.1降 維

從數(shù)據(jù)探索中可以看出，App樣本生成的向量d的維度較高，其數(shù)值約在100～200之間。向量d的維度過高將導(dǎo)致運算量大且內(nèi)存占用多。因此，需要對d做降維。

常見的降維方法有主成分分析(PCA)等。PCA技術(shù)可用于對高維空間下的點進(jìn)行分析，得到新的若干條最關(guān)鍵的坐標(biāo)軸。原始的高維數(shù)據(jù)可以投影到這些關(guān)鍵的坐標(biāo)軸上得到新的數(shù)據(jù)。這些新的數(shù)據(jù)的維度較小，并能較好地體現(xiàn)原有數(shù)據(jù)的特征[7]。

以圖5中的A0-A9進(jìn)行實驗，將集合DApp中所有的向量d組成矩陣M。其中，矩陣M的行數(shù)等于樣本數(shù)量，由于存在10個App，每個App有30個樣本，故共有300行；矩陣列數(shù)為向量d的維度，為157。使用PCA對M進(jìn)行降維，保留90%的信息，得到降維后的矩陣M的列數(shù)為26。若再繼續(xù)降低保留的信息量，則出現(xiàn)降維效果增加緩慢，而特征損失增加較快的情況。這將導(dǎo)致樣本信息損失較多?？紤]到網(wǎng)絡(luò)設(shè)備的內(nèi)存和運算能力較弱，使用分類器對26維的數(shù)據(jù)進(jìn)行運算對系統(tǒng)性能影響依舊較大。因此，由于應(yīng)用環(huán)境的限制，PCA技術(shù)不是本文方法最佳的降維方案。

在考慮了設(shè)備運算能力和實際數(shù)據(jù)特征的基礎(chǔ)上，本文設(shè)計了一種基于Jaccard包相似度的降維算法。在PCA技術(shù)中，算法會從數(shù)據(jù)中尋找最佳的數(shù)據(jù)軸。而在本環(huán)境的數(shù)據(jù)中，已知矩陣M中存在10類App樣本，且同類App樣本之間相似度高。因此，本算法新建立一個10維的空間，空間中的軸分別代表A0-A9十類App，各軸之間相互正交。原數(shù)據(jù)向量d轉(zhuǎn)換到新空間上的向量j的轉(zhuǎn)換過程可分為兩步處理：

(1) 由樣本報文變換得到的樣本向量集合DApp={DA0,DA1,…,DA9}來計算各App的樣本向量均值集合Dmeans=(dA0-means,dA1-means,…,dA9-means)。計算過程即將同類App的樣本向量進(jìn)行向量加法運算后，除以樣本數(shù)量。設(shè)某個編號為Ay的App存在樣本集合DAy，集合中包含d0-dk共k個樣本向量，則該App的樣本向量的均值dAy-means=(d0+d1+…+dk)/k。

(2) 使用Jaccard包算法計算待測向量dx與Dmeans中每一類App的樣本向量均值的相似度Sy。該算法以兩個集合的交集除以并集來計算其相似度。其中，以某個元素在兩個集合出現(xiàn)的最小次數(shù)作為其在交集中的個數(shù)；以某個元素在兩個集合中出現(xiàn)的最大次數(shù)作為其在并集中的個數(shù)。運算時，可將向量的一個維度視作集合中的一種元素，將該維度的數(shù)值視作對應(yīng)集合元素出現(xiàn)的次數(shù)。可定義函數(shù)INTER和UNION用于計算兩個向量的交集與并集，則dx與dAy-means的相似度Sy=INTER(dx,dAy-means)/UNION(dx,dAy-means)。將dx分別與dA0-means-dA9-means進(jìn)行計算后，即可得到降維后的向量j=(S0,S1,…,S9)。

轉(zhuǎn)換前的dx和dAy-means的維度均等于域名集合N的元素個數(shù)，轉(zhuǎn)換后的向量j的維度固定為10。該降維算法的可解釋性也較好。其轉(zhuǎn)換過程可視為計算待測點到樣本均值之間的相似度，其數(shù)值范圍在[0，1]之間，同時完成了數(shù)據(jù)歸一化的操作。

圖6直觀展示轉(zhuǎn)換后的數(shù)據(jù)，其中：橫軸表示新空間中A0-A9十類App對應(yīng)的數(shù)據(jù)軸；縱軸表示樣本點與對應(yīng)軸的相似度。圖中每條線表示某一類App的樣本點在某個軸上映射出的相似度數(shù)值。

圖6 樣本降維效果

可以看出，一類App的樣本在代表自身類別的軸上的映射的數(shù)據(jù)值較大，在其他軸上的映射的數(shù)值較小。同類樣本點在特定軸上映射的數(shù)值分布在一定區(qū)間內(nèi)，該特征可被分類器用于識別App類型。

2.3.2過濾背景流量

在移動互聯(lián)網(wǎng)環(huán)境中，數(shù)量龐大的App時時刻刻都在生成通信報文，這些報文中僅有少量屬于待識別App生成的報文。相對于待識別的App生成的報文，其他App的生成的報文構(gòu)成了背景流量。背景流量的報文數(shù)量龐大，如果都輸入到分類器進(jìn)行判斷，將占用大量的運算資源來處理無關(guān)數(shù)據(jù)流量。因此，本文設(shè)計了一種背景報文過濾機(jī)制來降低背景報文造成的運算資源消耗。

為探索目標(biāo)App報文和背景流量報文的分布特點，可構(gòu)造出圖7進(jìn)行分析，其中：橫軸表示A0-A9對應(yīng)的數(shù)據(jù)軸；縱軸表示樣本點與對應(yīng)軸的相似度。圖中深色點為待檢測的樣本點，淺色點為背景報文樣本在對應(yīng)軸上映射出的相似度數(shù)值。背景報文樣本的生成過程，即從背景報文數(shù)據(jù)集FBG中隨機(jī)選取200個樣本，再將樣本進(jìn)行數(shù)據(jù)轉(zhuǎn)換并降維，降維后的向量值即樣本點映射到各軸上的相似度數(shù)值。

圖7 目標(biāo)App報文和背景流量報文的分布情況

可以看出，某類App的報文樣本在代表自身類型的軸上的映射的數(shù)據(jù)值較大，而背景流量映射出的值較小。過濾機(jī)制將利用這一特性計算出一組閾值，如果樣本在某個維度上的數(shù)值大于閾值，才使用分類器對樣本進(jìn)行分類，否則直接按背景報文處理。本文方法以軸上背景報文樣本的上五分位為閾值，即過濾掉后80%的背景報文。各軸對應(yīng)的閾值如圖7中的虛線所示，可以看出，僅20%的背景流量和屬于目標(biāo)App的樣本能通過閾值過濾。

2.4 SVM訓(xùn)練

支持向量機(jī)SVM的基本思想是尋找一個最優(yōu)分類超平面將訓(xùn)練樣本分開[8]。本文方法使用SVM作為分類器對樣本進(jìn)行多分類。在數(shù)據(jù)變化階段中，App和背景流量的樣本已經(jīng)被轉(zhuǎn)換為10維的向量。訓(xùn)練時，將向量的每個維度的數(shù)值按序組成數(shù)組，作為訓(xùn)練輸入；而向量對應(yīng)的樣本類型作為訓(xùn)練輸出，將App樣本按類別使用數(shù)字0至9進(jìn)行標(biāo)識。實驗中發(fā)現(xiàn)，若所有背景樣本共用單一類別時，分類準(zhǔn)確率較低；而每5～6種背景樣本共用一種類別時，準(zhǔn)確率較高。故采用經(jīng)驗值，將每6類背景樣本共用一個大于9的數(shù)值標(biāo)識。數(shù)據(jù)集中存在500個樣本，其中含10類App作為識別目標(biāo)，共300個；含40類App作為背景流量，共200個。

訓(xùn)練時，將數(shù)據(jù)集使用十折交叉驗證法來劃分訓(xùn)練集和測試集，采用C_SVC類型的SVM分類器，使用一對一法(One-versus-one,OVO)來實現(xiàn)多分類。相比于一對多法(One-versus-rest,OVR)，在App版本更新時，OVO可避免對所有的分類器進(jìn)行重新訓(xùn)練。

2.5 使用模型進(jìn)行識別

相比于樣本采集及訓(xùn)練的過程，使用模型識別的過程還需要增加以下工作：

(1) 使用滑動窗口生成待測樣本。在樣本采集中，App啟動和抓包時間是人為控制的，而在實際的環(huán)境中，App啟動時間是未知的。為了從環(huán)境中動態(tài)地生成待測樣本，本文方法設(shè)計了一個滑動窗口?；瑒哟翱趦?nèi)存在一個隊列，用于保存當(dāng)前時間點至前10秒范圍內(nèi)的握手報文。當(dāng)有新報文到達(dá)時，加入隊列頭。窗口存在一個以1秒為周期的定時器，定時器到時時，先刪除隊尾超時的節(jié)點，再遍歷滑動窗口隊列中所有報文，將報文進(jìn)行樣本數(shù)據(jù)轉(zhuǎn)換，得到一個待識別的向量dx。進(jìn)而可對dx進(jìn)行降維、過濾和識別等操作。

(2) 使用布隆過濾器過濾無關(guān)IP。在數(shù)據(jù)探索中發(fā)現(xiàn)，域名/IP映射表中的IP地址數(shù)量約為1 500至2 000個。為避免大量使用無關(guān)IP的報文被加入隊列，本文方法使用布隆過濾器來快速檢查報文的IP是否存在于域名/IP映射表中。布隆過濾器由多個哈希函數(shù)和一個很長的二進(jìn)制數(shù)組組成，可用于快速檢查某個元素是否存在于一個很大的集合中。本文方法的過濾器使用了JSHash、RSHash、SDBMHash、PJWHash四種哈希函數(shù)，二進(jìn)制數(shù)組占用1 250字節(jié)。根據(jù)布隆過濾器的性質(zhì)，假設(shè)哈希函數(shù)能均勻地散列數(shù)據(jù)，有效IP為2 000個的情況下，則有約90.8%的無關(guān)IP可被過濾。

(3) 實時更新域名/IP映射表。根據(jù)對網(wǎng)絡(luò)技術(shù)的分析，域名與IP地址的對應(yīng)關(guān)系是隨著環(huán)境而變化的。從樣本中生成的域名/IP映射表需要根據(jù)運行環(huán)境的變化而更新。因此，本文方法在識別環(huán)境中也需要實時抓取DNS報文，并根據(jù)DNS解析的數(shù)據(jù)來更新映射表。

3 實 驗

3.1 實驗環(huán)境與算法實現(xiàn)

實驗使用一臺基于Mediatek-MT7620芯片方案的無線接入網(wǎng)關(guān)進(jìn)行驗證，其主頻為580 MHz的MIPS架構(gòu)處理器，內(nèi)存為123 MB，支持兩個百兆以太網(wǎng)口，以及2.4 GHz頻段Wi-Fi接入。設(shè)備運行OpenWrt系統(tǒng),該系統(tǒng)是一種適用于嵌入式網(wǎng)絡(luò)設(shè)備的Linux發(fā)行版，具有強(qiáng)大的擴(kuò)展性[9]。

本文方法的代碼實現(xiàn)主要分為兩個部分，第一部分是運行在計算機(jī)端的模型訓(xùn)練程序，使用Python實現(xiàn)；第二部分是運行在無線網(wǎng)關(guān)平臺上的識別程序。由于網(wǎng)關(guān)只能支持C/C++語言編程，故使用C語言實現(xiàn)了識別程序，經(jīng)交叉編譯后部署到設(shè)備上。其中，實時抓包使用了LIBCAP庫[10]，SVM分類器使用了LIBSVM庫[11]的實現(xiàn)。另外，實驗中使用LIBCAP庫編寫了一個報文重放工具，可解析cap格式的抓包文件，并將其中抓取的報文重放到網(wǎng)絡(luò)接口中。

3.2 識別效果評估

為評估模型識別的效果，實驗使用重放工具將測試集對應(yīng)的抓包文件重放到網(wǎng)絡(luò)中，由識別程序進(jìn)行在線識別。因使用十折交叉驗證法測試，故識別程序需分別使用10個SVM模型進(jìn)行識別，重放工具則分別重放10組測試集對應(yīng)的抓包文件。10組交叉驗證共生成500個識別結(jié)果。

識別程序在實驗中的識別效果如圖8所示?？梢钥闯?，程序?qū)δ繕?biāo)App報文的識別效果較好，并可以正確識別出大部分的背景流量，但部分特征和目標(biāo)App相似的背景流量可能會被誤識別為目標(biāo)App?？墒褂脺?zhǔn)確率P來評估識別效果，準(zhǔn)確率P=TP/(TP+FP)，其中TP為分類正確的樣本數(shù)，F(xiàn)P為分類錯誤的樣本數(shù)。則在當(dāng)前的測試集條件下，分類器的識別準(zhǔn)確率約為94.4%。

圖8 識別結(jié)果的混淆矩陣

3.3 資源占用情況評估

為評估本方法對系統(tǒng)資源占用情況，實驗中使用top命令以1秒為周期定時采集識別程序所在進(jìn)程的CPU及內(nèi)存利用率，其結(jié)果如圖9所示?？梢钥闯?，CPU利用率在0～2%之間波動，呈現(xiàn)周期性變化，這和程序?qū)瑒哟翱谶M(jìn)行周期性處理的特性相吻合。程序占用約1 025 KB內(nèi)存，占用率約為0.8%。

圖9 CPU與內(nèi)存占用率

對于網(wǎng)絡(luò)設(shè)備而言，吞吐量指設(shè)備在單位時間內(nèi)發(fā)送的數(shù)據(jù)量，體現(xiàn)了設(shè)備轉(zhuǎn)發(fā)報文的能力，是評估設(shè)備性能的重要指標(biāo)。為評估本方法對設(shè)備轉(zhuǎn)發(fā)性能的影響，設(shè)計了一種壓力測試實驗，該實驗中存在兩臺計算機(jī)分別通過以太網(wǎng)連接實驗網(wǎng)關(guān)，使用網(wǎng)絡(luò)吞吐量測試工具iperf[12]，從一臺計算機(jī)向另外一臺計算機(jī)以TCP連接的最大帶寬發(fā)送數(shù)據(jù)。在以下三個場景中觀察吞吐量的變化：① 識別程序未運行；② 識別程序運行，但環(huán)境中未運行目標(biāo)App；③ 識別程序運行，且環(huán)境中存在待識別App周期性啟動。

實驗結(jié)果如圖10所示，在場景1和場景2中，設(shè)備吞吐量都較為平穩(wěn)，其均值分別為94.06 Mbit/s和93.96 Mbit/s；在場景3中，設(shè)備吞吐量存在小范圍波動，其均值為91.64 Mbit/s，較場景1僅略微降低。

圖10 系統(tǒng)轉(zhuǎn)發(fā)吞吐量

4 結(jié) 語

本文針對當(dāng)前App識別方法運算量較大，難以進(jìn)行在線識別的問題，提出了一種基于域名訪問范圍特征的App實時識別方法。該方法的優(yōu)勢一方面在于其處理速度快，可以做到在線識別，避免了離線識別中抓包文件的存儲和傳輸消耗；另一方面，對系統(tǒng)資源占用較小，可以直接在資源受限的嵌入式網(wǎng)關(guān)中運行。但本文方法也存在不足之處：(1) 部分App進(jìn)行大版本升級后，訪問的域名集合會出現(xiàn)明顯變化，導(dǎo)致識別失??；(2) 同一公司開發(fā)的App訪問的域名較為相似，易產(chǎn)生誤判。這些都是可進(jìn)一步優(yōu)化的問題。除了本文方法收集的信息外，用戶App使用特征還有很多，如用戶年齡段、就職行業(yè)與手機(jī)平臺等，對這些特征的挖掘與分析可作為進(jìn)一步研究的方向。