eCDN レート制限ルール

レート制限ルールを使用することにより、特定の式に一致するリクエストのレート制限を指定し、そのレート制限に達したときにアクションを実行できます。レート制限ルールを使用して、特定のトラフィックパターンをターゲットにしてボットなどの脅威に対抗することで、ストアフロントの可用性を向上することができます。

このガイドでは、関連するさまざまなレート制限パラメーターの概要とともに、CDN-API を使用してこれらのルールをゾーンで有効にする方法について説明します。このページの下部にあるよくある質問 (FAQ) セクションも参照してください。

レート制限ルールの動作は、レート制限パラメーターの数によって異なります。

  • 説明
  • ルール式
  • 特性
  • アクション
  • 期間
  • 期間ごとのリクエスト
  • 緩和タイムアウト (Block ルールまたは Log ルールの場合のみ)
  • カウント式 (オプション)
  • 有効 (オプション)
  • 位置 (オプション)
  • API での使用法: description
  • レート制限ルールの説明。
  • API での使用法: expression
  • レート制限ルールを評価するタイミングを定義します。つまり、受信リクエストがルール式に一致する場合に、レート制限ルールが評価されます。ルールの評価時にレート制限基準が満たされると、ルールのアクションが実行されます。
    • 比較演算子:
      • eq, ne, contains, matches, in, lt, le, gt, ge
    • 論理演算子:
      • not, and, or, xor
    • フィールド:

フィールド

説明

式での使用法

タイプ


AS Number

クライアント IP アドレスに関連付けられた自律システム (AS) 番号。

ip.geoip.asnum

Integer

ip.geoip.asnum eq 12345

Cookie

Cookie 全体を文字列として表します。

http.cookie

String

http.cookie eq \"session=8521F670545D7865F79C3D7BEDC29CCE;-background=light\"

Country

ISO 3166-1 Alpha 2 形式の 2 文字の国コードを表します。

ip.geoip.country

String

not ip.geoip.country eq \"US\"

Host Name

完全なリクエスト URI で使用されるホスト名を表します。

http.host

String

http.host eq \"www.example.com\"

IP Address

クライアントの TCP IP アドレスを表します。

ip.src

IP address

ip.src in {93.184.216.34 192.168.123.132}

HTTP Headers

HTTP リクエストヘッダーを Map (または連想配列) として表します。

http.request.headers

Map<String><Array>

