科普文：软件架构Nginx系列之【Nginx web应用防火墙ModSecurity介绍】

ModSecurity 简介

官网：

中文手册：

使用教程：

ModSecurity是一个入侵侦测与防护引擎，它主要是用于Web 应用程序，所以也被称为Web应用程序防火墙。 它可以作为Apache Web服务器的模块或是单独的应用程序来运作。ModSecurity的功能是增强Web application的安全性和保护Web application以避免遭受来自已知与未知的攻击。

ModSecurity计划是从2002年开始，后来由Breach Security Inc.收购，但Breach Security Inc.允诺ModSecurity仍旧为open source，并开放源代码给大家使用。

最新版的ModSecurity（一个开源的web应用防火墙，即WAF）开始支持核心规则集（Core Rule Set，即CRS，可用于定义旨在保护Web应用免受零日及其他安全攻击的规则）了。

ModSecurity团队发布的2.5.10 版还包含了其他一些特性，如并行文本匹配、Geo IP解析和信用卡号检测等，同时还支持内容注入、自动化的规则更新和脚本等内容。

可以通过ModSecurity手工创建安全过滤器、定义攻击并实现主动的安全输入验证。此外，它还提供了一个面向Lua语言的新的API，为开发者提供一个脚本平台以实现用于保护Web应用的复杂逻辑。

ModSecurity是一个开源的、跨平台的Web应用防火墙（WAF），被称为WAF界的“瑞士军刀”。它可以通过检查Web服务接收到的数据，以及发送出去的数据来对网站进行安全防护。

ModSecurity相关下载

ModSecurity 稳定版 (v3.0.4)
Apache/Nginx:  ()

ModSecurity 稳定版 (v2.9.3)
Apache/Nginx:  ()
IIS:  () |  ()

ModSecurity 核心规则文件
|

注意：
由于官方停止了ModSecurity v3与Apache的连接器（ModSecurity-apache connector）的研发工作，因此如果生产环境的WEB服务器为Apache，请使用ModSecurity v2版本，v2版本更适用于Apache。

ModSecurity功能介绍

SQL Injection (SQLi)：阻止SQL注入
Cross Site Scripting (XSS)：阻止跨站脚本攻击
Local File Inclusion (LFI)：阻止利用本地文件包含漏洞进行攻击
Remote File Inclusione(RFI)：阻止利用远程文件包含漏洞进行攻击
Remote Code Execution (RCE)：阻止利用远程命令执行漏洞进行攻击
PHP Code Injectiod：阻止PHP代码注入
HTTP Protocol Violations：阻止违反HTTP协议的恶意访问
HTTPoxy：阻止利用远程代理感染漏洞进行攻击
Sshllshock：阻止利用Shellshock漏洞进行攻击
Session Fixation：阻止利用Session会话ID不变的漏洞进行攻击
Scanner Detection：阻止黑客扫描网站
Metadata/Error Leakages：阻止源代码/错误信息泄露
Project Honey Pot Blacklist：蜜罐项目黑名单
GeoIP Country Blocking：根据判断IP地址归属地来进行IP阻断

ModSecurity安装：CentOS7+ModSecurity v2.9.3

最新结论（20220114）：请勿在Nginx使用ModSecurity V2版本，V2版本与Nginx存在兼容问题，且目前官方团队明确表示不会进行修复。

服务器操作系统：；

ModSecurity：

一、安装相关工具

yum install -y wget epel-release
yum install -y httpd httpd-devel pcre pcre-devel libxml2-devel gcc lua-devel yajl-devel ssdeep-devel curl-devel

二、编译Modsecurity

将modsecurity安装包上传至/usr/local目录下

cd /usr/local
tar -zxvf modsecurity-2.9.3.tar.gz
cd modsecurity-2.9.3
./configure --enable-standalone-module --disable-mlogc
make

三、安装Nginx

cd /usr/local
wget http://nginx.org/download/nginx-1.16.1.tar.gz
tar -xvzf nginx-1.16.1.tar.gz
cd /usr/local/nginx-1.16.1
./configure --add-module=/usr/local/modsecurity-2.9.3/nginx/modsecurity/ --prefix=/usr/local/nginx
make
make install

