IT用語集

ブルートフォースアタックとは? 被害内容と対策など

水色の背景に六角形が2つあるイラスト 水色の背景に六角形が2つあるイラスト
アイキャッチ
目次

ブルートフォースアタック(総当たり攻撃)とは、ログインIDとパスワードの組み合わせを機械的に試し続け、有効な認証情報を見つけようとする攻撃です。成立しやすいのは、短いパスワードが残っている、試行回数の制限が弱い、ユーザーIDを推測しやすい、多要素認証が入っていない、といった条件が重なった環境です。

対策は二つの軸で整理すると判断しやすくなります。一つは、攻撃者に試行を続けさせないことです。もう一つは、試行されても突破しにくい認証方式へ寄せることです。前者ではレート制限、ロックアウト、監視、汎用的なエラーメッセージが効きます。後者では、長いパスワード、漏えい済み候補の排除、多要素認証FIDO2電子証明書のようなパスワード依存を下げる方式が候補に入ります。

ブルートフォースアタックとは

ブルートフォースアタックは、考えられる候補を順番に試す攻撃です。仕組み自体は単純ですが、自動化しやすく、認証画面が外部公開されている限り試行の入口は残ります。特に、短いパスワードや規則的なパスワードが残っている環境では、攻撃者に有利な条件がそろいやすくなります。

この攻撃は、オンラインのログイン画面に対して行われる試行を指すことが多い一方、漏えいしたハッシュを攻撃者が手元で解析する形では前提が変わります。オンラインでは試行回数制限や監視が効きますが、ハッシュ漏えい後のオフライン解析では、その制限が効きません。そのため、認証画面の保護だけでなく、認証情報の保管方法と漏えい後の運用まで見ておく必要があります。

攻撃が成立しやすい条件

ユーザーIDを推測しやすい

メールアドレス形式、社員番号規則、公開名から作れるIDのように、利用者IDを絞り込みやすい環境では攻撃効率が上がります。さらに、ログイン失敗時の表示が「ユーザーが存在しない」と「パスワードが違う」で分かれていると、攻撃者が有効なIDだけを選別しやすくなります。

試行回数の制限が弱い

失敗回数に応じた待機時間がない、ロックアウトがない、IP単位や端末単位の制御が弱い、といった環境では総当たりの速度が落ちません。レート制限や段階的な遅延がないと、候補を短時間で消化されやすくなります。

短いパスワードや予測しやすい候補が残っている

短いパスワードは探索空間が小さく、総当たりや推測攻撃の対象になりやすくなります。加えて、単語、連番、会社名、季節名、規則的な置き換えを使ったパスワードは、総当たりの前に候補を絞られやすくなります。NISTは、長さを優先し、漏えい済みや推測されやすい候補を拒否する考え方を示しています。

パスワードだけで認証が完結している

パスワードだけで入れる設計では、正しいパスワードが見つかった時点で突破されます。追加要素がない認証は運用しやすい反面、総当たりや漏えい後の再利用に弱くなります。

近い攻撃との違い

パスワードを狙う攻撃は一種類ではありません。ブルートフォースアタックだけを見ていると、別の経路を見落としやすくなります。

つまり、長いパスワードを求めるだけでは十分ではありません。IDの推測しやすさ、エラーメッセージ、使い回し、追加認証の有無まで含めて見ないと、別の攻撃へそのまま道を開けることがあります。

発生しうる被害

攻撃が成功すると、攻撃者は正規ユーザーとして振る舞えます。被害は認証突破で終わりません。情報閲覧、不正購入、設定変更、管理画面の改ざん、内部システムへの横展開など、権限に応じて影響が広がります。管理者アカウントや共有アカウントが突破された場合は、被害範囲が特に大きくなります。

  • 個人情報、機密情報、認証情報の閲覧や持ち出し
  • 管理画面や設定の改ざん
  • 不正購入、不正送金、ポイント悪用などの金銭被害
  • 社内システムや他サービスへの横展開

対策1:攻撃者に試行を続けさせない

試行回数制限とレート制限

最初に入れたいのは、短時間で大量試行できない設計です。一定回数の失敗後に待機時間を入れる、段階的に遅延させる、IPや端末単位で制御する、といった方法で総当たりの速度を落とします。単純な固定ロックアウトだけでは、第三者によるロック誘発で正規利用者が入れなくなることもあるため、運用影響も見ながら調整します。

汎用的なエラーメッセージ

「ユーザーが存在しない」「パスワードが違う」を分けて返すと、IDの有効性を教えることになります。失敗時は、認証に失敗したことだけを返す形に寄せた方が、アカウント列挙と総当たりの両方をやりにくくできます。

CAPTCHAは補助策として使う

CAPTCHAは自動化された試行の難度を上げますが、単独で完結する対策ではありません。OWASPでも、レート制限やロックアウトと組み合わせる補助策として扱われています。利用者体験を損ねやすい場面もあるため、失敗回数の増加時だけ出すなど、条件付きで使う方が運用しやすくなります。

ログ監視と自動遮断

短時間の大量失敗、同一IDへの連続試行、普段使わない地域やIPからの試行などは、総当たりの兆候として扱います。大事なのは、検知後の動作まで決めることです。誰が確認し、どこまで自動遮断し、いつ利用者へ通知し、どの条件でパスワード変更や追加認証を要求するかを運用へ落とします。

対策2:試行しても意味がない状態を作る

長さを優先したパスワード方針

