BLOGブログ

/wp-login.phpを放置すると危険?中小企業サイトが今すぐやるべきWordPressログイン防御11選【2026年版】

2026.04.17(更新: 2026.06.04)

「うちのサイトは大企業じゃないから、狙われないはず」

この認識は、WordPress運用では危険です。実際の攻撃の多くは、特定企業を狙う“人力のハッキング”ではなく、/wp-login.php/xmlrpc.php を機械的にスキャンする自動攻撃(ボット)だからです。つまり、知名度や会社規模に関係なく、公開しているだけでログイン画面は毎日試される、というのが現実です。

しかも近年は、単純な総当たりだけでなく、流出済みID・パスワードを使うクレデンシャルスタッフィング(使い回し認証情報の悪用)が増えています。正しい対策を複数組み合わせないと、1つの穴から侵入される可能性があります。

本記事では、2025〜2026年の脅威動向を踏まえ、WordPressログイン画面を守るための実践策を「設定手順」「メリット・デメリット」「実装難度」まで含めて解説します。Web専任者がいない中小企業でも、今日から着手できる内容に絞っています。

なぜWordPressのログイン画面が狙われ続けるのか

WordPressは世界中で利用されているCMSであり、攻撃者にとって「効率のよい標的」です。攻撃スクリプトを1つ作れば、多数のサイトに横展開できるためです。

まず押さえたいのは、ログイン関連の代表的な攻撃手法の違いです。

  • ブルートフォース攻撃: 文字列の組み合わせを総当たりで試す手法
  • 辞書攻撃: よく使われる単語・パスワード候補を順に試す手法
  • クレデンシャルスタッフィング: 他サービス流出情報(メールアドレス+パスワード)を流用する手法

とくに企業サイトでは、担当者アカウントのパスワード使い回しがあると、WordPress自体に脆弱性がなくても突破されることがあります。

また xmlrpc.php を悪用した多重試行(system.multicall)や、脆弱なプラグイン経由でユーザー名を列挙してからログイン試行する流れも、依然として観測されています。

2025〜2026年の脅威動向(ログイン周り)

最新の公開レポートや注意喚起を見ると、次の傾向が共通しています。

  • 自動化の進行: ボットネットによるログイン試行が継続的に増加
  • 認証情報悪用の一般化: フィッシング・情報漏えい由来の資格情報が再利用される
  • 多層防御の必要性: 1つの施策(例: URL変更のみ)では防ぎ切れない
  • プラグイン設定ミスの悪用: 導入済みでも設定が甘いと突破される

ポイントは、「攻撃をゼロにする」のではなく「侵入成功確率を現実的に下げる」ことです。次章から、実務で効果が高い11施策を優先度順に解説します。

まず優先して実装したい11のログイン防御策

# 対策 難度 効果 SiteGuard対応
1 ログインURL変更
2 2段階認証(2FA)
3 ログイン試行回数制限
4 強固なパスワード運用
5 admin 廃止
6 CAPTCHA導入
7 IPアドレス制限
8 Basic認証(二重ロック)
9 XML-RPC無効化
10 HTTPS強制
11 セキュリティプラグイン選定

はじめに選ぶなら SiteGuard WP Plugin が手堅い

「何から入れればいいか分からない」という場合、まず SiteGuard WP Plugin を試してみるのがおすすめです。JP-Secure(現: EGセキュアソリューションズ)提供の国産プラグインで、日本語UIで設定項目が直感的、しかも無料で使えます。

本記事で解説する「ログインURL変更」「ログインロック」「画像認証(CAPTCHA)」「ログイン通知」「XML-RPC対策」などを、これ1つでひととおり設定できるのが嬉しいポイント。複数のプラグインを組み合わせて管理するよりシンプルで、初心者でもつまずきにくい構成です。

以降では個別の対策ごとに SiteGuard のどの機能が該当するかも併記しています。まずはこれを入れて、そのうえで足りない部分を他のプラグインで補う、という流れが現実的です。

1) ログインURL変更(/wp-admin / /wp-login.php の秘匿化)

