Web Application Firewall:カスタムルール

手順 1：保護テンプレートタイプの設定

Web コア保護 ページの カスタムルール セクションで、テンプレートの作成 をクリックします。テンプレートの作成 パネルで、次のパラメーターを設定します。

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

• [デフォルトテンプレート]: カスタムルールモジュールでは、デフォルトテンプレートは 1つしか設定できず、新しいテンプレートの作成時にのみ設定可能です。

  • はい：有効対象 を設定する必要はありません。デフォルトでは、テンプレートは新しく追加されたものを含め、すべての保護対象オブジェクトおよびオブジェクトグループに適用されます。「適用しない」に設定することで、特定のオブジェクトを手動で除外できます。

  • いいえ：テンプレートを適用する保護対象オブジェクトまたはオブジェクトグループを手動で指定するには、有効対象 を設定する必要があります。

手順 2：保護テンプレートへの保護ルールの追加

ルールの設定 セクションで、ルールの作成 をクリックし、次のパラメーターを設定します。

• [Rule Name]：ルール名を入力します。

• [一致条件]: ルールで一致させるリクエストの特性を設定します。条件の追加 をクリックして条件を追加します。各条件は マッチフィールド、論理記号、および マッチコンテンツ で構成されます。次の表に設定例を示します。

  説明

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

  • 複数のエンドポイント (URI) に同じルールを適用するには、単一のルールで Contains One of Multiple Values 論理演算子を使用して OR 関係を作成することをお勧めします。

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

• [Protection Rule Type]: Access Control、Rate Limiting、プラグイン実行 の 3 種類がサポートされています。

  • [Access Control]：特定のリクエストタイプをきめ細かく制御する必要がある場合に適しています。

  • [Rate Limiting]: 不正使用対策やブルートフォース攻撃対策など、アクセス頻度に基づくシナリオに適しています。この機能は、サブスクリプションのエンタープライズ版、アルティメット版、および従量課金インスタンスでのみサポートされています。

  • [プラグイン実行]: 複雑なビジネスロジックにカスタム Lua スクリプトを必要とする、パーソナライズされたセキュリティ制御シナリオに適しています。まず 拡張機能 を設定します。

  [アクセス制御]

  アクセス制御ルールを設定し、特定の条件を満たす個々のリクエストに対して指定したアクションを実行します。

  [レート制限]

  レート制限ルールを設定して、クライアントからの過剰なアクセスを防止します。

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

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

  • レスポンスコード検出条件：特定の Status Code を持つレスポンスの Quantity または Percentage (%) が指定されたしきい値を超えると、ブラックリストアクションがトリガーされます。レスポンスコード検出を有効にした後、統計オブジェクトがレート検出条件とレスポンスコードの特徴条件の両方を満たした場合に、ブラックリストアクションがトリガーされます。

    パラメーター	説明
    [Status Code]	算出対象のステータスコードを設定します。
    [Quantity]	統計期間内のレスポンスで、指定されたStatus Codeが出現する最大回数を設定します。
    [Percentage (%)]	統計期間内に、指定されたStatus Codeのレスポンスの最大パーセンテージを設定します。

  • ブラックリストアクションの条件: 先行する検出条件を満たす統計オブジェクトをブラックリストに追加します。 Timeout Period 内は、Apply To の範囲内で、ブラックリストに登録されたオブジェクトからのリクエストに対して Rule Action で定義されたアクションが実行されます。

    パラメーター	説明
    [Apply To]	ブラックリストアクションの適用範囲を設定します。有効な値： [Current Match Condition]：アクションは、現在のルールの一致条件に一致するリクエストにのみ適用されます。 [Protected Object]: アクションは、統計オブジェクト (IP アドレスなど) から現在の保護対象へのすべてのリクエストに適用されます。
    [Timeout Period]	ブラックリストアクションが有効となる期間を設定します。単位：秒。有効な値：60～86400。

  [拡張機能の実行]

  設定済みの拡張プラグインルールから選択し、パーソナライズされたセキュリティ制御を実装します。

  説明

  拡張実行ルールは、ブロック と モニター の 2 つのルールアクションのみをサポートします。

• [Rule Action]: リクエストがルールに一致した場合に実行する保護アクションを選択します。

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

  説明

  • スライダー をサポートしているのは、従量課金インスタンス、およびサブスクリプションのエンタープライズ版とアルティメット版のインスタンスのみです。

  • JS 検証 と スライダー は、同期リクエストにのみ適用されます。 XMLHttpRequest や Fetch API などを使用した非同期リクエストの場合は、Web SDK を挿入する必要があります。 そうしないと、これらの機能は正常に機能しません。 詳細については、「ボット管理」の JS 検証およびキャプチャのセクションをご参照ください。

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

