Бөлісу құралы:

Настройка Azure Брандмауэр веб-приложений для Azure Front Door

  • Мақала

Набор правил по умолчанию, управляемый корпорацией Майкрософт, основан на наборе основных правил OWASP и включает правила сбора microsoft Threat Intelligence.

Часто предполагается, что правила брандмауэра веб-приложений (WAF) должны быть настроены в соответствии с конкретными потребностями приложения или организации, использующим WAF. Организации обычно выполняют настройку, выполнив одно из следующих действий:

  • Определение исключений правил.
  • Создание настраиваемых правил.
  • Отключение правил, которые могут вызывать проблемы или ложные срабатывания.

В этой статье описывается, что можно сделать, если запросы, которые должны передаваться через WAF, блокируются.

Примечание.

Набор правил, управляемых Корпорацией Майкрософт, недоступен для SKU Azure Front Door уровня "Стандартный". Дополнительные сведения о разных номерах SKU уровня см. в разделе "Сравнение компонентов между уровнями".

Ознакомьтесь с обзором WAF Azure Front Door и политикой WAF для документов Azure Front Door. Кроме того, включите мониторинг и ведение журнала WAF. В этих статьях объясняется, как работают функции WAF, как работают наборы правил WAF и как получить доступ к журналам WAF.

Общие сведения о журналах WAF

Целью журналов WAF является отображение каждого запроса, соответствующего или заблокированного WAF. Это коллекция всех вычисляемых запросов, которые соответствуют или блокируются. Если вы заметили, что WAF блокирует запрос, который не должен (ложноположительный результат), можно выполнить несколько действий.

Сначала сузите и найдите конкретный запрос. Можно настроить настраиваемое сообщение ответа, чтобы включить trackingReference поле, чтобы легко определить событие и выполнить запрос журнала по конкретному значению. Просмотрите журналы, чтобы найти конкретный универсальный код ресурса (URI), метку времени или IP-адрес клиента для запроса. При поиске связанных записей журнала можно действовать на ложных срабатываниях.

Например, предположим, что у вас есть допустимый трафик, содержащий строку 1=1 , которую вы хотите передать через WAF. Вот как выглядит соответствующий запрос.

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. Вы можете просмотреть журналы и просмотреть метку времени запроса и правила, которые блокировали или соответствовали.

В следующем примере показана запись журнала, созданная на основе соответствия правил. Чтобы найти заблокированные запросы за последние 24 часа, можно использовать следующий запрос Log Analytics.

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/. Далее найдите идентификатор 942110 правила в ruleName поле. Зная идентификатор правила, вы можете перейти в официальный репозиторий набора правил OWASP ModSecurity Core и выполнить поиск по этому идентификатору правила, чтобы проверить код и понять, на что соответствует это правило.

Затем, проверив action поле, вы увидите, что для этого правила задано блокировка запросов при сопоставлении. Вы можете убедиться, что запрос был заблокирован WAF, так как policyMode задано значение prevention.

Теперь проверьте сведения в details поле. Это поле, где можно просмотреть matchVariableName и matchVariableValue информацию. Это правило было активировано, так как кто-то вводимый в 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 Server, и вы получаете ложноположительные результаты, связанные с этими правилами. Отключение этих правил не обязательно приведет к ослаблению безопасности.

С этой информацией и знаниями, которые правило 942110 соответствует 1=1 строке в примере, можно сделать несколько действий, чтобы остановить этот законный запрос от блокировки:

  • Используйте списки исключений. Дополнительные сведения о списках исключений см. в Брандмауэр веб-приложений Azure с списками исключений Azure Front Door.
  • Изменение действий WAF. Дополнительные сведения о действиях, которые можно предпринять, когда запрос соответствует условиям правила, см. в статье WAF Actions.
  • Используйте пользовательские правила. Дополнительные сведения о настраиваемых правилах см. в разделе "Пользовательские правила" для Azure Брандмауэр веб-приложений с помощью Azure Front Door.
  • Отключите правила.

