Web Application Firewall:カスタムルール

カスタムルールの仕組み

カスタムルールは単純な階層で動作します。ルールは保護テンプレート (または単にテンプレート) にグループ化され、それが保護オブジェクトに適用されます。

• ルール: セキュリティチェックを定義する基本的な構成要素です。主なコンポーネントは次のとおりです。

  • 一致条件: ルールの if 部分です。リクエストパスやクライアント IP アドレスなど、検査対象のリクエストの特性を定義します。

  • ルールアクション: ルールの then 部分です。リクエストが一致した場合の対処方法を定義します。ルールアクションは、ブロック、厳格なスライダー CAPTCHA、スライダー CAPTCHA、JavaScript 検証、モニターの順に優先度が高くなります。

• テンプレート: ルールの具体的な内容と範囲を定義するルールのコレクションです。再利用可能なポリシーと考えることができます。テンプレートタイプ、保護ルール、および適用対象のオブジェクトの 3 つの部分で構成されます。次のタイプを作成できます。作成後にタイプは変更できないことに注意してください。

  • デフォルトテンプレート: グローバルに適用される普遍的な保護ルールを適用するために、自動的にすべての場所に適用されます。

  • カスタムテンプレート: ログインポータルや支払い API など、特定の高リスクサービスに詳細な保護ルールを適用するために、選択した特定のサービスにのみ適用されます。

• 保護オブジェクト: ドメイン名や API など、保護の対象です。複数のオブジェクトを保護オブジェクトグループにグループ化して、管理を容易にすることができます。

ステップ 1: カスタムルールエリアに移動する

1. Web Application Firewall 3.0 コンソールにログインします。

2. トップメニューバーで、WAF インスタンスのリソースグループとリージョン (中国本土 または 中国本土以外) を選択します。

3. 左側のナビゲーションウィンドウで、保護設定 > Web コア保護 を選択します。

ステップ 2: 保護テンプレートを作成する

Web コア保護 ページで、カスタムルール エリアの テンプレートの作成 をクリックします。[テンプレートの作成 - カスタムルール] パネルで、次の構成を完了します。

• テンプレート名: テンプレートの名前を入力します。

• デフォルトテンプレート: このテンプレートをカスタムルールモジュールのデフォルトにするかどうかを指定します。デフォルトテンプレートは 1 つしか作成できず、この設定は永続的であり、作成後に変更することはできません。

  • はい。テンプレートはすべての保護オブジェクトに自動的に適用されます。有効対象 設定を構成する必要はありませんが、後で特定のオブジェクトを手動で除外できます。

  • いいえ: デフォルトでは、テンプレートはどのオブジェクトにも適用されません。有効対象 設定を手動で構成して、適用する特定の保護オブジェクトまたはグループを選択する必要があります。

ステップ 3: 保護テンプレートに保護ルールを追加する

ルールの設定 エリアで、ルールの作成 をクリックし、次のパラメーターを構成します。

• Rule Name: ルールの名前を入力します。

• 一致条件: リクエストに一致する条件を指定します。条件の追加 をクリックして条件を追加します。各条件は、マッチフィールド、論理記号、および マッチコンテンツ で構成されます。以下の構成例を参照してください。

  説明

  ルールに複数の条件が含まれている場合、リクエストがルールに一致するには、すべての条件 (論理 AND) を満たす必要があります。一致フィールドと論理演算子の詳細については、「一致条件」をご参照ください。

  マッチフィールド	論理記号	マッチコンテンツ	説明
  URI パス	次を含む	/login.php	リクエストパスに /login.php が含まれている場合、リクエストはルールに一致します。
  IP	所属する	192.1.XX.XX	クライアント IP アドレスが 192.1.XX.XX の場合、リクエストはルールに一致します。

