Apacheのアクセスログを確認したところ、WordPressの xmlrpc.php へのPOSTが495件記録されていました。この記事では、そのログをどう見つけたか、どう塞いだか、そしてログの分け方によって気づけるかどうかが変わる、という話を書きます。
アクセスログにxmlrpc.phpへのPOSTが495件あった
Apacheのアクセスログを眺めていて目に付いたのが、xmlrpc.php へのPOSTでした。数えると495件ありました。通常の閲覧であればGETが並ぶはずのところに、同じパスへのPOSTがまとまって記録されている状態です。
xmlrpc.php はリモートから記事を投稿するための古い仕組みです。今のWordPressでREST APIを使っているなら、このファイルは使いません。つまり自分の運用では、このパスへの正当なアクセスは発生しません。にもかかわらずPOSTが495件来ているということは、自分の利用ではない何かが叩いているということになります。
なぜxmlrpc.phpが狙われるのか
xmlrpc.php は総当たり攻撃の入口として狙われやすいパスです。ログイン画面を経由せずに認証を試せる導線になるため、稼働しているだけで試行の対象になります。495件という数字は、そういう試行がまとまって飛んできた結果です。
なお、この495件の中に成功したものがあったかどうかは、今回確認したPOST件数だけでは判断していません。分かっているのは「POSTが495件記録されていた」という事実だけです。ここは断定しないでおきます。
Apacheの設定でアクセスを拒否した
対策としてやったことはシンプルで、Apacheの設定で xmlrpc.php へのアクセスを拒否しました。使っていない機能なので、止めても自分の運用に影響はありません。プラグインを増やして制御するより、Webサーバの手前で落としてしまうほうが確実だと考えました。
- xmlrpc.php はREST APIを使っているなら不要
- 不要なら、アプリケーション側で悩む前にApacheで拒否してしまえる
- 使っている場合は同じことができないので、この判断は「自分がxmlrpc.phpを使っていない」ことが前提です
気づけたのはログを分けていたから、ではなく分けていない怖さに気づいた
今回いちばん学びになったのは、攻撃そのものよりログの持ち方でした。サイトごとにアクセスログを分けていないと、この種の異常には気づきにくいです。
共有の access.log を見ると、中身は攻撃botのアクセスがほとんどです。xmlrpc.php へのPOSTのような異常も、大量のbotアクセスに混ざって流れていきます。逆に、実際の訪問者がどこを見ているのかは、サイト別のログを見ないと分かりません。
共有 access.log → 攻撃botのアクセスが大半 サイト別ログ → ここを見ないと実際の訪問者が分からない
つまり共有ログは「攻撃の観測用」、サイト別ログは「訪問者の把握用」と役割が違います。これを一本にまとめてしまうと、両方が見えなくなります。異常も埋もれるし、本物のアクセスも埋もれる、という二重の損です。
運用として決めたこと
- 使っていないエンドポイントは、存在させたままにしない。xmlrpc.php はApacheで拒否する
- アクセスログはサイトごとに分ける。混ざったログでは異常も訪問者も判別できない
- 件数を数える習慣を持つ。495件という数字が出たのは、パス単位で数えたからです
逆に、まだ分かっていないこともあります。この495件がどの期間に集中したものか、xmlrpc.php 以外に同じような試行が来ているパスがあるかどうかは、今回の確認では踏み込んでいません。ここは今後ログを分けた状態で見ていくしかないと考えています。
まとめ
- Apacheのアクセスログを確認したところ、xmlrpc.php へのPOSTが495件記録されていた
- xmlrpc.php はリモート投稿用の古い仕組みで、REST APIを使っているなら不要
- 総当たり攻撃の入口として狙われやすいパスである
- 対策として、Apacheの設定で xmlrpc.php へのアクセスを拒否した
- サイトごとにアクセスログを分けていないと、この種の異常には気づきにくい
- 共有の access.log は攻撃botのアクセスがほとんどで、実際の訪問者はサイト別のログを見ないと分からない
- 495件のうち成功した試行があったかどうかは、今回の確認では判断していない