Web Application Firewall:保護構成に関するよくある質問

WAF コンソールで特定の保護ルール ID を見つけることができないのはなぜですか？

WAF コンソールで特定のルール ID を見つけられない場合は、ルールの種類に応じて以下の項目を確認してください。

組み込みの Web コア保護ルールの検索

1. Web Application Firewall 3.0 コンソール にログインします。上部メニューバーから、WAF インスタンスのリソースグループおよびリージョン（中国本土 または 中国本土以外）を選択します。。

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

3. 対象の保護テンプレートを特定して展開し、エンジン構成 を 操作 列でクリックします。

4. 表示される エンジン構成 ページで、ルールを検索します。

カスタムルールの検索

Web コア保護 配下の他の保護モジュール（カスタムルール、HTTP Flood Protection、スキャン保護 など）のカスタムルールを検索するには、次の手順を実行します。

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

2. 次の図に示す場所で検索します。

ホワイトリストルールの検索

1. 左側のナビゲーションウィンドウで、保護設定 > ホワイトリスト を選択します。

2. 次の図に示す場所で検索します。

ボット管理ルールの検索

保護ルールが削除されている

前述のいずれの場所でもルールが見つからない場合、そのルールは削除されている可能性があります。Operation Audit を使用して、DeleteDefenseRule または DeleteDefenseTemplate という名前のイベントが存在するかどうかを確認できます。詳細については、「ActionTrail コンソールでのイベントの照会」をご参照ください。

WAF ログ内の acl_action:block は、リクエストが実際にブロックされたことを示していますか？

acl_action:block は必ずしもリクエストがブロックされたことを意味しません。acl_test が true に設定されている場合、これは観測モードを示します。このモードでは、ログのみ記録され、ブロックなどの保護アクションはトリガーされません。リクエストが実際にブロックされたかどうかを判断するには、final_action フィールドを確認してください。final_action:block は、リクエストがブロックされたことを示します。

マッチフィールドを Body Parameter に設定した後、カスタムルールが有効にならないのはなぜですか？

これは、入力したマッチ内容が短すぎるためです。Body Parameter フィールドを使用する際は、マッチ内容が 4 文字以上であることを確認してください。そうでない場合、トラフィックを検出できません。

