域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

自去年開(kāi)始，DDOS 攻擊已經(jīng)上升到了一個(gè)新的高度，其標(biāo)志性攻擊是針對(duì)國(guó)際反垃圾郵件聯(lián)盟和 cloudflare 的大規(guī)模 DDOS 攻擊，流量一度達(dá)到120G，當(dāng)然后面的 DDOS 遠(yuǎn)遠(yuǎn)超過(guò)了120G，不過(guò)這一次攻擊確實(shí)是歷史性的。

我們現(xiàn)在回過(guò)頭去看這些攻擊已經(jīng)清楚他們的攻擊來(lái)源是 DNS/NTP 等反射攻擊導(dǎo)致的，但是為什么 DNS和NTP 等服務(wù)具有如此厲害的能力呢?攻擊者是如何做到制造出如此巨大的流量的呢?DNS 這個(gè)在我們?nèi)粘＞W(wǎng)絡(luò)使用的時(shí)候再平常不過(guò)的服務(wù)是如何被利用來(lái)變成大規(guī)模攻擊的呢?

我們現(xiàn)在先提前給出最終答案，然后再進(jìn)行解釋：

1、DNS 使用了簡(jiǎn)單的 UDP 報(bào)文進(jìn)行客戶端和服務(wù)端之間的通訊;

2、DNS 是純天然的流量放大器，通過(guò)極小的請(qǐng)求返回很大的回應(yīng)數(shù)據(jù)包;

3、互聯(lián)網(wǎng)上充斥了大量的開(kāi)放 DNS 解析器，它們可以接受任何客戶端的請(qǐng)求而不會(huì)拒絕;

4、網(wǎng)絡(luò)的濫用導(dǎo)致很多地方可以發(fā)出偽造源 IP 地址的數(shù)據(jù)包。

這四個(gè)方面的問(wèn)題最終結(jié)合到了一起，形成了現(xiàn)在的 DNS 系統(tǒng)的格局，也使 DNS 系統(tǒng)成為了 DDOS 攻擊的重要問(wèn)題來(lái)源。一次正常的 DNS 請(qǐng)求可能發(fā)出的流量只有64bytes，但是它收到的回應(yīng)可能遠(yuǎn)遠(yuǎn)超過(guò)這個(gè)數(shù)，在某些特定場(chǎng)合下，這個(gè)流量被放大的比率可以輕輕松松超過(guò)50倍。按照這個(gè) 比率計(jì)算，如果通過(guò)一個(gè)僵尸網(wǎng)絡(luò)來(lái)同時(shí)發(fā)送 DNS 請(qǐng)求的話，那么生成G/s的流量是十分輕松的，如果是使用了 DNSSEC 的話，流量還將更大。

現(xiàn)在的問(wèn)題在于，實(shí)質(zhì)上這些流量和其他流量一樣都是看似正常的流量，所以簡(jiǎn)單的過(guò)濾機(jī)制對(duì)此將不起作用，我們需要尋求更深層次的解決方案來(lái)解決這個(gè)長(zhǎng)期困擾互聯(lián)網(wǎng)的問(wèn)題。

在這個(gè)問(wèn)題的討論上，其中一個(gè)講到如果大家在實(shí)施網(wǎng)絡(luò)的時(shí)候都按照 BCP38 來(lái)實(shí)施的話，可以阻止虛假 IP 地址發(fā)送 DNS 請(qǐng)求，從而阻止了利用 DNS 進(jìn)行反射放大的攻擊。當(dāng)然這個(gè)話題已經(jīng)久到比 BCP38 本身還要早，BCP38 作為一個(gè)文檔已經(jīng)存在了13年之久，但令人不爽的是這仍然未能改變?cè)谶^(guò)去的13年里層出不窮的源 IP 偽造攻擊，所以在未來(lái)數(shù)個(gè)月甚至若干年內(nèi)我們也不要對(duì)此報(bào)太大期望。

另外一個(gè)討論是說(shuō)解析器應(yīng)該實(shí)施應(yīng)答頻率限制(response rate limiting，RRL)，默默地將超過(guò)閾值的重復(fù)請(qǐng)求丟棄掉，這個(gè)對(duì)于權(quán)威 DNS 來(lái)說(shuō)確實(shí)相當(dāng)?shù)挠行?，但是?duì)于遞歸解析器群來(lái)說(shuō)效果就差很多，因?yàn)楣粢坏┥⒉降礁鱾€(gè)遞歸服務(wù)器，那么分?jǐn)傁氯ブ竽軌驒z測(cè)到的頻率就可能達(dá)不到檢測(cè)閾 值。盡管如此，權(quán)威 DNS 服務(wù)器實(shí)施 RRL 仍然是很好的選擇。

