一次大規模網站攻擊防護報告

時間  2019-11-09
標籤 一次 大規模 網站 攻擊 防護 報告 欄目 網站開發 简体版
原文   原文鏈接

1、 攻擊描述 php

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

2、 攻擊分析 node

一、 既然是網卡流出100M以上，那麼必定有不正常的請求地址過來，接着服務器纔會響應併發送到客戶端。由此判斷是請求的地址有異常 IT網.cn，http://www.it.net.cn mysql

應用服務器受到攻擊時的網卡流量圖

應用服務器受到攻擊時的網卡流量圖 IT網.cn，http://www.it.net.cn nginx

網站應用服務器受到攻擊時的負載現象 IT網.cn，http://www.it.net.cn web

網站應用服務器受到攻擊時的負載現象
  IT網，http://www.it.net.cn sql

  IT網.cn，http://www.it.net.cn 數據庫

二、 分析web日誌，能夠發現不少IP同時在一秒鐘對的多個地址發送GET請求，且返回的地址的流量在200k-300k之間。試想一下，返回一個php地址，怎麼會有200多k的流量，那麼就必定是惡意的請求。看下面url中的 232347，這個232347，就是返回給客戶端的流量。 IT網.cn，http://www.it.net.cn windows

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)" "-"

三、攻擊主要針對php應用，php併發跟nginx差了好幾個數量級。此次攻擊，平均每臺php 每秒最高承受200個併發，絕大部分的針對列表頁，直接對數據庫形成影響。 centos

4、解決方案

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

用封IP的方式來阻止攻擊源IP，是一種方法，起初，我是採用了這種方法，可是這樣封IP，還須要到日誌中去搜索。比較繁瑣，並且效果不明現。 IT網.com，http://www.it.net.cn

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的結果

5、總結

一、本次nginx 在防小型ddos或者cc有本身的特點:處理請求高效，消耗資源極低。 IT網.cn，http://www.it.net.cn

缺點：須要分析日誌，找到規律，好比：user-agent等等。

二、疑問?

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

A:cc攻擊者攻擊時，都會有本身特殊的user-agent，屏蔽該類user-agent，不會形成額外的誤殺。這是經過觀察屏蔽日誌的得出來的結論，服務器用上該類策略後，歷來木有一個網友由於這事找過。

Q:若是cc攻擊軟件假裝成正常的user-agent，這樣的形成誤殺多大？ IT網.cn，http://www.it.net.cn

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防禦策略能夠這麼作， IT網.cn，http://www.it.net.cn 

if （$http__referer ~ * "/zhuanti/nzpp/zonghegr.jsp?group=2"）
{
  return 444;
} IT網，http://www.it.net.cn

這樣就不會有誤殺了

三、經驗教訓 IT網，http://www.it.net.cn

教訓：去年的一次CC攻擊，跟此次攻擊有殊途同歸之處，都是打的是php；那時咱們在啓用了黑洞防禦牆後效果並不明顯。

經驗:當天晚上，我仔細分析了web日誌，發現其user-agent，都是相同的，例如windows 5.0，跟正常的windows NT 5.0有本質區別，那可不能夠在這上面作文章呢。帶着這個問題，在網上搜索了nginx 防cc方面的資料，果真發現網上的高手的想法跟個人相同，都從其相同點user-agent入手，用nginx 來匹配該類user-agent，而後返回503 http狀態碼，固然這裏我作了修改，返回了444狀態碼。因此，在吸收了上次的教訓後，在今年網站遭受攻擊時，我果斷採用該條策略，結果證實效果很明顯。雖然cc攻擊一直在持續，可是網站訪問依然流暢。

公司網站直接不能訪問了，當即登陸服務器，直接top看到狀況以下：

509ICG~L8BBP3)HF(11-27-16-40-01)

發現負載都達到了800了，機器眼看就要爆了，首先先停了mysql，發現負載有點降低，聯繫了開發同事一同查看，由於今天新上線了一些代碼，多是新上代碼的問題，隨後看到負載依然沒降，而後將php和nginx都重啓了，雖然短暫的降了一些，過一會立馬負載又起來了，這時看了下nginx日誌，看是否是用戶訪問致使的問題，結果一看就發現問題了，以下：

Catch(11-27-16-40-01)

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

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

QQ圖片20141127174138

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

QQ圖片20141127174523
將攻擊的ip所有寫入iptables裏面，而後聯繫機房看能不能作策略協助解決這種CC攻擊，最後機房那邊也將這些ip給封了，可是攻擊者在換ip怎麼辦？不可能他換一個我加一條把，看來只能發大招了，寫了個iptables腳本，以下：

QQ圖片20141127174901
統計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;
}

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程