專利名稱：分布式攻擊阻止方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種分布式攻擊阻止方法及裝置。
技術(shù)背景
CC攻擊是DDOS (分布式拒絕服務(wù))的一種，相比其它的DDOS攻擊CC似乎更有技術(shù)含量一些。這種攻擊見不到虛假IP，見不到特別大的異常流量，但造成服務(wù)器無法進(jìn)行正常連接，由此可見其危害性。最讓站長(zhǎng)們憂慮的是這種攻擊技術(shù)含量低，利用工具和一些 IP代理一個(gè)初、中級(jí)的電腦水平的用戶就能夠?qū)嵤┕簟?br> 在CC攻擊中，攻擊者控制某些主機(jī)不停地發(fā)送大量數(shù)據(jù)包給對(duì)方服務(wù)器造成服務(wù)器資源完全占用，一直到宕機(jī)崩潰。CC主要是用來攻擊頁面的，當(dāng)一個(gè)網(wǎng)頁訪問的人數(shù)特別多的時(shí)候，打開網(wǎng)頁就慢了，CC就是模擬多個(gè)用戶(有多少線程就可以模擬多少用戶) 不停地訪問那些需要大量數(shù)據(jù)操作(需要大量CPU時(shí)間)的頁面，造成服務(wù)器資源的占用， CPU長(zhǎng)時(shí)間處于100%使用率，永遠(yuǎn)都有處理不完的連接直至網(wǎng)絡(luò)擁塞，正常的訪問被中止。
CC攻擊可分為兩種攻擊方式，第一種是代理CC攻擊黑客借助代理服務(wù)器生成指向受害主機(jī)的合法網(wǎng)頁請(qǐng)求，實(shí)現(xiàn)DDOS和偽裝。第二種是肉雞CC攻擊黑客利用CC攻擊軟件，控制大量肉雞發(fā)動(dòng)攻擊。
在網(wǎng)絡(luò)安全設(shè)備中，傳統(tǒng)的防CC攻擊手段基本上都基于對(duì)服務(wù)器訪問的頻率設(shè)置閾值進(jìn)行限制。大致有以下兩種。
一種主要是基于訪問頻率的閾值的限制，當(dāng)訪問頻率達(dá)到用戶設(shè)定的閾值后，便丟棄后續(xù)數(shù)據(jù)。圖1是根據(jù)現(xiàn)有技術(shù)的防CC攻擊手段示意圖一，如圖1所示，其中虛線線條代表攻擊流量，實(shí)線線條代表正常流量。假如用戶設(shè)置的閾值為N(次)/秒，當(dāng)流經(jīng) Firewal 1的http Get次數(shù)達(dá)到N次/秒這個(gè)頻率后，F(xiàn)irewal 1會(huì)丟棄超過這個(gè)閾值的http Get請(qǐng)求；如上圖所示，他不會(huì)去識(shí)別是否是CC的攻擊流量。該技術(shù)最大的缺點(diǎn)是當(dāng)丟棄 http Get請(qǐng)求時(shí)，只負(fù)責(zé)丟棄超過閾值部分流量，這部分流量中包含攻擊流量和正常流量， 導(dǎo)致部分攻擊流量被放過；同時(shí)部分正常流量被丟棄。
另一種是在服務(wù)器上通過軟件進(jìn)行限制，通常的做法是在Web引擎中開發(fā)基于訪問頻率的閾值的限制。該技術(shù)主要是基于訪問頻率的閾值的限制，當(dāng)訪問頻率達(dá)到用戶設(shè)定的閾值后，便丟棄后續(xù)數(shù)據(jù)。圖2是根據(jù)現(xiàn)有技術(shù)的防CC攻擊手段示意圖二，如圖2所示假如用戶設(shè)置的閾值為N(次)/秒，當(dāng)防CC攻擊模塊統(tǒng)計(jì)的http Get次數(shù)達(dá)到N次/ 秒這個(gè)頻率后，引擎會(huì)丟棄超過這個(gè)閾值的http Get請(qǐng)求；如上圖所示，他不會(huì)去識(shí)別是否是CC的攻擊流量。該技術(shù)最大的缺點(diǎn)就是當(dāng)丟棄http Get請(qǐng)求時(shí)，只負(fù)責(zé)丟棄超過閾值部分流量，這部分流量中包含攻擊流量和正常流量，導(dǎo)致部分攻擊流量被放過；同時(shí)部分正常流量被丟棄。另外，由于不同用戶的Web服務(wù)器用到的引擎不同，導(dǎo)致需要為每個(gè)用戶開發(fā)單獨(dú)的防cc攻擊模塊，通用性較差。發(fā)明內(nèi)容
本發(fā)明提供了一種分布式攻擊阻止方法及裝置，以至少解決相關(guān)技術(shù)中在達(dá)到預(yù)設(shè)訪問量或訪問頻率時(shí)，直接丟棄超過閾值的流量，影響正常訪問網(wǎng)站的問題。
根據(jù)本發(fā)明的一個(gè)方面，提供了一種分布式攻擊阻止方法，包括接收到客戶端向第一 URL發(fā)送的請(qǐng)求報(bào)文；向客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文，其中第二 URL是根據(jù)第一 URL生成的；接收到客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文；向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文。
優(yōu)選地，第二 URL是根據(jù)第一 URL和第一驗(yàn)證碼生成的，第一驗(yàn)證碼是根據(jù)系統(tǒng)選擇的密鑰和/或客戶端的客戶端信息生成的。
優(yōu)選地，在向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文之前，還包括驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼與第一驗(yàn)證碼是否一致；如果判斷結(jié)果為是，則執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。
優(yōu)選地，在向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文之前，還包括驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼是否正確；如果判斷結(jié)果為是，則執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。
優(yōu)選地，系統(tǒng)選擇的密鑰是隨機(jī)生成的。
優(yōu)選地，客戶端信息包括以下至少之一客戶端的URI、客戶端的互聯(lián)網(wǎng)協(xié)議IP地址、客戶端的端口地址、客戶端的瀏覽器類型。
優(yōu)選地，在接收到客戶端向第二URL發(fā)送的請(qǐng)求報(bào)文之前，還包括采用HTTP重定向應(yīng)答自動(dòng)觸發(fā)客戶端向第二 URL發(fā)送請(qǐng)求報(bào)文。
優(yōu)選地，在向客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文之前，還包括在應(yīng)答報(bào)文中攜帶執(zhí)行腳本，其中執(zhí)行腳本用于自動(dòng)觸發(fā)客戶端向第二 URL發(fā)送請(qǐng)求報(bào)文。
根據(jù)本發(fā)明的另一個(gè)方面，提供了一種分布式攻擊阻止裝置，包括第一接收模塊，用于接收客戶端向第一 URL發(fā)送的請(qǐng)求報(bào)文；第一發(fā)送模塊，用于向客戶端發(fā)送攜帶有第二 URL值的應(yīng)答報(bào)文，其中第二 URL是根據(jù)第一 URL生成的；第二接收模塊，用于接收客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文；第二發(fā)送模塊，用于向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文。
通過本發(fā)明，分布式攻擊阻止裝置向客戶端發(fā)送攜帶第二 URL值的應(yīng)答報(bào)文，只有接收到該客戶端向第二 URL值發(fā)送的二次請(qǐng)求時(shí)，才會(huì)向網(wǎng)絡(luò)服務(wù)器發(fā)送該請(qǐng)求報(bào)文， 解決了在達(dá)到預(yù)設(shè)訪問量或訪問頻率時(shí)，直接丟棄超過閾值的流量，影響正常訪問網(wǎng)站的問題，進(jìn)而保證了普通用戶能正常地訪問網(wǎng)站。


