アプリケーション(レイヤー7)DDoS防護

対象: ✔️ Application Gateway V2 ✔️ Front Door Premium

Azure Web Application Firewall(WAF)は、分散型サービス拒否(DDoS)攻撃を防ぐための複数の防御メカニズムを含んでいます。 DDoS 攻撃は、ネットワーク層 (L3/L4) とアプリケーション層 (L7) の両方を対象にすることができます。 Azure DDoS Protection を使用すると、大規模なネットワーク層の帯域幅消費型攻撃から防御できます。レイヤー 7 で動作する WAF Azure、HTTP フラッドなどの L7 DDoS 攻撃から Web アプリケーションを保護します。これらの防御が合わさることで、攻撃者があなたのアプリケーションに到達し、その利用可能性やパフォーマンスに影響を与えるのを防ぎます。

アプリケーション層攻撃は実行コストが安く、正当なトラフィックと区別しにくいです。各リクエストはそれ自体で有効に見え、攻撃が明らかになるのはレートの集計、配信、クライアントの組み合わせだけです。したがって、効果的なL7防御は単一の制御よりも、攻撃開始前にすでに存在している層状の構成に依存しています。

防御層を選びましょう

L7 DDoS防御を計画する際には、以下のモデルを使用してください。各レイヤーはトラフィックをキャッチしますが、その上のレイヤーはできません。

レイヤー	それが何をするか	構成する場所
プラットフォームDDoS防御	AzureエッジやオリジンのパブリックIPに対するL3/L4のボリューメトリック攻撃を吸収します	Azure Front Doorにデフォルトで組み込まれており、アプリケーションゲートウェイのパブリックIPおよびオリジンパブリックIPに対してAzureのDDoSネットワーク保護が必要です
自動L7緩和	通常のトラフィックを学習し、緊急調整なしでサージ中に違反するクライアントをスロットルで制御します	HTTP DDoS ruleset (preview) on Azure Front Door Premium and Application Gateway WAF v2
クライアントの検証	ブロッキング前に、人間と正当なクライアントを自動攻撃トラフィックから分離します	Bot Manager ruleset, JavaScript challenge, CAPTCHA
レート制限	クライアント、地理、エンドポイントが送信できるリクエスト数に上限があります	フロントドアおよびアプリケーションゲートウェイに関するレート制限カスタムルール
ターゲットとなるカスタムルール	インシデント中に既知の攻撃シグネチャをブロックします	カスタムルール(geo、IP、ASN、クライアント指紋、ヘッダー、URI)をマッチングしてください。
起源保護	攻撃トラフィックがあなたのコンピュートに届くのを全く防いでいます	キャッシュ、オリジンロックダウン、オートスケール

基準設定チェックリスト

攻撃される前にこれらの手順を完了してください。応募要件に合わせて調整してください。

Azure WAFをAzure Front Door PremiumまたはApplication Gateway WAF v2で展開し、L7アプリケーション層攻撃から守ります。
WAFポリシーを 防止モードに切り替えてください。検出モードのポリシーはログのみを記録し、トラフィックをブロックしません。まずは本番トラフィックに対してポリシーを検証・調整して誤検知を減らし、その後に防止をオンにしてください。
HTTP DDoSルールセット(Azure Front Door PremiumとApplication Gateway WAF v2の両方で利用可能)を割り当てて、自動緩和策としてトラフィックベースラインを事前に学習できます。
Bot Manager管理ルールセットを有効にして、既知の悪質なボットを特定して対応させてください。
少なくとも1つの 包括的なレート制限ルール (レート制限参照)を設定してください。
元のインスタンス数を拡大して十分な余裕を確保し、Application Gatewayを自動スケールに設定し、低い最大インスタンス数を強制しません。
Azure Front Doorでキャッシュを有効にして、突然ピークトラフィックが発信地ではなくエッジで吸収されるようにしましょう。
プラットフォームによって異なるL3/L4曝露をカバーしてください。プラットフォームの DDoS防護はプラットフォームごとに異なります。 Originをロックして、Azure Front DoorやApplication Gatewayからのトラフィックのみを受け入れるようにしてください。
Log Analyticsで診断ログを有効にし、Analyze WAFでクエリを作成し、インシデント前にログにアクセスしてください。

