有时我们看到ModSecurity用户在邮件列表中询问性能。在这篇文章中，我将讨论一些提高ModSecurity性能的重要主题。

1 - HTTP缓存和加速

在一个通用的web环境中，静态内容(例如。图像)http通信的大部分区域。通常，用户不希望对这类内容执行安全规则。因此，第一个建议是在ModSecurity前面设置一个HTTP缓存和加速解决方案。

我们有有趣的开源解决方案，其中之一就是Varnish。。您可以将其设置在ModSecurity前面，并将其配置为缓存静态流量。一旦完成，Varnish将开始提供这类内容，ModSecurity将只看到真正需要的东西。

另一个可能的解决方案是设置规则来检测您想要检查和忽略其他文件扩展名:

SecRuleEngine On

SecAction "id:'1', phase:1, t:none,setvar:'tx.inspect_extensions=.html/ .php/', nolog, pass"

SecRule REQUEST_BASENAME "\.(.*)$""chain,capture,allow,setvar:tx.exts=.%(tx.1}/,phase:1, t:none,t:urlDecodeUni, t:lowercase,id:2,logdata:'%{TX.0}'"

SecRule TX:EXTS "!@within %{tx.inspect_extensions}"

然而，这并不是最好的解决方案，因为即使您跳过所有其他规则，ModSecurity也会花时间对这类数据进行缓冲、转发和执行一些规则。

2 -规则选择

如果您正在使用OWASP核心规则集，那么规则选择是另一个要讨论的重要主题。

我们在CRS中有许多类别的规则，您应该重新查看它们，并确定所有类别和规则对您是否重要。

我们建议加载所有规则，但是从性能的角度来看，有时是不可能的。所以你应该做一个风险分析，并载入原始数据。

3 -规则执行模式

OWASP核心规则集项目中的规则可以在两种不同的模式下执行:

自包含模式——规则继承“拒绝”破坏性操作。第一个匹配的规则将被阻塞。

协作检测模式——这是一种“延迟阻塞”操作模式，其中每个匹配规则将继承“通过”操作，并且只会导致异常分数。

从性能的角度来看，自包含模式是最好的解决方案，因为它执行的规则应该少于协作模式，从而减少了由规则引擎和日志引擎引起的开销。然而，从假阳性的角度来看，协作模式可以发出较少的假阳性。

也就是说，您应该首先尝试默认模式(自包含模式)，然后决定是否适合您。如果没有，在决定转向协作检测模式之前，我建议先使用ModSecurity规则异常特性。

值得一提的是，只有在SecRuleEngine打开时，才应该从性能的角度看到结果。

4 -规则预过滤

如果您打算编写自己的规则，特别是使用@rx操作符和非平凡的正则表达式来检查大量数据，比如响应体，您应该考虑使用@pm操作符作为预过滤器规则:

SecRule RESPONSE_BODY "@pm some_leak_patterns" "phase:4,chain,id:12345,deny"SecRule RESPONSE_BODY "@rxyour_nontrivial_regex_some_leak_patterns"

@pm操作符使用一种名为Aho-Corasick的快速多模式匹配算法，可以用来避免对入站和出站缓冲区执行regex。

另一个预过滤器的想法是:

1. 立即拒绝来自国家的ip
2. 立即拒绝有坏名声的ip
3. 立即拒绝不允许参数数量的事务
4. 立即拒绝参数长度不允许的事务。。

有了这个想法，您可以构建一小组规则，这些规则将在CRS之前运行，并将立即拒绝事务，以避免根据所有CRS规则检查它们。

5 -缓冲

ModSecurity工作，缓冲入站和出站数据到belater受规则检查。与此主题相关的主要瓶颈是缓冲响应体，原因有二:它将消耗大量RAM，并且通常放置在响应体阶段的规则非常昂贵。

也就是说，您可以考虑禁用响应体检查功能，将SecResponseBodyAccess设置为Off，并有条件地启用它，在特定情况下使用针对特定类型ecresponsebodymimetypes的responseBodyAccessOn ..

例如:

SecResponseBodyMimeType text/plain text/html text/xml

SecResponseBodyAccess Off

SecRule REQUEST_BODY|ARGS "@pm union select""phase:2,chain,id:1234,ctl:responseBodyAccess=On"

SecRule REQUEST_BODY|ARGS "@rxyour_nontrivial_regex_union_select"

SecRule RESPONSE_BODY "@pm some_leak_patterns""phase:4,chain,id:12345,deny"

SecRule RESPONSE_BODY "@rxyour_nontrivial_regex_some_leak_patterns"

6 -日志

如果你不集中注意力，日志引擎可能会成为性能杀手:

在规则中不断执行调优过程，以避免太多的误报。请记住，磁盘i/o非常昂贵，并且您不希望花费资源来记录误报。

不要使用串行记录模式。它使用锁来保护文件，这会降低性能。而是使用并发模式。

