眾所周知，DNS 是一種非?；镜膮f議 / 服務，它讓互聯網用戶和網絡設備能發現使用人類可讀的域名，而非純數字 IP 地址的網站。AWS 的這篇文章詳細解釋了 DNS 的工作原理。如果 DNS 服務受到攻擊或無法正常工作，那么你的服務或網站很有可能無法訪問。

在本篇博文中，我會詳細解釋 DNS 服務面臨的主要威脅，以及相應的緩解策略。

文中使用的真實攻擊數據和相關統計均來自 Imperva 云 WAF 保護服務。

DDoS

分布式拒絕服務（ DDoS ）會在攻擊期間導致受害者服務無法訪問。根據 Techradar 的這篇文章，DDoS 的受害者甚至包括前沿的云服務提供商，比如亞馬遜AWS。

對DNS 基礎設施上的DDoS 攻擊分為以下幾種：

1. Straightforward/Naive DDoS

黑客使用僵尸網絡創建不同端點，在同一時間段向受害者域名服務器直接發送海量 DNS 請求。

這種攻擊會在短時間內產生大量流量，利用無數請求堵塞 DNS 服務器，讓其無法響應，從而達到拒絕正常用戶訪問的目的。

緩解措施

通過使用基于硬件的網絡設備或云服務解決方案可以過濾或限制網絡流量。在一場 naive DDoS 攻擊中，攻擊者不會欺騙源 IP，用于攻擊的源數量也有限制。因此，限制策略可以是攔截攻擊者使用的 IP。

DNS 默認依賴 UDP 協議，而由于 UDP 本身的特性導致，只需偽造數據包的 IP 地址，便可以輕易將源 IP 換成隨機 IP。在這種情況下，攔截 IP 地址變成了無用功，我們需要求助于別的方案。

緩解措施

使用 DNS 緩存服務器吸收大部分的 DNS 流量。

DDoS 攻擊者通常會使用不存在的域名以確保解析器會轉發請求，已存在域名有可能會被保存在緩存中，這樣的請求是不會被轉發的。針對這種情況，我們建議在 DNS 緩存服務器中使用以下措施來限制來自不存在域名的 DNS 請求轉發率。

如果傳入請求的總數量超過閾值，則要求客戶端從 UDP 切換到 TCP。切換后，由于 TCP 需要三次握手，則可以避免源 IP 欺騙。

下圖顯示了受到 Imperva 保護的權威 DNS 服務器在遭到一次 DDoS 攻擊時的表現：

這次攻擊持續了 24 小時，Imperva 的 DNS 代理通過過濾和限制傳遞到服務器的請求速率來緩解 DDoS 攻擊。因此，服務器收到的請求速率沒有超過配置閾值，超過這個限制的惡意流量會被攔截。

攻擊者不僅會欺騙源 IP，連目的地 IP 也不會放過。來自正常 DNS 解析器的 DNS 回答會被發回給受害者（被欺騙的 IP），而不是原攻擊者的 IP，從而導致受害者受到 DDoS 攻擊。

這類攻擊模式會放大 DDoS 的影響：黑客精心設計了能觸發大量 DNS 回答的 DNS 請求，從而達到擴大傷害的效果。舉例來說，“ANY”類請求或具有多個 DNS 記錄的請求將觸發大量 DNS 回答。

在這種情況下，合法的 DNS 服務器反而會協助攻擊。

緩解措施

限制統一 IP 地址的 DNS 請求 / 回答速率。

因為 DNS 解析器會使用緩存，所以理論上來講，請求轉發率會十分低，一定的頻率限制應當會有效。

下圖顯示了一位受到 Imperva 保護的客戶基礎架構，在遭到嚴重 DDoS 綜合攻擊后的表現：

在這次 DDoS 攻擊中，黑客使用了兩種不同方式：

二者相結合，黑客成功實施了 100 Gbps 的 DDoS 攻擊。

在這次攻擊中，DNS 應答數據包平均是 1400 bytes，使得攻擊的放大倍數為 20。通過利用 3.5 Gbps 帶寬的 DNS 請求，黑客設法將 DNS 反射型 DDoS 攻擊放大到 70 Gbps。反射型攻擊方法非常普遍且強大。

與目標在于阻塞 DNS 服務器的 DDoS 攻擊不同，緩存投毒的目標是將訪客從真正的網站重定向到惡意網站。

攻擊階段

黑客發送 DNS 請求到 DNS 解析器，解析器會轉發請求到 Root/TLD/ 權威 DNS 服務器并等待回答。
黑客隨后發送大量包含惡意 IP 地址的投毒響應到 DNS 服務器。黑客需要搶在權威 DNS 回答之前用偽造響應命中正確的端口與查詢 ID，這一步可以通過蠻力來提高成功機會。
任何正常用戶請求該 DNS 解析器都會得到緩存中被投毒的響應，然后被重定向到惡意網站。

緩解措施

使用 DNSSEC。DNSSEC 通過提供簽名過的 DNS 回答來阻止這類攻擊。使用 DNSSEC 的 DNS 解析器會驗證其從 Root/Top Level Domain (TLD)/ 權威 DNS 服務器得到的簽名響應。
下列措施可以讓黑客更難成功：對每條請求使用隨機查詢 ID 對每條請求使用隨機源端口丟棄重復的轉發請求確保響應中所有區域均與請求相符合：query ID、name、class 和 type

詳細清單請查看這篇文章。