專利名稱：拒絕服務(wù)攻擊防護方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種拒絕服務(wù)攻擊防護方法及裝置。
背景技術(shù)：
DOS (Denial of Service)為拒絕服務(wù)，凡是導(dǎo)致合法用戶不能正常訪問網(wǎng)絡(luò)服務(wù)的行為都算是拒絕服務(wù)攻擊；DDOS(Distributed Denial of Service)即分布式拒絕服務(wù)， DDOS主要是通過大量的“僵尸主機”向受害主機發(fā)送大量看似合法的網(wǎng)絡(luò)包，從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，分布式拒絕服務(wù)攻擊一旦實施，攻擊網(wǎng)絡(luò)就會像洪水般涌向受害主機，從而把合法用戶的網(wǎng)絡(luò)包淹沒，導(dǎo)致合法用戶無法正常訪問服務(wù)器資源。因此，拒絕服務(wù)攻擊又被稱作“泛洪攻擊”。UDP Flood是日益猖獗的流量型D0S/DD0S攻擊，原理很簡單。常見的情況是利用大量的UDP小包沖擊DNS服務(wù)器或Radius認證服務(wù)器、流媒體視頻服務(wù)器。由于UDP是無連接的協(xié)議，因此攻擊者可以仿造無數(shù)個IP地址發(fā)送數(shù)據(jù)包。UDP DNS Query Flood攻擊采用的方法是向被攻擊的服務(wù)器發(fā)送大量的域名解析請求，通常請求解析的域名是隨機生成或者是網(wǎng)絡(luò)世界上根本不存在的域名，被攻擊的DNS 服務(wù)器在接收到域名解析請求的時候首先會在服務(wù)器上查找是否有對應(yīng)的緩存，如果查找不到并且該域名無法直接由服務(wù)器解析的時候，DNS服務(wù)器會向其上層DNS服務(wù)器遞歸查詢域名信息。域名解析的過程給服務(wù)器帶來了很大的負載，每秒鐘域名解析請求超過一定的數(shù)量就會造成DNS服務(wù)器解析域名超時。根據(jù)微軟的統(tǒng)計數(shù)據(jù)，一臺DNS服務(wù)器所能承受的動態(tài)域名查詢的上限是每秒鐘 9000個請求。而目前，在一臺P3的PC機上可以輕易地構(gòu)造出每秒鐘幾萬個域名解析請求， 足以使一臺硬件配置極高的DNS服務(wù)器癱瘓，由此可見DNS服務(wù)器的脆弱性。為解決DNS服務(wù)器遭受D0S/DD0S攻擊從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，合法用戶無法正常訪問服務(wù)器資源的技術(shù)問題，相關(guān)技術(shù)提供了一種通過防護設(shè)備做基于訪問頻率的限速功能來限制對服務(wù)器的訪問量的技術(shù)方案，具體的，主要是基于訪問頻率的閾值的限制，當訪問頻率達到用戶設(shè)定的閾值后，便丟棄后續(xù)數(shù)據(jù)。其示意圖請參見圖1，DNS請求包經(jīng)防火墻Firewall到達域名服務(wù)器DNS server, 其中，虛線代表共計流量，而實線代表正常流量，即非攻擊流量。假如用戶設(shè)置的閾值為 N(次)/秒，當流經(jīng)Firewall的DNS請求包次數(shù)達到N次/秒這個頻率后，F(xiàn)irewall會丟棄超過這個閾值的DNS請求包。在超出N次/秒這個頻率Firewall并不會去識別是否是 DDOS的攻擊流量，將所有的DNS請求包都拋棄。相關(guān)技術(shù)缺點在于，無法識別虛假IP地址，同時識別攻擊流量不夠準確，會有大量的攻擊流量流向服務(wù)器，同時會丟棄大量正常訪問流量。相關(guān)技術(shù)還提供了另外一種解決方法，通過增加帶寬、增加DNS Server冗余設(shè)備來保障正常服務(wù)的提供。但是，第二種解決方法大大增加運營成本，隨著黑客用來攻擊的肉雞數(shù)量的增加，需要增加更多的冗余設(shè)備來提供服務(wù)。
針對相關(guān)技術(shù)中DNS服務(wù)器遭受D0S/DD0S攻擊從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，合法用戶無法正常訪問服務(wù)器資源的技術(shù)問題，目前尚未提出有效的解決方案。

