雖然現(xiàn)在看來已經(jīng)可以算是陳年舊事，但就在互聯(lián)網(wǎng)剛剛誕生的約二十年前，我們曾面臨著一個巨大的難題：郵件服務器太過友好。

簡而言之，大多數(shù)郵件服務器允許任何人進行接入，并將郵件發(fā)送給任何收件者。要實現(xiàn)這一切，我們甚至不需要作為郵件服務器的用戶，或者只需要費一點小勁來將自己偽裝成用戶即可。

攻擊者能夠利用郵件服務器的郵件SMTP接收端口(TCP端口25)來實現(xiàn)連接，并模仿全部SMTP服務器用于交換郵件的內部命令發(fā)送各類操作(通過telent、腳本或者其它程序)。如此一來，黑客將能夠偽造電子郵件、宣稱其來自郵件服務器所托管的某位合法用戶并將任意郵件內容發(fā)送給任意收件人。

垃圾郵件發(fā)送者會尋找這類“開放轉發(fā)”服務器，并將成千萬甚至上億封垃圾郵件發(fā)送到世界各地。全球技術人員——以及郵件服務器供應商——花了約二十年時間來強制要求所有始發(fā)郵件必須進行實際來源驗證，且由認證用戶所發(fā)出。

然而在多年之后，類似的開放轉發(fā)問題又出現(xiàn)在互聯(lián)網(wǎng)領域的另一大基礎性技術當中，即DNS。攻擊者經(jīng)常會利用配置不當?shù)腄NS服務器向查詢客戶端發(fā)送無效IP地址——或者發(fā)送大量虛假流量以實施DDoS攻擊。

利用DNS實施DDoS攻擊

DDoS以及其它攻擊者多年來一直在利用DNS實施他們的邪惡陰謀，但在過去幾年當中，這種狀況出現(xiàn)了愈演愈烈之勢。

最近一段時間來，多數(shù)大規(guī)模DDoS攻擊者開始頻繁利用DNS“放大”技術。如果大家對其具體實現(xiàn)方式及背景信息感興趣，可以查看US-CERT、互聯(lián)網(wǎng)系統(tǒng)聯(lián)盟以及CloudFlare上的相關資料(英文原文)。

最終，DNS服務器供應商與協(xié)議開發(fā)商不得不采取對應措施，而這一切正如當年SMTP郵件供應商所作出的保護努力一樣。其中包括更理想的默認設置及新型防御機制。不過遺憾的是，DNS服務器——雖然它們看起來可能運行良好——仍然被人們所忽視，而且繼續(xù)保留著攻擊者不希望管理方發(fā)現(xiàn)的大量安全漏洞。

禁用開放轉發(fā)DNS服務器

每一家企業(yè)客戶都能夠輕松實現(xiàn)的保護手段就是限定自身DNS服務器對哪些以及來自誰的請求做出響應。對于內部DNS服務器而言，我們需要確保其只會針對來自內部計算機或者其它認證DNS服務器的查詢給出DNS響應。

即使是在外部環(huán)境下，面向公眾的DNS服務器也不應該以無腦方式對所有請求做出響應。如果大家的DNS服務器托管于*.example.com地址，那么絕對不會有合法用戶在該域名之外進行域名地址查詢。如果大家的DNS服務器當前會對來自任何使用者的全部查詢做出響應，特別是來自任意域名的請求，那么這就是一臺開放轉發(fā)DNS服務器——相信我，這絕不是什么好事。

為了確保我們的DNS服務器不被劃歸為開放轉發(fā)一類，并對其進行嚴格鎖定并保證其合法運作，請將其IP地址輸入到以下各DNS開放轉發(fā)檢測服務中進行安全性測試：

· Open Resolver Project

· Open DNS Resolver Check Site

· DNS Expertise - The Measurement Factory

· DNS Inspect

DNS響應速率限制

作為防止自有DNS服務器被用于DDoS攻擊活動的最佳防御手段之一，我們應當對其進行響應速率限制(簡稱RRL)。RRL主要面向權威DNS服務器(即那些應當對一個或者多個域名進行響應的DNS服務器)，且允許DNS管理員針對DNS響應流量作出有效速率限制。盡管在默認情況下并未啟用(但絕對應該被啟用!)，我們可以在BIND 9.9(及其后續(xù)版本)當中找到RRL，其同時也作為微軟即將推出的Windows Server 2016 DNS服務的組成部分。

如果大家的DNS服務器并不支持RRL，則可以嘗試利用其它備選方案實現(xiàn)同樣的效果，包括使用防火墻速率過濾或者其它反DDoS服務來保護自己的DNS。

禁用向上轉介響應

對于大多數(shù)DNS來講，當某臺非遞歸權威DNS服務器收到一條未經(jīng)認證的域名查詢時，該DNS服務器會直接將該查詢客戶重新定向至頂級域名DNS服務器(能夠在文件托管‘root hints’當中按照名稱及IP地址進行排列)。這是一種較為禮貌的作法，類似于“嘿，我不知道答案是什么，但我建議你到那邊試試運氣。”

但事實上，這種方式相當于因為個人原因而毀掉大家的生活，而DNS放大攻擊的出現(xiàn)也使得這種使用root hints的方式飽受詬病。BIND長久以來一直建議大家禁用這一向上轉介行為。微軟公司計劃在其Windows Server 2016當中默認禁用向上轉介機制，而大家也可以通過刪除該root hints文件(具體位置為c:\windows\system32\DNS\cache.dns)的方式在其它Windows Server早期版本中禁用該功能。

檢查所有DNS服務

針對計算機及設備用于接收連接的TCP或者UDP端口53進行掃描，從而檢查所有運行有DNS服務的計算機及設備并對其進行安全配置。一般來講，大家會發(fā)現(xiàn)其中存在著一些運行有計劃外DNS服務器的裝置及網(wǎng)絡設備(例如無線路由器等)。

開門揖盜最為愚蠢

DNS協(xié)議自從1983年誕生以來就一直擁有良好的實際表現(xiàn)。它雖然也經(jīng)歷過被濫用以及后續(xù)更新作為補救的狀況，但總體而言，它仍然扮演著保障互聯(lián)網(wǎng)正常運轉的核心角色。不過我們絕不能夠對現(xiàn)有安全水平盲目自滿，特別是在DNS方面。

在文章的最后，我要提醒大家千萬別讓自己的DNS服務器重復當初公共郵件服務器的覆轍——作為現(xiàn)代IT世界中的一員，我們不可能再拿出十年時間來解決那些早就該進行修復的問題。