淺談DDos攻擊攻擊與防禦

一背景

在前幾天，我們運營的某網站遭受了一次ddos攻擊，我們的網站是一個公益性質的網站，為各個廠商和白帽子之間搭建一個平台以傳遞安全問題等信息，我們並不清楚因為什麼原因會遭遇這種無恥的攻擊。因為我們本身並不從事這種類型的攻擊，這種攻擊技術一般也是比較粗糙的，所以討論得比較少，但是既然發生了這樣的攻擊我們覺得分享攻擊發生後我們在這個過程中學到得東西，以及針對這種攻擊我們的想法才能讓這次攻擊產生真正的價值，而並不是這樣的攻擊僅僅浪費大家的時間而已。

另外，我們發現大型的企業都有遭受攻擊的案例，但是大家遭受攻擊之後的應對措施及學到的經驗卻分享都比較少，這導致各家都是自行的摸索經驗，依然停留在一家企業對抗整個互聯網的攻擊的局面，而對於攻擊者卻是此次攻擊針對你，下次攻擊卻是針對他了，而且攻擊之後無論是技術還是資源都沒有任何的損耗，這也是導致這種攻擊頻繁並且肆無忌憚的原因。

我們來嘗試做一些改變：）

二應急響應

在攻擊發生後，第一個現象是我們的網站上不去了，但是依然可以訪問到管理界面，我們登陸上去簡單執行了命令：

netstat -antp

我們看到有大量的鏈接存在著，並且都是ESTABLISHED狀態，正常狀態下我們的網站訪問量沒有這麼高，如果有這麼高我們相信中國的信息安全就有希望了，對於這樣的情況其實處理就比較簡單，這是一次四層的攻擊，也就是所有ip都是真實的，由於目前為止只是消耗了webserver的網路連接資源，所以我們只需要簡單的將這些ip在網路層封禁就可以，很簡單，用下面的命令即可：

for i in `netstat -an | grep -i 『:80 『|grep 『EST』 | awk 『{print $5}』 | cut -d : -f 1 | sort | uniq -c | awk 『{if($1 > 50) {print $2}}』`

echo $i

echo $i >> /tmp/banip

/sbin/iptables -A INPUT -p tcp -j DROP -s $i

done

然後作為計劃任務一分鐘執行一次即可，很快，iptables的封禁列表就充斥了大量的封禁ip，我們簡單的統計了下連接數最大的一些ip發現都來自韓國。為了保證系統的性能，我們調大了系統的可接受的連接數以及對Nginx進行了每個連接能夠進行的請求速率，系統於是恢復了正常的運行。

正常狀態一直持續到第二天，但是到中午之後我們發現訪問又出現了問題，網路很慢，使用ping發現大概出現了70%左右的丟包，在艱難的登陸到系統上之後，發現系統已經很少有TCP的正常連接，為了查明原因，我們對系統進行了抓包：

tcpdump -w tmp.pcap port not 22

tcpdump -r tmp.pcap -nnA

我們發現攻擊已經從應用層的攻擊調整到了網路層的攻擊，大量的目標埠是80的udp和icmp包以極快的速度充滿了網路，一個包大小大概在1k左右，這次佔據的資源純粹是帶寬資源了，即使在系統上做限制也解決不了這個問題，不過也沒有關係，對於網路層的問題我們可以在網路層上做限制，我們只需要在網路上把到達我們ip的非TCP的所有包如UDP和ICMP等協議都禁止掉即可，但是我們沒有自己的伺服器也缺乏對網路設備的控制權，目前是由工信部CERT提供支持的，由於臨時無法協調進行相應的操作，後果如大家看到，我們的服務很慢，基本上停止了服務，在一段時間之後攻擊者停止了攻擊，服務才進行了恢復，很憋屈是么？但是同時我們得到了很多熱心朋友的幫助，得到了更好的網路和伺服器資源，在網路資源方面的能力得到了很大的提升，緩解了這方面的問題，這裡對他們表示感謝。

三常見ddos攻擊及防禦

繼續秉承80sec的」Know it then hack it」，這裡簡單談一下ddos攻擊和防禦方面的問題。ddos的全稱是分散式拒絕服務攻擊，既然是拒絕服務一定是因為某些原因而停止服務的，其中最重要的也是最常用的原因就是利用服務端方面資源的有限性，這種服務端的資源範圍很廣，可以簡單的梳理一個請求正常完成的過程：

1 用戶在客戶端瀏覽器輸入請求的地址

2 瀏覽器解析該請求，包括分析其中的dns以明確需要到達的遠程伺服器地址