プラットフォームのDDoS防護はプラットフォームによって異なります

L7防御は、基礎となるパブリックIPアドレスがボリューメトリック攻撃に耐え、2つのAzure WAFプラットフォームが同じ場所から始まっていない場合に限り意味を持ちます。

Azure Front DoorはデフォルトでプラットフォームのDDoS保護を備えています。 Azure Front Doorはグローバルに分散されたエッジサービスであり、そのエッジはAzureのインフラによるDDoS防御によって追加コストなしで、設定も不要で保護されています。トラフィックはあなたが所有するIPアドレスではなく、フロントドアの端で終わるため、攻撃者がL3やL4で標的にできるパブリックIPはありません。その保護はプラットフォームに内在しているので、何かを購入したり有効にしたりしてそれを手に入れる必要はありません。

アプリケーションゲートウェイにはAzure DDoSネットワーク保護が必要です。 アプリケーションゲートウェイは 、あなたの仮想ネットワーク内のパブリックIPアドレスを持つ地域リソースです。 Azureのデフォルトのインフラレベルの保護はAzureプラットフォーム自体を守りますが、そのIPに対して調整されたリソースごとの緩和策、テレメトリ、攻撃報告は提供しません。ゲートウェイのパブリックIPをL3/L4ボリューメトリック攻撃から守るには、ゲートウェイを含む仮想ネットワーク上でAzure DDoSネットワーク保護を有効にしてください。これは有料で別途購入するサービスです。

展開を選んだり設計したりする際の実用的な影響:

Azure Front Doorを使っているなら、L7コントロールに予算を割くべきです。L3/L4のエッジ保護はすでに存在しています。
もしアプリケーションゲートウェイを使っていてDDoSネットワーク保護を有効にしていなければ、WAFルールは完璧に調整されても、ゲートウェイのパブリックIPに対するボリューメトリック攻撃で回避されてしまいます。有効にします。
いずれの場合も、公開したOriginのパブリックIPはAzureのDDoSネットワーク保護と、WAFサービスのみがアクセスできるロックダウンが必要です。保護されていない、公開可能な発信源の前で保護されたフロントエンドは保護されません。

詳細については、Azure DDoS保護の概要および「Azure DDoS ネットワーク保護でアプリケーションゲートウェイを保護する」をご覧ください。

HTTP DDoSルールセットによる自動保護(プレビュー)

IPフィルターやジオフィルター、固定レート制限などの静的制御は分散型ボットネットに追いつかないことが多いです。閾値は推測であり、常にオンで、トラフィックパターンの変化に応じて再調整しなければなりません。 HTTP DDoSルールセットは、Azure WAF初の自動化されたレイヤー7保護モデルであり、最小限のユーザー設定で学習、検出、防御を行います。 Azure Front Door PremiumとApplication Gateway WAF v2の両方でプレビュー版で利用可能です。一度割り当てされると、通常のトラフィックを継続的にベースラインし、サージが攻撃を示す場合は、緊急チューニングなしで問題のあるクライアントを選択的にブロックします。

デザインは両プラットフォームで最も重要な点で同じです:

