Nginx伺服器抵禦CC攻擊的相關配置講解

0x00 CC攻擊的基本原理

CC攻擊利用代理伺服器向網站發送大量需要較長計算時間的URL請求，如資料庫查詢等，導致伺服器進行大量計算而很快達到自身的處理能力而形成DOS。而攻擊者一旦發送請求給代理後就主動斷開連接，因??代理並不因??客戶端這邊連接的斷開就不去連接目標伺服器。因此攻擊機的資源消耗相對很小，而從目標伺服器看來，來自代理的請求都是合法的。

以前防CC攻擊的方法

為了防範CC，以前的方法一個是限制每個IP的連接數，這在地址範圍很廣闊的情況下比較難實現;二是限制代理的訪問，因為一般的代理都會在HTTP頭中帶 X_FORWARDED_FOR欄位，但也有局限，有的代理的請求中是不帶該欄位的，另外有的客戶端確實需要代理才能連接目標伺服器，這種限制就會拒絕一些正常用戶訪問。

CC攻擊用硬防難防住

CC攻擊比DDOS攻擊更可怕的就是，CC攻擊一般是硬防很難防止住的。

個人分析原因有三：

一、因為CC攻擊來的IP都是真實的，分散的;

二、CC攻擊的數據包都是正常的數據包;

三、CC攻擊的請求，全都是有效的請求，無法拒絕的請求。

防CC攻擊思路

防CC有效性在於攻擊方不接受伺服器回應的數據，發送完請求後就主動斷開連接，因此要確認連接是否是CC，伺服器端不立即執行URL請求命令，而是簡單的返回一個頁面轉向的回應，回應中包含新的URL請求地址。如果是正常訪問，客戶端會主動再次連接到轉向頁面，對用戶來說是透明的;而對於CC攻擊者，由於不接收回應數據，因此就不會重新連接，伺服器也就不需要繼續進行操作。

0x01 驗證瀏覽器行為簡易版

我們先來做個比喻。

社區在搞福利，在廣場上給大家派發紅包。而壞人派了一批人形的機器人(沒有語言模塊)來冒領紅包，聰明工作人員需要想出辦法來防止紅包被冒領。

於是工作人員在發紅包之前，會給領取者一張紙，上面寫著「紅包拿來」，如果那人能念出紙上的字，那麼就是人，給紅包，如果你不能念出來，那麼請自覺。於是機器人便被識破，灰溜溜地回來了。

是的，在這個比喻中，人就是瀏覽器，機器人就是攻擊器，我們可以通過鑒別cookie功能(念紙上的字)的方式來鑒別他們。下面就是nginx的配置文件寫法。

if($cookie_say!="hbnl"){add_headerSet-Cookie"say=hbnl";rewrite.*"$scheme://$host$uri"redirect;}

讓我們看下這幾行的意思，當cookie中say為空時，給一個設置cookie say為hbnl的302重定向包，如果訪問者能夠在第二個包中攜帶上cookie值，那麼就能正常訪問網站了，如果不能的話，那他永遠活在了302中。你也可以測試一下，用CC攻擊器或者webbench或者直接curl發包做測試，他們都活在了302世界中。

當然，這麼簡單就能防住了？當然沒有那麼簡單。

增強版

仔細的你一定會發現配置文件這樣寫還是有缺陷。如果攻擊者設置cookie為say=hbnl（CC攻擊器上就可以這麼設置），那麼這個防禦就形同虛設了。我們繼續拿剛剛那個比喻來說明問題。

壞人發現這個規律後，給每個機器人安上了揚聲器，一直重複著「紅包拿來，紅包拿來」，浩浩蕩蕩地又來領紅包了。

這時，工作人員的對策是這樣做的，要求領取者出示有自己名字的戶口本，並且念出自己的名字，「我是xxx，紅包拿來」。於是一群只會嗡嗡叫著「紅包拿來」的機器人又被攆回去了。

當然，為了配合說明問題，每個機器人是有戶口本的，被趕回去的原因是不會念自己的名字，雖然這個有點荒誕，唉。

然後，我們來看下這種方式的配置文件寫法

if($cookie_say!="hbnl$remote_addr"){add_headerSet-Cookie"say=hbnl$remote_addr";rewrite.*"$scheme://$host$uri"redirect;}

