でのインテリジェントな脅威軽減のベストプラクティス AWS WAF

JavaScript とモバイルアプリケーション統合 SDK を実装する – アプリケーション統合を実装して、可能な限り最も効果的な方法で ACFP、ATP、または Bot Control 機能のすべて有効にします。マネージドルールグループは、SDK が提供するトークンを使用して、セッションレベルで正規のクライアントトラフィックを望ましくないトラフィックから分離させます。アプリケーション統合 SDK は、これらのトークンが常に利用可能であることを確実にします。詳細については、以下を参照してください。

クライアントにチャレンジを実装したり、JavaScript の場合は CAPTCHA パズルがエンドユーザーに提示される方法をカスタマイズしたりするために、統合を使用します。詳細については、「でのクライアントアプリケーション統合 AWS WAF」を参照してください。

JavaScript API を使用して CAPTCHA パズルをカスタマイズし、保護パックまたはウェブ ACL の任意の場所でCAPTCHAルールアクションを使用する場合は、 のクライアントで AWS WAF CAPTCHA レスポンスを処理するためのガイダンスに従ってくださいからの CAPTCHA レスポンスの処理 AWS WAF。このガイダンスは、ACFP マネージドルールグループや Bot Control マネージドルールグループのターゲットを絞った保護レベルなど、CAPTCHA アクションを使用するすべてのルールに適用されます。

ACFP、ATP、Bot Control ルールグループに送信するリクエストを制限する – インテリジェントな脅威軽減 AWS マネージドルールルールグループの使用には追加料金が発生します。ACFP ルールグループは、指定したアカウント登録エンドポイントと作成エンドポイントに対するリクエストを検査します。ATP ルールグループは、指定したログインエンドポイントに対するリクエストを検査します。Bot Control ルールグループは、保護パックまたはウェブ ACL 評価でそれに到達したすべてのリクエストを検査します。

これらのルールグループの使用を減らすため、以下のアプローチを検討してください。

料金の詳細については、「AWS WAF の料金表」を参照してください。

DDoS 対策 DDoS ルールグループに送信するリクエストを制限しない – このルールグループは、明示的に許可していないすべてのウェブトラフィックをモニタリングするように で設定する場合に最適です。ルールアクションを含むルールの後、および他のすべてのAllowルールの前にのみ評価されるように、ウェブ ACL に配置します。

分散型サービス拒否 (DDoS) 保護には、DDoS 対策 DDoS または Shield Advanced アプリケーションレイヤー DDoS 自動緩和のいずれかを使用します。他のインテリジェントな脅威軽減ルールグループは DDoS 保護を提供しません。ACFP は、アプリケーションのサインアップページに対するアカウントの不正な作成の試みから保護します。ATP は、ログインページに対するアカウント乗っ取りの試みを防ぎます。Bot Control は、トークンとクライアントセッションに対する動的なレート制限を使用して、人間のようなアクセスパターンを実施することに重点を置いています。

DDoS 対策を使用すると、DDoS 攻撃をモニタリングおよび制御できるため、脅威に迅速に対応して軽減できます。自動アプリケーションレイヤー DDoS 緩和を備えた Shield Advanced は、ユーザーに代わってカスタム AWS WAF 緩和を作成、評価、デプロイすることで、検出された DDoS 攻撃に自動的に応答します。

Shield Advanced の詳細については、「AWS Shield Advanced 概要」および「AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF」を参照してください。

分散サービス拒否 (DDoS) の防止の詳細については、DDoS 対策 DDoS ルールグループ「」および「」を参照してください分散サービス拒否 (DDoS) の防止。

通常のウェブトラフィック中にアンチ DDoS ルールグループと Bot Control ルールグループのターゲットを絞った保護レベルを有効にする – これらのルールカテゴリには、通常のトラフィックのベースラインを確立する時間が必要です。

通常のウェブトラフィック中に Bot Control ルールグループのターゲットを絞った保護レベルを有効にする – ターゲットを絞った保護レベルのルールの一部では、通常のトラフィックパターンのベースラインを確立してからでないと、不規則なトラフィックパターンや悪意のあるトラフィックパターンに対する認識と対応が行えません。例えば、TGT_ML_* ルールのウォームアップには最大 24 時間かかります。

攻撃が発生していない場合は、これらの保護を追加し、適切に応答することを期待する前にベースラインを確立する時間を与えます。攻撃中にこれらのルールを追加する場合は、カウントモードで Anti-DDoS ルールグループを有効にする必要があります。攻撃が沈静化した後、攻撃トラフィックによってスキューが追加されるため、ベースラインを確立する時間は通常、通常の所要時間の 2 倍から 3 倍になります。ルールとルールのウォームアップに必要な時間に関する詳細については、「ルールの一覧」を参照してください。

分散型サービス拒否 (DDoS) からの保護には、Shield Advanced のアプリケーションレイヤー DDoS 自動緩和を使用する – インテリジェントな脅威の軽減ルールグループは DDoS 保護を提供しません。ACFP は、アプリケーションのサインアップページに対するアカウントの不正な作成の試みから保護します。ATP は、ログインページに対するアカウント乗っ取りの試みを防ぎます。Bot Control は、トークンとクライアントセッションに対する動的なレート制限を使用して、人間のようなアクセスパターンを実施することに重点を置いています。

自動アプリケーションレイヤー DDoS 緩和を有効にして Shield Advanced を使用すると、Shield Advanced はユーザーに代わってカスタム AWS WAF 緩和を作成、評価、デプロイすることで、検出された DDoS 攻撃に自動的に応答します。Shield Advanced の詳細については、「AWS Shield Advanced 概要」および「AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF」を参照してください。

DDoS 対策 DDoS ルールグループのベースラインを確立するときに本番トラフィック負荷を使用する – 人工テストトラフィックを使用して他のルールグループをテストするのが一般的です。ただし、DDoS 対策 DDoS ルールグループのベースラインをテストして確立する場合は、本番環境の負荷を反映するトラフィックフローを使用することをお勧めします。一般的なトラフィックを使用してアンチ DDoS ベースラインを確立することは、ルールグループが本番環境で有効になっているときにリソースを保護する最善の方法です。

トークン処理の調整と設定 – 最適なユーザーエクスペリエンスを実現するために、保護パックまたはウェブ ACL のトークン処理を調整します。

任意のホスト仕様を持つリクエストを拒否する – ウェブリクエストの Host ヘッダーがターゲットリソースに一致することを必須とするように保護対象リソースを設定します。ホストについて、1 つの値、または特定の値セット (myExampleHost.com および www.myExampleHost.com など) を受け入れることはできますが、任意の値は受け入れないでください。

CloudFront ディストリビューションのオリジンである Application Load Balancer の場合、適切なトークン処理 AWS WAF のために CloudFront と を設定します。保護パックまたはウェブ ACL を Application Load Balancer に関連付け、Application Load Balancer を CloudFront ディストリビューションのオリジンとしてデプロイする場合は、「」を参照してくださいCloudFront からの Application Load Balancers に必要な設定。

デプロイ前にテストしてチューニングする – 保護パックまたはウェブ ACL に変更を実装する前に、このガイドのテストとチューニングの手順に従って、期待される動作が得られていることを確認します。これらの有料機能を使用する場合は特に重要です。一般的なガイダンスについては、「AWS WAF 保護のテストとチューニング」を参照してください。有料マネージドルールグループ固有の情報については、「ACFP のテストとデプロイ」、「ATP のテストとデプロイ」、「AWS WAF Bot Control のテストとデプロイ」を参照してください。