2つの閾値を一緒に評価します。 ルールセットは、グローバルな閾値(フロントドアプロファイルごと、またはアプリケーションゲートウェイごと)と個々のIPベースの閾値の両方を学習します。 IPベースの閾値は、グローバル閾値が突破された後にのみ強制されます。この設計により、数個のIPアドレスからのスパイクが実際に総トラフィックを正常を超えない限り、ルールセットが反応しません。
リソースごとにスコープが設定されています。 閾値はグローバルリソースレベルで学習されます。ルールセットで1つのWAFポリシーを複数のFront Doorプロファイルや複数のゲートウェイに割り当てると、サービスはそれぞれのプロファイルに対して個別に閾値を計算します。
感度。 各ルールには3つの感度レベルがあります。感度が高いほど閾値が低くなります。感度が低いほど閾値が高くなります。ミディアムがデフォルトで推奨される設定です。
評価の順序。 WAFはカスタムルールよりもまずHTTP DDoSルールセットを評価します。許可アクション付きのカスタムルールは他のすべてのWAF検査を回避しますが、HTTP DDoSルールセットを回避しません。
信頼されたトラフィックに対してルールセットを回避する。 Allowアクション付きのカスタムルールはここでは役に立ちません。他のすべてのルールセットを回避しますが、HTTP DDoSルールセットはバイパスしません。代わりに WAF例外 を使い、特定のルール、ルールグループ、またはHTTP DDoSルールセットを含む管理されたルールセット全体にスコープをかけることができます。例外付き免除された信頼トラフィックを参照してください。
継続的な交通が必要です。 ルールセットは信頼できるベースラインを学習して初めて行動できます。学習フェーズでリソースが十分なトラフィックを受け取れなければ、ルールセットはそれを検出したり保護したりしません。具体的な要件についてはプラットフォーム表をご覧ください。

プラットフォームの違い

特徴	Azure Front Door Premium（アジュールフロントドアプレミアムサービス）	アプリケーションゲートウェイ WAF v2
学習段階	基準値はローリングウィンドウで計算されます。過去7日間のうち少なくとも50% 日間トラフィックを受信したプロファイルについては、24〜36時間以内に検出が始まります	基準線は最低24時間学習されます。ルールセットは24時間の学習フェーズが終わるまで検出もブロックもしません
交通量不足	過去7日間のうち50% 未満のトラフィックがプロファイルに受信した場合、信頼できる基準となる十分なトラフィックが存在するまでルールセットは検出もブロックもしません	ゲートウェイが24時間学習フェーズで十分なトラフィックを受け取れず、信頼できる基準を確立できなければ、ルールセットはそれを確立するまで攻撃を検出・ブロックしません
Mitigation	違反したIPアドレスはペナルティボックスに入れられ、ペナルティボックスの間ブロックされます	問題のあるIPアドレスはペナルティボックスに入れられ、15分間ブロックされます
ルールID	500100(クライアントリクエスト率)、500110(疑わしいボット)	500100(クライアントリクエスト率)、500110(疑わしいボット)
その他のメトリック	Web Application Firewall HTTPDDoSRuleset がアクティブです	ペナルティボックスのサイズ、ペナルティボックスブロック数

ルールセット内のルール

ルールセットには現在2つのルールが含まれています。各ルールは独自のトラフィックベースラインを維持し、独自の感度と動作で設定可能です:

ルール	説明
500100:クライアントリクエストの高頻度で異常を検出	ポリシーが付随するフロントドアプロファイルまたはアプリケーションゲートウェイ上ですべてのトラフィックをベースライン化します。クライアントが学習済みの閾値を超えると、設定されたアクションがトリガーされ、問題のIPアドレスはペナルティボックスに格納されます。
500110:高いリクエスト率の送信が疑わしいボット	Microsoft Threat Intelligenceによってボットと分類されたトラフィックについては、一般的により厳格な別個の基準を維持しています。高リスクと分類されたボットは、グローバル閾値が突破されると即座にブロックされます。

ペナルティボックス

両プラットフォームとも ペナルティボックスで軽減しています。クライアントからのトラフィックがルールセットのルールの閾値を超えると、そのクライアントIPアドレスはペナルティボックスに入れられ、WAFによってペナルティボックスの期間(アプリケーションゲートウェイ上では15分)ブロックされます。期間が終了すると、IPアドレスは再びアクセス権を取り戻しますが、再び閾値を超えた場合はペナルティボックスに戻されます。

この設計はテレメトリの読み方に影響します。最初のルールヒットのみが記録されます。ペナルティボックスにIPアドレスが入っている間に追加のブロックリクエストはFront Doorに記録されないため、ログベースのカウントではブロックされたリクエスト数が過小評価されます。 Application Gatewayでは、実際のブロック数を示す ペナルティボックスブロック数 メトリックと、現在ペナルティされているIPアドレス数のペ ナルティボックスサイズ を使います。

