Rate Limiting Rules

解決する課題

• ログインページや検索APIなど特定のエンドポイントに対する総当たり攻撃やブルートフォースを止めたい
• 特定のクライアントによるAPI乱用やスクレイピングでオリジンの負荷が跳ね上がるのを防ぎたい
• DDoS対策だけではカバーしきれない、正常な形式だが過剰な頻度のリクエストを制御したい
• オリジン側にレート制御ロジックを実装せず、エッジ側で一元的にしきい値制御を完結させたい

主要概念と用語

• レートリミティングルール（Rate Limiting Rule）: 特定の条件に一致するリクエストの発生頻度を監視し、しきい値を超えた場合にアクションを実行する設定単位
• マッチ条件（Request Matching）: どのリクエストをカウント対象とするかを、URLパス・ホスト名・ヘッダーなど式（Expression）で指定する条件
• カウンティングキャラクタリスティック（Counting Characteristic）: 送信元IPやCookie、ヘッダー値など、リクエストをどの単位でグルーピングして数えるかを決める要素
• 期間（Period）としきい値（Threshold）: 一定期間内に許容するリクエスト数の上限。この期間内で条件に合致した回数がしきい値を超えると発火する
• ミティゲーションタイムアウト（Mitigation Timeout）: しきい値超過後にアクションを適用し続ける期間。この間は新たなリクエストも継続して制御される
• アクション（Action）: しきい値超過時に実行する処理。ブロック、チャレンジ（人間確認）、ログのみなど複数の選択肢がある
• カウンティングエクスプレッション（Counting Expression）: レスポンスコードなど、成功したリクエストのみをカウントするかどうかを絞り込む条件（例えば認証失敗のみを数える設定）

仕様・制限・クォータ

• レート制御はゾーン（ドメイン）単位、またはアカウント全体に及ぶルールセットの一部として設定する
• 1つのルールで指定できる期間・しきい値・ミティゲーションタイムアウトの組み合わせには、プランに応じた範囲がある
• ルールの評価順序はWAFの他のルール（カスタムルール、マネージドルールなど）と同じ実行順に組み込まれ、上から順に評価される
• カウントは基本的に各Cloudflareのエッジロケーションをまたいでグローバルに集計されるが、集計方式の詳細は仕様変更が入りやすいため公式ドキュメントの記載を優先して確認する
• 作成できるルール数やプラン別の上限は契約プランによって異なる

内部の仕組み

Rate Limiting Rulesは、リクエストがCloudflareのエッジに到着するたびにマッチ条件を評価し、条件に合致したリクエストをカウンティングキャラクタリスティックの単位（例えば送信元IPごと）で集計します。

指定した期間内のカウントがしきい値を超えると、そのグループ（例えば同一IP）からの以降のリクエストに対してミティゲーションタイムアウトの間、指定したアクションが適用されます。カウンティングエクスプレッションを併用すれば、単純なアクセス数ではなく「認証失敗のレスポンスだけを数える」といった、より意図に沿った検知が可能になります。

設計パターン / ベストプラクティス

• ログインエンドポイントには、認証失敗レスポンスのみをカウントするルールを設定し、正規ユーザーの通常利用を妨げずにブルートフォースを検知する
• API公開エンドポイントには、APIキーやトークンをカウンティングキャラクタリスティックに使い、クライアント単位で公平にしきい値を適用する
• 最初はログのみ（Log）でアクションを設定して既存トラフィックへの影響を観察し、誤検知が少ないことを確認してからブロックやチャレンジへ切り替える
• 単一IPからの攻撃だけでなく、分散した多数のIPからの低頻度アクセスも想定し、他のセキュリティ機能（Bot Managementなど）と役割分担する
• しきい値は業務上の正常なピーク挙動（バッチ処理や一括操作など）を踏まえて設定し、過剰な誤ブロックを避ける

運用・監視

• ダッシュボードのセキュリティイベントログで、どのルールがどの頻度で発火しているかを継続的に確認する
• しきい値超過によるブロック・チャレンジの発生状況を監視し、想定外の急増があれば攻撃の予兆として扱う
• ルール変更時は本番反映前にログのみモードで挙動を検証し、意図しない正規トラフィックへの影響がないかを確かめる
• 他のWAFルールとの評価順序や重複適用がないかを定期的に見直す

コスト

Rate Limiting Rulesは多くの場合、契約プランに応じてルール数や利用可否が変わる形で提供されます。追加のルールや高度な条件を使う場合に上位プランやアドオンが必要になることがあり、具体的な料金や上限は変わりやすいため、契約中のプランと公式の料金ページで確認することが望ましいです。

セキュリティ

• ログイン・パスワードリセット・検索など悪用されやすいエンドポイントを優先的に保護対象にする
• カウンティングキャラクタリスティックを工夫し、単純な送信元IPだけでなく認証トークンやセッションCookie単位での制御も検討する
• アクションには**ブロックだけでなくチャレンジ（人間確認）**も選択肢に入れ、正規ユーザーへの影響を抑えつつ自動化された攻撃を減速させる
• レート制御はDDoS対策やBot Managementを代替するものではなく、あくまで特定パターンの過剰アクセスに対する補完策として位置づける

関連サービス・比較

Rate Limiting RulesはCloudflare WAFのルールセットの一部として動作し、他のWAFルールやBot Managementと組み合わせて使います。AWSでは類似の役割をAWS WAFのレートベースルールが担います。

ハンズオン / CLI例

Rate Limiting Rulesはダッシュボードから設定するのが一般的ですが、wranglerでAPIトークンの状態を確認したうえで、Cloudflare APIを直接呼び出してルールを作成する例を示します。

# wrangler経由でCloudflare APIトークンの有効性を確認
wrangler whoami

# ゾーンのルールセット一覧を取得し、対象となるカスタムルールセットのIDを確認
curl -X GET "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets" \
  -H "Authorization: Bearer ${CF_API_TOKEN}"

# レートリミティングルールをルールセットに追加する例
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/${RULESET_ID}/rules" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "action": "block",
    "expression": "(http.request.uri.path eq \"/login\")",
    "description": "login-brute-force-protection",
    "ratelimit": {
      "characteristics": ["ip.src"],
      "period": 60,
      "requests_per_period": 20,
      "mitigation_timeout": 600
    }
  }'

# 作成済みルールの一覧を確認
curl -X GET "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/${RULESET_ID}" \
  -H "Authorization: Bearer ${CF_API_TOKEN}"