WordPressのxmlrpc.phpに495回のログイン試行が来ていた

Apacheのアクセスログを見ていたら、xmlrpc.php へのPOSTが495件記録されていました。この記事では、何が起きていたのか、どう対処したのか、そしてログの分け方を見直した理由を書きます。

アクセスログを見たら、同じファイルへのPOSTが並んでいた

きっかけは、Apacheのアクセスログをざっと眺めていたことでした。特に何かトラブルが起きていたわけではありません。ただ、ログの中に xmlrpc.php という同じパスが延々と並んでいて、しかもそれが全部POSTでした。

数えてみたところ、495件

実測

495件 の POST
Apacheのアクセスログに記録されていた xmlrpc.php へのPOST数

GETで様子見をしているのではなく、全部POSTです。xmlrpc.php にPOSTするというのは、そこに何かデータを送り込んでいるということで、この数のPOSTが並んでいる時点で、人間の操作ではなくログイン試行だと考えるのが自然です

xmlrpc.php とは何だったのか

xmlrpc.php は、WordPressにリモートから投稿するための古い仕組みです。外部のクライアントアプリなどから記事を投稿したり操作したりするための入口として用意されています。

ただし今は、同じことをREST APIで行えます。REST APIを使っているなら、xmlrpc.php は不要です。

そして問題なのは、この不要な入口が総当たり攻撃の入口として狙われやすいという点です。使っていないのに開いたままになっている扉が、まさにそこを狙って叩かれ続けていた、というのが今回の状況でした。

注意

自分のサイトが xmlrpc.php を使っていないかどうかは、閉じる前に確認が必要です。リモート投稿の仕組みに依存している運用をしている場合、閉じると動かなくなります。私の場合はREST APIで足りていたので閉じました。

対策:Apacheの設定でアクセスを拒否した

やったことはシンプルで、Apacheの設定で xmlrpc.php へのアクセスを拒否しました。

WordPress側のプラグインで塞ぐ方法もありますが、プラグインで塞ぐ場合はリクエストが一度WordPressまで届いてからPHPが処理することになります。Apacheの段階で拒否すれば、その手前で止まります。

  1. アクセスログで xmlrpc.php へのPOSTが来ていることを確認する
  2. 自分のサイトが xmlrpc.php を使っていないことを確認する
  3. Apacheの設定で xmlrpc.php へのアクセスを拒否する
  4. 設定後、実際に拒否されているかログで確認する
うまくいったこと

Apache側で拒否する形にしたので、WordPressやPHPを動かす前の段階で止められます。不要な機能をひとつ閉じただけで、495件分の入口がなくなりました。

本当の問題は「気づけなかったこと」のほうだった

495件のPOSTそのものより、私が気になったのはこれに今まで気づいていなかったことでした。

理由ははっきりしていて、サイトごとにアクセスログを分けていなかったからです。複数のサイトのアクセスが共有の access.log に全部混ざって記録されていました。

共有のaccess.logはほとんど攻撃botだった

実際に共有のログを見ると、中身のほとんどが攻撃botのアクセスです。今回の xmlrpc.php へのPOSTもそうですし、それ以外にも機械的なアクセスが大量に流れ込んでいます。

この状態だと、二つの意味で困ります。

  • 攻撃の兆候が、他サイトのアクセスに紛れて埋もれる
  • 実際の訪問者がどう動いているのかが、まったく読み取れない

実際の訪問者の動きは、サイト別のログを見ないと分かりません。共有ログを眺めても、そこに写っているのは大部分がbotの足跡です。「アクセスログを見ている」つもりで、実は攻撃者のログを見ていただけ、という状態でした。

ポイント

アクセスログをサイトごとに分けることは、単なる整理整頓ではありません。異常に気づくためと、本物の訪問者を見るための両方に必要な準備です。分けていないと、そもそも見るという行為が成立しません。

分かっていないこと

正直に書いておくと、今回の件で分かっていないことはいくつもあります。

  • 495件のPOSTが、どこから、どういう間隔で来ていたのか
  • ログイン試行が成功しかけたことがあったのかどうか
  • xmlrpc.php を閉じたことで、攻撃側が別の入口に移るのかどうか

これらは、今回確認した範囲では分かりません。「xmlrpc.php を閉じたから安全になった」という話ではないということは、はっきり書いておきます。閉じたのは、狙われやすい不要な入口をひとつ塞いだだけです。

失敗したこと

そもそもログをサイトごとに分けていなかったことが失敗でした。495件という数が積み上がるまで気づかなかったのは、監視していなかったからではなく、監視できる状態にしていなかったからです。

やったことの整理

項目 内容
見つけたもの xmlrpc.php へのPOSTが495件
xmlrpc.php の役割 リモート投稿用の古い仕組み。REST APIを使うなら不要
リスク 総当たり攻撃の入口として狙われやすい
対策 Apacheの設定でアクセスを拒否
見直したこと サイトごとにアクセスログを分ける
まとめ

  • Apacheのアクセスログに、xmlrpc.php へのPOSTが495件記録されていた
  • xmlrpc.php はリモート投稿用の古い仕組みで、REST APIを使っているなら不要
  • 不要なのに開いていて、総当たり攻撃の入口として狙われやすい
  • 対策はApacheの設定で xmlrpc.php へのアクセスを拒否した
  • そもそもサイトごとにログを分けていないと、この種の異常に気づけない
  • 共有のaccess.logはほとんど攻撃botで、実際の訪問者はサイト別のログでしか見えない
  • 攻撃元や試行の詳細、閉じた後に別の入口へ移るかどうかは分かっていない