之前的文章中介绍了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规则集
温馨提示
如果你喜欢本文,请分享到朋友圈,想要获得更多信息,请关注我。