ModSecurity第⼀章 简介
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服务器(反向代理模式)。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论