NGINX ModSecurity 快速入門與 OWASP 核心規則設定

本文旨在提供一個 NGINX 與 ModSecurity 3.0 的整合設定範例，並著重於 OWASP 核心規則集的應用與調整。首先設定 NGINX 作為反向代理伺服器，之後逐步匯入 ModSecurity 的基本規則與 OWASP CRS，並使用 Nikto 掃描工具進行安全性測試與驗證。過程中也包含了針對常見弱點的防護措施，例如跨站指令碼攻擊 (XSS) 的防禦設定，以及如何根據實際情況調整規則，減少誤報並提升防護效果。最後，文章也簡要介紹了 Trustwave SpiderLabs 商業規則集的整合方式，提供更進階的防護選項。

ModSecurity 3.0 與 NGINX：快速入門 - 第二章：安裝 ModSecurity

測試應用程式

首先，重新載入 NGINX 組態並發出請求以測試應用程式：

$ sudo nginx -s reload
$ curl -D - http://localhost:8085

輸出結果應類別似如下：

HTTP/1.1 200 OK
Server: nginx/1.11.10
Date: Wed, 3 May 2017 08:55:29 GMT
Content-Type: text/plain
Content-Length: 27
Connection: keep-alive
Thank you for requesting /

內容解密：

此步驟驗證 NGINX 是否正確執行並能夠處理請求。curl 命令用於傳送 HTTP 請求，而 -D - 選項則用於顯示回應頭。

組態 NGINX 為反向代理

接下來，將 NGINX 組態為 demo 應用程式的反向代理。

建立檔案 /etc/nginx/conf.d/proxy.conf，內容如下：

server {
    listen 80;
    location / {
        proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
    }
}

內容解密：

此組態建立了一個虛擬伺服器，監聽 80 埠，並將所有請求代理到 demo 應用程式。proxy_set_header 用於設定轉發請求的 Host 頭部。

重新載入 NGINX 組態：

$ sudo nginx -s reload

驗證請求是否成功，以確認代理工作正常：

$ curl -D - http://localhost

輸出結果應與前一步驟類別似，確認反向代理組態正確。

內容解密：

此步驟確保 NGINX 能夠正確地將請求轉發到 demo 應用程式，並將回應傳回給客戶端。

保護 Demo 網路應用程式

現在，將組態 ModSecurity 3.0 以保護 demo 網路應用程式，方法是阻止某些請求。

建立資料夾 /etc/nginx/modsec 以儲存 ModSecurity 組態：

$ sudo mkdir /etc/nginx/modsec

從 ModSecurity 的 GitHub 倉函式庫下載推薦的 ModSecurity 組態檔案，並命名為 modsecurity.conf：

$ cd /etc/nginx/modsec
$ sudo wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
$ sudo mv modsecurity.conf-recommended modsecurity.conf

內容解密：

此步驟下載並組態了 ModSecurity 的基本組態檔案，為進一步的規則組態奠定了基礎。

編輯 modsecurity.conf 以啟用規則執行：

# SecRuleEngine DetectionOnly
SecRuleEngine On

內容解密：

SecRuleEngine On 指令啟用了 ModSecurity 的規則引擎，使其能夠根據組態的規則檢查和處理請求。

建立主要的 ModSecurity 3.0 組態檔案 /etc/nginx/modsec/main.conf，並定義一個規則：

# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf

# A test rule
SecRule ARGS:testparam "@contains test" "id:1234,deny,log,status:403"

內容解密：

此組態包含了推薦的 ModSecurity 組態，並定義了一個測試規則。當查詢字串中的 testparam 引數包含 “test” 字串時，該規則將阻止請求並傳回 403 狀態碼。

修改反向代理組態檔案 (/etc/nginx/conf.d/proxy.conf) 以啟用 ModSecurity 3.0：

server {
    listen 80;
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
    location / {
        proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
    }
}

內容解密：

modsecurity on 啟用了 ModSecurity，而 modsecurity_rules_file 指定了 ModSecurity 組態檔案的位置。

重新載入 NGINX 組態：

$ sudo nginx -s reload

驗證在步驟 4 中組態的規則是否正確工作，方法是發出包含 “test” 字串的請求：

$ curl -D - http://localhost/foo?testparam=thisisatestofmodsecurity