既定のログインURLを推測されにくいURLへ変更します。

推奨プラグイン例

  • WPS Hide Login
  • SiteGuard WP Pluginログインページ変更 / 管理ページアクセス制限

設定手順(例)

  1. プラグインを有効化
  2. 設定 > 一般 の「Login url」を任意文字列に変更(例: /company-portal-login
  3. 新URLをパスワードマネージャーに保存し、関係者へ安全に共有

SiteGuard WP Plugin を使う場合は、ログインページ変更 で有効化時にログインURLが秘匿化されます。初期値は login_<5桁の乱数>(例: login_12345)ですが、任意の名称へ自由に変更できます(login_ 接頭辞は必須ではありません)。あわせて 管理ページアクセス制限 を有効にすると、wp-admin への直接アクセスを抑制できます。

メリット

  • ボットの無差別アクセスを大幅に減らせる
  • サーバー負荷軽減につながる

デメリット / 注意点

  • 「見つかりにくくする」施策であり、単体では不十分
  • URL共有ミスで担当者がログインできなくなることがある

実装難度: 低

2) 2段階認証(2FA)の導入

ID・パスワードに加え、ワンタイムコード(認証アプリ等)を必須化します。

推奨プラグイン例

  • Two-Factor(WordPress.org公式)
  • Wordfence Login Security(※単体版は2026年7月頃に廃止予定。新規導入はフル版 Wordfence 同梱の2FA機能を推奨)

設定手順(例)

  1. プラグイン有効化後、管理者ユーザーから2FAを登録
  2. Google Authenticator / Microsoft Authenticator などでQR読取
  3. ロール単位の強制機能を持つプラグインを使う場合は、管理者・編集者など権限の高いロールに2FAを必須化する(Two-Factor 単体には標準のロール強制機能はないため、利用プラグインの仕様に合わせる)
  4. バックアップコードをオフライン保管

メリット

  • パスワード漏えい時の侵入を強力に防止
  • クレデンシャルスタッフィング対策として有効

デメリット / 注意点

  • 初期導入時に運用ルール整備が必要
  • 端末紛失時の復旧フローを決めておく必要がある

実装難度: 中

3) ログイン試行回数の制限

連続失敗時に一定時間ロックし、総当たりを止めます。

推奨プラグイン例

  • Limit Login Attempts Security(旧称: Limit Login Attempts Reloaded)
  • SiteGuard WP Pluginログインロック / フェールワンス

設定手順(例)

  1. allowed retries を3〜5回に設定
  2. lockout time を15〜30分に設定
  3. Notify on lockout(通知)を有効化
  4. ホワイトリストIPを必要最小限で登録

SiteGuard WP Plugin では ログインロック で同様の試行回数制限を設定できます。さらに フェールワンス を使うと、初回のログイン試行を無条件で失敗させる追加防御も可能です。通知面は ログインアラート を併用すると、ログイン成功・失敗イベントの早期把握に役立ちます。

メリット

  • ブルートフォース・辞書攻撃に即効性が高い

デメリット / 注意点

  • 正規ユーザーの入力ミスでもロックされる
  • 共有IP環境では運用設計が必要

実装難度: 低

4) 強固なパスワード運用 + パスワードマネージャー

長くランダムなパスワードを、使い回しなしで管理します。

設定手順(運用)

  1. 最低12〜16文字以上、英大小・数字・記号を組み合わせる
  2. 役職アカウントでも個人ごとに発行(共用IDを避ける)
  3. 退職・異動時は即時ローテーション
  4. 1Password / Bitwarden などで安全共有

メリット

  • 低コストで効果が高い基本対策

デメリット / 注意点

  • 人手管理だと形骸化しやすい
  • ルールだけでなくツール導入が前提

実装難度: 低

5) 管理者ユーザー名を admin 以外にする

推測されやすいユーザー名を廃止し、攻撃者の前提情報を減らします。現行のWordPressは新規インストール時に管理者ユーザー名を任意で指定するため、admin が自動作成されるわけではありません。ただし既存サイトを admin のまま運用している場合は、以下の手順で別名へ移行しておきましょう。

