郭曉軍，孫海霞，張國梁

(1.西藏民族大學 信息工程學院，陜西 咸陽 712082；2.東南大學 計算機科學與工程學院，江蘇 南京 211189；3.西藏民族大學 西藏光信息處理與可視化技術(shù)重點實驗室，陜西 咸陽 712082)

0 引 言

目前針對西藏Web站點流量識別方面[1]研究工作較少，因此本文主要研究面向藏區(qū)Web站點流量識別的技術(shù)。

在Web站點流量識別方面，國內(nèi)外學者已經(jīng)進行了一些研究工作，多數(shù)以靜態(tài)的網(wǎng)絡(luò)流量記錄文件為數(shù)據(jù)對象。Ihm等[2]對現(xiàn)代Web站點流量的結(jié)構(gòu)進行了海量數(shù)據(jù)分析，指出由于當前Web站點頁面內(nèi)容包含豐富媒體應(yīng)用使得Web流量結(jié)構(gòu)復(fù)雜而不易識別；Ben等[3]通過對靜態(tài)包記錄數(shù)據(jù)集中報文的TCP/IP頭部字段分析來分析和提取其中的Web流量，但該方法沒有對在線網(wǎng)絡(luò)流量做測試，未能獲知其效果；Katerina等[4]從流持續(xù)時間、Request個數(shù)、會話傳輸字節(jié)數(shù)來描述惡意Web流量，但必須要求有先驗知識，需要人工輔助分析，無法實現(xiàn)自動判斷，無法應(yīng)用于大流量網(wǎng)絡(luò)環(huán)境；David等[5]基于其校園網(wǎng)24小時的流量記錄文件，使用BroIDS系統(tǒng)和TCP 80端口來進行提取Web流量，識別準確度受到限制，且該方式僅適用于與靜態(tài)的流量記錄文件。從以上工作可以看出，多數(shù)Web流量識別算法均以靜態(tài)網(wǎng)絡(luò)流量文件為對象，且缺少在大流量網(wǎng)絡(luò)環(huán)境中的實時驗證，識別正確率較低。

針對上述問題，本文提出了一種面向藏區(qū)Web站點流量識別算法TWTBF，該算法基于Bloom Filter[6]，將能夠反映藏區(qū)Web站點流的多個特征字段映射為BF中的位數(shù)組，形成識別規(guī)則，然后在設(shè)定假陽率的情況下，通過多個Hash函數(shù)來計算待識別數(shù)據(jù)包相應(yīng)特征字段的Hash值來判斷是否為Web流量包，有效解提高了Web站點識別算法的準確性和大流量網(wǎng)絡(luò)環(huán)境的魯棒性。

1 Bloom Fitler原理

Bloom Filter(BF)是一種空間效率很高的隨機數(shù)據(jù)結(jié)構(gòu)，其核心思想主要是通過多個不同的Hash函數(shù)來解決“沖突”。它利用位數(shù)組很簡潔地表示一個集合，并能判斷一個元素是否屬于這個集合。它是一個判斷元素是否存在于集合中的快速算法。

1.1 具體過程

(1)BF初始化。初始狀態(tài)時，Bloom Filter是一個包含s(s≥0)個二進制位的位數(shù)組Array，每一位都置為0，如圖1所示。

圖1 Bloom Filter的位數(shù)組Array

(2)映射關(guān)鍵字集合D。假設(shè)關(guān)鍵字集合D={d1，d2，……，dt}，t(t≥0)。BF使用q個相互獨立哈希函數(shù)(Hash Function)，H1()～Hq()它們分別將集合D中的每個元素di映射到Array數(shù)組中。對集合D任意一個元素di，分別計算哈希值H1(di)～Hq(di)，并在Array中將H1(di)～Hq(di)所對應(yīng)位置上的二進制位設(shè)置為1，如圖2所示。

圖2 BF映射集合D中元素的示例(q=3)

