ModSecurity與Project Honeypot整合強化網頁安全

– 13 分鐘閱讀

隨著惡意攻擊日益猖獗，網站安全防護變得至關重要。本文將探討如何結合ModSecurity和Project Honeypot，建構更完善的網站安全防禦機制。Project Honeypot透過佈署蜜罐，收集惡意IP地址資料，而ModSecurity則作為WAF，根據IP評價阻擋惡意流量。此方案能有效提升網站的安全性，降低被攻擊的風險。我們將深入探討NGINX的組態細節，以及如何在ModSecurity中啟用IP評價檢查，並提供生產環境佈署的最佳實踐，包含日誌管理、效能調校和速率限制等關鍵導向，協助您建構更穩固的網站安全防護體系。

使用ModSecurity與Project Honeypot提升網頁應用安全

在當前網路環境中，惡意機器人和掃描器的攻擊日益頻繁，網站管理員需要採取有效的措施來保護其網站。ModSecurity是一款強大的開源Web應用防火牆（WAF），可與Project Honeypot結合使用，以增強網站的安全性。本文將詳細介紹如何使用ModSecurity 3.0與NGINX來啟用Project Honeypot，從而提升網站的安全性。

瞭解Project Honeypot

Project Honeypot是一個免費的服務，它透過收集和分析惡意IP地址的資料，幫助網站管理員識別和阻止惡意流量。它的運作原理是透過在網站上設定一個隱藏的連結（稱為“蜜罐”），這個連結對正常使用者不可見，但會被惡意機器人和掃描器捕捉。當這些惡意實體存取這個連結時，它們的IP地址就會被記錄並新增到Project Honeypot的資料函式庫中。

設定Project Honeypot

要開始使用Project Honeypot，需要完成以下步驟：

  1. 註冊Project Honeypot帳戶：存取Project Honeypot網站並註冊一個免費帳戶。
  2. 設定蜜罐指令碼：Project Honeypot提供了多種程式語言的蜜罐指令碼，如PHP、Python等。選擇適合的指令碼下載並佈署到您的網站上。
  3. 組態NGINX以執行蜜罐指令碼：以下是一個使用PHP-FPM執行PHP指令碼的NGINX組態範例：