此處所說明的附圖用來提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā)明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中
圖1是根據(jù)現(xiàn)有技術(shù)的防CC攻擊手段示意圖一；
圖2是根據(jù)現(xiàn)有技術(shù)的防CC攻擊手段示意圖二 ；
圖3是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止方法的流程圖一；
圖4是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止方法的流程圖二 ；
圖5是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止方法的示意圖6是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖7是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖一；
圖8是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖二。
具體實(shí)施方式
需要說明的是，在不沖突的情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相互組合。下面將參考附圖并結(jié)合實(shí)施例來詳細(xì)說明本發(fā)明。
本發(fā)明提供了一種分布式攻擊阻止方法，圖3是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止方法的流程圖一，如圖3所示，包括如下的步驟S302至步驟S308。
步驟S302，接收到客戶端向第一 URL發(fā)送的請(qǐng)求報(bào)文。
步驟S304，向客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文，其中第二 URL是根據(jù)第一 URL生成的。
步驟S306，接收到客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文。
步驟S308，向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文。
相關(guān)技術(shù)中，在接收到來自客戶端的請(qǐng)求報(bào)文時(shí)，分布式攻擊阻止裝置在達(dá)到預(yù)設(shè)訪問量或訪問頻率時(shí)，直接丟棄超過閾值的流量，從而影響部分正常的訪問。通過本發(fā)明實(shí)施例，分布式攻擊阻止裝置向客戶端發(fā)送攜帶第二 URL值的應(yīng)答報(bào)文，只有接收到該客戶端向第二 URL值發(fā)送的二次請(qǐng)求時(shí)，才會(huì)向網(wǎng)絡(luò)服務(wù)器發(fā)送該請(qǐng)求報(bào)文，分布式攻擊無法進(jìn)行二次請(qǐng)求，從而避免了分布式攻擊且保證了對(duì)網(wǎng)站正常的訪問。
優(yōu)選地，第二 URL是根據(jù)第一 URL和第一驗(yàn)證碼生成的，第一驗(yàn)證碼是根據(jù)系統(tǒng)選擇的密鑰和/或客戶端的客戶端信息生成的。
優(yōu)選地，在向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文之前，還包括驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼與第一驗(yàn)證碼是否一致；如果判斷結(jié)果為是，則執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。在本優(yōu)選實(shí)施例中，通過驗(yàn)證兩次驗(yàn)證碼是否一致，即可判斷此次訪問是否是普通用戶的正常訪問，如果是正常的訪問，則發(fā)送請(qǐng)求報(bào)文，在用戶與網(wǎng)絡(luò)服務(wù)器之間建立連接。
優(yōu)選地，在向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文之前，還包括驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼是否正確；如果判斷結(jié)果為是，則執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。在本優(yōu)選實(shí)施例中，通過驗(yàn)證第二次驗(yàn)證碼是否正確正確，即可判斷此次訪問是否是普通用戶的正常訪問，如果是正常的訪問，則發(fā)送請(qǐng)求報(bào)文，在用戶與網(wǎng)絡(luò)服務(wù)器之間建立連接。
優(yōu)選地，系統(tǒng)選擇的密鑰是隨機(jī)生成的。通過本優(yōu)選實(shí)施例，系統(tǒng)不需進(jìn)行過多計(jì)算即可生成所需密鑰，節(jié)約了系統(tǒng)的資源。
優(yōu)選地，客戶端信息包括以下至少之一客戶端的URI、客戶端的互聯(lián)網(wǎng)協(xié)議IP地址、客戶端的端口地址、客戶端的瀏覽器類型。
優(yōu)選地，在接收到客戶端向第二URL發(fā)送的請(qǐng)求報(bào)文之前，還包括采用HTTP重定向應(yīng)答自動(dòng)觸發(fā)客戶端向第二 URL發(fā)送請(qǐng)求報(bào)文。
優(yōu)選地，在向客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文之前，還包括在應(yīng)答報(bào)文中攜帶執(zhí)行腳本，其中執(zhí)行腳本用于自動(dòng)觸發(fā)客戶端向第二 URL發(fā)送請(qǐng)求報(bào)文。
圖4是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止方法的流程圖一，如圖4所示，包括如下的步驟S402至步驟S412。
步驟S402，客戶端發(fā)送http request報(bào)文。
步驟S404，F(xiàn)irewall代替Web server回應(yīng)的應(yīng)答報(bào)文。
步驟S406，客戶端的再次(請(qǐng)求+驗(yàn)證)請(qǐng)求報(bào)文。
步驟S408，F(xiàn)irewal 1處理后轉(zhuǎn)發(fā)請(qǐng)求報(bào)文。
步驟S410，Web Server 發(fā)送 response 報(bào)文。
步驟 S412，F(xiàn)irewall 轉(zhuǎn)發(fā) Web Server 的 response 報(bào)文。
采用http請(qǐng)求再次驗(yàn)證技術(shù)，當(dāng)收到一個(gè)http請(qǐng)求報(bào)文時(shí)，不將該請(qǐng)求提交給服務(wù)器處理，而是模擬服務(wù)器向請(qǐng)求段發(fā)送一個(gè)經(jīng)過構(gòu)造的應(yīng)答報(bào)文，應(yīng)答報(bào)文中嵌入U(xiǎn)RL 值。
TCP是http協(xié)議的底層承載協(xié)議，因此在進(jìn)行CC攻擊的時(shí)候，也會(huì)占用服務(wù)器的協(xié)議棧中的連接；在我們的解決方案中不做TCP的代理。即允許三次握手的建立。
客戶端發(fā)送的請(qǐng)求，例如GET/xxx HTTP/1. 1，被發(fā)送給分布式攻擊阻止裝置時(shí)，分布式攻擊阻止裝置直接給客戶端返回應(yīng)答碼為302的臨時(shí)重定向應(yīng)答。重定向后的URL = URL+Parameter，參數(shù)的內(nèi)容為分布式攻擊阻止裝置隨機(jī)生成的加密的驗(yàn)證碼。
客戶端在得到應(yīng)答后，會(huì)根據(jù)重定向的內(nèi)容，再次發(fā)起請(qǐng)求，由于分布式攻擊阻止裝置給客戶端返回的重定向后的URL為原始URL+Parameter，所以客戶端會(huì)再次向服務(wù)器發(fā)起請(qǐng)求。
設(shè)備在收到第二次請(qǐng)求之后，會(huì)驗(yàn)證連接后面參數(shù)的值是否與期待值相同。如果一致，則去掉第二次的請(qǐng)求中的參數(shù)后，將請(qǐng)求發(fā)送給HTTP Server0
如果是利用自動(dòng)化工具進(jìn)行分布式攻擊，由于工具不具備瀏覽器的功能，無法解析應(yīng)答碼，并構(gòu)造新的請(qǐng)求，所以步驟C3)就不會(huì)執(zhí)行，這樣便過濾掉了所有的攻擊流量。
本發(fā)明所要解決的技術(shù)問題包括以下幾點(diǎn)。
1、傳統(tǒng)以限制速率方式防CC攻擊最大的問題就是限制不準(zhǔn)，會(huì)放過大量攻擊流量，同時(shí)會(huì)丟棄一部分正常流量；利用此方法可以100%識(shí)別攻擊流量，并全部過濾掉。
2、通過代理服務(wù)器發(fā)動(dòng)的CC攻擊可以全部過濾。
3、通過肉雞發(fā)動(dòng)的CC攻擊可以全部過濾。
4、無需用戶設(shè)置，自動(dòng)識(shí)別攻擊行為并過濾。
下面將結(jié)合實(shí)例對(duì)本發(fā)明實(shí)施例的實(shí)現(xiàn)過程進(jìn)行詳細(xì)描述。
某公司的Web服務(wù)器頻繁遭受大量的CC攻擊，導(dǎo)致正常業(yè)務(wù)中斷，部署傳統(tǒng)防CC 攻擊設(shè)備后，仍有部分用戶無法正常訪問該服務(wù)器。需求如下
1)有效防護(hù)針對(duì)Web服務(wù)器的CC攻擊；
2)降低防護(hù)產(chǎn)品的誤判率，不允許丟棄正常用戶的訪問；
3)不需要對(duì)防護(hù)設(shè)備進(jìn)行復(fù)雜配置。
圖5是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止方法的示意圖。如圖5所示，虛線線條代表來自真實(shí)IP的攻擊流量，點(diǎn)線線條代表來自虛假源IP的攻擊流量，實(shí)線線條代表正常流量。
通過本優(yōu)選實(shí)施例，在未對(duì)防護(hù)設(shè)備進(jìn)行復(fù)雜配置的情況下，有效地阻止了分布式攻擊，同時(shí)保證了正常用戶的訪問。需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。
本發(fā)明實(shí)施例提供了一種分布式攻擊阻止裝置，該裝置可以用于實(shí)現(xiàn)上述分布式攻擊阻止方法。圖6是根據(jù)本發(fā)明實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖，如圖6所示包括第一接收模塊62、第一發(fā)送模塊64、第二接收模塊66和第二發(fā)送模塊68。下面對(duì)其結(jié)構(gòu)進(jìn)行詳細(xì)描述。
第一接收模塊62，用于接收客戶端向第一URL發(fā)送的請(qǐng)求報(bào)文；第一發(fā)送模塊64， 用于向客戶端發(fā)送攜帶有第二URL值的應(yīng)答報(bào)文，其中第二URL是根據(jù)第一 URL生成的；第二接收模塊66，用于接收客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文；第二發(fā)送模塊68，用于向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文。
圖7是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖一，如圖7所示， 上述裝置還包括第一驗(yàn)證模塊610，用于驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼與第一驗(yàn)證碼是否一致；第一執(zhí)行模塊612，連接至第一驗(yàn)證模塊610，用于在判斷結(jié)果為是的情況下，執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。
圖8是根據(jù)本發(fā)明優(yōu)選實(shí)施例的分布式攻擊阻止裝置的結(jié)構(gòu)框圖二，如圖8所示， 上述裝置還包括第二驗(yàn)證模塊614，用于驗(yàn)證客戶端向第二 URL發(fā)送的請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼是否正確；第二執(zhí)行模塊616，連接至第二驗(yàn)證模塊614，用于在判斷結(jié)果為是的情況下，執(zhí)行向網(wǎng)絡(luò)服務(wù)器發(fā)送刪除第二驗(yàn)證碼后的請(qǐng)求報(bào)文的操作。
需要說明的是，裝置實(shí)施例中描述的分布式攻擊阻止裝置對(duì)應(yīng)于上述的方法實(shí)施例，其具體的實(shí)現(xiàn)過程在方法實(shí)施例中已經(jīng)進(jìn)行過詳細(xì)說明，在此不再贅述。
綜上所述，根據(jù)本發(fā)明提供的上述實(shí)施例，提供了一種分布式攻擊阻止方法及裝置。通過本發(fā)明，分布式攻擊阻止裝置向客戶端發(fā)送攜帶第二 URL值的應(yīng)答報(bào)文，只有接收到該客戶端向第二 URL值的二次請(qǐng)求時(shí)，才會(huì)向網(wǎng)絡(luò)服務(wù)器發(fā)送該請(qǐng)求報(bào)文，，解決了在達(dá)到預(yù)設(shè)訪問量或訪問頻率時(shí)，直接丟棄超過閾值的流量，影響正常訪問網(wǎng)站的問題，進(jìn)而保證了普通用戶能正常地訪問網(wǎng)站。
顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計(jì)算裝置來實(shí)現(xiàn)，它們可以集中在單個(gè)的計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計(jì)算裝置可執(zhí)行的程序代碼來實(shí)現(xiàn)，從而，可以將它們存儲(chǔ)在存儲(chǔ)裝置中由計(jì)算裝置來執(zhí)行，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們中的多個(gè)模塊或步驟制作成單個(gè)集成電路模塊來實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。
以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種分布式攻擊阻止方法，其特征在于包括接收到客戶端向第一 URL發(fā)送的請(qǐng)求報(bào)文；向所述客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文，其中所述第二URL是根據(jù)所述第一URL 生成的；接收到所述客戶端向所述第二 URL發(fā)送的所述請(qǐng)求報(bào)文；向網(wǎng)絡(luò)服務(wù)器發(fā)送所述請(qǐng)求報(bào)文。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述第二URL是根據(jù)所述第一URL和第一驗(yàn)證碼生成的，所述第一驗(yàn)證碼是根據(jù)系統(tǒng)選擇的密鑰和/或所述客戶端的客戶端信息生成的。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，在向網(wǎng)絡(luò)服務(wù)器發(fā)送所述請(qǐng)求報(bào)文之前， 還包括驗(yàn)證所述客戶端向所述第二 URL發(fā)送的所述請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼與所述第一驗(yàn)證碼是否一致；如果判斷結(jié)果為是，則執(zhí)行向所述網(wǎng)絡(luò)服務(wù)器發(fā)送刪除所述第二驗(yàn)證碼后的所述請(qǐng)求報(bào)文的操作。
4.根據(jù)權(quán)利要求2所述的方法，其特征在于，在向網(wǎng)絡(luò)服務(wù)器發(fā)送所述請(qǐng)求報(bào)文之前， 還包括驗(yàn)證所述客戶端向所述第二 URL發(fā)送的所述請(qǐng)求報(bào)文中攜帶的第二驗(yàn)證碼是否正確；如果判斷結(jié)果為是，則執(zhí)行向所述網(wǎng)絡(luò)服務(wù)器發(fā)送刪除所述第二驗(yàn)證碼后的所述請(qǐng)求報(bào)文的操作。
5.根據(jù)權(quán)利要求2至4中任一項(xiàng)所述的方法，其特征在于，所述系統(tǒng)選擇的密鑰是隨機(jī)生成的。
6.根據(jù)權(quán)利要求2至4中任一項(xiàng)所述的方法，其特征在于，所述客戶端信息包括以下至少之一所述客戶端的URI、所述客戶端的互聯(lián)網(wǎng)協(xié)議IP地址、所述客戶端的端口地址、所述客戶端的瀏覽器類型。
7.根據(jù)權(quán)利要求1至4中任一項(xiàng)所述的方法，其特征在于，在接收到所述客戶端向所述第二 URL發(fā)送的所述請(qǐng)求報(bào)文之前，還包括采用HTTP重定向應(yīng)答自動(dòng)觸發(fā)所述客戶端向所述第二 URL發(fā)送所述請(qǐng)求報(bào)文。
8.根據(jù)權(quán)利要求1至4中任一項(xiàng)所述的方法，其特征在于，在向所述客戶端發(fā)送攜帶有第二 URL的應(yīng)答報(bào)文之前，還包括在所述應(yīng)答報(bào)文中攜帶執(zhí)行腳本，其中所述執(zhí)行腳本用于自動(dòng)觸發(fā)所述客戶端向所述第二 URL發(fā)送所述請(qǐng)求報(bào)文。
9.一種分布式攻擊阻止裝置，其特征在于包括第一接收模塊，用于接收客戶端向第一 URL發(fā)送的請(qǐng)求報(bào)文；第一發(fā)送模塊，用于向所述客戶端發(fā)送攜帶有第二 URL值的應(yīng)答報(bào)文，其中所述第二 URL是根據(jù)所述第一 URL生成的；第二接收模塊，用于接收所述客戶端向所述第二 URL發(fā)送的所述請(qǐng)求報(bào)文；第二發(fā)送模塊，用于向網(wǎng)絡(luò)服務(wù)器發(fā)送所述請(qǐng)求報(bào)文。
全文摘要
本發(fā)明公開了一種分布式攻擊阻止方法及裝置，該方法包括接收到客戶端向第一URL發(fā)送的請(qǐng)求報(bào)文；向客戶端發(fā)送攜帶有第二URL的應(yīng)答報(bào)文，其中第二URL是根據(jù)第一URL生成的；接收到客戶端向第二URL發(fā)送的請(qǐng)求報(bào)文；向網(wǎng)絡(luò)服務(wù)器發(fā)送請(qǐng)求報(bào)文。本發(fā)明保證了普通用戶能正常地訪問網(wǎng)站。
文檔編號(hào)H04L29/08GK102510386SQ20111044231
公開日2012年6月20日 申請(qǐng)日期2011年12月26日 優(yōu)先權(quán)日2011年12月26日
發(fā)明者劉洪亮, 常磊, 張斌 申請(qǐng)人:山石網(wǎng)科通信技術(shù)(北京)有限公司