劉翼 詹宇昊

摘 要： 針對(duì)傳統(tǒng)的網(wǎng)絡(luò)終端識(shí)別方法對(duì)移動(dòng)設(shè)備特征信息的召回率和識(shí)別準(zhǔn)確率較低，提出一種基于流的移動(dòng)設(shè)備識(shí)別方法，從網(wǎng)絡(luò)流量中準(zhǔn)確地提取出移動(dòng)設(shè)備的特征信息。在真實(shí)網(wǎng)絡(luò)流量中，利用所提方法分別對(duì)目前流行的Android和iOS移動(dòng)系統(tǒng)平臺(tái)設(shè)備進(jìn)行測試。實(shí)驗(yàn)結(jié)果顯示，移動(dòng)系統(tǒng)平臺(tái)特征信息覆蓋率達(dá)91.66%，Android系統(tǒng)平臺(tái)和iOS系統(tǒng)平臺(tái)設(shè)備識(shí)別準(zhǔn)確率分別達(dá)到92.69%和83.88%；Android系統(tǒng)平臺(tái)設(shè)備型號(hào)特征覆蓋率達(dá)70.12%，識(shí)別準(zhǔn)確率達(dá)到96.15%。

關(guān)鍵詞： 移動(dòng)設(shè)備識(shí)別； DPI； 特征識(shí)別； HTTP； Android； iOS

中圖分類號(hào)： TN711?34； TP393 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2018）19?0093?03

Abstract： Since the traditional network terminal identification method has low recall rate and identification accuracy for mobile equipment feature information， a flow?based mobile equipment identification method is proposed to accurately extract the feature information of the mobile equipment from network traffic. In the real network traffic， the proposed method is used to test the popular Android and iOS mobile system platforms. The experimental results show that the feature information coverage rate of mobile system platform can reach up to 91.66%， and the identification accuracy of Android system platform and iOS system platform can reach up to 92.69% and 83.88% respectively； the feature coverage rate and identification accuracy for equipment models of Android system platform can reach up to 70.12% and 96.15% respectively.

Keywords： mobile equipment recognition； DPI； feature identification； HTTP； Android； iOS

0 引 言

面對(duì)日益增長和變化的網(wǎng)絡(luò)流量[1?2]，網(wǎng)絡(luò)管理員和運(yùn)營商希望更加清晰地了解和剖析在網(wǎng)絡(luò)上傳輸?shù)牧髁康母乓?，尤其是移?dòng)設(shè)備產(chǎn)生的流量的概要。在此情況下，移動(dòng)設(shè)備操作系統(tǒng)和類型在網(wǎng)絡(luò)上的分布成為關(guān)注的熱點(diǎn)之一[3]。

網(wǎng)絡(luò)設(shè)備識(shí)別通常采用網(wǎng)絡(luò)流量識(shí)別技術(shù)，通過區(qū)別網(wǎng)絡(luò)流量的類型，確定產(chǎn)生這些流量設(shè)備的類型和特征。網(wǎng)絡(luò)流量識(shí)別技術(shù)分為主動(dòng)識(shí)別技術(shù)和被動(dòng)識(shí)別技術(shù)[4]。主動(dòng)識(shí)別技術(shù)[5]主動(dòng)向終端設(shè)備發(fā)送探針數(shù)據(jù)包，并利用終端設(shè)備返回?cái)?shù)據(jù)包的特征區(qū)分終端設(shè)備。主動(dòng)識(shí)別技術(shù)不具備良好的網(wǎng)絡(luò)擴(kuò)展性，當(dāng)網(wǎng)絡(luò)內(nèi)存在大量節(jié)點(diǎn)時(shí)，主動(dòng)探測不能全面覆蓋所有網(wǎng)絡(luò)，所以主要用在故障隱患檢測和網(wǎng)絡(luò)及應(yīng)用性能測試等方面。由于運(yùn)營商也不想面對(duì)主動(dòng)識(shí)別產(chǎn)生的額外數(shù)據(jù)流量，而被動(dòng)識(shí)別技術(shù)能夠很好地應(yīng)用在諸多方面，并且避免了上述情況的發(fā)生。

傳統(tǒng)的被動(dòng)流量識(shí)別技術(shù)[6]只關(guān)注桌面設(shè)備的特征識(shí)別，對(duì)移動(dòng)終端特征識(shí)別存在明顯不足。首先，傳統(tǒng)流量識(shí)別方法僅統(tǒng)計(jì)分析各類型設(shè)備TCP協(xié)議頭部字段的區(qū)別，不能有效地識(shí)別移動(dòng)設(shè)備；其次，傳統(tǒng)流量識(shí)別方法并沒有完全將移動(dòng)設(shè)備的特征納入到自身的特征庫；最后，傳統(tǒng)流量識(shí)別方法對(duì)深度數(shù)據(jù)包檢測的特征位置不明確。這些情況導(dǎo)致傳統(tǒng)流量識(shí)別技術(shù)在識(shí)別移動(dòng)設(shè)備時(shí)的準(zhǔn)確性較差。