設定手順(安全な移行)

  1. 新しい管理者ユーザーを作成(推測困難なユーザー名)
  2. 新ユーザーでログイン確認
  3. admin を削除し、投稿の帰属先を新ユーザーへ引き継ぐ

メリット

  • ユーザー名列挙後の攻撃成功率を下げる

デメリット / 注意点

  • これ単体では防御力は限定的

実装難度: 低

6) reCAPTCHA の導入

ログインフォームに人間判定を追加し、ボットの試行を抑制します。

推奨プラグイン例

  • Advanced Google reCAPTCHA
  • Login No Captcha reCAPTCHA
  • SiteGuard WP Plugin画像認証

設定手順(例)

  1. Google reCAPTCHAでサイトキー/シークレットキー取得
  2. プラグインにキー登録
  3. 対象画面を Login / Lost Password / Register に適用
  4. 実運用前にログイン成功可否を必ずテスト

SiteGuard WP Plugin では、Google reCAPTCHA連携ではなく 画像認証(CAPTCHA)をログイン関連画面に追加できます。ボットによる自動入力の突破を難しくする運用が可能です。

メリット

  • ボットによる大量試行の抑止に有効

デメリット / 注意点

  • UX低下の可能性(特に画像選択型)
  • 認証サービス障害時の影響を考慮

実装難度: 中

7) IPアドレス制限(.htaccess

特定IPのみ wp-login.php / wp-admin へアクセス許可します。

設定例(Apache: wp-login.php.htaccess で制限)

<Directory> ディレクティブは .htaccess では使用できません(サーバー本体設定/VirtualHost専用)。.htaccess では <Files> を使って wp-login.php を制限します。

# サイトルートの .htaccess
<Files wp-login.php>
  Require ip 203.0.113.10
</Files>

設定例(Apache: wp-admin 全体を制限)

wp-admin ディレクトリ全体の制限は、wp-admin/ 直下に専用の .htaccess を置く(ディレクトリ単位で Require を記述)か、サーバー本体設定/VirtualHost側の <Directory> で行います。

# サーバー本体設定 / VirtualHost 側
<Directory /var/www/html/wp-admin>
  Require ip 203.0.113.10
</Directory>

※複数拠点・在宅勤務がある場合はVPN併用が現実的です。

メリット

  • 不要アクセスを入口で遮断できる

デメリット / 注意点

  • 固定IPがない環境では運用負荷が高い
  • 設定ミスで自社も入れなくなる

実装難度: 中〜高

8) Basic認証でwp-loginを二重ロック

wp-login.php / wp-admin に到達する前段でHTTP Basic認証を要求し、WordPress本体へ処理が届く前にアクセスを遮断します。アプリ層(WordPress)ではなくWebサーバー層で防ぐため、試行回数の多い自動攻撃に対して強力です。

