24小時在綫聯繫:
服務郵箱 [email protected]
BigDDos网络防御
  • 首页
  • Web安全
  • DDos防禦
  • 業界新聞
  • 关于我们

DDoS之“胡亂域名”攻擊

BigDDos网络防御 > 業界新聞 > DDoS之“胡亂域名”攻擊

DDoS之“胡亂域名”攻擊

3月 12, 2016BigDDos業界新聞0 Comment

1457750603-6429-Mn6v6b

一種針對域名服務器的新型分布式拒絕服務攻擊(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提供權威域名解析的)似乎是攻擊者的目標。比如說,我們觀察到的某些被攻擊的域名就是國內博彩網站使用的(也許是有人因爲損失慘重而對莊家進行報複?)無論如何,遞歸服務器終歸是無辜中箭,連帶崩潰。他們確實是目標麽?

比如之前,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攻擊受害者的幾率了——不管有意或無意。

Tags: 新型ddos攻击

Written by BigDDos

头像

← 揭秘DDoS攻擊背後的産業鏈
FBI和蘋果沈默面對“IP盒” →
  • 20150417142027590.jpg

留言

VJUJQI

最新文章

  • 業界文章停更說明
    2019年12月31日
  • 最強DDOS攻擊達3.7萬GPS,目標轉向應用層?
    2017年4月2日
  • 企業如何選擇最佳的SSL
    2016年8月17日

服務

  • 99.9% 正常運行時間保證
  • 300+ Gbps DDoS 保護
  • 多種DDoS緩解措施
  • 多種防禦 DDoS 方案
  • 24/7/365 技術支持
  • Geo DNS
  • 3分鍾內即時響應

緩解中心

  • 華盛頓
  • 蒙特利爾
  • 洛杉矶
  • 倫敦
  • 芝加哥
  • 多倫多
  • 達拉斯
  • 東京
  • 俄羅斯
  • 西雅圖
  • 烏克蘭
  • 荷蘭
  • 瑞典
  • 溫哥華
  • 馬來西亞
  • 香港
本站所有文章除特别声明外,皆转自互联网。如有侵权请联系 BigDDos 删除。
Powered by BigDDos.com | Copyright © 2004 - 2019 BigDDos.com All Rights Reserved