次の方法で共有


Azure Front Door の Azure Web アプリケーション ファイアウォールを調整する

Microsoft が管理する既定のルール セットは、OWASP コア ルール セットに基づいており、Microsoft Threat Intelligence 収集規則が含まれています。

多くの場合、Web アプリケーション ファイアウォール (WAF) を使用するアプリケーションまたは組織の具体的なニーズに合わせて、WAF 規則を調整することが必要になると思われます。 通常、組織では次のいずれかのアクションを行って調整を行います。

  • ルールの除外を定義する。
  • カスタム ルールを作成する。
  • 問題や誤検出を引き起こしている可能性があるルールを無効にする。

この記事では、WAF を通過する必要がある要求がブロックされた場合にできることを説明します。

注意

Microsoft が管理するルール セットは、Azure Front Door Standard SKU では利用できません。 さまざまなレベルの SKU の詳細については、「レベル間の機能の比較」を参照してください。

Azure Front Door WAF の概要Azure Front Door 用の WAF ポリシーに関するドキュメントを必ず読んでください。 また、Azure WAF の監視とログを有効にしてください。 これらの記事では、WAF がどのように機能するか、WAF 規則セットの仕組み、および WAF ログへのアクセス方法について説明されています。

WAF ログについて

WAF ログの目的は、WAF で一致したかブロックされたすべての要求を示すことです。 これは、一致したかブロックされたすべての評価済み要求のコレクションです。 ブロックしてはならない要求を WAF がブロックしていること (誤検出) に気づいた場合は、いくつかのことを実行できます。

まず、絞り込みを行って、特定の要求を見つけます。 イベントを簡単に識別し、その特定の値についてログのクエリを実行できるように、trackingReference フィールドを含むカスタム応答メッセージを構成することができます。 ログを調べて、要求の特定の URI、タイムスタンプ、またはクライアント IP を見つけます。 関連するログ エントリが見つかったら、誤検出に対処することができます。

たとえば、WAF を通過させたい正当なトラフィックに 1=1 という文字列が含まれているとします。 要求は次のようになります。

POST http://afdwafdemosite.azurefd.net/api/Feedbacks HTTP/1.1
Host: afdwafdemosite.azurefd.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

UserId=20&captchaId=7&captchaId=15&comment="1=1"&rating=3

要求を試すと、 WAF はパラメーターまたはフィールドに 1=1 という文字列を含むトラフィックをブロックします。 これは SQL インジェクション攻撃によく関係している文字列です。 ログを調べて、要求のタイムスタンプと、ブロックまたは一致したルールを確認できます。

次の例は、一致したルールに基づいて生成されたログ エントリを示しています。 次の Log Analytics クエリを使うと、過去 24 時間以内にブロックされた要求を見つけることができます。

AzureDiagnostics
| where Category == 'FrontDoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'
AzureDiagnostics
| where Category == 'FrontdoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

requestUri フィールドでは、要求が /api/Feedbacks/ に対して明示的に行われたことがわかります。 さらに、ruleName フィールドでルール ID 942110 を見つけます。 ルール ID がわかると、OWASP ModSecurity Core Rule Set の公式リポジトリにアクセスし、そのルール ID を検索して、そのコードを確認し、このルールが何と一致しているかを正確に把握することができます。

その後、action フィールドをチェックすると、このルールに一致したら要求をブロックするように設定されていることがわかります。 要求は、policyModeprevention に設定されているので、WAF によってブロックされたことが確認できます。