另外一個(gè)討論是說(shuō)，關(guān)閉掉這些開(kāi)放遞歸查詢服務(wù)器，open resolver project()這個(gè)項(xiàng)目就是準(zhǔn)備干這個(gè)事情的，讓開(kāi)放查詢服務(wù)器的維護(hù)者自行檢查配 置，把有問(wèn)題的查詢器關(guān)閉掉，和 BCP38 的被接收程度差不多，也不要太指望這個(gè)途徑能有太大作用。部分原因是因?yàn)榇罅康倪f歸服務(wù)器都疏于管理。

DNS 服務(wù)器接收小包請(qǐng)求產(chǎn)生打包回應(yīng)的這一行為已經(jīng)成為了 DNS 的固有屬性，特別針對(duì) DNSSEC 而言更是如此，我們既想要對(duì) DNS 解析結(jié)果有安全保障，又想要速度快，那么必然會(huì)選擇 UDP 協(xié)議，結(jié)合上無(wú)處不在的遞歸 DNS 查詢服務(wù)器，這就導(dǎo)致了回應(yīng)包的變大，最終導(dǎo)致了這一平臺(tái)成為了大流量攻擊的神器。

如果我們想要徹底解決掉利用 DNS 進(jìn)行大規(guī)模攻擊的難題，留給我們發(fā)揮的空間已經(jīng)很小很小了。然而仍然還存在一個(gè)關(guān)于 DNS 是否使用 UDP 的看法在延續(xù)。

在原版 RFC1123 中允許了 UDP 和 TCP 兩種方式作為 DNS 服務(wù)的協(xié)議，與此有關(guān)的一段是這么描述的：

“在不久的將來(lái)新的 DNS 記錄類型會(huì)超過(guò)512bytes的限制已經(jīng)非常明顯，據(jù)此基于 TCP 的 DNS 是需要的，所以遞歸解析器和權(quán)威服務(wù)器需要支持 TCP 方式提供服務(wù)作為當(dāng)下使用 UDP 方式的后備方案，今后必將用到 TCP 方式。”

(為什么是512bytes呢?這個(gè)限制是來(lái)自于ipv4 主機(jī)需求定義(RFC1122)，所有支持ipv4的系統(tǒng)都必須能夠接收至少576bytes，20bytes的IP header，8bytes的 UDP header和40bytes的ip options，這就決定的單個(gè) UDP 包的大小最大就512bytes)

現(xiàn)如今 IPv4 中生成更大的包已經(jīng)成為可能，理論最大可以達(dá)到65535bytes，UDP包大小可達(dá)65507bytes，但是如此大的包在傳輸過(guò)程中是會(huì)被分片的， 在這種情況下，典型的防火墻規(guī)則能夠?qū)ζ浜蟮陌M(jìn)行阻斷，可能導(dǎo)致其無(wú)法到達(dá)客戶端，這是由于很多防火墻是基于 UDP 和 TCP 端口地址的。因這些被分片的包本身并不包含 UDP 或 TCP 頭部，這使得防火墻陷入了窘境，到底是允許呢還是允許呢?這種情境下防火墻可能最終妥協(xié)繼而使得部分攻擊得逞?；蛘呤莵G棄掉所有的分片?考慮到這兩方面的 因素，傳統(tǒng) DNS 的做法是限制 UDP 回應(yīng)包大小為512bytes，且當(dāng)包大小超過(guò)512bytes的時(shí)候總是啟用 TCP 作為備用措施。

然而，客戶端或許并不知道 DNS 回應(yīng)包的大小會(huì)超過(guò)512bytes，所以為了通知客戶端使用 TCP 來(lái)接收整個(gè) DNS 響應(yīng)， DNS 解析器會(huì)發(fā)送給客戶一個(gè)設(shè)置了"truncated"位的回應(yīng)。

我們一直在這個(gè)途徑上堅(jiān)持了很多年， DNS 在大多數(shù)情況下使用 UDP 進(jìn)行通訊，只有在極少情況下才會(huì)啟用 TCP 通信。這種做法在后來(lái)我們考慮為 DNS 解析添加安全證書(shū)機(jī)制的時(shí)候就顯得不是那么爽了，隨著 DNSSEC 的加入已經(jīng)很少有響應(yīng)包可以做到不超過(guò)512bytes了，由 UDP 轉(zhuǎn)換為客戶端通過(guò) TCP 重發(fā)的機(jī)制勢(shì)必會(huì)導(dǎo)致解析的延遲。

就像 RFC5966 中寫(xiě)的那樣：