• Protection Rule Type: [アクセスの制御] と Rate Limiting の 2 つのタイプをサポートします。

  • [アクセスの制御]: 特定のタイプのリクエストを正確に制御する必要があるシナリオに適しています。

  • Rate Limiting: クレデンシャルスタッフィングやブルートフォース攻撃の防止など、リクエストレートに基づくシナリオに適しています。この機能は、サブスクリプションベースの Enterprise および Ultimate インスタンス、および従量課金インスタンスでのみ利用できます。

  アクセスの制御

  アクセス制御ルールを構成して、特定の条件を満たすリクエストに指定されたアクションを適用します。

  Rate Limiting

  レート制限ルールを構成して、クライアントからの過剰なアクセスを緩和します。

  • レート制限条件: 単一の Statistical Object が指定された 統計期間 (秒) 内にルールに一致する回数が、設定された しきい値 (回) を超えると、ブラックリストアクションがトリガーされます。

    パラメーター	説明
    Statistical Object	リクエストレートを測定するオブジェクトを選択します。オプション: IP: 同じ IP アドレスからのリクエストレートを測定します。 Custom Header: Referer などのカスタムリクエストヘッダーの値に基づいてリクエストをグループ化し、指定された期間内に同一のヘッダー値の各グループのリクエストレートを測定します。 Custom Parameter: URL に指定されたパラメーターを含むリクエストレートを測定します。たとえば、パラメーターが user_id の場合、WAF は同じ user_id 値を持つリクエストレートを測定します。 Custom Cookie: 指定された期間内に特定の Cookie を含む HTTP リクエストのレートを測定します。たとえば、カスタム Cookie 名が User の場合、WAF は期間内の各 User 値の出現回数をカウントします。 Session: WAF は、応答に acw_tc という名前の Cookie を設定してセッション ID を確立し、この Cookie の値に基づいてクライアントのリクエストレートを測定します。 Account: 同じアカウントからのリクエストレートを測定します。このオプションを使用する前に、保護対象 ページで アカウント抽出設定 を構成する必要があります。詳細については、「ユーザー識別」をご参照ください。
    統計期間 (秒)	統計期間を秒単位で設定します。
    しきい値 (回)	Statistical Object が 統計期間 (秒) 内に 一致条件 に一致できる最大回数を設定します。

  • ステータスコード検出条件: 特定の Status Code の Quantity または Percentage (%) が設定されたしきい値を超えると、ブラックリストアクションがトリガーされます。ステータスコード検出を有効にした場合、統計オブジェクトはレート制限条件とステータスコード条件の両方を満たしてブラックリストアクションをトリガーする必要があります。

    パラメーター	説明
    Status Code	監視するステータスコードを設定します。
    Quantity	指定された Status Code が統計期間内にリクエスト応答に表示される最大回数を設定します。
    Percentage (%)	指定された Status Code を含む応答の最大割合を統計期間内に設定します。

  • ブラックリストアクション条件: 上記の検出条件を満たす統計オブジェクトをブラックリストに追加します。Timeout Period の間、WAF は構成された Rule Action を、ブラックリストの Apply To スコープ内にあるこのオブジェクトからのリクエストに適用します。

    パラメーター	説明
    Apply To	ブラックリストアクションのスコープを設定します。オプション: Current Match Condition: 現在のルールの 一致条件 を満たすリクエストのみを処理します。 Protected Object: 統計オブジェクト (IP アドレスなど) から現在の保護オブジェクトにアクセスするすべてのリクエストを処理します。
    Timeout Period	ブラックリストアクションが有効である期間を設定します。単位: 秒。値の範囲: 60 ～ 86,400。

