ModSecurity是一款用于帮助用户保护其Web应用程序的工具。有了它，就可以让用户在晚上睡得更好；在这本书中，我们将介绍它是怎样实现该目标的。我们通常称ModSecurity为web应用防火墙（web application firewall,WAF），这个普遍被接受的术语指的是一类用于保护web应用程序的产品；其它时间，我们称它为HTTP入侵检测工具（HTTP intrusion detection tool），我们认为这个名称能够更好地描述ModSecurity是什么。这两个名字都不完全合适，但我们没有一个更好的被普遍接受的名称。然而，我们叫它什么并不重要。关键是，web应用程序——您的，我们的，每个人的——都非常不安全；我们都在努力克服安全问题，使用任何能够获取的办法来处理这些问题。

            Ivan在负责多个基于web的产品时想创建ModSecurity。他看到很多web应用程序非常不安全，工程师在设计这些web应用程序时花费了很少的时间，在理解安全问题时花费的时间就更少。不仅web应用程序不安全，而且人们很少意识到他们是否被攻击或者被渗透。很多web应用程序仅仅保留标准访问和错误日志，而这些日志并不能提供太多有用信息。

　　　　ModSecurity将帮助你在晚上睡的更好，最重要的是，它解决了可见性问题:它允许您查看web流量。可见性对于安全至关重要，一旦您能够查看HTTP流量，你可以实时地分析它，记录它，并对事件作出响应。该概念最优特点是在没有实际接触web应用程序的情况下完成所有工作。更好的是，这个概念可以应用于任何程序——即使你不能获取它们的源代码。

1.1  ModSecurity简史

　　　　　像很多其它开源工程一样，ModSecurity开始时只是作为一个爱好。回到2002年，生产安全的web应用程序几乎是不可能的事情。（可悲的是，如今的情况也是一样的。）然而，这种情况导致了一个在web应用程序前面设置工具的想法，这个工具可以控制进出系统的数据流。其第一版本在2002年９月发布，但是在这个工具变得有用之前还需要几个月的时间。其它人开始学习ModSecurity，并且其流行度开始增加。

　　　　　　最初，该工具的大部分开发工作都是针对Apache进行的，以使请求体检查成为可能。Apache 1.3.x不包括任何截取或过滤api，但是仍然有办法诱骗它进行提交内容。Apache 2.x通过提供能够截获内容的API改变了这一现状，但是没有可用的文档。

　　　　　到了2004年，Ivan从沉迷于软件开发转变为沉迷于Web应用程序安全。他辞掉了工作，开始将ModSecurity作为一个事业。在2006年夏天，ModSecurity在由Forrester research进行的评估中与其它web应用防火墙针锋相对。他取得了巨大的成功。同年晚些时候，它被Breach Security收购。一个人的团队最终变成了由很多人组成的团队：Brian Rectanus来研究ModSecurity，Ofer Shezaf着手规则，Ryan C. Barnett处理社区管理和教育。ModSecurity 2.0，一个完整的重写版本，在2006年晚些时候发布。Breach Security同样发布了ModSecurity社区控制器，将远程日志传感器的功能与监视和报告GUI结合起来。

　　　　在2009年，Ivan离开了Breach Security。他在ModSecurity中呆了一段时间，但是更多时间是在这本书的第一版上。拿他的话说，如果没有完善的文档记录，他不能离开这个项目。Brian Rectanus领头，与此同时，Ryan C. Barnett负责ModSecurity规则，并对核心规则第二版本进行了重大改进。2010年，Trustwave收购了Breach Security，并承诺振兴ModSecurity。然后，这个项目交给了Ryan C. Barnett和Breno Silva。

　　　　在2011年３月发生了重大事件：Trustwave宣布将把ModSecurity的许可从GPLv2更改为Apache软件许可证(ASLv2)。这是迈向更广泛使用ModSecurity的一大步，因为ASL属于许可许可证的范畴。后来，核心规则集项目也宣布了同样的变化，该项目由开放Web应用程序安全项目(OWASP)托管。随后，商业WAF产品开始集成ModSecurity引擎，并添加了OWASP ModSecurity，将核心规则作为默认规则集。从2.7.0开始，ModSecurity被移植到nginx和IIS web服务器上，但是这些移植从未达到原始版本的稳定性。这最终导致了一个重大的重写，它将能够很好地支持多个平台。这将成为ModSecurity 3.0，目前正在制作中。

        在2013年，Felipe Costa接手了Breno的首席开发员职位，当Ryan在2015年离开Trustwave时，他将规则集项目交给了Chaim Sanders；Chaim Sanders于2014年加入Trustwave，维护项目的编码和社区管理。