プレビュー中のモニタリング

IPアドレスが閾値を超えると、HTTP DDoSルールセットおよびWAFマネージドルールマッチメトリクスの増分に対してブロックアクションとともにログエントリが記録されます。

Front Door:Web Application Firewallリクエストカウントメトリックをルール名でフィルタリングしてブロック数をカウントし、Web Application Firewall HTTPDDoSRuleset Is Activeメトリックを使い、学習が完了しルールセットが学習閾値を超えるトラフィックに対応する準備ができたら1を報告します。
アプリケーションゲートウェイ: ペナルティを受けたIPアドレスからのその後のブロックリクエストごとにマネージドルールマッチメトリックが増加し、 ペナルティボックスのサイズ と ペナルティボックスブロックメ トリクスはペナルティボックスを直接追跡します。

例外付きで信頼できるトラフィックを免除

ヘルスプローブ、合成監視、負荷テスト、パートナー統合、内部バッチジョブなどは、見た目はフラッドのように見えても実際はフラッドではないトラフィックを生み出します。歴史的に、カスタム のAllow ルールはDefault Rule Set、Core Rule Set、Bot Protectionルールセットをバイパスしますが、HTTP DDoSルールセットを意図的に回避しないため、DDoSルールセットから除外する方法はありません。

WAFの例外は そのギャップを埋めています。例外は、特定の属性に一致するリクエストに対してWAF検査を回避し、単一のルール、ルールグループ、または管理されたルールセット全体にスコープされます。 HTTP DDoSルールセットだけでなく、DRS、CRS、ボット保護にも例外を適用できます。

例外は以下の通りに一致します:

リモートIPアドレス (EqualsまたはIPマッチ)は、既知の監視、負荷テスト、パートナーソースの範囲をDDoSルールセットから除外するための通常の選択肢です
要求 URI
リクエストヘッダー名と値、Equals、Starting with、Ends with、またはContains と一致します

DDoSルールセットでの例外使用に関するガイダンス:

できるだけ狭く範囲に絞りましょう。 ルールセット全体を除外するよりも、ルールごとの例外を好む。広範な例外は、攻撃者に自動化された緩和策を回避する文書化された経路を渡すものです。負荷発電機がルール500100からのみ解放されるなら、500110からも免除しないでください。
免除ソースを選び、パスを選ばないこと。 既知のテストハーネスに対するIPベースの例外は有界があります。公開エンドポイントにURIベースの例外を設けることは、それを見つけた誰にとっても開かれた扉です。
スケジュール通りに見直しましょう。 一度限りの負荷テストに追加された例外は、1年後も有効な場合があります。
限界に気をつけろ。 各WAFポリシーは最大60件の例外をサポートし、各Front Doorは関連するすべてのポリシーで合計60件をサポートしています。 1つの例外には最大600のIPアドレス、10のURI、または10のリクエストヘッダーを含めることができます。
例外は次世代のWAFエンジンおよび管理されたルールセットバージョン DRS 2.1以降が必要です。

適切なツールを使いましょう: 除外は リクエストの一要素(ノイズの多いクッキーやヘッダー)の検査をスキップし、他の要素は引き続き検査します。 例外は 特定のルールやルールセットをスキップし、リクエストをマッチングします。 カスタムのAllowルール はHTTP DDoSルールセット以外のすべてをバイパスします。

Important

WAF例外とHTTP DDoSルールセットは、Azure Front DoorとApplication Gateway WAF v2の両方でプレビュー中です。「Microsoft Azure プレビューの追加使用条件」を参照してください。

ブロックする前に挑戦しろ

ブロッキングはL7攻撃における鈍器的な手段であり、攻撃トラフィックはしばしば実際のユーザーを含むIPアドレスや地理から届きます。チャレンジは自動化と人間を分離し、ブロックによる巻き添えを避けられます。これはAzure WAFがL7フラッドを処理する際、ブロックのみのレート制限戦略と比べて最大の変化です。

