オーバーライドの例

ユースケース

次のシナリオでは、よくある HTTP DDoS Protection の問題に対して、オーバーライドルールをどう使うかを説明します。

モバイルアプリからのトラフィックが DDoS マネージドルールでブロックされる

モバイルアプリからのトラフィックが不審に見え、DDoS マネージドルールがブロックした可能性があります。

ブロックしているマネージドルールを特定し、感度レベルを Medium に変更します。それでもブロックが続く場合は、感度レベルを Low または Essentially off に設定します。

フィルター式を使える場合は、影響を受けているトラフィックだけを対象にするオーバーライドを作成できます。

位置情報に基づくアダプティブルールがトラフィックにフラグを立てており、攻撃の可能性がある

アダプティブルールがフラグを立てたトラフィックを攻撃と判断できる場合は、オーバーライドルールを作成し、アダプティブルールを緩和モードで有効にします。ブラウザーからのトラフィックなら challenge、その他の不審なトラフィックなら block を設定します。

正規トラフィックが攻撃と誤判定され、誤検知が起きる

誤検知は、誤った識別です。DDoS 保護では、正規トラフィックを攻撃トラフィックと誤って分類したときに誤検知になります。レガシーアプリケーション、インターネットサービス、不具合のあるクライアントアプリケーションが、不審に見える正規トラフィック、奇妙なトラフィックパターン、ベストプラクティスからの逸脱、プロトコル違反を生成する場合に起きることがあります。

こうしたケースでは、Cloudflare の DDoS Protection システムがそのトラフィックを悪意あるものとしてフラグし、緩和アクションを適用することがあります。実際には正規トラフィックで攻撃の一部でない場合、緩和アクションによってインターネットプロパティのサービス障害や停止が起きることがあります。

誤検知を解消するには、次の手順を実行します。

Cloudflare ダッシュボードで、Network analytics ↗ ページを開きます。
表示データにフィルターを適用します。
WAF/CDN のお客様
1. DDoS 攻撃の誤検知が起きているゾーンを選択します。
2. Security > Analytics > Events タブを開きます。
3. Add filter を選び、Service equals HTTP DDoS でフィルターします。
Magic Transit および Spectrum のお客様
1. Account Home > Analytics & Logs > Network Analytics を開きます。
2. 誤検知の原因になっている正規トラフィックを特定します。DDoS アラート（届いている場合）に含まれる Attack ID、または宛先 IP アドレスとポートなどのダッシュボードフィルターを使います。
Top events by source > HTTP DDoS rules までスクロールします。
ルール名をコピーします。
ゾーン > Security > Security rules > DDoS protection タブを開き、Create override を選びます。追加のオーバーライドをデプロイできない場合は、既存のオーバーライドを編集してルール設定を調整します。
Browse rules を選び、検索欄にルール名を貼り付けます。
ルールの Sensitivity Level を Essentially Off に下げるか、ルールアクションを Log に変更します（現在のプランとサブスクリプションで対応している場合）。
Next を選び、続いて Save を選びます。

保存すると、ルールは 1〜2 分以内に有効になります。調整はすぐに効くはずです。分析ダッシュボードで確認できます。

あとから調整したルールを更新する

あとから、誤検知の原因になっているルールの感度レベルを変更して今後の問題を防ぎ、ルールアクションを既定値に戻せます。

保護と可視性を保ちながら誤検知を避ける

高い感度レベルで DDoS マネージドルールの動作を確認しつつ、低い感度レベルで攻撃をブロックして保護を維持するには、Advanced DDoS Protection のお客様は、最初のオーバーライドで低い感度で攻撃をブロックし、2 番目のオーバーライドで高い感度でログを記録します。

オーバーライドはこの順序で設定する必要があります。そうしないと機能しません。オーバーライドは順番に評価され、式と感度の両方が一致した最初のオーバーライドで止まります。順序を間違えると、高い感度の Log オーバーライドがすべてのケースに一致します。その結果、後ろに置いた Block オーバーライドは評価されず、すべてのルールが Log モードになります。

式のないオーバーライドが一致すると、Cloudflare はその後の式を評価しません。

攻撃が正規トラフィックと誤判定され、見逃しが起きる

見逃しは、識別ができていない状態です。DDoS 保護では、攻撃トラフィックを正規トラフィックと誤って分類し、緩和しなかったときに見逃しになります。攻撃トラフィック量が緩和アクションを発動するほど高くない場合や、攻撃に一致するルールがない場合に起きることがあります。

見逃しに対処するには、次を行います。

WAF/CDN のお客様は、プロアクティブな DDoS 防御の手順に従います。Under Attack モードの有効化と、必要に応じたレート制限ルールおよび WAF カスタムルールの作成を案内しています。
Magic Transit のお客様は、Cloudflare Network Firewall ルールを使って攻撃の緩和を支援します。

緩和が不完全な場合

不完全な緩和は、DDoS 保護システムが緩和を適用したにもかかわらず、攻撃の一部しか緩和できていない状態です。Cloudflare のシステムが、攻撃に必要な厳しさより緩い緩和アクションを適用したときに起きることがあります。

システムは、ロジックと、そのトラフィックが実際に攻撃の一部であるという DDoS 保護システムの確信度に基づいて、緩和アクションを選びます。

確信度が高いルールでは、Block など厳しい緩和アクションを適用します。
確信度が低いルールでは、Challenge や Force Connection Close など、より緩い緩和アクションを適用します。

Cloudflare が検出した DDoS 攻撃を受けていて、適用された緩和アクションが十分に厳しくない場合は、ルールアクションを Block に変更します。

Cloudflare ダッシュボードで、Network analytics ↗ ページを開きます。
表示データにフィルターを適用します。
WAF/CDN のお客様
1. DDoS 攻撃の緩和が不完全になっているゾーンを選択します。
2. Security > Analytics > Events タブを開きます。
3. Add filter を選び、Service equals HTTP DDoS でフィルターします。
Magic Transit および Spectrum のお客様
1. Account Home > Analytics & Logs > Network Analytics を開きます。
2. 緩和が不完全な DDoS 攻撃を特定します。DDoS アラート（届いている場合）に含まれる Attack ID、または宛先 IP アドレスとポートなどのダッシュボードフィルターを使います。
Top events by source > HTTP DDoS rules までスクロールします。
ルール名をコピーします。
ゾーン > Security > Security rules > DDoS protection タブを開き、Create override を選びます。追加のオーバーライドをデプロイできない場合は、既存のオーバーライドを編集してルール設定を調整します。
Browse rules を選び、検索欄にルール名を貼り付けます。
ルールの Action を Block に変更します。
Next を選び、続いて Save を選びます。

保存すると、ルールは 1〜2 分以内に有効になります。調整はすぐに効くはずです。分析ダッシュボードで確認できます。

別の手順

上記の手順では Origin ウェブサーバーの過負荷を止められない場合は、次の情報を添えて Cloudflare サポートに問い合わせてください。

攻撃の期間（UTC タイムスタンプ）
対象になっているドメイン / パス（ゾーン名 / ID）
攻撃の頻度
問題を再現する手順。実際の結果と期待する結果
サイトの URL、エラーメッセージ、スクリーンショット、Origin ウェブサーバーの関連ログなど、役立つ追加情報