Coraza WAF在APISIX中IP白名单规则失效问题分析与解决方案

问题背景

在使用Coraza WAF与Apache APISIX集成时，安全团队发现一个关键问题：配置的IP白名单规则未能按预期工作。具体表现为，虽然已经设置了针对特定IP地址的放行规则，但来自该IP的请求仍然触发了后续的安全检测规则，导致合法请求被错误拦截。

问题现象

安全团队配置了以下关键规则：

1. IP白名单规则：使用@contains或@ipMatch操作符匹配特定IP，并设置ctl:ruleEngine=Off来关闭对该IP的规则检查
2. 通用防护规则：检测请求URI中的恶意模式

实际运行中发现，即使请求来自白名单IP，系统仍然执行了后续的防护规则，导致403拦截。

深度分析

通过启用SecDebugLogLevel 9调试日志级别，安全专家发现了问题根源：

1. 变量获取异常：调试日志显示REMOTE_ADDR变量值为空，这表明Coraza WAF未能正确获取客户端IP地址
2. 规则匹配失败：由于无法获取IP地址，IP白名单规则自然无法生效
3. APISIX环境特殊性：虽然APISIX本身可以正确获取remote_addr，但该值未能正确传递给Coraza WAF的规则引擎

解决方案

临时解决方案

1. 添加调试规则：通过以下规则验证变量获取情况

   SecRule REMOTE_ADDR "@unconditionalMatch" "id:1200,phase:1,pass,log,msg:'%{MATCHED_VAR_NAME} %{MATCHED_VAR}'"
   

2. 确认环境变量：检查APISIX的file-log插件输出，确认remote_address确实存在且包含正确值

根本解决方案

该问题的本质在于Coraza Proxy WASM组件与APISIX的集成问题。建议采取以下措施：

1. 升级集成组件：确保使用最新版本的Coraza Proxy WASM插件
2. 检查变量映射：确认APISIX的客户端IP变量与Coraza WAF的REMOTE_ADDR变量之间的映射关系
3. 配置验证：在测试环境中使用调试规则验证所有关键变量是否能够正确获取

最佳实践建议

1. 分阶段部署：新规则上线前，先在监测模式下运行，确认规则行为符合预期
2. 多层防护：不要完全依赖IP白名单，应考虑结合其他认证机制
3. 日志监控：建立完善的日志监控机制，及时发现规则异常
4. 变量验证：部署新规则前，先验证所有依赖的变量是否可用

总结

Coraza WAF作为一款强大的开源WAF解决方案，在与APISIX等API网关集成时，需要特别注意环境变量的传递问题。通过本文的分析和解决方案，安全团队可以更有效地部署和管理IP白名单规则，确保安全策略的精准执行。建议遇到类似问题的团队从变量获取这个根本问题入手，逐步排查集成环境中的配置问题。