這樣的寫法和前面的區別是，不同IP的請求cookie值是不一樣的，比如IP是1.2.3.4，那麼需要設置的cookie是say=hbnl1.2.3.4。於是攻擊者便無法通過設置一樣的cookie(比如CC攻擊器)來繞過這種限制。你可以繼續用CC攻擊器來測試下，你會發現CC攻擊器打出的流量已經全部進入302世界中。

不過大家也能感覺到，這似乎也不是一個萬全之計，因為攻擊者如果研究了網站的機制之後，總有辦法測出並預先偽造cookie值的設置方法。因為我們做差異化的數據源正是他們本身的一些信息（IP、user agent等）。攻擊者花點時間也是可以做出專門針對網站的攻擊腳本的。

完美版

那麼要如何根據他們自身的信息得出他們又得出他們算不出的數值？

我想，聰明的你一定已經猜到了，用salt加散列。比如md5("opencdn$remote_addr")，雖然攻擊者知道可以自己IP，但是他無法得知如何用他的IP來計算出這個散列，因為他是逆不出這個散列的。當然，如果你不放心的話，怕cmd5.com萬一能查出來的話，可以加一些特殊字元，然後多散幾次。

很可惜，nginx默認是無法進行字元串散列的，於是我們藉助nginx_lua模塊來進行實現。

rewrite_by_lua local say = ngx.md5("opencdn".. ngx.var.remote_addr)if(ngx.var.cookie_say ~= say) then ngx.header["Set-Cookie"] ="say=".. sayreturnngx.redirect(ngx.var.scheme .."://".. ngx.var.host .. ngx.var.uri) end ;

通過這樣的配置，攻擊者便無法事先計算這個cookie中的say值，於是攻擊流量(代理型CC和低級發包型CC)便在302地獄無法自拔了。

大家可以看到，除了借用了md5這個函數外，其他的邏輯和上面的寫法是一模一樣的。因此如果可以的話，你完全可以安裝一個nginx的計算散列的第三方模塊來完成，可能效率會更高一些。

這段配置是可以被放在任意的location裡面，如果你的網站有對外提供API功能的話，建議API一定不能加入這段，因為API的調用也是沒有瀏覽器行為的，會被當做攻擊流量處理。並且，有些弱一點爬蟲也會陷在302之中，這個需要注意。

同時，如果你覺得set-cookie這個動作似乎攻擊者也有可能通過解析字元串模擬出來的話，你可以把上述的通過header來設置cookie的操作，變成通過高端大氣的js完成，發回一個含有doument.cookie=...的文本即可。

那麼，攻擊是不是完全被擋住了呢？只能說那些低級的攻擊已經被擋住而來，如果攻擊者必須花很大代價給每個攻擊器加上webkit模塊來解析js和執行set-cookie才行，那麼他也是可以逃脫302地獄的，在nginx看來，確實攻擊流量和普通瀏覽流量是一樣的。那麼如何防禦呢？下節會告訴你答案。

0x02 請求頻率限制

不得不說，很多防CC的措施是直接在請求頻率上做限制來實現的，但是，很多都存在著一定的問題。

那麼是哪些問題呢？

首先，如果通過IP來限制請求頻率，容易導致一些誤殺，比如我一個地方出口IP就那麼幾個，而訪問者一多的話，請求頻率很容易到上限，那麼那個地方的用戶就都訪問不了你的網站了。

於是你會說，我用SESSION來限制就有這個問題了。嗯，你的SESSION為攻擊者敞開了一道大門。為什麼呢？看了上文的你可能已經大致知道了，因為就像那個「紅包拿來」的揚聲器一樣，很多語言或者框架中的SESSION是能夠偽造的。以PHP為例，你可以在瀏覽器中的cookie看到PHPSESSIONID，這個ID不同的話，session也就不同了，然後如果你杜撰一個PHPSESSIONID過去的話，你會發現，伺服器也認可了這個ID，為這個ID初始化了一個會話。那麼，攻擊者只需要每次發完包就構造一個新的SESSIONID就可以很輕鬆地躲過這種在session上的請求次數限制。

那麼我們要如何來做這個請求頻率的限制呢？

首先，我們先要一個攻擊者無法杜撰的sessionID，一種方式是用個池子記錄下每次給出的ID，然後在請求來的時候進行查詢，如果沒有的話，就拒絕請求。這種方式我們不推薦，首先一個網站已經有了session池，這樣再做個無疑有些浪費，而且還需要進行池中的遍歷比較查詢，太消耗性能。我們希望的是一種可以無狀態性的sessionID，可以嗎？可以的。

