标签：lock most 定义 orm completed protocol 配置 通过 延迟
传统检测模式所有规则都是“闭环”的模式。就像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"]
这种消息格式看起来与传统的规则日志格式相同。
传统检测模式的优缺点：
优点
缺点
从安全角度来看并非最佳
这种改进的检测模式的核心理念是实施协作检测和延迟阻塞。这意味着我们通过将检查/检测与阻塞功能分离来改变规则逻辑。可以运行单个规则，以便检测仍
然存在，但是，不是在此时应用任何破坏性操作，而是会进行事务性异常评分记录。另外，每个规则还将存储关于每个规则匹配的元数据（例如规则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注入等。
优点
缺点
标签：lock most 定义 orm completed protocol 配置 通过 延迟
原文地址：https://www.cnblogs.com/wuweidong/p/8876266.html
