すべてのプロダクト
Search
ドキュメントセンター

Edge Security Acceleration:不正トラフィックを防止する

最終更新日:Jun 20, 2025

ドメインが攻撃された場合、またはトラフィックリソースが悪意を持って消費された場合、帯域幅の使用量が急増し、予期しないトラフィックの増加が発生する可能性があります。 これにより、予想よりも高い請求が発生する可能性があります。 これらの高額な請求は免除または払い戻しできません。 このようなリスクを最小限に抑えるために、アクセス制御、WAF保護、およびその他の方法で異常な攻撃をブロックできます。

背景

近年、インターネット業界が成長を続けるにつれて、不正トラフィックを使用した攻撃がより一般的になっています。 コンテンツ配信を高速化し、ユーザーエクスペリエンスを最適化するために設計された Edge Security Acceleration (ESA) は、Web サイトのアウトバウンドトラフィックに対して顧客に課金します。 つまり、料金は Web サイトからダウンロードされたデータ量によって決定されるため、ESA は悪意のあるアクターによる悪用に脆弱になります。

予防策

使用量上限ポリシーを構成する

使用量上限を設定すると、予期しない高トラフィックが発生した場合に構成されたアクションに基づいてサイトリソースを管理し、多額の後払い請求を回避できます。 この機能はサービスの継続性に影響を与える可能性があるため、実装する前に慎重に評価してください。

  1. ESA コンソールで、[サイト管理] を選択し、管理する Web サイトの名前をクリックします。

  2. 左側のナビゲーションウィンドウで、[使用量の上限] を選択します。

  3. [ルールを作成] ボタンをクリックし、[ルール名] を入力し、条件と [統計周期] を設定します。

    • [5 分ごと]: 統計サイクルは 5 分です。

    • [1 時間ごと]: 統計サイクルは 1 時間です。

    • [毎日]: 統計サイクルは暦日です (当日の 00:00 から 23:59 まで)。

    • [毎月]: 統計サイクルは暦月です (当月の最初の日から最後の日まで)。

  4. 上限に達したときに実行するアクションを選択し、[OK] をクリックします。

    • [Web サイトの無効化]: Web サイトは無効になります。 高速化、保護、コンピューティングなどの ESA サービスは利用できなくなり、オンラインビジネスに影響を与える可能性があります。

      Web サイトの運用を確保するために、適切なトラフィック上限を設定することをお勧めします。

    • [DNS レコードの削除]: Web サイトの下で指定されたサブドメインレコードが削除されます。 Web サイトをオフラインにしたくない場合は、このオプションを選択できます。

      警告

      削除されると、サブドメインレコードは復元できません。 レコードを手動で追加して、再度設定する必要があります。

リアルタイムログ配信を有効にする

リアルタイムログ配信は、ESA ノードから分析システムにアクセスログを即座に送信し、ホットリンク、トラフィックの急増、不正アクセスなどの異常な動作を迅速に特定できるようにします。 不正トラフィックのソース (高頻度 IP アドレスや空の Referer など) を正確に特定し、ブロッキングルール (禁止やレート制限など) と組み合わせて攻撃を迅速にブロックし、帯域幅の消費とセキュリティリスクを大幅に削減します。 リアルタイムログ 機能を有効にすることをお勧めします。 ログタイプによって記録されるリクエストの範囲:

  • [エッジルーチンログ]

    収集範囲: アカウント内のすべての Web サイト

    コンテンツ: ESA ルーチンを呼び出すことによって生成されたリクエスト情報

    シナリオ: ビジネス分析と最適化

  • [エッジコンテナログ]

    収集範囲: アカウント内のすべての Web サイト

    コンテンツ: エッジルーチンによって生成されたビジネス情報

    シナリオ: パフォーマンス監視、ユーザー行動分析、監査とコンプライアンス

  • [アクセスとオリジンログ]

    収集範囲: 個々の Web サイト

    コンテンツ: ユーザーが ESA によって高速化された Web サイトまたはサービスにアクセスしたとき、および ESA POP がオリジンからデータをフェッチしたときに、詳細なリクエスト情報が生成されます

    シナリオ: ユーザー行動分析、ビジネス分析と最適化、監査とコンプライアンス

  • [ファイアウォールログ]

    収集範囲: 個々の Web サイト

    コンテンツ: ESA の Web アプリケーションファイアウォール (WAF) によって検出およびブロックされたすべての悪意のあるリクエストの詳細

    シナリオ: セキュリティ監視、ビジネス分析と最適化、監査とコンプライアンス

  • [TCP/UDP プロキシログ]

    収集範囲: 個々の Web サイト

    コンテンツ: トランスポート層 ESA でのコンテンツ配信の高速化に関する詳細

    シナリオ: パフォーマンス監視、ビジネス分析と最適化

  • [DNS ログ]

    収集範囲: 個々の Web サイト

    コンテンツ: ESA 高速化 DNS 解決の詳細なリクエスト情報

    シナリオ: 監査とコンプライアンス、DNS 解決の変更

