XMLRPC攻撃対策

WordPressのセキュリティプラグイン「SiteGuard WP Plugin」のログを、ある日ふと見ました。

ロック履歴：6,998件。

__。

桁を数え直しました。

4桁。

普通に4桁。

個人ブログに、なぜそんな数のロックが発生しているのか。

調べてみると、犯人は「XMLRPC攻撃」というやつでした。

名前だけは聞いたことがある、あいつです。

今回は、社内SEの私が、個人ブログのxmlrpc.phpを完全に黙らせるまでの記録を残しておきます。

同じようにロック履歴を見て震えている人の、参考になれば。

ある日気づいた6,998件のロック履歴

事の始まりは、本当に偶然でした。

[INTERNAL_LINK: Power Automate × Claude API でブログ自動化に挑戦した記録]の構築中、WordPressの管理画面をひたすら触っていました。

あの時、403エラーの犯人を探すために、ありとあらゆる画面を開いていたんです。

そして、たまたまSiteGuard WP Pluginの「ログイン履歴」を開きました。

SiteGuard WP Pluginで発見

SiteGuard WP Pluginは、ConoHa WINGなら最初から入っているプラグインです。

有効化されていれば、ログイン試行のログが自動で残ります。

そのログ画面を初めて、まじまじと眺めたわけです。

表示されたのは、ロック履歴6,998件。

日付別の内訳もあって、1日に数十件〜数百件のロックが、コンスタントに発生していました。

私のサイト、そんなにアクセスありましたっけ？

クロに相談したら、即答でこれでした。

ボットからの自動攻撃だ、と。

攻撃元IPの正体

気になって、ロック履歴のIPアドレスをいくつか調べました。

結果はこんな感じです。

• 中国系のIP
• ロシア系のIP
• 東欧系のIP
• たまに国内のVPS

知らない国々から、私の個人ブログに毎日アクセスが来ていた。

国際派ですね。

もちろん、誰も記事を読んでいません。

ただ、ひたすらログインを試みるだけのボット軍団です。

これは普通なのか

正直、最初の感想はこれでした。

「これって、普通なの？」

結論から言うと、普通でした。

普通に普通でした。

WordPressは世界中のWebサイトの40%以上で使われているCMSです。

攻撃側からすると、WordPressを狙うのが効率的。

つまり、WordPressを使っている時点で、攻撃対象リストに自動で入っているわけです。

個人ブログだろうと、企業サイトだろうと、関係なし。

君、そういうとこやで。

XMLRPCとは何か、なぜ攻撃される

そもそも、XMLRPCとは何なのか。

名前は聞いたことがあったんですが、ちゃんと調べたことはありませんでした。

社内SEあるあるです。

業務で関係ないものは、つい後回しにする。

WordPressの古いAPI

XMLRPCは、WordPressに昔から付いているAPIの一種です。

WordPressのルートディレクトリに、xmlrpc.phpというファイルがあります。

このファイルを経由して、外部から記事投稿やコメント取得ができる仕組み。

WordPress 3.5以降は、デフォルトで有効になっています。

つまり、何も設定しないと、誰でもxmlrpc.php経由でWordPressに話しかけられる状態。

本来は、外部ツールや古いブログクライアントが使うためのAPIでした。

今は、もっと新しいREST APIがあります。

つまり、XMLRPCは「過去の遺物」枠に入りつつあるAPIです。

でも、互換性のために残っている。

このへんの「とりあえず残しておく」文化は、業務システムでも見覚えがあります。

ブルートフォース攻撃の標的

では、なぜこのxmlrpc.phpが攻撃されるのか。

理由は、ものすごく実利的でした。

XMLRPCには、複数のメソッドを1リクエストでまとめて送れる「system.multicall」という機能があります。

本来は、効率化のための便利機能。

でも、攻撃側からすると、これがめちゃくちゃ便利な機能になります。

1回のリクエストで、数百〜数千のパスワード試行が可能。

普通のログイン画面（wp-login.php）よりも、効率的にパスワードを総当たりできる。

君、本当にそういうとこやで。

攻撃側からすると、xmlrpc.phpは「効率の良いログイン突破口」なわけです。

放置すると何が起きる

放置した場合のリスクは、大きく3つあります。

• パスワード突破される可能性
• サーバー負荷が上がる
• DDoS攻撃の踏み台にされる

パスワードを複雑にしていれば、突破される可能性は低いです。

ただ、可能性ゼロではない。

あと、突破されなくても、サーバー負荷は確実に上がります。