長いパスワードやパスフレーズは、総当たりの探索空間を大きくします。NISTは、長さを許容し、任意の文字種混在を一律に強制するより、長い候補を受け入れる考え方を示しています。複雑性ルールだけに頼るより、長さと漏えい済み候補の拒否へ寄せた方が、運用面でも破綻しにくくなります。

漏えい済み・推測しやすい候補を弾く

単語、会社名、連番、季節名、既知の漏えいパスワードは、長さが足りていても狙われやすくなります。パスワード変更時や新規登録時に、漏えいリストや拒否リストと照合する設計を入れると、攻撃者にとって当たりやすい候補を減らせます。

パスワードの定期変更は無条件で回さない

定期変更を一律に求めると、規則的な変更や使い回しが増えやすくなります。NISTは、漏えいの証拠や利用者からの要請がない限り、任意の周期での強制変更を求めない考え方を示しています。変更頻度を増やすより、長いパスワード、漏えい候補の排除、パスワードマネージャーの利用を組み合わせた方が、実運用では安定しやすくなります。

多要素認証

パスワードが見つかっても、追加要素がなければログインできない状態を作れます。まずは管理者、外部公開システム、VPN、SSO、クラウド管理画面から優先して適用すると、被害を抑える効果が見えやすくなります。

パスワードレスや証明書ベースの認証

FIDO2、パスキー、電子証明書のように、再利用できるパスワードへ依存しない方式を使うと、総当たりの成立条件そのものを崩しやすくなります。ただし、登録、失効、端末紛失時の復旧、例外運用まで決めて初めて安定します。

実装時に見落としやすい論点

認証画面だけ守って終わらせない

本番ログイン画面に対策を入れても、パスワード再設定、管理者用ログイン、API、VPN、古い公開フォームが弱いままだと、別の入口から突破されます。OWASPは、認証周辺の機能も含めて総当たり対策を求めています。

管理者アカウントを後回しにしない

利用頻度が低い管理者アカウント、共有管理者、初期設定のまま残ったアカウントは狙われやすくなります。一般利用者より先に、管理者側の認証方式、ログ、例外運用を点検した方が被害を抑えやすくなります。

突破後の動きまで前提にする

認証突破だけを防ぐ発想では足りません。突破後に何が見えるか、どこまで設定変更できるか、どのログが残るか、どのタイミングで検知できるかまで見ておくと、被害拡大を抑えやすくなります。WAFIDSIPSは補助になりますが、認証方式そのものの弱さは別途詰める必要があります。

まとめ

ブルートフォースアタックは、単純ですが軽く見てよい攻撃ではありません。成功しやすい条件は、短いパスワード、試行制限の弱さ、推測しやすいID、パスワード単独認証の残存です。対策では、レート制限、汎用的なエラーメッセージ、監視で試行を鈍らせ、長いパスワード、漏えい候補の排除、多要素認証、パスワードレスで突破の意味を薄くする考え方が有効です。

確認の順番を誤ると、複雑なパスワード方針だけが残って、試行制限も追加認証も弱い状態になりがちです。まずは、認証画面、管理者アカウント、パスワード再設定、APIの入口を洗い出し、「大量試行ができるか」「突破後に止められるか」の二点で点検してください。

よくある質問(FAQ)

Q.ブルートフォースアタックと辞書攻撃の違いは何ですか?

A.ブルートフォースアタックは候補を総当たりで試す攻撃です。辞書攻撃は、単語や漏えい済み候補のような当たりやすいパスワードから優先して試します。

Q.リバースブルートフォースアタックとは何ですか?

A.パスワード候補を固定または少数に絞り、ユーザーID側を多数試す手法です。IDが推測しやすい環境では効率が上がりやすくなります。

Q.パスワードを長くすればそれだけで十分ですか?

A.十分ではありません。長さは総当たりへの耐性を上げますが、使い回し、フィッシング、端末感染、追加認証の欠如は別の弱点として残ります。

Q.ロックアウトだけで対策は足りますか?

A.足りません。ロックアウトは有効ですが、第三者によるロック誘発で正規利用者が入れなくなることもあります。レート制限、段階的な遅延、追加認証と組み合わせた方が運用しやすくなります。

Q.CAPTCHAは対策になりますか?

A.自動化された試行の難度を上げる補助策として使えます。ただし、単独で完結する対策ではないため、レート制限や多要素認証と組み合わせた方が効果につながりやすくなります。

Q.パスワードの定期変更は必須ですか?

A.無条件の定期変更を一律に回す運用は推奨されにくくなっています。漏えいの証拠や利用者の申告がある場合に変更させる設計の方が、使い回しや規則的変更を減らしやすくなります。

Q.多要素認証はブルートフォースアタック対策として効きますか?

A.効きます。パスワードが見つかっても追加要素がなければ入れないため、突破後の不正利用を抑えやすくなります。

Q.エラーメッセージでアカウントの有無を区別するのは危険ですか?

A.危険です。ユーザーIDの列挙を助けることがあるため、認証失敗時は原因を分けずに返す設計がよく使われます。

Q.ログ監視では何を見ればよいですか?

A.短時間の大量失敗、同一IDへの連続試行、普段使わない端末やIPからの試行、深夜帯の不自然な認証失敗などを確認します。検知後の遮断や通知手順まで決めておくと運用しやすくなります。

Q.パスワードレスはブルートフォースアタックを防げますか?

A.パスワードへ依存しない認証へ移すことで、総当たりの成立条件を崩しやすくなります。ただし、登録、失効、復旧の運用まで含めて設計しないと安定しません。

記事を書いた人

ソリトンシステムズ・マーケティングチーム