WordPressサイトを運営していると、毎日のように同じ手順でアクセスが来ることがあります。
「これって攻撃されているの？」
「なぜ同じURLばかり叩かれるの？」
実際のアクセスログを見てみると、そこには決まった手順で動くBotの存在が見えてきます。
この記事では、実際のログをもとに、WordPressサイトに対して行われるスキャンの流れを分解して解説します。
実際のアクセスログ
以下は、同一IPアドレスから数秒の間に行われたアクセスです。
35.205.216.110 → /（301 → wwwへリダイレクト）
35.205.216.110 → /（200）
35.205.216.110 → /wp-includes/wlwmanifest.xml（403）
35.205.216.110 → /?author=1（302）
35.205.216.110 → /?author=2（302）
35.205.216.110 → /?author=3（302）
35.205.216.110 → /wp-json/wp/v2/users/（403）
35.205.216.110 → /wp-json/oembed/1.0/embed（403）
35.205.216.110 → /xmlrpc.php（POST）（403）このログは単なるアクセスの羅列ではなく、WordPressサイトを調査するための一連の動きを示しています。
Botの動きを分解｜WordPressスキャンの流れ
このBotの行動は、いくつかの段階に分けて理解できます。
① サイトの存在確認と正規URLの取得
GET /
→ 301（wwwへリダイレクト）
→ 200まずトップページにアクセスし、サイトが存在するかを確認しています。
同時に、wwwあり・なしのどちらが正規URLかも把握しています。
② WordPressかどうかの判定
GET /wp-includes/wlwmanifest.xmlwlwmanifest.xml はWordPress特有のファイルのひとつです。
このようなファイルにアクセスすることで、このサイトがWordPressかどうかを判定しています。
③ ユーザー名の列挙（author）
GET /?author=1
GET /?author=2
GET /?author=3?author= は、WordPressのユーザー情報を特定するための典型的な手法です。
ログイン攻撃の前段階として、ユーザー名の収集を行っています。
?author= を使ったユーザー列挙については、WordPressの仕様として知られており、別記事でも詳しく解説しています。
▶ WordPressでユーザー名がバレる理由と対策｜ユーザー列挙攻撃をログから解説
④ REST APIによる情報取得
GET /wp-json/wp/v2/users/WordPressのREST APIを使って、ユーザー情報を取得しようとしています。
author と合わせて、複数の手段でユーザー名を探しているのが分かります。
⑤ WordPress機能の確認（oEmbed）
GET /wp-json/oembed/1.0/embedこのエンドポイントは、WordPressの機能のひとつです。
BotはこうしたURLを叩くことで、サイトの構成や利用機能を確認しています。
REST APIを利用したユーザー情報の取得については、「wp-json/wp/v2/users にアクセスされる理由」の記事でも取り上げています。
⑥ xmlrpc.phpへのPOST
POST /xmlrpc.phpxmlrpc.phpは、ブルートフォース攻撃や悪用の対象になりやすいファイルです。
ここでは実際にPOSTリクエストが送られており、次の段階に進めるかどうかを試しています。
xmlrpc.phpはブルートフォース攻撃にも使われるため、ログイン関連の挙動については別記事でも詳しく解説しています。
▶ WordPress公開直後に来たxmlrpc.php POSTリクエスト｜アクセスログ分析
このアクセスは攻撃なのか？スキャンとの違い
結論から言うと、このログは本格的な攻撃ではなく探索（スキャン）の段階です。
特徴としては、
- 決まったURLを順番に叩いている
- 短時間で一連のアクセスが完結している
- 成功した箇所がなく、次の攻撃に進んでいない
つまり、Botは侵入できるかどうかの下調べをしている状態です。
なぜIPアドレスを変えてアクセスしてくるのか
同じIPアドレスから毎日同様のアクセスが来る理由としては、以下が考えられます。
- 自動化されたスキャンツールが定期実行されている
- WordPressサイトのリストを巡回している
- 定期的に再チェックしている
特にクラウド環境（VPSなど）では、こうした処理がスケジュール実行されることが多く、同じ動きが繰り返されます。
User-Agentは信用できるのか
このログでは、以下のUser-Agentが使われていました。
Mozilla/5.0 ... Chrome/88一見すると普通のブラウザに見えますが、
- バージョンが古い
- 常に同じUA
- 挙動が明らかに自動化
という点から、偽装されている可能性が高いと判断できます。
User-Agentは一見するとブラウザのように見えますが、実際には簡単に偽装できます。
詳しくは「User-AgentとRefererは信用できない」の記事でも解説しています。
対策は必要なのか
今回のログでは、多くのリクエストに対して403（拒否）が返されており、重要なエンドポイントへのアクセスは制限されています。
一方で、/?author= へのアクセスは302リダイレクトとなり、完全にブロックされている状態ではありませんでした。
この挙動は重大な脆弱性ではないものの、ユーザー情報の推測につながる可能性があるため、改善の余地があります。
そのため、この記事の検証後に404を返すように設定し、不要な探索リクエストへの対策としました。
このように、基本的なセキュリティ対策ができていれば過度に心配する必要はありませんが、細かな挙動まで見直すことで、より安全な状態に近づられます。
WordPressの基本的なセキュリティ対策については、別記事で初心者向けにまとめています。
▶ WordPressのセキュリティ対策は何からやるべきか│初心者向けに最低限の設定を解説
まとめ｜Botは決まった手順でサイトを調べている
今回のログから分かることはシンプルです。
WordPressサイトに対するBotの動きは、ある程度パターン化されています。
- サイトの存在確認
- CMSの判定
- ユーザー情報の収集
- 攻撃可能ポイントの確認
こうした一連の流れは、特定のサイトを狙ったものではなく、広範囲に対して自動的に行われています。
アクセスログを分析することで、何をされているのかが見えてくると、不必要な不安も減らすことができます。