本文提出一個(gè)基于HTTP流的特征識(shí)別框架，采用DPI方法提取HTTP協(xié)議頭部字段中的特征，能夠準(zhǔn)確地識(shí)別和采集移動(dòng)設(shè)備特征。

1 基于HTTP流的移動(dòng)設(shè)備識(shí)別方法體系結(jié)構(gòu)

首先，基于流的監(jiān)測體系結(jié)構(gòu)[7]已經(jīng)廣泛用于大規(guī)模網(wǎng)絡(luò)監(jiān)控，這是本文提出的系統(tǒng)部署的基礎(chǔ)條件；其次，網(wǎng)絡(luò)流量采集使用旁路采集方式，通常在網(wǎng)絡(luò)主干鏈路核心交換機(jī)或邊界設(shè)備上抓取傳輸中的網(wǎng)絡(luò)流量，同時(shí)又不會(huì)影響網(wǎng)絡(luò)鏈路的正常傳輸；最后，基于流的網(wǎng)絡(luò)監(jiān)測體系結(jié)構(gòu)能夠很好地適用于高速網(wǎng)絡(luò)。本文提出基于HTTP流移動(dòng)設(shè)備識(shí)別方法，抓取網(wǎng)絡(luò)數(shù)據(jù)包并提取其數(shù)據(jù)信息，然后聚合為流，最后提取HTTP流中的特征識(shí)別移動(dòng)設(shè)備，系統(tǒng)體系結(jié)構(gòu)如圖1所示。

1.1 網(wǎng)絡(luò)流量采集

網(wǎng)絡(luò)流量利用端口鏡像技術(shù)采集網(wǎng)絡(luò)流量。系統(tǒng)將網(wǎng)絡(luò)設(shè)備目標(biāo)端口A鏡像到相同設(shè)備端口B，這樣鏡像端口就完全復(fù)制目標(biāo)端口A的全部數(shù)據(jù)，并發(fā)送到流量采集服務(wù)器端，采集服務(wù)器利用高性能網(wǎng)絡(luò)流量采集卡收集發(fā)送來的全部流量數(shù)據(jù)。

在采集高速網(wǎng)絡(luò)中的流量時(shí)，網(wǎng)絡(luò)流量采集系統(tǒng)有三個(gè)方面能夠影響整個(gè)系統(tǒng)性能的關(guān)鍵點(diǎn)。一方面，在網(wǎng)絡(luò)設(shè)備上作端口鏡像后，目標(biāo)端口和鏡像端口的總流量相當(dāng)于目標(biāo)端口的1倍，在網(wǎng)絡(luò)目標(biāo)端口原本吞吐量較大時(shí)，要保證網(wǎng)絡(luò)設(shè)備總交換吞吐量遠(yuǎn)大于目標(biāo)端口的1倍，這樣就不會(huì)導(dǎo)致網(wǎng)絡(luò)設(shè)備本身被太大的流量擁塞，以致目標(biāo)網(wǎng)絡(luò)鏈路的斷開；另一方面，流量被傳輸?shù)讲杉?wù)器時(shí)，需要被全部收集到服務(wù)器存儲(chǔ)起來，當(dāng)鏡像端口發(fā)送來的網(wǎng)絡(luò)流量數(shù)據(jù)巨大時(shí)，采集卡的性能必須能夠保障數(shù)據(jù)采集不丟失數(shù)據(jù)包。另外，采集卡接收到數(shù)據(jù)后寫入計(jì)算機(jī)外存，外存設(shè)備要保障寫入的速度，否則也會(huì)出現(xiàn)丟失數(shù)據(jù)的現(xiàn)象。

網(wǎng)絡(luò)流量采集過程包括先存儲(chǔ)后過濾和先過濾后存儲(chǔ)兩種方式，這兩種方式分別使用在不同的環(huán)境。先存儲(chǔ)后過濾方式首先通過采集卡將全部流量抓取后，以結(jié)構(gòu)化的文件格式保留存儲(chǔ)，然后再讀取格式化文件進(jìn)行分析；與之相反，先過濾后存儲(chǔ)方式先按照過濾條件只抓取所需數(shù)據(jù)包或者特征字段，然后將過濾后的流量或者特征存儲(chǔ)起來。