輸出結果應傳回 403 狀態碼，確認 WAF 已啟用並執行了規則。

內容解密：

此步驟驗證了 ModSecurity 是否能夠根據組態的規則正確地阻止惡意請求。

安裝 OWASP Core Rule Set

OWASP ModSecurity Core Rule Set 是與 ModSecurity 一起使用的標準規則集。它是抵禦攻擊的第一道防線，例如 OWASP Top Ten 中描述的攻擊。安裝 ModSecurity 3.0 軟體後，下一步是安裝一個或多個 ModSecurity 規則集。強烈建議所有使用者安裝基本規則集，即 OWASP Core Rule Set (CRS)。CRS 由社群維護，包含有助於阻止常見攻擊向量的規則，包括 SQL 注入（SQLi）、跨站指令碼（XSS）等。

本章涵蓋了 OWASP CRS 的安裝。

ModSecurity 3.0 與 NGINX：快速入門第三章 - 安裝 OWASP 核心規則集

OWASP 核心規則集概述

OWASP 核心規則集最初由 Ofer Shezaf 於 2006 年發布，目前採用 Apache 軟體授權版本 2（ASLv2），並由包括 Dr. Christian Folini 在內的 10 名開發者共同維護。CRS3 版本於 2016 年 11 月發布，最主要的改進是將預設安裝中的誤報率降低了 90% 以上。

CRS 的檔案與目錄結構

CRS 被託管在 GitHub 上，位於 github.com/SpiderLabs/owasp-modsecurity-crs。主要的檔案和目錄包括：

crs-setup.conf.example：CRS 的主要設定檔，定義了異常評分的閾值、警戒級別和其他關鍵的 ModSecurity 設定。
rules/：包含規則的目錄，按照不同的檔案組織，每個檔案都有一個編號：
- 90x 檔案：用於排除誤報的規則。
- 91x 檔案：檢測惡意客戶端（如掃描器和機器人）的規則。
- 92x 檔案：檢測協定違規的規則。
- 93x 和 94x 檔案：檢測應用程式攻擊（如 SQL 注入和遠端命令執行）的規則。
- 95x 檔案：檢測輸出資料洩漏的規則。（不支援 NGINX 或 NGINX Plus）
- .data 檔案：規則使用的資料。例如 crawlers-user-agents.data 包含了用於識別掃描器和機器人的 User-Agent 值列表。

異常評分機制

CRS 使用可設定的異常評分模型。每當一個規則被觸發時，異常評分就會增加。如果評分超過設定的閾值，則交易將被封鎖。異常級別包括：

嚴重：異常評分為 5，表示可能的應用程式攻擊，主要由 93x 和 94x 檔案產生。
錯誤：異常評分為 4，表示可能的資料洩漏，主要由 95x 檔案產生。（不支援 NGINX 或 NGINX Plus）
警告：異常評分為 3，表示可能的惡意客戶端，主要由 91x 檔案產生。
通知：異常評分為 2，表示可能的協定違規，主要由 92x 檔案產生。

安裝前的準備：執行 Nikto 掃描工具

首先，向安裝了 ModSecurity WAF 的 NGINX Plus 示範網頁應用程式傳送攻擊流量。許多攻擊者使用漏洞掃描器來識別目標網站或應用程式中的安全漏洞。我們使用 Nikto 掃描工具來產生惡意請求，包括對已知漏洞檔案的探測、跨站指令碼（XSS）和其他型別的攻擊。

$ git clone https://github.com/sullo/nikto
Cloning into 'nikto'...
$ cd nikto
$ perl program/nikto.pl -h localhost
- Nikto v2.1.6
...
+ 7531 requests: 0 error(s) and 324 item(s) reported on remote host

安裝和啟用 OWASP CRS

從 GitHub 下載最新的 OWASP CRS，並將規則解壓縮到 /usr/local 或您選擇的其他位置。

$ wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz
$ tar -xzvf v3.0.0.tar.gz
$ sudo mv owasp-modsecurity-crs-3.0.0 /usr/local

複製 crs-setup.conf.example 為 crs-setup.conf。

$ cd /usr/local/owasp-modsecurity-crs-3.0.0
$ sudo cp crs-setup.conf.example crs-setup.conf