JavaScriptチャレンジ は、人間の介入を必要としない目に見えないチャレンジです。ブラウザがチャレンジを正常に計算すると、WAFはクライアントを非ボットとして検証し、残りのルールの評価を続けます。失敗したリクエストはブロックされます。一般的なウェブトラフィックのデフォルトチャレンジとして活用しましょう。チャレンジエンドポイントへのリクエストはバックエンドに転送されず、レート制限にはカウントされません。
CAPTCHA はユーザーの参加を必要とするインタラクティブなチャレンジであり、サインイン、サインアップ、チェックアウトといった高価値のフローに最適であり、自動的な悪用はコストがかかり、数秒間のユーザーの摩擦が許容される場合に適しています。チャレンジクッキーの有効期間はポリシー設定で5分から1,440分まで設定可能で、デフォルトは30分です。 CAPTCHAは使用量に基づく追加料金を発生します。

両方の機能の制限を事前に計画してから導入してください:

AJAXやAPIの呼び出しはサポートされていません。 APIルートの前にチャレンジを置かないでください。レートリミッターとマッチルールを使った方がいいですよ。
チャレンジはHTMLリソース向けに設計されており、埋め込み画像、CSS、JavaScriptファイル用ではありません。
チャレンジをトリガーする最初のリクエストでは、Azure Front DoorでPOSTボディが64KB、Application Gatewayで128KBに制限されています。
いずれの機能もInternet Explorerをサポートしていません。どちらもMicrosoft Edge、Chrome、Firefox、Safariの最新バージョンをサポートしています。
JavaScriptチャレンジは、クライアントのIPアドレスが変更された場合やクロスオリジン(CORS)リクエストに対して再発行されます。
Application GatewayではJavaScriptチャレンジがプレビュー段階で、レート制限のカスタムルールには対応していません。コンテナ用アプリケーションゲートウェイWAFはサポートしていません。

レート制限

最低限、単一のクライアントからの高要求レートをブロックするレート制限ルールを作成しましょう。このルールを 最低優先度 (最高数値)のレートリミットルールとして設定し、より具体的なレートリミットやマッチングルールを先に評価してください。

Azure Front Door

レート制限はソケットIPアドレスごとに適用されます。これはTCP接続をAzure Front Doorに開くクライアントのアドレスで、エンドユーザーではなくプロキシである場合もあります。
閾値は1分または5分の 固定されたウィンドウ で評価されます。閾値が突破されると、Azure Front Doorはそのウィンドウの残りの期間、ルールに合致するすべてのトラフィックをブロックします。 HTTPフラッド軽減のために 5分間のウィンドウ を活用しましょう。最初の1分間にブロックされた攻撃者は、残りの4分間ブロックされたままです。
許容される閾値が最も小さい大きなウィンドウが、最も効果的なアンチDDoS構成です。ウィンドウを大きくしきい値も設定済みの閾値に近づけます。非常に低い閾値(約200リクエスト未満)では、閾値を超えるリクエストが通過することもあります。なぜなら、あるクライアントからのリクエストがカウンターがまだ更新されていないフロントドアサーバーに届く可能性があるからです。
レート制限ルールはログおよび ブロック アクションのみをサポートします。許可はサポートされていません。
すべてのトラフィックにルールを適用し、長さが0より大きいHostヘッダーでマッチングします。なぜなら、Azure Front Doorへの有効なリクエストはすべて0長を持つからです。

アプリケーションゲートウェイ WAF v2

レートリミットは スライディングウィンドウ アルゴリズムを使用します。すべての一致するトラフィックは、閾値が突破された最初のウィンドウ中に切り捨てられます。 2番目のウィンドウ以降は閾値までのトラフィックが許可され、マッチングクライアントに対して完全な障害ではなくスロットリング効果が生じます。

ルールには GroupByUserSessionが必要で、これはリクエストのカウント方法を制御します。この機能により、クライアントIP以外のものでレート制限を設定できます:

