当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. Mod_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 "<script\\b" at REQUEST_URI. [file "/etc/modsecurity/07_XSS_XSS.conf"] [line "65"] [id "212620"] [rev "3"] [msg "WAF: Cross-site Scripting (XSS) Attack||webs.ccnorte.es|F|2"] [data "Matched Data: <script found within REQUEST_URI: /panel/?q=\x22><script>alert(1)</script>"] [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 "zuojiankuohaophpcnscript\\b" at REQUEST_URI: 指示了触发规则的具体模式和位置。在本例中，是REQUEST_URI中匹配到<script。
- [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文件或服务器配置文件中精准禁用该规则。
在您的网站根目录下的.htaccess文件中添加以下指令：
# .htaccess
<IfModule mod_security2.c>
SecRuleEngine On
SecRuleRemoveById 212620
</IfModule>说明：
- <IfModule mod_security2.c>: 这是一个条件块，确保只有在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规则，以维护网站的整体安全性。
