拒絕服務攻擊防護方法及裝置的制作方法

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

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


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