養雞廠廠長日記—規模化Botnet養殖和應用

04-30

Author: elknot@360corpsec

0x00 前言

前一段時間memcache drdos攻擊可謂是借著各種渠道火了一次，包括筆者所在的公司也被社會人反手掄了幾次，可以預見這種類型的DDoS一旦發生起來非常的可怕。我們對這種情況往往都是看到流量異常之後選擇封堵相關的協議和埠，或者有錢的方法直接上電信雲堤（據說收費非常坑爹，5000塊錢一次，現在不知道漲價沒有），這樣的話始終處於一個被動挨打的局面，那麼有沒有什麼方法可以稍微減輕一下被動的局面呢？答案在下面。

0x01 DDoS背後的故事

現在的DDoS其實說白了，也就那麼幾種方式，殺敵一千自損八百的TCP-Based Flood比如說SYN Flood，四兩撥千斤的反射型DDoS也就是DRDoS比如說UDP Flood，然後就是基於Botnet的殭屍網路發起的DDoS比如PerlBot、Mirai這種。接著就是一些來自於應用層攻擊的DDoS比如說CC、HTTP SlowRequest這些。當然了還有其他種類的DDoS。根據DDoSMon的數據來看，我們發現UDP-Based Flood實際上是佔比最多的DDoS類型。

緊接著我們用時間排序去看一下一段時間內的DDoS詳細數據，我們發現了一件有趣的事情：基本上SYN-Flood和UDP-Based Flood處於一個此消彼漲的關係，所以我們覺得有必要去了解一下裡面的貓膩。

我們通過對一些DDoS流量進行篩選和分析發現，很多的DNS Flood、SYN Flood還有一些其他的TCP-Based Flood都是由於Botnet引起的（這裡需要強調一下，數據可能不嚴謹，大多數都是來自於我這邊蜜罐的捕獲到的樣本，由於本人比較窮，所以蜜罐節點較少），而這些botnet的家族分布和最近一段時間的攻擊數據如下圖所示（大家請忽略那個和我id一樣的botnet，真尷尬，等有時間解釋一下為什麼要用這個id）。

OK，既然這樣的話，我們把問題集中到focus解決由Botnet引起的DDoS攻擊事件，就可以解決一部分的DDoS預警的事情了。

這裡插一句，筆者最近使用memcache服務在某雲廠商的VPS上搭建了一個開放11211埠的memcache的服務，很遺憾，只有幾個大黑客用我的節點打了人了，具體打了誰我們在第三部分說。

0x02 Botnet的養殖和數據獲取

首先botnet的養殖設施，俗稱養雞廠或者養馬場，已經不是個太新的概念了，很多地方都有，算是蜜罐的一個變種，主要是用來保證botnet的存活同時捕獲指令。大概先說一下思路，用邏輯鏈條來表示的話是這樣的：

獲取Botnet樣本——》逆向分析指令集——》分配容器——》載入Botnet——》存活性檢測——》流量監控——》收集Flood Target

我再來用大白話說一下完整的流程：我們通過蜜罐也好，還是其他的手段也好來獲取Botnet的樣本。通過對樣本的分析（沙箱、IDA什麼的無所謂）可以獲取到Botnet運行相關的指令數據包和傳遞方式。當我們完成了分析之後，我們在伺服器上為其預製一個容器，載入Botnet，同時開啟抓包功能（可以設置BPF過濾規則過濾指定的協議，同時設置好iptables防止攻擊真正發生），抓到指令後預警，輸出攻擊的目標，完結。

其實通過上面的描述你會發現，獲取樣本這一部分可以通過主動互動式蜜罐進行獲取，botnet分析部分可以通過自動化沙箱來完成分析，容器分配和管理可以使用Kubernate等調度工具進行分配，流量監控和存活性檢測這一部分可以依賴Kernel-Based Agent來檢測，所以從邏輯鏈條來說，這一套使用自動化完成理論上是沒有難度的。

雖然說實現上沒有難度，但是我們仍需要注意以下幾個點：

攻擊行為假戲真做：由於要養殖Botnet，所以Botnet必定是存活的，有兩種方法可以對Botnet進行限制，也就是Botnet減毒處理也就是把一些功能閹割掉，還有一種就是流量限制，開啟對應的流量限制可以防止DDoS假戲真做，當然如果沒有辦法的話，不處理也行，但是當心被人查到是你們家的東西打了人家。