設定手順(Apache: .htaccess + .htpasswd

  1. htpasswd コマンドでBasic認証用ユーザーを作成し、.htpasswd をWeb公開外に配置
  2. wp-login.phpwp-admin に対して AuthType Basic / AuthUserFile / Require valid-user を設定
  3. 管理画面へのアクセスとログイン動作を確認

.htaccess では <Directory> は使えないため、wp-login.php<Files> で、wp-admin 全体は wp-admin/ 直下の .htaccess(またはサーバー本体設定の <Directory>)で保護します。

# サイトルートの .htaccess(wp-login.php を保護)
<Files wp-login.php>
  AuthType Basic
  AuthName "Restricted"
  AuthUserFile /var/www/.htpasswd
  Require valid-user
</Files>
# wp-admin/ 直下の .htaccess(wp-admin 全体を保護)
AuthType Basic
AuthName "Restricted"
AuthUserFile /var/www/.htpasswd
Require valid-user

サーバー本体設定/VirtualHost側で記述する場合は、上記の wp-admin 用設定を <Directory /var/www/html/wp-admin> ... </Directory> で囲みます。

設定手順(Nginx: auth_basic

wp-login.phpwp-adminauth_basic / auth_basic_user_file を設定します。

location = /wp-login.php {
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass php;
}

location ^~ /wp-admin/ {
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
  try_files $uri $uri/ /wp-admin/index.php?$args;
}

admin-ajax.php の例外設定(必要時)

お問い合わせフォームやEC機能などで admin-ajax.php を未ログイン利用するプラグインは、Basic認証下で動作しなくなる場合があります(例: Contact Form 7、WooCommerceの一部機能)。必要に応じて admin-ajax.php のみ認証除外を行います。

location = /wp-admin/admin-ajax.php {
  auth_basic off;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass php;
}

Apacheでも admin-ajax.php を除外する構成は可能ですが、サイト構成によって記述方法が変わるため、検証環境で必ず動作確認してから本番へ反映してください。

メリット

  • WordPress到達前で遮断でき、負荷と侵入試行の両面に効く
  • WordPress側のプラグイン障害時でも防御レイヤーを維持しやすい

デメリット / 注意点

  • フロント側機能が admin-ajax.php を使う場合、例外設計が必要
  • Basic認証のID・パスワードはWordPress本体と必ず分離し、使い回しを避ける

補足

Basic認証はサーバー設定で実施するため、SiteGuard WP Plugin の機能だけではカバーできません。SiteGuardのログイン防御と併用して、別レイヤーの対策として位置づけるのが有効です。

実装難度: 中

9) XML-RPC の無効化(必要な場合のみ有効)

不要なら xmlrpc.php を無効化し、攻撃面を減らします。

設定手順(例)

  1. Jetpack連携や外部アプリ投稿など利用要件を確認
  2. 不要なら Disable XML-RPC 系プラグイン導入、またはWAF/サーバー設定で遮断
  3. https://example.com/xmlrpc.php へアクセスし無効化状態を確認

SiteGuard WP Plugin を使う場合は XMLRPC防御 を有効化することで、xmlrpc.php を悪用する攻撃の抑止をまとめて設定できます。

なお、xmlrpc_enabled フィルター(add_filter('xmlrpc_enabled', '__return_false'))は「認証が必要なXML-RPCメソッド」を止めるだけで、xmlrpc.php 自体やpingbackなどが完全に停止するわけではありません。確実に遮断したい場合は、WAFやWebサーバー側で xmlrpc.php へのアクセス自体をブロックしてください。

メリット

  • system.multicall 由来の大量試行を抑制しやすい

デメリット / 注意点

  • 必要機能まで止めるリスクがある

実装難度: 低〜中

10) SSL/TLS(HTTPS)の強制

ログイン情報を平文送信させないよう、管理画面を必ずHTTPS化します。

設定手順(例)

  1. サーバー証明書を設定(Let’s Encrypt等)
  2. 設定 > 一般 のURLを https:// に統一
  3. 常時SSLリダイレクトを設定
  4. 混在コンテンツ(http読込)を修正

メリット

  • 盗聴・改ざんリスクを大幅低減
  • ブラウザ警告回避で信頼性も向上

デメリット / 注意点

  • 証明書更新漏れ・混在コンテンツ対応が必要

実装難度: 中

11) 信頼できるセキュリティプラグインの選定と比較

多機能プラグインは「入れるだけ」でなく、役割を決めて最小構成で使うことが重要です。

プラグイン 強み 注意点 難度
Wordfence WAF、可視化、脅威情報連携が強い 設定項目が多く、初期設計が必要
Solid Security(旧 iThemes Security) ポリシー適用やハードニング機能が豊富 機能重複設定で競合しやすい
SiteGuard WP Plugin 日本語UIで導入しやすく、ログイン防御機能を一通り無料で集約しやすい 高度なWAF機能は限定的(必要に応じてサーバー側で補完)

中小企業・日本語サイトでの第一候補

運用担当が少ない現場では、まず SiteGuard WP Plugin を第一候補にし、足りない要件(例: 高度なWAF分析やマルウェア検査)だけを他ツールで補う構成が現実的です。なお、セキュリティプラグイン自体の脆弱性が公表されることもあるため(2026年6月4日時点の公式案内は 1.7.12、同年3月の脆弱性告知あり)、導入時・運用中とも必ず最新版を確認・適用してください。

