modSecurity規則學習（六）——檢測模式
傳統檢測模式-自主規則
傳統檢測模式所有規則都是“閉環”的模式。就像HTTP本身一樣，單獨的規則是無狀態的。這意味著規則之間不共享信息，每個規則都沒有關於任何先前規則匹配的信息。它僅使用其當前的單個規則邏輯進行檢測。在此模式下，如果規則觸發，它將執行當前規則中指定的任 何中斷/記錄日誌操作。
設置方法：
修改Crs-setup.conf
# Example: Self-contained mode, return error 403 on blocking # - In this configuration the default disruptive action becomes ‘deny‘. After a # rule triggers, it will stop processing the request and return an error 403. # - You can also use a different error status, such as 404, 406, et cetera. # - In Apache, you can use ErrorDocument to show a friendly error page or # perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html # SecDefaultAction "phase:1,log,auditlog,deny,status:403" SecDefaultAction "phase:2,log,auditlog,deny,status:403"
該設置為上面提到的CRS傳統檢測模式。當CRS規則匹配時，它將被拒絕，然後告警數據將記錄到Apache error_log文件和ModSecurity審計日誌。以下是SQL註入
攻擊的一個示例error_log消息：
[Tue Nov 16 16:02:38 2017] [error] [client ::1] ModSecurity: Access denied with
code 403 (phase 2). Pattern match "\\bselect\\b.{0,40}\\buser\\b" at ARGS:foo.
[file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
[line "67"] [id "959514"] [rev "2.0.9"] [msg "Blind SQL Injection Attack"]
[data "select * from user"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"]
[tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"]
[tag "PCI/6.5.2"] [hostname "localhost"] [uri "/vulnerable_app.php"]
[unique_id "TOLxbsCoC2oAABvWGW4AAAAA"]
這種消息格式看起來與傳統的規則日誌格式相同。
傳統檢測模式的優缺點：
優點
- 新用戶容易理解
- 更好的性能（更低的延遲/資源），因為直接阻斷了，停止進一步處理。
缺點
- 從規則管理的角度來看，這不是最優的（處理誤報/例外）
- 編輯規則的復雜正則表達式很困難
- 典型的方法是將現有規則復制/粘貼到本地自定義規則文件中，編輯邏輯然後禁用現有的CRS規則
- 最終結果是，當新的CRS版本發布時，大量定制的規則集未被更新
從安全角度來看並非最佳
- 並非每個站點都具有相同的風險容忍度
- 較低嚴重程度的警報大部分被忽略
- 單個低嚴重性警報可能不用阻止，多個低嚴重性警報在一起了需要阻止
異常評分檢測模式 - 協作規則概念
這種改進的檢測模式的核心理念是實施協作檢測和延遲阻塞。這意味著我們通過將檢查/檢測與阻塞功能分離來改變規則邏輯。可以運行單個規則，以便檢測仍
然存在，但是，不是在此時應用任何破壞性操作，而是會進行事務性異常評分記錄。另外，每個規則還將存儲關於每個規則匹配的元數據（例如規則ID，攻擊類
別，匹配位置和匹配數據）在唯一TX變量內。
設置方法：
修改Crs-setup.conf
SecDefaultAction "phase:1,pass,log" SecDefaultAction "phase:2,pass,log"
在這種新模式下，每個匹配規則不會阻塞，而是會使用ModSecurity的setvar動作增加異常分數。以下是SQL註入CRS規則的一個示例，該規則使用setvar動作來
增加整體異常評分和SQL註入子類別評分：{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|
XML:/* "@detectSQLi" "msg:‘SQL Injection Attack Detected via libinjection‘,id:942100,severity:‘CRITICAL‘,rev:‘1‘,ver:‘OWASP_CRS/3.0.0‘,maturity:‘1‘,accuracy:‘8‘,phase:request,block,multiMatch,t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:removeComments,capture,logdata:‘Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}‘,tag:‘application-multi‘,tag:‘language-multi‘,tag:‘platform-multi‘,tag:‘attack-sqli‘,tag:‘OWASP_CRS/WEB_ATTACK/SQL_INJECTION‘,tag:‘WASCTC/WASC-19‘,tag:‘OWASP_TOP_10/A1‘,tag:‘OWASP_AppSensor/CIE1‘,tag:‘PCI/6.5.2‘,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:‘tx.msg=%{rule.msg}‘,setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{matched_var}"
異常評分嚴重性等級
每個規則都具有指定的嚴重性級別。我們已經更新了規則，以允許異常評分收集增量使用宏擴展。這裏是一個例子：
例如上面那條規則的setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},
這允許用戶從crs-setup.conf文件中設置自己的異常評分值，並通過使用宏擴展將這些值傳播出來供規則使用。
# -- [[ Anomaly Mode Severity Levels ]] ---------------------------------------- # # Each rule in the CRS has an associated severity level. # These are the default scoring points for each severity level. # These settings will be used to increment the anomaly score if a rule matches. # You may adjust these points to your liking, but this is usually not needed. # # - CRITICAL severity: Anomaly Score of 5. # Mostly generated by the application attack rules (93x and 94x files). # - ERROR severity: Anomaly Score of 4. # Generated mostly from outbound leakage rules (95x files). # - WARNING severity: Anomaly Score of 3. # Generated mostly by malicious client rules (91x files). # - NOTICE severity: Anomaly Score of 2. # Generated mostly by the protocol rules (92x files). # # In anomaly mode, these scores are cumulative. # So it‘s possible for a request to hit multiple rules. # # (Note: In this file, we use ‘phase:1‘ to set CRS configuration variables. # In general, ‘phase:request‘ is used. However, we want to make absolutely sure # that all configuration variables are set before the CRS rules are processed.) # #SecAction # "id:900100,# phase:1,# nolog,# pass,# t:none,# setvar:tx.critical_anomaly_score=5,# setvar:tx.error_anomaly_score=4,# setvar:tx.warning_anomaly_score=3,# setvar:tx.notice_anomaly_score=2"
2.8以上版本的是在Crs-setup.conf中配置，看著比較亂了！！！
這種配置表明，嚴格等級為“critical”的每個CRS規則都會將每次規則匹配的事務異常分數提高5分。當我們有規則匹配時，您可以從modsec_debug.log文件中
看到常評分是如何加分的：
executing operator "rx" with param "\\bselect\\b.{0,40}\\buser\\b" against ARGS:foo.
Target value: "\xe2\x80\x98 union select * from user &#"
Added regex subexpression to TX.0: select * from user
Operator completed in 14 usec.
Ctl: Set auditLogParts to ABIFHZE.
Setting variable: tx.msg=%{rule.msg}
Resolved macro %{rule.msg} to: Blind SQL Injection Attack
Set variable "tx.msg" to "Blind SQL Injection Attack".
Setting variable: tx.sql_injection_score=+%{tx.critical_anomaly_score}
Recorded original collection variable: tx.sql_injection_score = "0"
Resolved macro %{tx.critical_anomaly_score} to: 5
Relative change: sql_injection_score=0+5
Set variable "tx.sql_injection_score" to "5".
Setting variable: tx.anomaly_score=+%{tx.critical_anomaly_score}
Recorded original collection variable: tx.anomaly_score = "0"
Resolved macro %{tx.critical_anomaly_score} to: 5
Relative change: anomaly_score=0+5
Set variable "tx.anomaly_score" to "5".
Setting variable: tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}
Resolved macro %{rule.id} to: 959514
Resolved macro %{matched_var_name} to: ARGS:foo
Resolved macro %{tx.0} to: select * from user
Set variable "tx.959514-WEB_ATTACK/SQL_INJECTION-ARGS:foo" to "select * from user".
Resolved macro %{TX.0} to: select * from user
Warning. Pattern match "\bselect\b.{0,40}\buser\b" at ARGS:foo. [file
"/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "67"] [id "959514"] [rev "2.0.9"]
[msg "Blind SQL Injection Attack"] [data "select * from user"] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"]
[tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
異常評分閾值等級（阻塞）
現在有了進行異常評分，下一步就是設置我們的閾值。這是如果當前交易分數高於此分數值，它將被拒絕。配置在Crs-setup.conf中
# Initialize anomaly scoring variables.
# All _score variables start at 0, and are incremented by the various rules
# upon detection of a possible attack.
# sql_error_match is used for shortcutting rules for performance reasons.
SecAction \
"id:901200,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.anomaly_score=0,\
setvar:tx.sql_injection_score=0,\
setvar:tx.xss_score=0,\
setvar:tx.rfi_score=0,\
setvar:tx.lfi_score=0,\
setvar:tx.rce_score=0,\
setvar:tx.php_injection_score=0,\
setvar:tx.http_violation_score=0,\
setvar:tx.session_fixation_score=0,\
setvar:tx.inbound_anomaly_score=0,\
setvar:tx.outbound_anomaly_score=0,\
setvar:tx.sql_error_match=0"
通過這些當前的默認設置，異常評分模式將從阻塞的角度看起來與傳統模式類似。由於所有關鍵等級規則都會將異常分數提高5分，這意味著即使是1個關鍵等級
規則匹配也會導致阻塞。如果您想調整異常分數以便阻止非惡意客戶（誤報）的可能性較低，則可以將tx.inbound_anomaly_score_level設置提高到10或15等更
高的值。這說明要阻止該請求需要評分為10或15以上，這種方法的另一個優點是可以聚合多個較低嚴重性規則匹配，然後決定阻止。
啟用/禁用阻止
REQUEST-949-BLOCKING-EVALUATION.conf 中的規則，用於評估請求階段結束時的異常分數並阻止請求：
#
# -=[ Anomaly Mode: Overall Transaction Anomaly Score ]=-
#
SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
"msg:‘Inbound Anomaly Score Exceeded (Total Score: %{TX.ANOMALY_SCORE})‘,\
severity:CRITICAL,\
phase:request,\
id:949110,\
t:none,\
deny,\
log,\
tag:‘application-multi‘,\
tag:‘language-multi‘,\
tag:‘platform-multi‘,\
tag:‘attack-generic‘,\
setvar:tx.inbound_tx_msg=%{tx.msg},\
setvar:tx.inbound_anomaly_score=%{tx.anomaly_score}"
當然也可以用特定分數來阻止，比如sql註入等。
異常評分檢測模式的優缺點
優點
- 對阻止的信心增加 - 由於更多檢測規則導致異常評分，評分越高，您越有信心阻止惡意事務。
- 允許用戶設置適合他們的閾值 - 不同的網站可能有不同的阻止閾值。
- 允許多個低嚴重性事件觸發警報，同時抑制單個警報。
- 一個相關事件有助於警報管理。
- 可以通過增加整體異常評分閾值或通過向本地自定義例外文件添加規則來處理例外情況，其中可以檢查之前規則匹配的TX數據並基於錯誤的標準重新調整異常分
- 數。
缺點
- 對於普通用戶來說更為復雜。
- 日誌監控腳本可能需要更新才能正確分析
modSecurity規則學習（六）——檢測模式