魔改容器：因為我們要對Botnet的行為和流量進行長時間監測，所以容器應該是我們Hook掉一些函數之後的魔改容器，當然也可以使用Agent這種大後門來對Botnet的系統級API進行Hook。

虛擬化技術的選擇：在這裡會有人問我為什麼不選擇虛擬機而選擇容器作為養殖環境，一方面是因為虛擬化對資源佔用比較多，同時成本較大，容易被發現，另一方面主要是由於容器的靈活性，當然我使用的是微軟Hyper-V Docker，相對於其他傳統的Docker而言，一張圖就能說明白Hyper-V Docker和其他的Docker差別在哪裡（圖源自於筆者去年參加Microsoft Build Tour的時候拍的一張ppt）。

這樣的話我們大概就有了個系統雛形，方便理解我還是畫個圖吧：

圖裡面大體都很好理解，前面沒說到的是主要是規則那裡，設置郵件告警和FastnetMon監測異常流量的原因主要是怕引起的攻擊打出去的能檢測的的到，並且及時通知異常流量，這裡的規則一般都是手動維護。

其實這套系統是我過年的時候研究tor的同時搭建的，目前由於樣本的問題監測到的DDoS基本上兩隻手能數的過來（截止到12號，日誌裡面顯示的是23次攻擊），樣本的數量也就10個左右，具體的數據分析後面再說。

我們在設置bot的數據結構的時候，建議設置成如下的方式：

{ "type": "botnet_info", "data": { "botnet_name": "elknot.xor", "botnet_caught_type": "Honeypot", "botnet_caught": "2018-02-17 14:25:74", "botnet_antivm": False, "botnet_status": "Alive", "botnet_container": "bot_e74a1dc3", "botnet_commands": ["PONG", "HTTP"], "botnet_attack": [{ "attack_info": "TCP SYN_Flood", "attcack_pps": 185425, "attack_target": ["171.***.***.24", "114.***.***.95"], "attack_true": True }, { "attack_info": "UDP NTP_Flood", "attcack_pps": 64229, "attack_target": ["221.***.***.15", "94.***.***.12"], "attack_true": True }] }}

其實還是為了方便對botnet進行管理和收集相關的信息，至於問BPF是啥的，建議回去惡補一下計算機網路編程，裡面對於BPF（Berkeley Packet Filter）解釋的非常詳細。

有關告警的問題其實不限於郵件，簡訊、微信、IM神馬的其實都可以，關鍵是方便通知即可。

0x03 養殖場的成果

觀察了這麼幾天botnet的動向，我發現botnet其實並不是打那些政府、銀行、教育、能源行業的伺服器，通過我這邊非常少量的數據可以觀察到攻擊目標行業的分布（我並沒有存目標IP的畫像，相反我在選擇的時候接入了riskiq的pdns服務，因為不要錢）如下：

果然還是利益驅動比較大，因為遊戲行業尤其是搭私服的，往往因為某些原因確實被DDoS乾的很慘，這個往往也是很多為遊戲業務提供雲服務的痛點。其次就是學校，果然炸學校這種事兒不是說說而已。金融政府這些，我覺得現有的法律制度約束你懂的。

再看下另外一項數據，就是botnet發起攻擊的數據，主要是兩項，一項是攻擊時間分布，另外一項是攻擊類型分布，下面的兩個統計結果。

看來是過年也沒怎麼好好休息啊，其實黑產一般過年會休息幾天，然後年後集中搞幾天事情，可能是因為今年過年之後就是各種開會所有沒什麼太多的機會吧。

這個就有點意思了，黑產看來也是懂得NTP Flood是目前放大倍數比較高的（最近的memcache比ntp要高），所以以後沒點文化估計連黑產也幹不了

0x04 總結

養殖場這個東西我覺得還是成本上有點高，所以大家在研究時候注意嚴格的成本限制，（最近真的因為這個搞得比較窮了）但是呢這個東西在研究一些的數據的時候真的能發現一些經驗上看不到的東西，所以說有條件的話大家可以試試看。

ref：

http://forum.huawei.com/enterprise//zh/thread-361461.html

https://ddosmon.net/insight/

https://docs.microsoft.com/zh-cn/windows-server/get-started/nano-server-quick-start

https://docs.docker.com/machine/drivers/hyper-v/#where-to-go-next