ngx_waf：方便且高性能的 Nginx 防火墻模塊

緩存策略為 LRU，IP 檢查和 CC 防御花費常數時間，其它的檢查花費 O(nm) 的時間，其中 n 是相關規則的條數，m 為執行正則匹配的時間復雜度，但是每次檢查過后會自動緩存本次檢查的結果，下次檢查相同的目標時就可以使用緩存而不是檢查全部的規則。不會緩存 POST 請求體的檢查結果。

1工具特點

介紹了該工具的主要特點以及核心功能！

該 Nginx 的第三方擴展工具，可以防御 CC 攻擊(超出限制后自動拉黑對應 IP 一段時間或者使用驗證碼做人機識別)，可以支持多種黑白名單(IP/POST/URL/UA等等)，還可以提供防護 SQL 注入和 XSS 工具。

使用簡單

配置文件和規則文件書寫簡單，可讀性強

基礎防護

如 IP 或 IP 網段的黑白名單、URI 黑白名單和請求體黑名單等

高性能

使用高效的 IP 檢查算法和緩存機制，支持 IPV4 和 IPV6

高級防護

兼容 ModSecurity 的規則，你可以使用 OWASP 的核心規則庫

友好爬蟲驗證

支持驗證 Google、Bing、Baidu 和 Yandex 的爬蟲并自動放行，避免錯誤攔截，主要是基于 User-Agent 和 IP 的識別規則

驗證碼

支持三種驗證碼：hCaptcha、reCAPTCHAv2 和 reCAPTCHAv3

2模塊安裝

第三方模塊我們應該怎么安裝呢？

Nginx 提供兩種安裝模塊的方式，即「靜態鏈接」和「動態加載」，通過兩種方式安裝的模塊也分別稱為「靜態模塊」和「動態模塊」，可以通過運行腳本 assets/guide.sh 來選擇使用靜態模塊還是動態模塊。

#執行如下命令
$shassets/guide.sh

#如果輸出下面這行，則建議使用動態模塊
#Itisrecommendedthatyouusedynamicmodules.

#如果輸出下面這行，則建議使用靜態模塊
#Itisrecommendedthatyouusestaticmodules.

[1] 靜態模塊

編譯安裝一個新的模塊需要知道當前的 Nginx 的 configure 腳本的參數，您可以通過運行 nginx -V 來獲取，務必記住 configure arguments: 后面的內容。安裝靜態模塊需要重新編譯整個 Nginx，花費的時間相對于安裝動態模塊比較長。如果不想在替換二進制文件時，關閉 Nginx 服務的話，可以參考官方文檔的熱部署方案。

#下載對應的Nginx版本
#http://nginx.org/en/download.html
$cd/usr/local/src
$wgethttps://nginx.org/download/nginx-1.20.1.tar.gz
$tar-zxfnginx-1.20.1.tar.gz

#使用穩定版的源碼
$cd/usr/local/src
$gitclone-bltshttps://github.com/ADD-SP/ngx_waf.git

#運行配置腳本
$cd/usr/local/src/nginx-1.20.1
$./configureARG--add-module=/usr/local/src/ngx_waf
$sed-i's/^(CFLAGS.*)/1
-fstack-protector-strong-Wno-sign-compare/'
objs/Makefile

#編譯(非并行/并行)
$make
$make-j$(nproc)

#替換Nginx二進制文件(假設已經安裝過)
$cpobjs/nginx/usr/local/nginx/sbin/nginx

[2] 動態模塊 - 下載預構建的模塊

通過執行腳本 assets/download.sh 來下載動態模塊。

#用于nginx-1.20.1的LTS版的模塊
$shassets/download.sh1.20.1lts

#用于nginx-1.20.1的最新版的模塊
$shassets/download.sh1.20.1current

#執行成功后會有如下輸出
checkingforcommand...yes
checkingforlibcimplementation...yes
+GNUClibary
Pullingremoteimageaddsp/ngx_waf-prebuild:ngx-1.20.1-module-beta-glibc
......
Downloadcomplete!

如果看到 Download complete! 的話，則說明下載成功，模塊會被保存在當前目錄下。你可以將其拷貝到一個目錄下，然后在 nginx.conf 的頂部添加一行。然后關閉 Nginx 服務并運行 nginx -t。如果沒有出錯則說明模塊被正常加載，反之則說明您的 Nginx 不支持預構建的模塊，請編譯安裝模塊。

load_module"/path/to/ngx_http_waf_module.so";

[3] 動態模塊 - 編譯動態模塊

編譯安裝動態模塊并不需要重新編譯整個 Nginx，只需要重新編譯所有的模塊，所以速度相對靜態模塊快一些，這也是本文檔推薦的方式。

#下載對應的Nginx版本
#http://nginx.org/en/download.html
$cd/usr/local/src
$wgethttps://nginx.org/download/nginx-1.20.1.tar.gz
$tar-zxfnginx-1.20.1.tar.gz

#使用穩定版的源碼
$cd/usr/local/src
$gitclone-bltshttps://github.com/ADD-SP/ngx_waf.git