不正トラフィックのシナリオ

不正トラフィックのシナリオには、通常、さまざまな悪意のあるリクエストが関係します。 次の表は、一般的な悪意のある攻撃方法と対応するソリューションを示しています。

攻撃タイプ

攻撃の原理

攻撃の兆候

ソリューション

User-Agent なりすまし

攻撃者は、偽造された User-Agent ヘッダーを使用して大量のリクエストを送信することにより、セキュリティチェックをバイパスしようとします。

一般的な偽造 User-Agent ヘッダー:

  • 空。

  • ランダムな文字列。

  • 一般的なブラウザの偽造文字列。

User-Agent ホワイトリストまたはブラックリストを構成して、信頼できない User-Agent ヘッダーを含むリクエストを拒否します。 たとえば、空であるか、無効なランダム文字列を含む User-Agent ヘッダーを拒否できます。

Referer なりすまし

攻撃者は、リクエスト内の Referer ヘッダーを偽造して、正当な参照元になりすまし、悪意のあるリクエストを開始します。

Referer ヘッダーの URL は、リクエストされたリソースと合理的な接続がないか、Referer ヘッダーが User-Agent ヘッダーと一致していません。

Referer ホワイトリストを構成して、正当な Referer アクセスを許可し、悪意のある Referer を含むリクエストを拒否します。 たとえば、自分のドメイン名からの Referer アクセスのみを許可します。

同じリソースへの頻繁なリクエスト

攻撃者は、短期間に同じリソース (API 操作など) を頻繁にリクエストし、サーバーの負荷が高くなり、リソースが消費され、コストが増加します。

リクエストは同じ IP アドレスまたは同じ IP アドレスのグループから来ています。

  • レート制限ルールを構成して、特定の期間内に同じ IP アドレスまたはユーザーからのリクエスト数を制御します。 たとえば、同じ IP アドレスから 1 秒あたり最大 10 件のリクエストを許可できます。

  • IP アドレスのブラックリストまたはホワイトリストを構成して、IP アドレスに基づいてアクセスを制限します。 一般的な攻撃 IP アドレスをブラックリストに、信頼できる IP アドレスをホワイトリストに追加します。

悪意のあるクローリング

攻撃者は、悪意のあるクローラーツールを使用して大量の Web サイトコンテンツをスクレイピングします。

同じリソースに対して頻繁にリクエストが行われます。

ESA のボット管理機能を使用して、異常なリクエストや悪意のあるクローラーを検出してブロックします。 周波数やリクエストパターンなどのリクエスト特性を分析して、不正なリクエストを特定してブロックします。

トラブルシューティング

ESA は、ログ収集および分析機能を提供します。 トラフィック分析オフラインログ、およびその他の方法を使用して、トラフィックの急増時のデータを分析し、異常のタイプに基づいて保護戦略を選択できます。

トラフィック分析

トラフィック分析データは ESA アクセスログから取得されます。アクセスログには、ESA ノードを通過する各リクエストに関する情報が記録されます。これには、クライアント IP アドレス、リクエスト時間、リクエストタイプ、応答ステータスなどが含まれますが、これらに限定されません。 これらのログを集計および分析することにより、ESA は正確なトラフィック統計と分析レポートを提供できます。

