ModSecurity CRS 4.2.0版本中ActivityPub推送请求的误报问题分析

在ModSecurity核心规则集（CRS）4.2.0版本发布后，用户在使用Friendica等支持ActivityPub协议的联邦社交网络服务时，发现大量针对/inbox端点的POST请求被错误拦截。这些请求触发了多个安全规则的误报，包括941100、932130、932260等规则。本文将从技术角度分析这一现象的原因和解决方案。

问题背景

ActivityPub是W3C推荐的去中心化社交网络协议标准，它定义了服务器间通过HTTP POST请求交换活动流数据的方式。在联邦社交网络中，服务器通过/inbox端点接收来自其他实例的活动推送。这些推送通常包含JSON格式的活动数据，并带有数字签名以确保消息完整性。

误报触发机制分析

从日志中可以观察到，误报主要发生在以下几个场景：

1. 签名值检测误报：RSA签名值中包含的随机字符串被误认为Unix命令注入。例如，签名值中的"enVTCsH"片段触发了932235规则，因为它包含了"tcsh"子串。

2. 内容文本误报：用户生成的内容中包含的技术术语或常见短语被误判为攻击。例如：

   • "search engine"触发了PHP配置指令检测(933120)
   • HTML中的分号和引号触发了Windows命令注入检测(932370/932380)

3. 用户名误报：包含"PowerShell"的用户名触发了Windows PowerShell命令检测(932120)

技术原理分析

这些误报的根本原因在于：

1. 签名值的随机性：RSA签名生成的Base64编码字符串具有高熵特性，可能包含各种安全规则定义的危险模式子串。

2. 用户内容的不可预测性：联邦社交网络允许用户自由发布内容，这些内容可能包含技术术语、代码片段或特殊符号组合。

3. 规则匹配的严格性：CRS的部分规则在PL1级别采用宽松的子串匹配策略，缺乏上下文感知能力，导致在非攻击场景下也容易触发。

解决方案建议

对于运营联邦社交网络实例的管理员，可以采取以下措施：

1. 针对性排除规则：为/inbox端点创建专门的规则排除策略，避免检查签名和内容字段。例如使用ctl:ruleRemoveTargetByTag指令排除特定参数的检查。

2. 内容类型白名单：针对application/activity+json和application/ld+json内容类型调整检查策略。

3. 规则调整：对于长期运营的实例，可以考虑将部分规则移至更高严格级别(PL2+)，或自定义调整正则表达式以减少误报。

长期改进方向

从CRS项目角度，这类问题提示我们需要：

1. 协议感知检测：增强对ActivityPub等特定协议的理解，在解析阶段就能识别出签名等特殊字段。

2. 上下文相关规则：开发能够区分用户生成内容与潜在攻击载荷的检测逻辑。

3. 联邦社交网络专项规则集：考虑为这类应用场景开发专门的规则子集，平衡安全性与可用性。

总结

ModSecurity CRS作为通用的Web应用防火墙规则集，在面对ActivityPub这样的特殊协议时，其通用检测逻辑可能导致较高的误报率。管理员需要通过合理的配置调整来适应这类场景，同时也期待未来版本能够更好地支持新兴的Web协议和应用模式。理解这些误报背后的技术原理，有助于我们更精准地配置WAF规则，在保障安全的同时确保服务的可用性。