• 詳細設定 (任意): 以下の高度な機能は、サブスクリプションのエンタープライズ版、アルティメット版、および従量課金インスタンスでのみサポートされます。

  パラメーター	説明
  [規則的グレースケール]	ルールを適用するオブジェクトの割合を、ディメンションごとに設定します。 カナリアリリースを有効にした後、ディメンション と グレースケール も設定する必要があります。ディメンション の有効な値は、IP、カスタムヘッダ、カスタムパラメーター、カスタム Cookie、Session です。 説明 カナリアリリースは、設定されたディメンションに基づいて有効になります。指定された割合のリクエストにルールがランダムに適用されるわけではありません。たとえば、ディメンションをIP に設定し、グレースケールを 10% に設定すると、WAF は IP アドレスの約 10% を選択します。すべてのリクエストの 10% にランダムにルールが適用されるのではなく、選択された IP アドレスからのすべてのリクエストにルールが適用されます。
  [有効化されるモード]	[Permanently Effective] (デフォルト): 保護テンプレートが有効な場合、ルールは永久に有効になります。 [期間ごとに有効化する]：指定された期間内でのみルールが有効になります。 [周期ごとに有効化する]: ルールは、指定された繰り返し期間内でのみ有効です。

手順 3：保護テンプレートの適用対象オブジェクトの設定

有効対象 セクションで、テンプレートを適用する 保護対象オブジェクトおよび保護対象オブジェクトグループを選択します。

適用対象の挙動は、手順 1 の設定によって異なります。

• [デフォルト保護テンプレートとして設定]：適用対象オブジェクトを設定する必要はありません。デフォルトでは、新しく追加されたものも含め、すべての保護対象およびオブジェクトグループにテンプレートが適用されます。特定の対象を手動で除外する場合は、[Not Applied] に設定します。

• [デフォルト保護テンプレートとして設定しない]：テンプレートを適用する保護対象および保護対象グループを手動で指定する必要があります。

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

設定したルールが想定どおりに有効にならない場合は、次の項目を順序どおりに確認してください：

• 保護対象が関連付けられていない：カスタムルールテンプレートが、特定の 保護対象 / グループ (ALB インスタンスやドメイン名など) に正しく関連付けられていることを確認してください。保護対象が追加されていない場合、ルールは有効になりません。

• テンプレートとルールのステータス：保護テンプレートと対象のルールがいずれも「有効」状態であることを確認してください。[テンプレートスイッチ] と、ルールの [ステータス] スイッチの両方がオンになっていることを確認してください。いずれかのスイッチがオフの場合、対応するカスタムルールは有効になりません。

• 一致条件の正確性：マッチフィールド、論理記号、マッチコンテンツ が、リクエストと正しく一致するかを確認してください。正規表現を使用する場合は、特殊文字を適切にエスケープしてください。

• 他のルール：他の保護ルールまたは保護モジュールを設定しているかを確認してください。たとえば、許可リストルール によって、カスタムルールが評価される前にリクエストが通過する場合があります。

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

レート制限ルールは、保護対象ディメンションに基づいて、同一の統計対象のリクエスト頻度を制限します。クラウドサービスインスタンスに複数のドメイン名からのトラフィックが含まれている場合、システムは統計の算出時にすべてのドメイン名にわたるアクセス頻度を集計します。特定のドメイン名のみのアクセス頻度を制限するには、次のいずれかの方法を使用します：

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

• レート制限ルールの 一致条件 で [Host] フィールドを使用し、アクセス頻度を制限するドメイン名を定義します。

異なる Rule Action 設定でリクエストがルールに一致した場合、ユーザーエクスペリエンスはどうなりますか？

• Rule Action を モニター に設定した場合：

  • ルールに一致した後、ユーザーリクエストはオリジンサーバーに到達するか： はい。

  • ルールに一致した後のユーザーエクスペリエンス： WAF が有効になっていない場合と同じです。

• Rule Action を ブロック に設定した場合：

  • ルールに一致した後、ユーザーリクエストはオリジンサーバーに到達するか： いいえ。

  • ルールに一致した後のユーザーエクスペリエンス： デフォルトでは、次のページが返されます。

    