レポートの表示とダウンロード

  1. ESA コンソールで、[サイト管理] を選択します。 サイト 列で、ターゲットサイトをクリックします。

  2. 左側のナビゲーションウィンドウで、[分析とログ] > [トラフィック分析] を選択します。

  3. [トラフィック分析] ページで、トラフィック統計と分析を表示します。 また、image アイコンをクリックしてページレポートを印刷するか、image アイコンをクリックしてデータを CSV 形式でローカルコンピュータにダウンロードすることもできます。 フィルターを使用してデータをフィルタリングできます。 時間には [カスタム時間範囲] を選択し、疑わしい不正トラフィック期間の日付と時刻を選択します。

    image

  4. トラフィック分析ページには、総トラフィックと ESA 応答トラフィックの折れ線グラフが表示されます。これにより、直感的なトラフィックの可視化が提供され、過去のトラフィック傾向をより適切に分析できます。

    image

    • [トラフィック合計]: ESA からクライアントに送信されたすべてのトラフィック。

    • [リクエスト総数]: クライアントから ESA が受信したリクエストの総数。

    • [ページビュー]: HTML コンテンツタイプで成功した HTTP 応答の数。

    • メトリックの変化率: 各データメトリックの変化率は期間比較値であり、現在の期間と前の同じ期間との比較です。前の期間にデータが存在しない場合、変化率は表示されません。

      例: [過去 30 日間] の期間を選択し、リクエスト数が 2.03% 増加した場合、過去 30 日間に ESA サーバーが受信したリクエスト数が、60 日前から 30 日前の 30 日間に比べて 2.03% 増加したことを意味します。

  5. このモジュールを使用して、トラフィックの地理的分布を深く理解し、異常なトラフィックエリアを特定できます。

image

  1. トラフィック分析機能は、トラフィックとユーザー行動の多次元分析を提供します。 これらのモジュールは連携して、包括的なトラフィックの概要とユーザー行動の洞察を提供します。 適切な時間範囲を選択することにより、これらのディメンションの詳細なデータと可視化を表示できます。

    説明

    トラフィック分析では、デフォルトで上位 5 つのデータが表示されます。 [もっと見る] をクリックすると、詳細情報を表示できます。

    image

オフラインログ分析

不正なリクエストの潜在的なパターンを徹底的に調査するには、アラート期間中にオフラインログの詳細な分析を実行する必要があります。 フィールド間の分析を通じて、ソース IP アドレス、URL パス、リクエストパラメータ、User-Agent、Referer ソースなどのディメンションに基づいて不正な動作のプロファイルを構築し、後続の正確な戦略策定のためのデータサポートを提供できます。

  1. オフラインログをダウンロードする

  2. ログファイルをローカルの Linux サーバーにアップロードします。

  3. ローカルの Linux サーバーにログオンして、ファイルの行数をカウントします。これは、リクエストの総数を示します。

    wc -l [$Log_Txt]

    1 時間ごとのリクエスト数をカウントします。

    awk -F' ' '{print \$4}' [$Log_Txt] | sed 's/^\[\(.*\/.*\/.*\):\(.*\):.*$/\1 \2:00/' | sort | uniq -c | sort -nr | head -n 10

    出力は、リクエスト数が異常であることを示しています。

    重要

    実際のビジネスシナリオに基づいて、次の手順を実行します。

  4. 上位 10 件の IP アドレスをクエリします。

    cat [$Log_Txt] | awk '{print $3}' |sort|uniq -c|sort -nr |head -10

    特定された疑わしい IP アドレスからのアクセスを制限します。 詳細については、「IP アクセスルール」をご参照ください。

  5. 上位 10 件の User-Agent ヘッダーをクエリします。

     grep -o '"Mozilla[^"]*' [$Log_Txt] | cut -d'"' -f2 | sed 's/ ANCHASHI-SCAN[^)]*)//g' | sort | uniq -c | sort -nr | head -n 10

    疑わしい User-Agent ヘッダーをフィルタリングします。 詳細については、「カスタムルール」をご参照ください。

  6. 上位 10 件の URL をクエリします。

    grep -oP '"https?://[^"]+"' [$Log_Txt] | sort | uniq -c | sort -nr | head -n 10

