WordPressのXML-RPCを無効化する方法とは？リスクと正しいセキュリティ対策を徹底解説

WordPressのXML-RPCを手っ取り早く無効化したいとお考えですか？その前に、なぜ無効化したいのか、その理由を一度立ち止まって考えてみましょう。

おそらく、次のような疑問もお持ちではないでしょうか。

• xmlrpc.phpとは何か？
• どれほどのセキュリティリスクがあるのか？
• xmlrpc.phpを無効化すれば脅威は自動的に解消されるのか？

この記事では、これらの質問にすべてお答えします。

要点：WordPressでXML-RPCを無効化することは、根本的な解決策ではありません。遅かれ早かれ、ハッカーは別の脆弱性を見つけて攻撃してきます。ボットや悪意あるIPアドレスをブロックするためには、強力なWordPressファイアウォールを導入することをおすすめします。

あなたのサイトはXML-RPCのせいでハッキングされている？

結論から言えば、いいえ。

実際に起きているのは、ハッカーがユーザー名とパスワードの組み合わせを総当たりで試し、サイトへのアクセスを試みている状態です。しかし慌てる必要はありません。まだサイトが乗っ取られたわけではありません。

ほぼすべてのサイトでこの種のアクセスは発生しています。強力なパスワードを使用していれば、この攻撃によってハッキングされる可能性はごくわずかです。私たちが確認した10,000件以上のハッキング被害サイトのうち、この種の攻撃が原因だったのは5%未満でした。

ただし、こうした攻撃（ブルートフォース攻撃と呼ばれます）はサーバーリソースを大量に消費します。ログインページや管理ページを保護していても、これらの攻撃はそれらのページを完全に回避してくるため、サーバーに過負荷がかかる原因となります。

これを防ぐためには、信頼できるファイアウォールの導入が重要です。

XML-RPCとは何か？

XML-RPCは、WordPressと他のシステム間でデータをやり取りするための機能です。現在ではREST APIにほぼ置き換えられていますが、後方互換性のためにインストール環境には依然として含まれています。

XML-RPCにより、サードパーティ製アプリからWordPressサイトへコンテンツを公開できます。たとえば、スマートフォンのWordPressモバイルアプリから記事を投稿する際、この通信を可能にしているのがXML-RPCです。

それだけではありません。WordPressは他のブログプラットフォームとの通信にもXML-RPCを使用しており、トラックバックやピンバックもこの仕組みによって実現されていました。

さらに、旧バージョンのJetpackプラグインもXML-RPCを利用していました。

通常、WordPressはモバイルアプリとの接続にXML-RPCを使います。WordPressモバイルアプリを使ったことがあれば、XML-RPCの有効化が必要だったことを覚えているかもしれません。

意外に思われるかもしれませんが、実は現在のWordPressはXML-RPCをもう使用していません。独自のREST APIがリリースされて以降、古いコードベースの利用は停止されました。

それでもWordPressにxmlrpc.phpファイルが残っている唯一の理由は、後方互換性のためです。平たく言えば、非常に古いバージョンのWordPressで稼働しているサイト向けの機能なのです。

もし古いバージョンをお使いなら、今すぐサイトのバックアップを取り、WordPress本体・テーマ・プラグインを更新することを強くおすすめします。古いバージョンのまま運用することは、xmlrpc.phpへの接続を試みるハッカーよりもはるかに大きなセキュリティリスクになります。

まとめると、WordPressのバージョンが4.7以上であれば、XML-RPCを安全に無効化できます。Jetpackを使用していても影響はありません。ただし、XML-RPCの無効化自体は安全な操作ではありますが、ハッカーからサイトを守る効果はないという点に注意してください。

なぜハッカーはXML-RPCを狙うのか？

WordPressモバイルアプリを使ったことがあれば、変更を加える前にサイトへログインする必要があったことを思い出すでしょう。このログイン時、認証情報はxmlrpc.phpスクリプトに送信され、そこで検証・認証されます。

ハッカーは基本的に同じことを行います。つまり、xmlrpc.phpスクリプトに認証情報を送り込んでサイトへのログインを試みるのです。最大のリスクは、パスワードが弱く推測されやすい場合です。このときXML-RPCはセキュリティ上の問題となります。

そうでなければ、懸念されるのはサーバーの過負荷です。これは決して好ましい状況ではありませんが、ファイアウォールがあれば簡単に対処できます。