• Rule Action を JS 検証 に設定し、ユーザーが検証に合格した場合 (通常のブラウザーなど)：

  • ルールに一致した後、ユーザーリクエストはオリジンサーバーに到達するか： はい。

  • ルールに一致した後のユーザーエクスペリエンス： 検証プロセスはユーザーに対して透過的です。WAF は応答ヘッダーに Set-Cookie: acw_sc__v2 を設定して検証識別子を発行します。クライアントは後続のリクエストでこの Cookie を自動的に含めます。ブラウザーの開発者ツールを使用して、リクエストヘッダーに acw_sc__v2 フィールドが存在するかを確認し、検証が完了していることを確認できます。

    リクエストがルールにヒットしてオリジンサーバー (nginx) に到達した後、ブラウザーの開発者ツールでリクエストヘッダー情報を確認できます。Cookie フィールド内の acw_sc__v2 の値は、アンチクローラー Cookie です。

    
    Server: nginx/1.24.0 (Ubuntu)
    
    リクエストヘッダー:
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cache-Control: max-age=0
    Connection: keep-alive
    Cookie: acw_tc=781xxx...xxxcbbbeddae542c4d6c39a7ca710; _c_WBKFRo=2ih42xxx...xxxWvi1kCJT26frci; _nb_ioWEgULi=xxx; acw_sc__v2=1234cf0d46-35eb58cc5edc98xxx...xxxea4e10a0826333f3c
    Host: www.xxx.top
    If-Modified-Since: Mon, 23 Mar 2026 08:01:29 GMT
    If-None-Match: W/"69c0f359-267"
    Referer: http://www.xxx.top/
    Upgrade-Insecure-Requests: 1
    

• Rule Action を JS 検証 に設定し、ユーザーが検証に失敗した場合 (自動攻撃ツールなど)：

  • ルールに一致した後、ユーザーリクエストはオリジンサーバーに到達するか： いいえ。

  • ルールに一致した後のユーザーエクスペリエンス： 検証に失敗したクライアントのリクエストはブロックされます。JavaScript を無効にするブラウザープラグインを使用してアクセスする場合、検証に失敗するためページの読み込みに失敗 (白い画面が表示される) し、リクエストヘッダーに acw_sc__v2 Cookie は含まれません。

    リクエストがブロックされた後、HTTP 応答ヘッダーの Set-Cookie によって acw_sc__v2 Cookie がクリアされます (max-age=0)。また、リクエストヘッダーの Cookie フィールドには acw_tc が含まれます。HTTP 応答ヘッダーとリクエストヘッダーの全体は次のとおりです：

    
    レスポンスヘッダー
    Cache-Control          no-cache, no-store
    Connection             keep-alive
    Content-Length         23670
    Content-Type           text/html; charset=utf-8
    Date                   Mon, 23 Mar 2026 11:10:30 GMT
    Pragma                 no-cache
    Server                 Tengine
    Set-Cookie             acw_sc__v2=; expires=Thu, 01 Jan 1970 00:00:00 GMT; max-age=0; path=/; HttpOnly
    
    リクエストヘッダー
    Accept                 text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
    Accept-Encoding        gzip, deflate
    Accept-Language        en-US,en;q=0.9
    Cache-Control          max-age=0
    Connection             keep-alive
    Cookie                 acw_tc=76b20f881xxx xxx798a274eb52ed
    

• Rule Action を スライダー / 厳密なスライダー に設定した場合：

  • ルールに一致した後、ユーザーリクエストはオリジンサーバーに到達するか：

    • 検証に合格したリクエスト：はい。

    • 検証に失敗したリクエスト：いいえ。

  • ルールに一致した後のユーザーエクスペリエンス： デフォルトでは、[アクセス検証] ページが返されます。検証に合格すると、ユーザーは元のページに自動的にリダイレクトされます。検証に失敗すると、エラーメッセージが表示され、ユーザーは現在のページに留まります。検証を再試行するには、ユーザーはページを更新する必要があります。

    ページタイトルは [アクセス検証] で、スライダー検証コンポーネントが含まれています。ユーザーはスライダーを右端まで押したままドラッグして、人間と機械の検証を完了するように求められます。

カスタムルールでボディパラメーターのマッチフィールドを設定した後に機能しないのはなぜですか？

入力したマッチ内容が短すぎる場合に発生することがあります。ボディパラメーター フィールドを使用する場合は、マッチ内容が 5 文字以上であることを確認してください。5 文字未満の場合、トラフィックを検出できません。