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

在上個系列《你的DNS服務真的安全麼？》裏咱們介紹了DNS服務器常見的攻擊場景，看完後，你是否對ddos攻擊憂心重重？本節咱們來告訴你，怎麼破局！!

首先回顧一下DDoS攻擊的原理。DDoS是Distributed Denial of Service的簡稱，即分佈式拒絕服務攻擊，其利用處於不一樣位置的足夠數量的殭屍主機產生數目巨大的數據包對一個或多個目標實施DoS攻擊，耗盡受害端的網絡帶寬、系統資源，使受害主機或網絡喪失提供正常網絡服務的能力。
【傳統網絡對DDoS攻擊的防護】
那傳統網絡是怎麼對DDoS攻擊進行安全防護的呢？簡單來說，傳統安全技術的防禦手段，一般是代替server端來響應client發過來的請求，並經過client的下一步動做有無跟進繼續請求，來判斷該請求是否來自真實用戶。由於若是是肉雞發起的攻擊行爲，一般不會再有下一步的動做被匹配到。而若是某個特定的client IP一旦被認定爲是真實請求的IP，則該IP會被放入對應的「白名單池」，後續一段時間內，當該IP繼續請求時，便會被認爲是合法的。可參考以下示意圖：

這只是一個簡單的原理模擬圖，有些在策略上可能不必定適用黑白名單IP list。
【傳統權威DNS服務器對DDoS的防護手段】 
知道了DDoS的經常使用防護手段，咱們再來講說，對於傳統的權威DNS服務器，是怎麼防禦DDoS攻擊的。對於權威DNS而言，默認的請求都是基於UDP，並且DNS協議裏面明確說明了DNS服務器能夠限制爲TCP提供的資源，因此權威DNS的DDoS攻擊防護最重要的是如何防住UDP攻擊。 可是UDP DDoS防護的最大的問題莫過於UDP沒有會話，不能經過包的交互來判斷某個請求是否爲攻擊行爲，僅僅查看某個DNS數據報文是不可能區分是否爲攻擊請求或者真實用戶請求的。所以傳統安全技術首要地工做就在於須要將缺少會話交互的UDP一來一回請求轉換成爲具備會話記錄的UDP多來多回請求，它們會利用DNS協議的特色採用以下技術進行防護：
一、CNAME重傳
利用DNS的特性，遞歸請求具備迭代查詢一直到獲取最終結果的特色，直接代替DNSserver給client返回一個僞造的惟一隨機字符串cname域名，並根據該源IP是否繼續發起針對該cname域名的請求來斷定，該IP是否爲正常請求。很顯然，若是某個IP立刻跟進發起了該cname域名的請求，則該IP是可被信任的；相對地，若是某個IP在規定的超時時間內並無發起針對該cname域名的請求，則該IP將被斷定爲攻擊者
二、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將被斷定爲攻擊者。 
三、首包丟棄
利用DNS的特性，在DNS請求client在超時時間內沒有收到DNS應答時會重發該請求的特色，傳統安全直接丟棄該首包請求，並根據該源IP是否繼續發起針對這個域名的第二次請求來斷定，該IP是否爲正常請求。很顯然，若是某個IP針對性地發起了第二次請求，則該IP是可被信任的；相對地，若是某個IP在規定的超時時間內並無發起第二次請求，則該IP將被斷定爲攻擊者。
由以上信息咱們能夠知道，這三種手段其原理都是經過將原來的DNS的UDP一來一回請求轉換成爲具備會話記錄的UDP多來多回請求，並經過判斷第二次請求的特色來斷定該源IP是否爲真實用戶訪問行爲或者攻擊行爲，並隨之進行對應的白名單/黑名單操做。
【傳統方案在權威DNS防禦中存在的問題】
以上的傳統方案是否是就能徹底保護咱們的權威DNS了呢？其實仍是存在一些防禦的問題。如下咱們總結了權威DNS防禦可能遇到的問題：
一、 首先從首包丟棄來說，這是在權威DNS防護中基本沒有被採用的技術，緣由主要是遞歸DNS在遇到權威查詢請求被丟棄時會根據SRTT算法另外選擇其餘的權威服務器，致使傳統安全基本上沒法收到所謂的「第二次請求」，所以誤殺的機率極高。同時權威丟棄遞歸發過來的查詢，會對遞歸服務器的資源佔用形成嚴重影響，這種狀況下遞歸服務器可能會根據自身保護的策略直接丟棄該域名的正常請求，有可能形成更嚴重的故障。
二、 其次是TC重傳，相對於CNAME重傳的策略，TC重傳主要的好處在於並無從數據內容信息上去進行篡改，並無「僞造」對應的應答；而重大的缺陷在於須要安全服務DNSserver端支持TCP的請求，這個在性能上是很是大的考驗，帶來的被打癱的風險反而會進一步加大。另外，有一部分ISP的 LocalDNS根本不支持TCP也是一個重要的問題。
三、 再來談CNAME重傳，前文提到了CNAME重傳最大的問題在於「僞造」了一個虛構的應答，正常流程中這個「僞造」的應答只起到中間傳遞的結果不會有其餘方面的影響，可是現實狀況中，ISP側的各類「緩存遞歸分離」「緩存加速應答」技術都會對正常的流程進行篡改，致使前面提到的這個「僞造」的結果被當成正確的結果直接回給終端用戶；更要命地是，ISP側的DNS各類「優化TTL」的技術還會把這種問題嚴重放大，最終致使嚴重的故障。
針對這種問題，最終咱們可能看見相似的錯誤結果：

總結，經過上面針對性的描述，咱們大概知道了這些方法用在DNS上都有或多或少的問題。固然，其實還包括一些安全集羣DNS會話狀態數據一致性、互聯網原生丟包帶來的黑白名單誤殺、僞造IP攻擊影響真實IP帶來的誤殺等各類狀況下的誤殺，這部分誤殺帶來的影響也不可小視。
【權威DNS攻擊的防禦重點】
說了這麼多，權威DNS究竟如何防？說真的，DNS系統自己的優異性能很是關鍵。打鐵還需自身硬，仍是建議選擇一款性能優異的服務器做爲權威的DNS服務器。從原理上來說，傳統安全把缺少會話交互的UDP一來一回請求轉換成爲具備會話記錄的UDP多來多回的策略比起單純的回覆一個DNS應答更耗費計算資源。好比在一樣的性能條件資源下，回覆一個所謂的「cname應答」或者「tc應答」，還不如直接回復原生的DNS應答，粗略比較下來二者之間耗費CPU指令集並無什麼差異。固然前提最重要的是DNS系統要有卓越的性能，超大的帶寬，有能力媲美安全服務器甚至優於安全服務器。阿里雲解析DNS具有單機千萬級QPS，遍及全球的超大規模集羣，具有anycast的架構、依託阿里巴巴大容量、穩定的基礎網絡，可以輕鬆抵抗過億級的DDoS攻擊。阿里雲解析DNS絕對值得你的信賴。（-->雲解析詳情頁）

本文做者：kimi_nyn

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。