由于 DNS 的核心原型已定， DNS 擴(kuò)展機(jī)制也被提出(EDNS0 RFC2671),這套機(jī)制可以用來(lái)表明客戶端可以接收大小超過(guò)512bytes的包，一個(gè) EDNS0 兼容的客戶端向兼容服務(wù)端發(fā)送的包可以是由客戶端 buffer size 大小指定的包大小而無(wú)需分片。

EDNS0 允許基于 UDP 的回應(yīng)包擁有更大的大小，這時(shí) TCP 已經(jīng)被當(dāng)作武功秘籍而為被廣為流傳了，僅僅被用來(lái)做域傳送，如果不想啟用域傳送的話，似乎 TCP 就完全不起任何作用了。

在 RFC1123 中有關(guān)主機(jī)的必要條件是這么描述的：

DNS 解析器和第歸服務(wù)器必須支持 UDP，可以支持 TCP 來(lái)發(fā)送查詢請(qǐng)求。

但是基于 TCP 的 DNS 不光是可以支持較大的 DNS 響應(yīng)，如果我們重新審視一下大規(guī)模 DNS 反射攻擊的先決條件，普遍的 UDP 大包響應(yīng)，以及缺乏實(shí)施的 BCP38，使得攻擊者可以通過(guò)源 IP 偽造的手段對(duì)目標(biāo)進(jìn)行攻擊。

TCP 不會(huì)出現(xiàn)此問(wèn)題，如果攻擊者通過(guò)偽造源 IP 來(lái)發(fā)起 TCP 請(qǐng)求的話，目標(biāo) IP 頂多只會(huì)收到一個(gè)很小的包，(40bytes)，只包含了 SYN 和 ACK 標(biāo)記，目標(biāo)系統(tǒng)由于沒(méi)有已經(jīng)建立了狀態(tài)的連接，這個(gè)包將會(huì)被丟棄掉，根據(jù)本地配置的不同，目標(biāo) IP 可能會(huì)發(fā)送一個(gè) TCP RESET 包給另一端來(lái)表明 state 的不確立，或者僅僅是默默的丟棄掉，這樣 DNS 攻擊的流量放大作用就沒(méi)有效的解決掉。

如果說(shuō) DNS 系統(tǒng)已經(jīng)使得整個(gè)互聯(lián)網(wǎng)面臨了如此巨大的問(wèn)題的話，那么是否我們就應(yīng)該停止使用EDNS0所支持的較大的 UDP 回應(yīng)包，繼而使用 TCP 來(lái)傳輸較大的請(qǐng)求?

我們?cè)賮?lái)看一下 RFC5966：

多數(shù) DNS 服務(wù)運(yùn)營(yíng)商已經(jīng)支持 TCP 且默認(rèn)的軟件配置也是支持 TCP 的，此文檔的主要受眾是那些。。。

這個(gè)地方我們需要看到的問(wèn)題是，我們?nèi)绾文軌蛄炕?DNS 支持 TCP 請(qǐng)求和回應(yīng)的覆蓋度?這里只的“多數(shù)”到底是多少?

通過(guò)測(cè)驗(yàn)發(fā)現(xiàn)，大部分的 DNS 系統(tǒng)對(duì) TCP 類型的報(bào)文是可以響應(yīng)的，也就是說(shuō)，利用 TCP 來(lái)回復(fù)大包以組織 DNS 使用 UDP 發(fā)送大包這一做法是切實(shí)可行的，不支持 TCP 的那部分 DNS 系統(tǒng)要么是由于主備DNS的配置導(dǎo)致其請(qǐng)求第一個(gè)服務(wù)器不通進(jìn)而請(qǐng)求下一個(gè)服務(wù)器，要么是一些其他的問(wèn)題，也就是說(shuō)，在處理TCP有問(wèn)題的DNS服務(wù)器里 也只是有部分是真實(shí)存在問(wèn)題的。

如果你是DNS系統(tǒng)管理員的話，我們建議:

1、盡量不要維護(hù)一些很小的開(kāi)放DNS解析服務(wù)，這些事情是網(wǎng)絡(luò)運(yùn)營(yíng)商該干的;

2 、權(quán)威DNS一定要對(duì)請(qǐng)求頻率加以限制，如果是使用 bind 的話可以利用 bind 自帶的 RRL 個(gè)功能進(jìn)行頻率限制，如果是 PDNS 的話可以通過(guò)防火墻規(guī)則來(lái)限制;

3、對(duì) DNS 系統(tǒng)進(jìn)行全面的檢查，對(duì) DNS 系統(tǒng)進(jìn)行配置檢查，以防止出現(xiàn)一些低級(jí)錯(cuò)誤等。只有通過(guò)多方面的努力，才能將 DDOS 攻擊影響逐步小化。來(lái)源：，轉(zhuǎn)載請(qǐng)注明出處，謝謝!

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！