• Rule Action: リクエストがルールに一致したときに実行するアクションを選択します。

  パラメーター	説明
  JS 検証	WAF はクライアントに JavaScript スニペットを返します。標準的なブラウザはこのコードを自動的に実行します。クライアントが正常に実行した場合、WAF はそのクライアントからのすべてのリクエストを一定期間 (デフォルトは 30 分) 許可します。それ以外の場合は、リクエストをブロックします。
  ブロック	ルールに一致するリクエストをブロックし、クライアントにブロックページを返します。 説明 デフォルトでは、WAF は標準のブロックページを使用します。カスタム応答を使用してブロックページをカスタマイズすることもできます。
  モニター	ルールに一致するリクエストを通過させますが、一致イベントをログに記録します。ルールをテストするときは、まずそのアクションを モニター に設定し、WAF ログを分析して、アクションを変更する前に正当なトラフィックがブロックされていないことを確認します。
  スライダー	WAF はクライアントにスライダー CAPTCHA ページを返します。クライアントがチャレンジを正常に完了した場合、WAF はそのクライアントからのすべてのリクエストを一定期間 (デフォルトは 30 分) 許可します。それ以外の場合は、リクエストをブロックします。
  厳密なスライダー	WAF はクライアントにスライダー CAPTCHA ページを返します。クライアントがチャレンジを正常に完了した場合、リクエストは許可されます。それ以外の場合はブロックされます。このモードでは、クライアントはルールに一致するすべてのリクエストに対してスライダーチャレンジを完了する必要があります。

  説明

  • スライダー 検証は、サブスクリプションベースの Enterprise および Ultimate インスタンス、および従量課金インスタンスでのみ利用できます。

  • JS 検証 と スライダー は同期リクエストにのみ適用されます。XMLHttpRequest や Fetch API を使用するような非同期リクエストで機能が正しく動作するようにするには、Web SDK を挿入します。詳細については、「ボット管理」の JS チャレンジとスライダー CAPTCHA のセクションをご参照ください。

  • JS 検証 または スライダー が有効になっている場合、WAF はクライアントが検証に合格した後、Set-Cookie を介して応答ヘッダーに Cookie を設定します。Cookie の名前は、JavaScript 検証の場合は acw_sc__v2、スライダー CAPTCHA の場合は acw_sc__v3 です。クライアントは、後続のリクエストの Cookie ヘッダーにこの識別子を含めます。

• 詳細設定 (オプション): 次の高度な機能は、サブスクリプションベースの Enterprise および Ultimate インスタンス、および従量課金インスタンスでのみ利用できます。

  パラメーター	説明
  Canary Release	さまざまなディメンションに基づいて、ルールが適用されるオブジェクトの割合を構成します。 カナリアリリースを有効にした後、Dimension と Canary Release Proportion を設定します。Dimension は IP、カスタムヘッダ、[カスタムパラメーター]、カスタム Cookie、または Session にすることができます。
  Effective Mode	Permanently Effective (デフォルト): 保護テンプレートが有効な場合、ルールは常にアクティブです。 期間ごとに有効化する: 保護ルールは指定された時間範囲でのみアクティブです。 周期ごとに有効化する: 保護ルールは指定された定期的なサイクルでのみアクティブです。

ステップ 4: 保護テンプレートの適用先を指定する

有効対象 エリアで、このテンプレートの 保護オブジェクトと保護オブジェクトグループ を選択します。

テンプレートの適用方法は、ステップ 2 の構成によって異なります。

• デフォルトテンプレート を [はい] に設定: オブジェクトを指定する必要はありません。テンプレートは、現在および将来のすべての保護オブジェクトと保護オブジェクトグループに自動的に適用されます。特定のオブジェクトを手動で除外できます。

• デフォルトテンプレート を [いいえ] に設定: テンプレートを適用する保護オブジェクトとオブジェクトグループを手動で選択します。

保護ルール構成の例

管理者バックエンドへのアクセスを特定の IP に制限する

管理者 IP アドレス 192.1.XX.XX からのアクセスを除き、/wp-admin パスへのすべてのアクセスをブロックします。

• 一致条件:

  • マッチフィールド: IP、論理記号: 等しくない、マッチコンテンツ: ホワイトリストに登録された管理者 IP アドレス 192.1.XX.XX。

  • マッチフィールド: URI、論理記号 : 次を含む、マッチコンテンツ: 制限された Web パス /wp-admin。

• Protection Rule Type: アクセスの制御。

• Rule Action: ブロック。

悪意のあるクローラーとスキャナーをブロックする

User-Agent (UA) フィールドに bot が含まれる HTTP リクエストをブロックします。

• 一致条件: マッチフィールド: User-Agent、論理記号: 次を含む、マッチコンテンツ: bot。

• Protection Rule Type: アクセスの制御。

• Rule Action: ブロック。

Web ページの CAPTCHA または JavaScript 検証の 有効化

API エンドポイントを除くすべてのページに CAPTCHA または JavaScript 検証を適用します。この例では、すべての API エンドポイント URI に文字列 /api が含まれていると仮定します。

• 一致条件: マッチフィールド: URI、論理記号: 次を含まない、マッチコンテンツ: /api。

• Protection Rule Type: アクセスの制御。

• Rule Action: スライダー CAPTCHA または JavaScript 検証。

API エンドポイントにレート制限を適用する

example.com/api/pay を除くすべての API エンドポイントに対してレート制限を有効にします。この例では、すべての API インターフェイス URI に文字列 /api が含まれています。

