※本記事にはプロモーションが含まれています。
以前の私は、ログインURLを変更すれば安心できると思っていました。
セキュリティプラグインを入れ、wp-login.php を別のURLに変更し、「これで大丈夫」とほっとしたのを覚えています。
ですが、その数日後。またログイン試行をロックしたという通知が届きました。
「なぜ？ちゃんと対策したはずなのに」
攻撃そのものよりも、“仕組みが分からないこと”が一番怖かったのだと思います。
この記事では、ログインURL変更の役割と限界、そしてWordPressが狙われる仕組みを整理します。
WordPressはなぜ公開直後から狙われるのか
WordPressは世界中で使われているCMSです。
公開した瞬間、インターネット上の「既知の構造を持つWebアプリケーション」になります。
攻撃の多くは、人間が個別に狙っているわけではありません。
自動化されたボットが、
/wp-login.php/wp-admin/xmlrpc.php
などの既知のエンドポイントへ機械的にアクセスします。
これはスキャンに近い動きです。
インターネット上では、常に膨大なボットがサイトを巡回し、
- WordPressかどうかを判定
- ログインエンドポイントを確認
- ログイン試行を開始
という流れで動いています。
つまり、特定の個人が狙われているのではなく、“WordPressという構造”が対象になっているのです。
ブルートフォース攻撃の仕組み
ブルートフォース攻撃は総当たり攻撃と呼ばれます。
基本的な流れは次の通りです。
- 既知のログインURLへアクセス
- 代表的なユーザー名を試行（admin など）
- 辞書化されたパスワードを機械的に送信
- 成功するまで繰り返す
攻撃側は、人間の感情や事情を考慮しません。
高速かつ大量に試行するだけです。
ログインURLを変更しても、攻撃ボットの中には、
- フォームを自動検出する
- リンク構造を解析する
xmlrpc.php経由で認証を試みる
といった動きをするものもあります。
そのため、URLを隠すだけではログイン認証の強度は変わりません。
XML-RPCがログイン攻撃に使われる理由
WordPressにはxmlrpc.phpというエンドポイントがあります。
これは本来、外部ツールやスマートフォンアプリからWordPressに投稿するための仕組みです。
しかし、この機能には認証処理も含まれています。
そのため、ログインURLを変更していても、
/xmlrpc.phpへリクエストを送ることでログイン認証を試みることが可能です。
さらに、system.multicall という機能を利用すると、1回のリクエストで複数のログイン試行を行うこともできます。
その結果、ログインURLを変更していてもブルートフォース攻撃が続くケースがあります。
ログインURL変更の本当の役割
ログインURL変更は無意味ではありません。
これは例えるなら、入口の看板を外す対策です。
自動的に /wp-login.php だけを狙う単純なボットは減る可能性があります。
しかし、
- 認証ロジックは変わらない
- パスワード強度も変わらない
- 試行回数も制限されない
のであれば、防御としては不十分です。
セキュリティの本質は隠すことではありません。
- ログイン周りを強化する
- 試行を制御する
- 不審な通信を遮断する
といった設計にあります。
本質的な対策とは何か
私が現在重視しているのは、次の対策です。
- 強力なパスワード（15桁以上、英数字＋記号）
- 二段階認証（2FA）
- ログイン試行回数の制限
- XML-RPCの無効化
- サーバー側WAFの有効化
特に2FAは非常に有効です。
仮にパスワードが突破されたとしても、第二認証がなければログインは成立しません。
また、サーバー側でWAF（Web Application Firewall）を有効にしておくことで、明らかに不審なリクエストを事前に遮断できます。
私は現在、エックスサーバーを利用していますが、WAFやアクセス制限機能が標準で利用できるため、初心者の頃よりも安心感があります。
もちろん、どのサーバーでも設定しなければ意味はありません。
ただ、隠すだけの対策よりも、
- 認証強度
- 試行制御
- 通信遮断
といった複数の防御を重ねるほうが現実的なセキュリティ対策になります。
まとめ│仕組みを理解すると、恐怖は減る
以前は、「自分だけが狙われているのではないか」と感じていました。
しかし今は、これは公開サイトであれば日常的に発生している現象だと理解しています。
攻撃はゼロにはなりません。
ですが、
- 認証を強化する
- 試行を制限する
- サーバー側で遮断する
といった層を重ねれば、必要以上に怖がる必要はありません。
当時の私に足りなかったのは、対策の数ではなく仕組みの理解でした。
ログインURLの変更は意味がないわけではありません。
ただし、それだけで安心できる対策ではない。
セキュリティとは隠すことではなく、突破されにくく、突破されても成立しにくい設計にすること。
それを知ってから、WordPressとの向き合い方は少し変わりました。
Web Security AcademyのラボをWordPress視点で整理しています。
WordPressを安全に運用するには、アプリ側の設定だけでなく、サーバー側の防御も重要です。
WAF（Web Application Firewall）などの仕組みがあるサーバーを使うことで、Botによるスキャンや不正アクセスを早い段階で遮断できます。