Совет

При выборе подхода, позволяющего разрешить законные запросы через WAF, попробуйте сделать его таким узким, как можно. Например, лучше использовать список исключений, чем полностью отключить правило.

Использование списков исключений

Одним из преимуществ использования списка исключений является то, что только выбранная для исключения переменная сопоставления больше не будет проверяться для заданного запроса. То есть можно выбрать конкретные заголовки запроса, файлы cookie запроса, аргументы строки запроса или аргументы записи текста запроса, которые будут исключены при выполнении определенного условия, а не исключить проверку всего запроса. Другие неопределенные переменные запроса проверяются обычно.

Исключения — это глобальный параметр. Настроенное исключение применяется ко всему трафику, который проходит через WAF, а не только к определенному веб-приложению или URI. Например, это может быть проблемой, если 1=1 это действительный запрос в тексте для определенного веб-приложения, но не для других пользователей в той же политике WAF.

Если имеет смысл использовать разные списки исключений для разных приложений, рассмотрите возможность использования различных политик WAF для каждого приложения и их применения к интерфейсному интерфейсу каждого приложения.

При настройке списков исключений для управляемых правил можно исключить следующее:

  • Все правила в наборе правил.
  • Все правила в группе правил.
  • Отдельное правило.

Список исключений можно настроить с помощью PowerShell, Azure CLI, REST API, Bicep, шаблонов Azure Resource Manager или портал Azure.

  • Исключения на уровне правила: применение исключений на уровне правила означает, что указанные исключения не будут анализироваться только в соответствии с этим отдельным правилом. Он по-прежнему будет анализироваться всеми другими правилами в наборе правил. Это самый детализированный уровень исключений. Его можно использовать для точной настройки управляемого набора правил на основе сведений, которые вы найдете в журналах WAF при устранении неполадок с событием.
  • Исключения на уровне группы правил: применение исключений на уровне группы правил означает, что указанные исключения не будут анализироваться в отношении этого определенного набора типов правил. Например, выбор SQLI в качестве исключенной группы правил указывает, что определенные исключения запросов не будут проверяться ни одной из правил, относящихся к SQLI. Он по-прежнему будет проверяться правилами в других группах, таких как PHP, RFI или XSS. Этот тип исключения может быть полезен, если вы уверены, что приложение не подвержено определенным типам атак. Например, приложение, у которого нет баз данных SQL, может исключить все правила SQLI без ущерба для уровня безопасности.
  • Исключения на уровне набора правил. Применение исключений на уровне набора правил означает, что указанные исключения не будут анализироваться ни в одном из правил безопасности, доступных в этом наборе правил. Это исключение является всеобъемлющим, поэтому используйте его тщательно.

В этом примере вы выполняете исключение на самом детальном уровне, применяя исключение к одному правилу. Вы хотите исключить имя объекта запроса соответствия в тексте запроса, содержащее commentимя args. Сведения об переменной соответствия можно просмотреть в журнале брандмауэра: "matchVariableName": "PostParamValue:comment" Атрибут имеет значение comment. Вы также можете найти это имя атрибута несколькими другими способами. Дополнительные сведения см. в разделе "Поиск имен атрибутов запроса".

Снимок экрана: правила исключения.

Снимок экрана: исключение правила для определенного правила.

Иногда существуют случаи, когда определенные параметры передаются в WAF способом, который не может быть интуитивно понятным. Например, маркер передается при проверке подлинности с помощью идентификатора Microsoft Entra. Маркер __RequestVerificationToken обычно передается в виде файла cookie запроса.

В некоторых случаях, когда файлы cookie отключены, этот маркер также передается в качестве аргумента записи запроса. По этой причине для устранения ложных срабатываний маркера Microsoft Entra необходимо убедиться, что __RequestVerificationToken он добавляется в список исключений для обоих RequestCookieNames и RequestBodyPostArgsNames.

