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: "xe2x80x98 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 "select.{0,40}user" 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数据并基于错误的标准重新调整异常分
数。

缺点

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