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數據並基於錯誤的標準從新調整異常分
• 數。

缺點

• 對於普通用戶來講更爲複雜。
• 日誌監控腳本可能須要更新才能正確分析