URL マッチフィールドに二重スラッシュ (//) を含むカスタム保護ポリシールールが有効にならないのはなぜですか？

WAF ルールエンジンはデフォルトで、連続するスラッシュ (/) を圧縮することにより URL を正規化します。そのため、URL マッチフィールドに二重スラッシュ (//) を含むカスタム保護ポリシールールは正しくマッチしません。

二重スラッシュ (//) を含む URL の ACL ルールを構成するには、対応する単一スラッシュのパスをマッチ条件として使用します。たとえば、URL マッチフィールドの条件値として //api/sms/request を使用したい場合は、マッチ内容フィールドに /api/sms/request を入力します。これにより、WAF はこのパスを含むリクエストにアクセス制御を適用できます。

リクエスト ID を使用して WAF によってブロックされたリクエストの原因をトラブルシューティングするにはどうすればよいですか？

WAF によってリクエストがブロックされると、システムは応答に一意のリクエスト ID を返します。この ID を使用してセキュリティレポートまたはログ内で詳細情報を検索し、ブロックの原因を特定できます。

1. リクエスト ID の取得：リクエストがブロックされた後、リクエスト ID はブロッキングページにデフォルトで表示されます。この ID をコピーして、以降の検索に使用します。

2. WAFコンソールでの検索: WAF 3.0コンソールにログインします。左側のナビゲーションウィンドウで、検知レスポンス > セキュリティレポートを選択します。検索の時間範囲を設定し、traceidを入力してください検索ボックスにリクエスト ID を貼り付けます。

   説明

   保護対象で log delivery が有効になっている場合は、検知レスポンス > SLS ページでも検索できます。

3. ブロック原因の分析：セキュリティレポート ページで、ページ下部の 保護モジュール および ヒットしたルール を確認します。リクエストが正常なビジネストラフィックであると確認できた場合は、ログリスト の 操作 列にある 誤検知の無視 をクリックして、リクエストをホワイトリストに追加します。詳細については、「ホワイトリスト」をご参照ください。

従量課金の WAF インスタンスで API Security 機能を無効化するにはどうすればよいですか？

従量課金の WAF インスタンスで API Security 機能が不要になった場合は、次の手順で無効化します。

1. Web Application Firewall 3.0 コンソール にログインします。上部メニューバーから、WAF インスタンスのリソースグループおよびリージョン（中国本土 または 中国本土以外）を選択します。。

2. 左側のナビゲーションウィンドウで、保護設定 > API セキュリティ を選択します。

3. ポリシーの設定 > 有効オブジェクトの設定 タブに移動します。

4. すべての保護対象および保護対象グループについて、基本検査 スイッチをオフにします。この操作により、API Security の既存データはパージされ、以後閲覧できなくなります。

Alibaba Cloud WAF は CORS レスポンスヘッダーを挿入したり、Origin リクエストヘッダーを動的にエコーしたりしますか？

WAF はリクエストの CORS ヘッダーを変更せず、CORS レスポンスヘッダーを自動的に挿入したり Origin ヘッダーを動的にエコーしたりするための構成オプションも提供していません。CORS ポリシーは、オリジンサーバーまたはご利用のアプリケーションで構成・管理する必要があります。

WAF が 413 Request Entity Too Large エラーを返す原因は何ですか？

原因：アップロードされたファイルが、WAF で設定された最大リクエストサイズ制限（現在 2 GB）を超えています。

解決方法：

• 各リクエストが 2 GB 未満になるようにファイルサイズを縮小します。

• Ultimate エディションに WAF をアップグレードします。Ultimate エディションでは最大 10 GB のファイルをサポートします。詳細については、「アップロードファイルサイズ」をご参照ください。

WAF インターセプトアラートを受信した場合、業務に影響が出ているということですか？

WAF インターセプトアラートを受信することは、セキュリティ保護メカニズムが正常に動作していることを示しており、必ずしも業務に影響が出ていることを直接意味するものではありません。ただし、特定のシナリオでは誤検知や保護の失敗の可能性を調査する必要があります。

アラートの意味

WAF インターセプトアラートは、システムがセキュリティルールに一致する攻撃リクエストを正常に識別・ブロックしたことを示します。このようなリクエストはオリジンサーバーに到達する前にクリーンアップされ、オリジンサーバーのリソースを消費したり、実際の攻撃による損害を引き起こしたりすることはありません。これは保護メカニズムが正常に機能しているサインです。

調査が必要なシナリオ

1. 誤検知：正当なユーザーのアクセス（バックエンドログインや API 呼び出しなど）がブロックされている場合、ルール構成が厳しすぎて誤ってブロックしている可能性があります。この場合、業務の可用性に影響が出ているため、保護ルールを調整するか、関連する特徴をホワイトリストに追加する必要があります。

2. 大規模な CC 攻撃：高頻度の CC 攻撃を受けている場合、WAF がインターセプトを実行していても一部のリクエストが通過してしまうことがあります。また、過剰な攻撃トラフィックによりブラックホールメカニズムがトリガーされ、WAF サービスが利用できなくなる可能性があります。具体的な防御戦略については、「HTTP フラッド攻撃対策の構成」をご参照ください。

デフォルトの WAF 保護ポリシーが .py/.sh などのスクリプトファイルのアップロードをインターセプトしないのはなぜですか？

デフォルトの WAF 保護ポリシーは、主に高頻度の Web 攻撃（SQL インジェクションや XSS など）および一般的な Web シェル（JSP、PHP、ASP）を対象としています。

.py、.sh、.cmd、.bat などのスクリプトファイル拡張子は、バックグラウンドタスクやバッチ処理など正当なビジネスシナリオで一般的に使用されます。正常なビジネスリクエストをブロックしないようにするため、デフォルトポリシーではこれらの拡張子をグローバルインターセプト範囲に含めていません。

このようなアップロードをインターセプトする必要がある場合は、「カスタムルール」を使用して、アップロードインターフェイスのパスおよびファイル名拡張子をマッチさせることで、アップロードを正確に制御することを推奨します。

海外 IP をブロックしつつ、特定の検索エンジンクローラーを許可するにはどうすればよいですか？

以下のように組み合わせて構成することで実現できます。

1. 地域ブロッキングルールの構成 機能を有効にし、Outside China のすべての地域をブロックするように選択します。

2. ホワイトリスト を作成します。一致条件 を、特定のクローラー識別子（Googlebot や bingbot など）を含む User-Agent に設定し、Bypassed Modules を リージョンのブロック に設定します。

プレフィックスマッチングと正規表現マッチングの違いは何ですか？どのように選べばよいですか？

1. マッチング能力：プレフィックスマッチングはシンプルモードで、固定文字列マッチングのみをサポートします。正規表現マッチングは高度なルールで、複雑なパターンマッチングをサポートします。

2. パフォーマンス：プレフィックスマッチングは実行効率が高いです。正規表現マッチングは、基盤となるエンジンの複雑さによりリソースをやや多く消費し、従量課金エディションではコストがやや高くなります。

3. ルールチューニングの提案：現在のルールが期待通りにブロックしない場合は、マッチング方法が不適切でないか確認してください。たとえば、URI パスの場合は、単一のプレフィックス/サフィックスマッチではなく、Contains One of Multiple Values または Regex Match を試してヒット率を向上させることができます。正規表現マッチングを使用する際は、正規表現の構文に注意し、複雑なネストを避けてください。

ホワイトリストは構成後にすぐに有効になりますか？それとも禁止期間が終了するまで待つ必要がありますか？

ホワイトリストルールを追加すると、即時に有効になります。元の禁止期間が終了するのを待つ必要はありません。

構成後も引き続きブロックされている場合は、以下の点を確認してください。

• テンプレートおよびルールのスイッチが有効になっていることを確認します。

• [Apply To] 設定が正しいことを確認します。

• マッチ条件が正確であることを確認します。

• WAF の前に CDN や Anti-DDoS などのレイヤー 7 プロキシが存在するかどうかを確認します。存在する場合は、アセットを追加する際に WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など) オプションを正しく構成する必要があります。そうしないと、WAF はクライアントの実 IP を取得できません。

WAF 指紋ルール (JA3/JA4/HTTP2) のマッチング原則とは何ですか？なぜ IP 以外のディメンションからヒットするのですか？

指紋ルールは、IP アドレスではなく、クライアントのブラウザーやツールの特性から生成されたハッシュ値に基づいてマッチします。具体的には以下のとおりです。

1. JA3 フィンガープリント：TLS ハンドシェイクの主要パラメーター（バージョン、暗号スイートなど）に MD5 ハッシュ化を適用して生成されます。

2. JA4 フィンガープリント：重複を減らすために追加アルゴリズム（ブラウザーバージョン、OS など）を導入しています。

3. HTTP/2 フィンガープリント：HTTP/2 クライアントのオリジナルフィンガープリントに基づき、MD5 アルゴリズムを使用して生成されます。

リクエストがマッチするフィンガープリント署名を保持していれば、IP の地理的出自に関係なくルールがトリガーされます。