Исключения в имени поля (селектор) означает, что значение больше не будет оцениваться WAF. Имя поля продолжает оцениваться и в редких случаях может соответствовать правилу WAF и активировать действие.

Снимок экрана: исключение правил для набора правил.

Изменение действий WAF

Другим способом обработки поведения правил WAF является выбор действия, которое он принимает, когда запрос соответствует условиям правила. Доступные действия: "Разрешить", "Блокировать", "Журнал" и "Перенаправление".

В этом примере блок действия по умолчанию изменился на действие журнала в правиле 942110. Это действие приводит к тому, что WAF регистрирует запрос и продолжает оценивать тот же запрос по оставшимся правилам с низким приоритетом.

Снимок экрана: действия WAF.

После выполнения того же запроса можно вернуться к журналам и увидеть, что этот запрос совпадает с идентификатором правила 942110. Теперь action_s поле указывает журнал вместо блока. Затем запрос журнала был развернут, чтобы включить trackingReference_s сведения, чтобы увидеть, что еще произошло с этим запросом.

Снимок экрана: журнал, показывающий несколько совпадений правил.

Теперь можно увидеть другое соответствие правил SQLI, которое происходит в миллисекундах после обработки идентификатора правила 942110. Этот же запрос соответствует правилу с идентификатором 942310, и на этот раз было активировано действие по умолчанию Блокировать.

Еще одно преимущество использования действия Журнал во время настройки или устранения неполадок в WAF заключается в том, что можно выяснить, соответствует ли блокируемый запрос нескольким правилам в определенной группе. Затем можно создать исключения на соответствующем уровне, то есть на уровне правила или группы правил.

Использование настраиваемых правил

После определения того, что вызывает совпадение правил WAF, можно использовать настраиваемые правила для настройки реагирования WAF на событие. Пользовательские правила обрабатываются перед управляемыми правилами. Они могут содержать несколько условий, а их действия могут быть разрешены, запрещены, журналы или перенаправления.

Предупреждение

Когда запрос соответствует пользовательскому правилу, подсистема WAF перестает обрабатывать запрос. Управляемые правила не будут обрабатываться для этого запроса, и ни другие пользовательские правила с более низким приоритетом.

В следующем примере показано пользовательское правило с двумя условиями. Первое условие ищет comment значение в тексте запроса. Второе условие ищет /api/Feedbacks/ значение в URI запроса.

Используя настраиваемое правило, вы можете быть наиболее детализированной, чтобы можно было точно настроить правила WAF и справиться с ложными срабатываниями. В этом случае вы не выполняете действия только на comment основе значения текста запроса, которое может существовать на нескольких сайтах или приложениях в одной политике WAF.

Если включить другое условие, которое также соответствует определенному URI /api/Feedbacks/запроса, это пользовательское правило действительно применяется к этому явному варианту использования, который вы проверены. Таким образом, одна и та же атака, если она выполняется в разных условиях, по-прежнему проверяется и предотвращается подсистемой WAF.

Снимок экрана: журнал.

При изучении журнала можно увидеть, что ruleName_s поле содержит имя, заданное пользовательскому правилу redirectcomment. В поле action_s можно увидеть, что для этого события было выполнено действие Перенаправить. details_matches_s В поле можно просмотреть сведения об обоих условиях.

Отключение правил

Другой способ обойти ложное срабатывание заключается в том, чтобы отключить правило, которое соответствовало входным данным, который считал WAF вредоносным. Так как вы анализируете журналы WAF и сузили правило до 942110, его можно отключить в портал Azure. Дополнительные сведения см. в статье "Настройка правил Брандмауэр веб-приложений Azure с помощью портал Azure".

Отключение правила является преимуществом, если вы уверены, что все запросы, которые соответствуют конкретному условию, являются законными запросами, или если вы уверены, что правило не применяется к вашей среде (например, отключение правила внедрения SQL, так как у вас есть неисправные серверные части SQL).