1.2　ModSecurity能够做什么？

　　　　ModSecurity是一个用于实时web应用程序监视、日志记录、调试和访问控制的工具包。我认为它是一个推动者。没有硬性规定告诉你该做什么，相反，由您通过可用的特性来选择您自己的方按。这就是为什么这个部分的标题会问ModSecurity能做什么，而不是它做了什么。

　　　　选择要做事情的自由是ModSecurity特性的一个重要组成部分，并且与它的开放源码特性很好地结合在一起。通过对源代码的完全访问，您可以选择扩展到自定义和扩展工具本身以满足你的需求的能力。这不是意识形态的问题，而是实用性的问题。我只是不想我的工具限制我所能做的。

　　　　　下面是ModSecurity最重要的使用场景：

1.2.1 实时应用程序安全监视和访问控制

          其核心，ModSecurity允许你实时访问HTTP流，和检查流的能力，这对于实时安全监控来说已经足够了。通过ModSecurity的持久性存储机制，可以增加一个维度，这使您能够跟踪系统元素并执行事件关联分析。如果您愿意，您可以可靠地阻塞，因为ModSecurity使用了完整的请求和响应缓冲。

1.2.２ 虚拟补丁

          虚拟补丁是一个概念，它在一个单独的分层中进行漏洞消除；应用程序中，您可以在不触及应用程序的情况下修复应用程序中的问题。虚拟补丁适用于使用任何通信协议的应用程序，但它对HTTP尤其有用，因为通常可以通过中间设备了解流量。ModSecurity擅长虚拟补丁，因为它有可靠的屏蔽能力和灵活的规则语言，可以适应任何需要。到目前为止，ModSecurity提供的虚拟补丁只需要最少的投资，它是最容易执行的，而且大多数组织都可以直接受益。

1.2.3全HTTP流日志

　　　　出于安全考虑，Web服务器在日志记录方面通常做得很少。默认情况下，它们的日志非常少，即使进行了大量调整，也无法获得所需的所有数据。我还没有遇到能够记录完整事务数据的web服务器——但是，ModSecurity使您能够记录所有内容，包括原始事务数据，这对于取证非常重要。另外，您可以选择哪些事务被记录，哪些部分被记录，哪些部分被清理。此外，这种详细的日志记录也有助于应用程序故障排除——而不仅仅是安全性。

1.2.４连续被动安全评估

　　　　　安全评估在很大程度上被看作是一个活动的预定事件，在这个事件中，一个独立的团队被提供来试图执行模拟攻击。持续被动安全评估是一种实时监控的变体，它不关注外部各方的行为，而是关注系统本身的行为。这是一种早期预警系统，可以在被利用之前检测到许多异常和安全缺陷的痕迹。

1.2.5Web应用程序加固

　　　　　ModSecurity中我最喜欢的用途之一是攻击表面消减，在这种情况下，您可以选择性地缩小您愿意接受的HTTP特性(例如，请求方法、请求头、内容类型等)。ModSecurity直接或通过与其他Apache模块的协作，可以帮助您执行许多类似的限制。例如，可以修复许多会话管理问题，以及跨站点请求的伪造漏洞。

1.2.6一件小事，但对你却很重要

                现实生活经常会对我们提出不同寻常的要求，当你处理这些需求时，当你最需要ModSecurity时，它的灵活性就派上了用场。你可能需要解决安全问题，或者你有一个完全不同的问题。例如，有些人将ModSecurity作为XML web服务路由器，结合其解析XML和应用XPath表达式的能力来代理请求。谁知道呢?

注意：

经常有人问我，ModSecurity是否可以用来保护Apache本身。答案是，在某些有限的情况下，它可以，但这不是它设计的目的。在Apache或第三方模块中，您有时可以在ModSecurity中捕捉到攻击，但是在ModSecurity之前有大量代码运行。如果该区域存在漏洞，ModSecurity将无法对此采取任何行动。

Web应用防火墙是什么?

我说过ModSecurity是一个web应用程序防火墙，但鲜为人知的是，没有人真正知道什么是web应用程序防火墙。一般认为，web应用程序防火墙是一种中介元素(既可以作为软件附加组件或过程实现，也可以作为网络设备)来增强web应用程序的安全性，但是一旦深入挖掘，就会产生不同的观点。有许多理论试图解释不同的观点，但我能想到的最好的理论是，与我们以前所拥有的不同，web应用程序空间是如此复杂，没有简单的方法可以将我们所做的安全区分开来。不要只关注名字，你应该关注一个特定的工具所做的事情以及它是如何帮助你的。