SiteGuard WP Plugin でまとめて設定しやすい主な機能

  • 管理ページアクセス制限wp-admin への不要アクセス抑制)
  • ログインページ変更login_* 形式のランダムURLへ変更)
  • 画像認証(CAPTCHA系防御)
  • ログイン詳細エラーメッセージの無効化
  • ログインロック / ログインアラート / フェールワンス
  • XMLRPC防御
  • 更新通知(更新見落とし防止)
  • WAFチューニングサポート(誤検知時の調整支援)

選定のコツ

  • まず「2FA」「試行回数制限」「ログ通知」を確実に有効化
  • 似た機能のプラグインを重複導入しない(不具合防止)
  • 本番反映前にステージングで検証

施策の優先順位(最短で事故確率を下げる)

時間がない場合は、次の順で進めると効果が出やすいです。

  1. 2FA導入
  2. 試行回数制限
  3. 強固なパスワード運用 + admin 廃止
  4. ログインURL変更
  5. reCAPTCHA / XML-RPC無効化
  6. IP制限、WAF調整

「まず5割の対策」ではなく「突破されやすい順に潰す」ことが重要です。

運用で差がつく監視ポイント(導入後に放置しない)

設定後に次を月次で確認すると、被害の早期発見につながります。

  • ロックアウト件数の急増(攻撃波の兆候)
  • 存在しないユーザー名への試行
  • 深夜帯・海外IPからの管理者ログイン
  • プラグイン設定の無効化や改変
  • SiteGuard WP Plugin 利用時は ログインアラート の通知先が個人依存になっていないか

可能なら、通知先を個人メールだけでなくチーム共有(例: セキュリティ用メーリングリスト)にして、担当者不在時でも気づける体制を作りましょう。

どこまで自社でやるべきか?判断の目安

以下に当てはまる場合、スポット支援や運用保守の併用を検討する価値があります。

  • 担当者が1名で、引き継ぎドキュメントがない
  • 退職・異動時のアカウント棚卸しが不定期
  • 夜間障害時の初動ルールがない
  • 「設定したはずだが今どうなっているか不明」な項目が多い

WordPressのログイン防御は、初期設定よりも「継続運用」で差がつきます。自社だけで難しい部分は、外部の専門家を適切に使う方が、結果としてコストとリスクの両面で合理的です。

まとめ

WordPressのログイン画面は、攻撃者から見れば最初に試す入口です。だからこそ、URL変更や試行回数制限のような軽量施策だけでなく、2FAや運用監視まで含めた多層防御が必要です。

株式会社WEBRALでは、WordPressの復旧・高速化・運用保守を提供しており、ログイン防御の初期設計から運用ルール整備、緊急時対応まで支援しています。社内で抱え込みすぎず、必要な範囲だけ外部を活用することで、事業を止めないWeb運用を実現できます。

「今の設定で本当に十分か不安」「担当者依存を減らしたい」という場合は、現状診断から段階的に進めるのがおすすめです。

参考情報(公開レポート・ガイドライン)

  • SiteGuard WP Plugin 公式: https://www.jp-secure.com/siteguard_wp_plugin/
  • WordPress.org(SiteGuard WP Plugin): https://ja.wordpress.org/plugins/siteguard/
  • Wordfence Threat Intelligence: https://www.wordfence.com/threat-intel/
  • Wordfence Research/Blog: https://www.wordfence.com/blog/category/research/
  • Sucuri Reports: https://sucuri.net/reports/
  • WPScan Research Blog: https://wpscan.com/blog/
  • JPCERT/CC 注意喚起: https://www.jpcert.or.jp/at/
  • IPA(情報処理推進機構)情報セキュリティ10大脅威: https://www.ipa.go.jp/security/10threats.html
  • OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

※レポートは毎年更新されるため、社内手順書に転記する際は最新版の発行年を確認してください。