《DNS攻擊防範科普系列2》 -DNS伺服器怎麼防DDoS攻擊

大濤學長發表於2019-10-16
在上個系列 《你的DNS服務真的安全麼?》裡我們介紹了DNS伺服器常見的攻擊場景,看完後,你是否對ddos攻擊憂心重重?本節我們來告訴你,怎麼破局!!
《DNS攻擊防範科普系列2》 -DNS伺服器怎麼防DDoS攻擊

首先回顧一下DDoS攻擊的原理。DDoS是Distributed Denial of Service的簡稱,即分散式拒絕服務攻擊,其利用處於不同位置的足夠數量的殭屍主機產生數目巨大的資料包對一個或多個目標實施DoS攻擊,耗盡受害端的網路頻寬、系統資源,使受害主機或網路喪失提供正常網路服務的能力。
【傳統網路對DDoS攻擊的防禦】
那傳統網路是怎麼對DDoS攻擊進行安全防禦的呢?簡單來講,傳統安全技術的防護手段,通常是代替server端來響應client發過來的請求,並透過client的下一步動作有無跟進繼續請求,來判斷該請求是否來自真實使用者。因為如果是肉雞發起的攻擊行為,通常不會再有下一步的動作被匹配到。而如果某個特定的client IP一旦被認定為是真實請求的IP,則該IP會被放入對應的“白名單池”,後續一段時間內,當該IP繼續請求時,便會被認為是合法的。可參考如下示意圖:
《DNS攻擊防範科普系列2》 -DNS伺服器怎麼防DDoS攻擊

這只是一個簡單的原理模擬圖,有些在策略上可能不一定適用黑白名單IP list。
【傳統權威DNS伺服器對DDoS的防禦手段】
知道了DDoS的常用防禦手段,我們再來說說,對於傳統的權威DNS伺服器,是怎麼防護DDoS攻擊的。對於權威DNS而言,預設的請求都是基於UDP,而且DNS協議裡面明確說明了DNS伺服器可以限制為TCP提供的資源,所以權威DNS的DDoS攻擊防禦最重要的是如何防住UDP攻擊。 但是UDP DDoS防禦的最大的問題莫過於UDP沒有會話,不能透過包的互動來判斷某個請求是否為攻擊行為,僅僅檢視某個DNS資料包文是不可能區分是否為攻擊請求或者真實使用者請求的。因此傳統安全技術首要地工作就在於需要將缺乏會話互動的UDP一來一回請求轉換成為具有會話記錄的UDP多來多回請求,它們會利用DNS協議的特點採用如下技術進行防禦:
1、CNAME重傳
利用DNS的特性,遞迴請求具有迭代查詢一直到獲取最終結果的特點,直接代替DNSserver給client返回一個偽造的唯一隨機字串cname域名,並根據該源IP是否繼續發起針對該cname域名的請求來判定,該IP是否為正常請求。很顯然,如果某個IP馬上跟進發起了該cname域名的請求,則該IP是可被信任的;相對地,如果某個IP在規定的超時時間內並沒有發起針對該cname域名的請求,則該IP將被判定為攻擊者
2、TC重傳
利用DNS的特性,在DNS請求client遇到DNS應答flag欄位中TC標記為1時必然會發起TCP DNS請求的特點,直接代替DNS server給client返回一個偽造的空應答但該應答flag欄位中TC標記為1,並根據該源IP是否繼續發起針對該域名的TCP的DNS請求來判定,該IP是否為正常請求。很顯然,如果某個IP馬上跟進發起了TCP的DNS請求,則該IP是可被信任的;相對地,如果某個IP在規定的超時時間內並沒有發起針對的TCP請求,則該IP將被判定為攻擊者。
3、首包丟棄
利用DNS的特性,在DNS請求client在超時時間內沒有收到DNS應答時會重發該請求的特點,傳統安全直接丟棄該首包請求,並根據該源IP是否繼續發起針對這個域名的第二次請求來判定,該IP是否為正常請求。很顯然,如果某個IP針對性地發起了第二次請求,則該IP是可被信任的;相對地,如果某個IP在規定的超時時間內並沒有發起第二次請求,則該IP將被判定為攻擊者。
由以上資訊我們可以知道,這三種手段其原理都是透過將原來的DNS的UDP一來一回請求轉換成為具有會話記錄的UDP多來多回請求,並透過判斷第二次請求的特點來判定該源IP是否為真實使用者訪問行為或者攻擊行為,並隨之進行對應的白名單/黑名單操作。
【傳統方案在權威DNS防護中存在的問題】
以上的傳統方案是不是就能完全保護我們的權威DNS了呢?其實還是存在一些防護的問題。以下我們總結了權威DNS防護可能遇到的問題:
1、 首先從首包丟棄來講,這是在權威DNS防禦中基本沒有被採用的技術,原因主要是遞迴DNS在遇到權威查詢請求被丟棄時會根據SRTT演算法另外選擇其他的權威伺服器,導致傳統安全基本上無法收到所謂的“第二次請求”,因此誤殺的機率極高。同時權威丟棄遞迴發過來的查詢,會對遞迴伺服器的資源佔用造成嚴重影響,這種情況下遞迴伺服器可能會根據自身保護的策略直接丟棄該域名的正常請求,有可能造成更嚴重的故障。
2、 其次是TC重傳,相對於CNAME重傳的策略,TC重傳主要的好處在於並沒有從資料內容資訊上去進行篡改,並沒有“偽造”對應的應答;而重大的缺陷在於需要安全服務DNSserver端支援TCP的請求,這個在效能上是非常大的考驗,帶來的被打癱的風險反而會進一步加大。另外,有一部分ISP的 LocalDNS根本不支援TCP也是一個重要的問題。
3、 再來談CNAME重傳,前文提到了CNAME重傳最大的問題在於“偽造”了一個虛構的應答,正常流程中這個“偽造”的應答只起到中間傳遞的結果不會有其他方面的影響,但是現實情況中,ISP側的各種“快取遞迴分離”“快取加速應答”技術都會對正常的流程進行篡改,導致前面提到的這個“偽造”的結果被當成正確的結果直接回給終端使用者;更要命地是,ISP側的DNS各種“最佳化TTL”的技術還會把這種問題嚴重放大,最終導致嚴重的故障。
針對這種問題,最終我們可能看見類似的錯誤結果:
《DNS攻擊防範科普系列2》 -DNS伺服器怎麼防DDoS攻擊

