自去年開始，DDOS 攻擊已經(jīng)上升到了一個新的高度，其標(biāo)志性攻擊是針對國際反垃圾郵件聯(lián)盟和 cloudflare 的大規(guī)模 DDOS 攻擊，流量一度達(dá)到120G，當(dāng)然后面的 DDOS 遠(yuǎn)遠(yuǎn)超過了120G，不過這一次攻擊確實(shí)是歷史性的。
我們現(xiàn)在回過頭去看這些攻擊已經(jīng)清楚他們的攻擊來源是 DNS/NTP 等反射攻擊導(dǎo)致的，但是為什么 DNS和NTP 等服務(wù)具有如此厲害的能力呢?攻擊者是如何做到制造出如此巨大的流量的呢?DNS 這個在我們?nèi)粘＞W(wǎng)絡(luò)使用的時候再平常不過的服務(wù)是如何被利用來變成大規(guī)模攻擊的呢?
我們現(xiàn)在先提前給出最終答案，然后再進(jìn)行解釋：
1、DNS 使用了簡單的 UDP 報(bào)文進(jìn)行客戶端和服務(wù)端之間的通訊;
2、DNS 是純天然的流量放大器，通過極小的請求返回很大的回應(yīng)數(shù)據(jù)包;
3、互聯(lián)網(wǎng)上充斥了大量的開放 DNS 解析器，它們可以接受任何客戶端的請求而不會拒絕;
4、網(wǎng)絡(luò)的濫用導(dǎo)致很多地方可以發(fā)出偽造源 IP 地址的數(shù)據(jù)包。
這四個方面的問題最終結(jié)合到了一起，形成了現(xiàn)在的 DNS 系統(tǒng)的格局，也使 DNS 系統(tǒng)成為了 DDOS 攻擊的重要問題來源。一次正常的 DNS 請求可能發(fā)出的流量只有64bytes，但是它收到的回應(yīng)可能遠(yuǎn)遠(yuǎn)超過這個數(shù)，在某些特定場合下，這個流量被放大的比率可以輕輕松松超過50倍。按照這個 比率計(jì)算，如果通過一個僵尸網(wǎng)絡(luò)來同時發(fā)送 DNS 請求的話，那么生成G/s的流量是十分輕松的，如果是使用了 DNSSEC 的話，流量還將更大。
現(xiàn)在的問題在于，實(shí)質(zhì)上這些流量和其他流量一樣都是看似正常的流量，所以簡單的過濾機(jī)制對此將不起作用，我們需要尋求更深層次的解決方案來解決這個長期困擾互聯(lián)網(wǎng)的問題。
在這個問題的討論上，其中一個講到如果大家在實(shí)施網(wǎng)絡(luò)的時候都按照 BCP38 來實(shí)施的話，可以阻止虛假 IP 地址發(fā)送 DNS 請求，從而阻止了利用 DNS 進(jìn)行反射放大的攻擊。當(dāng)然這個話題已經(jīng)久到比 BCP38 本身還要早，BCP38 作為一個文檔已經(jīng)存在了13年之久，但令人不爽的是這仍然未能改變在過去的13年里層出不窮的源 IP 偽造攻擊，所以在未來數(shù)個月甚至若干年內(nèi)我們也不要對此報(bào)太大期望。
另外一個討論是說解析器應(yīng)該實(shí)施應(yīng)答頻率限制(response rate limiting，RRL)，默默地將超過閾值的重復(fù)請求丟棄掉，這個對于權(quán)威 DNS 來說確實(shí)相當(dāng)?shù)挠行?，但是對于遞歸解析器群來說效果就差很多，因?yàn)楣粢坏┥⒉降礁鱾€遞歸服務(wù)器，那么分?jǐn)傁氯ブ竽軌驒z測到的頻率就可能達(dá)不到檢測閾 值。盡管如此，權(quán)威 DNS 服務(wù)器實(shí)施 RRL 仍然是很好的選擇。
另外一個討論是說，關(guān)閉掉這些開放遞歸查詢服務(wù)器，open resolver project()這個項(xiàng)目就是準(zhǔn)備干這個事情的，讓開放查詢服務(wù)器的維護(hù)者自行檢查配 置，把有問題的查詢器關(guān)閉掉，和 BCP38 的被接收程度差不多，也不要太指望這個途徑能有太大作用。部分原因是因?yàn)榇罅康倪f歸服務(wù)器都疏于管理。
DNS 服務(wù)器接收小包請求產(chǎn)生打包回應(yīng)的這一行為已經(jīng)成為了 DNS 的固有屬性，特別針對 DNSSEC 而言更是如此，我們既想要對 DNS 解析結(jié)果有安全保障，又想要速度快，那么必然會選擇 UDP 協(xié)議，結(jié)合上無處不在的遞歸 DNS 查詢服務(wù)器，這就導(dǎo)致了回應(yīng)包的變大，最終導(dǎo)致了這一平臺成為了大流量攻擊的神器。
如果我們想要徹底解決掉利用 DNS 進(jìn)行大規(guī)模攻擊的難題，留給我們發(fā)揮的空間已經(jīng)很小很小了。然而仍然還存在一個關(guān)于 DNS 是否使用 UDP 的看法在延續(xù)。
在原版 RFC1123 中允許了 UDP 和 TCP 兩種方式作為 DNS 服務(wù)的協(xié)議，與此有關(guān)的一段是這么描述的：
“在不久的將來新的 DNS 記錄類型會超過512bytes的限制已經(jīng)非常明顯，據(jù)此基于 TCP 的 DNS 是需要的，所以遞歸解析器和權(quán)威服務(wù)器需要支持 TCP 方式提供服務(wù)作為當(dāng)下使用 UDP 方式的后備方案，今后必將用到 TCP 方式。”
(為什么是512bytes呢?這個限制是來自于ipv4 主機(jī)需求定義(RFC1122)，所有支持ipv4的系統(tǒng)都必須能夠接收至少576bytes，20bytes的IP header，8bytes的 UDP header和40bytes的ip options，這就決定的單個 UDP 包的大小最大就512bytes)
現(xiàn)如今 IPv4 中生成更大的包已經(jīng)成為可能，理論最大可以達(dá)到65535bytes，UDP包大小可達(dá)65507bytes，但是如此大的包在傳輸過程中是會被分片的， 在這種情況下，典型的防火墻規(guī)則能夠?qū)ζ浜蟮陌M(jìn)行阻斷，可能導(dǎo)致其無法到達(dá)客戶端，這是由于很多防火墻是基于 UDP 和 TCP 端口地址的。因這些被分片的包本身并不包含 UDP 或 TCP 頭部，這使得防火墻陷入了窘境，到底是允許呢還是允許呢?這種情境下防火墻可能最終妥協(xié)繼而使得部分攻擊得逞?；蛘呤莵G棄掉所有的分片?考慮到這兩方面的 因素，傳統(tǒng) DNS 的做法是限制 UDP 回應(yīng)包大小為512bytes，且當(dāng)包大小超過512bytes的時候總是啟用 TCP 作為備用措施。
然而，客戶端或許并不知道 DNS 回應(yīng)包的大小會超過512bytes，所以為了通知客戶端使用 TCP 來接收整個 DNS 響應(yīng)， DNS 解析器會發(fā)送給客戶一個設(shè)置了"truncated"位的回應(yīng)。
我們一直在這個途徑上堅(jiān)持了很多年， DNS 在大多數(shù)情況下使用 UDP 進(jìn)行通訊，只有在極少情況下才會啟用 TCP 通信。這種做法在后來我們考慮為 DNS 解析添加安全證書機(jī)制的時候就顯得不是那么爽了，隨著 DNSSEC 的加入已經(jīng)很少有響應(yīng)包可以做到不超過512bytes了，由 UDP 轉(zhuǎn)換為客戶端通過 TCP 重發(fā)的機(jī)制勢必會導(dǎo)致解析的延遲。
就像 RFC5966 中寫的那樣：
由于 DNS 的核心原型已定， DNS 擴(kuò)展機(jī)制也被提出(EDNS0 RFC2671),這套機(jī)制可以用來表明客戶端可以接收大小超過512bytes的包，一個 EDNS0 兼容的客戶端向兼容服務(wù)端發(fā)送的包可以是由客戶端 buffer size 大小指定的包大小而無需分片。
EDNS0 允許基于 UDP 的回應(yīng)包擁有更大的大小，這時 TCP 已經(jīng)被當(dāng)作武功秘籍而為被廣為流傳了，僅僅被用來做域傳送，如果不想啟用域傳送的話，似乎 TCP 就完全不起任何作用了。
在 RFC1123 中有關(guān)主機(jī)的必要條件是這么描述的：
DNS 解析器和第歸服務(wù)器必須支持 UDP，可以支持 TCP 來發(fā)送查詢請求。
但是基于 TCP 的 DNS 不光是可以支持較大的 DNS 響應(yīng)，如果我們重新審視一下大規(guī)模 DNS 反射攻擊的先決條件，普遍的 UDP 大包響應(yīng)，以及缺乏實(shí)施的 BCP38，使得攻擊者可以通過源 IP 偽造的手段對目標(biāo)進(jìn)行攻擊。
TCP 不會出現(xiàn)此問題，如果攻擊者通過偽造源 IP 來發(fā)起 TCP 請求的話，目標(biāo) IP 頂多只會收到一個很小的包，(40bytes)，只包含了 SYN 和 ACK 標(biāo)記，目標(biāo)系統(tǒng)由于沒有已經(jīng)建立了狀態(tài)的連接，這個包將會被丟棄掉，根據(jù)本地配置的不同，目標(biāo) IP 可能會發(fā)送一個 TCP RESET 包給另一端來表明 state 的不確立，或者僅僅是默默的丟棄掉，這樣 DNS 攻擊的流量放大作用就沒有效的解決掉。
如果說 DNS 系統(tǒng)已經(jīng)使得整個互聯(lián)網(wǎng)面臨了如此巨大的問題的話，那么是否我們就應(yīng)該停止使用EDNS0所支持的較大的 UDP 回應(yīng)包，繼而使用 TCP 來傳輸較大的請求?
我們再來看一下 RFC5966：
多數(shù) DNS 服務(wù)運(yùn)營商已經(jīng)支持 TCP 且默認(rèn)的軟件配置也是支持 TCP 的，此文檔的主要受眾是那些。。。
這個地方我們需要看到的問題是，我們?nèi)绾文軌蛄炕?DNS 支持 TCP 請求和回應(yīng)的覆蓋度?這里只的“多數(shù)”到底是多少?
通過測驗(yàn)發(fā)現(xiàn)，大部分的 DNS 系統(tǒng)對 TCP 類型的報(bào)文是可以響應(yīng)的，也就是說，利用 TCP 來回復(fù)大包以組織 DNS 使用 UDP 發(fā)送大包這一做法是切實(shí)可行的，不支持 TCP 的那部分 DNS 系統(tǒng)要么是由于主備DNS的配置導(dǎo)致其請求第一個服務(wù)器不通進(jìn)而請求下一個服務(wù)器，要么是一些其他的問題，也就是說，在處理TCP有問題的DNS服務(wù)器里 也只是有部分是真實(shí)存在問題的。
如果你是DNS系統(tǒng)管理員的話，我們建議:
1、盡量不要維護(hù)一些很小的開放DNS解析服務(wù)，這些事情是網(wǎng)絡(luò)運(yùn)營商該干的;
2 、權(quán)威DNS一定要對請求頻率加以限制，如果是使用 bind 的話可以利用 bind 自帶的 RRL 個功能進(jìn)行頻率限制，如果是 PDNS 的話可以通過防火墻規(guī)則來限制;
3、對 DNS 系統(tǒng)進(jìn)行全面的檢查，對 DNS 系統(tǒng)進(jìn)行配置檢查，以防止出現(xiàn)一些低級錯誤等。只有通過多方面的努力，才能將 DDOS 攻擊影響逐步小化。來源：，轉(zhuǎn)載請注明出處，謝謝!
申請創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！
