一次大規模網站攻擊防御報告
原創【51CTO專稿】筆者所在的網站在某一個晚上出現大范圍的攻擊，據事后統計而知，這次用了攻擊方用了大約50萬并發持續攻擊網站，一看網站應用服務器的負載很高，怪不得很慢呢。接下來開始分析和解決問題。
一、 攻擊描述
年初開始，網站應用服務器網卡流量普遍躥升到100M以上，其中幾臺服務器網卡流量更是達到了204Mbps。隨之帶來的就是訪問速度逐漸變慢,網絡帶寬數次被用完。
二、 攻擊分析
1、 既然是網卡流出100M以上，那么一定有不正常的請求地址過來，接著服務器才會響應并發送到客戶端。由此判斷是請求的地址有異常
應用服務器受到攻擊時的網卡流量圖
網站應用服務器受到攻擊時的負載現象
2、 分析web日志，可以發現很多IP同時在一秒鐘對的多個地址發送GET請求，且返回的地址的流量在200k-300k之間。試想一下，返回一個php地址，怎么會有200多k的流量，那么就一定是惡意的請求。看下面url中的 232347，這個232347，就是返回給客戶端的流量。
123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-116-20.html HTTP/1.0" "200" 232347 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-" 123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-1402-1.html HTTP/1.0" "200" 253872 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-" 123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-63-1.html HTTP/1.0" "200" 118163 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-" 123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-1342-1.html HTTP/1.0" "200" 235327 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-" 123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum.php?mod=forumdisplay&fid=58 HTTP/1.0" "200" 283377 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"
3、攻擊主要針對php應用，php并發跟nginx差了好幾個數量級。這次攻擊，平均每臺php 每秒最高承受200個并發，絕大部分的針對列表頁，直接對數據庫造成影響。
四、解決方案
1、防火墻封IP（不推薦）
用封IP的方式來阻止攻擊源IP，是一種方法，起初，我是采用了這種方法，但是這樣封IP，還需要到日志中去搜索。比較繁瑣，而且效果不明現。
2、Nginx被動防御（推薦）
還記得日志中的相同的user-agent的沒有，nginx這次利用了user-agent來防御攻擊。
在的nginx的配置文檔的上面加入了
if ( $http_user_agent ~* "Mozilla/4.0\ \(compatible;\ MSIE\ 6.0;\ Windows\ NT\ 5.0\;\ .NET\ CLR\ 1.1.4322\)" )
{
return 444;
}
重啟nginx后，nginx 在日志中檢測到該類user-agent時，就會返回444 http 狀態碼，既請求失敗。這樣設置后，各應用服務器負載恢復到正常，網卡流量正常。
218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" 218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" 218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
Nginx 處理攻擊ip的結果
五、總結
1、本次nginx 在防小型ddos或者cc有自己的特色:處理請求高效，消耗資源極低。
缺點：需要分析日志，找到規律，比如：user-agent等等。
2、疑問?
Q:有些同學要問了，這樣屏蔽該類user-agent，造成誤殺率有多大？
A:cc攻擊者攻擊時，都會有自己特殊的user-agent，屏蔽該類user-agent，不會造成額外的誤殺。這是通過觀察屏蔽日志的得出來的結論，服務器用上該類策略后，從來木有一個網友因為這事找過。
Q:如果cc攻擊軟件偽裝成正常的user-agent，這樣的造成誤殺多大？
A:1）：并不是所有的攻擊者都具備修改user-agent的，相當部分的攻擊者用的都是購買的攻擊軟件，如果要修改，則要付出金錢的代價。這不是攻擊者想要的結果。2）：就算是偽裝成了正常的user-agent，也會有自己的特點，可以從其共有特征來分析，比如來源地址是否相同等等，這里就可以作為共同點來設置策略。在做策略時應注意觀察nginx屏蔽日志中，是否其他的正常的請求也被屏蔽了？
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" - 124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
例如上面的日志，這次攻擊者將user-agent偽裝成正常的，再用user-agent做關鍵字，就會有部分誤殺了。所以針對此類攻擊，可以以來源地址作為關鍵字，nginx防護策略可以這么做，
if （$http__referer ~ * "/zhuanti/nzpp/zonghegr.jsp?group=2"）
{
return 444;
}
這樣就不會有誤殺了
3、經驗教訓
教訓：去年的一次CC攻擊，跟這次攻擊有異曲同工之處，都是打的是php；那時我們在啟用了黑洞防護墻后效果并不明顯。
經驗:當天晚上，我仔細分析了web日志，發現其user-agent，都是相同的，例如windows 5.0，跟正常的windows NT 5.0有本質區別，那可不可以在這上面做文章呢。帶著這個問題，在網上搜索了nginx 防cc方面的資料，果然發現網上的高手的想法跟我的相同，都從其相同點user-agent入手，用nginx 來匹配該類user-agent，然后返回503 http狀態碼，當然這里我做了修改，返回了444狀態碼。所以，在吸取了上次的教訓后，在今年網站遭受攻擊時，我果斷采用該條策略，結果證明效果很明顯。雖然cc攻擊一直在持續，但是網站訪問依然流暢。
作者簡介：崔曉輝，網名coralzd，大眾網系統管理員，精通網站系統架構、Unix技術。gtalk：coralzd@gmail.com
