crs-setup.cnf
#SecDefaultAction指令后的规则都继承这一设置，除非为某条规则指定了一个特定的动作，或者指定了新的SecDefaultAction。特别注意到，未经处理的disruptive动作是不允许的，但是在SecDefautlAction中一不小心就会继承了使用disruptive动作。
#SecDefaultAction必须指定一个disruptive动作和处理阶段，而且不能包含元数据动作
SecDefaultAction "phase:1,log,auditlog,pass" SecDefaultAction "phase:2,log,auditlog,pass"
SecAction
"id:900990,
phase:1,
nolog,
pass,
t:none,
setvar:tx.crs_setup_version=302"
ModSecurity 2.x允许把规则置于下述五个阶段之一：
请求头(REQUEST_HEADERS) 阶段
这个阶段的规则会在apache完成请求头的读取后立即被执行（post-read-request阶段），这时，还没有读取请求体，意味着不是所有的参数都可用。如果你必须让规则尽早运行，应把规则放在这个阶段（在apache使用这个请求做某些事前），在请求体被读取前做些事情，从而决定是否缓存这个请求体，或者决定你将希望这个请求体如何被处理（如是否以XML格式解析或不解析）。
请求体(REQUEST_BODY) 阶段
这是通用输入分析阶段，大部分传统的应用规则不在这儿，这个阶段你肯定能收到参数（只有读取过请求体后），在请求体阶段，ModSecurity支持三种编码类型。
l application/x-www-form-urlencoded - used to transfer form data
l multipart/form-data - used for file transfers
l text/xml - used for passing XML data
大部分WEB应用还没有使用其它的编码方法。
响应头(RESPONSE_HEADERS) 阶段
发生在响应头被发送到客户端之前，如果你想观察响应发生前就在这儿运行，如果你想使用响应头来决定你是否想缓存响应体也行。注意一些响应状态码（如404）在请求环的早期就被apache管理着，我也无法触发预期。加上apache在后面的勾子上双增加了一些响应头（如日期、服务器和连接信息等），这些我们无法触发和审查。在代理配置模式下或使用phase:5(logging)工作的较好。
响应体(RESPONSE_BODY) 阶段
这是通用输出分析阶段，这里你能运行规则截断响应体（当然提供缓存）。这个阶段你想检查输出的HTML信息公布、错误消息和失败的验证文字。
记录(LOGGING) 阶段
在日志发生前运行的一个阶段，放在这个阶段的规则只能影响日志记录器如何执行，这个阶段可以检测apache记录的错误消息，在这个阶段你不能拒绝或阻断连接，因为太迟了，这个阶段也允许检测其它的响应头，如那在phase:3或者phase:4阶段中不可用的。注意在这个阶段，你应当小心不要继承破坏性的动作到规则中，这样的情况在ModSecurity2.5.0及其以后的版本中被当作配置错误。
图-1是标准的apache请求流程，5个ModSecurity处理阶段显示其中。因此，在rule的部分即可指定你要处理的哪一部份进行处理。
图-1