modSecurity规则学习(一)——配置文件

环境:modSecurity3.0,nignx1.13.8

modSecurity配置文件

1、nginx.conf

1 server {
2         listen       81;
3         modsecurity on; //启动modsecurity插件
4         location / {
5             modsecurity_rules_file /usr/local/nginx/conf/modsecurity.conf;      //modsecurity配置
6             root   html;
7             index  index.html index.htm;
8         }
9     }

2、modsecurity.conf

#SecRuleEngine是接受来自ModSecurity-CRS目录下的所有规则的安全规则引擎。因此,我们可以根据需求设置不同的规则。要设置不同的规则有以下几种。
#
SecRuleEngine On:将在服务器上激活ModSecurity防火墙。它会检测并阻止该服务器上的任何恶意攻击。
#SecRuleEngine Detection Only:如果这个规则是在whitelist.conf文件中设置的,它只会检测到所有的攻击,并根据攻击产生错误,但它不会在服务器上阻止任何东西。
#SecRuleEngine Off::这将在服务器上上停用ModSecurity的防火墙。
SecRuleEngine DetectionOnly
#
SecRequestBodyAccess是否允许ModeSecurity访问request bodies(post请求内容);备注:如果你计划检查POST_PAYLOAD 就使用这个指令,这个指令必须和"phase:2"处理阶段动作和REQUEST_BODY 变量/位置一起使用,这三部分任一一个没有配置,你就无法检查请求体。
SecRequestBodyAccess On
#SecRule是ModSecurity主要的指令,用于分析数据并根据结果执行动作,SecRule VARIABLES OPERATOR [ACTIONS];
#VARIABLES描述哪个变量被检查,举个例子,下述规则会拒绝URI中含有单词dirty的事务。每条规则可以指定一个或多个变量,如SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
#OPERATOR描述如何进行检查
#[ACTIONS]可选的,描述当操作进行成功的匹配一个变量时具体怎么做。
#XML内容情况下启动XML解析
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
#json内容情况下启动XML解析
SecRule REQUEST_HEADERS:Content-Type "application/json" "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
#配置ModSecurity允许的最大请求体的缓存区大小,第一条是有上传文件的,默认1G,第二条是没有文件的上传的限制,默认128K;#:配置ModSecurity 允许的最大请求体的缓存区大小,除了请求中正在传送的文件大小。
这项指令便于在受到某些使用大尺寸请求进行DoS 攻击时减少影响。提供上传文件服务的WEB 应用必须配置SecRequestBodyLimit 为一个很大的值。由于大文件直接进行磁盘文件存取,不会加大内存的消耗。
但是,仍然有可能有人利用超大请求体限制和发送大量大小的非上传请求。该指令消除这一漏洞。
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
#
SecRequestBodyLimitAction Reject:拒绝、Process Partial:呈现请求的第一部分    #当请求超过SecRequestBodyLimit策略中配置的设置时该做什么。 默认情况下拒绝大于集合的请求。
SecRequestBodyLimitAction Reject
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.'"
#设置PCRE库中的匹配限制。
SecPcreMatchLimit 1000
#在PCRE库中设置匹配限制递归,提高效率。
SecPcreMatchLimitRecursion 1000
SecRule TX:/^MSC_/ "!@streq 0" "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
#允许ModSecurity访问response body,您应该启用此指令以识别错误和数据泄漏问题。 启用这个指令会增加内存消耗和响应延迟。
SecResponseBodyAccess On
#备注:如果你计划检查HTML 的响应,需要使用这个指令。这个指令必须和"phase:4"处理阶段动作和REQUEST_BODY 变量/位置一起使用,这三部分任一一个没有配置,你就无法检查请求体。
#设置返回体的MIME资源的媒体类型
SecResponseBodyMimeType text/plain text/html text/xml
#配置允许缓存的最大响应体大小,默认512K SecResponseBodyLimit
524288
#配置SecResponseBodyLimit,控制如果request body 大小超过上面限制的情况,默认时ModSecurity拒绝超过指定长度的响应体,
#然而一些WEB站点,会产生一些非常长的响应为适当限制带来难度。
#这类网站不得不极大的提高关注度,把限制放到了首位(控制内存消耗)。
#有能力选择的是发生站点限制时,管理员能选择仅仅检查响应的第一部分,这部分可融入理想的限制,并让其通过。
#可以证明未经检查就允许部分响应是个漏洞,理论上这是对的,但仅适用于攻击者控制输出的案例(如它可以任意的长)。
#不管怎样,在这种情况下,无论如何是阻止不了漏洞的。攻击者在数据回送前可以压缩,打乱或者甚至是加密,因为可以穿越任意监控设备。
SecResponseBodyLimitAction ProcessPartial|Reject
#ModSecurity存放持久化数据(如ip 地址数据,session 数据等)路径,initcol、setsid和setuid需要用到这个指令 SecDataDir
/tmp/
#配置拦截文件存储的目录 #SecUploadDir /opt/modsecurity/var/upload/
#配置是否保存事务处理后的拦截文件 #SecUploadKeepFiles RelevantOnly #SecUploadFileMode 0600
#调试日志路径,1~3级别一直用于产生apache/nginx的错误日志,因为你可以在产品中一直使用0级别做为默认的日志级别,级别4-9用于调试,
不建议在产品中使用这么高级别的日志,过度的日志记录会显著服务器的性能。
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3
#配置审计日志引擎的开启与否;On - 默认情况下记录所有事务的日志;RelevantOnly - 默认只记录事务中由warning或error触发的日志,或者记录一些特意考虑过的状态码 SecAuditEngine RelevantOnly
#记录由规则标记的事务,以及触发服务器错误(由5xx或4xx确定,不包括404, #级别响应状态代码)。#备注:必须将SecAuditEngine 设置为RelevantOnly,其参数是个正则表达式。
#这个指令最主要的目的是允许你配置审计产生特殊HTTP 响应状态码的唯一事务,这个指令通常用于减少审计日志文件的总体大小。记住一点,如果使用了这个参数,那么返回状态码是200 的成功攻击事件不会记录。
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
#定义每个事务中记录到审计日志中的部分。默认: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 - 最终分界,意味着是条目的最后(强制的)
SecAuditLogParts ABIJDEFHZ
#配置使用审计日志记录机制的类型Serial|Concurrent,
Serial - 所有的审计日志条目都被存储在主审计日志记录文件中,随意使用是很方便,但是它很慢,因为任何时候只有一个文件被打开也只能写入一条审计日志条目。
Concurrent - 审计日志条目被存储于不同的文件中,每个事务一个,如果你要把审计日志数据发送到远程ModSecurity控制主机上就使用Concurrent日志模式。
SecAuditLogType Serial
#审计日志路径
SecAuditLog /var/log/modsec_audit.log
#指定的字符做为application/x-www-form-urlencoded内容的分隔符,默认是&,非常少的情况下应用会使用分号(;)。
这个指令用于后台WEB应用在使用非标准的参数分隔符,如果没有在每一个WEB应用中合理设置这个指令,
那么ModSecurity可能无法适当的分析所有的参数,并且规则匹配的效果可能会显著的降低。 SecArgumentSeparator
&
#选择当前配置文本中使用的cookie格式,0 - 使用version 0 (Netscape) cookies,这是大部分应用使用的,也是默认值;1 - 使用version 1 cookies SecCookieFormat 0
#定义将由urlDecodeUni变换函数用于在规范化期间映射Unicode代码点的文件的路径,并指定要使用的代码点。
SecUnicodeMapFile unicode.mapping 20127
#控制状态报告功能。 使用基于DNS的报告将软件版本信息发送到ModSecurity项目团队。
SecStatusEngine On #Load OWASP Config Include crs-setup.conf #Load all other Rules Include rules/*.conf

 

posted @ 2018-03-13 09:40  897807300  阅读(11167)  评论(0编辑  收藏  举报