レート制限¶

無制限なリソース消費は、最も重大なAPIセキュリティリスクの一覧であるOWASP API Top 10 2023に含まれています。レート制限の欠如は、このリスクの主な原因の1つです。適切なレート制限がなければ、APIはサービス拒否(DoS)、ブルートフォース、APIの過剰利用といった攻撃に脆弱になります。本記事では、Wallarmのレート制限ルールによりAPIとユーザーを保護する方法を説明します。

WallarmはAPIへの過剰なトラフィックを防ぐために、Advanced rate limitingのルールを提供します。このルールでは、特定のスコープに対するリクエストの最大数を指定でき、着信リクエストが均等に分散されるようにも制御します。定義した上限を超えるリクエストはWallarmが拒否し、ルールで選択したコードを返します。

WallarmはCookieやJSONフィールドなどさまざまなリクエストパラメータを評価するため、発信元IPアドレスだけでなく、セッション識別子、ユーザー名、メールアドレスに基づいても接続を制限できます。この追加の粒度により、あらゆる発信元データを基準としてプラットフォーム全体のセキュリティを強化できます。

本記事で説明するレート制限は、Wallarmが提供する負荷制御の方法の1つです。代替として、ブルートフォース対策を適用できます。レート制限は受信トラフィックを減速させる目的で、ブルートフォース対策は攻撃者を完全にブロックする目的で使用します。

ルールの作成と適用¶

レート制限を設定して適用するには:

Proceed to Wallarm Console:
- Rules → Add rule or your branch → Add rule.
- Attacks / Incidents → attack/incident → hit → Rule.
- API Discovery (if enabled) → your endpoint → Create rule.
Mitigation controls → Advanced rate limitingを選択します。
If request isで、ルールを適用するスコープを記述します。
対象スコープへの接続に対する希望の上限を設定します:
- 1秒または1分あたりのリクエストの最大数。
- Burst - 指定したRPS/RPMを超過した際にバッファリングされる過剰リクエストの最大数で、レートが通常に戻ったときに処理されます。0がデフォルトです。
  
  値が0以外の場合、バッファリングされた過剰リクエストの実行間でも、定義したRPS/RPMを維持するかどうかを制御できます。
  
  No delayは、レート制限による遅延を設けずに、バッファ済みの過剰リクエストをすべて同時に処理することを意味します。Delayは、指定数の過剰リクエストを同時に処理し、残りはRPS/RPMで設定された遅延で処理されることを意味します。
- Response code - 拒否されたリクエストに対して返すコードです。デフォルトは503です。
  
  以下は、5 r/s、burst 12、delay 8の設定におけるレート制限の挙動例です。
  
  最初の8リクエスト（delayの値）はWallarmノードによって遅延なしで転送されます。次の4リクエスト（burst - delay）は、定義した5 r/sというレートを超えないように遅延されます。さらに次の3リクエストは、バースト総量を超過したため拒否されます。その後のリクエストは遅延されます。
In this part of requestで、制限を設定したいリクエストのポイントを指定します。選択したリクエストパラメータの値が同一のリクエストをWallarmが制限します。

利用可能なポイントはこちらに記載しています。ユースケースに合うものを選択してください。例:
- 発信元IPで接続を制限するにはremote_addr
- JSON本文のapi_keyパラメータで接続を制限するにはjson → json_doc → hash → api_key
値の長さに関する制限

制限の基準とするパラメータ値の最大長は8000文字です。
ルールのコンパイルとフィルタリングノードへのアップロードが完了するまでお待ちください。

ルール例¶

APIの高可用性を確保するためのIP単位の接続制限¶

あるヘルスケア企業のREST APIが、医師に対し、/patientsエンドポイントへPOSTリクエストで患者情報を送信できるようにしているとします（ホストは'https://example-host.com'）。このエンドポイントの可用性は極めて重要であり、多数のリクエストで過負荷にすべきではありません。