(3)判斷未知元素x是否屬于D。BF在判斷x是否屬于D集合時，只需要使用q個哈希函數(shù)對x分別計算出哈希值H1(x)，H2(x)，…，Hq(x)。若H1(x)，H2(x)，…，Hq(x)所代表的Array位置的值都為1(即q個位置都已被設(shè)置為1)，那么就認為x∈屬于集合D(即x為集合D中的元素)，否則就認為x?不屬于集合D(即x不是集合D中的元素)。圖3中給出了一個判斷示例，由于哈希值H2(x1)在Array所代表的位置的二進制位值為0，因此x1不是集合D中的元素，而x2則屬于集合D。

圖3 BF判讀未知元素x1，x2是否屬于集合D

1.2 參數(shù)選擇

從1.1節(jié)及文獻[5]可知，BF涉及4個關(guān)鍵參數(shù)，表1給出了這些參數(shù)名稱及其含義。

表1 BF的參數(shù)及含義

由于BF不是一個完全精確的方法，它允許通過極小的假陽率(即假陽性的概率)來換取大量存儲空間的節(jié)省，其假陽率δ可通過式(1)計算

(1)

當s，t給定時，使得δ達到最小值時的q值為

(2)

此時δ為

(3)

而s可由式(4)計算

(4)

上述過程的具體推理，請參考文獻[6]，本文此處不再贅述。

2 藏區(qū)Web站點流量提取過程

藏區(qū)Web站點流量提取主要是指在高速大流量網(wǎng)絡(luò)環(huán)境下，如何根據(jù)藏區(qū)Web流量的特征快速準確地從被管網(wǎng)絡(luò)海量數(shù)據(jù)包中識別出藏區(qū)Web站點流量的數(shù)據(jù)包，進而準確獲得瀏覽藏區(qū)Web站點過程的流量，為其它應(yīng)用提供純凈的藏區(qū)Web站點流量數(shù)據(jù)。

2.1 Web流量特征選擇

目前，Web服務(wù)主要使用傳輸層TCP協(xié)議[7]的80端口、應(yīng)用層HTTP協(xié)議來建立連接、傳輸數(shù)據(jù)。然而，卻不能使用這兩個特征來唯一標識Web服務(wù)，這是因為一方面采用HTTP協(xié)議的不一定是Web服務(wù)，例如SSDP(simple service discovery protocol)服務(wù)也使用HTTP協(xié)議[8]實現(xiàn)，如圖4所示；而另一方面，即使同時使用TCP 80端口、HTTP協(xié)議的也未必是Web服務(wù)，如圖5所示，此流量是大白菜裝機維護工具桌面應(yīng)用工具獲取數(shù)據(jù)時產(chǎn)生的流量。

圖4 使用HTTP協(xié)議的SSDP服務(wù)

圖5 同時使用TCP 80端口和HTTP協(xié)議的應(yīng)用流量

由此看見，在大流量的網(wǎng)絡(luò)環(huán)境下，由于流量類型復(fù)雜，僅根據(jù)端口號80和協(xié)議標識很難準確識別Web流量。為提高識別Web流量的準確性，本文根據(jù)大量的實際Web流量觀察和分析，可采用IDTCP，80，8080，text/html，Server，Date等6個關(guān)鍵字作為識別Web流量特征。其中，IDTCP=6為IP頭部中“協(xié)議”字段TCP協(xié)議的編號。80，8080分別為TCP頭部中的端口號，text/html為HTTP頭部中“Content-Type”字段的值，Server、Date分別為HTTP頭部的字段名稱。

因此，本文的關(guān)鍵字集合D={IDTCP，80，8080，text/html，Server，Date}，t=|D|=6。

2.2 Hash函數(shù)選擇

Hash函數(shù)[9]是指能夠?qū)㈥P(guān)鍵字(key)的值直接映射為數(shù)組記錄中的某個元素的函數(shù)，以加快查找速度。該數(shù)組記錄也叫散列表(hash table)。