四、测试效果

启动nginx

/usr/local/nginx/sbin/nginx

模拟攻击，测试未启动ModSecurity时的访问效果，访问URL为：http://服务器IP/?param=%22%3E%3Cscript%3Ealert(1);%3C/script%3E

效果如下：

五、最后配置

创建用于存在配置文件的文件夹，并复制相关配置文件到目录中

mkdir -p /usr/local/nginx/conf/modsecurity/
cp /usr/local/modsecurity-2.9.3/modsecurity.conf-recommended /usr/local/nginx/conf/modsecurity/modsecurity.conf
cp /usr/local/modsecurity-2.9.3/unicode.mapping /usr/local/nginx/conf/modsecurity/unicode.mapping

，解压后复制crs-setup.conf.example到/usr/local/nginx/conf/modsecurity/下并重命名为crs-setup.conf；

复制rules文件夹到/usr/local/nginx/conf/modsecurity/下，同时修改REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example与RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example两个文件的文件名，将".example"删除，可将自己写的规则放置于此两个文件中；

编辑nginx.conf

在http或server节点中添加以下内容（在http节点添加表示全局配置，在server节点添加表示为指定网站配置）：

ModSecurityEnabled on;  
ModSecurityConfig modsecurity/modsecurity.conf;

编辑modsecurity.conf

SecRuleEngine DetectionOnly改为SecRuleEngine On

同时在文件末尾添加以下内容：