レンタルサーバーのCPU使用率が、何もしてないのにじわじわ上がっていく現象。

「サイト遅いな」と思ったら、犯人がxmlrpc.phpだった、というのは、わりとある話らしいです。

個人ブログには、xmlrpc.phpは、もう要らない。

これが結論です。

xmlrpc.php を完全無効化する3つの方法

無効化の方法は、調べると何パターンも出てきます。

全部試した結果、現実的なのは3つに絞られます。

順番に書きます。

方法A：SiteGuard WP PluginでON/OFF

一番簡単なのが、この方法。

SiteGuard WP Pluginの「XMLRPC防御」をONにするだけ。

手順はこれだけです。

• WordPress管理画面 → SiteGuard → XMLRPC防御
• 「ピンバック無効化」を「XMLRPC無効化」にチェック
• 「変更を保存」

これで、xmlrpc.phpへのアクセスがブロックされます。

所要時間：1分。

簡単すぎて、逆に不安になります。

方法B：.htaccessで完全拒否

サーバーレベルでブロックしたいなら、.htaccessを使う方法もあります。

WordPressのルートディレクトリにある「.htaccess」に、以下を追記。

<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

これで、xmlrpc.phpへのアクセスはサーバーレベルで403を返します。

WordPress本体に届く前に弾けるので、負荷も軽い。

ただし、.htaccessをいじるのが怖い人にはおすすめしません。

間違えると、サイト全体が落ちます。

私は念のため、バックアップを取ってからやりました。

社内SEなので、サイトを自分で壊した経験が、地味にあります。

__。

方法C：プラグインで対応

専用プラグインを入れる方法もあります。

有名どころは「Disable XML-RPC Pingback」「Wordfence Security」あたり。

ただ、これは個人的にはおすすめしません。

理由はシンプルで、プラグインを増やしたくないから。

プラグインを増やせば、サイトは重くなるし、脆弱性も増えます。

本末転倒です。

すでにSiteGuard WP Pluginが入っているなら、方法Aで充分。

これが私の結論です。

実際にやってみた効果

方法AとBを併用しました。

SiteGuard WP PluginでXMLRPC防御をONにして、念のため.htaccessでも完全拒否。

二重ブロックです。

社内SEとして、冗長性は大事。

導入前後の数字を比較しました。

ロック発生率の変化

SiteGuard WP Pluginのログイン履歴で、ロック件数の推移を比較しました。

項目	対策前（1週間）	対策後（1週間）
ロック件数	約340件/週	0件/週
1日平均	約48件	0件
累計	6,998件	増えず

正確には、攻撃自体は来ています。

ただ、xmlrpc.phpへのアクセスが完全ブロックされているので、ログイン試行に到達しない。

ログイン試行に到達しないから、ロックされない。

静かなものです。

サーバー負荷の変化

ConoHa WINGの管理画面で、CPU使用率を比較しました。

項目	対策前	対策後
CPU平均使用率	約12%	約7%
ピーク値	38%	21%
変動の山	定期的に発生	ほぼ平坦

劇的に変わったわけではありません。

個人ブログなので、もともと負荷が高いわけではない。

でも、グラフを見ると、ピーク値が明らかに減っています。

静かに、効いている感じ。

サイト速度の変化

PageSpeed Insightsで、対策前後を計測しました。

項目	対策前	対策後
モバイルスコア	68	71
デスクトップスコア	89	92
TTFB	0.82秒	0.71秒

体感は変わりません。

でも、数字は確実に良くなっています。

TTFB（サーバー応答時間）が、0.1秒ほど改善。

0.1秒、誤差みたいなものですが、SEO観点だと地味に効きます。

サーバー負荷が下がれば、応答が速くなる。

当たり前のことが、当たり前に起きた、という結果です。

xmlrpc無効化の副作用と注意点

「無効化していいの？」

これが、一番気になるポイントだと思います。

結論は「ほとんどの人は無効化していい」です。

ただし、いくつか影響を受ける機能があります。

順番に書きます。

Jetpackへの影響

JetpackというWordPress公式のプラグインを使っている人は、要注意。

Jetpackの一部機能（統計、自動投稿など）が、xmlrpc.php経由で動いています。

つまり、xmlrpc.phpを完全ブロックすると、Jetpackが部分的に壊れます。

Jetpackを使っているなら、特定IPからのアクセスだけ許可する設定が必要。

ちょっと面倒です。

私はJetpackを使っていないので、関係ありませんでした。