3 明確地址後瀏覽器和伺服器的服務嘗試建立連接，嘗試建立連接的數據包通過本地網路，中間路由最終艱苦到達目標網路再到達目標伺服器

4 網路連接建立完成之後瀏覽器根據請求建立不同的數據包並且將數據包發送到伺服器某個埠

5 埠映射到進程，進程接受到數據包之後進行內部的解析

6 請求伺服器內部的各種不同的資源，包括後端的API以及一些資料庫或者文件等

7 在邏輯處理完成之後數據包按照之前建立的通道返回到用戶瀏覽器，瀏覽器完成解析，請求完成。

上面各個點都可以被用來進行ddos攻擊，包括：

1 某些著名的客戶端劫持病毒，還記得訪問百度跳搜狗的事情么？：）

2 某個大型互聯網公司發生的dns劫持事件，或者直接大量的dns請求直接攻擊dns伺服器，這裡可以使用一些專業的第三方dns服務來緩解這個問題，如Dnspod

3 利用建立網路連接需要的網路資源攻擊伺服器帶寬使得正常數據包無法到達如udp的洪水攻擊，消耗前端設備的cpu資源以使得數據包不能有效轉發如icmp和一些碎片包的洪水攻擊，消耗伺服器方建立正常連接需要的資源如syn flood或者就是佔用大量的連接使得正常的連接無法發起，譬如這次的TCP flood

4 利用webserver的一些特點進行攻擊，相比nginx來說，apache處理一個請求的過程就比較笨重。

5 利用應用程序內部的一些特性攻擊程序內部的資源如mysql，後端消耗資源大的介面等等，這也就是傳統意義上的CC攻擊。

這裡涉及到攻防的概念，但是實際上如果了解對方的攻擊點和攻擊手法，防禦會變成簡單的一個拼資源的過程，不要用你最弱的地方去抗人家最強的地方，應該從最合適的地方入手把問題解決掉，譬如在路由器等設備上解決應用層攻擊就不是一個好的辦法，同理，在應用層嘗試解決網路層的問題也是不可能的，簡單來說，目標是只讓正常的數據和請求進入到我們的服務，一個完善的防禦體系應該考慮如下幾個層面：

1 作為用戶請求的入口，必須有良好的dns防禦

2 與你的價值相匹配的帶寬資源，並且在核心節點上布置好應用層的防禦策略，只允許你的正常應用的網路數據包能夠進入，譬如封殺除了80以外的所有數據包

3 有支持你的服務價值的機器集群來抵抗應用層的壓力，有必要的話需要將一個http請求繼續分解，將連接建立的過程壓力分解到其他的集群里，這裡似乎已經有一般的硬體防火牆能做這個事情，甚至將正常的http請求解析過程都進行分解，保證到達後端的是正常的請求，剔除掉畸形的請求，將正常的請求的請求頻度等行為進行記錄和監控，一旦發生異常就在這裡進行應用層的封殺

每個公司都有自己對自己價值的評估從而決定安全投入上的大小，每一次攻擊也會涉及到利益的存在，正如防禦因為種種原因譬如投入上的不足和實施過程中的不完美，有著天生的弱點一樣，攻擊也是有著天生的弱點的，因為每一次攻擊涉及到不同的環節，每個環節都可能由不同水平的人完成，他所擁有的資源，他使用的工具和技術都不會是完美的，所以才有可能進行防禦，另外，我相信進行DDOS攻擊的人是一個固定的行業，會有一些固定的人群，對於其中使用的技術，工具，資源和利益鏈都是比較固定的，與之相對的是各個企業卻缺乏相應的溝通，以個人企業對抗一個產業自然是比較困難，而如果每一個企業都能將自己遭受攻擊時的經驗分享出來，包括殭屍網路的大小及IP分布，攻擊工具的特徵，甚至有能力的可以去分析背後的利益點及操作者，那麼每一次攻擊都能讓大家的整體防禦能力上升，讓攻擊者的攻擊能力有損失，我們很願意來做這個事情。

四根源及反擊

我困惑的是一點，攻擊我們並不能得到實際的好處為什麼還是有人來攻擊，而且聽說其他公司都有被攻擊的情況，我覺得有一點原因就是攻擊我們的確得不到什麼好處，但是實際上攻擊者也並不損失什麼，無論是資源上還是法律風險上，他不會因為一次攻擊而損失太多，而相比之下，服務提供者損失的東西卻太多了，這從經濟學角度來講就是不平衡的，我們處於弱勢。