Include crs-setup.conf
Include rules/*.conf

六、重新加载Nginx测试效果

/usr/local/nginx/sbin/nginx -s reload

ModSecurity配置操作

ModSecurity的运作设计有以下的基础概念：

l  让使用者可以做任何想做的事情(Empower users to do what they want)

l  使用者设定的动作才会执行(Don’t do anything implicitly)

l  预设是不做任何动作(Be passive)

ModSecurity的部署架构

l  与Web Server结合 。

l  与Apache结合部署为网关，当作一个反向代理。

ModSecurity是一个Web应用防火墙（WAF）。当前已经有超过70％的攻击发生在网络应用层，各级组织急需要能够保证他们的系统安全性的帮助。WAF系统的部署，可以为web应用增加一个外部安全层来检测或防止攻击。针对一系列的攻击,ModSecurity为web应用提供了强大的保护，并对HTTP流量进行监测和实时分析，这些都只是很少或是根本没有影响系统的基础设施。

HTTP流量记录

web服务器已有的日志功能已经足够进行访问请求分析，但是就web的应用分析还有些不足，特别是大多情况下没办法记录下请求体。你的对手很清楚这一点，所以很多时候的攻击是通过POST请求产生，并导致您的系统失明。ModSecurity充分的获取HTTP交互中的所以内容，并记录完整的请求和响应。其日志功能可以允许您更细致的做出判断究竟什么是登录的时候，并确保相关的数据都被记录下来。一些请求和响应中的某些关键字段可能包含敏感数据，ModSecurity可以被配置成在记录这些审计日志前隐藏它。

实时监控和攻击检测

除了提供记录日志功能外，ModSecurity还能实时的监控HTTP的流量以检测攻击。在某些时候，ModSecurity做为一个WEB入侵，可以让你对发生在WEB系统上的一些可疑事件做出响应。

攻击防御和及时修补

ModSecurity能够立即针对你的WEB应用系统进行攻击防御，有三种通用的方法：

1、消极(negative)安全模型：消极安全模型监控那些异常的、不常用的和通用的WEB攻击类请求。它统计每个请求的有关IP地址、应该连接、和用户帐户的异常分数，当出现较高的异常分数时，会记录日志并完全的阻止访问。

2、积极安全模开型：部署积极安全模型后，只有那些明确的请求被允许通过，其它的一律禁止。这个模式要求你对需要保护的WEB应用要非常的了解。因此积极安全模式最好是用于那种大量访问却很少更新的系统，这样才能使这种模型的维护工作量降到最低。

3、已知漏洞攻击：其规则语言使ModSecurity成为一个理想的外部修补工具，外部修补（有时是指虚拟修补）可以减少机会之窗。一些组织修补这些应用的漏洞通常需要几周的时间，使用ModSecurity，应用系统可以从外部修补，根本不用改应用的源码（甚至时不用去管它），可以保证你的系统安全直到有一个合适的补丁来应用到系统中。

灵活的规则引擎

灵活的规则引擎是ModSecurity的核心，其实现了ModSecurity的规则语言，这是一个专用的程序语言设计的用于处理HTTP的传输数据。ModSecurity规则语言被设计的简单易用，非常的灵活：通用的操作是简单的，而复杂的操作也是可以实现的。经过认证的ModSecurity规则，放在ModSecurity中，包含了一整套规则，它实现了通用目的强化、协议正规化和对一些通用web应用安全问题的检测。大量评论认为，这些规则可以用于学习研究使用。

嵌入式模式部署

ModSecurity是一个可嵌入式的WEB应用防火墙，意思就是它可以做为以apache为基础的已经提供WEB服务的WEB服务器的一部分。这样的部署译意风一些特殊的优势：

1、不改变已有的网络结构。只需要花几分钟就可以为你的WEB服务器添加ModSecurity，而且由于它默认被设计为完全的被动方式，你可以自由的逐步部署并且只使用你需要的特性。同样也可以根据你的需要轻松的删除或停用它。

2、不存在单点故障。与网络设备部署方式不同，你不会给你的系统带来新的故障点。

3、绝对支持负载均衡。因为它以嵌入方式运行在WEB服务器上，ModSecurity会自动的利用附加的负载均衡特性。你不需要考虑负载均衡，除非你的系统本来就需要它。

4、极少开销。因为它在WEB服务器进程内工作，不会带来网络间接通信的负载，而且只进行最小的分析和数据交换开销。

5、加密或压缩内容没问题。许多IDS系统分析SSL流量的时候很困难，但对于ModSecurity没有麻烦，因为它工作于已解密和解压的数据环节。

基于网络的部署

在基于apache的反向代理模式上ModSecurity同样能工作的很好，我们很多客户选择这样做。在这种情形下，装了ModSecurity的可以保护任一一种WEB服务器（即使它不是apache的）。

可移植性

众所周知，ModSecurity可以很好的工作在众多操作系统上，已经将它成功运行在Linux, Windows, Solaris, FreeBSD, OpenBSD, NetBSD, AIX, Mac OS X, 和HP-UX等系统上。

1.了解mod_security 配置文件

/etc/httpd/conf.d/mod_security.conf ：mod_security模块主配置文件 /etc/httpd/modsecurity.d/ – 配置文件目录。 /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf – 特别配置文件 /var/log/httpd/modsec_debug.log –调试文件日志。 /var/log/httpd/modsec_audit.log ModSecurity报警信息文件。 查看/etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf 确保下面有一行：

SecRuleEngine On

2.设置mod_security

上述的步骤只是将Mod Security启动而已，但实际上并不会为你的web服务器做任何的防护动作；因此需要额外设定才会让Mod Security发挥功能，此部分将会对如何设定Mod Security做一个说明。

下面开始介绍Mod Securit的四种主要的设定指令。

（1）一般的设定，包括装规则引擎(rule engineer)开启等基本指令，常见的设定如下：

#Basic configuration options

# 打开过滤引擎开关。如果是Off，那么下面这些都不起作用了。

SecRuleEngine On

#配置是否让ModSecurity默认处理或缓冲请求体

SecRequestBodyAccess On

#配置ModSecurity允许的最大请求体的缓存区大小

SecResponseBodyAccess On

#配置拦截的目录

SecUploadDir /opt/apache-fronted/tmp/

#配置是否保存事务处理后的拦截文件

SecUploadKeepFiles Off

#配置ModSecurity允许的最大请求体的缓存区

SecRequestBodyLimit 131072

#配置ModSecurity使用内存保存的最大请求体大小

SecRequestBodyInMemoryLimit 131072

#配置ModSecurity允许的最大请求体的缓存区大小，除了请求中正在传送的文件大小。这项指令便于在受到某些使用大尺寸请求进行DoS攻击时减少影响。提供上传文件服务的WEB应用必须配置SecRequestBodyLimit为一个很大的值。由于大文件直接进行磁盘文件存取，不会加大内存的消耗。但是，仍然有可能有人利用超大请求体限制和发送大量大小的非上传请求。该指令消除这一漏洞。

SecResponseBodyLimit 524288

（2）设定Mod Security如何执行调试的日志部分，常见的设定如下：

#指定ModSecurity调试日志文件的路径

SecDebugLog logs/modsec_debug.log

#配置冗长的调试日志数据

SecDebugLogLevel 0

（3） 设定Mod Security如何执行审计的日志部分，常见的设定如下：

#定义主审计日志文件

SecAuditEngine RelevantOnly

SecAuditLogRelevantStatus ^5

SecAuditLogParts ABIFHZ

SecAuditLogType Serial

SecAuditLog logs/modsec_audit.log

(4) Rules

Mod Security最主要的设定部分，是一个以事件为基础的语言。

语法：SecRule VARIABLES OPERATOR [ACTIONS]

VARIABLES：指定哪些变量要进行处理

OPERATOR：要如何处理这些变量取得我们想要的

ACTIONS (optional)：当达到上述的处理时，要做什么动作

（5）Rule处理的阶段

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及其以后的版本中被当作配置错误。

（6）Rules 简介

SecRule是ModSecurity主要的指令，用于分析数据并根据结果执行动作。通常规则的格式如下：

SecRule VARIABLES OPERATOR [ACTIONS]

l  VARIABLES 规则中的变量

第一部分，VARIABLES描述哪个变量被检查，举个例子，下述规则会拒绝URI中含有单词dirty的事务。

SecRule ARGS dirty

每条规则可以指定一个或多个变量

SecRule ARGS|REQUEST_HEADERS:User-Agent dirty

XPath格式是选择操作的第三方支持格式。XPath格式仅能针对特殊变量XML使用，只有请求体使用XML格式时可用。

SecRule XML:/xPath/Expression dirty

注意：不是所有的集合支持选择操作格式类型，你需要参考各个集合的文档来决定是否支持。

一些常见的变量：

ARGS、ARGS_NAMES、ARGS_GET、ARGS_GET_NAMES、ARGS_POST、ARGS_POST_NAMES

AUTH_TYPE

REQBODY_PROCESSOR、REQBODY_PROCESSOR_ERROR

FILES、FILES_NAMES、FILE_SIZES

REMOTE_ADDR、REMOTE_HOST、REMOTE_PORT

REQUEST_BODY、REQUEST_COOKIES、REQUEST_COOKIES_NAMES、REQUEST_FILENAME

RESPONSE_BODY

Rule中的变量部分可以一个以上， 以”|”来区隔即可，如果设定的规则超过多行，则可用”\”来进行分隔。

l  OPERATOR

第二部分，OPERATOR描述如何进行检查。OPERATOR是正则表达式(Regular Expression)，但其实ModSecurity提供不少可用的OPERATOR，利用”@”即可指定要用何种OPERATOR，例如SecRule REQUEST_URI  iii”。

以下是一些范例：

SecRule REMOTE_ADDR “^192\.168\.1\.101$”

REMOTE_ADDR：指定变量对象为远程联机的IP地址

“^192\.168\.1\.101$”：针对上述的变量进行比对，如果非192.168.1.101，则符合，可指定要做何种动作

SecRule ARGS “@validateUtf8Encoding”

ARGS：指定变数为http传递的参数

“@validateUtf8Encoding”：指定OPERATOR为对这些参数进行Utf8编码进行检查

SecRule FILES_TMPNAMES “@inspectFile /path/to/inspect_script.pl”

FILES_TMPNAMES：指定变量为上传档案的暂存名称

“@inspectFile /path/to/inspect_script.pl”：指定利用inspect_script.pl档案的语法来检查上传档案

l  ACTIONS

第三部分可选的，ACTIONS，描述当操作进行成功的匹配一个变量时具体怎么做。指定如果VARIABLE有符合OPERATOR的情况时，要执行何种动作。ACTIONS主要区分为五种型态：

（1）Disruptive actions (中断目前的处理)

deny、drop、redirect、proxy、pause…

（2）Non-disruptive actions (改变状态)

Append、auditlog、exec…

（3）Flow actions (改变规则流动)

allow、chain、pass、skip…

（4）Meta-data actions (包含规则的metadata)

id、rev、severity、msg、phase、log, nolog、…

（5）Data actions (可放置内容给其它action用)

capture、status、t、xmlns…

使用例子

SecRule REQBODY_PROCESSOR_ERROR “ 0“ “phase:2,log,deny,msg:’Failed to parse request body.’,severity:2“

说明：

REQBODY_PROCESSOR_ERROR：指定针对request body发生的进程发生的错误的代码

“ 0“：当不等于0时，即有错误发生时

处理动作 “phase:2,log,deny,msg:’Failed to parse request body.’,severity:2“

phase:2：由于对象为request body，因此指定在phase:2进行

log：当情况符合（发生错误），将错误记录

deny：将这个处理拒绝

msg:’Failed to parse request body’：网页上并显示出这样的错误讯息

severity:2：将此状况列为严重程度为2

（ModSecurity Core Rules）  核心规则内容

ModSecurity是一个WEB应用防火墙引擎，自身所提供的保护非常少。为了变得更有用些，ModSecurity必须启用规则配置。为了让用户能够充分利用ModSecurity离开方块，Breach Security, Inc.为ModSecurity 2.x提供了一套免费的认证规则集。和入侵检测及防御系统不一样，它们依赖于具体的签名过的已知漏洞，而这一核心规则却是为从网络应用中发现的不知名的漏洞提供一般的保护，通常这些漏洞大多数情况下都是自定义编码的。这一核心规则有了大量的评论，从而使得这些能够被用来做ModSecurity的部署向导。最新的核心规则可能通过ModeSecurity的站点找到-http://www.modsecurity.org/projects/rules。

核心规则内容

为了提供一般WEB应用保护，核心规则使用以下技术：

l  HTTP保护 – HTTP协议正规划检测，并启用本地有效策略

l  一般WEB攻击保护 – 检测一般WEB应用的安全攻击

l  自动检测 – 检测机器人、爬虫、扫描器和其它的表面恶意行动

l  木马检测 – 检测木马程序进入

l  过失隐藏 – 伪装服务器发出错误消息

开源的ModSecurity与那些商业产品相比的不同之处

硬件设备对比软件方案：ModSecurity是一个软件Web 应用防火墙引擎，本质上是个Apache模块。这意味着它是嵌入在目标Web服务器当中的，而并非部署在单独的设备中。然而，我们也可以将Apache配置成一个反向代理并达到类似的目的，但要知道ModSecurity本身并不会处理这个方面。软件WAF方案的优势：有些情况需要进行大规模的部署，在这种情况下，将 WAF分布在目标Web服务器当中要比从垂直方向上增加外部硬件设备实际的多。嵌入式部署的另一个好处是无需再去处理SSL解码了，因为Web服务器会进行预处理并将数据回传给ModSecurity。软件WAF方案也并非完美无缺，其缺点如下：

· 可能无法将新的软件加到Web服务器当中。

· 会使用到本地资源。

· 反应时间的影响——很多商业WAF设备可以在Sniff模式下进行非线性部署，这样就无法评估在线性情况下对HTTP事务的访问所需的反应时间了。商业与开源产品高级功能对比：ModSecurity拥有一个高级的规则语言和Lua API以编写复杂逻辑。我们既可以创建消极安全规则（寻找已知的坏输入），也可以创建积极安全规则（只允许已知的好输入）以规定输入验证的防护类型。这种方式的主要限制在于ModSecurity无法自动化创建这些规则，所以必须手工创建。但只在以下两种场合之一才行：

A.如果Web应用不经常变化

B.响应攻击扫描报告，在这种情况下可以使用目标的积极安全规则

如果将ModSecurity作为一个对已知问题的虚拟修补方案，那么它就不太适合于B了。高端的商业WAF都具有自动化的学习和分析机制以创建这些积极安全规则，同时还能够从客户端与Web应用之间的交互中进行学习。