在資安的軍備競賽中，駭客與資安人員似乎不斷地在找尋入侵與防範的手法。近年，研究人員發現駭客正在使用一種新興的技術──Fast-Flux，它其實算是一種DNS技術的新應用，使用的技術跟RRDNS (Round-robin DNS)或CDNs (Content Distributed Networks)很相似。
一些流量大的網站，如Google與Myspace，會將網站的域名迅速對應至不同的實體機器，以達到網路流量負載(Network Load Balance)的功能。相同地，Fast-Flux也是會不斷地變化網域對應的實體機器，比較不一樣的是，這些被對應的機器通常都是受害電腦設備，駭客則利用這些機器來保護其惡意的內容網站，如釣魚(phishing)網站、惡意程式下載站、及垃圾郵件內容網站。Support Intelligence的營運長Adam Waters
則說：「Fast-Flux不只是隱藏這些惡意網站的地方，而且是在你的面前說：『來抓我吧』，而你卻抓不到。」道出了追蹤Fast-Flux真正來源的困難性。
Fast-Flux技術介紹
在[1]文章中有詳細說明了Fast-Flux的技術，並定義了Single-Flux與Dougle-Flux二種類型的Fast-Flux網路。簡單地說，Fast-Flux是於DNS Resource Record(RR)上設定非常短的TTL，並以循序(Round-robin)的方式於一群IP中做替換，而這群IP則扮演了流量導向(Proxy)的角色。由圖1我們可以看出正常網路與Fast-Flux網路的差異，一般網站之網域查詢所得到的IP是固定不變的，而在Fast-Flux網路中查到的IP則是頻繁地變動，且使用者查詢的內容則不存在這些IP上面，它們只負責幫忙傳送給真正提供內容的伺服器(所謂的mothership)。
這對於用瀏覽器點選網頁的使用者而言，感覺不出其迥異，但是背後的實作技術與影響卻差異很大。對於駭客來說，使用Fast-Flux的好處是惡意網站受到保護使其不易被追查與延長了惡意網站的壽命。以釣魚網站為例，過去靠著各國CERT或資安組織的協助，一個釣魚網站的存活時間平均為3~4天，隨著Fast-Flux技術的流行，則拉長了釣魚網站的存活時間。對於事件處裡人員來說，Fast-Flux增加了追蹤與分析的困難度，因為這些IP散布於世界各地，而且並沒有惡意內容存留於這些機器上。
Double-Flux一樣是使用Fast-Flux的技術概念，但是使用的對象也包含了名稱伺服器(Name Server)，意思是Double-Flux除了DNS A Record不斷地變動，連DNS NS Record所對應的IP也頻繁地變動。從圖2可以我們可以看出Single-Flux與Double-Flux查詢DNS的差異，在不考慮DNS暫存(cache)的情況下，雖然使用者查詢DNS所得到的結果是一樣的，但是Single-Flux詢問的名稱伺服器的IP是固定的，而Double-Flux則是變動地，故其只是個流量導向的功能，不具有名稱伺服器的功能，真正的DNS回應記錄則在駭客所控制的上層主機(mothership)中，這表示駭客對其所掌握的名稱伺服器也做了保護的機制。
實例分析
從資安組織及網站所提供的資訊，發現一隻名叫Waledac的惡意程式使用了大量的Fast-Flux網域來傳播，我們利用dig網域查詢工具來觀看其中一個網域名稱為「obiassi.com」的變化，請詳見圖3。我們發現駭客將Fast-Flux網域的TTL設定為0，而且每次查詢所得到的IP都只有一筆，所以幾乎每次查詢都可以獲得不一樣的IP。比較特別的是，每次的DNS回應記錄都沒有Authority與Additional區塊的資訊，這和一般正常的DNS查詢所回應的方式不一樣，表示駭客所掌控的DNS 伺服器經過客製化，可能為了避免DNS伺服器被發現或是Fast-Flux網域被偵測到(有些偵測技術會針對名稱伺服器數量做為偵測的特徵[2,4])，而將這些資訊不回應於DNS查詢中。
我們挑選了10個網域經過近一週的時間(2009/7/5~2009/7/11)進行測試，發現每個Fast-Flux網域對應的不重複IP數量平均也有1113.4筆，最多的也有1289筆(詳見圖4)。此外我們亦發現很多IP同時都被很多Fast-Flux網域所使用，顯示駭客已經入侵大量受害IP並供這些Fast-Flux網域來使用。
偵測Fast-Flux網域
在Fast-Flux網域之偵測上已經有不少專家提出其偵測的方式[2,4,8]，而在偵測Fast-Flux網域之前最重要的即可疑網域的來源，才知道需要對什麼樣的網域進行偵測。從Fast-Flux參與的惡意活動[7]中，大都與釣魚網站、賣藥網站、賭博網站及惡意程式下載站有關，故從垃圾郵件或惡意程式使用之網域中是最容易發現Fast-Flux網域的出現，這也是為什麼目前的研究大多從垃圾郵件尋找的原因。
Holz et al.[2]針對DNS查詢回應的3個特徵來偵測Fast-Flux網路，分別如下：
- 在經過多次DNS查詢後，不重複的IP數量
- 在單一次DNS查詢中所的到名稱伺服器(NS)的數量
- 在經過多次DNS查詢後，所得到IP對應不重複之Autonomous System Number (ASN)數量
Fast-Flux網路使用了比較多的名稱伺服器，故其數量會比一般的DNS查詢所的到還多，而查詢ASN的原因主要是因為這些IP大多是分散在世界各地的受害主機，與CDN相較之下，會有明顯的差異，因為CDN使用的IP所屬ASN多屬於同一個單位。此外Holz et al.不使用TTL做為特徵的理由是其不容易將Fast-Flux網路與CDN做區隔，因為CDN也使用了很短的TTL。
Chenfeng Vincent Zhou [4]則提出了2種改善的偵測方式，其中一種是利用同時查詢不同的DNS伺服器來增加不重複的IP數量，以減少偵測Fast-Flux網域的時間。另一種則是透過交叉比對Fast-Flux網域查詢的結果來加速偵測效果，因為我們知道很多Fast-Flux網域都會共用相同的IP，故如果某待測網域查詢的結果與Fast-Flux網域查詢結果很相似，則此待測網域為Fast-Flux網域的可能性極高。雖然Holz et al.[2]提出的偵測方式已有不錯的偵測率，但是像是一些正當用途的網域(如pool.ntp.org、database.clamav.net)還是會被歸納為Fast-Flux網域，造成不少的誤判。Emanuele Passerini.[8]則使用了更多的特徵(9個)來做區分，主要可以分成3大類：
- 網域名稱的資訊
- Fast-Flux網路的可取得性(availability)
- Fast-Flux受害機器的異質性
網域名稱的資訊包含了網域的壽命(age)與網域註冊單位(registrar)，通常惡意用途的網域名稱其壽命都非常短，平均為5週[8]，因為惡意網域被發現時會被網域管理單位停用，故駭客必須再去註冊其他的網域來使用。而很多管制鬆散的網域註冊單位也是駭客喜歡註冊的地方，最主要是這些註冊單位是位於法律比較不嚴謹的國家。Fast-Flux網路的可取得性主要有不重複的IP數量與DNS回應的TTL，Emanuele Passerini.則認為TTL是Fast-Flux網路的重要特徵，因此才可以迅速的對應至不同的IP。最後，異質性則包含網段數量、ASN數量、反查網域、註冊單位指派之網路代號及組織名稱，這些特徵的異質性越高則會符合Fast-Flux網路的特性。[8]在異質性上為什麼需要取這麼多特徵的原因是，因為並不是每個特徵都可以獲得，而多樣的特徵則可以減少誤判的可能性。
學術上大多從DNS回應的資訊去做分類及偵測，[8]則還使用了網域名稱的資訊，我個人認為網域名稱的資訊也是一個不錯的特徵之一，例如駭客常常會使用受害者的個人資訊或是亂取的名稱來註冊惡意網域，我們則可以從已經被偵測為Fast-Flux網路的個人註冊資訊去尋找到其他的惡意網域。此外名稱伺服器變動的次數也是一個可以偵測的特徵，因為正常的網站不會於短時間內常常變動名稱伺服器。
Fast-Flux網路與 Botnet
根據Nazario, Jose[7]的研究，相較於Holz et al.[2]的分析結果，Fast-Flux使用的TLD (Top Level Domain)有越來越多的趨勢，可見駭客試圖在一些法律鬆散的國家尋找更多可以註冊的網域，來延長其存活的時間。比較特別的是，有些Fast-Flux網域會有一段「睡眠期」，意指當網域被註冊到真正被駭客使用於Fast-Flux網路的期間，其睡眠期平均都超過一個月的時間。
要建構一個Fast-Flux網路必須要擁有很多連線穩定之IP，對駭客來說，最容易的方式就是從入侵之Botnet中去挑選適合的Fast-Flux Bot。而Fast-Flux Botnet與一般的Botnet具有一些不一樣的特色，如下所述[1,7]
- 具有流量導向(proxy redirection)的功能，且其流量導向之服務常為port 80 (HTTP)或port 53 (DNS)
- 為了讓Fast-Flux網路穩定且能順利取得，駭客會利用一些機制來檢查Fast-Flux Bot的網路穩定性，以便及時更換Fast-Flux網路節點
- 因為具有流量導向功能，所以Fast-Flux Bot必須是具有公開網路位址的節點，所以於NAT下的受害Bot則無法成為Fast-Flux Botnet的成員
過去在Botnet研究議題上大多從網路流量去偵測或是透過滲透入Botnet來發現受害的範圍與大小，而透過偵測Fast-Flux網路則提供我們另一個不同的思考方式來發現Botnet及其範圍或大小。但是必須注意的是，從DNS紀錄來估算Botnet的大小可能高估或低估，例如受害機器可能是使用ADSL撥接上網，下次對應至此機器之IP可能因使用者關係而變動，造成高估了此Botnet的範圍。另外，如果駭客將TTL的值設的比較久(如1800秒)，則可能會低估了參與Fast-Flux的Bot數目。
Fast-Flux之因應
Fast-Flux的議題與嚴重性逐漸被網路管理單位的重視，ICANN也特別成立Fast-Flux工作小組來深入討論此議題[9]。討論的議題包含：誰是Fast-Flux的受益者與受害者?是否網域註冊商也參與了Fast-Flux的活動?是否需要制定更嚴謹的DNS變更政策或是網域註冊程序?制定了這些管制政策對使用者、網域註冊商、及網域管理單位各有什麼影響?...等等的問題。
以下是一些可能的應變機制[1,2,10]，例如:
透過持續對網域的追蹤，我們可以建立出Fast-Flux網域的黑名單資訊，並請網域的註冊單位協助，停止這些網域繼續使用的權力，而這些黑名單也是可以當作垃圾郵件的過濾機制或是內部網路連線阻擋清單。
駭客可以註冊很多網域來使用，如果某個網域被停用了，他們則再換下一個來使用。為了找到真正掌控的惡意內容主機，我們可以對某些Bot的進出流量進行監控，找出Fast-Flux Botnet的控制端，並通報相關單位進行事件處裡。
過去駭客從偷來的信用卡帳號密碼就可以從註冊單位隨便申請一個惡意網域，如果改善過去某些網域註冊的鬆散機制，將大大提升網域被濫用的機會。此外對於經常變動或是設置很短TTL的網域進行嚴格管制或是監控，如果沒有正當合法的理由便無法任意變動DNS Records資訊，而設置最少一小時或二小時的TTL時間也有助於追蹤惡意來源的網站。
針對一般使用者或是ISP，必須讓他們了解Fast-Flux的威脅與嚴重性，才能減少被入侵而當作Bot的可能性。透過教育與宣導，讓使用者習慣一些安全使用網路的認知，並會確認與通報可疑的網站。
結論
本文介紹了目前駭客喜歡擁抱的技術－「Fast-Flux」，它延長了惡意活動存活的時間，增加追蹤的困難度。本文也實際分析一個Fast-Flux的例子－「Waledac」，發現相當多的受害機器被加入Fast-Flux Botnet。此外我們亦探討如何偵測Fast-Flux網域、Fast-Flux網路的特性、及如何針對此議題做一些因應措施。期望藉由本文的說明，可以讓對Fast-Flux議題有興趣的人有所幫助與瞭解。
參考文獻
[1] The Honeynet Project & Research Alliance: Know Your Enemy: Fast-Flux Service Networks (2007),
http://www.honeynet.org/papers/ff/fast-flux.html
[2] Holz, T., Gorecki, C., Freiling, F., Rieck, K.: Measuring and Detecting of Fast-Flux Service Networks. In: Proceeding of the 15th Annual Network & Distributed System Security Symposium (NDSS''08). (February 2008)
[3] Fast flux foils bot-net takedown, http://www.securityfocus.com/news/11473/2
[4] Chenfeng Vincent Zhou, Christopher Leckie and Shanika Karunasekera, Collaborative Detection of Fast Flux Phishing Domains, JOURNAL OF NETWORKS, VOL. 4, NO. 1, FEBRUARY 2009
[5] Shadowserver Foundation, http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20081231
[6] sudosecure.net , http://www.sudosecure.net/
[7] Nazario, Jose & Thorsten Holz. As the Net Churns: Fast-Flux Botnet Observations. Sept 5,2008
[8] Emanuele Passerini., Roberto Paleari., Lorenzo Martignoni., and Danilo Bruschi.: FluXOR: detecting and monitoring fast-flux service networks. Springer, July 10-11, 2008
[9] ICANN , GNSO Fast Flux Working Group, http://gnso.icann.org/announcements/announcement-30may08.htm
[10] SAC 025 SSAC Advisory on Fast Flux Hosting and DNS
本文作者為資通安全會報技術服務中心經理