新聞中心
NEW CENTER
聯係澳門AG視訊
官網:http://www.jxkzhb.com
電話:0518-85827858
郵箱:18936669530@189.cn
地址:連雲港市花果山的大道17號科創城3號樓902室
行業動態
當前位置:首頁>新聞中心>行業動態
一種新型的DDoS:“胡亂域名”攻擊
文章來源:江蘇澳門AG視訊計算機科技有限公司   發布時間:2015-02-06   瀏覽量:350

文章來自安全牛,原文鏈接:http://www.aqniu.com/threat-alert/6568.html

       一種針對域名服務器的新型分布式拒絕服務攻擊(DDoS),可稱之為“胡亂域名”(Nonsense Name)攻擊。它能給遞歸域名服務器和權威域名服務器(authoritative name servers)造成嚴重破壞。這種“無意義域名”DDoS攻擊通常是這樣進行的:
– 攻擊者選定一個域作為目標,比如someone.example。
– 在目標域內,攻擊者操縱僵屍網絡產生大量隨機域名。這些隨機域名的頭部都是些諸如asdfghjk、zxcvbnm之類的無意義的字符,製造出來的域名形如:asdfghjk.someone.example和zxcvbnm.someone.example。
– 然後向遞歸域名服務器發起大量針對這些無意義域名的查詢請求。
– 遞歸域名服務器轉而將請求發送到someone.example的權威服務器以查詢這些域名。
– 權威域名服務器返回‘請求的域名不存在’的響應(NXDOMAIN)。
– 遞歸服務器中繼轉發這一響應給原始請求者,並緩存下域名不存在的記錄。
– 請求,響應,緩存,再來一遍。反反複複無窮盡。
如果攻擊者發起這種胡亂域名解析請求的速度足夠快,聚合查詢的速度將令someone.example權威域名服務器應接不暇瀕臨崩潰。真正的傷害就發生了:
– 僵屍主機繼續向遞歸域名服務器發送無意義域名的查詢請求。
– 權威域名服務器終於崩潰,不再響應請求,遞歸域名服務器也就需要花費長得多的時間來處理單個域名解析請求。如果采用的是BIND域名服務器,那麽服務器會等待30秒,並在放棄之前發出幾十個(未解決的)查詢請求。
– 這將占用遞歸域名服務器上的遞歸查詢時間片,最終導致資源耗盡,拒絕接受其他遞歸查詢——盡管其中包含了合法的查詢請求。
一旦發生這種狀況,BIND域名服務器會向係統日誌中寫入一條消息,形如:
       Jan 21 14:44:00 ns1 named[4242]: client 192.168.0.1#1110: no more recursive clients: quota reached
       至此,域名服務器拒絕任何新入遞歸請求,停止向客戶提供服務。
       攻擊目標是個迷
       大多數情況下,運營權威域名服務器的機構(本例中是為someone.example提供權威域名解析的)似乎是攻擊者的目標。比如說,澳門AG視訊觀察到的某些被攻擊的域名就是國內博彩網站使用的(也許是有人因為損失慘重而對莊家進行報複?)無論如何,遞歸服務器終歸是無辜中箭,連帶崩潰。他們確實是目標麽?
       比如之前,Infoblox的客戶遭受攻擊的域中有部分在攻擊過後神秘消失了一天或兩天,表明這些域並沒有被使用(事實上很可能是被“試探性搶注”了)。攻擊者可能故意將這些域注冊到慢速或停止響應的域名服務器上,這樣域內的域名解析就會無限漫長。
       當然,拋開目標問題不談,攻擊背後的機製也同樣迷霧重重。
       解決辦法
       一般而言,當遞歸域名服務器開始發生遞歸查詢時間片資源不足的情況時,你就可以從早先記錄下的係統日誌消息中發現無意義域名攻擊的蹤跡。這些日誌消息記錄了由於時間片缺乏而被拒絕服務的查詢者的IP地址。
       首先,確認日誌記錄中的這些IP地址是否是你的域名服務器應該服務的範圍。如果不是,你簡單利用訪問控製列表將域名服務器配置為隻為已授權用戶提供服務即可。如果惡意查詢來自合法IP地址,很顯然,你得換個手段阻止他們。
       備選方案之一就是使用BIND提供的極為順手的響應策略域(RPZ)功能,它可以暫時性阻止你的域名服務器為問題域提供查詢服務。用以阻止你的域名服務器查找someone.example域名的RPZ規則可以如此簡單:
       *.someone.example.your.rpz.zone. IN CNAME .
       當然,除此之外,你還需要將qname-wait-recurse選項設置為no。這可以使你的域名服務器不詢問someone.example域名服務器就直接向所有someone.example域內的域名解析請求返回NXDOMAIN響應。
       如果你的遞歸域名服務器還沒升級到BIND9.10及其以上,或者根本就沒用BIND,你也可以通過設置一個空someone.example域來避免服務器嚐試在問題域查找數據。域數據文件可以極小化成這樣:
       @ IN SOA ns1 root 2015010700 1h 15m 30d 10m IN NS ns1
       將你的遞歸域名服務器配置為域內權威服務器——這個工作就留給讀者去完成啦——它就可以歡快地直接向大多數someone.example域名解析請求返回NXDOMAIN響應(詢問SOA或NS記錄的請求顯然不在此列)。
       隻有一點需要記住:RPZ規則或者域配置都是臨時的。攻擊結束後,你還得取消它們以使該域的解析服務恢複正常。
       互聯網係統協會那些開發了BIND域名服務器的好兄弟們也在為更精妙地解決這一問題而思考新的機製。它們打算引入兩個新的配置選項:fetches-per-server和fetches-per-zone。
       fetches-per-server選項給遞歸域名服務器能向單個權威服務器發送的並發查詢請求數加上一個限製。這個限製實際上是動態的,會根據查詢權威服務器時的超時情況自動調整。Fetches-per-zone選項則是針對發往單個域的並發請求數加以限製。
       有了這兩個功能,管理員們應該就能減少BIND域名服務器成為無意義域名DDoS攻擊受害者的幾率了——不管有意或無意。