rewrite_by_lua local random = ngx.var.cookie_randomif(random ==nil) then random = math.random(999999) end local token = ngx.md5("opencdn".. ngx.var.remote_addr .. random)if(ngx.var.cookie_token ~= token) then ngx.header["Set-Cookie"] = {"token=".. token,"random=".. random}returnngx.redirect(ngx.var.scheme .."://".. ngx.var.host .. ngx.var.uri) end ;

大家是不是覺得好像有些眼熟？是的，這個就是上節的完美版的配置再加個隨機數，為的是讓同一個IP的用戶也能有不同的token。同樣的，只要有nginx的第三方模塊提供散列和隨機數功能，這個配置也可以不用lua直接用純配置文件完成。

有了這個token之後，相當於每個訪客有一個無法偽造的並且獨一無二的token，這種情況下，進行請求限制才有意義。

由於有了token做鋪墊，我們可以不做什麼白名單、黑名單，直接通過limit模塊來完成。

http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;}

然後我們只需要在上面的token配置後面中加入

limit_reqzone=session_limit burst=5;

於是，又是兩行配置便讓nginx在session層解決了請求頻率的限制。不過似乎還是有缺陷，因為攻擊者可以通過一直獲取token來突破請求頻率限制，如果能限制一個IP獲取token的頻率就更完美了。可以做到嗎？可以。

http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m;}location /{ limit_req zone=session_limit burst=5; rewrite_by_lua local random = ngx.var.cookie_randomif(random ==nil) thenreturnngx.redirect("/auth?url=".. ngx.var.request_uri) end local token = ngx.md5("opencdn".. ngx.var.remote_addr .. random)if(ngx.var.cookie_token ~= token) thenreturnngx.redirect("/auth?url=".. ngx.var.request_uri) end ;}location /auth { limit_req zone=auth_limit burst=1;if($arg_url ="") { return403; } access_by_lua local random = math.random(9999) local token = ngx.md5("opencdn".. ngx.var.remote_addr .. random)if(ngx.var.cookie_token ~= token) then ngx.header["Set-Cookie"] = {"token=".. token,"random=".. random}returnngx.redirect(ngx.var.arg_url) end ;}

我想大家也應該已經猜到，這段配置文件的原理就是：把本來的發token的功能分離到一個auth頁面，然後用limit對這個auth頁面進行頻率限制即可。這邊的頻率是1個IP每分鐘授權1個token。當然，這個數量可以根據業務需要進行調整。

需要注意的是，這個auth部分我lua採用的是access_by_lua，原因在於limit模塊是在rewrite階段後執行的，如果在rewrite階段302的話，limit將會失效。因此，這段lua配置我不能保證可以用原生的配置文件實現，因為不知道如何用配置文件在rewrite階段後進行302跳轉，也求大牛能夠指點一下啊。

當然，你如果還不滿足於這種限制的話，想要做到某個IP如果一天到達上限超過幾次之後就直接封IP的話，也是可以的，你可以用類似的思路再做個錯誤頁面，然後到達上限之後不返回503而是跳轉到那個錯誤頁面，然後錯誤頁面也做個請求次數限制，比如每天只能訪問100次，那麼當超過報錯超過100次(請求錯誤頁面100次)之後，那天這個IP就不能再訪問這個網站了。

於是，通過這些配置我們便實現了一個網站訪問頻率限制。不過，這樣的配置也不是說可以完全防止了攻擊，只能說讓攻擊者的成本變高，讓網站的扛攻擊能力變強，當然，前提是nginx能夠扛得住這些流量，然後帶寬不被堵死。如果你家門被堵了，你還想開門營業，那真心沒有辦法了。

然後，做完流量上的防護，讓我們來看看對於掃描器之類的攻擊的防禦。

0x03 防掃描

ngx_lua_waf模塊

這個是一個不錯的waf模塊，這塊我們也就不再重複造輪子了。可以直接用這個模塊來做防護，當然也完全可以再配合limit模塊，用上文的思路來做到一個封IP或者封session的效果。

0x04 總結

本文旨在達到拋磚引玉的作用，我們並不希望你直接單純的複製我們的這些例子中的配置，而是希望根據你的自身業務需要，寫出適合自身站點的配置文件。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！