【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攻擊一直在持續,但是網站訪問依然流暢。
本文出自 “ 曉輝 ” 博客,請務必保留此出處 http://coralzd.blog.51cto.com/90341/941630
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