1.3指导原则

　　　　ModSecurity的三个指导原则:

灵活性

ModSecurity是根据一个特定的用户设计和构建的:一个需要能够拦截、分析和存储HTTP流量的安全专家。我在硬编码的功能上没有看到太多的价值，因为现实生活是如此的复杂，以至于每个人都需要做一些稍微不同的事情。ModSecurity通过提供一种强大的规则语言来实现灵活性，它允许您精确地执行您需要的操作，并结合使用规则的能力，只需要将规则细化到单个字节。

被动

另一个关键的设计决策是尽可能地使模式安全成为被动;因此，除非得到指示，否则它不会对事务数据进行更改。这样做的主要原因是为了让用户有信心使用完全被动的规则集来部署ModSecurity，这样他们就可以在知道自己的应用程序不会受到影响的情况下，安全地进行观察。这就是为什么ModSecurity会给你很多信息，但是最终，把决定权留给你。

可预测性

没有完美的工具，但是可以预测下一个最好的工具。有了所有的事实，你就能理解ModSecurity的弱点，并围绕它工作。

ModSecurity中的一些元素不在这些原则的范围之内。例如，ModSecurity可以改变Apache对外部世界的识别方式，将Apache进程限制在一个范围内，甚至将安全令牌注入到流量中。尽管这些功能是有用的，但我认为它们偏离了ModSecurity的主要目的，它是一种可靠的、可预测的工具，可以实现HTTP流量检查。

1.４部署选项

　　ModSecurity支持两种部署选项:嵌入式和反向代理部署。没有一种正确的方法来使用它们;根据最适合你的情况选择一个选项。两种选择都有利有弊:

        嵌入式

        因为ModSecurity是一个Apache模块，所以您可以将它添加到任何兼容的Apache版本中。目前，这意味着，最适合modsecurity的最新Apache版本，是从2.4.x以后的版本。这就是说，2.2.x以后的版本Modsecurity都可以工作。ModSecurity已经被移植到Nginx和IIS，它引入了更广泛的平台选项。嵌入式选项对于那些已经设计并不想更改其架构的人来说是一个很好的选择。如果需要保护数百个web服务器，嵌入式部署首选。在这种情况下，构建一个单独的基于代理的安全层是不切实际的。嵌入式ModSecurity不仅不会引入新的失败点，而且还会随着底层web基础设施的规模而无缝伸缩。嵌入式部署的主要挑战是服务器资源在web服务器和ModSecurity之间共享。嵌入式选项对于那些已经设计并不想更改其架构的人来说是一个很好的选择。

        反向代理

        反向代理是有效的HTTP路由器，设计为站在web服务器和它们的客户机之间。当您安装一个专用的Apache反向代理并为其添加ModSecurity时，您会得到一个“适当的”网络web应用程序防火墙，您可以使用它来保护同一网络上的任意数量的web服务器。许多安全从业人员希望有一个单独的安全层，这样您就可以完全隔离所保护的系统。在性能方面，一个独立的ModSecurity安装将会有专门的资源，这意味着您将能够做更多的事情（例如，有更复杂的规则)。这种方法的主要缺点是新的故障点，需要使用两个或多个反向代理的高可用性设置来解决这个问题。

1.5 开始

            在本书的第一个实用章节中，我将简要介绍ModSecurity的内部信息，以帮助您入门。

1.5.1混合ModSecurity的性质

            ModSecurity是一个混合的WAF引擎，它的一些工作依赖于主机web服务器。ModSecurity最初是为Apache web服务器编写的，但后来被移植到Nginx和IIS上。尽管Nginx和IIS两个版本的ModSecurity都被积极维护，但它们受到ModSecurity的传统和与Apache源代码紧密集成的影响。ModSecurity的下一个主要版本正在重新实现，以将其与Apache分离，从而使它能够同样地支持所有web服务器。在此之前，运行ModSecurity的最好的web服务器是Apache 2.x。

　　　　Apache为ModSecurity提供了它为所有其他模块所做的工作—它处理以下基础设施任务:

1、解密SSL

2、将入站连接流分解为HTTP请求。

3、部分解析HTTP请求