• 一致条件:

  • マッチフィールド: URI、論理記号: 等しくない、マッチコンテンツ: /api/pay。

  • マッチフィールド: URI、論理記号: 次を含む、マッチコンテンツ: /api。

• Protection Rule Type: レート制限。

• Statistical Object: IP。

• 統計期間 (秒): 10。

• しきい値 (回): 5。

• Apply To: Current Match Condition。

• Timeout Period: 1800。

• Rule Action: ブロック。

本番環境での適用

サービスの中断を避けるため、Block アクションを持つ新しいルールを本番環境に直接適用しないでください。以下のデプロイメントプロセスに従うことをお勧めします。

1. リクエスト特性の分析: WAF の セキュリティレポート と ログ を使用して、IP アドレス、User-Agent、ヘッダー、URI など、通常のサービスリクエストと悪意のある攻撃の特性を特定します。レート制限ルールを構成する予定の場合は、通常のサービスのリクエストレートのベースラインも決定する必要があります。

2. ホワイトリストの構成: カスタムルールテンプレートを作成する前に、ホワイトリストルール を作成し、信頼できる IP アドレスをホワイトリストに追加します。これにより、信頼できるリクエストが新しいルールによって誤ってブロックされるのを防ぎます。

3. カナリアリリーステストの実施: カスタムルールを作成した後、次の 3 つの方法のいずれかを使用して、本番環境にデプロイする前にその動作をテストおよび観察できます。

   • テストのためにルールを非本番環境に適用します。

   • Rule Action を モニター に設定します。

   • 詳細設定 で Canary Release を有効にします。

4. テスト結果の分析: テスト期間の後、ルールに一致するリクエストの中に誤検知がないか、セキュリティレポートとログを確認します。

5. 本番環境への適用: 誤検知率が許容範囲内であることを確認したら、ルールのアクションを意図したアクションに変更し、本番環境に適用します。

6. 継続的な監視と最適化: セキュリティレポートとログを継続的に監視し、ビジネスの変化と保護効果に基づいてルールを動的に調整および最適化します。

その他の操作

• スライダー、Rate Limiting、および 詳細設定 は、サブスクリプションベースの Enterprise および Ultimate インスタンス、および従量課金インスタンスでのみ利用できます。

• 単一の保護ルールには、最大 5 つの一致条件を設定できます。

ルールが有効にならないのはなぜですか？

ルールが有効にならない場合は、次の項目を順番に確認してください。

• テンプレートのステータス: 保護テンプレートとルールの両方のステータスが有効に設定されていることを確認します。

• 適用対象: 保護オブジェクトの適用ステータスが 有効 であることを確認します。

• ルール構成: ルールの構成、特に [一致条件] を確認して、意図したリクエストを対象としていることを確認します。

• その他のルール: 競合するルールやモジュールがないか確認します。たとえば、ホワイトリストルール は、リクエストが他のチェックをバイパスすることを許可します。

複数のドメインが単一のクラウドサービスインスタンスに解決される場合、レート制限をどのように構成すればよいですか？

レート制限ルールは、保護オブジェクトレベルで統計オブジェクトのリクエストレートを制限します。単一のクラウドサービスインスタンスが複数のドメインのトラフィックを処理する場合、WAF は関連するすべてのドメインからのトラフィックを集約してリクエストレートを計算します。特定のドメインのリクエストレートのみを制限する必要がある場合は、次の 2 つの方法のいずれかを選択します。

• 方法 1: 専用の保護オブジェクトを作成する

  ドメイン名を WAF の保護オブジェクトとして追加し、そのドメイン名オブジェクトにレート制限ルールを適用します。詳細については、「保護オブジェクトと保護オブジェクトグループの構成」をご参照ください。

• 方法 2: 一致条件で Host ヘッダーを使用する

  レート制限ルールの 一致条件 セクションで、[Host] フィールドを使用して、リクエストレートを制限したい正確なドメインを指定します。

一致フィールドを Body Parameter に構成した後、ルールが有効にならないのはなぜですか？

これは、一致内容が短すぎる場合に発生する可能性があります。Body Parameter フィールドを使用する場合、一致内容が 5 文字以上であることを確認してください。そうでない場合、WAF はトラフィックを検査できません。