在BF中，Hash函數(shù)的作用是將關(guān)鍵字集合D中的所有元素快速地映射到位數(shù)組Array中。目前常用的Hash函數(shù)構(gòu)造方法有直接尋址法、平方取中法、隨機數(shù)法、除留余數(shù)法等多種方法。為簡單起見，本文此處直接借用文獻[9]中已有的Hash函數(shù)作為BF中Hash函數(shù)的選擇范圍，如圖6所示。至于BF中Hash函數(shù)的個數(shù)，由式(2)給出的Hash函數(shù)個數(shù)q、集合D的勢t以及Array位數(shù)組s之間的關(guān)系決定。

圖6 常用Hash函數(shù)

2.3 提取過程

在確定Web站點特征后，提取Web站點流量過程實質(zhì)上就是根據(jù)這些特征構(gòu)造Bloom Filter，然后利用該Bloom Filter從被監(jiān)管網(wǎng)絡(luò)的大流量環(huán)境下的流量中正確識別出Web流的首個數(shù)據(jù)包，在此基礎(chǔ)上，再將該Web流的后續(xù)數(shù)據(jù)包過濾出，該過程的具體流程如圖7所示。

圖7 藏區(qū)Web站點流量提取流程

其中，IPsrc、IPdst、FPro、FSPort和FDPort字段分別代表網(wǎng)絡(luò)包的源IP地址、目的IP地址、IP頭部中的協(xié)議字段、源端口和目的端口。FServer、FDate分別代表HTTP頭部中的Server字段和Date字段，F(xiàn)text/html表示Content-Type字段的值。在確認Web站點流量的首個數(shù)據(jù)包后，本文利用文獻[10]中的異或Hash算法來過濾出該Web流量后續(xù)的網(wǎng)絡(luò)包。

3 實驗過程與結(jié)果分析

本文使用C語言實現(xiàn)了Bloom Filter及所提出的Web站點流量提取方法。為測試該算法性能，本文將其部署在局域網(wǎng)內(nèi)一臺安裝雙網(wǎng)卡的服務(wù)器GATE上(軟硬件配置見表2)，并使用Libpcap庫[11]捕獲網(wǎng)絡(luò)包，實驗的網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖8所示。

表2 GATE軟硬件配置參數(shù)

圖8 實驗拓撲結(jié)構(gòu)

3.1 準確性

準確性是指本文所提算法所能正確識別出的Web站點流的情況，此處用識別準確率θ表示，即在設(shè)定δ值的條件下，正確識別出的Web站點流量首個數(shù)據(jù)包數(shù)量與所有測試Web站點總數(shù)(WSNum)的比例。本文測試了4個不同δ值下的識別準確率θ，實驗結(jié)果如圖9所示。

圖9 不同δ值對應(yīng)的識別準確率θ

從圖9中可以看出，當δ值較大時(δ=0.1，δ=0.01)，隨著測試Web站點總數(shù)的增加，識別準確率θ會呈現(xiàn)明顯的下降趨勢。這是主要是因為，δ值較大BF的位數(shù)組Array長度s較小，在對較多Web站點流量的首個數(shù)據(jù)包后應(yīng)用q個Hash函數(shù)產(chǎn)生的碰撞次數(shù)會大大增加，從而導(dǎo)致對數(shù)據(jù)包的誤判概率增加，因而會降低識別準確率θ。但當δ值較小時(δ=0.001)，Hash函數(shù)產(chǎn)生的碰撞次數(shù)會明顯下降，此時θ的下降趨勢也明顯緩慢，基本保持在92.3%以上。而當δ=0.0001時，此時BF完全能正確識別所有測試的Web站點流量的首個數(shù)據(jù)包，識別準確率θ基本為100%。可見，δ值的越小，就越能取得較好的識別效果。然而，δ值變小時，BF的Array位數(shù)組大小s、Hash函數(shù)個數(shù)q也會極大增加，會增加識別過程中的計算復(fù)雜度。因此，應(yīng)該根據(jù)實際問題選擇恰當?shù)腂F參數(shù)。表3給出了不同δ值所對應(yīng)的s、q值。

表3 不同δ所對應(yīng)的s和q

3.2 魯棒性

魯棒性指TWTBF算法在被管網(wǎng)絡(luò)不同背景流量下，完成所測試Web站點流的識別的時間。主要用于衡量TWTBF算法對網(wǎng)絡(luò)噪音流量的抵抗能力。