GroupByVariable (変数によるグループ化)	次の場合に使用します。
`ClientAddr` (既定値)	これは、ソースIPごとに独立したカウンターが存在する通常のケースです
`ClientAddrXFFHeader`	ゲートウェイはCDNやプロキシの背後にあり、実際のクライアントIPはそこにあります `X-Forwarded-For`
`GeoLocation`	地理的に集中した洪水の際には国や地域ごとの交通量を制限したいのです
`GeoLocationXFFHeader`	上記と同じで、 `X-Forwarded-For`
`None`	サインインページや疑わしいユーザーエージェントのリストなど、狭く一致したパターンのための単一の共有カウンター

レート制限ルールは最新のWAFエンジン(デフォルトルールセットはCRS 3.2以降を選択してください)が必要で、エアギャップドクラウドではサポートされません。
アプリケーションゲートウェイは、ポリシーが接続される 各エンドポイント ごとに独立して閾値をカウントします。 5人のリスナーに対する単一のポリシーは5セットのカウンターを維持します。
閾値は厳密に強制されていないため、細かい交通制御にはレートリミットは使わないでください。異常な率を軽減し、利用可能性を維持するために活用しましょう。 GeoLocationやNoneを使うワイドマッチングルールには特に注意してください。誤った閾値の選択は、正当なトラフィックに対して頻繁に短時間の停止を引き起こす可能性があります。

地理認識の閾値を設定する

単一のグローバル基準は、最も忙しい国に対して十分に寛大でなければならず、それが他の国ではあまりにも寛大すぎます。平時にはほとんどのアプリケーションが地理的に大きく偏っており、ごく一部の国や地域がほぼすべての正当なトラフィックを生み出し、残りはわずかな供給しか生み出しません。攻撃トラフィックはその分布をほとんど尊重しません。地理ごとに閾値のサイズを設定することで、その非対称性が検出信号であると同時に緩和策にもなります。

まずは平時の分布を少なくとも1週間にわたって測定し、平日、週末、タイムゾーンの効果を表現します。

Azure Front Door で、Request count metric を ClientCountry dimension で分割します。

Log Analyticsで、アクセスログ内のクライアントIPアドレスから国を導出します:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(7d)
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize Requests = count(), Clients = dcount(clientIp_s) by Country
| extend ShareOfTraffic = round(100.0 * Requests / toscalar(
      AzureDiagnostics
      | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
      | count), 2)
| order by Requests desc

その後、結果を階層にまとめ、それぞれの閾値を設定します:

レベル	平時のシェア	推奨治療法
主要市場	あなたのトラフィックの大部分を生み出す国々	その国のp99を基準にした寛大なクライアント一人当たりの閾値で、実際のユーザーに影響が出ない
二次市場	意味のあるが控えめな交通量	クライアント一人当たりの基準を厳しくし、その国のp99から基準を定めて、グローバル基準を基準にします
ロングテールの地理	正当な交通のわずかな流れ	アグレッシブ・スレッショルド、つまりブロックの代わりにチャレンジアクションを使う
あなたがサービスしていない地域	実質的にゼロです	完全にブロックするか、静的ページにリダイレクトしてください

階層の実装方法はプラットフォームによって異なります:

アプリケーションゲートウェイWAF v2 - GroupByVariable: GeoLocation (またはCDNやプロキシの背後に GeoLocationXFFHeader )を使い、1つの地理圏からのすべてのトラフィックがカウンターを共有し、各階層ごとに独自の閾値を持つ1つのレート制限ルールを作成します。侵害はその地理区域のすべてのクライアントに対して影響を及ぼすため、これらの閾値を慎重にサイズ化し、まずログアクションで検証してください。誤った設定の広範囲一致ジオルールは、正当なトラフィックに対して頻繁に短時間の障害を引き起こす可能性があります。
Azure Front Door - カウンターはソケットIPアドレスごとに割り当てられるので、代わりにジオマッチ条件で階層を構築してください。各階層ごとに1つのレート制限ルールを設定し、それぞれの国でマッチングし、それぞれに独自の閾値を設定します。ロングテール地域のすべてのクライアントは、主要市場のクライアントよりもはるかに低い天井を得られますが、一方のクライアントの行動が他のクライアントに影響を与えることはありません。

