生產環境實施 ModSecurity 最佳實踐

在實際佈署 ModSecurity 至線上環境前，務必在測試環境中進行充分驗證。本文提供一個檢查清單，確保 ModSecurity 在生產環境穩定執行，並著重於減少誤報、提升效能以及與 NGINX 的整合。首先，建議逐步調整異常閾值，從高值開始，逐步降低至預設值，並監控誤報情況。同時，為了避免效能瓶頸和磁碟空間耗盡，建議在生產環境中關閉稽核日誌，並依靠 NGINX 錯誤日誌記錄被阻擋的請求。此外，應避免對靜態內容進行 ModSecurity 檢查，可利用 NGINX 的 location 指令區分靜態和動態資源，提升處理效率。

為了應對 DDoS 攻擊，可以利用 NGINX 內建的速率限制功能，例如使用 limit_req_zone 和 limit_req 指令設定請求速率上限，保護後端服務。實際佈署時，還需考量伺服器擴充套件性，密切監控 CPU 利用率，並根據實際情況進行垂直或水平擴充套件。此外，應根據應用程式特性精選 ModSecurity 規則，避免不必要的規則增加 CPU 負擔並產生誤報。最後，建議在 NGINX 與 ModSecurity 前端新增快取層，減少重複檢查，並持續關注最新的安全漏洞資訊，確保 Web 應用程式安全。

在生產環境中實施 ModSecurity

在前面的章節中，我們已經在非生產環境中安裝並執行 ModSecurity，同時也啟用了除錯日誌來瞭解其背後的運作。在將 ModSecurity 佈署到生產環境之前，徹底在非生產環境中進行測試是非常重要的。本章節提供了一個檢查清單，以便在將 ModSecurity 完全佈署到生產環境之前進行逐步檢查。

調整 ModSecurity 以減少誤報

誤報是 Web 應用程式防火牆（WAFs）的一大挑戰，許多人因此而不使用 WAFs，或僅在被動監控模式下執行。預設情況下，OWASP Core Rule Set（CRS）觸發的誤報非常少。以下調整 ModSecurity 以減少誤報的方法根據 OWASP CRS 專案共同負責人 Dr. Christian Folini 的建議。

1. 確保 ModSecurity 處於主動攔截模式：如果您一直遵循本文的指示，ModSecurity 應該已經處於攔截模式。如果不存在，請在 modsecurity.conf 中新增以下行：

   SecRuleEngine On
   

2. 確保稽核日誌已啟用（預設情況下已啟用）。

3. 將異常閾值提高到 1000：透過取消註解 crs-setup.conf 中的規則並修改異常閾值來實作：

   SecAction \
     "id:900110,\
     phase:1,\
     nolog,\
     pass,\
     t:none,\
     setvar:tx.inbound_anomaly_score_threshold=1000,\
     setvar:tx.outbound_anomaly_score_threshold=1000"
   

4. 監控稽核日誌中的誤報，並透過在 main.conf 中新增 SecRemoveRuleByID 來防止誤報：

   SecRemoveRuleByID rule-id
   

5. 如果一段時間後沒有看到誤報，則將異常閾值降低一半，並重複步驟 4 和 5。繼續這個過程，直到異常閾值回到預設值 5。

程式碼範例：調整異常閾值

SecAction \
  "id:900110,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.inbound_anomaly_score_threshold=1000,\
  setvar:tx.outbound_anomaly_score_threshold=1000"

內容解密：

• SecAction：這是一個用於執行操作的指令，這裡用於設定變數。
• id:900110：指定該規則的唯一ID。
• phase:1：指定該規則在第一階段執行。
• nolog 和 pass：表示該規則不會記錄日誌且會繼續執行後續規則。
• t:none：表示不對變數進行轉換。
• setvar：用於設定變數的值，這裡設定了入站和出站異常分數的閾值。

停用稽核日誌

在預設的 ModSecurity 組態中，稽核日誌是啟用的，但我們建議在生產環境中停用它，原因有兩個：

