本記事はXML RPCの無効化という一点に絞り 攻撃の入口を減らす具体策をについて記載いたしました。
対象は制作会社の担当者 個人事業の運用者 社内の情シスなどすべてのWordPress運用者です。
読了後、今日やること 明日から続けること 影響確認の手順までを安全に実行できます。
■ 現状の課題
XML RPC＝外部アプリからWordPressに命令を送る古い仕組みです。
今も総当たりのログイン試行とピンバック悪用の起点になりやすい入口です。
多くのサイトでは利用がなく 使わない入口を開けたままになっています。
■ 結論
使っていないなら閉じるが正解です。
閉じる前に本当に不要かを確認し 仮停止で影響を見てから本停止に進めます。
二要素認証やパスキーと組み合わせると入口対策の効果が安定します。
■ 最短フロー
不要確認
・外部投稿アプリや古い連携を使っていないかを点検する
・Jetpackや外部監視でXML RPC依存が残っていないか運用記録で確認する
仮停止
・セキュリティプラグインの機能やサーバの一時ルールでxmlrpc.phpへのアクセスを遮断する
・管理者と編集者で投稿や画像アップロード 予約投稿の動作を試す
本停止
・サーバ側の常設ルールでxmlrpc.phpを拒否する
・WAFやレート制限でログイン試行の連続アクセスも合わせて抑制する
監視開始
・アクセスログでxmlrpc.phpへのアクセス数を毎日または週次で記録する
・急増時は遮断が効いているかと別の入口の有無を併せて確認する
■ 運用
・半年に一度 不要連携の棚卸しを実施する
・新しい連携はREST APIの利用とアプリケーションパスワードの最小権限を標準にする
・管理者は二要素認証とパスキーを必須にする
・ログのしきい値を決め 超過時は通知する
■ 失敗しやすい点
・過去の外部投稿アプリの存在を見落とす
・仮停止をせず本停止して現場の更新が止まる
・遮断後の確認をログイン画面だけで終えてしまう
・記録を残さず同じ調査を繰り返す
■ FAQ
Q XML RPCを止めると何が困る
A 外部投稿アプリや古い連携が動かない可能性がある 事前に利用有無を確認します
Q Jetpackは使えるのか
A 多くの機能は動くことが多い ただし環境差があるため仮停止で実機確認が安全です
Q 例外的に必要な場合の対処は
A 許可元のIP制限と回数制限を重ねる 可能ならREST APIへの切り替えを検討します
Q 効果をどう測る
A xmlrpc.phpへのアクセス数とログイン失敗回数の推移を記録し 前後比較で評価します
Q なぜパスキーを勧めるのか
A パスキーはフィッシング耐性が高く 使い回しや漏えいリスクを下げられるため
■ まとめ
使わない入口は閉じる これが攻撃面を減らす最短の一手です。
XML RPCを仮停止で確認し 本停止と監視で固め 二要素認証とパスキーで入口をさらに強化します。
小さな入口の削減が復旧コストの削減につながります 今日から着手してください。