ここで、details フィールドの情報を確認してみます。 このフィールドでは、matchVariableNamematchVariableValue の情報を確認できます。 このルールがトリガーされたのは、誰かが Web アプリの comment フィールドに 1=1 を入力したためです。

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}
{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

また、アクセス ログを調べると、特定の WAF イベントに関する知識を広げることもできます。 次に、前のイベントへの応答として生成されたログを確認します。

これらのログは trackingReference の値が同じであるので関連していることがわかります。 userAgentclientIP などの一般的な分析情報が提供されるさまざまなフィールドの中で、httpStatusCode フィールドと httpStatusDetails フィールドに注目します。 ここでは、クライアントが HTTP 403 応答を受信したことを確認できます。これは、この要求が拒否されてブロックされたことを示しています。

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorAccessLog",
    "operationName": "Microsoft.Cdn/Profiles/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}
{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorAccessLog",
    "operationName": "Microsoft.Network/FrontDoor/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

誤検出の解決

誤検出の扱いについて十分な情報を得た上で意思決定を行うには、お使いのアプリケーションで使用されるテクノロジに習熟することが重要です。 たとえば、テクノロジ スタックに SQL サーバーがなく、それらの規則に関連する誤検出が発生しているとします。 それらの規則を無効にしても、セキュリティが低下するとは限りません。

この情報と、この例ではルール 942110 は 1=1 という文字列と一致したものであるという情報に基づいて、この正当な要求がブロックされないように、いくつかのことを行うことができます。

ヒント

WAF を使用して正当な要求を許可する方法を選択する際は、これを可能な限り狭くするようにしてください。 たとえば、ルールを完全に無効にするのではなく、除外リストを使用することをお勧めします。

除外リストを使用します

除外リストを使用する利点の 1 つは、除外対象として選択した一致変数のみが、特定の要求で検査されなくなることです。 つまり、要求全体を検査から除外するのではなく、特定の条件が満たされた場合に除外する特定の要求ヘッダー、要求 Cookie、クエリ文字列引数、または要求本文の POST 引数を選択することができます。 要求のその他の指定されていない変数は、通常どおり検査されます。

除外はグローバル設定です。 構成されている除外は、特定の Web アプリや URI だけでなく、WAF を通過するすべてのトラフィックに適用されます。 たとえば、1=1 が特定の Web アプリの本文では有効な要求であっても、同じ WAF ポリシーで他のアプリに対しては無効である場合、これが問題になる可能性があります。

異なるアプリケーションに異なる除外リストを使用することに合理的な理由がある場合は、アプリケーションごとに異なる WAF ポリシーを使用し、各アプリケーションのフロントエンドにそれを適用することを検討してください。

マネージド ルールの除外リストを構成する場合、次の項目を除外できます。

  • ルール セット内のすべてのルール。
  • ルール グループ内のリボン グループリボン グループすべてのルール。
  • 個々のユーザー。

除外リストは、Azure PowerShellAzure CLIREST API、Bicep、Azure Resource Manager テンプレート、Azure portal を使って構成できます。

  • ルール レベルでの除外: ルール レベルで除外を適用すると、指定した除外が適用される個々のルールのみが分析されません。 ルール セット内のそれ以外のルールでは引き続き分析が行われます。 これは最も細かいレベルの除外です。 WAF ログにある情報に基づいて管理されるルール セットを微調整し、イベントのトラブルシューティングを行う場合に使用できます。
  • ルール グループ レベルでの除外: ルール グループ レベルで除外を適用すると、指定した除外が適用される特定のルールの種類のグループが分析されません。 たとえば、除外されるルール グループとして SQLI を選択すると、定義されている除外対象の要求はどの SQLI 固有ルールでも検査されません。 ただし、PHPRFIXSS など、他のグループのルールでは検査されます。 この種類の除外は、アプリケーションが特定の種類の攻撃の影響を受けないことが確実である場合に役立ちます。 たとえば、SQL データベースを持たないアプリケーションの場合、すべての SQLI ルールを除外しても、セキュリティ レベルに悪影響を与えることはありません。
  • ルール セット レベルでの除外: ルール セット レベルで除外を適用すると、指定した除外が適用されるルール セットで利用できるすべてのセキュリティ ルールが分析されません。 この除外は広範囲に及ぶので、慎重に使用してください。

この例では、除外を 1 つのルールに適用することで、最も細かいレベルで除外を行います。 comment を含む一致変数 Request body post args name を除外します。 一致変数の詳細は、ファイアウォール ログの "matchVariableName": "PostParamValue:comment" で確認できます。 属性は comment です。 この属性名は、他のいくつかの方法で見つけることもできます。 詳細については、「要求の属性名の検索」をご覧ください。

除外ルールを示すスクリーンショット。

特定ルールの除外を示すスクリーンショット。

直感的ではないような方法で、特定のパラメーターが WAF に渡される場合があります。 たとえば、Microsoft Entra ID を使って認証を行うと、トークンが渡されます。 通常、このトークン __RequestVerificationToken は要求 Cookie として渡されます。

Cookie が無効になっている場合は、このトークンも要求の POST 引数として渡されます。 このため、Microsoft Entra トークンの擬陽性に対処するには、RequestCookieNamesRequestBodyPostArgsNames の両方の除外リストに __RequestVerificationToken を確実に追加する必要があります。

フィールド名 ("セレクター") での除外は、WAF によってその値が評価されなくなることを意味します。 フィールド名自体は引き続き評価され、まれに WAF のルールと一致して、アクションがトリガーされる可能性があります。

ルール セットに対するルール除外を示すスクリーンショット。

WAF のアクションを変更します

WAF 規則の動作を制御するもう 1 つの方法は、要求がルールの条件に一致したときに実行されるアクションを選択することです。 使用できるアクションは許可、ブロック、ログ、リダイレクトです。

この例では、ルール 942110 で既定のアクション "ブロック" を "ログ" アクションに変更しました。 このアクションを選ぶと、WAF で要求がログに記録され、同じ要求が残りの優先順位の低いルールに対して引き続き評価されます。

WAF のアクションを示すスクリーンショット。

同じ要求を実行したら、ログを参照することで、この要求がルールID 942110 に一致したことを確認できます。 action_s フィールドには "ブロック" ではなく "ログ" が表示されるようになります。 次に、ログ クエリを拡張して trackingReference_s の情報が含まれるようにして、この要求でほかに何が起きたのかを確認します。

複数のルールの一致を示すログのスクリーンショット。

ルール ID 942110 が処理された数ミリ秒後に、別の SQLI ルールの一致が発生したことがわかります。 同じ要求がルール ID 942310 と一致し、今回は既定のアクションである "ブロック" がトリガーされました。

WAF の調整またはトラブルシューティングの間に "ログ" アクションを使用するもう 1 つの利点は、特定のルール グループ内の複数のルールが特定の要求と照合してブロックしているかどうかを特定できることです。 その後、適切なレベル (ルール レベルまたはルール グループ レベル) で除外を作成できます。

カスタム ルールを使用します

WAF のルールに一致する原因になっているものが明らかになったら、カスタム ルールを使用して、WAF がイベントに反応する方法を調整できます。 カスタム ルールは、マネージド ルールの前に処理されます。 カスタム ルールには、複数の条件を含むことができます。また、アクションとしては、許可、拒否、ログ、またはリダイレクトを使用できます。

警告

要求がカスタム ルールと一致すると、WAF エンジンは要求の処理を停止します。 この要求に対してマネージド ルールは処理されません。また、優先度が低い他のカスタム ルールも処理されません。

次の例は、2 つの条件を持つカスタム ルールを示しています。 1 つ目の条件では、要求本文で comment という値が検索されます。 2 つ目の条件では、要求 URI で /api/Feedbacks/ という値が検索されます。

カスタム ルールを使用すると最も細かく設定できるので、WAF 規則を微調整し、誤検知に対処することができます。 このケースでは、要求本文の値 comment だけに基づいてアクションを実行することはしません。同じ WAF ポリシーで複数のサイトまたはアプリに同じ値が存在する可能性があります。

特定の要求 URI /api/Feedbacks/ にも一致する別の条件を入れることで、このカスタム ルールが、入念に考えられたこのユース ケースに実際に適用されるようにします。これにより、同じ攻撃が異なる条件に対して実行された場合でも、WAF エンジンによって検査され、防止されます。

ログを示すスクリーンショット。

ログを調べると、ruleName_s フィールドに、カスタム ルールに指定した名前 redirectcomment が含まれていることがわかります。 action_s フィールドでは、このイベントに対して "action_s" アクションが実行されたことがわかります。 details_matches_s フィールドを見ると、両方の条件が一致した場合の詳細を確認できます。

ルールの無効化

誤検出を回避する別の方法は、WAF が悪意ありと判断した入力に一致したルールを無効にすることです。 WAF ログを解析してルールを 942110 に絞り込んだので、Azure portal で無効できます。 詳細については、「Azure portal を使用した Web アプリケーション ファイアウォール規則のカスタマイズ」を参照してください。

ルールを無効にすることは、その特定の条件を満たすすべての要求が実際に正当な要求であることが確実である場合、または単にそのルールが環境に適用されないことが確実である場合 (たとえば、SQL のバックエンドがないため SQL インジェクション ルールを無効にする場合) に役立ちます。

ルールを無効にすることはグローバルな設定で、WAF ポリシーに関連付けられているすべてのフロントエンド ホストに適用されます。 ルールを無効にすると、WAF ポリシーに関連付けられている他のフロントエンド ホストに対し、保護や検出が行われずに脆弱性がさらされたままになるおそれがあります。

Azure PowerShell を使用してマネージド ルールを無効にする場合は、PSAzureManagedRuleOverride オブジェクトのドキュメントを参照してください。 Azure CLI を使用する場合は、az network front-door waf-policy managed-rules override のドキュメントを参照してください。

WAF 規則を示すスクリーンショット。

ヒント

WAF ポリシーに対して行ったすべての変更を記録してください。 誤検知の検出を示す要求の例も入れます。 カスタム ルールを追加した理由や、ルールまたはルール セットを無効にした理由、例外を追加した理由について説明します。 将来にアプリケーションを再設計する場合、変更がまだ有効であることを確認する必要があることがあります。 また、監査を行う場合や、WAF ポリシーを既定の設定から再構成した理由を確認する必要がある場合もあります。

要求フィールドの検索

Fiddler のようなブラウザー プロキシを使用して個々の要求を検査し、Web ページのどの特定のフィールドが呼び出されているかを判別することができます。 これは、WAF の除外リストを使用して検査から特定のフィールドを除外する必要があるときに役立ちます。

要求の属性名の検索

この例では、文字列 1=1 が入力されたフィールドは comment と呼ばれています。 このデータは、POST 要求の本文で渡されました。

Fiddler の要求の本文を示すスクリーンショット。

このフィールドは除外できます。 除外リストの詳細については、Web アプリケーション ファイアウォールの除外リストに関するページを参照してください。 この場合、次の除外を構成することで、評価を除外することができます。

除外ルールを示すスクリーンショット。

ファイアウォールのログを調べて、除外リストに追加する必要があるものを確認するための情報を取得することもできます。 ログの有効化については、Azure Front Door でのメトリックとログの監視に関するページを参照してください。

PT1H.json ファイルのファイアウォール ログで、検査対象の要求が発生した日時を調べます。 PT1H.json ファイルは、FrontDoorWebApplicationFirewallLog および FrontDoorAccessLog 診断ログが保存されているストレージ アカウントのコンテナーで使用できます。

PT1H.json ファイルのファイアウォール ログで、検査対象の要求が発生した日時を調べます。 PT1H.json ファイルは、FrontdoorWebApplicationFirewallLog および FrontdoorAccessLog 診断ログが保存されているストレージ アカウントのコンテナーで使用できます。

この例では、ルールによって (同じトランザクション参照の) 要求がブロックされ、それが同じ時刻に発生したことを確認できます。

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}
{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Azure によって管理されるルール セットがどのように機能するかについての知識があれば、action: Block プロパティが含まれるルールは、要求の本文で一致したデータに基づいてブロックしていることがわかります。 (詳細については、「Azure Front Door 上の Azure Web アプリケーション ファイアウォール」を参照してください)。パターン (1=1) と一致し、フィールドの名前が comment であることを詳細情報で確認できます。 前と同じ手順に従って、comment が含まれる RequestBodyPostArgNames を除外します。

要求のヘッダー名の検索

Fiddler は、要求ヘッダー名を検索する場合に便利なツールです。 次のスクリーンショットはこの GET 要求のヘッダーを示しており、Content-TypeUser-Agent が含まれています。 要求ヘッダーを使用して、WAF で除外やカスタム ルールを作成することもできます。

Fiddler の要求のヘッダーを示すスクリーンショット。

要求ヘッダーと応答ヘッダーを表示する別の方法は、Microsoft Edge や Chrome などのブラウザーの開発者ツール内で調べることです。 F12 キーを押すか、右クリックで調査>開発者ツールを開きます。 [ネットワーク] タブを選択します。Web ページを読み込み、検査する要求を選択します。

ネットワーク インスペクターの要求を示すスクリーンショット。

要求に Cookie が含まれている場合、[Cookie] タブを選択して Fiddler で表示します。 Cookie の情報は、WAF で除外やカスタム ルールを作成する場合にも使用できます。

異常スコアリング ルール

WAF を調整するプロセスでルール ID 949110 が表示された場合、異常スコアリングプロセスによって要求がブロックされたことを示します。

追跡参照が同じログ エントリを検索して、同じ要求に対する他の WAF ログ エントリを確認します。 トリガーされた各ルールを確認します。 この記事のガイダンスに従って、各ルールを調整します。

警告

新しいマネージド ルールセットを WAF ポリシーに割り当てると、ルールの状態、ルール アクション、ルール レベルの除外など、既存のマネージド ルールセットから以前に行ったすべてのカスタマイズが、新しいマネージド ルールセットの既定値に再設定されます。 ただし、カスタム ルールとポリシー設定は、新しいルールセットの割り当て中に影響を受けないまま維持されます。

次のステップ