web-dev-qa-db-ja.com

* un *-認証されたリクエストのレート制限

レート制限も行うロードバランサーがあるとします。レート制限は、ログインしているユーザーにとって非常に簡単なようです。JWTを確認し、メモリ内のデータストアを使用して、そのユーザーの過去10秒間のリクエスト数を確認してください。

ただし、ログインしていない(認証されていない)ユーザーについてはどうですか?誰からのリクエストなのか、どこからリクエストされたのかは正確にはわかりません。そのため、これらのリクエストを簡単にレート制限することはできません。

AWSや他のホスティングプラットフォームにこれに対する組み込みのソリューションはありますか?ログインしたユーザーのレート制限ロジックを手動で処理する必要があるようですが、ログインしていないユーザーはどうですか?

私の推測/希望は、ホスティングプラットフォームで認証されていないリクエストをレート制限するための組み込みメカニズムがあるかもしれないことです。すべてお知らせください。

11
user290257

ただし、ログインしていない(認証されていない)ユーザーについてはどうですか?誰からのリクエストなのか、どこからリクエストされたのかは正確にはわかりません。そのため、これらのリクエストを簡単にレート制限することはできません。

あなたが取ることができるいくつかのアプローチがあります。 1つは、IPアドレスなど、かなり信頼できるOrigin識別子が必要なことです。 IPアドレスでレート制限を行うことができるため、侵害された単一のマシンへの攻撃が制限されます。これは非常に単純なアプローチですが、大規模なネットワークプロバイダーが単一の送信IPアドレスしか使用できないため、NATの背後に非常に多くのユーザーを隠すことができるという欠点があります。

使用できるレート制限の別のアプローチは、認証されていない要求に対して 作業の証明 を要求することです。サーバーはチャレンジコードを発行します。認証されていないリクエスト(ログインリクエストなど)を行うクライアントは、リクエストが処理される前にリソースを大量に消費するレスポンスを計算する必要があります。このアイデアの一般的な実装では、クライアントが部分的なハッシュ復元を計算する必要があります。

9
Lie Ryan

リクエストが認証されたユーザーからのものか匿名ユーザーからのものかを知るには、必ずリクエストを処理する必要があります(ただし迅速に)。これは、アプリケーションがサービス拒否攻撃に対して脆弱であることを意味します。

1秒あたりの全体的なリクエストを確認する必要があります。特定の数を超えた場合は、残りを無視するだけです。その数は、通常の機能中に問題を引き起こさないように十分に高くする必要がありますが、そのような攻撃から保護する必要があります。

また、原則として、少なくともDOS攻撃に関しては、認証されたユーザーからの攻撃ではないと想定しないでください。弱いパスワードは、誰かが古いユーザーの身元を簡単に推測できるようにします。したがって、そのようなチェックを行うことができると仮定すると、(人間の)ユーザーは、多数の個々のユーザーがいるからといって、そのようなレートで要求を実行する必要はありません。

6
Neil

Cloudflareの主要製品 の1つは、API/Webサーバーにインテリジェントなプロキシを提供することにより、サービス拒否攻撃に対する保護です。基本サービスは無料です。彼らは、CDNサービスやロードバランシングのような他の関連サービスから収益を得ています。また、より洗練された制御可能な Rate Limiting サービスを提供しています。現在のところ、1万件の有効なリクエストごとにUS $ .05のレートです(拒否されたリクエストは無料です)。 1つのグローバルルールよりも。

ドメインのネームサーバーを制御できる限り、AWSやその他のプラットフォームでCloudflareのサービスを使用できます(ドメインに登録されているネームサーバーを変更できます)。

ログインユーザーを別のURLに誘導することで、匿名ユーザーとログインユーザーに別々のレート制限を提供できます。たとえば、匿名で使用できるすべてのURLパスの前に単に「/ u」を付けるだけで、常に認証を必要とし、レート制限が異なるエンドポイントを作成できます。

Cloudflareのレート制限(私が知っている匿名ユーザーに対するすべての商用レート制限と同様)は、クライアントをIPアドレスで定義することに注意してください。プライバシーを高めるために、多数のクライアントを1つのIPアドレスの背後に隠す傾向があるため、これは商用VPNまたはTorを使用する人々に問題を引き起こす可能性があります。

0
Old Pro

AWSには、関連サービス AWSシールドおよびAWS WAF があります。これらは主にDDoS攻撃の防止を目的としていますが、IPアドレスに基づくレート制限もサポートしています。

WAFでは、コンセプトは Rate-Based Rules と呼ばれます。ブルートフォースに基づくログイン試行の防止は、ユースケースとして 元の発表 に記載されています。

この新しいタイプのルールは、顧客のWebサイトとAPIを、WebレイヤーのDDoS攻撃、ブルートフォースログインの試行、悪質なボットなどの脅威から保護します。レートベースのルールは、クライアントからのWebリクエストが特定の設定可能なしきい値を超えると自動的にトリガーされます。

他のクラウドプロバイダーも同様のサービスを提供する必要があります。ここに表形式の比較があります: Google Cloud Armor vs. AWS WAF vs. Cloudflare WAF

すでにNginxを使用しているので、組み込みのIPベースのレート制限を使用することも簡単なオプションです。モジュールは ngx_http_limit_req_module と呼ばれます。この ブログ投稿 は、それをどのように使用できるかを説明しています。

IPベースのレート制限は比較的単純な概念ですが、完全ではないことに注意してください。

  • IPアドレスが共有されている可能性があり(同じオフィスで働いている人々)、誤検知につながります
  • 攻撃者は複数のIPアドレスに簡単にアクセスでき、それらを使用して制限を回避する可能性があります(分散型ブルートフォースログイン攻撃)

一般に、IPアドレスが適切な出発点です。ただし、より強力な保護が必要な場合、最適な選択はスレッドモデル(どの種類の攻撃を防止するか)によって異なります。

0
Philipp Claßen