#運行配置腳本
$cd/usr/local/src/nginx-1.20.1
$./configure--add-dynamic-module=/usr/local/src/ngx_waf--with-compat
$sed-i's/^(CFLAGS.*)/1
-fstack-protector-strong-Wno-sign-compare/'
objs/Makefile

#開始編譯動態模塊
$makemodules

#將動態模塊拷貝到模塊目錄(關閉服務)
$cpobjs/*.so/usr/local/nginx/modules

最后，在 Nginx 的配置文件頂部添加一行，表示加載這個編譯好的模塊。

load_module"/usr/local/nginx/modules/ngx_http_waf_module.so";

3模塊使用

第三方模塊我們應該怎么使用呢？更多參數參考 配置語法

現在就可以在 nginx.conf 內的一個 server 塊中添加配置來開啟 ngx_waf 模塊來配置服務的防火墻了，下面是一個例子。

[1] LTS 版本

http{
...
server{
...
#on/off表示啟用和關閉
wafon;

#規則文件所在目錄的絕對路徑，必須以/結尾
waf_rule_path/usr/local/src/ngx_waf/assets/rules/;

#防火墻工作模式，STD表示標準模式
waf_modeSTD;

#CC防御參數
#1000表示每分鐘請求次數上限，超出上限后封禁對應ip地址60分鐘
waf_cc_denyrate=1000r/mduration=60m;

#最多緩存50個檢測目標的檢測結果
#對除了IP黑白名單檢測、CC防護和POST檢測以外的所有檢測生效
waf_cachecapacity=50;
...
}
...
}

[2] Current 版本

http{
#聲明一塊共享內存
waf_zonename=wafsize=20m;
...
server{
...
#on/off表示啟用和關閉
wafon;

#規則文件所在目錄的絕對路徑，必須以/結尾
waf_rule_path/usr/local/src/ngx_waf/assets/rules/;

#防火墻工作模式，STD表示標準模式
waf_modeSTD;

#CC防御參數
#1000表示每分鐘請求次數上限，超出上限后封禁對應ip地址60分鐘
waf_cc_denyonrate=1000r/mduration=60mzone=waf:cc;

#對除了IP黑白名單檢測、CC防護和POST檢測以外的所有檢測生效
waf_cacheoncapacity=50;
...
}
...
}

4常用設置

列出一些 常用的設置，拿來直接就可以使用！

因為模塊的配置比較復雜，為了降低使用難度，在這里列出了一些常見用法。

[1] 針對路徑或文件限流

有時你可能想要限制不同的路徑或文件的請求速率，比如靜態資源和動態資源使用不同的速率限制。

#LTS

#將靜態資源的請求速率限制到10,000次/分鐘
location/static/{
waf_cc_denyrate=10000r/mduration=1h;
}

#將動態資源的請求速率限制到2,000次/分鐘
location/dynamic/{
waf_cc_denyrate=2000r/mduration=1h;
}

#Current

http{
waf_zonename=wafsize=20m;
server{
#將靜態資源的請求速率限制到10,000次/分鐘
location/static/{
waf_cc_denyrate=10000r/mduration=1hzone=waf:cc_static;
}

#將動態資源的請求速率限制到2,000次/分鐘
location/dynamic/{
waf_cc_denyrate=2000r/mduration=1hzone=waf:cc_dynamic;
}
}
}

[2] 開啟驗證碼

hCaptcha

reCAPTCHAv2

reCAPTCHAv3

當你的站點受到 CC 攻擊時開啟驗證碼是不錯的選擇，因為驗證碼可以幫助你進行人機識別。本模塊目前支持三種驗證碼，你應該選擇一個并從其網站上申請到 Sitekey 和 Secret。配置完成之后，重啟 nginx 服務。

#整個站點開啟驗證碼
server{
waf_captchaonprov=hCaptchasecret=your_secretsitekey=your_sitekey;
}

#為某個路徑開啟驗證碼
location{
waf_captchaonprov=hCaptchasecret=your_secretsitekey=your_sitekey;
}

#當訪問頻率過高時開啟驗證碼
http{
waf_zonename=wafsize=20m;
server{
waf_cc_denyonrate=1000r/mduration=1hzone=waf:cc;
waf_captchaoffprov=hCaptchasecret=your_secretsitekey=your_sitekey;
waf_actioncc_deny=CAPTCHAzone=waf:action;
}
}

[3] 攔截請求時啟用驗證碼

如今，許多攻擊者都會使用自動工具攻擊服務器，這些自動工具會嘗試每一個漏洞，有的會被安全措施所攔截，有的則可以躲避檢測。如果攻擊者覺得你的價值比較高，可能會手動攻擊你的服務。我們并不能完美地防御這些攻擊，但卻能很簡單地提高攻擊的成本。

當一個請求被攔截時，ngx_waf 會對該 IP 啟用驗證碼，此時該 IP 想要繼續訪問就必須完成驗證碼。這基本可以廢掉多數的自動攻擊工具，因為這些工具會嘗試每一個漏洞，而我們總能識別一些明顯的攻擊請求并啟用驗證碼，而自動工具時難以通過驗證的。對于手動攻擊者，這也能提高他們的時間成本。

http{
waf_zonename=wafsize=20m;

server{
waf_captchaoffprov=xxxsitekey=xxxsecret=xxx;
waf_actionblacklist=CAPTCHAzone=waf:action;
}
}

[4] 被攻擊時降低帶寬占用

當你受到 CC 攻擊時，攻擊者的 IP 已經被 CC 防護拉黑，但是你的上下行帶寬依然很高， 這是因為 CC 防護會返回一個 503 狀態碼，因此占用了你的帶寬，你可以使用下面的配置來降低帶寬占用。

444 狀態碼是 nginx定義的一個非標準的 HTTP 狀態碼，其作用就是直接關閉連接，不再發送任何數據。如果你使用了 444 狀態碼，那么在用戶看來你的網站就像是不存在一樣。這是因為網站出錯一般都會有 HTTP 狀態碼用來提示錯誤， 如果訪問一個網站連錯誤提示都沒有，那么大概率是這個網站不存在。

#LTS
waf_http_statuscc_deny=444;

#Current
waf_actioncc_deny=444;

[5] 抵御分布式 CC 攻擊

CC 攻擊(HTTP 洪水)是指發送大量的 HTTP 請求來耗盡服務器的資源。如果攻擊者使用的 IP 較少則防御較為簡單，因為只需要限制 IP 的請求頻率，但是如果攻擊者使用大量的 IP 進行攻擊，僅僅限制 IP 的請求頻率是無濟于事的。這種使用大量 IP 進行 CC 攻擊的方式稱為分布式 CC 攻擊或分布式 HTTP 洪水。

本模塊提供了一些緩解方式，第一種開啟驗證碼來緩解，第二種使用降低帶寬占用，第三種使用五秒盾來緩解。你可能聽說過 Cloudflare 的五秒盾，本模塊的五秒盾和 Cloudflare 的完全不同。它的功能是檢測客戶端是否能夠正確地支持 Cookie，比如發送 Cookie 和正確地處理 Set-Cookie 響應頭。你可以從本項目的 assets/ 目錄下找到 under-attack.html 并將其拷貝到某個路徑下，然后通過修改 nginx 的配置文件來開啟五秒盾。

#LTS

#為整個網站開啟五秒盾
server{
waf_under_attackonfile=/path/to/under_attack.html;
}

#為某個路徑開啟五秒盾
location/path{
waf_under_attackonfile=/path/to/under_attack.html;
}

#Current

#為整個網站開啟五秒盾
server{
waf_under_attackon;
}

#為某個路徑開啟五秒盾
location/path{
waf_under_attackon;
}

5效果測試

如需更多幫助，可以參考 如何測試！

當我們部署和配置服務完成之后，需要測試下防火墻是否正常起作用了，可以通過如下方式進行簡單的測試來判斷規則是否正常運行。

#測試時的配置
master_processon;
worker_processes1;

http{
server{
listen80;
server_namelocalhost;

access_logoff;

wafon;
waf_modeDYNAMIC!CC!POST;
waf_rule_path/usr/local/src/ngx_waf/rules/;
waf_cachecapacity=6000interval=1hpercent=50;

location/{
default_typetext/html;
return200'hello';
}
}
}

[1] 簡易測試

運行下列命令，如果輸出 403 則表示模塊正常工作

$curl-I-o/dev/null--user-agentbench
-s-w"%{http_code}\n"https://example.com

[2] 自動測試

項目附帶了許多測試用例，你可以通過下面的指令來運行全部的用例

#這行命令的執行時間比較長
$cpanTest::Nginx

#如果目錄已經存在則會先刪除再創建
$exportMODULE_TEST_PATH=/path/to/temp/dir

#如果你安裝了動態模塊則需要指定動態模塊的絕對路徑，反之則無需執行這行命令
$exportMODULE_PATH=/path/to/ngx_http_waf_module.so

#自動化測試
$cd./test/test-nginx
$sh./init.sh
$sh./start.sh./t/*.t

#可以使用WRK工具測試
$wrk-c100-d30m-t1-stest/wrk/rand.lua--latency
http://localhost/--/path/to/rand-str.txt

6注意事項

如需更多幫助，可以參考 常見問題與解答！

本模塊只保證對 nginx-1.18.0 或更新的版本的兼容性，且不保證與 Linux 以外的操作系統的兼容性。這里需要注意的是，模塊與 ngx_http_rewrite_module 存在兼容性問題。

當 return 指令生效時，該模塊不會生效

當 rewrite 指令造成了返回(如 302 重定向)時，該模塊不會生效

所以可以使用 try_files 代替 rewrite 指令，避免上述問題的出現

#rewrite
if(!-e$request_filename){
rewrite(.*)/index.php
}

#try_files
try_files$uri$uri//index.php;

7參考鏈接

Github 代碼倉庫

黑白名單規則說明

檢測項目規則優先級

模塊的內置變量

日志相關的配置說明

審核編輯：湯梓紅