REST APIを使って外部アプリと接続するWordPress 4.7以降では、「OAuthトークン」と呼ばれる認証方式を採用しています。OAuthは外部アプリと接続する非常に安全な方法です。一方、XML-RPCがユーザー名とパスワードを直接使用する方式は、安全性とは言えません。

時間さえあれば、ハッカーやボットはユーザー名とパスワードのバリエーションをxmlrpc.phpに送り続け、正しい組み合わせを突き止めようとします。

これが「ブルートフォース攻撃（総当たり攻撃）」です。

XML-RPCのもう一つの重大なセキュリティ問題は、ピンバックに使われていたことです。ピンバックとは、誰かがあなたのコンテンツへリンクした際にWordPressが通知を受け取る仕組みです。脅威となるのは、ハッカーが大量のピンバックをサイトに送り付けるケースです。

この種の攻撃は「DDoS攻撃」と呼ばれ、サーバーに過負荷をかけ、リソースを枯渇させ、最悪の場合ホスティング会社からサイトを停止させられることもあります。

繰り返しますが、この機能もREST APIに置き換えられました。ピンバックがお好きでも、安心してXML-RPCを無効化できます。

万が一自分のサイトが被害を受けている5%に入っていないか心配な方は、無料のマルウェアスキャナーですぐに確認してみてください。

XML-RPCは無効化すべきか？

結論として、私たちはXML-RPCの無効化を推奨しません。

その理由はシンプルです。PHPファイルを無効化してもメリットがないからです。XML-RPCを無効化しても、ハッカーやボットはいなくなりません。彼らの攻撃対象がwp-login.phpへ移るだけで、ブルートフォース攻撃は継続されます。

さらに、無効化用プラグインはリクエストをブロックするために読み込む必要があるため、サイトの表示速度が低下します。

重要なのはサイトを守ることです。ここまで読んでいただければ、私たちがファイアウォールの導入を勧めるだろうと予想できたかもしれません。そうです、その定番の答えです。

WordPressでXML-RPCを無効化する方法

WordPressの設定全般と同様に、XML-RPCの無効化にも2つの方法があります。

• プラグインを使う方法
• プラグインを使わない方法

通常、WordPressでの作業はほとんどの場合プラグインの利用をおすすめします。管理画面からコードを手動で編集すると、深刻なトラブルにつながりかねません。今回は珍しくどちらの方法も推奨しませんが、参考として両方の手順をご紹介します。

作業の際は慎重に進め、必ず事前にサイトのバックアップを取得してください。

ステップ1：サイトでXML-RPCが有効になっているか確認する

WordPressにxmlrpc.phpが含まれていたとしても、現在有効になっているとは限りません。無効化作業に進む前に、まずサイトで有効かどうかを確認しましょう。

「WordPress XML-RPC Validation Service」を利用してください。このツールがサイトをチェックし、xmlrpc.phpが有効かどうかを教えてくれます。

ちなみにMalCareのサイトで同じチェックを行うと、403エラーが表示されます。ファイアウォールが設置されているためです。

ステップ2：サイトでXML-RPCを無効化する

いよいよWordPressのXML-RPCを無効化しましょう。

ここでは2つの方法をご紹介します。ファイルの無効化自体は推奨しませんが、どうしても実行したい場合はプラグインの利用をおすすめします。

方法A：プラグインを使う

XML-RPCを無効化できるプラグインは多数あります。ここでは「REST XML-RPC Data Checker」プラグインをおすすめします。

ただし、プラグインはリクエストをブロックするために読み込む必要があるため、サイト速度が低下します。また、ハッカーの攻撃対象はwp-login.phpへ移ります。

つまり、セキュリティ面では何の成果も得られません。本当の保護を求めるなら、MalCareの高度なファイアウォールプラグインの導入をおすすめします。

プラグインをインストールしたら、設定 > REST XML-RPC Data Checker へ移動します。

次に「XML-RPC」タブをクリックします。

APIインターフェース、投稿のフォーマット機能、ピンバック、トラックバックを個別に無効化できます。さらに便利なことに、引き続きXML-RPCを利用できる信頼済みユーザーや、ブロック対象外とする信頼済みIPアドレスのリストを登録することも可能です。

簡単かつ効率的ですね。ただし「REST」タブは触らず、デフォルトのままにしておいてください。

方法B：プラグインを使わない

これは選択肢の中で最も避けるべき方法です。できれば次のセクション（XML-RPC攻撃への実際の防御策）へ進んでください。

それでも手動で無効化したい場合は、必ず事前にサイト全体のバックアップを取得してください。

