Настраиваемые правила брандмауэра веб-приложения версии 2 для шлюза приложений Azure

Шлюз приложений Azure Брандмауэр веб-приложений (WAF) версии 2 поставляется с предварительно настроенным набором правил, управляемым платформой, который обеспечивает защиту от различных типов атак. В число таких атак входят межсайтовые сценарии, внедрение кода SQL и другие. Если вы являетесь администратором WAF, вам может потребоваться написать собственные правила, чтобы расширить правила набора основных правил (CRS). Пользовательские правила могут блокировать, разрешать или регистрировать запрошенный трафик на основе критериев соответствия. Если политика WAF настроена в режиме обнаружения, а настраиваемое правило блока активируется, запрос регистрируется и не выполняется действие блокировки.

Настраиваемые правила позволяют вам создавать собственные правила, которые оцениваются для каждого запроса, передаваемого через WAF. Эти правила имеют более высокий приоритет, чем любые правила из управляемых наборов правил. Пользовательские правила содержат имя правила, приоритет правила и массив условий сопоставления. Если эти условия выполнены, выполняется действие (для разрешения, блокировки или журнала). Если настраиваемое правило активируется и выполняется действие "Разрешить" или "Блокировать", то не вычисляются дополнительные пользовательские или управляемые правила. Пользовательские правила можно включить или отключить по запросу.

Например, можно заблокировать все запросы с IP-адреса в диапазоне 192.168.5.0/24. В этом правиле оператором является IPMatch, matchValues — это диапазон IP-адресов (192.168.5.0/24), а действие — блокировка трафика. Вы также задаете имя правила, приоритет и отключенное состояние.

