Создание и использование настраиваемых правил брандмауэра веб-приложений Azure (WAF) версии 2 в шлюзе приложений
Брандмауэр веб-приложений Azure (WAF) версии 2 в шлюзе приложений Azure обеспечивает защиту веб-приложений. Для этого используется основной набор правил Open Web Application Security Project (OWASP). В некоторых случаях необходимо создать собственные настраиваемые правила в соответствии с определенными требованиями. Дополнительные сведения о настраиваемых правил WAF см. в статье о Настраиваемых правила брандмауэра веб-приложений.
В этой статье приведены некоторые примеры настраиваемых правил, которые можно создать и использовать с WAF версии 2. Сведения о развертывании WAF с настраиваемыми правилами с помощью Azure PowerShell см. в статье Настройка пользовательских правил брандмауэра веб-приложений с помощью Azure PowerShell.
Фрагменты кода JSON, приведенные в этой статье, являются производными от ресурса ApplicationGatewayWebApplicationFirewallPolicies.
Примечание.
Если шлюз приложений не использует уровень WAF, на правой панели будет предоставлена возможность обновить шлюз приложений до уровня WAF.
Пример 1
Известно, что существует бот с именем evilbot, который необходимо заблокировать, чтобы предотвратить сканирование содержимого веб-сайта. В этом случае вы блокируете злобный бот user-agent в заголовках запроса.
Логика: p
$variable = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector User-Agent
$condition = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable `
-Operator Contains `
-MatchValue "evilbot" `
-Transform Lowercase `
-NegationCondition $False
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name blockEvilBot `
-Priority 2 `
-RuleType MatchRule `
-MatchCondition $condition `
-Action Block `
-State Enabled
Ниже приведен соответствующий код JSON:
{
"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"
]
}
]
}
]
}
WAF, развернутый с помощью этого настраиваемого правила, описан в разделе Настройка пользовательских правил брандмауэра веб-приложений Azure с помощью Azure PowerShell.
Пример 1a
То же самое можно сделать с помощью регулярного выражения:
$variable = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector User-Agent
$condition = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable `
-Operator Regex `
-MatchValue "evilbot" `
-Transform Lowercase `
-NegationCondition $False
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name blockEvilBot `
-Priority 2 `
-RuleType MatchRule `
-MatchCondition $condition `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "blockEvilBot",
"priority": 2,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RequestHeaders",
"selector": "User-Agent"
}
],
"operator": "Regex",
"negationCondition": false,
"matchValues": [
"evilbot"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Пример 2
Вы хотите разрешить трафик только из США с помощью оператора GeoMatch и по-прежнему применять управляемые правила:
$variable = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RemoteAddr `
$condition = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable `
-Operator GeoMatch `
-MatchValue "US" `
-Transform Lowercase `
-NegationCondition $True
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name "allowUS" `
-Priority 2 `
-RuleType MatchRule `
-MatchCondition $condition `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "allowUS",
"priority": 2,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RemoteAddr"
}
],
"operator": "GeoMatch",
"negationCondition": true,
"matchValues": [
"US"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Пример 3
Необходимо заблокировать все запросы с IP-адресов в диапазоне 198.168.5.0/24.
В этом примере вы блокируете весь трафик, поступающий из диапазона IP-адресов. Имя правила — myrule1, а значение приоритета — 10.
Логика: p
$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RemoteAddr
$condition1 = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable1 `
-Operator IPMatch `
-MatchValue "192.168.5.0/24" `
-NegationCondition $False
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name myrule1 `
-Priority 10 `
-RuleType MatchRule `
-MatchCondition $condition1 `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "myrule1",
"priority": 10,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RemoteAddr"
}
],
"operator": "IPMatch",
"negationCondition": false,
"matchValues": [
"192.168.5.0/24"
],
"transforms": []
}
]
}
]
}
Соответствующее правило CRS: SecRule REMOTE_ADDR "@ipMatch 192.168.5.0/24" "id:7001,deny"
Пример 4
В этом примере необходимо заблокировать агента пользователя evilbotи трафик в диапазоне 192.168.5.0/24. Чтобы выполнить это действие, можно создать два отдельных условия соответствия и поместить их в одно правило. Эта конфигурация гарантирует соответствие обоих злоботов в заголовке пользователя и IP-адресах диапазона 192.168.5.0/24, то запрос блокируется.
Логика: p и q
$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RemoteAddr
$variable2 = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector User-Agent
$condition1 = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable1 `
-Operator IPMatch `
-MatchValue "192.168.5.0/24" `
-NegationCondition $False
$condition2 = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable2 `
-Operator Contains `
-MatchValue "evilbot" `
-Transform Lowercase `
-NegationCondition $False
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name myrule `
-Priority 10 `
-RuleType MatchRule `
-MatchCondition $condition1, $condition2 `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "myrule",
"priority": 10,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RemoteAddr"
}
],
"operator": "IPMatch",
"negationCondition": false,
"matchValues": [
"192.168.5.0/24"
],
"transforms": []
},
{
"matchVariables": [
{
"variableName": "RequestHeaders",
"selector": "User-Agent"
}
],
"operator": "Contains",
"negationCondition": false,
"matchValues": [
"evilbot"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Пример 5
В этом примере необходимо заблокировать запрос, если IP-адрес находится вне диапазона 192.168.5.0/24 или строка агента пользователя не совпадает со значением chrome (то есть не используется браузер Chrome). Поскольку в этой логике используется оператор или, два условия находятся в отдельных правилах, как показано в следующем примере. Для блокировки трафика должны соблюдаться оба правила, myrule1 и myrule2.
Логика: не (p и q) = не p или не q.
$variable1 = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RemoteAddr
$variable2 = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector User-Agent
$condition1 = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable1 `
-Operator IPMatch `
-MatchValue "192.168.5.0/24" `
-NegationCondition $True
$condition2 = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable2 `
-Operator Contains `
-MatchValue "chrome" `
-Transform Lowercase `
-NegationCondition $True
$rule1 = New-AzApplicationGatewayFirewallCustomRule `
-Name myrule1 `
-Priority 10 `
-RuleType MatchRule `
-MatchCondition $condition1 `
-Action Block `
-State Enabled
$rule2 = New-AzApplicationGatewayFirewallCustomRule `
-Name myrule2 `
-Priority 20 `
-RuleType MatchRule `
-MatchCondition $condition2 `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "myrule1",
"priority": 10,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RemoteAddr"
}
],
"operator": "IPMatch",
"negationCondition": true,
"matchValues": [
"192.168.5.0/24"
],
"transforms": []
}
]
},
{
"name": "myrule2",
"priority": 20,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RequestHeaders",
"selector": "User-Agent"
}
],
"operator": "Contains",
"negationCondition": true,
"matchValues": [
"chrome"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Пример 6
Вы хотите разрешить запросы только от определенных известных агентов пользователей.
Поскольку в логике используется оператор или, а все значения находятся в заголовке агента пользователя, все MatchValues можно представить в виде списка, разделенного запятыми.
Логика: p или q или r
$variable = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector User-Agent
$condition = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable `
-Operator Equal `
-MatchValue @('user1', 'user2') `
-NegationCondition $True
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name BlockUnknownUserAgents `
-Priority 2 `
-RuleType MatchRule `
-MatchCondition $condition `
-Action Block `
-State Enabled
Соответствующий код JSON:
{
"customRules": [
{
"name": "BlockUnknownUserAgents",
"priority": 2,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RequestHeaders",
"selector": "User-Agent"
}
],
"operator": "Equal",
"negationCondition": true,
"matchValues": [
"user1",
"user2"
],
"transforms": []
}
]
}
]
}
Пример 7
Это не редкость для развертывания Azure Front Door перед Шлюз приложений. Чтобы убедиться, что трафик, получаемый шлюзом приложений, поступает из развертывания Azure Front Door, рекомендуется проверить, содержит ли заголовок X-Azure-FDID
ожидаемое уникальное значение. Дополнительные сведения о защите доступа к приложению с помощью Azure Front Door см. в статье "Как заблокировать доступ к серверной части только Azure Front Door"
Логика: не p
$expectedFDID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$variable = New-AzApplicationGatewayFirewallMatchVariable `
-VariableName RequestHeaders `
-Selector X-Azure-FDID
$condition = New-AzApplicationGatewayFirewallCondition `
-MatchVariable $variable `
-Operator Equal `
-MatchValue $expectedFDID `
-Transform Lowercase `
-NegationCondition $True
$rule = New-AzApplicationGatewayFirewallCustomRule `
-Name blockNonAFDTraffic `
-Priority 2 `
-RuleType MatchRule `
-MatchCondition $condition `
-Action Block `
-State Enabled
Ниже приведен соответствующий код JSON:
{
"customRules": [
{
"name": "blockNonAFDTraffic",
"priority": 2,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RequestHeaders",
"selector": "X-Azure-FDID"
}
],
"operator": "Equal",
"negationCondition": true,
"matchValues": [
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Следующие шаги
После создания настраиваемых правил вы можете узнать, как просматривать журналы WAF. Дополнительные сведения см. в разделе Журналы диагностики.