CC 攻擊可以歸為 DDoS 攻擊的一種。他們之間都原理都是一樣的,即傳送大量的請求資料來導致站群伺服器拒絕服務,是一種連線攻擊。 CC 攻擊又可分為代理 CC 攻擊,和肉雞 CC 攻擊。代理 CC 攻擊是駭客藉助代理站群伺服器生成指向受害 WordPress 主機的合法 WordPress 網頁請求,實現 DOS,和偽裝就叫:cc(ChallengeCollapsar)。而肉雞 CC 攻擊是駭客使用 CC 攻擊站群軟體,控制大量肉雞,發動攻擊,相比來後者比前者更難防禦。因為肉雞可以模擬正常使用者訪問網站的請求。偽造成合法資料包。防禦 CC 攻擊可以透過多種方法,禁止網站代理訪問,儘量將網站做成靜態頁面,限制連線數量等。
Nginx 是一款輕量級的 Web 站群伺服器,由俄羅斯的程式設計師 Igor Sysoev 所開發,最初供俄國大型的入口網站及搜尋引 Rambler 使用。 其特點是佔有記憶體少,併發能力強,事實上 Nginx 的併發能力確實在同型別的網站站群伺服器中表現較好。
Nginx 雖然可以比 Apache 處理更大的連線數,但是 HTTP GET FLOOD 針對的不僅僅是 WEB 站群伺服器,還有資料庫站群伺服器。大量 HTTP 請求產生了大量的資料庫查詢,可以在幾秒之內使資料庫停止響應,系統負載升高,最終導致站群伺服器當機。
本文主要介紹 CentOS+Nginx 下如何快速有效得防禦 CC 攻擊。至於如何安裝 Nginx 就不詳細介紹了,有興趣的讀者可以在 Nginx 官方網站(http://www.nginx.org/)下載原始碼進行編譯。如果你使用的是 Centos5,也可以使用 rpm 包進行安裝(http://centos.alt.ru/repository/centos/5/i386/nginx-stable-0.7.65-1.el5.i386.rpm)。
主動抑制方法
為了讓 Nginx 支援更多的併發連線數,根據實際情況對工作執行緒數和每個工作執行緒支援的最大連線數進行調整。例如設定 “worker_processes 10” 和 “worker_connections 1024”,那這臺站群伺服器支援的最大連線數就是 10×1024=10240 。
worker_processes 10;
events {
use epoll;
worker_connections 10240;
}
Nginx 0.7 開始提供了 2 個限制使用者連線的模組:NginxHttpLimitZoneModule 和 NginxHttpLimitReqModule 。 NginxHttpLimitZoneModule 可以根據條件進行併發連線數控制。
例如可以定義以下程式碼:
http {
limit_zone my_zone $binary_remote_addr 10m;
server {
location /somedir/ {
limit_conn my_zone 1;
}
}
}
其中 “limit_zone my_zone $binary_remote_addr 10m” 的意思是定義一個名稱為 my_zone 的儲存區域、 my_zone 中的內容為遠端 IP 地址、 my_zone 的大小為 10M;“location /somedir/” 的意思是針對 somedir 目錄應用規則;“limit_conn my_zone 1” 的意思是針對上面定義的 my_zone 記錄區記錄的 IP 地址在指定的目錄中只能建立一個連線。
NginxHttpLimitReqModule 可以根據條件進行請求頻率的控制。例如可以定義以下程式碼:
http {
limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s;
…
server {
…
location /somedir/ {
limit_req_zone zone= my_req_zone burst=2;
}
Discuz! 是使用比較多的一個 php 論壇程式。以 Discuz!7.0 為例,程式目錄下有比較多的可以直接訪問的 php 檔案,但其中最容易受到攻擊的一般有 index.php(首頁)、 forumdisplay.php(板塊顯示)、 viewthread.php(帖子顯示)。攻擊者一般會對這些頁面發起大量的請求,導致 HTTP 站群伺服器連線數耗盡、 mysql 資料庫停止響應,最終導致站群伺服器崩潰。為了防止上述頁面被攻擊,我們可以設定以下的規則進行防禦:
http {
limit_zone myzone_bbs $binary_remote_addr 10m;
limit_req_zone $binary_remote_addr zone=bbs:10m rate=1r/s;
…
server {
…
location ~ ^/bbs/(index|forumdisplay|viewthread).php$ {
limit_conn myzone_bbs 3;
limit_req zone=bbs burst=2 nodelay;
root html;
fastcgi_pass unix:/dev/shm/php-cgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
includefastcgi_params;
}
}
}
應用這條規則後,bbs 目錄下的 index.php 、 forumdisplay.php 和 viewthread.php 這些頁面同一個 IP 只許建立 3 個連線,並且每秒只能有 1 個請求(突發請求可以達到 2 個)。雖然這樣的規則一般來說對正常的使用者不會產生影響(極少有人在 1 秒內開啟 3 個頁面),但是為了防止影響那些手快的使用者訪問,可以在 nginx 中自定義 503 頁面,503 頁面對使用者進行提示,然後自動重新整理。在 Nginx 中自定義 503 頁面:
error_page 503 /errpage/503.html;
503 頁面的原始碼:
< head>
< title>頁面即將載入….
< meta http-equiv=content-type c>
< META NAME=”ROBOTS” C>
< /head>
< body bgcolor=”#FFFFFF”>
< table cellpadding=”0″ cellspacing=”0″ border=”0″ width=”700″ align=”center”height=”85%”>
|
頁面即將載入 你重新整理頁面的速度過快。請少安毋躁,頁面即將載入… [ |
< /table>
< /body>
< /html>
< SCRIPT language=javascript>
function update()
{
window.location.reload();
}
setTimeout(“update()”,2000);
< /script>
被動防禦方法
雖然主動防禦已經抵擋了大多數 HTTP GET FLOOD 攻擊,但是道高一尺魔高一丈,攻擊者會總會找到你薄弱的環節進行攻擊。所以我們在這裡也要介紹一下被動防禦的一些方法。
封 IP 地址
訪問者透過瀏覽器正常訪問網站,與站群伺服器建立的連線一般不會超過 20 個,我們可以透過指令碼禁止連線數過大的 IP 訪問。以下指令碼透過 netstat 命令列舉所有連線,將連線數最高的一個 IP 如果連線數超過 150,則透過 iptables 阻止訪問:
#!/bin/sh
status=`netstat -na|awk ‘$5 ~ /[0-9]+:[0-9]+/ {print $5}’ |awk -F “:” –‘{print $1}’ |sort -n|uniq -c |sort -n|tail -n 1`
NUM=`echo $status|awk ‘{print $1}’`
IP=`echo $status|awk ‘{print $2}’`
result=`echo “$NUM > 150” | bc`
if [ $result = 1 ]
then
echo IP:$IP is over $NUM, BAN IT!
/sbin/iptables -I INPUT -s $IP -j DROP
fi
執行 crontab -e,將上述指令碼新增到 crontab 每分鐘自動執行:
* * * * * /root/xxxx.sh
透過 apache 自帶的 ab 工具進行站群伺服器壓力測試:
# ab -n 1000 -c 100 http://www.xxx.com/bbs/index.php
測試完成後,我們就可以看到系統中有 IP 被封的提示:
#tail /var/spool/mail/root
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env:
X-Cron-Env:
X-Cron-Env: <;PATH=/usr/bin:/bin>
X-Cron-Env:
X-Cron-Env:
IP:58.246.xx.xx is over 1047, BAN IT!
至此,又一次 HTTP GET FLOOD 防禦成功。
根據特徵碼遮蔽請求(對 CC 攻擊效果較好)
一般同一種 CC 攻擊工具發起的攻擊請求包總是相同的,而且和正常請求有所差異。當站群伺服器遭遇 CC 攻擊時,我們可以快速檢視日誌,分析其請求的特徵,比如 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;
}
本文主要介紹了 nginx 下的 HTTP GET FLOOD 防禦,如果有不對的地方,希望大家可以向我提出。同時,也希望大家能夠舉一反三,把這種思路應用到 apache 、 lighttpd 等常見的 web 站群伺服器中。
原文連結:http://www.centoscn.com/CentosSecurity/SoftSecurity/2015/0525/5528.html