Web サイトに RESTful API を実装しようとしています (WCF データ サービスに基づいていますが、おそらく問題にはなりません)。
この API を介して提供されるすべてのデータは、サーバーの特定のユーザーに属しているため、それらのユーザーのみがリソースにアクセスできるようにする必要があります。このため、すべてのリクエストは、リクエストの一部としてログイン/パスワードの組み合わせを使用して実行する必要があります。
このシナリオでブルート フォース攻撃を防ぐために推奨されるアプローチは何ですか?
資格情報が間違っているために拒否された失敗したリクエストをログに記録し、失敗したリクエストの特定のしきい値を超えた後、同じ IP からのリクエストを無視することを考えていました。これは標準的なアプローチですか、それとも重要な何かが欠けていますか?
NAT ゲートウェイの数が多いため、IP ベースのブロック自体は危険です。
クライアントがあまりにも多くのリクエストをすばやく行うと、クライアントの速度が低下する (タール ピット) 可能性があります。つまり、応答する前に意図的に数秒の遅延を挿入します。人間が文句を言う可能性は低いですが、ボットの速度が低下しました。
Web サイトの場合と同じアプローチを使用します。特定のウィンドウ内で失敗したログイン試行の回数を追跡します。たとえば、15 分などの妥当な期間内に 3 回 (または 5 回または 15 回) を許可します。しきい値を超えた場合は、アカウントをロックアウトし、ロックアウトが発生した時刻をマークします。このイベントもログに記録できます。別の適切な期間 (たとえば 1 時間) が経過したら、アカウントのロックを解除します (次のログイン試行時)。ログインが成功すると、カウンターと最後のロックアウト時間がリセットされます。ロックアウトされたアカウントで実際にログインを試みることはなく、単に login failed を返すだけであることに注意してください。
これにより、ブルート フォース攻撃が効果的にレート制限され、妥当なパスワードに対する攻撃が成功する可能性が非常に低くなります。上記の数値を使用する攻撃者は、1.25 時間あたり 3 回 (または 5 回または 15 回) しか試行できません。ログを使用して、同じ日に同じアカウントから複数のロックアウトを探すだけで、そのような攻撃がいつ発生した可能性があるかを検出できました。サービスはプログラムによって使用されることを意図しているため、サービスにアクセスするプログラムが資格情報を適切に設定すると、攻撃が進行中でない限り、ログインに失敗することはありません。これは、攻撃が発生している可能性があることを示す別の兆候です。攻撃が進行中であることがわかったら、問題のある IP へのアクセスを制限するか、必要に応じて当局を関与させるためのさらなる対策を講じて、攻撃を停止させることができます。