一次網站被攻擊後分析與防禦

標籤：伺服器   mysql   server   監控   網站   攻擊   

晚上23點左右收到大量的監控警示，公司網站直接不能訪問了，立即登入伺服器，直接top看到情況如下：

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/54/17/wKiom1R33o2CIglhAAH_T-KD8CQ742.jpg" title="509ICG~L8BBP3)HF(11-27-16-40-01).jpg" alt="wKiom1R33o2CIglhAAH_T-KD8CQ742.jpg" />

發現負載都達到了800了，機器眼看就要爆了，首先先停了mysql，發現負載有點下降，聯絡了開發同事一同查看，因為今天新上線了一些代碼，可能是新上代碼的問題，隨後看到負載依然沒降，然後將php和nginx都重啟了，雖然短暫的降了一些，過一會立馬負載又起來了，這時看了下nginx日誌，看是不是使用者訪問導致的問題，結果一看就發現問題了，如下：

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/54/17/wKiom1R33qWyrnY3AAjSqydwWmA873.jpg" title="Catch(11-27-16-40-01).jpg" alt="wKiom1R33qWyrnY3AAjSqydwWmA873.jpg" />

30分鐘發了60w+的請求。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/54/15/wKioL1R331XyfvTlAABaLA8wHwQ087.jpg" title="QQ圖片20141127181509.jpg" alt="wKioL1R331XyfvTlAABaLA8wHwQ087.jpg" />

發現這個ip不停的發請求，很明顯，是被攻擊了，臨時將這個ip在nginx中deny掉，直接返回給它503，配置如下：在server中加入

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/54/17/wKiom1R33ufBOvfaAAApMj1Nqyg355.jpg" title="QQ圖片20141127174138.jpg" alt="wKiom1R33ufBOvfaAAApMj1Nqyg355.jpg" />

負載也慢慢降下來了，服務也正常了，當時太晚了，洗洗就睡了，結果第二天早上一來又發現網站打不開了，直接看nginx日誌，攻擊者換了一個ip，跟昨晚的現象一樣，這次直接在源頭把他幹掉了，就是添加iptables，如下：

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/54/15/wKioL1R334OSr2v5AAEr8pgdt3M099.jpg" title="QQ圖片20141127174523.jpg" alt="wKioL1R334OSr2v5AAEr8pgdt3M099.jpg" />

將攻擊的ip全部寫入iptables裡面，然後聯絡機房看能不能做策略協助解決這種CC攻擊，最後機房那邊也將這些ip給封了，但是攻擊者在換ip怎麼辦？不可能他換一個我加一條把，看來只能發大招了，寫了個iptables指令碼，如下：

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/54/17/wKiom1R33xXyQS2tAAEmHF3l-ro822.jpg" title="QQ圖片20141127174901.jpg" alt="wKiom1R33xXyQS2tAAEmHF3l-ro822.jpg" />

統計tcp串連，同一ip超過500次tcp串連的肯定就是攻擊者的ip了，正常使用者也不可能一下去開500個視窗去訪問我的網站吧，然後將這個ip直接在iptables上面幹掉，現在好了，問題解決了，這種CC攻擊有一個特點就是用的源ip基本都是固定的，DDOS有些可能是用不同原ip進行攻擊，那麼這種防禦就顯得有些吃力了。那遇到不同源ip攻擊怎麼防禦呢?

首先要聯絡機房，一般機房都有監控和防禦裝置，讓機房幫忙解決一些問題可能更有效，

不能在iptable上面去防禦，就只能通過nginx去防禦了，讓nginx去識別哪些是攻擊者，哪些是真正的使用者？其實nginx有2個模組：ngx_http_limit_conn_module和ngx_http_limit_req_module 可以參考官方文檔：

http://nginx.org/cn/docs/http/ngx_http_limit_req_module.html

http://nginx.org/cn/docs/http/ngx_http_limit_conn_module.html

首先在http中定義，如下：
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

然後到你需要限制的目錄下面，server段中，一般就是php請求，如下：

location ~* ^/(.*)\.php?$ {

limit_conn addr 3;
limit_req zone=one burst=2 nodelay;

fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $host_path/$fastcgi_script_name;
include fastcgi_params;
}

應用這2條規則後，只要需要執行php指令碼的這些頁面同一個IP只許建立3個串連，並且每秒只能有1個請求（突發請求可以達到2個）。
雖然這樣的規則一般來說對正常的使用者不會產生影響（極少有人在1秒內開啟3個頁面），但是為了防止影響那些手快的使用者訪問，可以在nginx中自訂503頁面，503頁面對使用者進行提示，然後自動重新整理，這個參數可以根據自己的情況變更，這樣不管攻擊者是多個ip還是單個ip攻擊都可以防禦到.

如果在nginx日誌中能找到攻擊者特有的代碼，這樣就更容易防禦，
比如User-agent。下面的是某一次CC攻擊時的User-agent
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE 3.01)Cache-Control: no-store, must-revalidate
幾乎沒有正常的瀏覽器會在User-agent中帶上“must-revalidate”這樣的關鍵字。所以我們可以以這個為特徵進行過濾，將User-agent中帶有“must-revalidate”的請求全部拒絕訪問：

if ($http_user_agent ~ must-revalidate) {
return 403;
}

原文地址：http://www.myjishu.com/?p=240

本文出自 “營運之道” 部落格，謝絕轉載！

一次網站被攻擊後分析與防禦