1. 稽核日誌會對 ModSecurity 的效能產生負面影響。
2. 日誌檔案可能會快速增長並耗盡磁碟空間。

要停用稽核日誌，請將 modsecurity.conf 中的 SecAuditEngine 指令的值更改為 off：

SecAuditEngine off

NGINX 的錯誤日誌（預設啟用）會記錄所有被阻止的交易，因此您不會因為停用 ModSecurity 稽核日誌而丟失資訊。

程式碼範例：停用稽核日誌

SecAuditEngine off

內容解密：

• SecAuditEngine：控制稽核日誌引擎的指令。
• off：將稽核日誌引擎關閉。

不檢查靜態內容

對由簡單的靜態內容虛擬伺服器或沒有動態應用程式的 Web 伺服器處理的請求執行 ModSecurity 規則意義不大。相反，使用 location 指令將靜態和動態資源的請求路由到不同的伺服器或檔案系統位置。

程式碼範例：分離靜態圖片檔案

server {
    listen 80;
    location / {
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/main.conf;
        proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
    }
    location ~ \.(gif|jpg|png|jpeg|svg)$ {
        root /data/images;
    }
}

內容解密：

• location /：比對根位置，並啟用 ModSecurity。
• location ~ \.(gif|jpg|png|jpeg|svg)$：比對圖片檔案，並直接從 /data/images 提供服務，不經過 ModSecurity 檢查。

使用 NGINX 進行 DDoS 緩解和速率限制

ModSecurity 動態模組目前不支援內建的 CRS 規則進行 DDoS 緩解（REQUEST-912-DOS-PROTECTION.conf）。幸運的是，NGINX 和 NGINX Plus 本身提供了內建的速率限制和 DDoS 緩解功能。

程式碼範例：速率限制組態

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
    listen 80;
    location / {
        limit_req zone=mylimit;
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/main.conf;
        proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
    }
}

內容解密：

• limit_req_zone：定義速率限制的引數。
• $binary_remote_addr：使用客戶端的 IP 地址作為限速的鍵。
• zone=mylimit:10m：定義了一個名為 mylimit 的分享記憶體區域，大小為 10MB。
• rate=10r/s：限制速率為每秒 10 個請求。
• limit_req zone=mylimit：在當前上下文中啟用速率限制，使用之前定義的 mylimit 區域。

在生產環境中實施ModSecurity的最佳實踐

在將ModSecurity佈署到生產環境時，需要考慮多個關鍵因素以確保其高效執行。以下是一些重要的提示和技巧：

擴充套件性準備

• 監控CPU利用率：密切關注NGINX工作程式的CPU利用率。如果持續超過50%，則需要考慮透過增加核心數和執行更多NGINX工作程式來進行垂直擴充套件，或透過佈署更多NGINX伺服器並進行流量負載平衡來進行水平擴充套件。

精選ModSecurity規則

• 按需選擇規則：無需將PHP特定的規則應用於不使用PHP直譯器的應用程式。同樣，如果資料從未由SQL伺服器處理（包括離線處理），則無需保護應用程式免受SQL注入攻擊。無謂地啟用規則不僅會增加CPU利用率，還可能影響延遲或產生誤報。

新增快取層

• 減少不必要的檢查：除了將內容分離以避免對靜態內容進行ModSecurity檢查外，還可以在執行NGINX與ModSecurity的伺服器前新增快取層。這大大減少了為了確保靜態內容不被ModSecurity處理而分割流量的必要性。ModSecurity檢查在NGINX快取引擎之前執行，而快取是一種內容生成形式，因此它在NGINX的請求處理流程中非常靠後。這意味著無法在虛擬伺服器上啟用快取，因為請求檢查會在快取檢查之前發生。

關注最新的安全漏洞

• 保持安全意識：ModSecurity是保護Web應用程式的強大工具，可以阻止廣泛的攻擊，但它不能取代對安全漏洞的主動監控。有許多優秀的線上資源提供已知漏洞的資料函式庫，如NIST。

檔案修訂歷史