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

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


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