4、调用ModSecurity，选择正确的配置上下文。

5、在必要时将请求体删除。

　　　　Apache在反向代理中执行了一些额外的任务:

1、将请求转发到后端服务器(使用或不使用SSL)

2、部分解析HTTP响应

3、在必要时将响应体删除。

　　　混合实现的优点是它是高效的;当涉及到HTTP解析时，工作的重复是最小的。这种方法的一些缺点是，您不总是能够访问原始数据流，并且web服务器有时不以安全意识工具的方式处理数据。在Apache的情况下，混合方法运行得相当好，有几个小问题:

　　　　请求行和报头均为空终止。

这通常不是问题，因为Apache看不到的东西不会伤害任何模块或应用程序。然而，在一些罕见的情况下，空字节逃避的目的是隐藏一些东西，而这种Apache行为只会帮助隐藏。

　　　　　请求头转换

Apache将规范化请求头，合并多个使用相同名称的头，并将跨越两个或多个行的标题合并。这种转化可能会让人很难察觉到轻微的闪避，但实际上，这还不是问题。

　　　　　　快速的请求处理

Apache将快速处理一些请求，使得ModSecurity在日志记录阶段不能做任何事情。特别是无效的HTTP请求，将会被Apache拒绝，而没有ModSecurity参与。

　　　　　　无法访问某些响应头

由于Apache的工作方式，在嵌入式模式下，服务器和日期响应头是不可见的。他们不能被检查或记录。

1.5.２主要领域的功能

ModSecurity提供的功能大致分为四个方面:

　　　　解析

ModSecurity试图弄清楚可用的数据。受支持的数据格式由具有安全意识的解析器支持，这些解析器提取数据位并将其存储在规则中。

　　　　缓冲

在典型的安装中，请求和响应主体都将被缓冲。这意味着ModSecurity通常在将完整的请求传递给应用程序进行处理之前，并在它们被发送到客户端之前完成响应。缓冲是一个重要的特性，因为它是提供可靠阻塞的唯一方法。缓冲的缺点是需要额外的RAM来存储请求和响应体数据。

　　　　日志记录

完整的事务日志(也称为审计日志记录)是ModSecurity的重要组成部分。这个特性允许您记录完整的HTTP流量，而不只是基本的访问日志信息。请求标头、请求体、响应头、响应体——所有这些位都将可用。只有有能力看到正在发生的事情，你才能控制住自己。

　　　　　规则引擎

规则引擎以所有其他组件执行的工作为基础。当规则引擎开始运行时，它所需要的各种数据位和数据块都将准备就绪，以便进行检查。在这一点上，规则将接管评估事务并在必要时采取行动。

　　　　　请注意

有一件事是ModSecurity有意避免做的:作为一个设计问题，ModSecurity不支持数据清理。我不相信清洗处理，纯粹因为我相信它太难了。如果你确定你被攻击了(你必须在你决定进行清洗之前)，那么你应该拒绝处理所有的违规请求。试图清洗只是打开了一个新的战场，在这个战场上，你的攻击者没有任何东西可以失去，但却拥有一切来赢得胜利。另一方面，你没有任何东西可以赢，但一切都会输。

1.6规则是什么样子

ModSecurity的每一部分都围绕着两件事:配置和规则。配置告诉ModSecurity如何处理它看到的数据;规则决定如何处理处理后的数据。虽然现在讨论规则如何工作还为时过早，但我将在这里举一个简单的例子，让您了解它们的外观。例如:

　　　　SecRule ARGS "@rx" \

　　　　　　"id:2000,log,deny,status:404"

即使没有进一步的帮助，您也可以识别规则中指定我们想要在输入数据( )中寻找的内容的部分。类似地，如果我们找到所需的模式(log,deny,status:404)，您很容易就会知道会发生什么。当您查看一般规则语法时，情况将变得更加清晰:

SecRule VARIABLES OPERATOR ACTIONS

　　　　这三部分含义如下:

1、变量部分告诉ModSecurity在哪里看。在示例中使用的ARGS变量表示所有请求参数。

2、操作符部分告诉ModSecurity如何看待。在示例中，我们有一个正则表达式模式，它将与ARGS匹配。

3、动作部分用于向规则添加元数据，并指定当匹配发生时ModSecurity应该做什么。前一个示例的规则指定ID 2000，以唯一标识规则，并在匹配上指定以下操作:日志问题、停止事务处理和返回HTTP响应代码404。

