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

[アーティクル]
08/02/2023

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 フィールドをチェックすると、このルールに一致したら要求をブロックするように設定されていることがわかります。要求は、policyMode が prevention に設定されているので、WAF によってブロックされたことが確認できます。

ここで、details フィールドの情報を確認してみます。このフィールドでは、matchVariableName と matchVariableValue の情報を確認できます。このルールがトリガーされたのは、誰かが 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 の値が同じであるので関連していることがわかります。 userAgent や clientIP などの一般的な分析情報が提供されるさまざまなフィールドの中で、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 という文字列と一致したものであるという情報に基づいて、この正当な要求がブロックされないように、いくつかのことを行うことができます。

除外リストを使用します。 除外リストの詳細については、「Front Door の除外リストを使用する Web Application Firewall (WAF)」を参照してください。
WAF のアクションを変更します。 要求がルールの条件に一致した場合に実行できるアクションの詳細については、「WAF のアクション」を参照してください。
カスタムルールを使用します。 カスタムルールの詳細については、「Azure Front Door での Web アプリケーションファイアウォールのカスタム規則」を参照してください。
ルールを無効化します。

ヒント

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

除外リストを使用します

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

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

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

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

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

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

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

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

Screenshot that shows exclusion rules.

Screenshot that shows rule exclusion for a specific rule.

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

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

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

Screenshot that shows rule exclusion for a rule set.

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

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

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

Screenshot that shows WAF actions.

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

Screenshot that shows a log showing multiple rule matches.

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

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

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

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

警告

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

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

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

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

Screenshot that shows a log.

ログを調べると、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 のドキュメントを参照してください。

Screenshot that shows WAF rules.

ヒント

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

要求フィールドの検索

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

要求の属性名の検索

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

Screenshot that shows the body of a Fiddler request.

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

Screenshot that shows an exclusion rule.

ファイアウォールのログを調べて、除外リストに追加する必要があるものを確認するための情報を取得することもできます。ログの有効化については、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-Type と User-Agent が含まれています。要求ヘッダーを使用して、WAF で除外やカスタムルールを作成することもできます。

Screenshot that shows the header of a Fiddler request.

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

Screenshot that shows a Network inspector request.

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

異常スコアリングルール

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

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

次のステップ

Azure Web アプリケーションファイアウォールについて学習します。
Azure Front Door のインスタンスを作成する方法について学習します。

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