Настраиваемые правила поддерживают использование логики объединения для создания более сложных правил, удовлетворяющих ваши потребности в безопасности. Например, можно использовать два настраиваемых правила для создания следующей логики ((rule1:Condition 1 и rule1:Condition 2) или rule2:Condition 3. Эта логика означает, что если условие 1 и условие 2 выполнены или если условие 3 выполнено, WAF должен выполнить действие, указанное в пользовательских правилах.

Разные условия сопоставления в рамках одного и того же правила всегда объединяются с помощью оператора и, например, можно заблокировать трафик с определенного IP-адреса и только в том случае, если используется определенный браузер.

Если вы хотите использовать оператор или между двумя разными условиями, два условия должны быть в разных правилах. Например, можно блокировать трафик с определенного IP-адреса или блокировать трафик, если используется определенный браузер.

Регулярные выражения поддерживаются в пользовательских правилах, так же как в основных наборах правил. Примеры см. в примерах 3 и 5 в статье Создание и использование настраиваемых правил брандмауэра веб-приложения.

Примечание.

Максимальное количество настраиваемых правил WAF — 100. Дополнительные сведения об ограничениях шлюза Azure см. в статье Лимиты, квоты и ограничения подписки и служб Azure.

Внимание

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

Разрешение и блокировка

Настраиваемые правила позволяют легко разрешать и блокировать трафик. Например, можно заблокировать весь трафик из диапазона IP-адресов. Вы можете создать еще одно правило, разрешающее трафик, если запрос поступает из определенного браузера.

Чтобы что-либо разрешить, укажите для параметра -Action значение Allow (Разрешить). Чтобы что-либо заблокировать, укажите для параметра -Action значение Block (Заблокировать).

$AllowRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example1 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Allow `
   -State Enabled

$BlockRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example2 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Block `
   -State Enabled

Приведенное выше правило $BlockRule сопоставляется со следующим пользовательским правилом в Azure Resource Manager:

"customRules": [
      {
        "name": "blockEvilBot",
        "priority": 2,
        "ruleType": "MatchRule",
        "action": "Block",
        "state": "Enabled",
        "matchConditions": [
          {
            "matchVariables": [
              {
                "variableName": "RequestHeaders",
                "selector": "User-Agent"
              }
            ],
            "operator": "Contains",
            "negationCondition": false,
            "matchValues": [
              "evilbot"
            ],
            "transforms": [
              "Lowercase"
            ]
          }
        ]
      }
    ], 

Это пользовательское правило содержит имя, приоритет, действие и массив условий сопоставления, которые должны быть выполнены для выполнения действия. Более подробное описание этих полей см. ниже. Примеры настраиваемых правил см. в статье Создание и использование настраиваемых правил брандмауэра веб-приложения.

Поля для настраиваемых правил

Имя [необязательно]

Имя правила. Отображается в журналах.

Включение правила [необязательно]

Включите или отключите это правило. Пользовательские правила включены по умолчанию.

Приоритет [обязательно]

• Определяет порядок оценки правил. Чем меньше значение, тем раньше будет проводиться оценка правила. Допустимый диапазон — от 1 до 100.
• Должно быть уникальным для всех настраиваемых правил. Правило с приоритетом 40 оценивается раньше правила с приоритетом 80.

Тип правила [обязательно]

В настоящее время нужно использовать тип MatchRule.

Переменная сопоставления [обязательно]

Должна быть одной из следующих переменных:

• RemoteAddr — IPv4-адрес или диапазон подключения к удаленному компьютеру
• RequestMethod — метод HTTP-запроса
• QueryString — переменная в URI
• PostArgs — аргументы, отправляемые в теле запроса POST. Пользовательские правила, использующие эту переменную соответствия, применяются только в том случае, если заголовок Content-Type имеет значение application/x-www-form-urlencoded и multipart/form-data. Дополнительный тип контента application/json поддерживается в CRS версии 3.2 или более поздней версии, наборе правил защиты бота и пользовательских правилах геосопоставления.
• RequestUri — URI запроса
• RequestHeaders — заголовки запроса
• RequestBody — эта переменная содержит весь текст запроса в целом. Пользовательские правила с использованием этой переменной сопоставления применяются только в том случае, если для заголовка Content-Type задан тип мультимедиа application/x-www-form-urlencoded. Дополнительные типы контента application/soap+xml, application/xml, text/xml поддерживаются в CRS версии 3.2 или более поздней версии, наборе правил защиты бота и пользовательских правилах геосопоставления.
• RequestCookies — файлы Cookie запроса

Селектор [необязательно]

Описывает поле коллекции matchVariable. Например, если matchVariable имеет значение RequestHeaders, то селектор может находиться в заголовке User-Agent.

Оператор [обязательно]

Необходимо использовать один из следующих операторов:

• IPMatch — используется только при использовании переменной match RemoteAddr и поддерживает только IPv4
• Equal — входные данные совпадают с переменной MatchValue
• Любой — он не должен иметь MatchValue. Рекомендуется использовать переменную match с допустимым селектором.
• Содержит
• LessThan;
• GreaterThan
• LessThanOrEqual;
• GreaterThanOrEqual
• BeginsWith
• EndsWith
• Регулярное выражение
• Geomatch

Условие с отрицанием [необязательно]

Отрицает текущее условие.

Преобразование [необязательно]

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

• Нижний регистр
• Верхний регистр
• Trim
• UrlDecode
• UrlEncode
• RemoveNulls
• HtmlEntityDecode

Значения для сопоставления [обязательно]

Список значений для сопоставления, которые действуют так, как если бы использовался оператор или. Например, это могут быть IP-адреса или другие строки. Формат значения зависит от предыдущего оператора.

Поддерживаемые значения метода HTTP-запроса включают:

• GET
• HEAD
• POST
• ПАРАМЕТРЫ
• PUT
• DELETE
• PATCH

Действие [обязательно]

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

• Allow — разрешает транзакцию, пропуская все остальные правила. Указанный запрос добавляется в список разрешений и после сопоставления запрос останавливает дальнейшую оценку и отправляется в внутренний пул. Правила, которые находятся в списке разрешений, не оцениваются для дополнительных пользовательских правил или управляемых правил.
• Блокировать — блокирует или регистрирует транзакцию на основе SecDefaultAction (режим обнаружения и предотвращения).
  • Режим предотвращения — блокирует транзакцию на основе SecDefaultAction. Allow Как и действие, после оценки запроса и добавления в список блокировок оценка останавливается и запрос блокируется. Любой запрос после этого соответствует тем же условиям не оценивается и блокируется.
  • Режим обнаружения — регистрирует транзакцию на основе SecDefaultAction после остановки оценки. Любой запрос после этого соответствует тем же условиям не оценивается и только регистрируется.
• Log — позволяет правилу записываться в журнал, но не препятствует оценке остальных правил. Другие настраиваемые правила оцениваются в порядке их приоритета, после чего оцениваются управляемые правила.

Копирование и дублирование пользовательских правил

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

Географическое согласование настраиваемых правил

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

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

• Создание собственных пользовательских правил
• Дополнительные сведения о безопасности сети Azure