一，每个事务的生命周期:
如图:
每个事务在modsecurity需要经历5个阶段，在每个阶段可能需要解析等操作，
然后调用相应阶段的规则进行匹配，对应规则中的phase
阶段一：request headers请求头，这是modsecurity最先接触到的数据，
需要验证请求头相关的规则，并根据请求头来判断如何解析request body
阶段二：request body请求体，此阶段需要根据请求头正确解析body数据，并验证request body相关的规则
阶段三：response headers响应头，
在获取到响应头之后，验证response header相关的规则
阶段四：response body响应体，
正确解析响应体数据之后，验证response body相关的规则
阶段五：logging日志记录，日志记录阶段是一定存在的，
用于记录事务信息，包括命中规则信息，处理方式等。
二，两种检测模式:
检测模式的配置在crs-setup.conf中，具体通过SecDefaultAction来进行配置
1,Self-contained mode：自主机制
例子：
# SecDefaultAction "phase:1,log,auditlog,deny,status:403"
# SecDefaultAction "phase:2,log,auditlog,deny,status:403" 说明：
这种机制是非常传统的简单的方式，只要命中其中一条规则，就直接进行拦截，返回403，
也可以设置其他动作，
各规则之间没有任何联系，当然可以通过规则链的写法进行弥补规则之间的联系，
优点: 很明显，学习和使用难度很小，理解简单，并且在性能上很优秀，命中规则直接拦截，不需要后续的处理。
缺点: 对于目前庞大的规则体系里，使用这种模式肯定是要删除掉大量规则的，
比如: 对于一些本来只需要警告或者提醒的规则，使用自主模式，会造成误报，并且很多规则没法使用
默认未启用
2, Anomaly Scoring mode：评分机制，默认启用，是默认使用的检测机制
例子：
SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"说明：
优点: 这种评分机制作为默认机制，是crs体系优点之一，
顾名思义，评分机制就是给每个规则赋予一个权重分数，当命中规则的权重分数增加到设定的拦截阈值时，进行拦截。
使各条规则之间通过变量的方式进行联系，从而计算总体权重分。
对于危险性或者说攻击性不足的规则给予小权重，
对于确认很大可能为攻击的规则给与大权重，
然后可以根据业务情况来设定拦截阈值，从而在误报和漏报之间寻找平衡，优点十分明显。
缺点: 增加了使用者的学习难度，加大了性能的消耗，
在确认拦截之前需要去匹配大量的规则，
并且需要设置变量并进行变量的计算，对性能是一种考验。
三，全局级别分类:
1, 所有规则分为四类，分别为
critical_anomaly_score/error_anomaly_score/
warning_anomaly_score/notice_anomaly_score，
对应严重，错误，警告，提醒四类，
权重由高到低，
默认其权重分数在crs-setup.conf中配置，
分数对应为5/4/3/2
#SecAction \
# "id:900100,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0-dev',\
# 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, 在阈值判断中，默认使用949中的anomaly_score作为总分和阈值进行比较，
达到阈值就进行拦截，
其他权重分的计算目前只是在日志中记录，利于后续分析与调试