サイトが稼働しているサーバーの種類に応じて、以下のいずれかの方法を選択します。

.htaccessでWordPressのXML-RPCを無効化する

以下のコードスニペットを.htaccessファイルに貼り付けます。

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>

5行目の「allow from xxx.xxx.xxx.xxx」は、特定のIPアドレスからXML-RPCを利用し続けたい場合に、xの部分を実際のIPアドレスに置き換えてください。不要であれば、この行は削除しても構いません。

Apacheサーバーでホスティングしている場合は、cPanelまたはFTPでサーバーに接続すれば、どちらの方法でも.htaccessファイルにアクセスできます。

Nginx.configでWordPressのXML-RPCを無効化する

Nginxでホスティングしているサイトの場合は、Nginx.configファイルに以下のコードを追加します。

location ~* ^/xmlrpc.php$ {
return 403;
}

または、ホスティング会社に依頼してXML-RPCを無効化してもらうこともできます。

フィルターでWordPressのXML-RPCを無効化する

別の方法として、任意のプラグインにフィルターを追加することもできます。

add_filter('xmlrpc_enabled', '__return_false');

テーマのfunctionsファイルからも同じことができますが、プラグインとして作成する方がはるかに良い習慣です。また、この方法ならサーバーの種類を問わず利用できます。

繰り返しますが、これらの方法はいずれも真の解決策ではなく、手動でのコード変更は決して良いアイデアではありません。どうしても実行する場合は、万一に備えてWordPressのバックアップを必ず準備しておいてください。

XML-RPC攻撃を防ぐには？

ここがこの記事で最も重要なセクションであり、内容も充実しています。そこで、サイトへのXML-RPC攻撃を防ぐために実践できる具体的なステップに分けてご紹介します。

ステップ1：サイトがすでにハッキングされていないか確認する

おそらく、あなたのサイトはまだハッキングされていないでしょう。

しかし、念のため確認は必要です。もし本当にハッキングされているなら、まずマルウェアを除去しなければ、XML-RPCを無効化しても意味がありません。

サイトがハッキングされているかどうかを確認する最も簡単な方法は、MalCareの無料マルウェアスキャナーを使うことです。セットアップは数分で完了し、未知のマルウェアであっても数秒で検出できます。

MalCareでハッキングの警告が表示された場合は、「Autoclean（自動クリーニング）」ボタンを押すだけです。

MalCareなら、マルウェア除去全体を60秒で完了できます。

ステップ2：WordPressファイアウォールを導入する

これこそがXML-RPCの脆弱性への正しい対処法です。xmlrpc.phpへの接続を試みるボットをブロックできるWordPressファイアウォールを使用しましょう。

ファイルを無効化しても意味がありません。ハッカーは単に次はwp-login.phpを狙い始めるだけだからです。

唯一の課題は、一般的なファイアウォールでは対応が遅れてしまうことです。ハッカーがxmlrpc.phpやwp-login.phpに接続しようとするたびに、WordPressサイト全体が読み込まれてしまうのです。

だからこそ、私たちがおすすめするのは次の特徴を持つMalCareの高度なファイアウォールです。

• サイトが読み込まれる前にボットやハッカーを撃退
• Cloudflareのようにサイトの表示速度を低下させない
• 保護する250,000以上のサイトのネットワークから学習し、悪意あるIPのデータベースを常時更新

MalCareで保護されたサイトでは、ボットやハッカーがXML-RPCやWP-Loginに接続しようとしても、403エラーが返されるだけです。このようなエラーは、ハッカーにそれ以上攻撃を続ける気をなくさせる効果があります。

なぜ多くの人はXML-RPCの無効化を勧めるのか？

いくつかの理由があります。それぞれ見ていきましょう。（多少の応急処置であることは承知の上で）なぜこの対応策が推奨されるのか理解できるはずです。

読者の皆さんがWordPressサイトでXML-RPCを無効化したいと考える最大の理由の一つは、サーバーリソースの問題を経験したからです。ログを確認すると、xmlrpc.phpファイルへの大量のアクセス記録を目にしたことがあるかもしれません。

Jetpackを使用していて、インストール時に設定エラーが発生したこともあるでしょう。その奇妙な名前のファイルについて調べ、脆弱性に関連する記事を多数読んだのではないでしょうか。

または、セキュリティスキャナーを使った際に、次のような警告が表示されたのかもしれません。

これはWordfenceのトラフィックログのスクリーンショットです。

