最近帮几个朋友排查 WordPress 站点卡顿和 CPU 飙高的问题绕来绕去最后都指向同一个文件xmlrpc.php。WordPress 站点被入侵、被刷爆、被当作肉鸡的案例里这个文件出现频率高得吓人。很多人连它是干嘛的都不知道更别说主动去关了。这篇文章不教怎么攻击别人而是从防御者的角度把 xmlrpc.php 的原理、攻击者常用的利用思路、自查方法和加固方案拆开讲清楚。无论你是个人站长、外贸建站还是公司里负责 WordPress 运维的人都值得花十分钟把这篇文章看完然后去检查一下自己的站点。1. xmlrpc.php 到底是什么1.1 一个存在了二十多年的远程遥控接口XML-RPC 是一种诞生于上世纪九十年代末的远程调用协议简单说就是用 HTTP 请求传一段 XML 格式的指令服务器执行完再把结果用 XML 包回来。WordPress 从很早的版本就内置了这个能力而 xmlrpc.php 就是整个协议的具体入口文件。它的本意是好的早期没有好用的网页编辑器写博客的人喜欢用 Windows Live Writer 这类离线客户端通过 xmlrpc.php 远程发布文章。后来 Trackback、Pingback 这两个站与站之间的互相通知机制也走这个接口。再往后WordPress 手机 App、Jetpack 插件、甚至部分自动更新流程也会用到它。也就是说这个文件承担了大量站外访问站内的功能。问题在于它默认开启而且很多站长压根不知道自己网站一直开着这样一个接口。你说的每一句话它都能听懂攻击者发的每一段恶意 XML它也会照单全收。1.2 为什么安全报告里总有它的名字xmlrpc.php 被盯上不是因为代码写得有多烂而是因为它太适合当突破口了。第一它是一个公开的功能入口不需要什么特殊权限就能访问。攻击者不需要先找到后台登录地址只要往你的域名后面加个 /xmlrpc.php就能开始对话。第二它支持把大量操作塞进一个请求里。XML 报文的可扩展性太强了一个请求里可以嵌套几百上千个子操作。这对暴力破解来说等于开了加速器同时又绕过了很多只看请求频率的安全插件。第三它里面的部分方法本身就存在可以被滥用的设计。比如 Pingback 方法设计初衷是通知别人你引用了他的文章但它实际上会让服务器主动去访问攻击者指定的任意网址。这个特性被玩出了花扫内网、探端口、拉黑名单。哪怕没有新的 CVE光是基于这些默认特性和历史漏洞组合出的攻击手法也足够让一堆不做安全加固的站点吃大亏。我在巡检时见过后台全是陌生作者账号的、数据库被删光勒索的、站点被用来刷别人家接口的根因几乎都能追到 xmlrpc.php 这个入口上。2. 站在攻击者视角四类典型手法拆解2.1 用户名枚举先摸清你的前台都有谁攻击者做暴力破解之前第一步往往是确认哪些用户名真实存在。WordPress 有个特点后台登录页通常会提示用户名错误还是密码错误这本身就泄露了信息。而 xmlrpc.php 更直接它提供了 wp.getUsersBlogs 这类需要认证的方法。攻击者会构造一个 XML 请求里面传一个猜测的用户名和一个随便编的密码。如果用户名不存在接口会返回一个类似没有这个用户的错误如果用户名存在但密码错误返回的是密码不正确。两者虽然都在报错但报错的内容不同。就凭这个差异攻击者可以用脚本批量枚举你的用户名把 admin、editor、author 一个个试出来。别小看这一步。很多人的用户名就是拼音或者简单单词比如 zhangsan、admin、fangwen。一旦确认了有效用户名后续撞库和暴力破解就精准多了。而且很多攻击者还会去抓 wp.getUsersBlogs 成功时的返回内容响应里会带上博客名称、用户昵称这些都是社工素材。2.2 system.multicall 把暴力破解打包了传统暴力破解有一个明显的流量特征一秒内几百次登录请求很容易被专门的限制登录插件拦住。但 xmlrpc.php 提供了一个叫 system.multicall 的方法允许把多个子调用打包在一个 HTTP 请求里服务器收到后会逐条执行并逐个返回结果。打个比方普通登录一次只能试一个密码而 multicall 可以在一张纸上写 500 个密码一起交给服务器去试。响应时间变长了一点但请求次数从 500 次降到了 1 次。很多安全插件统计的是单位时间内请求数面对这种打法直接失效。更恶心的是multicall 里每一个子调用都是独立认证的攻击者可以把几万个密码分成很少的几个请求发完。等到你发现服务器 CPU 跑满、数据库连接数爆炸的时候攻击早就结束了。我在日志里见过一个非常典型的案例凌晨两点某个 IP 对 /xmlrpc.php 连发了二十多次 POST每次请求耗时都超过三十秒服务器负载从 1 直接飙到 30。这就是 multicall 在跑暴力破解的典型特征。2.3 Pingback 把服务器变成了内网探针Pingback 的本意是当你的文章引用了别人的文章时WordPress 会去访问对方网站告诉对方有人引用了你。这个访问对方网站的动作是服务器发起的不是浏览器。攻击者如果把这个目标地址换成内网地址比如 http://127.0.0.1:端口/ 或者 http://内网IP:端口/会发生什么你的服务器会老老实实地发起一次内网请求。虽然结果往往被包装成目标网站没有链接到你之类的提示但攻击者可以从响应差异、耗时长短来推断某个内网端口是否开放、某个服务是否存在。这就是典型的 SSRF服务端请求伪造。在云服务器环境里更危险因为实例的元数据服务地址往往是固定的很多攻击脚本会把它作为重点探测目标。xmlrpc 如果开着相当于你把自家服务器的内网探针交到了别人手里。防御角度讲没有任何理由让一个公开站点接口具备向外发起任意请求的能力。2.4 你的站点也可能被别人当反射源除了打你自身xmlrpc.php 还可能被用来攻击别人。原理还是 Pingback攻击者找到一堆开启了 xmlrpc 的 WordPress 站点构造 pingback 请求让这些站点去访问同一个目标地址。因为请求是大量真实服务器发出去的目标站点看到的是几百上千个来自不同 IP 的正常请求很难去封禁。这种攻击不像大流量 DDoS 那样追求带宽它的作用更多是绕防护、隐藏攻击源、消耗对方资源。也可能被用来刷第三方接口的验证码、做账号批量注册。这意味着如果你不关掉自己站点的 xmlrpc.php你的网站就随时可能成为攻击者手里的一颗棋子。你以为自己只是个小博客没人管实际上你的服务器 IP 和带宽都可能正在帮别人干活。3. 自查流程确认你的站点是否暴露3.1 三分钟快速验证接口状态最简单的验证方法就是用 curl 发一个 XML-RPC 请求看看接口是否会正常返回方法列表。注意 GET 请求访问 xmlrpc.php 往往只能说明文件存在判断接口是否真正开放必须发 POST。curl -sS -X POST https://你的域名/xmlrpc.php \ -H Content-Type: text/xml \ --data ?xml version1.0?methodCallmethodNamesystem.listMethods/methodNameparams/params/methodCall如果返回了 HTTP 200 并且响应是一长串 XML里面有 wp.getPosts、pingback.ping、system.multicall 这些方法名说明接口处于开放状态需要处理。如果返回 403、404 或者 405说明已经被服务器层面拦截或禁用问题不大。顺带提醒一句别只测 www 域名。我遇到过主站关了但二级域名、临时域名上还跑着旧版本 WordPress 的情况xmlrpc.php 照样开放。全域名扫一遍更稳妥。3.2 access log 里隐藏的攻击痕迹光看接口开没开还不够得确认是否已经被利用过。SSH 登录服务器检查 Web 服务器的访问日志。grep xmlrpc.php /var/log/nginx/access.log | tail -n 50重点看几个特征请求频率如果同一个 IP 短时间内频繁 POST /xmlrpc.php大多是在跑枚举或暴力破解。请求体内容日志里看不到完整 XML但可以从 User-Agent、响应字节数、响应状态码做初步判断。恶意请求的 UA 常被伪造成搜索引擎爬虫或者干脆为空。响应状态码大量 200 响应且响应体很大说明接口正常处理了请求危险度高大量 403 说明拦截规则已经在生效。请求时间分布暴力破解通常是深夜或者凌晨服务器负载高峰与日志中的 xmlrpc 请求时间段吻合的话基本可以确认被打过。如果日志里出现了很多POST /xmlrpc.php HTTP/1.1 200并且服务器配置了 PHP 慢日志还应该去翻一下 PHP-FPM 的 slow log看看是不是有请求长时间执行、占满了进程。我处理过的一个案例就是PHP-FPM 子进程全部卡在 xmlrpc 请求上整个网站打不开表面看像数据库挂了实际是 xmlrpc 被刷爆了。4. 加固方案禁用、拦截与白名单控制4.1 彻底禁用插件、代码、服务器三选一如果你的站点没有使用 Jetpack、手机 App 远程发布这些依赖 xmlrpc 的功能最简单的方案就是彻底禁用它。三种方式按你的技术水平选。方案一插件禁用。装一个 Disable XML-RPC 之类的安全插件激活后自动关闭 xmlrpc 的所有方法。这种方式零代码适合新手。不过插件多了会增加维护成本安全插件之间还可能冲突我一般只在帮客户快速处理时用。方案二在当前主题的 functions.php 里加一行代码。add_filter( xmlrpc_enabled, __return_false );这一行代码在 WordPress 加载时就会把 xmlrpc 功能整个关闭。优点是干净、不依赖第三方插件升级主题后需要重新添加。也可以做成一个自定义功能插件这样不受主题更换影响。方案三在服务器层面直接拦截。Nginx 环境在 server 配置块里加location /xmlrpc.php { deny all; }Apache 环境在站点根目录的 .htaccess 里加Files xmlrpc.php Require all denied /Files服务器层面拦截最大的好处是请求根本到不了 PHP 解析阶段不消耗应用资源。喜欢隐身效果的可以把 deny all 换成 return 404让攻击者以为文件不存在。我个人更推荐返回 403因为语义明确方便自己排查日志。4.2 需要保留时按来源控制而不是全开有些站点确实离不开 xmlrpc最常见的就是 Jetpack 连接。Jetpack 的部分通信走的就是 xmlrpc如果你全关站点和 Jetpack 服务器的连接会断后台一堆功能报错。这种场景下建议采用白名单思路而不是保持全开状态。Nginx 里可以配合判断来源做精细化控制location /xmlrpc.php { allow 192.0.64.0/18; # 这里填可信来源的 IP 段 deny all; }需要说明的是如果站点套了 CDN 或反代来源 IP 会变成 CDN 节点 IP直接按 IP 白名单可能会误伤或失效。这种情况需要借助 CDN 提供的真实客户端 IP 字段来做判断比如 Cloudflare 可以按 CF-Connecting-IP 头配合 WAF 规则控制。另外一个折中做法是保留 xmlrpc 但移除最危险的方法。在 functions.php 里加过滤代码只关闭 Pingback 和 Trackbackadd_filter( xmlrpc_methods, function( $methods ) { unset( $methods[pingback.ping] ); unset( $methods[pingback.extensions.getPingbacks] ); unset( $methods[trackback.ping] ); return $methods; } );这个方法挡住了 SSRF 和反射攻击但用户名枚举和暴力破解仍然可能发生。所以如果选了这条保留路线必须配合强密码和登录限制插件。4.3 顺手做好的基础安全配置关闭 xmlrpc 只是 WordPress 安全里的一环。我在巡检时发现很多站点的漏洞不是单独存在的而是多个基础问题叠加。既然动手加固了建议把下面几件事也一起做完。更新一切WordPress 核心、主题、插件都要保持最新。很多攻击脚本扫到旧版本直接就打连试探都省了。清理账号删除不用的管理员账号不要保留用户名为 admin 的账号这等于把一半暴力破解的功夫省了。开启登录保护安装 Limit Login Attempts 这类插件限制 IP 登录失败次数。虽然挡不住 multicall 那种打包请求但至少能拦一部分脚本。修改默认后台路径通过插件或转发规则把 /wp-admin 改掉减少自动化脚本的命中率。做好文件和数据库备份云服务器上定时快照数据库每天异地备份。真被搞了还有后悔药吃。5. 实操中的常见问题与避坑记录5.1 关闭 xmlrpc 后 Jetpack、手机 App 用不了怎么办这是我最常被问到的问题。关闭 xmlrpc 后Jetpack 可能在站点状态里报连接错误官方手机 App 的远程发布也会失灵。我先建议确认你到底需不需要这些功能很多自建站用户其实只在电脑后台写文章App 里那点功能用不上Jetpack 对于不靠 WP 统计数据的人来说价值也没有想象中高。如果确实需要保留就不要搞全部禁用而是按 4.2 里的白名单方案来。另一种思路是转向 WordPress 自带的 REST API也就是 /wp-json 那一套新版官方 App 已经在逐步迁移到 REST API将来对 xmlrpc 的依赖会越来越低。5.2 禁用之后日志反而出现大量攻击记录一些人反馈禁用 xmlrpc 后access log 里关于 xmlrpc.php 的记录反而更多了。这不代表你的加固失效而是攻击脚本仍然在不断扫描定位这个文件。服务器返回 403 或者 404这些请求照样会被记进日志。我一般教大家用状态码过滤来看awk $7 ~ /xmlrpc\.php/ $9 200 /var/log/nginx/access.log | wc -l如果返回 200 的次数是 0说明没有请求真正进入 PHP 执行拦截是有效的。剩下那些 403、404 只是噪音不用焦虑但如果你觉得日志看着烦也可以在 Nginx 日志格式里把对 xmlrpc.php 的访问单独跳过眼不见为净。5.3 常见问题速查表现象可能的原因处理方式curl 发 system.listMethods 返回 200 和一堆方法名xmlrpc 接口全开立即按 4.1 的方式禁用或按 4.2 白名单控制日志中单一 IP 持续 POST /xmlrpc.php状态码 403攻击者仍在扫描已被拦截确认拦截后暂时封禁该 IP观察是否换 IP 继续尝试日志中状态码 200 的 xmlrpc 请求数量很大服务器负载高暴力破解或 multicall 请求正在执行立即禁用 xmlrpc检查后台账户是否被添加、数据库是否有异常写入Jetpack 无法连接站点xmlrpc 被完全禁用改用白名单方式保留 Jetpack 所需的范围或放弃 Jetpack 改用替代统计方案手机 App 无法发布文章xmlrpc 被完全禁用确认 App 是否支持 REST API不支持则按白名单保留站点出现了陌生管理员账号可能通过 xmlrpc 或后台暴力破解成功过删除陌生账号全站改密码禁用 xmlrpc检查核心文件是否有被修改服务器 CPU 峰值与 xmlrpc 请求时间完全重合定向攻击或扫描撞库封 IP、禁 xmlrpc、开启 PHP 慢日志排查后续考虑上 WAF6. 一点个人经验我自己的习惯是新接手的 WordPress 站点第一时间就用 4.1 的 curl 命令探一遍 xmlrpc.php存在就直接禁用绝不给它留开放窗口。不是因为被害妄想而是现实中十次 WordPress 被爆破、被刷、被当跳板七八次都跟它有直接关系。也有过为了图省事只改了后台登录地址、没管 xmlrpc结果隔了两周站点后台就出现陌生账号的教训。那次之后凡是经手的站点禁 xmlrpc 已经成了默认动作。如果你不想每次都上服务器敲命令可以在本地写个脚本定期探测或者用监控工具盯住POST /xmlrpc.php 且状态码为 200这个特征。只要它一天不向攻击者低头你的站点就少了一扇大门。