これを維持しやすく保ついくつかの実践例を挙げます:

ルールは最も具体的な順に並べてください:プライマリーマーケットルールは優先度が高い(数値値が低い)、次にセカンダリー、ロングテール、そしてグローバルキャッチオールを最低優先度のレート制限ルールとします。
ロングテールの地理的環境ではブロックよりも チャレンジ アクションを好みます。正当な取引量が少ない国からのトラフィックは総じて怪しいですが、実際のユーザー(旅行者、VPNユーザー、リモート従業員)も含まれます。
マーケティングローンチ、地域展開、主要製品イベントの後に再測定しましょう。地理認識型の構成は、その基準値が基準に左右されます。
インシデント中に逆方向の信号に注意してください。通常はトラフィックの1% を占める国が突然40% に増えるのは、攻撃が起きていることを認識する最も速い方法の一つです。これは自然発生的な成長ではなく攻撃であることを確かめる最速の方法の一つです。

自分のトラフィックから閾値を選びましょう

以下のLog Analyticsクエリを使ってキャッチオールルールのサイズを調整してください。 Application Gatewayの場合は FrontdoorAccessLog を ApplicationGatewayAccessLogに置き換えてください。

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

先述の地理別閾値をサイズ化するために、同じクエリに国を追加してください:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

平時の交通量の99パーセンタイル以上に設定し、最大値ではなく設定してください。最大値は通常クローラーか誤った設定のクライアントで、それに合わせてサイズ化すると攻撃時に助けにくくなってしまいます。

ターゲットを絞った緩和のためのカスタムルール

特定のユーザーエージェント、ヘッダー、クッキー、クエリ文字列パターン、URI、またはそれらの組み合わせなど、識別可能な署名を持つHTTPおよびHTTPS攻撃をブロックまたはレート制限するカスタムWAFルールを作成しましょう。文字列マッチング以外にも、Azure Front Door WAFのカスタムルールは以下の場所でマッチングできます:

ジオロケーション:サービスエリア外からのトラフィックをブロックするか、静的なページにリダイレクトします。
クライアントのIPアドレス(CIDR) や、悪意のあるアドレスと範囲の IP制限 リストです。
AS番号(ASN):正当なユーザーが発信していないホスティングプロバイダーやトランジットネットワークからの洪水を軽減し、IP範囲を列挙せずに対処します。
クライアントフィンガープリント(JA4):クライアントのTLSハンドシェイクとHTTP特性から導き出されたハッシュである JA4フィンガープリントのマッチ。攻撃ツールやボットネットクライアントは、送信元に関わらず一貫した指紋を生成するため、JA4は分散攻撃時に利用可能な最も耐久性の高いシグネチャの一つです。数千の送信元IPアドレスをローテーションしても指紋は変わらず、ブロックやレート制限で一つのルールでボットネット全体を破壊します。指紋を平時の記録と照合してから、それを強制してください。人気のあるブラウザや一般的なSDKは、膨大な数の正当なユーザーの間で指紋を共有するため、未検証のJA4ブロックは非常に広範囲に及ぶことがあります。まずログアクションを導入し、指紋が攻撃トラフィックにのみ表示されているか確認し、その後ブロックまたはレート制限ルールに切り替えます。
JA4を他の疾患と組み合わせ て、事故時の外科的緩和策を用いてください。例えば、特定のJA4指紋とユーザーにサービスしないASNをブロックするのではなくレート制限、あるいはJA4指紋とリクエストURIをブロックするのではありません。
リクエストコンポーネントに対するサービスタグおよびサイズ制約。

事例の際に重要な2つの実践があります:

既知の正当なトラフィックに対して「 マッチを許可 するルール」を作成し、誤検知を減らし、ブロックやレート制限ルールよりも高い優先度(数値値より低い)を付与してください。許可ルールは他のWAF検査をバイパスしますが、HTTP DDoSルールセット を回避しません 。
ルール評価は Log以外のすべてのアクションで停止し、優先度番号は一意でなければなりません。緊急ルール用に低優先度の番号ブロックを予約し、攻撃時に番号を変更せずに挿入できるようにしましょう。

