ModSecurity拦截URI：诊断与精准解决方案

当modsecurity web应用防火墙（waf）错误地拦截包含特定模式（如uri中的`://`）的合法请求时，会导致“not acceptable!”错误。本文将详细指导您如何通过分析apache错误日志，识别并精准禁用modsecurity中导致误判的特定规则，从而在不完全关闭waf功能的前提下解决此类问题，并提供相关注意事项。

ModSecurity是一个强大的Web应用防火墙，旨在保护Web应用程序免受各种攻击。然而，在某些情况下，其默认规则集可能会过于严格，错误地将合法请求识别为潜在威胁，从而导致“Not Acceptable!”（HTTP 406）错误。这尤其常见于请求参数中包含完整URI（如https://example.com/path）时，因为://这样的模式可能被某些XSS或SQL注入规则误判。

1. 诊断ModSecurity错误：定位核心问题

解决ModSecurity误判的第一步是准确识别是哪条规则导致了拦截。简单地看到“Not Acceptable!”错误页面或JavaScript中的Ajax错误提示（如Uncaught Error.\nMod_Security）并不能提供足够的诊断信息。

关键步骤：检查Apache错误日志。

ModSecurity的详细拦截信息通常记录在Apache的错误日志中。这些日志文件的位置可能因服务器配置而异，常见路径包括：

• /var/log/apache2/error.log (Debian/Ubuntu)
• /etc/httpd/logs/error_log (CentOS/RHEL)
• $HOME/logs/apache.error.log (某些共享主机环境)

在错误日志中，您需要查找包含“ModSecurity: Access denied”字样的条目。一个典型的ModSecurity错误日志条目可能如下所示：

[Fri Nov 19 08:35:22.757764 2021] [:error] [pid 16443:tid 140407413257984] [client 192.168.1.1] [client 192.168.1.1] ModSecurity: Access denied with code 403 (phase 2). Pattern match ""] [severity "CRITICAL"] [tag "CWAF"] [tag "XSS"] [hostname example.com] [uri "/lus.php"] [unique_id "YZdTulJinXUAAEA7KdcAAABC"]

从上述日志条目中，我们需要关注以下几个关键信息：

• Access denied with code 403: 表明请求被ModSecurity拦截，返回HTTP 403 Forbidden状态码。
• Pattern match "
• [id "212620"]: 这是ModSecurity规则的唯一标识符。这是解决问题的关键信息。
• [msg "WAF: Cross-site Scripting (XSS) Attack"]: 提供了规则拦截的原因，例如XSS攻击、SQL注入等。
• [file "/etc/modsecurity/07_XSS_XSS.conf"]: 指明了触发规则所在的配置文件。

通过分析这些信息，我们可以明确是哪条规则（ID为212620）因为检测到类似XSS攻击的模式而拦截了请求。

2. 解决方案：精准禁用特定ModSecurity规则

一旦确定了导致误判的ModSecurity规则ID，最直接且推荐的解决方案是在.htaccess文件或服务器配置文件中精准禁用该规则。

WeShop唯象

WeShop唯象是国内首款AI商拍工具，专注电商产品图片的智能生成。

下载

在您的网站根目录下的.htaccess文件中添加以下指令：

# .htaccess

    SecRuleEngine On
    SecRuleRemoveById 212620

说明：

• : 这是一个条件块，确保只有在ModSecurity模块加载时，内部指令才会被处理，避免在没有ModSecurity的环境中引发错误。
• SecRuleEngine On: 确保ModSecurity引擎是开启的。
• SecRuleRemoveById 212620: 这条指令将禁用ID为212620的ModSecurity规则。请务必将212620替换为您在错误日志中找到的实际规则ID。

注意事项：

• 安全性考量： 禁用ModSecurity规则会降低服务器的安全性。在禁用任何规则之前，请务必确认被拦截的请求确实是合法且无害的。如果可能，应优先考虑调整应用程序代码，使请求不再触发ModSecurity规则，而不是直接禁用规则。
• 规则粒度： 强烈建议使用SecRuleRemoveById来禁用特定的规则，而不是使用SecFilterEngine Off或SecRuleEngine Off来完全关闭ModSecurity。完全关闭ModSecurity会使您的网站暴露在各种Web攻击之下。
• 配置位置： 理想情况下，这些规则应在主服务器配置文件（如httpd.conf或虚拟主机配置）中进行管理，因为.htaccess文件可能会带来性能开销，并且在某些共享主机环境中可能无法完全生效或被禁用。如果您无法修改主配置文件，.htaccess是次优选择。
• 重启/重载Apache： 在某些服务器环境下，修改配置文件后需要重启或重载Apache服务才能使更改生效。

3. 常见尝试与分析

在面对ModSecurity问题时，开发者通常会尝试多种方法。以下是对一些常见尝试的分析：

• 尝试1：完全关闭ModSecurity (SecFilterEngine Off) 虽然这可以解决问题，但如前所述，它会使您的网站完全失去ModSecurity的保护，风险极高，不推荐。

• 尝试2：对URI进行编码 (encodeURI())

  "LU": encodeURI($("#LongURI").val())

  并配合PHP端的urldecode()。这种方法有时有效，但ModSecurity通常会在处理请求时对参数进行解码或部分解码，然后才应用其规则。因此，即使客户端进行了编码，如果ModSecurity的规则匹配的是解码后的内容，或者其模式足够复杂以识别编码后的恶意载荷，编码也可能无法绕过拦截。

• 尝试3：将GET请求改为POST请求 从GET改为POST有时可以绕过针对GET请求的特定ModSecurity规则。然而，如果POST请求仍然导致HTTP 500错误（Internal Server Error），这可能意味着：

  • 存在针对POST请求的ModSecurity规则被触发。
  • PHP代码在处理POST数据时出现了问题。
  • 服务器的其他配置（如PHP的post_max_size或upload_max_filesize）限制了POST数据的大小。 在这种情况下，同样需要检查Apache错误日志和PHP错误日志，以获取更详细的500错误信息。

• 尝试4：排除.htaccess中的重写规则 重命名或移除.htaccess文件以排除重写规则的影响是一个很好的诊断步骤。如果问题依然存在，则表明问题与重写规则无关，进一步确认了ModSecurity是主要原因。

总结

当您的Web应用程序因ModSecurity而遭遇“Not Acceptable!”错误时，最有效的诊断方法是深入检查Apache错误日志。通过识别日志中[id "XXXXXX"]所示的特定规则ID，您可以精准地使用SecRuleRemoveById指令在.htaccess或服务器配置中禁用该规则，从而解决误判问题。在执行此操作时，务必权衡安全风险，并优先考虑通过调整应用程序代码来避免触发WAF规则，以维护网站的整体安全性。