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

一、攻擊描述

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

二、攻擊分析

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

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

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

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

四、解決方案

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

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

2、Nginx被動(dòng)防御（推薦）

還記得日志中的相同的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 在日志中檢測(cè)到該類user-agent時(shí)，就會(huì)返回444 http 狀態(tài)碼，既請(qǐng)求失敗。這樣設(shè)置后，各應(yīng)用服務(wù)器負(fù)載恢復(fù)到正常，網(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有自己的特色:處理請(qǐng)求高效，消耗資源極低。

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

2、疑問?

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

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

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

A: 1）：并不是所有的攻擊者都具備修改user-agent的，相當(dāng)部分的攻擊者用的都是購(gòu)買的攻擊軟件，如果要修改，則要付出金錢的代價(jià)。這不是攻擊者想要的結(jié)果。2）：就算是偽裝成了正常的user-agent，也會(huì)有自己的特點(diǎn)，可以從其共有特征來分析，比如來源地址是否相同等等，這里就可以作為共同點(diǎn)來設(shè)置策略。在做策略時(shí)應(yīng)注意觀察nginx屏蔽日志中，是否其他的正常的請(qǐng)求也被屏蔽了？

    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做關(guān)鍵字，就會(huì)有部分誤殺了。所以針對(duì)此類攻擊，可以以來源地址作為關(guān)鍵字，nginx防護(hù)策略可以這么做，

    if （$http__referer ~ * "/zhuanti/nzpp/zonghegr.jsp?group=2"）
{
  return 444;
}
  

這樣就不會(huì)有誤殺了

3、經(jīng)驗(yàn)教訓(xùn)

教訓(xùn)：去年的一次CC攻擊，跟這次攻擊有異曲同工之處，都是打的是php；那時(shí)我們?cè)趩⒂昧撕诙捶雷o(hù)墻后效果并不明顯。

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

本文出自 “ 曉輝 ” 博客，請(qǐng)務(wù)必保留此出處 http://coralzd.blog.51cto.com/90341/941630

一次大規(guī)模網(wǎng)站攻擊防御報(bào)告