發(fā)明內(nèi)容
針對DNS服務(wù)器遭受D0S/DD0S攻擊從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，合法用戶無法正常訪問服務(wù)器資源的技術(shù)問題，本發(fā)明提供了一種拒絕服務(wù)攻擊防護方法及裝置，以至少解決上述問題。根據(jù)本發(fā)明的一個方面，提供了一種拒絕服務(wù)攻擊防護方法，包括防火墻 Firewall接收個人電腦Local PC發(fā)送的域名服務(wù)器DNS請求包；所述Firewall向所述 Local PC返回應(yīng)答消息；所述Firewall判斷所述Local PC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過；所述Firewal 1將驗證通過的DNS請求包發(fā)送至所述DNS服務(wù)器 server。優(yōu)選的，所述應(yīng)答消息包括所述Firewall構(gòu)造的緩存COOKIE，其中，所述COOKIE 為DNS轉(zhuǎn)介回應(yīng)的域名。優(yōu)選的，所述Firewall判斷所述Local PC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過，包括所述Firewall接收所述Local PC發(fā)送的查詢信息，其中，所述查詢信息用于查詢所述COOKIE的地址；所述Firewall向所述Local PC返回所述COOKIE的地址；所述Firewall接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時， 確定所述Local PC發(fā)送的DNS請求包安全性驗證通過。優(yōu)選的，所述COOKIE的地址為DNS server的地址或者所述Firewall的地址。優(yōu)選的，所述Firewall判斷所述Local PC驗證通過之后，還包括所述Firewall 繼續(xù)接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時，直接將其透傳至所述 DNSserver0優(yōu)選的，所述Firewall將驗證通過的DNS請求包發(fā)送至所述DNS server，包括 所述Firewall修改所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包的目的地址為所述DNS server的地址，將修改后的DNS請求包發(fā)送給所述DNS server。優(yōu)選的，所述Firewall將修改后的DNS請求包發(fā)送給所述DNS server之后，還包括所述Firewall接收所述DNS server返回的響應(yīng)消息，將所述響應(yīng)消息的源IP地址修改為所述Firewall的地址，并將修改后的響應(yīng)消息發(fā)送至所述Local PC。根據(jù)本發(fā)明的另一方面，提供了一種拒絕服務(wù)攻擊防護裝置，設(shè)置于防火墻 Firewall中，包括接收模塊，用于接收個人電腦Local PC發(fā)送的域名服務(wù)器DNS請求包； 應(yīng)答模塊，用于向所述Local PC返回應(yīng)答消息；驗證模塊，用于判斷所述Local PC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過；發(fā)送模塊，用于將驗證通過的DNS請求包發(fā)送至所述DNS服務(wù)器server。優(yōu)選的，所述驗證模塊包括接收單元，用于接收所述Local PC發(fā)送的查詢信息， 其中，所述查詢信息用于查詢COOKIE的地址，其中，所述COOKIE為DNS轉(zhuǎn)介回應(yīng)的域名； 地址發(fā)送單元，用于向所述Local PC返回所述COOKIE的地址；確定單元，用于接收到所述 Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時，確定所述Local PC發(fā)送的DNS請求包安全性驗證通過。優(yōu)選的，所述接收模塊還用于繼續(xù)接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包；所述發(fā)送模塊還用于直接將所述DNS請求包透傳至所述DNS server.在本發(fā)明實施例中，F(xiàn)irewall接收Local PC發(fā)送的DNS請求包，向Local PC返回應(yīng)答消息，進而Firewall判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過，之后Firewall將驗證通過的DNS請求包發(fā)送至DNS server。即，在本發(fā)明實施例中， 把DNS請求的無連接行，變成有連接，這樣使在請求與應(yīng)答過程中增加交互，F(xiàn)irewall判斷 Local PC是否對應(yīng)答消息進行反饋，只能進行反饋的Local PC發(fā)送的DNS請求包才被驗證通過。如果Local PC沒有反饋，則認為是攻擊流量。因為有了交互過程，可以直接過濾掉偽造的地址發(fā)送的DNS請求，通過請求與應(yīng)答過程中的交互，來完成客戶端驗證工作；這樣可以過濾掉通過自動化攻擊工具發(fā)送的攻擊包。即使后續(xù)攻擊工具增加全協(xié)議解析功能， 本發(fā)明實施例提供的拒絕服務(wù)攻擊防護方法也能大大降低了其攻擊速率，使得其很難達到攻擊的目的。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當限定。在附圖中圖1是根據(jù)相關(guān)技術(shù)的第一種解決方法的網(wǎng)絡(luò)架構(gòu)圖；圖2是根據(jù)本發(fā)明實施例的拒絕服務(wù)攻擊防護方法的流程圖；圖3是根據(jù)本發(fā)明實施例的實施例一的流程圖；圖4是根據(jù)本發(fā)明實施例的實施例二的流程圖；圖5是根據(jù)本發(fā)明實施例的實施例三的防火墻部署網(wǎng)絡(luò)圖以及請求包傳送示意圖；圖6是根據(jù)本發(fā)明實施例的拒絕服務(wù)攻擊防護裝置的結(jié)構(gòu)示意圖；圖7是根據(jù)本發(fā)明實施例的驗證模塊的結(jié)構(gòu)示意圖。
具體實施例方式下文中將參考附圖并結(jié)合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。相關(guān)技術(shù)中提到，DOS主要是通過大量的“僵尸主機”向受害主機發(fā)送大量看似合法的網(wǎng)絡(luò)包，從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，分布式拒絕服務(wù)攻擊一旦實施，攻擊網(wǎng)絡(luò)就會像洪水般涌向受害主機，從而把合法用戶的網(wǎng)絡(luò)包淹沒，導(dǎo)致合法用戶無法正常訪問服務(wù)器資源。通常情況下，如果DNS請求包小于512字節(jié)，則用UDP協(xié)議，只有大于512字節(jié)的請求包采用TCP協(xié)議進行傳輸。黑客正是利用了 UDP協(xié)議本身的特性來進行D0S/DD0S進行攻擊。UDP本身是無連接的，DNS請求也是無連接的，在做DNS請求時，通常是一應(yīng)一答的方式，客戶端向服務(wù)器發(fā)送一個Query包，服務(wù)器回應(yīng)一個Request包。因此，本發(fā)明實施例解決的是DNS請求時由于使用UDP協(xié)議，由于UDP本身的無連接性，導(dǎo)致黑客利用肉雞對DNS服務(wù)器進行DDOS攻擊。自動化DDOS攻擊工具最主要的特點就是必須能夠發(fā)送大量的數(shù)據(jù)，以DNS query flood攻擊工具為例，為了發(fā)送高頻率的攻擊包，自動化DDOS攻擊工具所發(fā)送的UDP數(shù)據(jù)都是基于發(fā)送后不管的原理，即只負責發(fā)送數(shù)據(jù)包，不對應(yīng)答包處理。為解決上述技術(shù)問題，本發(fā)明實施例提供了一種拒絕服務(wù)攻擊防護方法，其流程示意圖如圖2所示，包括步驟S202、Firewall接收Local PC發(fā)送的DNS請求包；步驟S204、Firewall向Local PC返回應(yīng)答消息；步驟S206、Firewall判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過；步驟S208、Firewall將驗證通過的DNS請求包發(fā)送至DNS server。在本發(fā)明實施例中，F(xiàn)irewall接收Local PC發(fā)送的DNS請求包，向Local PC返回應(yīng)答消息，進而Firewall判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過，之后Firewall將驗證通過的DNS請求包發(fā)送至DNS server。即，在本發(fā)明實施例中， 把DNS請求的無連接行，變成有連接，這樣使在請求與應(yīng)答過程中增加交互，F(xiàn)irewall判斷 Local PC是否對應(yīng)答消息進行反饋，只能進行反饋的Local PC發(fā)送的DNS請求包才被驗證通過。如果Local PC沒有反饋，則認為是攻擊流量。因為有了交互過程，可以直接過濾掉偽造的地址發(fā)送的DNS請求，通過請求與應(yīng)答過程中的交互，來完成客戶端驗證工作；這樣可以過濾掉通過自動化攻擊工具發(fā)送的攻擊包。即使后續(xù)攻擊工具增加全協(xié)議解析功能， 本發(fā)明實施例提供的拒絕服務(wù)攻擊防護方法也能大大降低了其攻擊速率，使得其很難達到攻擊的目的。在本發(fā)明實施例中，應(yīng)答消息包括=Firewall構(gòu)造的緩存(COOKIE)，其中，COOKIE 為DNS轉(zhuǎn)介回應(yīng)的域名。此處的COOKIE僅僅是一個標識，可以使用其他名稱。此時， Firewall判斷Local PC是否對應(yīng)答消息進行反饋的具體操作如下步驟A、Firewall接收Local PC發(fā)送的查詢信息，其中，查詢信息用于查詢COOKIE 的地址；步驟B、Firewall 向 Local PC 返回 COOKIE 的地址；步驟C、Firewall接收到Local PC向COOKIE的地址發(fā)送的DNS請求包時，確定 Local PC發(fā)送的DNS請求包安全性驗證通過。在步驟B中，F(xiàn)irewall返回的COOKIE的地址為DNS server的地址或者Firewall 的地址。在一個優(yōu)選的實施例中，F(xiàn)irewall判斷Local PC驗證通過之后，F(xiàn)irewall若繼續(xù)接收到Local PC向COOKIE的地址發(fā)送的DNS請求包，則直接將其透傳至DNS server。在另一個優(yōu)選的實施例中，F(xiàn)irewall將驗證通過的DNS請求包發(fā)送至DNS server,實施時，F(xiàn)irewall可以修改Local PC向COOKIE的地址發(fā)送的DNS請求包的目的地址為DNS server的地址，將修改后的DNS請求包發(fā)送給DNS server。相應(yīng)的，F(xiàn)irewall 接收DNS server返回的響應(yīng)消息，將響應(yīng)消息的源IP地址修改為Firewall的地址，并將修改后的響應(yīng)消息發(fā)送至Local PC。BP,Firewall在本實施例中通過修改地址達到防護的作用。為將本發(fā)明實施例提供的拒絕服務(wù)攻擊防護方法闡述地更清楚更明白，現(xiàn)以幾個具體實施例對其進行說明。實施例一本實施例的處理流程圖如圖3所示，包括步驟S302至步驟S316。步驟S302、Local PC 發(fā)送 www. example, com 的 DNS 請求包。步驟S304、Firewall代替DNS Server回應(yīng)一個構(gòu)造的COOKIE (此名字可隨意構(gòu)造)。步驟S306、Local PC 查詢 COOKIE 的地址。步驟S308、Firewall向Local PC返回COOKIE的地址，此地址可以是DNS Server 的IP地址也可以是Firewall的地址。步驟S310、Local PC向COOKIE對應(yīng)的IP地址查詢www. example, com對應(yīng)的地址。步驟S312、Firewall將驗證通過的DNS請求轉(zhuǎn)發(fā)給DNS Server。步驟S314、DNS krver返回解析后的結(jié)果。步驟S316、Firewall 將 DNS Server 返回的結(jié)果轉(zhuǎn)發(fā)給 Local PC。如圖3所示，防火墻接收來自Local PC的DNS請求包(302)，如果是第一次的請求，則不把該請求包轉(zhuǎn)發(fā)給DNS Server，而是構(gòu)造一個COOKIE，COOKIE按如下公式計算值 key, COOKIE = key (source_IP+dns_seq+request_domain),其中，source_IP 為源 IP 地址， dns_seq為DNS請求包的序列號，request_domain為請求的域名；然后模擬DNS Server回應(yīng)一個轉(zhuǎn)向應(yīng)答包(304)，轉(zhuǎn)向域名構(gòu)造 Domain_name = C00KIE+request_domain。Local PC接收到該應(yīng)答包后會請求Domain_name的IP地址(306)，因為Domain_ name = C00KIE+request_domain 所以此時驗證 Domain_name 中的 COOKIE 值，如果驗證通過則返回DNS Server的IP地址給Local PC (308)。這樣一個驗證過程通過，后續(xù)Local PC會根據(jù)(308)的返回結(jié)果繼續(xù)請求解析 requeSt_dOmain(310)，因為在第(306)步中已經(jīng)驗證通過了，所以根據(jù)(306)的驗證結(jié)果把 Local PC 的請求轉(zhuǎn)發(fā)給 DNS Server (312)。隨后DNS Server會把解析的結(jié)果返回給防火墻(314)，防火墻再把該結(jié)果轉(zhuǎn)發(fā)給 Local PC (316)。本例Firewall起到防護功能的工作流程如下接收客戶端(Local PC)的DNS請求包，查找連接表，如果是初始請求包，不會有會話建立；如果是初始請求包，則根據(jù)請求的域名、源IP地址、DNS請求包的序列號計算 COOKIE值，并構(gòu)造轉(zhuǎn)向域名Domairuname，同時在連接表中記錄當前狀態(tài)；把構(gòu)造的Domairuname返回給客戶端，同時遷移連接表狀態(tài)。在當前狀態(tài)下如果接收到圖3中(306)的請求Domairuname的請求包，則驗證 Domain_name 中的 COOKIE 值；如果驗證通過，則返回Domairuname的IP地址，并遷移連接表狀態(tài)；在當前狀態(tài)下如果收到圖3中的(310)的真正的DNS請求包，則證明當前是一個正常的請求，把當前請求轉(zhuǎn)發(fā)給DNS Server，遷移連接表狀態(tài)；如果收到圖3中的(314)的來自DNS Server的應(yīng)答包，則轉(zhuǎn)發(fā)給客戶端，整個過程結(jié)束。如果查到連接表，則說明該請求不是初始請求，根據(jù)當前連接表狀態(tài)，對數(shù)據(jù)包進行驗證，只有圖3中的(306)或(310)兩種情況才是正常狀態(tài)，如果是圖3中的(306)的數(shù)據(jù)包，則執(zhí)行步驟S306 ；如果是圖3中的(310)的數(shù)據(jù)包，則執(zhí)行步驟S310。實施例二在實施例一的基礎(chǔ)上，F(xiàn)irewall可以構(gòu)造成代理模式的防護功能，具體流程圖請參見圖4，包括步驟S402至步驟S420。步驟S402、Local PC 發(fā)送 www. example, com 的 DNS 請求包。步驟S404、Firewall代替DNS Server回應(yīng)一個嵌入了經(jīng)過構(gòu)造的COOKIE的名字 servername (此名字可隨意構(gòu)造)。步驟 S406、Local PC 查詢 servername 的地址。步驟S408、Firewall 向 Local PC 返回 Firewall 自己的 IP 地址。步驟S410、Local PC向Firewall請求域名解析。步驟S412、Firewall將驗證通過并修改其目的IP為DNS Server的IP地址。步驟S414、Firewall將修改后的DNS請求轉(zhuǎn)發(fā)給DNS Server。步驟S416、DNS Server把返回的結(jié)果返回給Firewall。步驟S418、Fierwall將DNS Server返回的結(jié)果的源IP地址改為自己的IP地址。步驟S420、Firewall把修改后的結(jié)果轉(zhuǎn)發(fā)給Local PC。如圖4所示，F(xiàn)irewall接收來自Local PC的DNS請求包(402)，如果是第一次的請求，則不把該請求包轉(zhuǎn)發(fā)給DNS Server,而是構(gòu)造一個COOKIE，COOKIE = key (source_ IP+dns_seq+request_domain)；然后模擬DNS Server回應(yīng)一個轉(zhuǎn)向應(yīng)答包(404)，轉(zhuǎn)向域名構(gòu)造Domain_name = COOKIE+servername (此名字可隨意構(gòu)造)。Local PC接收到該應(yīng)答包后會請求Domain_name的IP地址(404)，因為Domain_ name = COOKIE+servername，所以此時能夠驗證Domain_name中的COOKIE值，如果驗證通過則返回Firewall的IP地址給Local PC(408)。此時一個驗證過程結(jié)束，后續(xù)Local PC會根據(jù)008)的返回結(jié)果繼續(xù)請求解析 requestdomainGlO)，因為在第(406)步中已經(jīng)驗證通過了，所以根據(jù)006)的驗證結(jié)果把該請求包的目的IP地址修改為DNS Server的IP地址(412)。把修改后的請求轉(zhuǎn)發(fā)給 DNSServer (414)。隨后DNS krver會把解析的結(jié)果返回給防火墻016)，防火墻再把應(yīng)答包的源IP地址修改為自己的IP地址后G18)，最后將該結(jié)果轉(zhuǎn)發(fā)給Local PC (420)。本例Firewall起到防護功能的工作流程如下1、接收客戶端(Local PC)的DNS請求包，查找連接表，如果是初始請求包，不會有會話建立；2、如果是初始請求包，則根據(jù)請求的域名、源IP地址、DNS請求包的序列號計算 COOKIE值，并構(gòu)造轉(zhuǎn)向域名Domairuname，同時在連接表中記錄當前狀態(tài)；3、把構(gòu)造的Domairuname返回給客戶端，同時遷移連接表狀態(tài)。4、在當前狀態(tài)下如果接收到圖4中(406)的請求Domairuname的請求包，則驗證 Domain_name 中的 COOKIE 值；5、如果驗證通過，則返回Domain_name的IP地址(此IP地址為Firewall本身的地址)，并遷移連接表狀態(tài)；6、在當前狀態(tài)下如果收到圖4中的010)的真正的DNS請求包，則證明當前是一個正常的請求，修改該請求包的目的IP地址為DNS Server的IP地址，并把當前請求轉(zhuǎn)發(fā)給DNSServer，遷移連接表狀態(tài)；7、如果收到圖4中的016)的來自DNS Server的應(yīng)答包，則修改其源IP地址為 Firewall本身的IP地址，并轉(zhuǎn)發(fā)給客戶端，整個過程結(jié)束。8、如果查到連接表，則說明該請求不是初始請求，根據(jù)當前連接表狀態(tài)，對數(shù)據(jù)包進行驗證，只有圖4中的(406)或(410)兩種情況才是正常狀態(tài)，如果是圖4中的(406)的數(shù)據(jù)包，則執(zhí)行步驟S406;如果是圖4中的010)的數(shù)據(jù)包，則執(zhí)行步驟S410。實施例三本優(yōu)選實施例提供了一種具體的應(yīng)用場景，并對防護方法進行說明。某公司要通過防火墻對DNS服務(wù)器進行防護，防護重點就是DNS DDOS攻擊；需求如下能有效防護基于UDP的DNS DDOS攻擊；記錄攻擊IP ；識別虛假攻擊地址；誤判率要低；不影響原來的網(wǎng)絡(luò)架設(shè)與拓撲。本例中防火墻部署網(wǎng)絡(luò)圖以及請求包傳送示意圖請參見圖5，其中，實線代表來自真實IP的攻擊流量，間隔較寬的虛線代表來自虛假源IP的攻擊流量，點組成的虛線代表正常流量。從圖線可以看出，實線以及間隔較寬的虛線均無法到達DNS server，只有點組成的虛線能夠經(jīng)過Firewall到達另一側(cè)的DNS server。由此可見，F(xiàn)irewall起到了防護的作用，將來自真實IP的攻擊流量以及來自虛假源IP的攻擊流量均進行了攔截。從經(jīng)濟以實用角度而言，DNS服務(wù)器為網(wǎng)絡(luò)服務(wù)的基礎(chǔ)設(shè)施，無論歸屬企業(yè)還是政府，都承載著網(wǎng)絡(luò)服務(wù)中的基礎(chǔ)服務(wù)，如果DNS服務(wù)器遭受DDOS攻擊，會給企業(yè)或政府帶來巨大的經(jīng)濟、業(yè)務(wù)以及聲譽損失。而相關(guān)技術(shù)中提到的為了抵抗DDOS攻擊，運營商采用大量的冗余設(shè)備以及負載設(shè)備的方法，會在經(jīng)濟上給運營商帶來壓力，且會增加貸款，造成很大的資源浪費。而本發(fā)明實施例提供的拒絕服務(wù)攻擊防護方法可以為企業(yè)、政府以及運營商提供保護，最大限度保護服務(wù)器的可用性，以此降低各方面損失?；谕话l(fā)明構(gòu)思，本發(fā)明實施例還提供了一種拒絕服務(wù)攻擊防護裝置，設(shè)置于 Firewall中，其結(jié)構(gòu)示意圖如圖6所示，包括接收模塊601，用于接收個人電腦Local PC發(fā)送的域名服務(wù)器DNS請求包；應(yīng)答模塊602，與接收模塊601耦合，用于向Local PC返回應(yīng)答消息；驗證模塊603，與應(yīng)答模塊602耦合，用于判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過；發(fā)送模塊604，與驗證模塊603耦合，用于將驗證通過的DNS請求包發(fā)送至DNS服務(wù)器 Server0在一個優(yōu)選的實施例中，如圖7所示，驗證模塊603可以包括
接收單元701，用于接收Local PC發(fā)送的查詢信息，其中，查詢信息用于查詢 COOKIE的地址，其中，COOKIE為DNS轉(zhuǎn)介回應(yīng)的域名；地址發(fā)送單元702，用于向Local PC返回COOKIE的地址；確定單元703，用于接收到Local PC向COOKIE的地址發(fā)送的DNS請求包時，確定 LocalPC發(fā)送的DNS請求包安全性驗證通過。在一個優(yōu)選的實施例中，接收模塊601還可以用于繼續(xù)接收到Local PC向COOKIE 的地址發(fā)送的DNS請求包；發(fā)送模塊604還可以用于直接將DNS請求包透傳至DNS server.從以上的描述中，可以看出，本發(fā)明實現(xiàn)了如下技術(shù)效果在本發(fā)明實施例中，F(xiàn)irewall接收Local PC發(fā)送的DNS請求包，向Local PC返回應(yīng)答消息，進而Firewall判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過，之后Firewall將驗證通過的DNS請求包發(fā)送至DNS server。即，在本發(fā)明實施例中， 把DNS請求的無連接行，變成有連接，這樣使在請求與應(yīng)答過程中增加交互，F(xiàn)irewall判斷 Local PC是否對應(yīng)答消息進行反饋，只能進行反饋的Local PC發(fā)送的DNS請求包才被驗證通過。如果Local PC沒有反饋，則認為是攻擊流量。因為有了交互過程，可以直接過濾掉偽造的地址發(fā)送的DNS請求，通過請求與應(yīng)答過程中的交互，來完成客戶端驗證工作；這樣可以過濾掉通過自動化攻擊工具發(fā)送的攻擊包。即使后續(xù)攻擊工具增加全協(xié)議解析功能， 本發(fā)明實施例提供的拒絕服務(wù)攻擊防護方法也能大大降低了其攻擊速率，使得其很難達到攻擊的目的。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1.一種拒絕服務(wù)攻擊防護方法，其特征在于，包括防火墻Firewall接收個人電腦Local PC發(fā)送的域名服務(wù)器DNS請求包； 所述Firewall向所述Local PC返回應(yīng)答消息；所述Firewall判斷所述Local PC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過；所述Firewall將驗證通過的DNS請求包發(fā)送至所述DNS服務(wù)器server。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述應(yīng)答消息包括所述Firewall構(gòu)造的緩存C00KIE，其中，所述COOKIE為DNS轉(zhuǎn)介回應(yīng)的域名。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述Firewall判斷所述LocalPC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過，包括所述Firewal 1接收所述Local PC發(fā)送的查詢信息，其中，所述查詢信息用于查詢所述 COOKIE的地址；所述Firewall向所述Local PC返回所述COOKIE的地址；所述Firewall接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時， 確定所述Local PC發(fā)送的DNS請求包安全性驗證通過。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述COOKIE的地址為DNSserver的地址或者所述Firewall的地址。
5.根據(jù)權(quán)利要求3或4所述的方法，其特征在于，所述Firewall判斷所述LocalPC驗證通過之后，還包括所述Firewall繼續(xù)接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時，直接將其透傳至所述DNS server.
6.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述Firewall將驗證通過的DNS請求包發(fā)送至所述DNS server，包括所述Firewall修改所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包的目的地址為所述DNS server的地址，將修改后的DNS請求包發(fā)送給所述DNS server。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述Firewall將修改后的DNS請求包發(fā)送給所述DNS server之后，還包括所述Firewall接收所述DNS server返回的響應(yīng)消息，將所述響應(yīng)消息的源IP地址修改為所述Firewall的地址，并將修改后的響應(yīng)消息發(fā)送至所述Local PC。
8.—種拒絕服務(wù)攻擊防護裝置，其特征在于，設(shè)置于防火墻Firewall中，包括 接收模塊，用于接收個人電腦Local PC發(fā)送的域名服務(wù)器DNS請求包；應(yīng)答模塊，用于向所述Local PC返回應(yīng)答消息；驗證模塊，用于判斷所述Local PC是否對所述應(yīng)答消息進行反饋，如果反饋，則驗證通過；發(fā)送模塊，用于將驗證通過的DNS請求包發(fā)送至所述DNS服務(wù)器server。
9.根據(jù)權(quán)利要求8所述裝置，其特征在于，所述驗證模塊包括接收單元，用于接收所述Local PC發(fā)送的查詢信息，其中，所述查詢信息用于查詢 COOKIE的地址，其中，所述COOKIE為DNS轉(zhuǎn)介回應(yīng)的域名；地址發(fā)送單元，用于向所述Local PC返回所述COOKIE的地址；確定單元，用于接收到所述Local PC向所述COOKIE的地址發(fā)送的所述DNS請求包時， 確定所述Local PC發(fā)送的DNS請求包安全性驗證通過。
10.根據(jù)權(quán)利要求8或9所述的裝置，其特征在于，所述接收模塊還用于繼續(xù)接收到所述LocalPC向所述COOKIE的地址發(fā)送的所述DNS請求包；所述發(fā)送模塊還用于直接將所述DNS請求包透傳至所述DNS server.
全文摘要
本發(fā)明公開了一種拒絕服務(wù)攻擊防護方法及裝置，該方法包括Firewall接收Local PC發(fā)送的DNS請求包；Firewall向Local PC返回應(yīng)答消息；Firewall判斷Local PC是否對應(yīng)答消息進行反饋，如果反饋，則驗證通過；Firewall將驗證通過的DNS請求包發(fā)送至DNS服務(wù)器server。采用本發(fā)明能夠解決DNS服務(wù)器遭受DOS/DDOS攻擊從而造成網(wǎng)絡(luò)阻塞或者服務(wù)器資源耗盡而導(dǎo)致拒絕服務(wù)，合法用戶無法正常訪問服務(wù)器資源的技術(shù)問題。
文檔編號H04L29/06GK102404334SQ20111040438
公開日2012年4月4日 申請日期2011年12月7日 優(yōu)先權(quán)日2011年12月7日
發(fā)明者劉洪亮, 常磊, 張斌 申請人:山石網(wǎng)科通信技術(shù)(北京)有限公司