WordPressのログイン画面には、第三者がユーザー名とパスワードを何度も試す不正ログイン攻撃が行われることがあります。
ログイン試行回数制限は、短時間に失敗を繰り返したアクセスを一時的に遅らせたり、一定時間ログインできなくしたりして、総当たり攻撃を続けにくくする仕組みです。
30秒でわかる結論
- ログイン試行回数制限は、短時間の大量ログイン試行を抑える仕組み
- 主にブルートフォース攻撃やパスワードスプレーの負担を増やす
- 「5回失敗したら永久ロック」のような強すぎる設定は、正規ユーザーの締め出しにつながる
- IPだけで制限すると、分散攻撃を十分に止められない場合がある
- 可能ならアカウント単位とIP単位の両方を見る
- WordPressではサーバー・WAF・CDN側でのレート制限を優先すると負荷を抑えやすい
- ログイン試行制限だけでなく、2要素認証・強いパスワード・更新・ログ監視を併用する
ログイン試行回数制限とは？
ログイン試行回数制限とは、一定時間内に何度もログインへ失敗した利用者に対し、追加のログインを遅らせたり、一時停止したりする仕組みです。
例
10分以内に5回ログインへ失敗 → 15分間だけ追加試行を制限。
攻撃者が何千回・何万回とパスワード候補を試す速度を落とし、不正ログイン成功の可能性を下げることが目的です。
何を防げる？
主に、認証情報を大量に試す攻撃への対策として使われます。
| 攻撃 | ログイン試行制限の効果 |
|---|---|
| ブルートフォース攻撃 | 試行速度を落としやすい |
| 辞書攻撃 | 大量試行を制限しやすい |
| パスワードスプレー | アカウント単位の制限が有効 |
| パスワードリスト攻撃 | IP・アカウント双方の制限が有効 |
完全防御ではない
正しいIDとパスワードがすでに漏えいしている場合、試行回数制限だけでは止められないことがあります。そのため2要素認証などと併用します。
ブルートフォース攻撃との関係
WordPress公式では、ブルートフォース攻撃を「ユーザー名とパスワードの組み合わせを繰り返し試す攻撃」と説明しています。
自動化されたBotやボットネットが使われることもあり、ログインに成功しなくても大量リクエストによってサーバー負荷が高くなる場合があります。
ログイン試行制限の役割
「攻撃者が正解へ到達する前に、試行コストを高くする」ための防御層です。
回数だけ決めればよい？
ログイン制限では、回数だけでなく、次の3つをセットで考えます。
| 項目 | 意味 |
|---|---|
| 試行回数 | 何回失敗したら制限するか |
| 監視時間 | 何分間の失敗を数えるか |
| ロック時間 | 何分間追加試行を止めるか |
OWASPも、アカウントロックアウトを設計する際は、しきい値・監視ウィンドウ・ロック時間のバランスを考えるよう推奨しています。
何回に設定すればよい？
「必ず5回」「10回なら安全」といった万能の正解はありません。
サイトの利用者数、管理者数、パスワード入力ミスの頻度、2要素認証の有無などで適切な値は変わります。
考え方の例
一般公開のWordPress管理画面なら、数回の失敗で即永久停止するのではなく、短時間の失敗を検知して段階的に待ち時間を増やす方式が扱いやすくなります。
強すぎる制限も危険
攻撃者が他人のユーザー名を使ってわざと失敗を繰り返すと、正規ユーザーをログイン不能にするDoS攻撃へ悪用される可能性があります。
固定ロックと段階的遅延の違い
ログイン制限には、一定時間ロックする方式と、失敗するたび待ち時間を長くする方式があります。
| 方式 | 特徴 |
|---|---|
| 固定ロック | 一定回数失敗後、10分など固定時間停止 |
| 段階的遅延 | 失敗が増えるほど待ち時間を延ばす |
OWASPでは、指数的に待ち時間を増やす「exponential lockout」の考え方も紹介されています。
正規ユーザーを締め出しにくくする
いきなり長時間ロックするより、短い遅延から段階的に強くする方が、利便性と防御のバランスを取りやすい場合があります。
IPアドレスだけで制限すればよい？
IP単位の制限だけでは不十分な場合があります。
攻撃者はボットネット、クラウド、プロキシなどを使い、複数IPから少しずつ試行できるためです。
分散攻撃の例
1つの管理者アカウントへ、100個のIPから各3回ずつ試行されると、IPごとの制限だけでは合計300回試される可能性があります。
OWASPは、失敗回数のカウンターをIPだけでなくアカウント側へ関連付ける考え方を推奨しています。
アカウント単位とIP単位を組み合わせる
実務では、次の2方向を組み合わせると分散攻撃へ対応しやすくなります。
2つの視点
- 同じアカウントへ大量に失敗していないか
- 同じIPから多数アカウントへ試行していないか
OWASPのBot Managementガイドでも、ログインエンドポイントでは「ユーザー名単位」と「IP単位」の両方でレート制限する考え方が示されています。
WordPressではどこで制限する？
WordPressのログイン試行制限は、複数の場所で実装できます。
| 場所 | 特徴 |
|---|---|
| セキュリティプラグイン | 導入しやすい |
| Webサーバー | PHPより前で制限できる場合がある |
| WAF・CDN | サーバーへ届く前に遮断しやすい |
| レンタルサーバー標準機能 | 管理画面から設定できる場合がある |
できれば前段で止める
WordPress公式は、ホストやCDNで制限できるなら、エッジやサーバー側でのレート制限を推奨しています。WordPressプラグインだけだと、攻撃リクエストのたびにPHP処理が動き、負荷が残る場合があります。
プラグインで制限する場合の注意点
共用レンタルサーバーでサーバー設定を変更できない場合、セキュリティプラグインを使う方法があります。
確認する設定
- 何回失敗で制限するか
- 何分間制限するか
- IPだけかアカウントも見るか
- 管理者へ通知するか
- 解除方法があるか
- 自分自身をロックした場合の復旧手段
複数のセキュリティ機能を重ねすぎない
サーバー標準制限、WAF、CDN、WordPressプラグインをすべて強く設定すると、正規ログインまで遮断した際に原因を切り分けにくくなります。
CAPTCHAとの違い
CAPTCHAは、ログインしようとしている相手が自動Botではないかを判定する追加チェックです。
| 対策 | 役割 |
|---|---|
| 試行回数制限 | 大量試行の速度を抑える |
| CAPTCHA | 自動操作を難しくする |
OWASPでは、CAPTCHAは完全な防御ではなく、攻撃コストを増やす多層防御として位置づけています。
最初から毎回CAPTCHAでなくてもよい
数回失敗したときだけCAPTCHAを追加するなど、利便性と防御を両立する設計もあります。
2要素認証との違い
ログイン試行回数制限は「パスワードを何度も試す」行為を抑えます。
2要素認証は、パスワードが正しくても、別の認証要素がなければログインできないようにします。
試行回数制限 ＝ 大量試行を遅くする
2要素認証 ＝ パスワードだけでは入れなくする
どちらか一方ではなく、管理者アカウントでは併用する方が安全です。
強いパスワードはまだ必要？
必要です。
ログイン試行回数制限を設定していても、簡単なパスワードや使い回しパスワードを使ってよいわけではありません。
WordPress公式も、ブルートフォース対策の基本として、長く固有のパスワードと2要素認証を推奨しています。
管理者アカウントの基本
- 長く推測されにくいパスワード
- 他サービスとの使い回し禁止
- パスワードマネージャー利用
- 2要素認証
- 不要な管理者アカウントを削除
ログインURL変更だけでは不十分
ログインURLを変更すると、自動Botからのノイズを減らせる場合があります。
ただし、WordPress公式も、ログインURLを隠すことを唯一の防御にしないよう案内しています。
URLを知られたら終わる対策にしない
ログインURL変更は補助対策と考え、試行制限、2要素認証、強いパスワード、WAFなどと組み合わせます。
XML-RPCにも注意する
WordPressでは、wp-login.phpだけでなくxmlrpc.phpが不正ログイン試行に悪用される場合があります。
WordPress公式も、XML-RPCを使わない場合は無効化を検討し、使う場合はWAFやレート制限を行うよう案内しています。
Jetpackや一部の外部アプリでXML-RPCを使う場合があります。必要性を確認せず無効化しないでください。
ログを確認する
ログイン制限を設定したら、実際にどれくらい失敗が発生しているか確認します。
確認したい内容
- 失敗ログインの件数
- 同じユーザー名への連続試行
- 同じIPから多数アカウントへの試行
- ロックアウトの発生
- ログイン成功直前の大量失敗
OWASPも、認証成功・失敗、アカウントロックなどを記録・監視することを推奨しています。
正規ユーザーがロックされたら？
ログイン試行制限は、自分や社内担当者もロックする可能性があります。
事前に確認する復旧手段
- 一定時間で自動解除されるか
- パスワード再設定が使えるか
- サーバー管理画面から解除できるか
- プラグインを停止できる方法があるか
- 管理者が複数いる場合の連絡方法
永久ロックを安易に使わない
他人のユーザー名が分かるサイトでは、攻撃者がわざと失敗を繰り返し、そのアカウントを使えなくする可能性があります。
共用レンタルサーバーではどうする？
共用レンタルサーバーでは、まずサーバー会社がログイン保護・WAF・Bot対策・アクセス制限機能を提供していないか確認します。
サーバー標準WAF＋強いパスワード＋2要素認証＋必要なら試行制限。
管理者アカウントを絞り、2要素認証と試行制限、ログ監視を組み合わせます。
Nginx、WAF、CDN、Fail2Ban等で前段制限を検討し、WordPressだけに処理を任せない構成を考えます。
教科書判定
ログイン試行制限は有効。ただし「回数を厳しくする」より多層防御で考える
初心者は、まず強い固有パスワードと2要素認証を設定し、そのうえでサーバーやWAFにログイン試行制限機能があれば有効化を検討してください。
WordPressプラグインで制限する場合は、自分自身をロックしたときの解除方法も先に確認します。
「3回失敗で永久ロック」のような極端な設定は、正規ユーザーを締め出す攻撃に悪用される可能性があるため避け、短時間の制限や段階的遅延を使う方が現実的です。
FAQ
Q．ログイン試行回数は何回にすればよいですか？
万能な正解はありません。管理者数や利用状況によって異なります。回数だけでなく、監視時間・ロック時間・解除方法をセットで決めてください。
Q．IPアドレスを制限すれば十分ですか？
十分とは限りません。複数IPから分散して攻撃される場合があるため、可能ならアカウント単位とIP単位の両方で制限します。
Q．試行回数制限があれば2要素認証は不要ですか？
不要にはなりません。試行回数制限は大量試行を抑える仕組み、2要素認証はパスワードが正しくても追加確認を要求する仕組みで、役割が違います。
Q．ログインURLを変えれば試行制限はいりませんか？
ログインURL変更だけを防御にするのはおすすめできません。URLが知られた場合に備え、試行制限・2要素認証・WAF等を併用してください。
Q．プラグインとWAFのどちらで制限すべきですか？
可能ならWAF・CDN・WebサーバーなどWordPressより前段で制限する方が、攻撃リクエストによるPHP負荷を減らしやすくなります。共用サーバーで難しい場合はプラグインも選択肢です。
まとめ
この記事の結論
- ログイン試行回数制限は短時間の大量ログイン試行を抑える仕組み
- ブルートフォース・パスワードスプレー・パスワードリスト攻撃への防御層になる
- 回数・監視時間・ロック時間をセットで設計する
- IPだけでなくアカウント側の失敗回数も見る
- 強すぎるロックは正規ユーザーへのDoSに悪用される可能性がある
- 可能ならWAF・CDN・Webサーバー側で前段制限する
- 2要素認証・強いパスワード・ログ監視を併用する
- 設定前に自分がロックされた場合の解除方法を確認する
「ブルートフォース攻撃とは？仕組みと対策を解説」もあわせて確認してください。