ModSecurity安装了，不懂原理和规则？这篇帮你搞定
之前的文章中介绍了Nginx中添加模块ModSecurity，默认ModSecurity
只有一个配置文件modsecrurity.conf，ModSecurity就是通过该文件进行配置，包括安全规则引擎以及安全规则配置，下面是该文件内容详解：
SecRuleEngine DetectionOnly|On|Off
#SecRuleEngine是接受来自ModSecurity-CRS目录下的所有规则的安全规则引擎。因此，我们可以根据需求设置不同的规则。要设置不同的规则有以下几种。
#SecRuleEngine On：将在服务器上激活ModSecurity防火墙。它会检测并阻止该服务器上的任何恶意攻击。
#SecRuleEngine Detection Only：如果这个规则是在whitelist.conf文件中设置的，它只会检测到所有的攻击，并根据攻击产生错误，但它不会在服务器上阻止任何东西。
#SecRuleEngine Off:：在服务器上停用ModSecurity的防火墙。
SecRequestBodyAccess On
#SecRequestBodyAccess是否允许ModeSecurity访问request body(post请求内容)；备注：如果你计划检查POST_PAYLOAD 就使用这个指令，这个指令必须和"phase:2"处理阶段动作和REQUEST_BODY 变量/位置一起使用，这三部分任意一个没有配置，你就无法检查请求体。
SecRule VARIABLES OPERATOR [ACTIONS]
#SecRule是ModSecurity主要的指令，用于分析数据并根据结果执行动作，
#VARIABLES描述哪个变量被检查，举个例子，下述规则会拒绝URI中含有单词dirty的事务。每条规则可以指定一个或多个变量,如SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
#OPERATOR描述如何进行检查
#[ACTIONS]可选的,描述当操作进行成功的匹配一个变量时具体怎么做。
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
#XML内容情况下启动XML解析
SecRule REQUEST_HEADERS:Content-Type "application/json" "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
#json内容情况下启动XML解析
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
#配置ModSecurity允许的最大请求体的缓存区大小，第一条是有上传文件的，默认1G，第二条是没有文件的上传的限制，默认128K;
这项指令便于在受到某些使用大尺寸请求进行DoS 攻击时减少影响。提供上传文件服务的WEB 应用必须配置SecRequestBodyLimit 为一个很大的值。由于大文件直接进行磁盘文件存取，不会加大内存的消耗。
但是，仍然有可能有人利用超大请求体限制和发送大量大小的非上传请求。该指令消除这一漏洞。
SecRequestBodyLimitAction Reject|Process Partial
#SecRequestBodyLimitAction Reject：拒绝、Process Partial：呈现请求的第一部分 #当请求超过SecRequestBodyLimit策略中配置的设置时该做什么。默认情况下拒绝大于集合的请求。
SecRule REQBODY_ERROR "!@eq 0" "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:400, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
SecPcreMatchLimit 1000
#设置PCRE库中的匹配限制。
SecPcreMatchLimitRecursion 1000
#在PCRE库中设置匹配限制递归，提高效率。
SecRule TX:/^MSC_/ "!@streq 0" "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
SecResponseBodyAccess On
#允许ModSecurity访问response body，您应该启用此指令以识别错误和数据泄漏问题。启用这个指令会增加内存消耗和响应延迟。
#备注：如果你计划检查HTML 的响应，需要使用这个指令。这个指令必须和"phase:4"处理阶段动作和REQUEST_BODY 变量/位置一起使用，这三部分任意一个没有配置，你就无法检查请求体。
SecResponseBodyMimeType text/plain text/html text/xml
#设置返回体的MIME资源的媒体类型
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial|Reject
#配置允许缓存的最大响应体大小，默认512K
#配置SecResponseBodyLimit，控制如果request body 大小超过上面限制的情况，默认时ModSecurity拒绝超过指定长度的响应体，
SecDataDir /tmp/
#ModSecurity存放持久化数据（如ip 地址数据，session 数据等）路径，initcol、setsid和setuid需要用到这个指令
SecUploadDir /opt/modsecurity/var/upload/
#配置拦截文件存储的目录
SecUploadKeepFiles RelevantOnly
#配置是否保存事务处理后的拦截文件
SecUploadFileMode 0600
#配置拦截文件存储权限
SecDebugLog /opt/modsecurity/var/log/debug.log
SecDebugLogLevel 3
#调试日志路径，1~3级别一直用于产生apache/nginx的错误日志，因为你可以在产品中一直使用0级别做为默认的日志级别，级别4-9用于调试，
不建议在产品中使用这么高级别的日志，过度的日志记录会限制服务器的性能。
SecAuditEngine RelevantOnly
#配置审计日志引擎的开启与否；On － 默认情况下记录所有事务的日志；RelevantOnly - 默认只记录事务中由warning或error触发的日志，或者记录一些特意考虑过的状态码
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
#记录由规则标记的事务，以及触发服务器错误(由5xx或4xx确定，不包括404， #级别响应状态代码)。#备注：必须将SecAuditEngine 设置为RelevantOnly，其参数是个正则表达式。
#这个指令最主要的目的是允许你配置审计产生特殊HTTP 响应状态码的唯一事务，这个指令通常用于减少审计日志文件的总体大小。记住一点，如果使用了这个参数，那么返回状态码是200 的成功攻击事件不会记录。
SecAuditLogParts ABIJDEFHZ
#定义每个事务中记录到审计日志中的部分。默认：ABCFHZ.
可用的审计日志部分:
A - 审计日志标题(强制的)
B - 请求标题
C - 请求体(目前仅针对请求体存在，并且ModSecurity已经配置成拦截)
D - 为中间人响应头保留，暂未实现
E - 中间人响应体(目前仅对配置了拦截响应体和配置审计日志引擎记录有效)。中间人响应体和实际的响应体相同，除非ModSecurity拦截了中间人响应体，这种情况下，实际响应体会包含出错信息（可能是apache的默认错误信息，也可能是出错文档页面）。
F - 最终响应头(除了日期和服务器标题以外的被apache添加的近期内容传递信息)。
G - 为实际响应体保留，暂未实现。
H - 审计日志索引
I - 这C部分的替换，使用multipart/form-data编码时，在所有的异常情形下会记录与C相同的数据，在这种情况下，会记录假的application/x-www-form-urlencoded内容，这包含参数的相关信息，但不是这个文件的。如果你不想用文件（通常很大）来存储你的审计日志，这是很方便的。
J - 保留。实现后，这部分会包含文件使用multipart/form-data编码上传的信息。
K - 这部分包含一个完整的列表，按顺序匹配（每行一个），这些规则是完全合格的，从而表明继承默认的动作和操作，从2.5.0开始支持。
Z - 最终分界，意味着是条目的最后(强制的)
#配置使用审计日志记录机制的类型Serial|Concurrent,Serial - 所有的审计日志条目都被存储在主审计日志记录文件中，随意使用是很方便，但是它很慢，因为任何时候只有一个文件被打开也只能写入一条审计日志条目。
SecAuditLogType Serial
Concurrent - 审计日志条目被存储于不同的文件中，每个事务一个，如果你要把审计日志数据发送到远程ModSecurity控制主机上就使用Concurrent日志模式。
SecAuditLog /var/log/modsec_audit.log
#审计日志路径
SecArgumentSeparator &
#指定的字符作为application/x-www-form-urlencoded内容的分隔符，默认是&，非常少的情况下应用会使用分号(;)。
这个指令用于后台WEB应用在使用非标准的参数分隔符,如果没有在每一个WEB应用中合理设置这个指令，
那么ModSecurity可能无法适当的分析所有的参数，并且规则匹配的效果可能会显著的降低。
SecCookieFormat 0
#选择当前配置文本中使用的cookie格式，0 - 使用version 0 (Netscape) cookies，这是大部分应用使用的，也是默认值；1 - 使用version 1 cookies
SecUnicodeMapFile unicode.mapping 20127
#定义将由urlDecodeUni变换函数用于在规范化期间映射Unicode代码点的文件的路径，并指定要使用的代码点。
SecStatusEngine On
#控制状态报告功能。使用基于DNS的报告将软件版本信息发送到ModSecurity项目团队。
上面的内容解释已经很详细了，需要再详细说明的一个地方(重点来了)，就是上面提到的规则中定义的阶段，就是在规则中看到的phase部分
ModSecurity是有分五个阶段，这五个阶段，基本就是从一个web请求，到达服务器到服务器响应的一个过程，分别是以下阶段：
phase1:阶段1
请求标头到达服务器
phase2:阶段2
请求体阶段，这个也是安全规则默认的阶段
phase3:阶段3
响应头阶段
phase4:阶段4
响应体阶段
phase5:阶段5
记录阶段
比如上诉介绍配置详情时，关于SecRequestBodyAccess配置的解释，说必须和第二个阶段动作一起使用，我们都知道，RequestBody就是请求体
然后上面说到SecResponseBodyAccess必须和第四个阶段动作一起使用，因为ResponseBody时响应体
所以就是说定义你制定的规则，在哪个阶段起作用，起上面作用，阻止还是记录
默认的Modsecurity只有上面几个规则，对于web防护来说肯定是不够的，而OWASP维护了一套核心的规则集，包括200多个ModSecurity规则，基本覆盖了所有攻击类型的规则，有大佬整理了所有crs规则集，详情请查看http://f2ex.cn/modsecurity-crs-3-list/
下篇文章中详细介绍crs规则集
持续更新，欢迎扫码关注，敬请期待！
温馨提示
如果你喜欢本文，请分享到朋友圈，想要获得更多信息，请关注我。