トラフィックフィルタールールを使用した DoS および DDoS 攻撃のブロック

AEM as a Cloud Service（AEMCS）が管理する CDNで、レート制限トラフィックフィルター ​ルールやその他の戦略を使用して、サービス拒否（DoS）攻撃と分散型サービス拒否（DDoS）攻撃をブロックする方法を説明します。これらの攻撃は、CDN および潜在的に AEM パブリッシュサービス（接触チャネル）でトラフィックの急増を引き起こし、サイトの応答性と可用性に影響を与える可能性があります。

このチュートリアルは、トラフィックパターンを分析し、レート制限トラフィックフィルタールール ​を設定して、これらの攻撃を軽減する方法に関するガイドとして機能します。このチュートリアルでは、攻撃が疑われる場合に通知が来るように、アラートを設定する方法についても説明します。

保護について

AEM web サイトのデフォルトの DDoS 保護機能を説明します。

これらの組み込み保護は、DDoS 攻撃のパフォーマンスへの影響を最小限に抑える、組織の能力のベースラインとして考える必要があります。Web サイトごとにパフォーマンス特性が異なり、Adobeが定義したレート制限に達する前にパフォーマンスが低下する可能性があるので、次の方法でデフォルトの保護機能を拡張することをお勧めします 顧客設定.

DDoS 攻撃から web サイトを保護するために、顧客が実行できる追加の推奨対策をいくつか見てみましょう。

レート制限トラフィックルールのバリエーション rate-limit-variations

レート制限トラフィックルールには、次の 2 つのバリエーションがあります。

カスタマージャーニー

以下の手順は、顧客が web サイトを保護するために取り組む必要があるプロセスを示しています。

このチュートリアルの残りの部分では、このプロセスについて順を追って説明します。

ルール設定の必要性の認識 recognize-the-need

前述したように、特定のレートを超える CDN のトラフィックはデフォルトでブロックされますが、サイトによってはそのしきい値を下回るとパフォーマンスが低下する場合があります。そのため、レート制限トラフィックフィルタールールを設定する必要があります。

このルールは、実稼動環境への移行を開始する前に設定するのが理想です。実際、多くの組織は攻撃の可能性を示すトラフィックスパイクの警告を受けた場合にのみ、ルールを事後的に宣言します。

特定の PoP に対して、単一の IP アドレスからのトラフィックがデフォルトのしきい値を超えると、接触チャネルトラフィックスパイクアラートがアクションセンターの通知として送信されます。このようなアラートを受信した場合は、レート制限トラフィックフィルタールールを設定することをお勧めします。このデフォルトのアラートは、トラフィックフィルタールールを定義する際に、顧客が明示的に有効にする必要があるアラートとは異なります。このルールについては、後のセクションで説明します。

トラフィックパターンの分析 analyze-traffic

サイトが既に実稼働している場合は、CDN ログとAdobe提供のダッシュボードを使用してトラフィックパターンを分析できます。

を使用したダッシュボードツールの設定 次のいずれかのオプション:

ELK：ダッシュボードツールの設定

アドビが提供する Elasticsearch、Logstash、Kibana（ELK） ​のダッシュボードツールを使用して、CDN ログを分析できます。このツールには、トラフィックパターンを視覚化するダッシュボードが含まれており、レート制限トラフィックフィルタールールの最適なしきい値を簡単に決定できます。

Splunk：ダッシュボードツールの設定

次の顧客： Splunk ログ転送が有効 では、トラフィックパターンを分析する新しいダッシュボードを作成できます。

Splunk でダッシュボードを作成するには、次に従います AEMCS CDN ログ分析用の Splunk ダッシュボード 手順。

データの確認

ELK ダッシュボードと Splunk ダッシュボードでは、次のビジュアライゼーションを使用できます。

しきい値の選択

レート制限トラフィックフィルタールールのしきい値は、上記の分析に基づいて、正当なトラフィックがブロックされないように設定する必要があります。しきい値の選択方法のガイダンスについては、次の表を参照してください。