　　　　我希望您不会对第一个规则的简单性感到失望。我向您保证，通过结合ModSecurity提供的各种设施，您将能够编写有用的规则，在必要时实现复杂的逻辑。

１.7事务生命周期

在ModSecurity中，每个事务都经过五个步骤或阶段。在每个阶段中，ModSecurity将在开始时执行一些工作(例如，解析已成为可用的数据)，调用指定在该阶段工作的规则，或者在阶段规则完成后执行一两个任务。乍一看，似乎五个阶段太多了，但每个阶段都存在一个原因。总是有一个任务，有时是几个，只能在事务生命周期的某个特定时刻执行。

请求头(1)

请求标头阶段是ModSecurity的第一个入口点。此阶段的主要目的是允许规则编写人员在进行昂贵的请求体处理之前评估请求。类似地，经常需要影响如何处理请求主体，且在这个阶段是进行该过程的时间。例如，ModSecurity在默认情况下不会解析XML或JSON请求体，但是您可以通过将适当的规则放到第1阶段来指导它。

请求主体(2)

请求体阶段是主请求分析阶段，在接收和处理完请求体之后立即进行。这个阶段的规则拥有所有可用的请求数据。之后，web服务器将生成响应本身(在嵌入式模式中)，或者将事务转发到后端web服务器(反向代理模式)。

响应头(3)

响应头阶段发生在响应头可用之后，但在响应主体读取之前。需要决定是否检查响应主体的规则应该在此阶段运行。

响应主体(4)

响应体阶段是主要的响应分析阶段。在此阶段开始时，将读取响应主体并将其所有数据提供给规则以进行决策。

日志(5)

日志记录阶段是特殊的。这是你不能阻止的唯一阶段。在此阶段运行时，事务将完成，因此您可以做的事情很少，但可以记录发生的事实。在这个阶段的规则是用来控制日志记录是如何执行的，或者是在持久存储中保存信息。

1.8生命周期的例子

为了让您更好地了解每个事务中发生了什么，我们将检查一个POST事务的详细调试日志。调试日志是由ModSecurity提供的一个额外的日志工具，它允许您非常详细地观察模块的执行步骤。我故意选择了一个事务类型，它将请求主体作为其传输数据的主要方法，因为这样的事务将执行ModSecurity的大部分。为了使事情保持相对简单，我使用了一个没有任何规则的配置，删除了一些调试日志，以使其更加清晰，并从每个日志行删除了时间戳和一些额外的元数据。

请注意

此时，请不要试图了解有关日志的所有内容。我们的想法是让大家了解ModSecurity的工作原理以及调试日志的介绍。在您开始使用ModSecurity后不久，您将发现调试日志是必不可少的规则编写和故障排除工具。

在本节中，我使用的事务非常简单。我把请求数据放到两个不同的位置，参数a在查询字符串中，参数b在请求体中，但是这个请求没有别的意思。

POST /?a=test HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 6

b=test

响应是完全不起眼的:

HTTP/1.1 200 OK

Date: Fri, 22 Jul 2016 04:59:13 GMT

Server: Apache

Content-Length: 12

Connection: close

Content-Type: text/html

Hello World!

在请求头(如果有的话)被读取之前，Apache首先会调用ModSecurity。首先是初始化消息，其中包含mod_unique_id生成的唯一事务ID。有了这个，您应该能够将调试日志中的信息与访问和审计日志中的信息结合起来。此时，ModSecurity将解析请求行和请求头中的信息。在本例中，查询字符串部分包含一个单独的参数(a)，因此您将看到一个记录其发现的消息。然后ModSecurity将创建一个事务上下文并调用REQUEST_HEADERS阶段:

[4]Initialising transaction (txid V5LjWH8AAQEAAFPTr64AAAAA).

[5]Adding request argument (QUERY_STRING): name "a", value "test"

[4]Transaction context created (dcfg 1154668).

[4]Starting phase REQUEST_HEADERS.

假设规则没有阻塞事务，ModSecurity现在将返回对Apache的控制，允许其他模块在控制权返回之前处理请求。

在第二阶段，ModSecurity将首先读取并处理请求主体，如果它存在的话。在下面的示例中，您可以看到来自输入过滤器的三条消息，它们告诉您所读的内容。第四个消息告诉您从请求主体中提取了一个参数。该请求中使用的内容类型(应用程序/x-www-form-urlencode)是ModSecurity自动识别和解析的类型之一。一旦请求主体被处理，就会处理request_body规则。