server {
    listen 80;
    server_name example.com;
    
    location ~ \.php$ {
        modsecurity off;
        root /code;
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass localhost:9000;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

請注意，需要將root /code;中的/code替換為您存放蜜罐指令碼的實際目錄。

  1. 啟動蜜罐：透過瀏覽器存取蜜罐指令碼並點選啟用連結，以啟動蜜罐。

將蜜罐連結新增到所有頁面

為了捕捉惡意機器人和掃描器，需要在網站的每個頁面上新增一個指向蜜罐指令碼的隱藏連結。可以使用NGINX的sub_filter指令來實作這一點：

location / {
    proxy_set_header Host $host;
    sub_filter '</html>' '<a href="http://example.com/weddingobject.php"><!-- hightest --></a></html>';
    sub_filter_once on;
}

這段組態會在每個HTML頁面的底部新增一個隱藏的連結，指向weddingobject.php（您的蜜罐指令碼）。

在ModSecurity中啟用IP評價檢查

  1. 取得Project Honeypot的http:BL存取金鑰：在Project Honeypot網站上申請一個http:BL存取金鑰。
  2. 組態ModSecurity：編輯ModSecurity的組態檔案，找到SecHttpBlKey區塊，並替換my_api_key為您的http:BL存取金鑰。同時，根據需要組態相關的規則，例如：
SecHttpBlKey your_api_key_here
SecAction "id:900500,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.block_search_ip=0,\
setvar:tx.block_suspicious_ip=1,\
setvar:tx.block_harvester_ip=1,\
setvar:tx.block_spammer_ip=1"

重新載入NGINX組態以使更改生效。

驗證組態

為了測試組態是否正確，可以使用一個已知的惡意IP地址（可從Project Honeypot取得）進行測試。以下是一個範例測試規則：

SecRule REMOTE_ADDR "@rbl httpbl.your_api_key_here.your_project_honeypot_domain" \
    "id:1001,phase:1,deny,status:403,msg:'RBL Match for SPAM Source',log,auditlog"

重新載入組態後，使用curl命令測試：

curl -I http://example.com/?ip=203.0.113.20

如果組態正確，請求應該會被阻止，並傳回403 Forbidden狀態碼。

ModSecurity的記錄功能

ModSecurity提供了兩種型別的日誌：稽核日誌和除錯日誌。稽核日誌記錄了被阻止的交易詳情，而除錯日誌則提供了ModSecurity操作的詳細資訊。這些日誌對於故障排除和了解攻擊模式至關重要。

稽核日誌

稽核日誌記錄了所有被ModSecurity阻止的交易，包括請求和回應的詳細資訊。這些資訊可以幫助管理員瞭解攻擊的性質和來源。

除錯日誌

除錯日誌提供了ModSecurity操作的詳細資訊，包括規則的匹配過程和變數的變化。這些資訊對於除錯和最佳化ModSecurity組態非常有用。

圖表：ModSecurity與Project Honeypot工作流程

  flowchart TD
    A[開始] --> B[接收HTTP請求]
    B --> C{檢查IP評價}
    C -->|評價良好| D[繼續處理請求]
    C -->|評價不良| E[阻止請求]
    E --> F[記錄到稽核日誌]
    D --> G[傳回回應]

圖表翻譯：

此圖表展示了ModSecurity與Project Honeypot結合的工作流程。當接收到HTTP請求時，系統會檢查請求來源IP的評價。如果IP評價良好，請求會被繼續處理；如果評價不良，請求會被阻止，並記錄到稽核日誌中。這個流程有效地提升了網站的安全性。

ModSecurity 3.0 與 NGINX：日誌管理與生產環境佈署

日誌管理的重要性

在 ModSecurity 中，日誌管理是一項至關重要的功能。正確的組態日誌管理可以幫助我們監控和除錯系統，及時發現潛在的安全威脅。

稽核日誌（Audit Log）詳解

稽核日誌是 ModSecurity 的主要日誌形式，記錄了所有被觸發的警告或錯誤的交易，以及導致5xx 和4xx 回應的交易（除404 外）。在 Ubuntu 系統中，稽核日誌通常位於 /var/log/modsec_audit.log。

稽核日誌的結構

稽核日誌被劃分為多個部分，以便於查詢和分析。以下是各個部分的主要內容：

部分描述
A稽核日誌頭部（必備）
B請求頭部
C請求主體
D保留
E回應主體
F回應頭部
G保留
H稽核日誌尾部，包含額外資料
I緊湊請求主體替代（排除檔案）
J上傳檔案資訊
K匹配的交易規則列表
Z最終邊界（必備）

稽核日誌範例分析

以下是一個典型的稽核日誌條目範例：

A--
[04/Oct/2017:21:45:15 +0000]150715351558.929952141.212.122.1664384
141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
Host:54.183.57.254
User-Agent: Mozilla/5.0 zgrab/0.x
Accept-Encoding: gzip
---ICmPEb5c---D--
---ICmPEb5c---F--
HTTP/1.1 200
Server: nginx/1.13.4
Date: Wed,04 Oct 2017 21:45:15 GMT
Content-Type: text/html
Connection: keep-alive
---ICmPEb5c---H--
ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[\d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `54.183.57.254' ) [file "/root/owasp_modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [rev "2"] [msg "Host header is a numeric IP address"] [data "54.183.57.254"] [severity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [ref "o0,13v21,13"]
---ICmPEb5c---I--
---ICmPEb5c---J--
---ICmPEb5c---Z--

圖表：稽核日誌結構示意圖

  flowchart TD
    A[稽核日誌開始] --> B[請求頭部]
    B --> C[請求主體]
    C --> D[保留部分]
    D --> E[回應主體]
    E --> F[回應頭部]
    F --> G[保留部分]
    G --> H[稽核日誌尾部]
    H --> I[緊湊請求主體]
    I --> J[上傳檔案資訊]
    J --> K[匹配規則列表]
    K --> Z[稽核日誌結束]

圖表翻譯：

此圖示展示了稽核日誌的結構流程，從開始到結束的每個部分都有詳細的標示。透過這個流程圖，可以清楚地瞭解稽核日誌的組成部分及其順序。

稽核日誌組態

要組態稽核日誌，需要調整以下三個指令：

  1. SecAuditEngine：控制是否啟用稽核日誌。可選值包括 Off、On 和 RelevantOnly。
  • Off：停用稽核日誌。
  • On：記錄所有交易。
  • RelevantOnly：僅記錄觸發警告/錯誤或符合 SecAuditLogRelevantStatus 狀態碼的交易。
  1. SecAuditLogRelevantStatus：當 SecAuditEngine 設定為 RelevantOnly 時，此指令控制哪些 HTTP 狀狀碼碼。

spoiler: true

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ

除錯日誌（Debug Log）詳解

除錯日誌提供了 ModSecurity 展望的詳細資訊，是故障排除和了解 ModSecurity 行為的重要工具。

除錯日誌範例分析

[4] (Rule:1234) Executing operator "Contains" with param "test" against ARGS:testparam.
[9] Target value: "test" (Variable: ARGS:testparam)
[9] Matched vars updated.
[4] Running [independent] (non-disruptive) action: log
[9] Saving transaction to logs
[4] Rule returned 1.
[9] (SecDefaultAction) Running action: log
[9] Saving transaction to logs
[9] (SecDefaultAction) Running action: auditlog
[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)
[4] Running (non-disruptive) action: auditlog
[4] Running (disruptive) action: deny

圖表：除錯日誌處理流程

  sequenceDiagram
    participant ModSecurity as "ModSecurity"
    participant RuleEngine as "Rule Engine"
    participant DebugLog as "Debug Log"

    ModSecurity->>RuleEngine: 執行規則檢查
    RuleEngine->>DebugLog: 記錄規則執行詳情
    DebugLog->>DebugLog: 儲存交易記錄
    ModSecurity->>DebugLog: 記錄除錯資訊

圖表翻譯：

此圖示展示了 ModSecurity 在執行規則檢查時與除錯日誌的互動過程。透過這個序列圖，可以清楚地瞭解 ModSecurity 如何將規則執行的詳細資訊記錄到除錯日誌中。

除錯日誌組態

預設情況下，除錯日誌是停用的，因為它可能對效能產生負面影響。要啟用除錯日誌，需要在 /etc/nginx/modsec/main.conf 中進行以下組態：

SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 9
  • SecDebugLog：指定除錯日誌檔案的路徑。
  • SecDebugLogLevel：控制記錄的詳細程度，範圍從0 到9，其中9 表示最詳細的記錄。

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

調整 ModSecurity 組態以最佳化效能

在生產環境中佈署 ModSecurity 時，必須進行一系列組態調整以確保系統的最佳效能。首先，確保稽核日誌（audit log）已啟用，這有助於監控和除錯潛在的安全問題。接著，適當地調整異常閾值（anomaly threshold），例如將其設定為1000，以減少誤報的可能性。同時，密切監控稽核日誌中的誤報情況，並根據實際執行情況適時調整閾值。

組態範例：調整異常閾值

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

圖表：ModSecurity 處理流程

  flowchart TD
    A[開始處理] --> B{檢查資料}
    B -->|資料有效| C[處理資料]
    B -->|資料無效| D[回報錯誤]
    C --> E[完成處理]
    D --> E

圖表翻譯：

此圖示展示了 ModSecurity 的基本處理流程。首先，系統開始處理請求，接著進行資料有效性檢查。若資料有效，系統會進入資料處理階段；若資料無效，則轉向錯誤回報階段。最後，無論資料處理成功與否，流程都會到達完成處理階段。

停用稽核日誌以提升效能

在生產環境中，建議停用稽核日誌以提升 ModSecurity 的效能。稽核日誌會對效能產生負面影響，並且可能導致日誌檔案快速增長，佔用大量磁碟空間。要停用稽核日誌，請將 SecAuditEngine 指令的值設為 off。

組態範例：停用稽核日誌

SecAuditEngine off

最佳化 NGINX 錯誤日誌

適當組態 NGINX 的錯誤日誌有助於及時發現和解決問題。建議將錯誤日誌級別設定為 error 或 warn 以平衡資訊量和效能。

組態範例：NGINX 錯誤日誌

error_log /var/log/nginx/error.log warn;

實施速率限制

為了降低 DDoS 攻擊的風險，建議在 NGINX 中實施速率限制。以下是一個範例組態：

組態範例：NGINX 速率限制

http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=5r/s;

    server {
        listen 80;
        location / {
            limit_req zone=req_limit burst=10 nodelay;
            proxy_pass http://backend;
        }
    }
}

圖表：速率限制流程

  flowchart TD
    A[接收請求] --> B{檢查請求頻率}
    B -->|未超限| C[處理請求]
    B -->|超限| D[傳回 503 錯誤]
    C --> E[繼續處理]
    D --> F[記錄錯誤日誌]

圖表翻譯：

此圖示展示了 NGINX 速率限制的處理流程。當接收到請求時，系統會檢查請求頻率是否超出限制。如果未超出限制，請求會被正常處理；如果超出限制，系統會傳回 503 錯誤，並記錄錯誤日誌。

ModSecurity與NGINX整合的最佳實踐

錯誤日誌分析與安全威脅檢測

NGINX的錯誤日誌對於監控被ModSecurity阻擋的交易至關重要。這些日誌記錄了所有被攔截的請求，確保重要的安全資訊不會遺失。透過定期分析錯誤日誌，管理員可以及時發現並處理潛在的安全威脅，從而提升系統的安全性。

日誌範例解析：ModSecurity阻擋交易

2019/12/19 14:40:58 [warn] 1205#1205: *12 [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 1). 
Matched "Operator 'Contains' with parameter 'test' against variable 'ARGS:testparam' (Value: 'thisisatest' ) 
[file "/etc/nginx/modsec/..."] 
[severity "0"] 
[ver ""] 
[maturity "0"] 
[accuracy "0"] 
[hostname "127.0.0.1"] 
[uri "/foo"] 
[unique_id "151369445814.452751"] 
[ref "o7,4v19,11"], 
client: 127.0.0.1, 
server: , 
request: "GET /foo?testparam=thisisatest HTTP/1.1", 
host: "localhost"

此日誌範例顯示了一次被ModSecurity阻擋的交易。日誌中包含了請求的詳細資訊，如客戶端IP、請求方法、URI、主機名等。透過分析這些資訊，管理員可以瞭解攻擊的來源和性質，從而採取相應的安全措施。

日誌分析重點

  1. 請求詳情：包含客戶端IP、請求方法、URI等資訊。
  2. 阻擋原因：顯示觸發的ModSecurity規則及引數。
  3. 嚴重程度：記錄了規則的嚴重程度和其他屬性。

靜態內容處理最佳化

對於靜態內容（如圖片、CSS檔案等），無需執行ModSecurity規則檢查，以避免不必要的效能開銷。透過使用NGINX的location指令，可以將靜態資源和動態資源分開處理，從而提高系統的整體效能。

組態範例：分離靜態和動態資源

server {
    listen 80;
    location / {
        modsecurity on;
        proxy_set_header Host $host;
        # 處理動態請求
    }
    location ~ \.(gif|jpg|png|jpeg|svg)$ {
        root /data/images;
        # 直接提供靜態資源，無需經過ModSecurity檢查
    }
}

在這個組態範例中，NGINX根據請求的URI將靜態資源和動態資源分開處理。靜態資源直接由NGINX提供，而動態請求則經過ModSecurity檢查，以確保安全性。

利用NGINX進行DDoS防護和速率限制

雖然ModSecurity動態模組目前不支援內建的速率限制功能，但NGINX本身提供了強大的速率限制和DDoS防護功能。透過組態limit_req_zone和limit_req指令，可以有效限制單一IP的請求速率，防止惡意攻擊。

組態範例：速率限制

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
    server {
        listen 80;
        location / {
            limit_req zone=mylimit burst=20 nodelay;
            modsecurity on;
            proxy_set_header Host $host;
        }
    }
}

此組態範例定義了一個速率限制區域mylimit，限制每秒10個請求，並允許短暫的流量突增（burst）。透過這種方式，可以有效防止DDoS攻擊，同時確保合法使用者的正常存取。

生產環境準備要點

  1. 監控CPU利用率：根據CPU利用率情況，考慮擴充（增加核心數或增加NGINX工作程式）或擴充套件（佈署更多NGINX伺服器並進行負載平衡）。
  2. 謹慎選擇ModSecurity規則：避免啟用不必要的規則，以減少CPU負擔和誤報率。
  3. 新增快取層：在NGINX伺服器前新增快取層，以減少對靜態內容的處理需求，提升系統效能。
  4. 關注最新的安全漏洞：定期檢查已知的安全漏洞資料函式庫（如NIST），保持對最新安全威脅的關注，並及時更新防護措施。

隨著Web安全威脅的不斷演變，ModSecurity和NGINX的整合將繼續發揮重要作用。未來，可以期待更多針對新型攻擊手段的防護措施，以及更高效的效能最佳化方案。例如，更智慧的速率限制機制、更精細的規則自訂功能等，都將進一步提升系統的安全性和效能。

程式碼範例：ModSecurity規則自訂

以下是一個使用Python自訂ModSecurity規則的範例：

def customize_modsecurity_rules(rules_config):
    # 自訂ModSecurity規則
    customized_rules = []
    for rule in rules_config:
        # 根據實際需求調整規則
        customized_rule = adjust_rule(rule)
        customized_rules.append(customized_rule)
    return customized_rules

def adjust_rule(rule):
    # 根據特定條件調整規則
    if rule['action'] == 'deny':
        rule['action'] = 'log'
    return rule

# 使用範例
rules_config = [
    {'id': 1, 'action': 'deny', 'pattern': 'malicious_pattern'},
    {'id': 2, 'action': 'allow', 'pattern': 'benign_pattern'}
]
customized_rules = customize_modsecurity_rules(rules_config)
print(customized_rules)

程式碼解析

  1. customize_modsecurity_rules函式：遍歷輸入的規則組態，根據需求調整每條規則。
  2. adjust_rule函式：根據特定條件調整單條規則，例如將deny動作改為log。
  3. 使用範例：展示如何呼叫customize_modsecurity_rules函式並列印自訂後的規則。

圖表：ModSecurity規則自訂流程

  flowchart TD
    A[開始自訂規則] --> B{檢查規則組態}
    B -->|規則有效| C[調整規則]
    B -->|規則無效| D[回報錯誤]
    C --> E[完成自訂]
    D --> E

圖表解析

  1. 開始自訂規則：流程的起始點。
  2. 檢查規則組態：判斷規則的有效性。
  3. 調整規則：對有效的規則進行自訂調整。
  4. 回報錯誤：對無效的規則回報錯誤。
  5. 完成自訂：流程的結束點，無論規則自訂成功與否。

透過上述最佳實踐和範例，可以有效地整合ModSecurity與NGINX，提升Web應用程式的安全性和效能。未來，隨著技術的進步，這種整合將繼續演進，提供更強大的安全防護和更最佳化的效能表現。

在日益嚴峻的網路安全威脅下，ModSecurity 與 Project Honeypot 的結合，為網站管理員提供了強大的防禦能力。透過蜜罐技術誘捕惡意行為者，並結合 ModSecurity 的 WAF 功能，可以有效識別、阻擋並記錄惡意流量。深入分析這項整合方案，可以發現它不僅提升了網站的安全性，更減輕了管理員的負擔。然而，技術限制仍需關注，例如誤報的可能性以及對於新型攻擊的適應性。技術團隊應著重於調整規則的精確度和持續更新規則函式庫，才能最大限度地發揮這項技術的潛力。玄貓認為，此技術組合在防禦已知攻擊方面表現出色，值得重視安全性的網站採用。隨著攻擊手段的不斷演變，預見未來 ModSecurity 和 Project Honeypot 將持續發展，融入更先進的機器學習和行為分析技術，以應對更複雜的網路威脅。

玄貓

玄貓

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