メインコンテンツへスキップ

開始前に

Bot Detection を有効にし、キャプチャ プロバイダーを設定しておく必要があります。
Auth0 の Bot Detection 監視機能 は、ボットネットや攻撃を早期に検知するための仕組みです。以下では、テナントへのログインを試みるボットを特定するためのガイダンスを示します。

​
注目すべきログイベントを特定する

対応を検討する際は、まず想定される攻撃に関連するログメッセージを絞り込みます。高度な分析を行うには、ログストリーミングを有効にし、任意の外部ツールに接続します。 ボットアクティビティの増加を調査する際は、次のログイベントタイプが参考になります。
Log Event TypeDescription
plaログイン前に生成されるイベントで、ボット検知が監視モードのみでボットの識別にキャプチャを使用していない場合でも記録されます。
fu無効なユーザー名によるユーザーログイン失敗イベント。ユーザー名列挙やアカウント乗っ取りの試行を示している可能性があります。
fp無効なパスワードによるユーザーログイン失敗イベント。クレデンシャルスタッフィング攻撃の試行を示している可能性があります。
pwd_leak漏えいしたパスワードを使ったログイン試行イベント。クレデンシャルスタッフィング攻撃の試行を示している可能性があります。
limit_wc単一アカウントに対してログイン失敗が >10 回発生した場合の IP ブロックイベント。この IP アドレスはボットによるものである可能性が高いことを示します。
limit_sul同じ IP アドレスから 1 分間に >20 回のログイン試行があった場合のユーザーブロックイベント。ボットアクティビティである可能性が高いことを示します。
limit_mu同じ IP アドレスからログイン失敗が >100 回、またはサインアップ試行が >50 回あった場合の IP ブロックイベント。ボットアクティビティである可能性が高いことを示します。
fcoaクロスオリジン認証の失敗イベント。攻撃者が自動化を使ってアカウント乗っ取りを試みていることを示します。
scoaクロスオリジン認証の成功イベント。少数の IP アドレスから複数のユーザーに対して、攻撃者が自動化を使ってアカウント乗っ取りを行っていることを示します。

​
攻撃への対応

レベルを High に設定すると攻撃を直ちに緩和できますが、包括的な戦略では、ビジネスのリスク許容度や技術的能力と、ユーザーのサインイン時の体験とのバランスを取る必要があります。対応する際は、主に次の 2 つの要素を考慮してください。
  • ユーザーの負担: 緩和策 (例: キャプチャ の頻度) がユーザー体験に与える影響を評価します。
  • 技術的能力: IP ブロック、WAF ルール、 の適用を実装する能力を評価します。
Auth0 は、最適な保護のために複数の緩和手法を組み合わせた多層防御アプローチを推奨しています。

​
緩和策

攻撃に対する保護を最適化するには、次の対策を検討してください。
  • 1 つ以上のフローでキャプチャを有効にし、必要に応じてキャプチャの実行頻度を上げてください。ただし、キャプチャは抑止策であり、根本的な解決策ではないことに注意してください。
  • 攻撃者に現在のキャプチャが回避されている場合は、キャプチャのプロバイダーを変更するか、Auth0 の Auth Challenge または別のサポート対象プロバイダーへの移行を検討してください。
  • サインアップ詐欺キャンペーンが疑われる場合は、公開された未認証エンドポイントからアプリケーションへの新規ユーザー登録を一時的に停止してください。
  • エッジプロバイダー側で Web アプリケーションファイアウォールのルールを変更するか、テナントアクセス制御リストを使用して、悪意のある IP、自律システム番号、地理的位置、TLS クライアント、または user-agent 文字列などの HTTP ヘッダー要素をブロックし、リバースプロキシの導入も検討してください。
  • 許可される接続数の上限を引き下げてブルートフォース攻撃を緩和するため、Brute ForceおよびSuspicious IPのしきい値を厳しくしてください。ブルートフォース攻撃の詳細については、Brute Force playbookを参照してください。
  • Cross-Origin Authentication の設定を変更して、未使用のエンドポイントを無効にしてください。漏えいしたパスワードを悪用する攻撃が疑われる場合は、Breached Password playbookを参照してください。
  • 侵害されたアカウントに対してstep-up MFAを適用し、必要に応じて侵害の可能性があるアカウントにも MFA を必須にしてください。
  • SMS ポンピング攻撃や通話料詐欺攻撃を緩和するため、SMS ベースまたは音声ベースの MFA を OTP または WebAuthn に置き換え、より強力な MFA オプションへ移行してください。