[4]Second phase starting (dcfg 1154668).

[4]Input filter: Reading request body.

[9]Input filter: Bucket type HEAP contains 6 bytes.

[9]Input filter: Bucket type EOS contains 0 bytes.

[5]Adding request argument (BODY): name "b", value "test"

[4]Input filter: Completed receiving request body (length 6).

[4]Starting phase REQUEST_BODY.

日志中提到的过滤器是处理请求和响应主体的ModSecurity的一部分:

[4] Hook insert_filter: Adding input forwarding filter (r 7f5fc8002970).

[4] Hook insert_filter: Adding output filter (r 7f5fc8002970).

每次ModSecurity将一组数据发送到请求处理程序时，调试日志中将会有一条消息，最后一条消息是，缓冲区中不再有任何数据:

[4] Input filter: Forwarding input: mode=0, block=0, nbytes=8192 (f 7f5fc800ae90, r 7f5fc8002970).

[4] Input filter: Forwarded 6 bytes.

[4] Input filter: Sent EOS.

[4] Input filter: Input forwarding complete.

请求现在在Apache的请求处理程序的手中。如果web服务器在嵌入式模式下运行，请求处理程序将自己生成响应。如果它以反向代理模式运行，服务器将把事务转发到后端服务器。

此后不久，输出过滤器将开始接收数据，此时将调用response_header规则：

[9] Output filter: Receiving output (f 7f5fc800aeb8, r 7f5fc8002970).

[4] Starting phase RESPONSE_HEADERS.

一旦所有的规则都运行了，ModSecurity将继续在其缓冲区中存储响应主体，之后它将运行response_body规则：

[9]Content Injection: Not enabled.

[9]Output filter: Bucket type MMAP contains 13 bytes.

[9]Output filter: Bucket type EOS contains 0 bytes.

[4]Output filter: Completed receiving response body (buffered full - 12 bytes).

[4]Starting phase RESPONSE_BODY.

同样，假设没有一个规则被阻塞，那么累积的响应主体将被转发给客户端:

[4] Output filter: Output forwarding complete.

最后，日志记录阶段将开始。日志规则将首先运行，以允许它们影响日志记录，之后将调用审核日志子系统以在必要时记录事务。来自审计日志子系统的消息将是日志中的最后一个事务消息。在这个示例中，ModSecurity告诉我们它在事务中没有找到任何感兴趣的东西，它认为没有理由记录它:

[4]Initialising logging.

[4]Starting phase LOGGING.

[4]Recording persistent data took 0 microseconds.

[4]Audit log: Ignoring a non-relevant request.

1.8文件上传的例子

包含文件的请求的处理方式略有不同。通过再次遵循调试日志中的活动，可以更好地理解这些变化:

[4] Input filter: Reading request body.

[9] Multipart: Boundary: ------------------------ce3de83f6cf79943

[9] Input filter: Bucket type HEAP contains 140 bytes.

[9] Multipart: Added part header "Content-Disposition" "form-data; name=\"f\"; filename=\"eicar.com.txt

[9] Multipart: Added part header "Content-Type" "text/plain"

[9] Multipart: Content-Disposition name: f

[9] Multipart: Content-Disposition filename: eicar.com.txt

[9] Input filter: Bucket type HEAP contains 116 bytes.

[4] Multipart: Created temporary file 1 (mode 0600): /usr/local/modsecurity/var/tmp/20160723-054018-V5L

