Web Application Firewall:保護設定に関する FAQ

特定の保護ルール ID を検索する方法

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

組み込みコア Web 保護ルールを検索する

1. Web アプリケーションファイアウォール 3.0 コンソールにログインします。上部のナビゲーションバーで、お使いの WAF インスタンスのリソースグループとリージョン (中国本土 または 中国本土以外) を選択します。

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

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

4. エンジン構成 ページでルールを検索します。

カスタムルールを検索する

Web コア保護 の下にある カスタムルール、HTTP Flood Protection、スキャン保護 などの他のモジュール用のカスタムルールを見つけるには、次の手順に従います。

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

2. ページでルールを検索します。

ホワイトリストルールを検索する

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

2. ページでルールを検索します。

ボット管理ルールを検索する

保護ルールが削除された場合

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

WAF ログにおける acl_action:block の意味

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

ボディパラメーターフィールドを使用したカスタムルールが有効にならない場合

考えられる原因は、指定された一致コンテンツが短すぎることです。[Body Parameter] フィールドを使用してトラフィックを検出するには、一致コンテンツを 4 文字より長くする必要があります。たとえば、パラメーター名を name に、論理演算子を [equals] に、一致コンテンツを David に設定できます。この値の長さは 5 文字で、4 文字を超えています。

ダブルスラッシュ (//) を含む URL に対するルールが有効にならない場合

WAF ルールエンジンは、連続するスラッシュ (/) を 1 つのスラッシュに圧縮することで URL を正規化します。したがって、ダブルスラッシュ (//) を含む URL に一致するように設定されたカスタムルールはトリガーされません。

二重スラッシュ (//) を含む URL に対して ACL アクセス制御を設定する場合、対応する単一スラッシュのパスを一致条件として直接使用できます。 たとえば、URL パス //api/sms/request に一致させるには、一致内容として /api/sms/request を入力するだけです。 これにより、WAF はこのパスを含むリクエストにアクセス制御を適用します。

リクエスト ID を使用して WAF ブロックを調査する方法

WAF がリクエストをブロックすると、一意のリクエスト ID がレスポンスで返されます。この ID を使用して、セキュリティレポートまたはログで詳細を検索し、リクエストがブロックされた理由を特定できます。

1. リクエスト ID を取得する：リクエストがブロックされると、ブロックページにデフォルトでリクエスト ID が表示されます。後の検索で使用するために ID をコピーします。

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

   説明

   保護対象のログ配信が有効になっている場合、検知レスポンス > SLS ページで検索を実行することもできます。

3. ブロック理由の分析: セキュリティレポート ページで、リクエストの 保護モジュール と ヒットしたルール を表示します。リクエストが正当であると判断した場合は、ログリスト でリクエストを検索し、操作 列にある 誤検知の無視 をクリックします。詳細については、「ホワイトリスト」をご参照ください。

従量課金 WAF の API セキュリティを無効にする方法

従量課金 WAF インスタンスで API セキュリティ機能が不要になった場合は、以下の手順に従って無効にします。

1. Web Application Firewall 3.0 コンソールにログインします。上部のナビゲーションバーで、WAF インスタンスのリソースグループとリージョン（中国本土 または 中国本土以外）を選択します。

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

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

4. すべての保護オブジェクトおよび保護オブジェクトグループの 基本検査 スイッチをオフにします。オフにすると、履歴 API Security データがクリアされ、アクセスできなくなります。

WAF による CORS ヘッダーの処理

WAF は、リクエストの CORS ヘッダーを変更 しません。また、CORS レスポンスヘッダーを自動的に挿入したり、Origin ヘッダーを動的にエコーバックしたりする設定項目も提供 しません。CORS ポリシーは、オリジンサーバーまたはアプリケーションで設定および管理する必要があります。

"413 Request Entity Too Large" エラーが発生する理由

原因：アップロードされたファイルのサイズが、1 回のリクエストに対する WAF の制限 (現在 2 GB) を超えています。

解決策：

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

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

WAF ブロックアラートについて

WAF ブロックアラートを受信することは、保護メカニズムが機能していることを示します。これは必ずしもサービスが影響を受けていることを意味するわけではありません。ただし、場合によっては、誤検知や保護の失敗を確認する必要があります。

アラートの意味

WAF ブロックアラートは、システムがセキュリティルールに一致する悪意のあるリクエストを正常に識別してブロックしたことを意味します。これらのリクエストは、オリジンサーバーに到達する前にフィルタリングされます。オリジンサーバーのリソースを消費しません。これは、保護が意図したとおりに機能していることを示しています。

調査が必要なシナリオ

1. 誤検知：バックエンドログインや API 呼び出しなどの正当なユーザートラフィックがブロックされている場合、保護ルールが厳しすぎる可能性があります。この場合、サービスの可用性が影響を受けます。保護ルールを調整するか、リクエストの特性をホワイトリストに追加する必要があります。

2. 大規模な CC 攻撃：高頻度の CC 攻撃を受けている場合、WAF がトラフィックをブロックしていても、一部の悪意のあるリクエストが WAF 保護をバイパスする可能性があります。さらに、過剰な攻撃トラフィックによってブラックホールフィルタリングがトリガーされ、WAF サービスが利用できなくなる可能性があります。防御戦略の詳細については、「HTTP フラッド攻撃対策ルールを設定して CC 攻撃を防御」をご参照ください。

スクリプトファイルのアップロードに対するデフォルトポリシー

デフォルトの WAF 保護ポリシーは、主に SQL インジェクションやクロスサイトスクリプティング (XSS) などの高頻度 Web 攻撃、および JSP、PHP、ASP などの一般的な Web シェルを防御するように設計されています。

.py、.sh、.cmd、.bat  などのスクリプトファイルの拡張子は、正規のバックグラウンドタスクやバッチ処理によく使用されます。通常の業務リクエストを誤ってブロックすることを避けるため、デフォルトポリシーでは、これらの拡張子はグローバルなブロック範囲に含まれていません。

これらのアップロードをブロックする必要がある場合は、カスタムルールを作成して、アップロード API パスとファイル拡張子を照合することで、アップロードを正確に制御することを推奨します。

中国国外の IP をブロックしながらクローラーを許可する方法

これは、設定を組み合わせることで実現できます。

1. 地域ブロック機能を有効にし、Outside China の地域からのすべてのリクエストをブロックするように設定します。

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

前方一致と正規表現マッチの比較

1. 一致機能：前方一致は、固定文字列にのみ一致するシンプルなモードです。正規表現マッチは、複雑なパターンマッチングをサポートする高度なモードです。

2. パフォーマンス：前方一致は非常に効率的です。正規表現マッチは、内部エンジンの複雑さによりリソースを若干多く消費し、従量課金 WAF インスタンスを使用している場合はコストがわずかに高くなります。

3. ルールのチューニングに関する推奨事項: ルールで期待される保護が得られない場合は、一致方法が適切かどうかを確認してください。 たとえば、URI パスの場合、単一のプレフィックスまたはサフィックスによる一致の代わりにContains One of Multiple ValuesまたはRegex Matchを使用することで、一致率を向上させることができます。 正規表現による一致を使用する場合、正規表現が整形式であることを確認し、複雑なネストを避けてください。

ホワイトリストルールの有効時間

ホワイトリストルールは、追加後 すぐに 有効になります。既存のブロック期間が終了するまで待つ必要はありません。

ルールを設定した後もリクエストがブロックされる場合は、以下の項目を確認してください。

• テンプレートとルールのスイッチがオンになっている。

• [適用対象] 設定が正しい。

• 一致条件が正しく設定されている。

• CDN や Anti-DDoS などのレイヤー 7 プロキシが WAF の前面にデプロイされている場合、アセットを追加する際に、WAF の前にレイヤー 7 プロキシがあるかどうか (Anti-DDoS Proxy や CDN など) オプションを選択する必要があります。そうしないと、WAF は実際のクライアント IP アドレスを取得できません。

レート制限ルールによってブラックリストに登録されたオブジェクトを管理する方法

• 手動でのブロック解除：このシナリオでは、オブジェクトを手動でブロック解除することはできません。アクセスをすぐに復元するには、以下のいずれかの方法を使用します。

  • ホワイトリストルールを作成する (推奨)：ホワイトリストルールを追加して、リクエストを許可します。

  • ルール設定の変更: ルールの 一致条件、アクション、Statistical Object、または [しきい値] を変更すると、そのルールの履歴ブラックリストがクリアされ、以前にブロックされていたすべてのオブジェクトのブロックが解除されます。

• 永続的なブロック：サポートされていません。最大ブロック期間は 86,400 秒 (24 時間) です。

空または欠落している Referer を含むリクエストをブロックする方法

両方のシナリオをカバーするには、以下の 2 つの一致条件を追加する必要があります。

• ヘッダーフィールド Referer の論理演算子は Does Not Exist に設定されています。

• ヘッダーフィールド Referer の論理演算子は Empty に設定されています。

リスク警告

この設定により、内部サーバーの呼び出し、API リクエスト、クライアント SDK からのリクエストなど、Referer ヘッダーを含まない正当なリクエストがブロックされる可能性があります。このような正当なトラフィックを許可するために、ホワイトリストルールを作成することを推奨します。

異なるポート間でルールトリガーに一貫性がない場合

WAF 保護テンプレートは、保護対象ごとに独立して有効になります。特定のポートでルールがトリガーされない場合、通常は、ポートが WAF に正しく追加されていないか、正しい保護テンプレートに関連付けられていないことが原因です。

トラブルシューティングと解決策

1. ポート接続ステータスを確認する：影響を受けるポートが WAF に正常に追加されていることを確認します。

2. ポリシーバインディングを確認する：ポートに対応する保護対象が、意図した保護テンプレートに正しく関連付けられていることを確認します。

ホワイトリストルールの他のモジュールに対する優先度

ホワイトリストルールの優先度が最も高くなります。リクエストがホワイトリストルールに一致すると、WAF は Bypassed Modules で指定されたモジュールをバイパスします。

API を使用してルールに IP を追加する方法

はい。詳細については、「コア Web 保護ルールの作成」をご参照ください。

WAF フィンガープリントルールの仕組み

フィンガープリントルールは、IP アドレスではなく、クライアントブラウザーまたはツールの特性から生成されたハッシュ値に基づいてリクエストに一致します。詳細は以下のとおりです。

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

2. JA4 フィンガープリント：このフィンガープリントは、ブラウザーバージョンやオペレーティングシステムを含むより多くの情報を利用して、重複を減らします。

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

リクエストが一致するフィンガープリントを含んでいる限り、IP アドレスの地理的な発信元に関係なくルールがトリガーされます。

WAF によるドメインリダイレクトのサポート

いいえ。WAF はドメインリダイレクト機能を提供しません。このタイプのリダイレクトを実装するには、オリジンサーバーまたは DNS レイヤーで設定する必要があります。