的確な対策

攻撃の特性に基づいて適切なソリューションを選択できます。 異常を分析すると、複数の攻撃特性が特定される場合があります。 複数の保護ポリシーを構成して、包括的な保護を実現できます。

WAF ルールを構成して悪意のあるリクエストをブロックする

ESA は、エッジ Web アプリケーションファイアウォール (WAF) 機能と組み合わせて、ESA ノードで WAF 保護を提供します。これにより、ビジネストラフィックの悪意のある特性を効果的に特定し、正常で安全なトラフィックをサーバーにルーティングできます。 WAF は、Web サーバーを侵入から保護し、重要なビジネスデータを保護し、攻撃によって引き起こされるサーバーの異常を防ぐことができます。

  1. ESA コンソールで、[サイト管理] を選択します。 サイト 列で、ターゲットサイトをクリックします。

  2. 左側のナビゲーションバーで、[セキュリティ保護] > [WAF] を選択します。

  3. [概要] タブの [インテリジェントレート制限] セクションで、[設定] をクリックし、[ステータス] スイッチをオンにして、[保護等級][アクション] を選択します。

    image

  4. インテリジェントレート制限 がビジネス要件を満たしていない場合は、カスタム保護ポリシーを構成できます。

    リクエスト数を制限する

    詳細については、「レート制限ルール」をご参照ください。

    API 呼び出しの急激な増加により、アラートがトリガーされます。 リアルタイムログでは、攻撃期間中に 60 秒で IP アドレスから操作が 3,000 回以上呼び出されます。 ドメイン名が攻撃されていない場合、操作は 60 秒で IP アドレスから最大 100 回呼び出されます。 ドメイン名が攻撃されていない場合に操作が通常呼び出される回数の 2 ~ 3 倍に、60 秒で IP アドレスから操作が呼び出される最大回数を設定できます。

    説明
    • リアルタイムログを表示し、攻撃されたリソースを見つけ、攻撃された期間とドメイン名が攻撃されていない期間のアクセス頻度を比較する必要があります。 違いがある場合は、保護ポリシーを構成できます。

    • ほとんどの場合、サーバーは操作を呼び出してインターネット経由でリソースをリクエストします。 内部 IP アドレスに頻繁にアクセスする場合は、IP アドレスを無視する一致条件を追加する必要があります。

    • ワークロードとリアルタイムログの攻撃者のアクセス頻度に基づいて、保護するカスタム URI と保護をトリガーするためのしきい値を指定する必要があります。 次の例では、ルールの構成方法について説明します。

    image

    構成項目

    値の例

    説明

    [ルール名]

    カスタムルールの名前。 名前に は、次の要件を満たす必要があります。

    • 名前には、文字、数字、アンダースコア (_) を使用できます。

    • 名前は最大 64 文字まで使用できます。

    リクエストされたパスに / が含まれており、ターゲット IP アドレスに属していない場合、リクエストがこのルールに一致することを示します。

    リクエストが以下のルールと一致する場合...

    • [一致フィールド] では、[URI] を選択します。 [論理演算子] では、[次を含む:] を選択します。 [一致コンテンツ] には、/を入力します。

    以下の同様の特性を有します...

    クライアント IP

    同じクライアント IP アドレスを示します。

    レートが以下の値を超えた場合...

    レート: 300 回/1 分。

    クライアント IP アドレスが 1 分以内に 300 回を超えて条件に一致した場合、その IP アドレスがブラックリストに追加されることを示します。

    次を実行...

    操作:

    [レート制限を超えたリクエストに対してのみ実行] の場合ブロックを選択します。

    応答コード: 403.

    頻度検出条件を満たす統計オブジェクトがブラックリストに追加されたことを示します。 3600 秒以内に、このオブジェクトからのすべてのリクエストがブロックされます。

    異常なリクエストをブロックする

    カスタムルールを参照して、ルールポリシー構成を完了します。

    説明
    • ほとんどの場合、アプリケーションでは User-Agent ヘッダーは空です。このポリシーを使用する必要はありません。

    • User-Agent ヘッダーの値がアプリケーション名の場合、ビジネスで使用されているアプリケーションの名前を一致コンテンツに追加する必要があります。

    image

    構成項目

    値の例

    説明

    ルール名

    カスタムルールの名前。名前は次の要件を満たしている必要があります。

    • 名前には、文字、数字、およびアンダースコア(_)を含めることができます。

    • 名前は最大 64 文字まで使用できます。

    リクエストの User Agent ヘッダーに Android,iPhone,iPad,Mac,Windows,Linux が含まれていない場合、リクエストはブロックされます。

    一致条件

    • [一致フィールド] で、[User Agent] を選択します。

    • [論理演算子] で、[次の値に等しくない:] を選択します。

    • [一致コンテンツ] に、Android,iPhone,iPad,Mac,Windows,Linux と入力します。

    以下を実行する...

    [操作] で、[ブロック] を選択します。

    [応答のブロックページ] で、[デフォルトのブロックページ] を選択します。

    [応答コード] に 403 と入力します。

    異常な IP アドレスからのリクエストをブロックする

    IP アクセスルール を参照して、ルールポリシー構成を完了してください。

    image

    Web クローラーをブロックする

    ボット を参照して、ルール ポリシー構成を完了します。実際のニーズに基づいて、関連する保護項目を有効にします。

    image