管理ルールはDDoS防御を目的としたものではありませんが、他の一般的な攻撃から守るため有効にすべきです。管理ルール(Azure Front Door)または管理ルール(Application Gateway)を参照してください。

起源を守る

発信元のパブリックIPへのアクセスをロックし、受信トラフィックを制限してAzure Front DoorかApplication Gatewayだけがアクセスできるようにします。 Azure Front Door Originsへのトラフィックの確保に関するガイダンスに従ってください。
アプリケーションゲートウェイの仮想ネットワーク内に公開されているIPアドレスがないか確認してください。
Azure Front Doorでキャッシュを有効にしてください。キャッシュ応答はエッジのピークボリュームを吸収し、発信元に到達するリクエストレートを下げます。これはしばしばパフォーマンス低下と障害の差となります。
スケールオリジンズとヘッドルーム。自動および手動の緩和策は導入に時間がかかります。予備容量がそのギャップを埋めています。

攻撃が発生した場合に対応する

それが攻撃であり、有機的な成長ではないか確認してください。 WAFやアクセスログでリクエストレート、クライアントIP数、地理的分布、ユーザーエージェントの分布、リクエストされたURIの突然の変化を確認してください。
すでに何が緩和効果になっているか確認してください。 HTTP DDoSルールセットが有効かどうかを確認し、ルール名でブロックを確認しましょう。 Application Gatewayではペ ナルティボックスのサイズ を確認し、ペ ナルティボックスは メトリクスもブロックします。なぜなら、ログにはIPアドレスあたりの最初のブロックしか表示されないからです。料金制限ルールの一致を確認しましょう。
地理的な構成をベースラインと比較してみてください。 通常はトラフィックのごく一部しか占めていない国が、突然その国を支配するのが、高速で高い信頼度の高い攻撃信号となります。また、どのレート制限の階層を最初に厳しくするべきかも教えてくれます。
新しいルールを書く前に敏感度を高めましょう。 HTTP DDoSルールセットの感度を高めるか、既存のレート制限閾値を下げる方が、プレッシャーの中で新しいルールを作成するよりも速く安全です。
交通が混ざっている場所は、ブロックするのではなく挑戦しましょう。影響を受けたHTMLルートにはJavaScriptチャレンジを適用し、繊細なフローにはCAPTCHAを適用します。
持続的な署名を特定した後にのみターゲットを絞ったルールを作成しましょう:ASN、クライアント指紋、ヘッダーの組み合わせ、地理、またはURIパターン。パターンが実際のユーザーと一致する場合は、まずLogアクションで展開してください。
チューニング中はオリジンを保護してください:キャッシュがオンになっているか確認し、オリジンロックダウンを確認し、スケールアウトします。
インシデント後は 、新しい交通データに基づいてレート制限の閾値を基準に再設定し、正確だった緊急ルールをログモードで保持し、継続的に適用してほしくない場合は引き続き有効です。

WAFおよびアクセスログの解析

Azure WAFログを使ってトラフィックを監視し、異常なリクエスト数、異常なユーザーエージェント文字列、異常なクエリ文字列パターンを送る疑わしいIPアドレスを特定しましょう。

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

攻撃ウィンドウ上のトップトーカーおよびトップユーザーエージェント(Azure Front Door表示;アプリケーションゲートウェイの代替ApplicationGatewayAccessLog):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

詳細については、「Azure WAF with Azure Front Door」および「Azure WAF with Azure Application Gateway」をご覧ください。

HTTP DDoSルールセット:Azure Front Door WAF | Application Gateway WAF
WAF例外リスト:Azure Front Door WAF | アプリケーションゲートウェイWAF
レート制限:Azure Front Door WAF | アプリケーションゲートウェイWAF
WAFセットアップ:Azure Front Door | Application Gateway
WAF JavaScript チャレンジのAzure
AZURE FRONT DOOR WAF CAPTCHA
Azure Front DoorにおけるDDoS保護
Azure DDoS Protection リファレンスアーキテクチャ
Azure DDoS Protection の概要

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-14