检查正在记录的审计日志部分。像k和E这样的部分可能会增加日志引擎带来的开销，因为它通常需要向磁盘写入大量数据。

不要启用生产中的调试日志。

7 - PCRE-JIT

在pcrelibrary中插入了即时编译器支持(>=8.20)。即时编译是一种优化，可以极大地加快模式匹配操作。当相同的条件被多次匹配时，效果最好。

发布8.20 21-Oct-2011——

这个版本的主要变化是包含了ZoltanHerczeg的即时编译器支持，可以通过构建PCREwith——enable-jit来访问它。8.20还修复了8.13中引入的一个不幸的bug，并消除了与Perl的一些错误和差异。

ModSecurity 2.7。x系列可以使用PCRE-JIT执行regex。从性能的角度来看，这是一个非常好的特性。要启用它，您必须使用以下配置选项编译ModSecurity:

./configure –enable-pcre-jit

确保您的PCRE库是使用JIT支持编译的(使用上面的PCRE发行说明中描述的选项)。而且modsecurityandapache必须使用相同的库版本。你可以查看intoerror log来检查它。

例如，我们发送了一个大的输入，请求体规则处理并测量了花费的时间:

JIT Disabled Phase 2 rules = 422749 usecs

JIT Enabled Phase 2 rules = 115777 usecs

看看这个例子，pcr -jit可以使规则平均速度提高75%。

8.缓存Lua虚拟机

这适用于需要在同一事务中执行多个Lua脚本的人。正常情况下，ModSecurity会创建并销毁一个运行在同一事务中的VM foreach lua脚本。你可以改变这个行为，重新编译ModSecurity与选项:

./configure –enable-lua-cache

重新编译后，ModSecurity将在整个事务期间将LuaVM保存在内存中，从而减少create/destroyVM操作造成的开销。

作为一个例子，让我们来测量在同一事务中执行的三个脚本的性能:

禁用缓存

Lua: Executing script: /etc/apache2/modsecurity/script1.lua

Lua: Script completed in 742 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script2.lua

Lua: Script completed in 517 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script3.lua

Lua: Script completed in 489 usec, returning: 1.

Total: 1748usecs

缓存启用

Lua: Executing script: /etc/apache2/modsecurity/script1.lua

Lua: Script completed in 592 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script2.lua

Lua: Script completed in 130 usec, returning: 1.

Lua: Executing script: /etc/apache2/modsecurity/script3.lua

Lua: Script completed in 101 usec, returning: 1.

Total: 823usecs

我们可以看到由VM创建/销毁操作导致的开销减少了约50%。

9.检测昂贵的规则。

如果有更多的性能问题，您可以尝试以下步骤来找到昂贵的规则，然后有机会改进它。

作为一个例子，假设我们试图检测运行在阶段2(请求体)上的昂贵规则。如果您使用的是最新的modsecurity版本(>= 2.7.4)，则可以使用所有这些特性。

创建一个规则来检测阶段2是否存在问题。假设1000微秒太多了

SecRule PERF_PHASE2 "@qt 1000" "id:1234,phase:3"

如果你有一个触发器，它表明你有昂贵的规则。因此，让我们试着检测它们是否添加了遵循规则

# All rules that spent more than 50usecs will be present inaudit log part H

SecRulePerfTime 50

# PERF_RULES is a collection that will contain all rulesthat spent more than SecRulePerfTime vallue to run.

SecRule PERF_RULES "@qt 50" "id:1,phase:3"

所以如果你有昂贵的规则，我们会看到警告:

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:960032. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:958022. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

[Tue Apr 23 17:50:26 2013] [error] [client 192.168.0.103]ModSecurity: Warning. Operator GT matched 50 at PERF_RULES:973323. [file"/etc/apache2/modsecurity/owasp-modsecurity-crs-2.2.6/base_rules/modsecurity_crs_99_perl.conf"][line "2"] [id "1"] [hostname "192.168.0.104"][uri "/acao.php"] [unique_id "UXcCIsCoAGUAACvOLqcAAAAD"]

我们可以看到，规则960032、958022和973323的执行花费了50 usecs。，但具体需要多少时间呢?您将把这些信息放入审计日志H部分:

Rules-Performance-Info: "960032=622","958022=731", "973323=109".

请查看参考手册以查看所有PERF_variables。

10 -永久存储

ModSecurity的持久存储机制是基于磁盘的。尽管如此，它并不快，好像我们可以共享内存中的数据。因此，如果可能的话，我们可以在RAMDISK中设置和定义数据目录。modsecurity中持久存储文件可能比需要的大，因为旧条目只有在过期时才会被覆盖。默认过期时间是3600秒，这通常太多了，您可能需要几分钟的数据，所以可以使用SecCollectionTimeout指令减少默认超时。

 

原文：https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-performance-recommendations/

本文:http://pub.intelligentx.net/modsecurity-performance-recommendations

讨论：请加入知识星球或者小红圈【首席架构师圈】