在 WordPress 安全防护的实践中，XML-RPC 接口的暴力破解攻击是一个持续存在的威胁。传统的检测方案通常聚焦于请求频率或失败次数的单一维度，但有一种更为隐蔽的检测视角 —— 缓存命中率异常，却往往被忽视。本文将深入探讨如何通过 xmlrpc.php 请求的缓存命中率变化，构建一套针对暴力破解攻击的异常检测体系。
XML-RPC 暴力破解的放大原理
WordPress 的 XML-RPC 接口位于站点根目录的 xmlrpc.php 文件，它支持远程发布、pingback 以及最为关键的 system.multicall 方法。system.multicall 允许客户端在单个 HTTP 请求中封装多个方法调用，这意味着攻击者可以在一次请求中尝试成百上千个不同的用户名密码组合。与传统的针对 wp-login.php 的暴力破解不同，XML-RPC 的多调用机制具有明显的放大效应：攻击者用极少的网络请求即可产生巨量的登录尝试，这种特性使其成为大规模自动化攻击的首选路径。
正常情况下，WordPress 站点对 xmlrpc.php 的请求具有一定的规律性。使用移动端应用远程发布内容、第三方 pingback 服务回调、以及少量的 API 调用构成了主要流量来源。这些请求的响应通常可以被缓存层（如 Nginx 的 fastcgi_cache、Varnish 或 CDN）部分或完全命中，从而降低后端处理压力。然而，当攻击者发起暴力破解时，请求模式会发生根本性变化，这种变化会直接反映在缓存命中率这一指标上。
缓存命中率作为攻击检测指标的逻辑
缓存命中率之所以能够有效指示暴力破解攻击，源于攻击流量与正常流量在请求特征上的本质差异。正常用户的 xmlrpc.php 请求通常包含完整的认证信息（如用户名和有效凭证），服务器在验证通过后会返回一致的响应内容，这类响应具有很高的缓存复用价值。攻击者发送的请求则截然不同：每个请求携带的凭证组合都是独特的，验证必然失败，服务器返回的错误响应也各不相同。由于缓存键通常包含请求参数的哈希值，大量失败的登录尝试几乎不会产生缓存命中，导致缓存命中率急剧下降。
具体而言，正常运营的 WordPress 站点在闲时可能观察到 50% 至 70% 的 xmlrpc.php 请求缓存命中率，这一数值基于重复的认证会话刷新和 pingback 请求。当暴力破解攻击发生时，请求量可能暴增数倍甚至数十倍，而缓存命中率可能骤降至 5% 以下。这种断崖式下跌是一个非常强烈的信号，因为它不仅反映了请求数量的异常，更反映了请求性质的异常 —— 大量独特的、必然失败的登录尝试正在冲击服务器。
工程实现：多维度检测体系构建
基于缓存命中率异常检测的攻击识别系统需要在三个层面建立监控能力：缓存层指标采集、请求模式分析、以及响应特征关联。在缓存层面，需要为 xmlrpc.php 端点配置独立的缓存键标识，确保能够单独统计该接口的命中与未命中次数。对于使用 Nginx fastcgi_cache 的场景，可以通过设置特定的缓存区域（如 fastcgi_cache_path /var/cache/xmlrpc levels=1:2 keys_zone=xmlrpc_cache:10m）并为 xmlrpc.php 请求设置独立的缓存键前缀来实现隔离统计。
检测阈值的选择需要基于站点的历史基线。建议采集过去七至三十天的 xmlrpc.php 缓存命中率数据，计算均值与标准差。常见的报警策略是将缓存命中率低于均值减去两个标准差作为触发条件，同时结合绝对阈值（例如缓存命中率低于 20%）作为二级保护。对于日均请求量超过一万次的站点，可以引入请求速率作为辅助判断：一旦单 IP 在一分钟内的 xmlrpc.php 请求超过十个，且缓存命中率低于 30%，即可触发高危告警。
进一步细化检测规则需要解析 XML-RPC 请求的内部结构。system.multicall 方法调用会包含多个 methodCall 元素，每个元素代表一次独立的登录尝试。通过在应用层（如通过 ModSecurity 规则或自定义 PHP 中间件）解析请求体，可以统计单个 XML-RPC 请求中包含的尝试次数。当单个请求的尝试次数超过十个（或根据业务场景设定的阈值），且来源 IP 在短时间内发送了多个此类请求时，基本可以判定为攻击行为。配合缓存命中率异常这一宏观指标，可以有效过滤掉误报 —— 单纯的爬虫扫描可能产生大量请求但未必导致缓存命中率异常，而真正的暴力破解必然伴随缓存命中的急剧下降。
响应策略与参数建议
检测到异常后的响应措施需要兼顾安全性与可用性。推荐的响应流程分为三个层级：第一层级为临时封禁，当单 IP 在五分钟内触发异常检测规则（如缓存命中率低于 15% 且请求速率超过阈值），将其加入临时黑名单，时长设置为十五分钟至一小时；第二层级为深度分析，对进入黑名单的 IP 进行请求特征复盘，确认是否存在 system.multicall 放大模式、请求凭证多样性是否符合暴力破解特征；第三层级为永久防御，如果同一 IP 段在二十四小时内多次触发一级响应，应考虑将整个 /24 或 /16 网段加入长期封禁列表。
在具体参数配置上，以下数值经过实践验证具有较好的平衡性：缓存命中率报警阈值设为基线减去三个标准差，同时不低于 25%；请求速率阈值设为单 IP 每分钟十五次 xmlrpc.php 请求；system.multicall 检测阈值设为单个请求包含超过二十个方法调用；失败登录关联阈值设为单一来源在十分钟内产生超过五十次认证失败。当上述条件满足两项及以上时，触发自动化阻断的概率可达 95% 以上，同时误报率可控制在 5% 以内。
对于完全不需要 XML-RPC 功能的站点，最彻底的防护措施是在 Web 服务器层面直接禁用该接口。Nginx 配置可以通过返回 403 状态码实现：location = /xmlrpc.php {deny all;}。如果业务确实需要 pingback 或远程发布功能，建议通过插件（如 Disable XML-RPC API）仅开放必要的方法，同时保留对 system.multicall 的完全封禁。
监控体系与持续优化
有效的检测体系离不开持续的监控与调优。建议部署基于 Prometheus 或类似时序数据库的监控面板，展示以下核心指标：xmlrpc.php 请求总量与环比增长率、xmlrpc.php 缓存命中率与趋势线、按来源 IP 分布的请求热度图、以及认证失败事件的时间序列。设置 Grafana 告警规则，当缓存命中率在五分钟内下降超过 20 个百分点时发送即时通知。
在优化层面，需要定期更新基线数据以适应业务变化。例如，站点开展营销活动期间可能导致正常的 xmlrpc.php 请求量上升，此时缓存命中率可能自然波动。可以通过引入时间窗口因子（如区分工作日与周末、区分营业时间与非营业时间）来动态调整检测阈值。此外，攻击者的策略也在不断演进，一些高级攻击者会故意在请求中模拟缓存友好的模式以规避检测，这要求检测系统具备机器学习能力或至少保留人工审核通道。
综合来看，通过缓存命中率异常结合请求速率、system.multicall 使用模式、失败登录关联等多维度特征构建的检测体系，能够在攻击早期阶段实现精准识别。与传统的单一阈值报警相比，这种方法具有更低的误报率和更强的抗规避能力，为 WordPress 站点提供了更为可靠的安全保障。
参考资料
- WordPress XML-RPC Brute Force Attacks with Multiple Logins, Wordfence, 2015
- Huge Increase in WordPress xmlrpc.php POST Requests, SAOTN.org