專(zhuān)利名稱(chēng)：基于狀態(tài)檢測(cè)的鏈路層資源定位信息過(guò)濾的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種基于狀態(tài)檢測(cè)的鏈路層統(tǒng)一資源定位信息(UniformResource Locator，簡(jiǎn)稱(chēng)為URL)過(guò)濾的方法，特別是指一種內(nèi)容過(guò)濾中對(duì)URL進(jìn)行過(guò)濾的方法，屬于計(jì)算機(jī)信息處理和計(jì)算機(jī)網(wǎng)絡(luò)安全技術(shù)領(lǐng)域。
目前，業(yè)界的URL過(guò)濾技術(shù)基本上是在應(yīng)用層實(shí)現(xiàn)，相應(yīng)的防火墻只有作為應(yīng)用層代理時(shí)，才可以進(jìn)行URL過(guò)濾。而對(duì)于最常用的企業(yè)、政府和網(wǎng)站應(yīng)用環(huán)境，防火墻在鏈路層或網(wǎng)絡(luò)層做包過(guò)濾和數(shù)據(jù)轉(zhuǎn)發(fā)時(shí)，卻不具備URL過(guò)濾的功能。
此外，當(dāng)前的URL過(guò)濾技術(shù)對(duì)每一個(gè)到達(dá)應(yīng)用層的數(shù)據(jù)包都要進(jìn)行拆包檢查過(guò)濾，這種技術(shù)一方面受限于代理的處理性能而嚴(yán)重影響過(guò)濾速度，另一方面由于URL搜索過(guò)濾也嚴(yán)重降低了代理的性能。傳統(tǒng)方法無(wú)法辨別哪些數(shù)據(jù)包需要拆包檢查過(guò)濾，哪些數(shù)據(jù)包不需要檢查，因而，這種方法不能大幅度提高過(guò)濾效率。
參見(jiàn)圖2，當(dāng)前的代理型URL過(guò)濾技術(shù)對(duì)每一個(gè)到達(dá)應(yīng)用層的數(shù)據(jù)包都要進(jìn)行拆包檢查過(guò)濾，這種方案一方面受限于代理的處理性能而嚴(yán)重影響過(guò)濾速度，另一方面由于URL搜索匹配過(guò)濾，也同時(shí)降低了代理的性能。例如業(yè)界通用的URL過(guò)濾方法是當(dāng)用戶訪問(wèn)某網(wǎng)站的URL，要在URL黑名單里進(jìn)行串匹配，如果用戶訪問(wèn)的URL子串中包含有“URL黑名單”里所含有的子串，則不允許具有該URL的報(bào)文通過(guò)防火墻。這種方法雖然簡(jiǎn)單，但存在效率低下的問(wèn)題，尤其是URL黑名單中的數(shù)目很大時(shí)，如幾百、幾千甚至上萬(wàn)，每一個(gè)HTTP數(shù)據(jù)包通過(guò)都需要做同樣匹配搜索，因此平均一次匹配所花的時(shí)間就會(huì)非常多。具體匹配所花費(fèi)的時(shí)間可以用如下的公式計(jì)算TC＝t×n其中，TC為匹配一條URL的時(shí)間，t為匹配一條URL黑名單的平均時(shí)間，n為URL黑名單的條數(shù)。
由此可見(jiàn)，在串匹配方法一定的情況下，n值越大，TC的值就越大，這種增長(zhǎng)速率是線性的；而查找時(shí)間的線性增長(zhǎng)對(duì)防火墻性能的影響是非常嚴(yán)重的問(wèn)題。很明顯，傳統(tǒng)的URL過(guò)濾技術(shù)無(wú)法滿足在高速網(wǎng)絡(luò)環(huán)境下大吞吐量URL過(guò)濾的性能需要。
本發(fā)明的目的是這樣實(shí)現(xiàn)的一種基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，至少包括如下的步驟步驟1防火墻操作系統(tǒng)內(nèi)核接收到達(dá)的數(shù)據(jù)包；
步驟2防火墻操作系統(tǒng)內(nèi)核對(duì)該數(shù)據(jù)包進(jìn)行狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查；步驟3如果該數(shù)據(jù)包未通過(guò)上述的狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查，則結(jié)束；步驟4提取出數(shù)據(jù)包的URL信息，進(jìn)行過(guò)濾處理。
上面所述的狀態(tài)檢測(cè)是指進(jìn)行一個(gè)判斷，即如果該數(shù)據(jù)包為HTTP端口的已經(jīng)建立連接的TCP數(shù)據(jù)包，則進(jìn)行URL過(guò)濾檢查；否則就放行該數(shù)據(jù)包。
端口匹配則是從狀態(tài)表中提取出數(shù)據(jù)包所在的端口，檢查是否為端口列表中記錄的端口，如果是，才對(duì)該數(shù)據(jù)包進(jìn)行過(guò)濾，否則就放行該數(shù)據(jù)包。
所述的協(xié)議檢查為檢查數(shù)據(jù)包是否為HTTP協(xié)議數(shù)據(jù)包，并且請(qǐng)求方法為請(qǐng)求指定的頁(yè)面信息(GET)時(shí)則對(duì)該數(shù)據(jù)包過(guò)濾，否則放行該數(shù)據(jù)包。
上面所述的步驟4具體包括如下的過(guò)濾處理步驟41首先進(jìn)行哈希處理步驟42在URL緩存哈希表中進(jìn)行快速匹配；步驟43如果在表中匹配到，則立即通過(guò)；否則進(jìn)入U(xiǎn)RL黑名單或URL白名單子串列表中查詢。
如上所述當(dāng)進(jìn)入黑名單子串列表中查詢時(shí)，如果查到，該URL拒絕通過(guò)；沒(méi)查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中。
如上所述當(dāng)進(jìn)入白名單子串列表中查詢時(shí)，如果查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中；沒(méi)查到，該URL拒絕通過(guò)。
所述的URL黑名單及URL白名單以字符串方式維護(hù)。
URL緩存哈希表為以哈希索引方式維護(hù)、并經(jīng)過(guò)URL黑名單或URL白名單過(guò)濾后允許通過(guò)的正常URL緩存列表。
所述的狀態(tài)表至少記錄每個(gè)數(shù)據(jù)包協(xié)議類(lèi)型(TCP、UDP、ICMP)、連接狀態(tài)、源或目的IP地址、源或目的端口號(hào)；端口列表至少記錄期望被過(guò)濾的HTTP端口或代理的HTTP端口。
本發(fā)明解決了目前防火墻不能對(duì)鏈路層和網(wǎng)絡(luò)層轉(zhuǎn)發(fā)的HTTP數(shù)據(jù)包進(jìn)行URL過(guò)濾的問(wèn)題；其可以對(duì)應(yīng)用層代理、鏈路層橋下轉(zhuǎn)發(fā)、網(wǎng)絡(luò)層路由或NAT偽裝(網(wǎng)絡(luò)地址轉(zhuǎn)換)三種情況下數(shù)據(jù)包進(jìn)行URL過(guò)濾；同時(shí)，采用狀態(tài)檢測(cè)、端口匹配、協(xié)議檢測(cè)技術(shù)可以有效地減少拆包過(guò)濾檢查的數(shù)據(jù)包數(shù)量，提高了過(guò)濾的效率；其改進(jìn)了傳統(tǒng)URL過(guò)濾串匹配搜索的方法，大大提高了匹配效率，節(jié)省了查找時(shí)間。
圖2為現(xiàn)有的URL過(guò)濾流程示意圖。
圖3為本發(fā)明URL過(guò)濾的流程示意圖。
圖4為本發(fā)明方法與傳統(tǒng)過(guò)濾方法所用過(guò)濾時(shí)間的對(duì)比曲線示意圖。
參見(jiàn)圖3，本發(fā)明的一實(shí)施例的URL過(guò)濾方法為首先，位于鏈路層防火墻的URL過(guò)濾模塊接收到達(dá)的數(shù)據(jù)包，并對(duì)該數(shù)據(jù)包進(jìn)行包括狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查在內(nèi)的URL合法性檢查；如果該數(shù)據(jù)包未通過(guò)上述的狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查，則結(jié)束過(guò)濾，否則提取出數(shù)據(jù)包的URL信息，進(jìn)行相應(yīng)的過(guò)濾處理。其中，所述的過(guò)濾處理包括首先進(jìn)行哈希處理；在URL緩存哈希表中進(jìn)行快速匹配；
如果在表中匹配到相應(yīng)的串，則立即通過(guò)該URL；否則進(jìn)入U(xiǎn)RL黑名單或URL白名單子串列表中查詢；當(dāng)進(jìn)入黑名單子串列表中查詢時(shí)，如果查到，拒絕該URL通過(guò)；沒(méi)查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中。
當(dāng)進(jìn)入白名單子串列表中查詢時(shí)，如果查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中；沒(méi)查到，拒絕該URL通過(guò)。
本發(fā)明只對(duì)HTTP協(xié)議數(shù)據(jù)包進(jìn)行過(guò)濾，對(duì)于其他協(xié)議不予考慮，一律放行。因此，只需要判斷到達(dá)的數(shù)據(jù)包是否為HTTP協(xié)議數(shù)據(jù)包，如果不是則立即返回，以減少過(guò)濾時(shí)延。由于完整的URL只在HTTP協(xié)議的請(qǐng)求中出現(xiàn)，所以也只需(沒(méi)有請(qǐng)求就沒(méi)有響應(yīng))對(duì)HTTP請(qǐng)求進(jìn)行過(guò)濾，即只需考慮HTTP協(xié)議中的請(qǐng)求指定的頁(yè)面信息(GET)方法；即查看TCP的數(shù)據(jù)包部分的四個(gè)字節(jié)是否為“GET”。
由于HTTP的請(qǐng)求協(xié)議包一定是在TCP三次握手之后發(fā)出來(lái)的，也就是內(nèi)部網(wǎng)主機(jī)和代理之間已經(jīng)建立了“ESTABLISHED(已建立)”狀態(tài)。因此，只對(duì)狀態(tài)表中存在的端口號(hào)為80/8080(由用戶添加需要過(guò)濾的端口)，狀態(tài)值為“ESTABLISHED(已建立)”連接的TCP數(shù)據(jù)包進(jìn)行拆包過(guò)濾檢查；即只對(duì)HTTP端口的已經(jīng)建立連接的TCP數(shù)據(jù)包進(jìn)行URL過(guò)濾檢查，其他類(lèi)型的數(shù)據(jù)包(比如ICMP、UDP包)不作過(guò)濾檢查，一律放行。這樣就會(huì)有效地減少過(guò)濾包的總數(shù)，減少了URL過(guò)濾對(duì)正常包過(guò)濾的影響，大大提高了過(guò)濾速度。
為此，可在內(nèi)核維持一個(gè)狀態(tài)表和相應(yīng)的端口列表；狀態(tài)表記錄每個(gè)防火墻允許通過(guò)的數(shù)據(jù)包的連接狀態(tài)，端口列表記錄用戶希望過(guò)濾的HTTP端口，通常HTTP為80端口，如果用戶利用自己的代理服務(wù)器則也可以過(guò)濾相應(yīng)的代理的HTTP端口，例如用戶自定義的8080端口。
上面所述的URL黑名單及URL白名單以字符串方式維護(hù)；URL緩存哈希表為經(jīng)過(guò)URL黑名單或URL白名單過(guò)濾后允許通過(guò)的正常URL緩存列表，并以哈希索引方式進(jìn)行維護(hù)。
為了提高URL查詢速度，可以根據(jù)上述的方法建立一種URL緩存哈希表快速匹配和黑/白名單子串列表查詢相結(jié)合的URL過(guò)濾搜索引擎；該URL過(guò)濾搜索引擎當(dāng)URL列表為黑名單時(shí)，只禁止匹配到黑名單中字符串的URL，并將放行的URL插入到緩存哈希表中；當(dāng)URL列表為白名單時(shí)，只允許匹配到白名單中字符串的URL通過(guò)，并將放行的URL插入到緩存哈希表中。
上述的過(guò)濾方法可以大大提高過(guò)濾的效率，節(jié)省查找時(shí)間。由于大多數(shù)用戶進(jìn)行的www訪問(wèn)，都是訪問(wèn)正常、合法的URL地址，因此除了第一次訪問(wèn)的用戶所花的時(shí)間為哈希處理時(shí)間(H)+串匹配時(shí)間(S)外，其余用戶訪問(wèn)相同的URL地址所花時(shí)間為哈希處理時(shí)間(H)。因此，匹配一條URL時(shí)間(T)＝哈希處理時(shí)間(H)+串匹配時(shí)間(S)哈希處理時(shí)間(H)＝計(jì)算哈希函數(shù)時(shí)間(h1)+查找正常URL哈希表的時(shí)間(h2)串匹配時(shí)間(S)＝匹配一條URL黑名單的平均時(shí)間(t)×URL黑名單條數(shù)(n)參見(jiàn)圖4，由于哈希的處理時(shí)間(H)值比較小，比較固定，且與串匹配中匹配URL黑名單條數(shù)(n)無(wú)關(guān)，因此該方法可以極大的提高URL過(guò)濾的效率，而且和只有串匹配的URL過(guò)濾方式相比，URL黑名單的條數(shù)越多，效率越高。
在黑名單中條數(shù)和通過(guò)URL過(guò)濾器URL總數(shù)相同的情況下，如果URL總數(shù)中相同URL的比例越大，URL過(guò)濾緩存技術(shù)同傳統(tǒng)的URL過(guò)濾技術(shù)比優(yōu)勢(shì)越大。
通過(guò)URL過(guò)濾器中，相同URL占URL總數(shù)的比例越高，URL過(guò)濾緩存技術(shù)所花時(shí)間越少，URL過(guò)濾的效率就越高。這種特點(diǎn)對(duì)于用URL過(guò)濾器做網(wǎng)站的WEB入侵過(guò)濾特別有效。但是網(wǎng)站的訪問(wèn)量一般都非常大，一天內(nèi)可能有幾百萬(wàn)次訪問(wèn)，采用傳統(tǒng)的URL過(guò)濾方法，效率并不是很高。簡(jiǎn)單的分析一下訪問(wèn)某一網(wǎng)站的URL就可以知道，從Internet上訪問(wèn)的URL，其中相當(dāng)一部分是相同的，也就是相同URL占總數(shù)比例會(huì)很高，這時(shí)采用URL過(guò)濾緩存技術(shù)，可以很明顯的降低URL過(guò)濾所需時(shí)間，而且相同URL所占比例越高，所花時(shí)間就越少，效率越高。這樣既保護(hù)了網(wǎng)站，又不太提高訪問(wèn)網(wǎng)站的時(shí)延，一舉兩得。
本發(fā)明的方法將穿過(guò)防火墻的屬于同一連接的所有數(shù)據(jù)包作為一個(gè)整體的數(shù)據(jù)流看待，構(gòu)成連接狀態(tài)表，通過(guò)規(guī)則表與狀態(tài)表的共同配合，對(duì)表中的各個(gè)連接狀態(tài)、各種協(xié)議類(lèi)型(甚至各種應(yīng)用協(xié)議)等因素加以識(shí)別和進(jìn)行訪問(wèn)控制?；谶@種狀態(tài)檢測(cè)，使得防火墻能夠在允許報(bào)文進(jìn)入U(xiǎn)RL過(guò)濾引擎之前精確定位HTTP請(qǐng)求類(lèi)型數(shù)據(jù)報(bào)，從而避免了對(duì)其他類(lèi)型數(shù)據(jù)報(bào)文的重復(fù)過(guò)濾檢查，在極大的提高了URL過(guò)濾效率的同時(shí)，保證了防火墻對(duì)數(shù)據(jù)報(bào)文轉(zhuǎn)發(fā)的很高的吞吐能力。
以上的實(shí)施方式僅用以說(shuō)明而并非限制本發(fā)明的技術(shù)方案；盡管參照上述所有的實(shí)施方式對(duì)本發(fā)明已經(jīng)進(jìn)行了詳細(xì)的說(shuō)明，本領(lǐng)域的普通技術(shù)人員不能否認(rèn)本發(fā)明中的各技術(shù)特征依然可以做相應(yīng)的修改、調(diào)整或者等同替換；但是，一切不脫離本發(fā)明的精神和范圍的任何修改或局部替換，均應(yīng)為本發(fā)明所揭示的技術(shù)特征，并均應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。
權(quán)利要求
1.一種基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于該方法至少包括如下的步驟步驟1防火墻操作系統(tǒng)內(nèi)核接收到達(dá)的數(shù)據(jù)包；步驟2防火墻操作系統(tǒng)內(nèi)核對(duì)該數(shù)據(jù)包進(jìn)行狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查；步驟3如果該數(shù)據(jù)包未通過(guò)上述的狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查，則結(jié)束；步驟4提取出數(shù)據(jù)包的URL信息，進(jìn)行過(guò)濾處理。
2.根據(jù)權(quán)利要求1所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的狀態(tài)檢測(cè)為如果該數(shù)據(jù)包為HTTP端口的已經(jīng)建立連接的TCP數(shù)據(jù)包，則進(jìn)行URL過(guò)濾檢查；否則放行該數(shù)據(jù)包。
3.根據(jù)權(quán)利要求1所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的端口匹配為從狀態(tài)表中提取出數(shù)據(jù)包所在的端口，檢查其是否為端口列表中記錄的端口，如果是則對(duì)該數(shù)據(jù)包進(jìn)行過(guò)濾，否則放行該數(shù)據(jù)包。
4.根據(jù)權(quán)利要求1所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的協(xié)議檢查為檢查數(shù)據(jù)包是否為HTTP協(xié)議數(shù)據(jù)包，并且請(qǐng)求方法為請(qǐng)求指定的頁(yè)面信息(GET)時(shí)則對(duì)該數(shù)據(jù)包過(guò)濾，否則放行該數(shù)據(jù)包。
5.根據(jù)權(quán)利要求1所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于步驟4所述的過(guò)濾處理包括步驟41首先進(jìn)行哈希處理步驟42在URL緩存哈希表中進(jìn)行快速匹配；步驟43如果在表中匹配到，則立即通過(guò)；否則進(jìn)入U(xiǎn)RL黑名單或URL白名單子串列表中查詢。
6.根據(jù)權(quán)利要求5所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于當(dāng)進(jìn)入黑名單子串列表中查詢時(shí)，如果查到，該URL拒絕通過(guò)；沒(méi)查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中。
7.根據(jù)權(quán)利要求5所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于當(dāng)進(jìn)入白名單子串列表中查詢時(shí)，如果查到，該URL放行通過(guò)，并將該URL插入緩存哈希表中；沒(méi)查到，該URL拒絕通過(guò)。
8.根據(jù)權(quán)利要求5所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的URL黑名單及URL白名單以字符串方式維護(hù)。
9.根據(jù)權(quán)利要求5所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的URL緩存哈希表為以哈希索引方式維護(hù)、并經(jīng)過(guò)URL黑名單或URL白名單過(guò)濾后允許通過(guò)的正常URL緩存列表。
10.根據(jù)權(quán)利要求2所述的基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，其特征在于所述的狀態(tài)表至少記錄每個(gè)數(shù)據(jù)包協(xié)議類(lèi)型(TCP、UDP、ICMP)、連接狀態(tài)、源或目的IP地址、源或目的端口號(hào)；端口列表至少記錄期望被過(guò)濾的HTTP端口或代理的HTTP端口。
全文摘要
一種基于狀態(tài)檢測(cè)的鏈路層URL過(guò)濾的方法，首先，接收到達(dá)的數(shù)據(jù)包；其次，對(duì)該數(shù)據(jù)包進(jìn)行狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查；然后，如果該數(shù)據(jù)包未通過(guò)上述的狀態(tài)檢測(cè)、端口匹配和協(xié)議檢查，則結(jié)束；最后，提取出數(shù)據(jù)包的URL信息，進(jìn)行過(guò)濾處理。本發(fā)明解決了目前防火墻不能對(duì)鏈路層和網(wǎng)絡(luò)層轉(zhuǎn)發(fā)的HTTP數(shù)據(jù)包進(jìn)行URL過(guò)濾的問(wèn)題；可對(duì)應(yīng)用層代理、鏈路層橋下轉(zhuǎn)發(fā)、網(wǎng)絡(luò)層路由或NAT(網(wǎng)絡(luò)地址轉(zhuǎn)換)偽裝三種情況下數(shù)據(jù)包進(jìn)行URL過(guò)濾；同時(shí)，采用狀態(tài)檢測(cè)、端口匹配、協(xié)議檢測(cè)技術(shù)可以有效地減少拆包過(guò)濾檢查的數(shù)據(jù)包數(shù)量，提高了過(guò)濾的效率；其改進(jìn)了傳統(tǒng)URL過(guò)濾串匹配搜索的方法，大大提高了匹配效率，節(jié)省了查找時(shí)間。
文檔編號(hào)G06F17/30GK1475930SQ02125740
公開(kāi)日2004年2月18日 申請(qǐng)日期2002年8月15日 優(yōu)先權(quán)日2002年8月15日
發(fā)明者宋春雨, 高紅, 楊聰毅 申請(qǐng)人:聯(lián)想(北京)有限公司