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数据并基于错误的标准从新调整异常分
• 数。

缺点

• 对于普通用户来讲更为复杂。
• 日志监控脚本可能须要更新才能正确分析