WordPress 的 XML-RPC 攻击可能会产生数千个垃圾请求，尝试暴力破解密码，并消耗服务器资源。攻击目标通常是 xmlrpc.php——这是一个内置端点，允许兼容的应用程序与 WordPress 进行远程通信。.
虽然阻止所有请求可能会减少滥用行为，但也可能中断合法的集成。本指南将介绍如何识别可疑活动、安全地限制 XML-RPC，以及如何判断真正的问题是应用程序安全问题还是托管限制。.
什么是 WordPress XML-RPC？
XML-RPC 是 WordPress 支持的一种远程通信协议。其端点 /xmlrpc.php 接受针对受支持的远程操作的结构化请求。.
WordPress 还提供了 REST API，许多现代应用程序都改用该接口。不过，一些现有的集成方案可能仍然依赖于 XML-RPC。.
因此，正确的安全决策取决于您网站的集成情况，而不仅仅取决于该端点是否存在。.
为什么攻击者会将xmlrpc.php作为攻击目标？
攻击者可能会利用 XML-RPC 身份验证方法尝试进行未经授权的登录。自动化工具可以反复提交凭据，或利用端点的多调用功能，将多个操作打包到请求中。.
Pingback 功能也被滥用来向其他网站发送不需要的请求。这与成功入侵您的 WordPress 安装情况不同。.
即使是未成功的攻击，也可能导致不必要的 PHP 处理、数据库活动以及冗余的安全日志。.
然而，检测到 XML-RPC 请求并不一定意味着攻击者已经获得了访问权限。应通过调查确定这些请求是恶意的、被拦截的，还是合法应用程序活动的一部分。.
步骤 1：检查是否可以访问 XML-RPC
先从一个简单的 HTTP 请求开始：
curl -i https://example.com/xmlrpc.php请将示例域名替换为您的网站。普通的 GET 请求可能会返回一条消息，指出 XML-RPC 服务器仅接受 POST 请求。.
此响应证实了端点的行为，而非安全漏洞。403响应可能表明存在有意设置的防火墙限制。.
在更改访问规则之前，请确认您的网站是否使用了 Jetpack、旧版移动发布功能，或是其他需要 XML-RPC 的集成方案。.
步骤 2：在服务器日志中识别可疑请求
检查 Apache 或 Nginx 的访问日志，查看是否有针对该端点的重复请求。在典型的 Apache 安装环境中：
sudo grep 'xmlrpc.php' /var/log/apache2/access.log | tail -30不同发行版和主机控制面板之间的路径各不相同。请检查请求频率、响应代码、源地址和时间戳。.
来自多个地址的重复 POST 请求可能表明存在自动化滥用行为。不过，在未核查相关集成之前，请避免将每个请求都视为恶意请求。.
将可疑流量与 PHP 工作进程利用率、错误日志和应用程序响应时间进行关联分析。.
步骤 3：在不需要时阻止 XML-RPC
如果您的网站不需要 XML-RPC，那么在 Web 服务器或防火墙层封锁该端点，即可防止请求到达 WordPress。.
Apache 配置
对于支持相关指令的 Apache 安装，限制示例如下：
Require all denied在适当的服务器配置或允许的 .htaccess 环境中应用该规则。随后请验证语法并测试网站。.
Nginx 配置
在相应的 Nginx 服务器块中，可以配置一个限制性 location：
location = /xmlrpc.php {
deny all;
}使用以下方法验证配置： nginx -t 在重新加载 Nginx 之前，请确认目标虚拟主机已接收该规则。.
这些示例不仅会阻断攻击，还会阻断合法的 XML-RPC 流量。在未检查兼容性之前，请勿应用这些示例。.
第 4 步：保留必需的集成
如果某项集成需要使用 XML-RPC，请考虑采用更精细的控制措施，而不是完全封锁该端点。.
可采取的措施包括限制身份验证尝试次数、在可行的情况下限制受信任的源地址，以及应用经过仔细测试的WAF规则。.
WordPress 还提供了过滤器，开发人员可以利用这些过滤器禁用 XML-RPC 身份验证方法。不过，禁用身份验证并不等同于移除所有的 XML-RPC 功能。.
在部署前，请在测试环境中测试变更。我们的 WordPress 测试站指南 介绍了如何评估插件和服务器变更，而不会立即影响生产环境。.
第 5 步：配置 Cloudflare 或其他 WAF
Web应用防火墙可以在可疑请求到达源服务器之前对其进行检查并加以限制。.
对于使用 Cloudflare 的网站，请审查安全事件，并根据端点、请求方法和观察到的流量模式制定范围狭窄的规则。.
一刀切的挑战或封锁可能会干扰合法的远程发布工具。请仔细测试例外情况，并避免信任容易被伪造的用户代理字符串。.
速率限制可以减少滥用请求的数量，但阈值设定时必须考虑到合法的自动化操作和共享源地址的情况。.
第 6 步：加强 WordPress 身份验证
阻止 XML-RPC 并不能替代更全面的账户安全措施。攻击者还可以针对常规登录页面或存在漏洞的插件发起攻击。.
请使用强密码且密码要独特，在支持的情况下启用多因素认证，限制管理员权限，并及时更新软件。.
删除未使用的账户，并审查异常登录活动。保持独立备份，并制定有记录的恢复流程。.
我们的 非托管服务器安全检查清单 涵盖了其他服务器加固措施。.
第 7 步：诊断 PHP 工作进程和服务器负载
大量的 XML-RPC 请求可能会增加 PHP 的处理负担，尤其是在请求绕过页面缓存的情况下。.
在出现可疑流量时，监控并发 PHP 工作进程、CPU 使用率、内存压力、响应时间以及防火墙事件。.
我们的 WordPress PHP 工作进程限制指南 解释了为何未缓存的请求会形成队列，从而导致原本运行良好的网站变慢。.
首先应阻止或限制恶意流量。如果不解决攻击源头，仅增加CPU或内存，可能会导致可供处理恶意请求的资源反而增加。.
什么时候应该考虑更换更好的主机服务？
大多数 XML-RPC 问题都可以通过配置、应用程序安全和防火墙控制来解决。当监控显示存在持续的资源限制或管理访问权限不足时，就需要考虑升级主机服务。.
SiteGround 值得考虑用于以WordPress为主的托管和托管服务。. KnownHost 以及 ScalaHosting 为需要更大服务器控制权的网站提供托管型VPS方案。.
Cloudways 为需要灵活基础设施管理的应用程序提供托管云主机服务。.
比较防火墙控制措施、技术支持范围、PHP 资源、备份策略以及安全责任。购买前请核实具体套餐的功能；没有任何主机服务商能保证完全免受攻击。.
对于更广泛的基础设施决策，请了解我们的 托管云主机对比.
常见问题解答
WordPress 的 XML-RPC 是否存在安全漏洞？
并非自动如此。XML-RPC 是一种受支持的接口，但其公开的功能可能会被滥用。风险取决于配置、身份验证安全性以及已安装的软件。.
禁用 XML-RPC 会导致 Jetpack 无法正常工作吗？
这可能会影响依赖于 XML-RPC 的功能。在阻止访问之前，请检查您当前的集成要求并进行测试。.
阻止 XML-RPC 能否阻止所有暴力破解攻击？
不。攻击者可能会将其他身份验证端点作为目标。应保持分层登录保护和应用程序安全。.
最终裁决
应采用基于证据的控制措施来应对 WordPress XML-RPC 攻击。需识别滥用请求，确认集成要求，并在服务器或防火墙层限制不必要的访问。.
当正常流量和安全控制措施仍无法掩盖基础设施的局限性时，应根据实际工作负载和运营需求，对比评估托管主机、VPS 和云解决方案。.