總結,透過上面針對性的描述,我們大概知道了這些方法用在DNS上都有或多或少的問題。當然,其實還包括一些安全叢集DNS會話狀態資料一致性、網際網路原生丟包帶來的黑白名單誤殺、偽造IP攻擊影響真實IP帶來的誤殺等各種情況下的誤殺,這部分誤殺帶來的影響也不可小視。
【權威DNS攻擊的防護重點】
說了這麼多,權威DNS究竟如何防?說真的,DNS系統本身的優異效能非常關鍵。打鐵還需自身硬,還是建議選擇一款效能優異的伺服器作為權威的DNS伺服器。從原理上來講,傳統安全把缺乏會話互動的UDP一來一回請求轉換成為具有會話記錄的UDP多來多回的策略比起單純的回覆一個DNS應答更耗費計算資源。比如在同樣的效能條件資源下,回覆一個所謂的“cname應答”或者“tc應答”,還不如直接回復原生的DNS應答,粗略比較下來兩者之間耗費CPU指令集並沒有什麼差別。當然前提最重要的是DNS系統要有卓越的效能,超大的頻寬,有能力媲美安全伺服器甚至優於安全伺服器。阿里雲解析DNS具備單機千萬級QPS,遍佈全球的超大規模叢集,具備anycast的架構、依託阿里巴巴大容量、穩定的基礎網路,能夠輕鬆抵抗過億級的DDoS攻擊。阿里雲解析DNS絕對值得你的信賴。(--> 雲解析詳情頁

本文作者:kimi_nyn
本文為雲棲社群原創內容,未經允許不得轉載。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69947441/viewspace-2660192/,如需轉載,請註明出處,否則將追究法律責任。

相關文章