この/patientsエンドポイントに対し、一定期間内のIP単位で接続を制限するとこれを防げます。これにより、DoS攻撃を防止して患者情報のセキュリティを保護しつつ、すべての医師に対するエンドポイントの安定性と可用性を確保できます。

例えば、各IPアドレスごとに1分あたり5件のPOSTリクエストに制限する設定は次のとおりです:

認証パラメータへのブルートフォース攻撃を防ぐためのセッション単位の接続制限¶

ユーザーセッションにレート制限を適用することで、保護されたリソースへの不正アクセスを得る目的で有効なJWTや他の認証パラメータを見つけようとするブルートフォース試行を抑止できます。例えば、1セッションあたり1分間に10リクエストのみを許可するようレート制限を設定すると、異なるトークン値で多数のリクエストを送って有効なJWTを見つけようとする攻撃者は、すぐにレート上限に達し、期間がリセットされるまでリクエストが拒否されます。

アプリケーションが各ユーザーセッションに一意のIDを割り当て、X-SESSION-IDヘッダーに反映しているとします。URLhttps://example.com/api/loginのAPIエンドポイントは、AuthorizationヘッダーにBearer JWTを含むPOSTリクエストを受け付けます。このシナリオにおけるセッション単位の接続制限ルールは次のようになります:

Authorizationの値に使用する正規表現は`^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$です。

ユーザーセッションの管理にJWT (JSON Web Tokens)を使用している場合は、次のようにルールを調整してJWTを復号し、ペイロードからセッションIDを抽出できます:

サーバーの過負荷を防ぐための顧客ID単位の接続制限¶

オンラインショッピングプラットフォームの顧客注文データにアクセスできるWebサービスを考えます。顧客IDごとのレート制限は、短時間に過剰な注文が行われて在庫管理や出荷処理に負荷がかかる事態を防ぐのに役立ちます。

例えば、https://example-domain.com/ordersへのPOSTリクエストを各顧客あたり1分に10件へ制限するルールは、次のようになります。この例では、顧客IDがJSON本文オブジェクトdata.customer_idで渡されるものとします。

制限事項と特記事項¶

レート制限機能には次の制限事項と特記事項があります:

レート制限ルールは、すべてのSecurity Edgeおよびself-hostedのデプロイメント形態でサポートされますが、以下は対象外です:
- OOB Wallarmデプロイメント
- MuleSoft、Amazon CloudFront、Cloudflare、Broadcom Layer7 API Gateway、Fastlyのコネクタ
制限の基準とするパラメータ値の最大長は8000文字です。
複数のWallarmノードがあり、各ノードに到着するトラフィックがレート制限ルールに該当する場合、それぞれ独立して制限されます。
複数のレート制限ルールが着信リクエストに適用可能な場合、最も小さいレート上限のルールが適用されます。
着信リクエストに、ルールのIn this part of requestセクションで指定したポイントが存在しない場合、そのリクエストには本ルールによる制限は適用されません。
Webサーバー側でも接続制限（例: ngx_http_limit_req_moduleというNGINXモジュールの使用）を構成しており、同時にWallarmのルールも適用している場合、Webサーバーは自側の設定に従ってリクエストを拒否しますが、Wallarmは拒否しません。
Wallarmはレート制限を超えたリクエストを保存しません。ルールで選択したコードを返して拒否するだけです。例外は攻撃の兆候があるリクエストで、レート制限ルールにより拒否された場合でも、Wallarmによって記録されます。

rate abuse protectionとの違い¶

大量のリクエストによるリソース消費の抑制と攻撃の防止には、本稿で説明したレート制限に加えて、Wallarmはレート乱用対策も提供します。

レート制限は、レートが高すぎる場合に一部のリクエストを遅延させ（バッファに格納し）、バッファが満杯になると残りを拒否します。レートが正常に戻ると、バッファ済みのリクエストが配信され、IPやセッション単位のブロックは行いません。一方、レート乱用対策は攻撃者をIPやセッションで一定時間ブロックします。