先存儲(chǔ)后過濾方式將網(wǎng)絡(luò)傳輸?shù)牧髁咳坎杉?，按照PCAP格式存儲(chǔ)到硬盤上或存儲(chǔ)陣列中。在存儲(chǔ)過程中，寫入存儲(chǔ)的速度一定要大于端口流量的采集速度，這樣才不會(huì)丟失數(shù)據(jù)。Wireshark工具[8]是一款支持包括PCAP等多種文件格式的網(wǎng)絡(luò)流量分析工具，使用它可以讀取、過濾并分析以PCAP格式文件存儲(chǔ)的網(wǎng)絡(luò)流量。

先過濾后存儲(chǔ)方式利用采集卡支持的tcpdum[9]命令在端口過濾并抓取特征字段，將特征字段以文本的格式存儲(chǔ)到文本文件或者M(jìn)ySQL，Hadoop等數(shù)據(jù)庫內(nèi)。

本文采用先過濾后存儲(chǔ)的方式，直接提取數(shù)據(jù)包的五元組信息、數(shù)據(jù)包長度，以及HTTP數(shù)據(jù)包頭的信息進(jìn)行存儲(chǔ)。

1.2 信息流聚合

依次提取采集到數(shù)據(jù)包的五元組[7]信息和數(shù)據(jù)包長度等信息，按照數(shù)據(jù)包的五元組信息將數(shù)據(jù)包聚合為若干流，并存入流表。同時(shí)，提取網(wǎng)絡(luò)流量中HTTP數(shù)據(jù)包的五元組及頭部信息建立HTTP信息表。根據(jù)HTTP信息表中的五元組字段查詢流表中相同五元組的流信息，將HTTP信息表與流表合并成為HTTP信息流表，具體表結(jié)構(gòu)及數(shù)據(jù)流如圖2所示。

HTTP信息流表記錄HTTP流所需的各種信息，特別是使用正則表達(dá)式將HTTP數(shù)據(jù)包頭的User?Agent字段存入HTTP信息流表的字段中，作為設(shè)備識(shí)別特征。

1.3 HTTP流特征識(shí)別

HTTP信息流表中的特征字段被提取出來匹配特征庫內(nèi)的正則表達(dá)式，并提取出相應(yīng)的信息返回到HTTP信息流表的字段中，最后從表中輸出結(jié)果。

特征識(shí)別采用一款開源的工具UASparser[10]，它能夠準(zhǔn)確地解釋User?Agent字段[11]的字符串，其特征庫利用正則表達(dá)式覆蓋94%的User?Agent字符串，可以有效地提取出User?Agent字段中攜帶的終端設(shè)備信息。

2 實(shí)驗(yàn)與結(jié)果分析

2.1 實(shí)驗(yàn)數(shù)據(jù)集介紹

利用實(shí)驗(yàn)搭建的無線網(wǎng)絡(luò)環(huán)境，本文采集了2016年6月8日—16日一周的真實(shí)流量作為數(shù)據(jù)集。數(shù)據(jù)集共計(jì)52.1 GB流量，6 900萬個(gè)數(shù)據(jù)包。

經(jīng)過排除IPv6、局域網(wǎng)廣播等干擾數(shù)據(jù)包，對(duì)數(shù)據(jù)集進(jìn)行過濾和清洗。利用網(wǎng)絡(luò)上的物理地址（MAC）和現(xiàn)實(shí)接入網(wǎng)絡(luò)的終端設(shè)備的對(duì)應(yīng)關(guān)系，統(tǒng)計(jì)出具體設(shè)備的類型，并以此結(jié)果作為數(shù)據(jù)集的基線（Ground Trues）。

數(shù)據(jù)集在一周內(nèi)總共接入網(wǎng)絡(luò)終端設(shè)備44臺(tái)，其中Android系統(tǒng)終端設(shè)備15臺(tái)、iOS系統(tǒng)終端設(shè)備8臺(tái)和Windows系統(tǒng)傳統(tǒng)臺(tái)式設(shè)備21臺(tái)。

2.2 實(shí)驗(yàn)結(jié)果與分析

實(shí)驗(yàn)從采集的數(shù)據(jù)集中提取出HTTP Request數(shù)據(jù)包共計(jì)696 603個(gè)，并檢測HTTP包頭中User?Agent字段，詳細(xì)分布情況如表1所示。由此可見，并不是全部的HTTP Request數(shù)據(jù)包頭中都含有User?Agent字段，其包含數(shù)量約占[23]。

實(shí)驗(yàn)利用UASparser工具的特征庫提取數(shù)據(jù)包中的特征信息。通過檢測發(fā)現(xiàn)，在整個(gè)數(shù)據(jù)集中共有397 993條有效字段，占總體的91.66%。這個(gè)情況證明UASparser工具的特征庫較為全面地覆蓋了大多數(shù)UA特征信息。實(shí)驗(yàn)提取UA特征信息的結(jié)果包括系統(tǒng)平臺(tái)信息和設(shè)備型號(hào)，其中系統(tǒng)平臺(tái)信息的準(zhǔn)確率分布如表1所示，設(shè)備型號(hào)分布如圖3所示。