セキュリティプラグインが、ボットがWordPressのXML-RPC経由でサイトへの侵入を試みていることを示しています。すると自然と、この機能を丸ごと無効化したいと思うわけです。

やってはいけないことと、その理由

IPアドレスのブラックリスト登録

ハッカーのIPアドレスを手動でブロックすれば良いと考えるかもしれません。実際、多くのセキュリティ「専門家」がこの方法を推奨しています。しかしこれは機能しません。1つのIPアドレスをブロックしても、ブルートフォース攻撃のボットは別のIPアドレスを使って攻撃を続けるだけです。

XML-RPCファイルの削除

WordPressからxmlrpc.phpファイルを削除することは絶対に考えないでください。サイトが完全に壊れる恐れがあります。仮に壊れなかったとしても、次回WordPressを更新すればファイルは元通りに復活します。

次にすべきこと

WordPressのセキュリティ向上は、一度やれば終わりというものではありません。ファイアウォールの導入は素晴らしい第一歩ですが、さらに改善できる点を見つけるために、サイト全体のWordPressセキュリティ監査を実施することをおすすめします。

すでにMalCareを導入しているなら、直感的なダッシュボード内に多くの改善提案が表示されています。セキュリティスキャンを実行し、案内に沿って進めてください。

すぐにわかるように、WordPressサイトのセキュリティを強化することは賢明な投資です。こちらも指示に従うだけで、数クリックで完了します。

セキュリティのもう一つの重要な要素は、常に最新情報を把握しておくことです。

新しいWordPressの脆弱性が発見されたら、自分のサイトに影響が出る前に対策を講じられるよう、速やかに情報を入手する必要があります。

よくある質問（FAQ）

XML-RPCとは何ですか？

XML-RPCは「XML Remote Call Procedure（XMLリモートプロシージャコール）」の略です。HTTP接続とXMLエンコーディングを使用してブログに接続する、旧式のブログシステム向けプロトコルです。簡単に言えば、WordPressなどのブログプラットフォームにリモートで接続することを可能にするプロトコルです。

XML-RPCは何に使われていますか？

XML-RPCは、WordPressモバイルアプリなどのサードパーティ製アプリからWordPressへリモート接続するための手段です。また、トラックバックやピンバックを通じて、誰かがあなたの記事へリンクするたびに通知を受け取る仕組みにも使われていました。

XML-RPCはどうやって無効化できますか？

「REST XML-RPC Data Checker」などのプラグインを使えば無効化できます。ただし、XML-RPCを無効化しても、ハッカーによるWordPressサイトへの侵入試行は止められません。攻撃を食い止めるには、代わりにMalCareの高度なファイアウォールプラグインを導入してください。

CAPTCHAや2段階認証（2FA）を使っていますが、それでもXML-RPC経由でパスワードを破られる可能性はありますか？

CAPTCHAや2段階認証（2FA）プラグインは追加のセキュリティ対策を目的としたものであり、XML-RPCへのハッキングに対する本格的な保護は提供していません。

ほとんどのCAPTCHAおよびWordPress用2FAプラグインは、WordPressのログインページのみを保護し、XML-RPCスクリプトは保護しません。お使いのセキュリティプラグインがXML-RPC経由のログインを防止しているか、必ず確認してください。

悪意あるIPアドレスをブラックリストに登録できますか？

ハッカーのIPアドレスをブロックすれば安全になる——一見すると明白な解決策に思えます。

しかしこの考えには乗らないでください。それはハッカーとの「モグラ叩き」のようなものです。相手はIPアドレスを変えながら、別のIPで攻撃を続けてきます。終わりはありません。

助けになるのは、MalCareのファイアウォールのようなものだけです。Bot Protection機能を備え、国やデバイスに基づいて悪意あるIPを自動的にブロックします。高度なファイアウォールはネットワーク上の250,000以上のサイトから学習し、攻撃が始まる前にボットや悪意あるIPを識別します。しかもサイトの表示速度を落とすことはありません。

それでも永遠に悪意あるIPを一件ずつブロックし続けたい場合は、関連記事が役立つでしょう。

XML-RPCファイルを削除してはいけないのですか？WordPressはもう使っていないのでしょう？

削除はやめてください。XML-RPCファイルが存在しなくても、ボットは接続を試み続け、サイトに過負荷をかけ続けます。より大きなリスクは、WordPressのコアファイルを安易に削除することがサイトを完全に破壊しかねない点です。

最悪なのは、xmlrpc.phpが次回のWordPress更新時に再インストールされるため、ファイル削除の目的自体が果たせないことです。