本文在不同本地網(wǎng)絡(luò)背景流量下對TWTBF算法進行了測試，結(jié)果如圖10所示。被管網(wǎng)絡(luò)背景流量采用工具iPerf[12]生成。該圖表明，在測試Web站點流保持不變情況下，背景流量增加對TWTBF算法識別Web站點流量的時間影響并不明顯。這主要由于一方面GATE主機上的千兆網(wǎng)卡能以極高的效率捕獲局域網(wǎng)背景流量，另一方面TWTBF算法主要采用Hash映射，能快速地對數(shù)據(jù)包的字段進行計算，判斷該包是否為Web流的首個數(shù)據(jù)包。此兩方面的優(yōu)勢決定了TWTBF算法在不同背景流量表現(xiàn)出了較好的魯棒性。另外，圖10也說明隨著測試Web站點數(shù)量的增加，TWTBF算法識別Web站點所花費時間也在以近似線性的方式增加。

圖10 被管網(wǎng)背景流量對TWTBF算法識別時間的影響

4 結(jié)束語

藏區(qū)Web站點流量準確而快速的識別有助于研究藏區(qū)內(nèi)Web站點信息泄露評估、滲透測試、指紋信息提取等方面的內(nèi)容。本文提出了一種面向藏區(qū)Web站點的流量識別方法，通過精確Web站點流量特征和引入Bloom Filter結(jié)構(gòu)來有效保證在被管網(wǎng)大流量條件下對Web站點流量識別的準確性和魯棒性，并在真實網(wǎng)絡(luò)環(huán)境下進行了實驗驗證，取得了較好的實驗效果。下一步打算在Web站點多流歸并、加密Web流量識別、更大規(guī)模被管網(wǎng)絡(luò)試用等方面開展研究工作。

[1]McIlwain C.Racial formation,inequality and the political

economy of Web traffic[J].Information,Communication & Society,2016,19(7):1-17.

[2]Ihm S,Pai VS.Towards understanding modern Web traffic[C]//Proc of the ACM SIGCOMM Conference on Internet Measurement Conference.New York:ACM,2011:295-312.

[3]Newton B,Jeffay K,Aikat J.The continued evolution of Web traffic[C]//Proc of IEEE 21st International Symposium on Modelling,Analysis and Simulation of Computer and Telecommunication Systems.New York:IEEE,2013:80-89.

[4]Goseva-Popstojanova K,Anastasovski G,Dimitrijevikj A,et al.Characterization and classification of malicious Web traffic[J].Computers & Security,2014,42(5):92-115.

[5]Gugelmann D,Ager B,Lenders V,et al.Towards understanding upstream Web traffic[C]//Proc of International Wireless Communications and Mobile Computing Conference.New York:IEEE,2015:538-544.

[6]Xylomenos G,Ververidis CN,Siris VA,et al.A survey of information-centric networking research[J].IEEE Communications Surveys & Tutorials,2014,16(2):1024-1049.

[7]Zhou D,Song W,Wang P,et al.Multipath TCP for user coo-peration in LTE networks[J].IEEE Network,2015,29(1):18-24.

[8]Grigorik I.Making the Web faster with HTTP 2.0[J].Communications of the ACM,2013,56(12):42-49.

[9]Arash Partow.Available Hash functions[EB/OL].[2016-10-22].http://www.partow.net/programming/hashfunctions/#AvailableHashFunctions.

[10]Fu C,Bian O,Jiang H,et al.A new chaos-based image cipher using a hash function[C]//Proc of IEEE/ACIS 15th International Conference on Computer and Information Science.New York:IEEE,2016:1-9.

[11]Luis Martin Garcia.Libpcap library[EB/OL].[2000-07-13/2016-09-24].http://www.tcpdump.org/.

[12]Wang Q,Yin S,Gnawali O,et al.Demo:OpenVLC1.0 Platform for research in visible light communication networks[C]//Proc of of the 21st Annual International Conference on Mobile Computing and Networking.New York:ACM,2015:179-181.