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

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

きっかけは、サーバーの状態確認のついでにApacheのアクセスログを覗いたことでした。ざっと眺めていると、同じパスへのPOSTが延々と並んでいます。それがxmlrpc.phpでした。数えてみると495件。

正直なところ、この495件がどのくらいの期間に分散していたのか、送信元が単一なのか複数なのか、認証が実際に通ったものが含まれるのかまでは、私は確認していません。「495回のPOSTが記録されていた」以上のことは分かっていないというのが正確な状況です。ただ、通常の運用でこのファイルにPOSTが集中する理由が自分のサイトには無い、という点だけははっきりしていました。

xmlrpc.php は自分のサイトでは使っていなかった

xmlrpc.phpはリモート投稿用の古い仕組みです。外部のクライアントから記事を投稿したり操作したりするための入口で、REST APIを使っている環境であれば必要ありません。私の運用でも、このファイルを通す用途は存在しませんでした。

そして問題は、使っていないファイルであっても、置いてある限り総当たり攻撃の入口として狙われるという点です。今回のPOSTの並びは、まさにそこを叩かれている形でした。使っていない機能が、こちらの意図とは無関係に攻撃対象として生き続けていたわけです。

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

プラグインで塞ぐ方法もありますが、私はWordPressに到達する前で止めたかったので、Apacheの設定側でxmlrpc.phpへのアクセスを拒否しました。やったことは実質これだけです。

1. アクセスログでxmlrpc.phpへのPOSTが495件あることを確認する
2. そのサイトでxmlrpc.phpを使う用途が無いことを確認する（REST APIで足りている）
3. Apacheの設定でxmlrpc.phpへのアクセスを拒否する

<Files "xmlrpc.php">
    Require all denied
</Files>

ただし、これで攻撃自体が止まるわけではありません。リクエストは相手が送ってくるものなので、こちらができるのは受け取ってから拒否することだけです。「入口を1つ閉じた」以上の効果を期待すべきではない、と自分では整理しています。

もっと重要だったのは「ログを分けていなかったこと」

今回いちばん反省したのは、495件そのものよりも気づくのが遅れる構造になっていたことです。

共有のaccess.logを見ると、記録されているのは攻撃botのアクセスがほとんどでした。実際の訪問者の動きは、その中に埋もれてしまって読み取れません。逆に言えば、サイトごとにアクセスログを分けていないと、こういう異常にも実際の訪問者にも気づけないということです。

できたこと・できていないこと

• xmlrpc.php へのPOSTが495件あることをログから把握した
• Apacheの設定でそのファイルへのアクセスを拒否した

• 495件の送信元や期間、成否の内訳までは調べていない
• サイトごとのログ分離が済んでいない（ここが今の課題）