Поделиться через


Настройка брандмауэра веб-приложения (WAF) для 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 информацию. Это правило было активировано, потому что кто-то ввел 1=1 в поле comment веб-приложения.

{
    "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 в примере, можно предпринять несколько шагов, чтобы этот законный запрос не был заблокирован:

Совет

При выборе подхода, позволяющего разрешить законные запросы через 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. Сведения об переменной соответствия можно просмотреть в журнале брандмауэра: "matchVariableName": "PostParamValue:comment" Атрибут имеет значение comment. Вы также можете найти это имя атрибута несколькими другими способами. Дополнительные сведения см. в разделе "Поиск имен атрибутов запроса".

Снимок экрана, который показывает правила исключения.

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

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

В некоторых случаях, когда файлы cookie отключены, этот маркер также передается в качестве аргумента POST-запроса. По этой причине для устранения ложных срабатываний маркера 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 из его параметров по умолчанию.

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

Используя прокси-сервер браузера, например 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. Повторите ранее выполненные действия, чтобы исключить из тела запроса имя аргументов post, которое содержит comment.

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

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

Снимок экрана, показывающий заголовок запроса в Fiddler.

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

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

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

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

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

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

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

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

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