一般而言，的確對於作惡者是沒有什麼懲罰措施，但是這次，我們覺得我們是可以做一些事情的，我們嘗試挖掘背後的攻擊者，甚至清除這個殭屍網路。

首先這次攻擊起源於應用層的攻擊，所以所有的ip都是真實的，經過與CERT溝通，也發現這些ip都是韓國的，並且控制端不在國內，因為期間沒有與國內有過通訊，即使在後面換成了udp+icmp的flood，但是依然是那些韓國的ip，這很有意思，正常情況下udp+icmp的數據包是可以偽造的，但是這裡居然沒有偽造，這在後面大概被我們證實了原因。

這些ip是真實存在的ip，而且這些ip肯定在攻擊完我們之後一定依然跟攻擊者保持著聯繫，而一般的聯繫方式因為需要控制的方便都是dns域名，既然如此，如果我們能挖掘到這個dns域名我們就可能間接的挖掘出真正幕後黑手在哪裡。首先，我們迅速的找出了這次攻擊ip中開放了80埠的機器，因為我們對80埠上的安全問題比較自信，應該很快可以獲知這些ip背後的細節（80sec名稱由來），我們發現大部分是一些路由器和一些web的vpn設備，我們猜測這次攻擊的主要是韓國的個人用戶，而個人用戶的機器操作系統一般是windows所以在較高版本上發送數據包方面可能有著比較大的限制，這也解釋了為什麼即使是udp+icmp的攻擊我們看到的大都是真實ip。發現這些路由設備之後我們嘗試深入得更多，很快用一些弱口令譬如admin/admin登陸進去，果然全世界的網民都一樣，admin/admin是天生的入口。

登陸進去一些路由之後我們發現這些路由器裡面存在一個功能是設置自己的dns，這意味著這下面的所有dns請求都可以被定向到我們自己設置的dns伺服器，這對於我們去了解內部網路的細節會很有用，於是我們建立了一個自己的dns伺服器，並且開啟了dns請求的日誌功能以記錄所有請求的細節。我們大約控制了20台路由器的dns指向，並且都成功重定向到我們自己的伺服器。

剩下的就是簡單的數據分析，在這之前我們可以對殭屍網路的控制域名做如下的猜測：

1 這個dns應該為了靈活的控制域名的緩存時間TTL一般不會特別長

2 這個dns應該是定期的被請求，所以會在dns請求里有較大的出現比例

3 這個dns應該是為了控制而存在的，所以域名不應該在搜索引擎以及其他地方獲得較高的訪問指數，這與2中的規則配合起來會比較好確定，是一個天生的矛盾。

4 這個dns應該在各個路由下面都會被請求

這些通過簡單的統計就很容易得出答案，我們發現了一些3322的通用惡意軟體域名但是發現它並不是我們需要的，因為只有少數機器去訪問到，經過一些時間之後最後我們發現一個域名訪問量與naver（韓國的一個門戶）的訪問量持平，workgroup001.snow****.net，看起來似乎對自己的殭屍網路管理很好嘛，大概有18台機器訪問過這個域名，這個域名的主機託管在新加坡，生存時間TTL在1800也就是半小時，這個域名在所有的搜索引擎中都不存在記錄，是一個韓國人在godady一年前才註冊的，同時我們訪問這個域名指向主機的3389，簡單的通過5下shift就判斷出它上面存在著一個典型的windows後門，似乎我們找到它了，不是么？經過後續的觀察，一段時間後這個域名指向到了127.0.0.1，我們確信了我們的答案,workgroup001.snow****.net，看起來似乎對自己的殭屍網路管理很好嘛：）

這是一次典型的ddos攻擊，攻擊之後我們獲得了參與攻擊的主機列表和控制端的域名及ip，相信中國和韓國的cert對於清理這次的攻擊源很有興趣，我們是有一些損失，但是攻擊者也有損失了（大概包括一個殭屍網路及一個控制端域名，甚至可能包括一次內部的法律調查），我們不再是不平等的了，不是么？

五總結

正如一個朋友所講的，所有的防禦是不完美的正如攻擊是不完美的一樣，好的防禦者在提升自己的防禦能力趨於完美的同時也要善於尋找攻擊者的不完美，尋找一次攻擊中的漏洞，不要對攻擊心生恐懼，對於Ddos攻擊而言，發起一次攻擊一樣是存在漏洞的，如果我們都能夠擅長利用其中的漏洞並且抓住後面的攻擊者那麼相信以後的ddos攻擊案例將會減少很多，在針對目標發起攻擊之前攻擊者也會做更多的權衡，損失，利益和法律。