劉翼 詹宇昊
摘 要: 針對傳統(tǒng)的網(wǎng)絡(luò)終端識別方法對移動設(shè)備特征信息的召回率和識別準確率較低,提出一種基于流的移動設(shè)備識別方法,從網(wǎng)絡(luò)流量中準確地提取出移動設(shè)備的特征信息。在真實網(wǎng)絡(luò)流量中,利用所提方法分別對目前流行的Android和iOS移動系統(tǒng)平臺設(shè)備進行測試。實驗結(jié)果顯示,移動系統(tǒng)平臺特征信息覆蓋率達91.66%,Android系統(tǒng)平臺和iOS系統(tǒng)平臺設(shè)備識別準確率分別達到92.69%和83.88%;Android系統(tǒng)平臺設(shè)備型號特征覆蓋率達70.12%,識別準確率達到96.15%。
關(guān)鍵詞: 移動設(shè)備識別; DPI; 特征識別; HTTP; Android; iOS
中圖分類號: TN711?34; TP393 文獻標識碼: A 文章編號: 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
面對日益增長和變化的網(wǎng)絡(luò)流量[1?2],網(wǎng)絡(luò)管理員和運營商希望更加清晰地了解和剖析在網(wǎng)絡(luò)上傳輸?shù)牧髁康母乓?,尤其是移動設(shè)備產(chǎn)生的流量的概要。在此情況下,移動設(shè)備操作系統(tǒng)和類型在網(wǎng)絡(luò)上的分布成為關(guān)注的熱點之一[3]。
網(wǎng)絡(luò)設(shè)備識別通常采用網(wǎng)絡(luò)流量識別技術(shù),通過區(qū)別網(wǎng)絡(luò)流量的類型,確定產(chǎn)生這些流量設(shè)備的類型和特征。網(wǎng)絡(luò)流量識別技術(shù)分為主動識別技術(shù)和被動識別技術(shù)[4]。主動識別技術(shù)[5]主動向終端設(shè)備發(fā)送探針數(shù)據(jù)包,并利用終端設(shè)備返回數(shù)據(jù)包的特征區(qū)分終端設(shè)備。主動識別技術(shù)不具備良好的網(wǎng)絡(luò)擴展性,當網(wǎng)絡(luò)內(nèi)存在大量節(jié)點時,主動探測不能全面覆蓋所有網(wǎng)絡(luò),所以主要用在故障隱患檢測和網(wǎng)絡(luò)及應(yīng)用性能測試等方面。由于運營商也不想面對主動識別產(chǎn)生的額外數(shù)據(jù)流量,而被動識別技術(shù)能夠很好地應(yīng)用在諸多方面,并且避免了上述情況的發(fā)生。
傳統(tǒng)的被動流量識別技術(shù)[6]只關(guān)注桌面設(shè)備的特征識別,對移動終端特征識別存在明顯不足。首先,傳統(tǒng)流量識別方法僅統(tǒng)計分析各類型設(shè)備TCP協(xié)議頭部字段的區(qū)別,不能有效地識別移動設(shè)備;其次,傳統(tǒng)流量識別方法并沒有完全將移動設(shè)備的特征納入到自身的特征庫;最后,傳統(tǒng)流量識別方法對深度數(shù)據(jù)包檢測的特征位置不明確。這些情況導(dǎo)致傳統(tǒng)流量識別技術(shù)在識別移動設(shè)備時的準確性較差。
本文提出一個基于HTTP流的特征識別框架,采用DPI方法提取HTTP協(xié)議頭部字段中的特征,能夠準確地識別和采集移動設(shè)備特征。
首先,基于流的監(jiān)測體系結(jié)構(gòu)[7]已經(jīng)廣泛用于大規(guī)模網(wǎng)絡(luò)監(jiān)控,這是本文提出的系統(tǒng)部署的基礎(chǔ)條件;其次,網(wǎng)絡(luò)流量采集使用旁路采集方式,通常在網(wǎng)絡(luò)主干鏈路核心交換機或邊界設(shè)備上抓取傳輸中的網(wǎng)絡(luò)流量,同時又不會影響網(wǎng)絡(luò)鏈路的正常傳輸;最后,基于流的網(wǎng)絡(luò)監(jiān)測體系結(jié)構(gòu)能夠很好地適用于高速網(wǎng)絡(luò)。本文提出基于HTTP流移動設(shè)備識別方法,抓取網(wǎng)絡(luò)數(shù)據(jù)包并提取其數(shù)據(jù)信息,然后聚合為流,最后提取HTTP流中的特征識別移動設(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è)備目標端口A鏡像到相同設(shè)備端口B,這樣鏡像端口就完全復(fù)制目標端口A的全部數(shù)據(jù),并發(fā)送到流量采集服務(wù)器端,采集服務(wù)器利用高性能網(wǎng)絡(luò)流量采集卡收集發(fā)送來的全部流量數(shù)據(jù)。
在采集高速網(wǎng)絡(luò)中的流量時,網(wǎng)絡(luò)流量采集系統(tǒng)有三個方面能夠影響整個系統(tǒng)性能的關(guān)鍵點。一方面,在網(wǎng)絡(luò)設(shè)備上作端口鏡像后,目標端口和鏡像端口的總流量相當于目標端口的1倍,在網(wǎng)絡(luò)目標端口原本吞吐量較大時,要保證網(wǎng)絡(luò)設(shè)備總交換吞吐量遠大于目標端口的1倍,這樣就不會導(dǎo)致網(wǎng)絡(luò)設(shè)備本身被太大的流量擁塞,以致目標網(wǎng)絡(luò)鏈路的斷開;另一方面,流量被傳輸?shù)讲杉?wù)器時,需要被全部收集到服務(wù)器存儲起來,當鏡像端口發(fā)送來的網(wǎng)絡(luò)流量數(shù)據(jù)巨大時,采集卡的性能必須能夠保障數(shù)據(jù)采集不丟失數(shù)據(jù)包。另外,采集卡接收到數(shù)據(jù)后寫入計算機外存,外存設(shè)備要保障寫入的速度,否則也會出現(xiàn)丟失數(shù)據(jù)的現(xiàn)象。
網(wǎng)絡(luò)流量采集過程包括先存儲后過濾和先過濾后存儲兩種方式,這兩種方式分別使用在不同的環(huán)境。先存儲后過濾方式首先通過采集卡將全部流量抓取后,以結(jié)構(gòu)化的文件格式保留存儲,然后再讀取格式化文件進行分析;與之相反,先過濾后存儲方式先按照過濾條件只抓取所需數(shù)據(jù)包或者特征字段,然后將過濾后的流量或者特征存儲起來。
先存儲后過濾方式將網(wǎng)絡(luò)傳輸?shù)牧髁咳坎杉螅凑誔CAP格式存儲到硬盤上或存儲陣列中。在存儲過程中,寫入存儲的速度一定要大于端口流量的采集速度,這樣才不會丟失數(shù)據(jù)。Wireshark工具[8]是一款支持包括PCAP等多種文件格式的網(wǎng)絡(luò)流量分析工具,使用它可以讀取、過濾并分析以PCAP格式文件存儲的網(wǎng)絡(luò)流量。
先過濾后存儲方式利用采集卡支持的tcpdum[9]命令在端口過濾并抓取特征字段,將特征字段以文本的格式存儲到文本文件或者MySQL,Hadoop等數(shù)據(jù)庫內(nèi)。
本文采用先過濾后存儲的方式,直接提取數(shù)據(jù)包的五元組信息、數(shù)據(jù)包長度,以及HTTP數(shù)據(jù)包頭的信息進行存儲。
1.2 信息流聚合
依次提取采集到數(shù)據(jù)包的五元組[7]信息和數(shù)據(jù)包長度等信息,按照數(shù)據(jù)包的五元組信息將數(shù)據(jù)包聚合為若干流,并存入流表。同時,提取網(wǎng)絡(luò)流量中HTTP數(shù)據(jù)包的五元組及頭部信息建立HTTP信息表。根據(jù)HTTP信息表中的五元組字段查詢流表中相同五元組的流信息,將HTTP信息表與流表合并成為HTTP信息流表,具體表結(jié)構(gòu)及數(shù)據(jù)流如圖2所示。
HTTP信息流表記錄HTTP流所需的各種信息,特別是使用正則表達式將HTTP數(shù)據(jù)包頭的User?Agent字段存入HTTP信息流表的字段中,作為設(shè)備識別特征。
1.3 HTTP流特征識別
HTTP信息流表中的特征字段被提取出來匹配特征庫內(nèi)的正則表達式,并提取出相應(yīng)的信息返回到HTTP信息流表的字段中,最后從表中輸出結(jié)果。
特征識別采用一款開源的工具UASparser[10],它能夠準確地解釋User?Agent字段[11]的字符串,其特征庫利用正則表達式覆蓋94%的User?Agent字符串,可以有效地提取出User?Agent字段中攜帶的終端設(shè)備信息。
2.1 實驗數(shù)據(jù)集介紹
利用實驗搭建的無線網(wǎng)絡(luò)環(huán)境,本文采集了2016年6月8日—16日一周的真實流量作為數(shù)據(jù)集。數(shù)據(jù)集共計52.1 GB流量,6 900萬個數(shù)據(jù)包。
經(jīng)過排除IPv6、局域網(wǎng)廣播等干擾數(shù)據(jù)包,對數(shù)據(jù)集進行過濾和清洗。利用網(wǎng)絡(luò)上的物理地址(MAC)和現(xiàn)實接入網(wǎng)絡(luò)的終端設(shè)備的對應(yīng)關(guān)系,統(tǒng)計出具體設(shè)備的類型,并以此結(jié)果作為數(shù)據(jù)集的基線(Ground Trues)。
數(shù)據(jù)集在一周內(nèi)總共接入網(wǎng)絡(luò)終端設(shè)備44臺,其中Android系統(tǒng)終端設(shè)備15臺、iOS系統(tǒng)終端設(shè)備8臺和Windows系統(tǒng)傳統(tǒng)臺式設(shè)備21臺。
2.2 實驗結(jié)果與分析
實驗從采集的數(shù)據(jù)集中提取出HTTP Request數(shù)據(jù)包共計696 603個,并檢測HTTP包頭中User?Agent字段,詳細分布情況如表1所示。由此可見,并不是全部的HTTP Request數(shù)據(jù)包頭中都含有User?Agent字段,其包含數(shù)量約占[23]。
實驗利用UASparser工具的特征庫提取數(shù)據(jù)包中的特征信息。通過檢測發(fā)現(xiàn),在整個數(shù)據(jù)集中共有397 993條有效字段,占總體的91.66%。這個情況證明UASparser工具的特征庫較為全面地覆蓋了大多數(shù)UA特征信息。實驗提取UA特征信息的結(jié)果包括系統(tǒng)平臺信息和設(shè)備型號,其中系統(tǒng)平臺信息的準確率分布如表1所示,設(shè)備型號分布如圖3所示。
在三種主流的系統(tǒng)平臺中,Android系統(tǒng)平臺設(shè)備的系統(tǒng)識別率最高,達到92.69%,這是因為Android系統(tǒng)的開放性,基于Android平臺的應(yīng)用在發(fā)送HTTP請求時,多數(shù)會在UA字段內(nèi)嵌入標志信息用來區(qū)分其他應(yīng)用或收集信息。 iOS系統(tǒng)平臺設(shè)備識別率相對較低(83.88%),這是因為iOS系統(tǒng)平臺應(yīng)用在編寫時對請求字段有一定的要求和規(guī)范,保護用戶的隱私。Windows系統(tǒng)平臺設(shè)備的系統(tǒng)識別率只有66.79%。經(jīng)過研究發(fā)現(xiàn),近[13]的Winodws系統(tǒng)硬件上部署了虛擬機軟件或虛擬Mac OS系統(tǒng),導(dǎo)致部分(21.22%)Windows平臺設(shè)備被識別成Mac OS系統(tǒng)。
本文提出一種基于流的移動設(shè)備識別系統(tǒng),能夠從流量中有效地提取出移動設(shè)備的特征信息,準確識別移動設(shè)備的操作系統(tǒng)和設(shè)備類型。以真實網(wǎng)絡(luò)流量作為實驗數(shù)據(jù),利用本文提出的方法分別對目前流行的Android和iOS移動系統(tǒng)平臺特征信息和設(shè)備型號特征信息進行檢測。實驗結(jié)果顯示,本文提出的系統(tǒng)在識別移動系統(tǒng)平臺與設(shè)備型號兩種特征信息的過程中具有較高的覆蓋率和準確率。
參考文獻
[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.