[9] Multipart: Added file part 7f67b400fd50 to the list: name "f" file name "eicar.com.txt" (offset 140

[9] Input filter: Bucket type EOS contains 0 bytes.

[4] Request body no files length: 96

[4] Input filter: Completed receiving request body (length 256)

除了在操作中查看Multipart解析器之外，您还将看到ModSecurity创建一个临时文件(它将从中提取pload),并调整其特权以匹配所需的配置。

然后，在事务结束时，您将看到清理和临时文件被删除：

[4] Multipart: Cleanup started (remove files 1).

[4] Multipart: Deleted file (part) "/usr/local/modsecurity/var/tmp/20160723-054427-V5LoG38AAQEAAF4SFAoA

如果ModSecurity决定保留上传的文件，该临时文件将不会被删除。相反，它将被转移到存储区:

[4] Multipart: Cleanup started (remove files 0).

[4] Input filter: Moved file from "/usr/local/modsecurity/var/tmp/20160723-054018-V5LnIn8AAQEAAFurQfQAA

在示例跟踪中，您已经观察到存储在RAM中的一个小文件的上传。当出现较大的上传时，ModSecurity首先会尝试使用RAM，一旦发现文件更大，就切换到磁盘上的存储空间:

[9] Input filter: Bucket type HEAP contains 6080 bytes.

[9] Input filter: Bucket type HEAP contains 2112 bytes.

[9] Input filter: Bucket type HEAP contains 5888 bytes.

[9] Input filter: Bucket type HEAP contains 2304 bytes.

[9] Input filter: Bucket type HEAP contains 5696 bytes.

[9] Input filter: Bucket type HEAP contains 2496 bytes.

[9] Input filter: Bucket type HEAP contains 5504 bytes.

[9] Input filter: Bucket type HEAP contains 2688 bytes.

[9] Input filter: Bucket type HEAP contains 5312 bytes.

[9] Input filter: Bucket type HEAP contains 2880 bytes.

[9] Input filter: Bucket type HEAP contains 5120 bytes.

[9] Input filter: Bucket type HEAP contains 3072 bytes.

[4] Input filter: Request too large to store in memory, switching to disk.

将创建一个新文件来存储整个原始请求主体:

[4] Input filter: Created temporary file to store request body: /usr/local/modsecurity/var/tmp/20160723

[4] Input filter: Wrote 128146 bytes from memory to disk.

这个文件总是在清理阶段被删除:

[4] Multipart: Deleted file (part) "/usr/local/modsecurity/var/tmp/20160723-054813-V5Lo-X8AAQEAAF4SFAsA

[4] Input filter: Removed temporary file: /usr/local/modsecurity/var/tmp/20160723-054813-V5Lo-X8AAQEAAF

1.9对Web服务器的影响

添加ModSecurity将改变你的web服务器的运行方式。和所有的Apache模块一样，你要为额外的灵活性和安全模式付出代价，ModSecurity增加了服务器上的CPU和内存消耗。确切的数量将取决于您的modsecurity配置——即规则——以及您的服务器的使用情况。以下是增加资源消耗的各种活动的详细清单:

•ModSecurity将增加Apache已经执行的解析，这将导致CPU消耗略有增加。

•复杂的解析器(例如，XML)比较昂贵。

•文件上传的处理可能需要I/O操作。在某些情况下，入站数据会被复制到磁盘上。

•解析将增加RAM的消耗，因为每个提取的元素(例如，一个请求参数)都需要复制到它自己的空间中。

•请求体和响应体通常是缓冲的，以支持可靠的阻塞。

•配置中的每一条规则都将使用一些CPU时间(用于操作符)和RAM(在分析输入数据之前)。

•规则中使用的一些运算符(例如正则表达式运算符)是cpu密集型的。在非常大的请求或响应体上运行正则表达式可能需要很长时间——甚至是秒。

•完整事务日志是一个昂贵的I/O操作。

在实践中，这份清单很重要，因为它能让你了解情况;重要的是您有足够的资源来支持您的ModSecurity需求。如果你这样做了，那么不管ModSecurity有多昂贵，都不重要。而且，对一个人来说，昂贵的东西可能不是别人。如果您没有足够的资源来完成所有您想要的ModSecurity，您将需要监视系统的操作，并删除一些功能以减少资源消耗;实际上，ModSecurity所做的一切都是可配置的，所以您应该没有问题。

通常，在反向代理模式下运行ModSecurity更容易，因为这样你通常会有一个完整的服务器(有自己的CPU和RAM)。在嵌入式模式中，ModSecurity将添加到已经由web服务器执行的处理中，因此在繁忙的服务器上这种方法更具挑战性。

为了实现它的价值，ModSecurity通常使用最少的必要资源来执行所需的功能，所以这实际上是一个为了速度而交换功能的例子;如果你想做得更多，你就得付出更多。

1.20接下来是什么?

本节的目的是绘制未来的ModSecurity活动，并帮助确定从何处进行。你的去向取决于你想要实现的目标以及需要花费多少时间。可以说，完整的ModSecurity经验包括以下几个要素:

安装和配置

这是所有用户必须学习如何执行的基本步骤。接下来的三章将教你如何使ModSecurity操作、执行安装、一般配置和日志配置。一旦完成了这些任务，就需要决定如何使用modsecurity——这就是本书剩余部分的内容。

规则编写

规则编写是一项基本技能。您现在可以将规则视为检测应用程序安全性攻击的工具。他们是那样的，但他们也有更多功能。在ModSecurity中，您编写规则来了解更多关于HTTP客户端的信息(例如，地理定位和IP地址的声誉)，执行长期的活动跟踪(例如IP地址、会话和用户)，执行策略决策(使用可用的信息来做出警告或阻塞的决策)，编写虚拟补丁，甚至检查ModSecurity本身的状态。

的确，攻击检测规则是属于其独特的特性，但为了成功地编写它们，您需要了解大量关于应用程序安全性的知识。出于这个原因，许多ModSecurity用户通常都专注于使用第三方规则集进行攻击检测。这是一个合理的选择。不是每个人都有时间和意愿成为应用安全专家。即使最终不使用任何检验规则，编写虚拟修补程序的能力也足以使用ModSecurity。

规则集

使用现有的规则集是最简单的方法，可以达到众所周知效果：

投入少量的精力，获得巨大的利益。传统上，ModSecurity规则的主要来源是CRS项目，现在由OWASP托管。另一方面，如果你想要勤写代码，我可以告诉你，我很乐意写自己的规则。这是了解应用程序安全性的好方法。唯一的缺点是它需要大量的时间投资。

远程日志和警报管理GUI

在没有远程日志解决方案和没有GUI的情况下，ModSecurity是完全可用的（两者通常是在一起的）。重要的错误消息被复制到Apache的错误日志中。完整的事务通常记录到审计日志中。有了一个通知系统，您就会知道什么时候发生了什么事情，并且可以访问审计日志。例如，许多安装会将Apache的错误日志转移到一个中央日志系统(通过syslog)。

使用多个传感器来管理这个过程会变得更加困难。此外，GUIs使整个监控的体验更加愉快。出于这个原因，您可能打算安装一个可用的远程集中工具，并使用它的GUI。下面的参考资料部分列出了可用选项。

1.21资源

本节包含各种可帮助您工作的ModSecurity资源列表。

通用资源

以下资源是最基本的:

ModSecurity网站

ModSecurity的网站可能会成为你的主要信息来源。您应随时访问网站，以及订阅来自博客的更新。

官方文档

官方的ModSecurity文档是在wiki中维护的，但是它的副本都是为了包含在每个版本中。

问题跟踪器

您将希望访问ModSecurity问题跟踪器，原因有二:报告一个ModSecurity本身的问题(例如，当您发现一个bug)或检查下一个(主要的或次要的)版本的进展。在报告任何问题之前，检查一下支持清单，它将帮助您收集帮助解决问题所需的信息。提供尽可能多的信息将帮助开发人员理解并复制问题，并快速提供修复(或解决方案)。

用户的邮件列表

用户的邮件列表(mod-security-users@lists.sourceforge.net)是一个通用的邮件列表，您可以通过它讨论ModSecurity。可以自由提问，提出改进意见，并讨论想法。您将首先通过这个列表了解新的ModSecurity版本。

核心规则集邮件列表

CRS项目是OWASP的一部分，并且有一个单独的邮件列表(owasp-modsecuri-core -core- rules -set@lists.owasp.org)。关于假阳性和新规则的开发的讨论也发生在核心规则GitHub库中。

1.22开发人员资源

如果您对开发工作感兴趣，您需要访问以下资源:

开发人员邮件列表

开发人员的邮件列表是讨论ModSecurity软件开发的资源。如果您决定开始使用源代码，请使用此列表来寻求建议并讨论您的工作。还有一个ModSecurity开发人员指南和示例。

源代码的访问

ModSecurity的源代码托管在GitHub存储库中，它允许您直接访问或通过基于web的UI访问它。

1.23AuditConsole

从命令行完全使用ModSecurity是很有趣的，但审查审计和调试日志在没有特殊脚本或高级工具的情况下是很困难的。日志集中和GUI工具的最佳选择是由Christian Bockermann创建的AuditConsole。

AuditConsole是免费的，提供以下功能:

.事件集中来自多个远程ModSecurity安装。

.Event存储和检索

.支持多个用户帐户，支持不同的视图。

.Event标签

.事件触发器，在控制台中执行。

1.24总结

本章提供了一个学习ModSecurity的指南。我在一个较高的层次上介绍了ModSecurity，讨论了它是什么，它不是什么，它能做什么，不能做什么。我还让您了解了ModSecurity是什么样子，并描述了它的常见使用场景，并介绍了它的一些有趣的操作部分。

你现在所拥有的基础应该足以帮助你踏上ModSecurity探索之旅。下一章讨论安装。