そもそも、Jetpackは多機能すぎて、個人ブログには重い印象です。

あいつ、ちょっと太りすぎなんですよ。

WordPressモバイルアプリ

WordPressの公式モバイルアプリも、一部xmlrpc.phpを使うらしいです。

ただし、最近はREST APIに移行しているので、影響は限定的。

私はモバイルアプリも使っていないので、確認できていません。

使っている人は、無効化前にテストしてください。

個人ブログなら、たぶんブラウザ管理で充分なんですけどね。

影響なし→無効化推奨

逆に、以下に該当する人は、迷わず無効化していいです。

• Jetpackを使っていない
• WordPressモバイルアプリを使っていない
• 外部ツールから記事投稿していない
• ピンバック・トラックバックを使っていない

たぶん、個人ブロガーの9割は、ここに該当します。

該当するなら、xmlrpc.phpは不要。

無効化一択。

ちなみに私の場合、[INTERNAL_LINK: Power Automate × Claude API でブログ自動化に挑戦した記録]で構築したシステムは、REST API経由で動いています。

つまり、xmlrpc.phpを無効化しても、ブログの自動化システムには一切影響なし。

同じ「API」でも、XMLRPCとREST APIは別物。

君だけ、退場してくれ。

私のサイトでの設定例

私の実際の設定を、ここに載せておきます。

SiteGuard WP Plugin

SiteGuard WP Pluginの設定

SiteGuardの設定で、以下にチェックを入れています。
XMLRPC無効化 → ON
悩む必要がありません。

.htaccessの記述

.htaccessには、以下を追記しました。

# xmlrpc.php を完全拒否
<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

記述位置は、WordPress関連ブロックの直前です。

「# BEGIN WordPress」より上に書きます。

WordPress関連ブロックの中に書くと、自動更新時に消える可能性があるためです。

このへんの仕様、地味にハマるポイントです。

知らんて。

動作確認

設定後、動作確認をします。

確認方法は簡単。

ブラウザで自分のサイトの「/xmlrpc.php」にアクセスします。

正しく無効化されていれば、403エラー画面が出ます。

「Forbidden」の文字が見えたら、勝利です。

普段は嫌いな403エラーが、この時だけは嬉しい。

[INTERNAL_LINK: Power Automate × Claude API でブログ自動化に挑戦した記録]を書いた時は、403に泣かされましたが、今回はその逆。

同じエラーでも、立場で見え方が変わる。

社内SEあるあるです。

攻撃に気づくきっかけがなかった怖さ

今回、振り返って一番怖いのは、攻撃そのものじゃありません。

「気づいていなかった」事実です。

SiteGuard WP Pluginのログを開いたのは、Power Automateで403エラーが出たから。

つまり、ブログ自動化の構築をしていなかったら、6,998件のロックを知らないまま、ブログを運営し続けていたわけです。

これは、社内SE的に、わりとゾッとする話です。

業務システムなら、定期的にログ監視するのが当たり前です。

でも、個人ブログだと、誰も監視していない。

誰も監視していないから、攻撃に気づかない。

気づかないから、対策しない。

対策しないから、攻撃され続ける。

このループ、地味に怖い。

クロの言うとおりでした。

個人ブログでも、無差別攻撃の対象になる。

むしろ、対策が薄い個人ブログの方が、狙われやすい。

業務システム並みのセキュリティは要らない。

でも、最低限の対策はやっておくべきだな、と思いました。

まとめ：個人ブログにXMLRPCは不要

今回の話をまとめます。

• SiteGuard WP Pluginのログで6,998件のロックを発見
• 原因はxmlrpc.phpへのブルートフォース攻撃
• 個人ブログにxmlrpc.phpは、もう要らない
• SiteGuard + .htaccess で完全ブロック
• 対策後、ロックはゼロ、サーバー負荷も低下

所要時間は、設定だけなら10分。

動作確認まで含めても、30分かかりません。

コストはゼロ。

業務システムなら、ありえない費用対効果です。

個人ブログだからこそ、まずやるべき対策と言えるかもしれません。

もし、これを読んでいるあなたが、SiteGuard WP Pluginのログを一度も見ていないなら。

今すぐ、見てきてください。

4桁のロック履歴が、待っているかもしれません。

__。

余談ですが、ブログ自動化システムの構築をしていなければ、私もこの攻撃に気づきませんでした。

本来の目的とは違うところで、ブログを守ることになった。

結果オーライです。

業務効率化のために動いたら、副産物でセキュリティが強化された。

社内SEっぽい結末ですね。