Отключение правила — это глобальный параметр, который применяется ко всем внешним узлам, связанным с политикой WAF. Если вы решили отключить правило, вы можете оставить уязвимости, предоставляемые без защиты или обнаружения для других интерфейсных узлов, связанных с политикой WAF.

Если вы хотите использовать Azure PowerShell для отключения управляемого правила, изучите документацию по объекту PSAzureManagedRuleOverride. Если вы хотите использовать Azure CLI, ознакомьтесь az network front-door waf-policy managed-rules override с документацией.

Снимок экрана: правила WAF.

Совет

Задокументируйте все изменения, внесенные в политику WAF. Включите примеры запросов, чтобы проиллюстрировать ложноположительное обнаружение. Объясните, почему вы добавили настраиваемое правило, отключили правило или набор правил или добавили исключение. Если вы перепроектировали приложение в будущем, может потребоваться убедиться, что изменения по-прежнему действительны. Или вы можете быть проверены или должны оправдать, почему вы перенастроили политику WAF из его параметров по умолчанию.

Поиск полей запроса

Используя прокси-сервер браузера, например Fiddler, можно проверить отдельные запросы и определить, какие поля веб-страницы вызываются. Этот метод полезен, если необходимо исключить определенные поля из проверки с помощью списков исключений в WAF.

Поиск имен атрибутов запроса

В этом примере поле, в котором 1=1 была введена строка, вызывается comment. Эти данные были переданы в тексте запроса POST.

Снимок экрана: текст запроса Fiddler.

Это поле можно исключить. Дополнительные сведения о списках исключений см. в списках исключений брандмауэра веб-приложения. Вы можете исключить оценку в этом случае, настроив приведенные ниже исключения.

Снимок экрана: правило исключения.

Вы можете также просмотреть журналы брандмауэра, чтобы понять, что нужно добавить в список исключений. Сведения о включении ведения журнала см. в разделе "Мониторинг метрик и журналов" в 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 Брандмауэр веб-приложений в Azure Front Door.) Вы увидите сведения о том, что оно соответствовало шаблону (1=1) и поле называетсяcomment. Повторите выполненные ранее действия, чтобы исключить имя аргументов записи текста запроса, содержащее comment.

Поиск имен заголовков запросов

Fiddler — это полезное средство для поиска имен заголовков запросов. На следующем снимках экрана показаны заголовки для этого запроса GET, которые включают Content-Type и User-Agent. Вы также можете использовать заголовки запросов для создания исключений и пользовательских правил в WAF.

Снимок экрана: заголовок запроса Fiddler.

Другим способом просмотра заголовков запросов и ответов является поиск в средствах разработчика браузера, таких как Microsoft Edge или Chrome. Вы можете выбрать F12 или щелкните правой кнопкой мыши "Проверить>средства разработчика". Выберите вкладку "Сеть ". Загрузите веб-страницу и выберите запрос, который требуется проверить.

Снимок экрана: запрос инспектора сети.

Если запрос содержит файлы cookie, выберите вкладку "Файлы cookie" , чтобы просмотреть их в Fiddler. Сведения о файлах cookie также можно использовать для создания исключений или пользовательских правил в WAF.

Правило оценки аномалий

Если во время настройки WAF отображается идентификатор правила 949110, его присутствие указывает, что запрос был заблокирован процессом оценки аномалий.

Просмотрите другие записи журнала WAF для того же запроса, выполнив поиск записей журнала с той же ссылкой на отслеживание. Просмотрите все правила, которые были активированы. Настройте каждое правило, следуя инструкциям в этой статье.

Предупреждение

При назначении нового управляемого набора правил политике WAF все предыдущие настройки из существующих управляемых наборов правил, таких как состояние правила, действия правил и исключения уровня правил, будут сброшены на новые значения по умолчанию управляемого набора правил. Однако все пользовательские правила и параметры политики останутся не затронутыми во время назначения нового набора правил.

Следующие шаги