我們很自豪地推出 Advanced DNS Protection 系統，這是一種強大的防禦機制，旨在防禦最複雜的 DNS 型 DDoS 攻擊。該系統設計用於提供頂級安全性，確保您的數位基礎架構在面對不斷變化的威脅時保持復原能力。
我們現有的系統已經能夠成功偵測和緩解針對 DNS 的「簡單」DDoS 攻擊，但卻難以應對更複雜的攻擊。Advanced DNS Protection 系統能夠利用我們將在本部落格文章中展示的新技術來彌補這一差距。
Advanced DNS Protection 目前處於測試階段，所有 Magic Transit 客戶均可免費使用。請繼續閱讀，以詳細瞭解 DNS DDoS 攻擊、新系統如何運作以及未來預計會出現哪些新功能。
報名表達您的興趣，詳細瞭解我們如何幫助您保持 DNS 伺服器受保護、可用且高效能。
分散式阻斷服務 (DDoS) 攻擊是一種網路攻擊，旨在中斷和壓垮網站及其他線上服務。當 DDoS 攻擊成功且網站離線時，可能會導致重大收入損失和聲譽受損。
2023 年 DDoS 攻擊類型分佈情況
中斷和壓垮網站的常見方法是向其伺服器傳送超出其處理能力的流量。這稱為 HTTP 洪水攻擊。它是一種 DDoS 攻擊，使用大量 HTTP 請求_直接_針對網站。根據我們上一份 DDoS 趨勢報告，2023 年，我們的系統自動緩解了 520 萬次 HTTP DDoS 攻擊，佔所有 DDoS 攻擊的 37%。
HTTP 洪水攻擊圖
然而，還有另一種方法可以使網站下線：_間接_針對網站。威脅行為者不是淹沒網站伺服器，而是淹沒 DNS 伺服器。如果 DNS 伺服器因查詢數量超出其容量而不堪重負，主機名稱到 IP 位址的轉譯就會失敗，網站會因 DNS 伺服器無法回應合法查詢而間接造成服務中斷。
一個引人注目的範例是 2016 年 10 月針對 DNS 提供者 Dyn 的攻擊。這是由臭名昭著的 Mirai 殭屍網路發起的毀滅性 DDoS 攻擊。它導致了 Airbnb、Netflix 和 Amazon 等主要網站的中斷，Dyn 花了一整天的時間才恢復服務。這對於服務中斷來說是一個很長的時間，可能會導致嚴重的聲譽和收入影響。
七年多後，Mirai 攻擊和 DNS 攻擊仍然非常常見。2023 年，DNS 攻擊是第二常見的攻擊類型，佔所有 DDoS 攻擊的 33%（460 萬次攻擊）。Mirai 變種殭屍網路發動的攻擊是第五大常見的網路層 DDoS 攻擊類型，佔所有網路層 DDoS 攻擊的 3%。
DNS 查詢洪水攻擊圖
當每個查詢中存在重複模式時，DNS 型 DDoS 攻擊可以更容易緩解。這就是所謂的「攻擊指紋」。基於指紋的緩解系統可以識別這些模式，然後部署緩解規則，在不影響合法流量的情況下精確篩選攻擊流量。
例如，我們假設一個攻擊者向目標傳送大量 DNS 查詢的場景。在此範例中，攻擊者僅隨機化來源 IP 位址。所有其他查詢欄位保持一致。緩解系統偵測到該模式（來源連接埠為 1024，查詢的網域為 `example.com`），並將產生一個臨時緩解規則來篩選這些查詢。
攻擊指紋概念的簡化圖
然而，DNS 型 DDoS 攻擊更加複雜和隨機，缺乏明顯的攻擊模式。如果沒有一致的模式來鎖定，幾乎不可能使用基於指紋的緩解系統來緩解攻擊。此外，即使在高度隨機的攻擊中偵測到攻擊模式，該模式也可能非常通用，可能導致錯誤地緩解合法使用者流量和/或無法捕獲整個攻擊。
在此範例中，攻擊者還在 DNS 查詢洪水攻擊中隨機化了查詢網域。同時，合法的用戶端（或伺服器）也在查詢 `example.com`。他們被指派了一個隨機連接埠號，恰好是 1024。緩解系統偵測到一種模式（來源連接埠是 1024，查詢的網域是 `example.com`），該模式僅捕獲與指紋匹配的攻擊部分。緩解系統錯過了查詢其他主機名稱的攻擊部分。最後，緩解系統錯誤地捕捉了與攻擊流量相似的合法流量。
隨機化 DNS 洪水攻擊的簡化圖
這只是指紋辨識為何無法阻止隨機 DDoS 攻擊的一個非常簡單的範例。當攻擊者透過信譽良好的公用 DNS 解析程式（DNS解析程式，也稱為遞迴 DNS 伺服器，是一種負責從各種其他 DNS 伺服器追蹤網站 IP 位址的 DNS 伺服器類型）「洗白」他們的攻擊流量時，這種挑戰就會被放大。這就是所謂的 DNS Laundering 攻擊。
DNS 解析過程圖
在 DNS Laundering 攻擊期間，攻擊者查詢由受害者的權威 DNS 伺服器管理的真實網域的子網域。定義子網域的首碼是隨機的，並且不會多次使用。由於隨機化元素，遞迴 DNS 伺服器不可能擁有已快取的回應，需要將查詢轉寄至受害者的權威 DNS 伺服器。然後，權威 DNS 伺服器就會被過多的查詢轟炸，直到其無法處理合法查詢，甚至完全崩溃。
DNS Laundering 攻擊圖
複雜 DNS DDoS 攻擊的複雜性在於其自相矛盾的性質：雖然它們相對容易偵測，但非常難以有效緩解。這種困難源於這樣一個事實：權威 DNS 伺服器不能簡單地封鎖來自遞迴 DNS 伺服器的查詢，因為這些伺服器也會發出合法請求。此外，權威 DNS 伺服器無法篩選針對目標網域的查詢，因為它是需要維持可存取性的真實網域。
使用 Advanced DNS Protection 系統緩解複雜的 DNS 型 DDoS 攻擊
這些複雜的 DNS 型 DDoS 攻擊的興起促使我們開發一種新的解決方案，來更好地保護我們的客戶並彌補更傳統的指紋辨識方法的差距。這個解決方案就是 Advanced DNS Protection 系統。與 Advanced TCP Protection 系統類似，它是我們建立的軟體定義系統，由我們的具狀態緩解平台 flowtrackd（流程追蹤精靈）提供支援。
Advanced DNS Protection 系統補充了我們現有 DDoS 防禦系統套件的不足。與我們其他 DDoS 防禦系統相同，Advanced DNS Protection 系統也是分散式系統，它的執行個體在世界各地的每台 Cloudflare 伺服器上執行。一旦系統啟動，每個執行個體都可以自主偵測和緩解攻擊，無需任何集中監管。偵測和緩解是即時的（零秒）。每個執行個體也與資料中心其他伺服器上的其他執行個體進行通訊。它們_閒聊_並分享威脅情報，以在每個資料中心內提供全面的緩解措施。
Cloudflare 儀表板的螢幕截取畫面，顯示 Advanced DNS Protection 系統緩解的一次 DNS 型 DDoS 攻擊
我們基於指紋辨識的系統（DDoS 防護受管理規則集）和具狀態緩解系統共同提供了強大的多層防禦策略，以防禦最複雜和隨機的 DNS 型 DDoS 攻擊。該系統也是可自訂的，允許 Cloudflare 客戶根據自己的需求進行定制。查看我們的文件以取得有關設定選項的更多資訊。
Cloudflare 的 DDoS 防護系統圖
我們還新增了以 DNS 為中心的新資料點，以協助客戶更瞭解其 DNS 流量模式和攻擊。這些新資料點可在 Cloudflare 網路分析儀表板內的新「DNS 保護」索引標籤中找到。該新索引標籤提供了有關傳遞和捨棄哪些 DNS 查詢的深入解析以及這些查詢的特徵（包括查詢的網域名稱和記錄類型）。也可以使用 Cloudflare GraphQL API 並透過 Logpush 將記錄匯出到您自己的監控儀表板來取得分析。
為了防範複雜且高度隨機的 DNS 型 DDoS 攻擊，我們需要更好地確定哪些 DNS 查詢對我們的客戶來說可能是合法的。然而，僅憑查詢名稱很難推斷哪些是合法的，哪些可能是攻擊的一部分。我們不能完全依賴基於指紋的偵測機制，因為有時看似隨機的查詢，如 abc123.example.com 可能是合法的。反過來也是如此：針對 mailserver.example.com 的查詢可能看起來合法，但最終可能不是客戶的真正子網域。
更糟的是，我們基於第 3 層封包路由的緩解服務 Magic Transit 使用直接伺服器回傳 (DSR)，這意味著我們無法看到 DNS 來源伺服器的回應，從而獲得哪些查詢最終合法的回饋。
具有直接伺服器回傳 (DSR) 的 Magic Transit 圖
我們認為，應對這些攻擊的最佳方法是根據我們建立的歷史記錄，建立每個客戶預期 DNS 查詢的資料模型。有了這個模型，我們就可以更有信心地確定哪些查詢可能是合法的，並捨棄我們認為不合法的查詢，從而保護客戶的 DNS 伺服器。
這是 Advanced DNS Protection 的基礎。它檢查傳送給 Magic Transit 客戶的每個 DNS 查詢，並根據資料模型和每個客戶的個人設定傳遞或捨棄它們。
為此，我們全球網路中的每台伺服器都會不斷向我們的核心資料中心傳送某些與 DNS 相關的資料，例如查詢類型（如 A 記錄）和查詢的網域（但不是查詢的來源），我們在其中定期計算每個客戶的 DNS 查詢流量設定檔。這些設定檔分佈在我們的全球網路中，在這些網路中查閱它們可以幫助我們更自信、更準確地確定查詢是否合法。我們會根據客戶的設定，考慮客戶對意外 DNS 查詢的容忍度，捨棄不良查詢並傳遞良好的查詢。
解決設計 Advanced DNS Protection 系統時出現的技術挑戰
在建構這個系統時，我們面臨幾個具體的技術挑戰：
我們每天在全球網路上為 Magic Transit 客戶處理數千萬個 DNS 查詢（不包括 Cloudflare 的其他 DNS 產品套件），並使用上述 DNS 相關資料來建立自訂查詢流量設定檔。分析此類資料需要仔細處理我們的資料管道。在構建這些流量設定檔時，我們在寫入和讀取必要的資料時分別使用寫入時採樣和自適應位元速率技術，以確保我們以細粒度擷取資料，同時保護我們的資料基礎架構，並且我們會捨棄可能影響終端使用者隱私的資訊。
我們的一些客戶每天都會看到數千萬次 DNS 查詢。以未壓縮格式儲存和分發如此大量的資料將非常昂貴。為了解決這個挑戰，我們決定對每個客戶的流量設定檔使用 Counting Bloom Filter。這是一種機率資料結構，使我們能夠簡明地儲存和分發每個客戶的 DNS 設定檔，然後在處理封包時有效地查詢它。
我們需要定期重新計算資料中心之間每個客戶的 DNS 流量設定檔並將其重新分配到我們裝置群中的每個伺服器。我們使用自己的 R2 儲存服務來大幅簡化此任務。啟用區域提示和自訂網域後，我們啟用了快取並僅使用了少數 R2 貯體。每次我們需要更新邊緣裝置群中客戶資料模型的全域檢視時，98% 的傳輸位元都是從快取提供的。
當新網域名稱投入使用時，我們的資料模型不會立即意識到它們，因為以前從未見過使用這些名稱的查詢。因為這一點以及一些其他原因，可能導致誤判，這要求我們需要在系統中建立一定程度的容忍度，以允許潛在的合法查詢。我們透過利用權杖貯體演算法來做到這一點。客戶可以透過變更 Advanced DNS Protection 系統的敏感層級來設定權杖貯體的大小。敏感度越低，權杖貯體越大，反之亦然。較大的權杖貯體可以更好地容忍意外的 DNS 查詢和偏離設定檔的預期 DNS 查詢。高敏感度層級意味著更小的權杖貯體和更嚴格的方法。
歸根結底，這些都是 Cloudflare 擅長解決的挑戰類型。我們的客戶信任我們能夠處理他們的流量，並確保他們的網際網路內容受到保護、可用且高效能。我們非常重視這種信任。
Advanced DNS Protection 系統利用我們的全球基礎架構和資料處理能力以及智慧演算法和資料結構來保護我們的客戶。
如果您還不是 Cloudflare 客戶，且想要保護您的 DNS 伺服器，請告訴我們。現有 Cloudflare 客戶可以透過聯絡其客戶團隊或 Cloudflare 支援來啟用新系統。