【51CTO專稿】筆者所在的網(wǎng)站在某一個晚上出現(xiàn)大范圍的攻擊，據(jù)事后統(tǒng)計而知，這次用了攻擊方用了大約50萬并發(fā)持續(xù)攻擊網(wǎng)站，一看網(wǎng)站應用服務器的負載很高，怪不得很慢呢。接下來開始分析和解決問題。

一、   攻擊描述

年初開始，網(wǎng)站應用服務器網(wǎng)卡流量普遍躥升到100M以上，其中幾臺服務器網(wǎng)卡流量更是達到了204Mbps。隨之帶來的就是訪問速度逐漸變慢,網(wǎng)絡帶寬數(shù)次被用完。 

二、 攻擊分析

1、 既然是網(wǎng)卡流出100M以上，那么一定有不正常的請求地址過來，接著服務器才會響應并發(fā)送到客戶端。由此判斷是請求的地址有異常

應用服務器受到攻擊時的網(wǎng)卡流量圖

網(wǎng)站應用服務器受到攻擊時的負載現(xiàn)象

2、 分析web日志，可以發(fā)現(xiàn)很多IP同時在一秒鐘對的多個地址發(fā)送GET請求，且返回的地址的流量在200k-300k之間。試想一下，返回一個php地址，怎么會有200多k的流量，那么就一定是惡意的請求?？聪旅鎢rl中的 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并發(fā)跟nginx差了好幾個數(shù)量級。這次攻擊，平均每臺php 每秒最高承受200個并發(fā)，絕大部分的針對列表頁，直接對數(shù)據(jù)庫造成影響。

四、解決方案

1、防火墻封IP（不推薦）

用封IP的方式來阻止攻擊源IP，是一種方法，起初，我是采用了這種方法，但是這樣封IP，還需要到日志中去搜索。比較繁瑣，而且效果不明現(xiàn)。

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 狀態(tài)碼，既請求失敗。這樣設置后，各應用服務器負載恢復到正常，網(wǎng)卡流量正常。

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的結(jié)果

五、總結(jié)

1、本次nginx 在防小型ddos或者cc有自己的特色:處理請求高效，消耗資源極低。

缺點：需要分析日志，找到規(guī)律，比如：user-agent等等。

2、疑問?

Q:有些同學要問了，這樣屏蔽該類user-agent，造成誤殺率有多大？

A:cc攻擊者攻擊時，都會有自己特殊的user-agent，屏蔽該類user-agent，不會造成額外的誤殺。這是通過觀察屏蔽日志的得出來的結(jié)論，服務器用上該類策略后，從來木有一個網(wǎng)友因為這事找過。

Q:如果cc攻擊軟件偽裝成正常的user-agent，這樣的造成誤殺多大？

A:1）：并不是所有的攻擊者都具備修改user-agent的，相當部分的攻擊者用的都是購買的攻擊軟件，如果要修改，則要付出金錢的代價。這不是攻擊者想要的結(jié)果。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、經(jīng)驗教訓

教訓：去年的一次CC攻擊，跟這次攻擊有異曲同工之處，都是打的是php；那時我們在啟用了黑洞防護墻后效果并不明顯。

經(jīng)驗:當天晚上，我仔細分析了web日志，發(fā)現(xiàn)其user-agent，都是相同的，例如windows 5.0，跟正常的windows NT 5.0有本質(zhì)區(qū)別，那可不可以在這上面做文章呢。帶著這個問題，在網(wǎng)上搜索了nginx 防cc方面的資料，果然發(fā)現(xiàn)網(wǎng)上的高手的想法跟我的相同，都從其相同點user-agent入手，用nginx 來匹配該類user-agent，然后返回503 http狀態(tài)碼，當然這里我做了修改，返回了444狀態(tài)碼。所以，在吸取了上次的教訓后，在今年網(wǎng)站遭受攻擊時，我果斷采用該條策略，結(jié)果證明效果很明顯。雖然cc攻擊一直在持續(xù)，但是網(wǎng)站訪問依然流暢。

作者簡介：崔曉輝，網(wǎng)名coralzd，大眾網(wǎng)系統(tǒng)管理員，精通網(wǎng)站系統(tǒng)架構(gòu)、Unix技術。gtalk：coralzd@gmail.com