any(http.request.headers[\"content-type\"][*] eq \"application/json\")

URI Full

Web サーバーが受信した完全な URI を表します。

http.request.full_uri

String

http.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"

URI

リクエストの URI パスとクエリ文字列を表します。

http.request.uri

String

http.request.uri eq \"/path/index?section=123456&expand=comments\"

URI Path

リクエストの URI パスを表します。

http.request.uri.path

String

http.request.uri.path eq \"/path/index\"

URI Query String

? 区切り文字を除いたクエリ文字列全体を表します。

http.request.uri.query

String

http.request.uri.query eq \"section=123456&expand=comments\"

Raw URI Full

http.request.full_uri 非 raw フィールドと同様です。Web サーバーが受信した完全な URI を表します。URI フラグメント (存在する場合) は含まれず、変換も行われません。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。

raw.http.request.full_uri

String

raw.http.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"

Raw URI

http.request.uri 非 raw フィールドと同様です。リクエストの URI パスとクエリ文字列を変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。

raw.http.request.uri

String

raw.http.request.uri eq \"/path/index?section=123456&expand=comments\"

Raw URI Path

http.request.uri.path 非 raw フィールドと同様です。リクエストの URI パスを変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。

raw.http.request.uri.path

String

raw.http.request.uri.path eq \"/path/index\"

Raw URI Query String

http.request.uri.query 非 raw フィールドと同様です。? 区切り文字と変換を含まないクエリ文字列全体を表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。

raw.http.request.uri.query

String

raw.http.request.uri.query eq \"section=123456&expand=comments\"

HTTP Referer

現在リクエストされているページにリンクされている Web ページのアドレスを含む HTTP Referer リクエストヘッダーを表します。

http.referer

String

http.referer contains \"www.example.com\"

User Agent

HTTP ユーザーエージェントを表します。これはクライアントオペレーティングシステムと Web ブラウザーの識別を可能にする特性文字列を含むリクエストヘッダーです。

http.user_agent

String

http.user_agent eq \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.61 Safari/537.36\"

Request Method

HTTP メソッドを表し、大文字の文字列として返されます。

http.request.method

String

http.request.method eq \"GET\"

Continent

クライアント IP アドレスに関連付けられた大陸コードを表します。
AF – アフリカ
AN – 南極大陸
AS – アジア
EU – ヨーロッパ
NA – 北アメリカ
OC – オセアニア
SA – 南アメリカ
T1 – Tor ネットワーク

ip.geoip.continent

String

ip.geoip.continent in {\"NA\" \"EU\"}

Bot Score*

リクエストがボットから発信された可能性を 1 ~ 99 のスコアで表します。スコアが低い場合は、リクエストがボットまたは自動エージェントからのものであることを示します。

cf.bot_management.score

Integer

cf.bot_management.score le 10

Threat Score

0 ~ 100 の脅威スコアを表します。0 はリスクが低いことを示します。10 を超える値はスパマーまたはボットを表している可能性があり、40 を超える値はインターネット上の悪意ある人物を識別します。
60 を超える値はまれです。一般的な推奨事項は、10 を超えるスコアのリクエストにチャレンジを提示し、50 を超えるリクエストをブロックすることです。

cf.threat_score

Integer

cf.threat_score gt 50

JA3 Fingerprint*

潜在的なボットリクエストの識別に役立つ SSL/TLS フィンガープリントを提供します。

cf.bot_management.ja3_hash

String

cf.bot_management.ja3_hash eq \"e7d705a3286e19ea42f587b344ee6865\"

Verified Bot*

true の場合、このフィールドはリクエストが既知の良好なボットまたはクローラーから発信されたことを示します。cf.client.bot と同じ情報を提供します。

cf.bot_management.verified_bot

Boolean

cf.bot_management.verified_bot

cf.bot.management.* フィールドを使用するには、ボット管理を有効にして独自の Cloudflare アカウント (o2o) を実装する必要があります。

レート制限ルール式の長さは最大 4096 文字です。

  • API での使用法: characteristics
  • 文字列の配列を受け取ります。特性により、受信リクエストがどのようにグループ化されるかが決まります。定義された特性と同じ値をもつリクエストはグループ化され、レートカウンターを共有します。
    • たとえば、ルールの特性として IP が使用されるとしましょう。単一の IP アドレスからのリクエストのレートが、定義された制限を超える場合、その IP アドレスからのさらなるリクエストのレートは制限されます。他の IP アドレスからのリクエストは、同じレートカウンターを共有しません。つまり、1 つの IP アドレスのリクエストレートは、他の IP アドレスのリクエストレートに影響を与えません。
  • 以下の特性がサポートされます。
特性説明特性配列での使用法
IPクライアントの TCP IP アドレスに基づいてリクエストをグループ化します。ip.src
NAT サポート付き IP同じ IP アドレスを共有する NAT のもとでのリクエストなどの状況を含め、プライバシー保護技術を使用してユニーク訪問者数を識別します。cf.unique_visitor_id
  • 同じレート制限ルールの特性として「 NAT サポート付き IP 」と「 IP 」の両方を使用することはできないことに注意してください。したがって、API の使用例は次のとおりです。

    "characteristics": ["ip.src"]

    または

    "characteristics": ["cf.unique_visitor_id"]

推奨事項は、NAT サポート付きの IP を使用することです。詳細については、よくある質問 (FAQ) を参照してください。

  • API での使用法: action
  • レート制限基準が満たされた場合に実行するアクションです。
  • サポートされているアクション: blockloglegacy_captchajs_challengemanaged_challenge
    • 各アクションの詳細については、こちらのドキュメントを参照してください。
  • API での使用法: period
  • リクエストレートを評価する際に考慮する期間。
  • サポートされている値: 1060120300600 (単位: 秒)。
  • API での使用法: requestsPerPeriod
  • 任意の正の整数値。指定された期間内のリクエスト数の制限を表します。
  • API での使用法: mitigationTimeout
  • 「タイムアウト」の時間。レート制限基準が満たされると、レート制限ルールは、このフィールドで定義された期間、ルール式に一致するさらなるリクエストにアクションを適用し続けます。
    • block または log アクションを使用するルールにのみ関連します。このパラメーターは、チャレンジアクション (legacy_captchajs_challengemanaged_challenge) を使用するルールには指定できません。
  • サポートされている値: 60120300600360086400 (単位: 秒)。
    • mitigationTimeout の値も、定義された period 以上である必要があります。
  • API での使用法: countingExpression
  • レート制限を適用するリクエスト基準を定義します。つまり、このパラメーターはレートカウンターをインクリメントするタイミングを定義します。レートカウンターは、期間ごとにリクエスト数を追跡 ​​ します。レートカウンターが、設定した期間ごとに定義されたリクエスト制限を超えると、ルールのアクションが実行されます。
    • カウント式が指定されていない場合、カウント式はルール式と同じになります。
    • カウント式は、HTTP レスポンスコードに基づいてレート制限するオプションをサポートしています。 ルール式のみを使用する場合、これはできません。HTTP レスポンスコードに基づいてレート制限を行う場合は、カウント式を使用する必要があります。カウント式を使用する場合のその他の例については、よくある質問 (FAQ) を参照してください。
  • カウント式の検証はルール式と同じですが、次のフィールドが追加されています。
フィールド説明カウント式での使用法タイプ
HTTP Response Codeクライアントに返される HTTP ステータスコードを表します。http.response.codeInteger``http.response.code eq 400
  • API での使用法: enabled
  • レート制限ルールが有効かどうかを指定します。デフォルト値は true です。
  • API での使用法: position

  • このパラメーターを指定すると、ルールセット内の特定の相対位置にルールが挿入されます。このパラメータは、レート制限ルールを作成または更新するときに使用できます。

    • 提供されたインデックスが現在のルールセット内のルールと一致するかを検証します。レート制限ルールの作成時に位置が指定されていない場合、そのルールはデフォルトでルールセットの最後に追加されます。

次のセクションでは、レート制限ルールの一般的なユースケースについて説明します。これらの例を使用し、必要に応じて組み合わせて、独自のビジネスニーズに合わせて調整してください。

  • ユーザーエージェント、IP アドレス、ホスト、国、世界の地域などの基準に基づくアクセス管理を含む、リソースへのきめ細かいアクセス管理を実施します。
  • 例 A: 個々のユーザーエージェントによって実行されるリクエストの速度を制限します。
    • ルール式: http.user_agent eq "MobileApp"
    • レート: 100 件のリクエスト/ 10 分
    • アクション: 管理されたチャレンジ
  • 例 B: 特定の IP アドレスまたは ASN をレート制限ルールに含める、または除外します。
    • ルール式: http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in { <defined IPs> }
    • レート: 10 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • クレデンシャルスタッフィングやアカウント乗っ取り攻撃から保護します。一般的なユースケースは、ログインエンドポイントを保護することです。また、複数のレート制限ルールを作成し、増加するペナルティを定義して、リクエストが多すぎるクライアントを管理することもできます。
  • 例 A: ログイン失敗回数が多すぎる場合の保護。
    • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
    • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
    • レート: 5 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • 例 B: ユーザーが例 A で定義されたルールによって提示されたチャレンジにパスした場合に備えて、別の保護層を作成します。ユーザーがこの 2 番目のしきい値を超えると、ログインページへのアクセスは 10 分間ブロックされます。
    • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login"
    • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
    • レート: 20 件のリクエスト/ 10 分
    • アクション: 10 分間ブロック
  • 個々のクライアントが実行するオペレーションの数を制限します。ボットによるスクレイピング、機密データへのアクセス、新しいアカウントの一括作成、自動買い付けを防ぎます。
  • 例 A: (クエリ文字列による) コンテンツのスクレイピングを防ぎます。
    • ルール式: http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
    • レート: 10 件のリクエスト / 1 分
    • アクション: 管理されたチャレンジ
  • 例 B: ボットからのリクエストを制限します。ボットからのトラフィックを識別する一般的な方法は、エラーレスポンスのステータスコードを大量にトリガーするリクエストをレート制限することです。
    • ルール式: http.host eq "example.com"
    • カウント式: http.response.code in {401 403}
    • レート: 25 件のリクエスト/ 2 分
    • アクション: 管理されたチャレンジ
  • 例 C: ゾーンにボット管理の資格がある場合は、bot_management フィールドの使用を検討します。
    • ルール式: cf.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
    • レート: 20 件のリクエスト/ 5 分
    • アクション: 1 時間ブロック

このエンドポイントは、指定されたゾーンのレート制限ルールを作成します。

  • パラメーター検証の詳細については、上記の レート制限パラメーター セクションを参照してください。

新しく作成されたルールはデフォルトで有効になり、特に指定のない限り、ルールセットの最後に追加されます。1 つのゾーンで最大 3 つのレート制限ルールが許可されます。

成功レスポンス - 201 HttpStatus コードの例 レスポンスボディには、作成されたレート制限ルールが含まれます。

このエンドポイントは、指定されたゾーンのすべてのレート制限ルールを優先順位に従って返します。レート制限ルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、指定されたゾーンの現在のレート制限ルールがすべて含まれます。

このエンドポイントは、リクエストされたレート制限ルールを返します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを更新します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

  • 少なくとも 1 つのレート制限パラメーターをリクエストボディに指定する必要があります。
  • countingExpression を設定したが、それを削除したい (したがってルール式のデフォルトにしたい) というシナリオでは、リクエストボディに "countingExpression": "" を含めて値をリセットする必要があります。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを削除します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 204 HttpStatus コード (コンテンツなし) の例

  • カウント式はルール式とどのように異なりますか?
    • ルール式は、レート制限ルールを 評価 するタイミングを定義します。リクエストがルール式に一致する場合、レート制限ルールが評価されます。レート制限ルールを評価するときは、レートカウンターが、期間ごとに定義されたリクエストを超えているかどうかを確認します。超えている場合、ルールのアクションが適用されます。
    • カウント式は、レート制限する リクエストの種類 を定義します。リクエストがカウント式に一致する場合、レートカウンターがインクリメントされます。カウンターは、レート制限基準を満たしたリクエスト数を記録します。
  • カウント式はどのような場合に使用しますか?
    • ほとんどのユースケースでは、カウント式をルール式と同じにするだけで十分であり、カウント式を指定する必要はありません。
      • 例 A: 特定のパスに送信される高トラフィックをレート制限します。リクエスト数が 1 分間に 10,000 件を超えた場合、そのパスへのさらなるリクエストを 10 分間ブロックします。
        • ルール式: http.request.uri.path eq "/path"
        • カウント式 (デフォルト): http.request.uri.path eq "/path"
        • レート: 10,000 件のリクエスト / 1 分
        • アクション: 10 分間ブロック
    • 時には、HTTP レスポンスコードに基づいてレート制限を行いたい場合があります。これらのユースケースでは、カウント式を指定する必要があります。カウント式では、追加のレスポンスコードフィールドを利用できるためです。ルール式のみを使用する場合、HTTP レスポンスコードに基づくレート制限はできません。
      • 例 B: 自動化された攻撃者に対して管理されたチャレンジを提示することで、悪意のあるトラフィックでフォームが過負荷になるのを防ぎます。400 応答コードを返す特定のフォームに送信されるトラフィックをレート制限します。
        • ルール式: http.request.uri.path eq "/form"
        • カウント式: http.request.uri.path eq "/form" and http.response.code eq 400
        • レート: 15 件のリクエスト/ 5 分
        • アクション: 管理されたチャレンジ
    • 次に挙げるのは、カウント式をルール式と異なるものとする別の例です。
      • 例 C: 悪意のある攻撃者からログインエンドポイントを保護します。ユーザーが 10 分間に 15 回の不正なログインリクエストを行った場合、そのユーザーはサイト 全体 へのアクセスを 1 時間ブロックされます。
        • ルール式: http.host eq "example.com"
        • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
        • レート: 15 件のリクエスト/ 10 分
        • アクション: 1 時間ブロック
  • 特性はどのように機能しますか?
    • 定義されたルールの特性の値の組み合わせごとに、個別のレートカウンターが保持されます。つまり、特性によって、受信リクエストがどのようにグループ化されるかが決まります。
      • 次の特性で構成されたルールを考えてみましょう。
        • IP アドレス
        • HTTP ヘッダー x-api-key
      • この場合、HTTP ヘッダー X-API-Key の値は同じですが、IP アドレスが 異なる 2 つの受信リクエストは、値の組み合わせが異なるため、別々にカウントされます。さらに、カウンターはデータセンター間で共有はされません。
    • CDN-API は現在、「 IP 」または「 NAT サポート付き IP 」のみを特性として受け入れ、これら 2 つの特性を同じレート制限ルールで使用することはできないことに注意してください。したがって、上で示した使用例は今回は関係ありませんが、特性がどのように機能するかを理解するのに役立つ例となります。
  • NAT サポート付きの IP の使用が推奨されるのはなぜですか?
    • 同じ IP アドレスで eCDN にリクエストが入ってくる可能性がある状況でもユニーク訪問者を識別できるため、NAT サポート付き IP を使用することをお勧めします。
    • NAT サポート付き IP の使用は、スタック型 eCDN 構成を使用している顧客に必要です。 これは、リクエストが eCDN に到達する前にスタックされたプロバイダーを経由してルーティングされるためです。NAT サポート付き IP を使用すると、それぞれのユニーク訪問者が適切に識別され、スタックされたプロバイダーのソース IP はレート制限されなくなります。
  • ルールの順序が重要なのはなぜですか?
    • レート制限ルールは、リストされた最初のルールから始めて、レスポンスボディで返される順序で評価されます。特定のルールの優先度を更新するには、PATCH エンドポイントを使用し、リクエストボディに position パラメーターを指定します。
    • リクエストがレート制限基準を満たし、レート制限ルールの実行をトリガーすると、ルールのアクションが実行され、その特定のリクエストに対して他のレート制限ルールは評価されません。次のリクエストが受信されると、ルールの評価はルールセットの先頭から始まります。
  • ルール式を構築するにはどうすればいいですか?
    • ルール式の構築に関する詳細については、こちらのドキュメントを参照してください。
  • ルール式で特定のフィールドを使用するにはどうすればよいですか?
    • 特定のフィールドの使用法の詳細については、こちらのドキュメントを参照してください。