使用する倍数は、オーガニックトラフィック、キャンペーン、その他のイベントによるトラフィックの通常のスパイクの予想値によって異なります。5～10 の倍数が適切な場合があります。

サイトがまだ公開されていない場合は、分析するデータがないので、レート制限トラフィックフィルタールールに設定する適切な値を経験に基づいて推測する必要があります。次に例を示します。

ルールの設定 configure-rules

上記の説明に基づいた値を使用して、AEM プロジェクトの /config/cdn.yaml ファイルで​ レート制限トラフィックフィルター ​ルールを設定します。必要に応じて、web セキュリティチームに問い合わせて、レート制限値が適切で、正当なトラフィックをブロックしないことを確認します。

詳しくは、AEM プロジェクトでのルールの作成を参照してください。

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent attack at edge by blocking client for 5 minutes if they make more than 500 requests per second on average
      - name: prevent-dos-attacks-edge
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 500 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: all # count all requests
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true
    #  Prevent attack at origin by blocking client for 5 minutes if they make more than 100 requests per second on average
      - name: prevent-dos-attacks-origin
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 100 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: fetches # count only fetches
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true

接触チャネルルールと Edge ルールの両方が宣言され、アラートプロパティが true に設定されているので、しきい値に達した場合は常にアラートを受信でき、攻撃を示している可能性があります。

数時間または数日間トラフィックを監視して、正当なトラフィックがこれらのレートを超えないように、アクションタイプを最初にログに記録するように設定することをお勧めします。数日後、ブロックモードに変更します。

AEMCS 環境に変更をデプロイするには、次の手順に従います。

リクエスト変換ルールの設定 configure-request-transform-rules

レート制限トラフィックフィルタールールに加えて、リクエスト変換を使用してアプリケーションに不要なクエリパラメーターの設定を解除し、キャッシュバスティング手法によるキャッシュをバイパスする方法を最小限に抑えることをお勧めします。例えば、search と campaignId のクエリパラメーターのみを許可する場合は、次のルールを宣言できます。

kind: "CDN"
version: "1"
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  experimental_requestTransformations:
    rules:
      - name: unset-all-query-params-except-those-needed
        when:
          reqProperty: tier
          in: ["publish"]
        actions:
          - type: unset
            queryParamMatch: ^(?!search$|campaignId$).*$

トラフィックフィルタールールアラートの受信 receiving-alerts

上記のように、トラフィックフィルタールールに experimental_alert: true が含まれている場合、ルールが一致するとアラートを受信します。

アラートに対するアクション acting-on-alerts

場合によっては、アラートが情報となり、攻撃の頻度を把握できます。上記のダッシュボードを使用して CDN データを分析し、トラフィックスパイクが攻撃によるものであることを検証することをお勧めします。トラフィックスパイクが単なる正当なトラフィック量の増加ではないことがあります。後者の場合は、しきい値を増やすことを検討してください。

攻撃シミュレーション attack-simulation

この節では、DoS 攻撃をシミュレートする方法について説明します。この方法を使用すると、このチュートリアルで使用したダッシュボードのデータを生成し、設定したルールが攻撃を正常にブロックすることを検証できます。

攻撃をシミュレートするには、Apache ベンチマーク、Apache JMeter、Vegeta などのツールを使用できます。

Edge リクエスト

次の Vegeta コマンドを使用すると、web サイトに対して多くのリクエストを行うことができます。

$ echo "GET https://<YOUR-WEBSITE-DOMAIN>" | vegeta attack -rate=120 -duration=5s | vegeta report

上記のコマンドは、5 秒間で 120 件のリクエストを実行し、レポートを出力します。Web サイトにレート制限がないとすると、トラフィックのスパイクが発生する可能性があります。

接触チャネルリクエスト

CDN キャッシュをバイパスして、接触チャネル（AEM パブリッシュサービス）にリクエストを行うには、URL に一意のクエリパラメーターを追加できます。詳しくは、JMeter スクリプトを使用した DoS 攻撃のシミュレーションのサンプル Apache JMeter スクリプトを参照してください。