在三種主流的系統(tǒng)平臺(tái)中，Android系統(tǒng)平臺(tái)設(shè)備的系統(tǒng)識(shí)別率最高，達(dá)到92.69%，這是因?yàn)锳ndroid系統(tǒng)的開放性，基于Android平臺(tái)的應(yīng)用在發(fā)送HTTP請(qǐng)求時(shí)，多數(shù)會(huì)在UA字段內(nèi)嵌入標(biāo)志信息用來區(qū)分其他應(yīng)用或收集信息。 iOS系統(tǒng)平臺(tái)設(shè)備識(shí)別率相對(duì)較低（83.88%），這是因?yàn)閕OS系統(tǒng)平臺(tái)應(yīng)用在編寫時(shí)對(duì)請(qǐng)求字段有一定的要求和規(guī)范，保護(hù)用戶的隱私。Windows系統(tǒng)平臺(tái)設(shè)備的系統(tǒng)識(shí)別率只有66.79%。經(jīng)過研究發(fā)現(xiàn)，近[13]的Winodws系統(tǒng)硬件上部署了虛擬機(jī)軟件或虛擬Mac OS系統(tǒng)，導(dǎo)致部分（21.22%）Windows平臺(tái)設(shè)備被識(shí)別成Mac OS系統(tǒng)。

3 結(jié) 語

本文提出一種基于流的移動(dòng)設(shè)備識(shí)別系統(tǒng)，能夠從流量中有效地提取出移動(dòng)設(shè)備的特征信息，準(zhǔn)確識(shí)別移動(dòng)設(shè)備的操作系統(tǒng)和設(shè)備類型。以真實(shí)網(wǎng)絡(luò)流量作為實(shí)驗(yàn)數(shù)據(jù)，利用本文提出的方法分別對(duì)目前流行的Android和iOS移動(dòng)系統(tǒng)平臺(tái)特征信息和設(shè)備型號(hào)特征信息進(jìn)行檢測。實(shí)驗(yàn)結(jié)果顯示，本文提出的系統(tǒng)在識(shí)別移動(dòng)系統(tǒng)平臺(tái)與設(shè)備型號(hào)兩種特征信息的過程中具有較高的覆蓋率和準(zhǔn)確率。

參考文獻(xiàn)

[1] TONGAONKAR A. A look at the mobile APP identification landscape [J]. IEEE Internet computing， 2016， 20（4）： 9?15.

[2] DAINOTTI A， PESCAPE A， CLAFFY K C. Issues and future directions in traffic classification [J]. IEEE network， 2012， 26（1）： 35?40.

[3] RANJAN G， TONGAONKAR A， TORRES R. Approximate mat?ching of persistent Lexicon using search?engines for classifying mobile APP traffic [C]// Proceedings of the 35th Annual IEEE International Conference on Computer Communications. [S.l.]： IEEE， 2016： 1?9.

[4] CALLADO A， KAMIENSKI C， SZABO G， et al. A survey on Internet traffic identification [J]. IEEE communications surveys & tutorials， 2009， 11（3）： 37?52.

[5] FALAKI H， LYMBEROPOULOS D， MAHAJAN R， et al. A first look at traffic on smartphones [C]// Proceedings of ACM Conference on Internet Measurement. Melbourne： ACM， 2010： 281?287.

[6] LUCKIE M， BEVERLY R， WU T， et al. Resilience of deployed TCP to blind attacks [C]// Proceedings of 2015 ACM Conference on Internet Measurement. Tokyo： ACM， 2015： 13?26.

[7] CLAISE B， TRAMMELL B， AITKEN P. RFC 7011： specification of the IP flow information export （IPFIX） protocol for the exchange of flow information [S/OL]. [2013?09?11]. http：//www.openssl.ps.pl/pub/rfc/rfc7011.txt.pdf.

[8] NDATINYA V， XIAO Z， MANEPALLI V R， et al. Network forensics analysis using Wireshark [J]. International journal of security and networks， 2015， 10（2）： 91?106.

[9] FUENTES F， KAR D C. Ethereal vs. Tcpdump： a comparative study on packet sniffing tools for educational purpose [J]. Journal of computing sciences in colleges， 2005， 20（4）： 169?176.

[10] HUS?K M， VELAN P， VYKOPAL J. Security monitoring of http traffic using extended flows [C]// Proceedings of the 10th International Conference on Availability， Reliability and Security （ARES）. Toulouse： IEEE， 2015： 258?265.

[11] XU Y， XIONG G， ZHAO Y， et al. Toward identifying and understanding user?agent strings in HTTP traffic [C]// Procee?dings of 2014 Asia?Pacific Web Conference. Switzerland： Springer， 2014： 177?187.