在主要的 ModSecurity 設定檔（/etc/nginx/modsec/main.conf）中新增 Include 指令，以讀取 CRS 設定和規則。

# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf

# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.0/crs-setup.conf
Include /usr/local/owasp-modsecurity-crs-3.0.0/rules/*.conf

重新載入 NGINX Plus 設定。
```
$ sudo nginx -s reload
```

#### 內容解密：

上述步驟詳細介紹瞭如何安裝和啟用 OWASP CRS。首先，我們從 GitHub 下載 CRS，並將其解壓縮到指定目錄。然後，複製主要的設定檔範例為正式的設定檔，並在 ModSecurity 的主設定檔中包含 CRS 的設定和規則，最後重新載入 NGINX Plus 的設定以使變更生效。

#### 測試 CRS

在本文中，我們將探討 CRS 中的規則如何根據請求的特定特徵封鎖 Nikto 的請求。我們的最終目標是展示 CRS 如何有效地封鎖 Nikto 的請求，從而減少潛在的漏洞。

#### 內容解密：

測試 CRS 的過程中，我們使用 Nikto 掃描工具對示範網頁應用程式發起攻擊，以驗證 CRS 的有效性。透過比較啟用 CRS 前後的掃描結果，可以明顯看出 CRS 對惡意請求的攔截效果，從而提升了應用程式的安全性。

ModSecurity 3.0 與 NGINX：快速入門第三章 - 安裝 OWASP Core Rule Set

停用根據 User-Agent Header 的請求封鎖

OWASP Core Rule Set（CRS）透過檢查 User-Agent header 來識別來自掃描器的請求，包括 Nikto。預設情況下，CRS 會封鎖具有 Nikto 預設 User-Agent header 的請求。

$ curl -H "User-Agent: Nikto" http://localhost/
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.11.10</center>
</body>
</html>

在測試階段，我們不希望封鎖所有來自 Nikto 的請求，因為我們正在使用它們來檢測 Demo 應用程式中的潛在漏洞。要停止 CRS 僅因為 User-Agent header 是 Nikto 而封鎖請求，我們重新組態 Nikto 不在 header 中包含 Nikto 和相關值。

設定 USERAGENT

在 program/nikto.conf 中註解掉目前的 USERAGENT 設定，並替換為以下值：

# USERAGENT=Mozilla/5.00 (Nikto/@VERSION) (Evasions:@EVASIONS) (Test:@TESTID)
USERAGENT=Mozilla/5.00

消除對脆弱檔案的請求

當我們重新執行 Nikto 對 Web 應用程式進行掃描時，我們發現只有 116 個請求到達應用程式伺服器，而 CRS 未啟用時有 324 個請求。這表明 CRS 正在保護我們的應用程式免受 Nikto 請求所暴露的大部分漏洞。

$ perl program/nikto.pl -h localhost
...
+ 7531 requests: 0 error(s) and 116 item(s) reported on remote host

Nikto 的輸出非常長，直到現在我們一直截斷它，只顯示報告專案數量的最後一行。當我們更仔細地檢視輸出時，我們發現許多剩餘的 116 個專案指的是應用程式中的一個脆弱檔案，如下例所示：

$ perl program/nikto.pl -h localhost
...
+ /site.tar: Potentially interesting archive/cert file found.
...
+ 7531 requests: 0 error(s) and 116 item(s) reported on remote host

回想一下，在安裝 NGINX Plus with ModSecurity WAF 時，我們組態了 Demo 應用程式，使其對每個請求都傳回狀態碼 200，而實際上從未傳遞檔案。Nikto 將這些 200 狀態碼解釋為它所請求的檔案實際存在，這在我們的應用程式上下文中是一個假陽性。

停用對脆弱檔案的請求

現在我們消除這樣的請求，以便更好地瞭解實際漏洞可能存在的位置。透過在 program/nikto.conf 中新增 -sitefiles 來停用這些請求，如下所示：

# Default plug-in macros
# Remove plug-ins designed to be run standalone
@@EXTRAS=dictionary;siebel;embedded
@@DEFAULT=@@ALL;-@@EXTRAS;tests(report:500);-sitefiles

封鎖包含 XSS 攻擊的請求

當我們再次重新執行 Nikto 時，它報告了只有 26 個專案：

$ perl program/nikto.pl -h localhost
- Nikto v2.1.6
...
+ 7435 requests: 0 error(s) and 26 item(s) reported on remote host

大多數這 26 個專案出現是因為 OWASP CRS 目前未組態為封鎖在請求 URL 中包含 XSS 嘗試的請求，例如 <script>alert('Vulnerable')</script>。

編輯 XSS Application Attack rule set

要封鎖包含 XSS 嘗試的請求，請編輯 CRS 的 XSS Application Attack rule set（REQUEST-941-APPLICATION-ATTACK-XSS.conf）中的規則 941160 和 941320，透過在每個規則的變數列表開頭新增 REQUEST_URI：

SecRule REQUEST_URI|REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/ ...

重新載入 NGINX Plus 組態

重新載入 NGINX Plus 組態以讀取修訂後的規則集：

$ sudo nginx -s reload

當我們重新執行 Nikto 時，它報告了只有四個專案，並且它們是針對我們的應用程式的假陽性：

$ perl program/nikto.pl -h localhost
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /smg_Smxcfg30.exe?vcc=3560121183d3: This may be a Trend Micro Officescan 'backdoor'.
+ 7435 requests: 0 error(s) and 4 item(s) reported on remote host

ModSecurity 3.0 與 NGINX：快速入門第四章 - 安裝 TrustWave SpiderLabs 商業規則集

TrustWave SpiderLabs 商業規則集簡介

Trustwave SpiderLabs 商業規則集提供了超出 OWASP CRS 的額外保護，例如針對 WordPress、Joomla、SharePoint 等的特定應用程式規則集。欲瞭解更多關於 Trustwave SpiderLabs 商業規則集的資訊，請存取：trustwave.com/Products/Application-Security/ModSecurity-Rules-and-Support。

本章涵蓋了 Trustwave SpiderLabs 商業規則集的安裝。

總覽

Trustwave SpiderLabs 的 ModSecurity® Rules 補充了 Open Web Application Security Project Core Rule Set（OWASP CRS），為多種常見應用程式（ASP.NET、Joomla、WordPress 等）提供了針對特定攻擊的保護，包括 SQL injection、cross-site scripting（XSS）、local 和 remote file includes（LFI 和 RFI）。此外，Trustwave SpiderLabs Rules 提供了 IP 評價和其他功能，並每天更新。

本章建立在安裝 ModSecurity 的基本組態之上，展示如何組態 Trustwave SpiderLabs Rules 以保護在那裡建立的 Demo Web 應用程式。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

NGINX ModSecurity 快速入門與 OWASP 核心規則設定

ModSecurity 3.0 與 NGINX：快速入門 - 第二章：安裝 ModSecurity

測試應用程式

內容解密：

組態 NGINX 為反向代理

內容解密：

內容解密：

保護 Demo 網路應用程式

內容解密：

內容解密：

內容解密：

內容解密：

內容解密：

安裝 OWASP Core Rule Set

本章涵蓋了 OWASP CRS 的安裝。

ModSecurity 3.0 與 NGINX：快速入門 第三章 - 安裝 OWASP 核心規則集

OWASP 核心規則集概述

CRS 的檔案與目錄結構

異常評分機制

安裝前的準備：執行 Nikto 掃描工具

安裝和啟用 OWASP CRS

#### 內容解密：

#### 測試 CRS

#### 內容解密：

ModSecurity 3.0 與 NGINX：快速入門 第三章 - 安裝 OWASP Core Rule Set

停用根據 User-Agent Header 的請求封鎖

設定 USERAGENT

消除對脆弱檔案的請求

停用對脆弱檔案的請求

封鎖包含 XSS 攻擊的請求

編輯 XSS Application Attack rule set

重新載入 NGINX Plus 組態

ModSecurity 3.0 與 NGINX：快速入門 第四章 - 安裝 TrustWave SpiderLabs 商業規則集

TrustWave SpiderLabs 商業規則集簡介

總覽

玄貓 BlackCat

ModSecurity 3.0 與 NGINX：快速入門第三章 - 安裝 OWASP 核心規則集

ModSecurity 3.0 與 NGINX：快速入門第三章 - 安裝 OWASP Core Rule Set

ModSecurity 3.0 與 NGINX：快速入門第四章 - 安裝 TrustWave SpiderLabs 商業規則集