ユースケース

不正トラフィックによるゲームインストールパッケージのダウンロードのトリガー

背景

ゲームのお客様は 2 年前にゲームをリリースし、ゲームは 2 年間安定して稼働していました。ESA は最近、高額な請求書を示しました。

例外の識別

トラフィック監視とログ分析のためのリアルタイムログ配信 により、高頻度のインストールパッケージダウンロードリクエストの複数のインスタンスが発見されました。わずか 1 時間以内に、PC から最大 310,000 件、Android デバイスから 18,000 件のダウンロードがありました。

説明

リアルタイムログ配信を有効にすると、指定されたサービスに配信されるログエントリに対して課金されます。

image

APK ダウンロードリクエストパケットの分析によると、User-Agent ヘッダーはクライアントが Android デバイスではなく PC であることを示していました。

image

ほとんどのユーザーは APK ファイルを PC にダウンロードしてから USB 経由で携帯電話に転送するのではなく、携帯電話に直接ダウンロードするため、これは異常と思われました。したがって、ダウンロードは攻撃者によって生成されたと結論付けられました。

また、リクエストの頻度とリクエストされたリソースは異常であり、1 つの IP アドレスから 1 分あたり APK ファイルへのリクエストが 300 件以上、EXE ファイルへのリクエストが 5,100 件以上ありました。

ソリューション

アクセス制御対策を講じてユーザー ID をフィルタリングし、ダウンロード頻度を制限します。

  • 疑わしい IP アドレスをブロックする:上位の IP アドレスを IP アドレスブラックリストに含めます。詳細については、「IP アクセスルール」をご参照ください。

    image

  • リソース頻度制御:同じ IP アドレスからの EXE または APK リソースへのリクエスト数を 60 秒あたり 20 に制限するルールを作成します。詳細については、「レート制限ルール」をご参照ください。

    image

  • 不正なクローラーを防止する:ボット脅威インテリジェンスライブラリスイッチをオンにし、「スライダ CAPTCHA」を有効にします。詳細については、「ボット」をご参照ください。

    image

ウェブサイトコンテンツの盗難

背景

E コマース顧客 A のウェブサイトは安定して稼働していましたが、最近、短期間で他のウェブサイトによって画像が頻繁に盗難されていることが発見されました。

例外の識別

トラフィック監視とログ分析のためのリアルタイムログ配信 により、ログに偽造された Referer ヘッダーが見つかりました。

image

SQL 文を実行したクエリの結果、refer_domain で示される偽造されたドメイン名が 10 分以上で 10,000 回以上ウェブサイト画像をリクエストしたことが示されました。

image

refer_domain と domain の不一致、および異常に高い訪問数に基づいて、ウェブサイトがコンテンツの盗難と悪意のある攻撃を受けたという結論を出すことができます。

ソリューション

カスタムルール を使用して、domain と refer_domain が一致しないリクエストをブロックします。

image