WordPressのログイン画面は公開URLにあるため、総当たりや漏えいパスワードの試行を完全には避けられません。URLを変更すると機械的なアクセス量を減らせる場合はありますが、認証情報が漏れたときの防御にはなりません。

優先したいのは、不要な管理者を消し、利用者ごとに固有のパスワードと二要素認証を設定することです。そこへ試行制限、更新、ログ監視を重ねます。一つのプラグインではなく、弱い入口が残らない順番で進めます。

最初に管理者アカウントを一人ずつ確認する

管理者一覧を開き、現在の担当者・制作会社・退職者を照合します。用途不明のアカウントを見つけたら、いきなり削除せず作成時期と投稿の所有を確認します。必要な記事を現担当者へ引き継いだ後、不要な入口を停止します。

一つのadminを複数人で共有すると、誰の操作か追えません。担当者ごとのアカウントを作り、日常業務には編集者など必要な役割だけを割り当てます。プラグイン追加や利用者管理を行う人だけに管理者権限を残します。

表示名をログイン名と違うものにしても、それだけで認証は強くなりません。利用者名が推測される前提で、パスワードと追加要素を守ります。最終ログインや操作履歴を確認できる環境では、不使用アカウントを見つける材料にします。

固有の長いパスワードと二要素認証を組み合わせる

パスワードは他サービスと使い回さず、会社で認めたパスワード管理ツールで生成・保存します。NISTの認証指針は、既知または侵害済みのパスワードを拒否し、パスワード管理ツールと貼り付けを許可するよう求めています。記号の置換パターンだけを複雑さと考えません。

WordPress公式のセキュリティ資料も、強いパスワードに加えて二段階認証を勧めています。対応するならパスキーやセキュリティキーなど、フィッシング耐性のある方式を優先します。認証アプリの手入力コードもパスワードだけより防御を増やしますが、偽画面へ入力したコードを中継される可能性は残ります。

全管理者へ設定しなければ、攻撃者は二要素認証のない入口を狙います。回復コードをパスワードと同じ場所へ保存せず、会社管理の保管先へ置きます。通常ログインと回復手順を試してから、古い端末や旧担当者の認証を解除します。

ログイン試行を遅らせ異常を通知する

長いパスワードでも、無制限に試せる入口は放置しません。NISTはオンライン推測攻撃へのレート制限を求めています。WordPressではサーバー・WAF・セキュリティ機能のどこで制限するかを決め、同じ機能を重ねて正規利用者を締め出さないようにします。

IPアドレス一つを永久遮断するだけでは、分散した攻撃や共有回線へ対応できません。アカウントごとの失敗回数、待機時間、送信元の変化を組み合わせます。解除手段を攻撃者が悪用できないよう、回復メールのアカウントにも二要素認証を設定します。

失敗試行の急増、管理者の追加、未知の端末からの成功ログインを通知対象にします。通知が多すぎると見なくなるため、正常な失敗と対応が必要な変化を分けます。ログにはIPや利用者情報が含まれるので、閲覧権限と保管期間も制限します。

URL変更や追加認証は補助策として扱う

ログインURLの変更は、既定URLだけを巡回するボットを減らす効果が見込めます。しかし新URLがリンクやログから判明すれば、パスワード攻撃は再開できます。URL変更を強い認証の代わりにせず、担当者と回復手順を記録します。

wp-adminへサーバー側の追加認証を置く方法もあります。WordPress公式資料は第二層になり得る一方、admin-ajax.phpなどを使う機能が壊れる場合を示しています。公開フォームやプラグインの通信を含め、保護対象と例外を確認します。

XML-RPC・REST API・アプリケーションパスワードなど、ログイン画面以外の認証経路を使う連携もあります。画面URLを変えてもこれらは別に残ります。利用中の外部アプリを一覧にし、不要な連携と発行済み資格情報を解除します。

更新と端末管理をログイン防御へ含める

ログイン画面を守っても、古いプラグインの脆弱性から管理者権限を得られる場合があります。WordPress本体・テーマ・プラグインを公式情報に基づいて更新し、使っていないものは停止だけでなく削除を検討します。更新前のバックアップと検証は別記事の手順に沿います。

管理に使うパソコンがマルウェアへ感染すれば、入力した認証情報やログイン済みセッションを奪われる可能性があります。OSとブラウザーを更新し、共有パソコンや信頼できない回線で管理作業を行いません。退職や端末紛失時には、アカウントだけでなくセッションと認証器も無効にします。

HTTPSはログイン通信を保護する前提です。証明書警告を無視して管理画面へ入らず、正しいホスト名と有効な証明書を確認します。サイトのURL設定と転送が不安定な状態でログイン対策を重ねると、回復経路まで失うことがあります。

導入後は正常系と回復系を別々に試す

対策は一度にすべて有効にしません。予備の管理者セッションを安全に確保し、一層ずつ反映します。通常ログイン、パスワード再設定、二要素認証の回復を別のブラウザーで試します。

公開フォーム・予約機能・管理Ajax・外部アプリも確認します。正規利用者の失敗が増えた場合は、制限を外す前にどの層で拒否されたかをログから調べます。対策全体を無効にするのではなく、誤判定の条件だけを調整します。

権限台帳には管理者・役割・認証方式・最終確認日を残します。回復手段の保管責任者、通知先、退職時の停止手順も必要です。ログイン防御の完成条件は攻撃表示がゼロになることではなく、資格情報が一つ漏れても侵入されにくく、不審な成功へ早く気づけることです。