Usar regras personalizadas de geomatch do Azure WAF para melhorar a segurança da rede
Os firewalls de aplicativos da Web (WAFs) são uma ferramenta importante que ajuda a proteger os aplicativos da Web contra ataques prejudiciais. Eles podem filtrar, monitorar e parar o tráfego da Web usando regras predefinidas e personalizadas. Você pode criar sua própria regra que o WAF verifica para cada solicitação que recebe. As regras personalizadas têm prioridade maior do que as regras gerenciadas e são verificadas primeiro.
Um dos recursos mais poderosos do Firewall de Aplicativo Web do Azure é a correspondência geográfica de regras personalizadas. Estas regras permitem-lhe fazer corresponder os pedidos da Web à localização geográfica da sua origem. Talvez você queira interromper solicitações de determinados locais conhecidos por atividades prejudiciais ou permitir solicitações de locais importantes para sua empresa. As regras personalizadas do Geomatch também podem ajudá-lo a seguir as leis de soberania e privacidade de dados, limitando o acesso às suas aplicações Web com base na localização das pessoas que as utilizam.
Use o parâmetro priority com sabedoria ao usar regras personalizadas de geomatch para evitar processamento desnecessário ou conflitos. O WAF do Azure avalia regras na ordem determinada pelo parâmetro priority, um valor numérico que varia de 1 a 100, com valores mais baixos indicando prioridade mais alta. A prioridade deve ser exclusiva em todas as regras personalizadas. Atribua maior prioridade a regras críticas ou específicas para a segurança do seu aplicativo Web e menor prioridade a regras menos essenciais ou gerais. Isso garante que o WAF aplique as ações mais apropriadas ao seu tráfego da web. Por exemplo, o cenário em que você identifica um caminho de URI explícito é o mais específico e deve ter uma regra de prioridade mais alta do que outros tipos de padrões. Isso protege um caminho crítico no aplicativo com a prioridade mais alta, permitindo que o tráfego mais genérico seja avaliado em outras regras personalizadas ou conjuntos de regras gerenciados.
Para tornar o parágrafo mais fácil de entender para um público técnico usando o tempo presente e a voz ativa, você pode reescrevê-lo da seguinte maneira:
Teste sempre as suas regras antes de as aplicar à produção e monitorize regularmente o seu desempenho e impacto. Seguindo essas práticas recomendadas, você pode aprimorar a segurança do seu aplicativo Web usando o poder das regras personalizadas de correspondência geográfica.
Este artigo apresenta as regras personalizadas de geocorrespondência do WAF do Azure e mostra como criá-las e gerenciá-las usando o portal do Azure, o Bicep e o Azure PowerShell.
Padrões de regras personalizadas de correspondência geográfica
As regras personalizadas de correspondência geográfica permitem que você atenda a diversas metas de segurança, como bloquear solicitações de áreas de alto risco e permitir solicitações de locais confiáveis. Eles são particularmente eficazes na mitigação de ataques distribuídos de negação de serviço (DDoS), que procuram inundar seu aplicativo Web com uma infinidade de solicitações de várias fontes. Com regras personalizadas de geomatch, você pode identificar e bloquear prontamente as regiões que geram mais tráfego DDoS, enquanto ainda concede acesso a usuários legítimos. Neste artigo, você aprenderá sobre vários padrões de regras personalizados que você pode empregar para otimizar seu WAF do Azure usando regras personalizadas de correspondência geográfica.
Cenário 1 - Bloquear o tráfego de todos os países ou regiões, exceto "x"
As regras personalizadas do Geomatch são úteis quando você pretende bloquear o tráfego de todos os países ou regiões, exceto um. Por exemplo, se seu aplicativo Web atende exclusivamente a usuários nos Estados Unidos, você pode formular uma regra personalizada de correspondência geográfica que obstrua todas as solicitações não originadas dos EUA. Essa estratégia minimiza efetivamente a superfície de ataque do seu aplicativo Web e impede o acesso não autorizado de outras regiões. Esta técnica específica emprega uma condição de negação para facilitar este padrão de tráfego. Para criar uma regra personalizada de correspondência geográfica que obstrua o tráfego de todos os países ou regiões, exceto os EUA, consulte os seguintes exemplos de portal, Bíceps e PowerShell:
Exemplo de portal - Application Gateway
Exemplo de portal - Front Door
Nota
Observe no WAF do Azure Front Door, você usa SocketAddr
como a variável de correspondência e não RemoteAddr
. A RemoteAddr
variável é o endereço IP original do cliente que geralmente é enviado através do cabeçalho da X-Forwarded-For
solicitação. A SocketAddr
variável é o endereço IP de origem que o WAF vê.
Exemplo de bíceps - Application Gateway
properties: {
customRules: [
{
name: 'GeoRule1'
priority: 10
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: true
matchValues: [
'US'
]
transforms: []
}
]
state: 'Enabled'
}
Exemplo de bíceps - Front Door
properties: {
customRules: {
rules: [
{
name: 'GeoRule1'
enabledState: 'Enabled'
priority: 10
ruleType: 'MatchRule'
matchConditions: [
{
matchVariable: 'SocketAddr'
operator: 'GeoMatch'
negateCondition: true
matchValue: [
'US'
]
transforms: []
}
]
action: 'Block'
}
Exemplo do Azure PowerShell - Application Gateway
$RGname = "rg-waf "
$policyName = "waf-pol"
$variable = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable -Operator GeoMatch -MatchValue "US" -NegationCondition $true
$rule = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule1 -Priority 10 -RuleType MatchRule -MatchCondition $condition -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
Exemplo do Azure PowerShell - Front Door
$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue "US" -NegateCondition $true
$customRuleObject = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule1" -RuleType MatchRule -MatchCondition $matchCondition -Action Block -Priority 10
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject
Cenário 2 - Bloquear o tráfego de todos os países ou regiões, exceto "x" e "y" que visam o URI "foo" ou "bar"
Considere um cenário em que você precise usar regras personalizadas de correspondência geográfica para bloquear o tráfego de todos os países ou regiões, exceto dois ou mais específicos, visando um URI específico. Suponha que seu aplicativo Web tenha caminhos de URI específicos destinados apenas a usuários nos EUA e no Canadá. Nesse caso, você cria uma regra personalizada de correspondência geográfica que bloqueia todas as solicitações não originárias desses países ou regiões.
Esse padrão processa cargas úteis de solicitação dos EUA e Canadá por meio dos conjuntos de regras gerenciados, capturando quaisquer ataques mal-intencionados e bloqueando solicitações de todos os outros países ou regiões. Essa abordagem garante que apenas seu público-alvo possa acessar seu aplicativo da Web, evitando tráfego indesejado de outras regiões.
Para minimizar possíveis falsos positivos, inclua o código de país ZZ na lista para capturar endereços IP ainda não mapeados para um país ou região no conjunto de dados do Azure. Essa técnica usa uma condição negada para o tipo de geolocalização e uma condição não negada para a correspondência de URI.
Para criar uma regra personalizada de correspondência geográfica que bloqueie o tráfego de todos os países ou regiões, exceto os EUA e o Canadá, para um URI especificado, consulte os exemplos de portal, Bíceps e Azure PowerShell fornecidos.
Exemplo de portal - Application Gateway
Exemplo de portal - Front Door
Exemplo de bíceps - Application Gateway
properties: {
customRules: [
{
name: 'GeoRule2'
priority: 11
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: true
matchValues: [
'US'
'CA'
]
transforms: []
}
{
matchVariables: [
{
variableName: 'RequestUri'
}
]
operator: 'Contains'
negationConditon: false
matchValues: [
'/foo'
'/bar'
]
transforms: []
}
]
state: 'Enabled'
}
Exemplo de bíceps - Front Door
properties: {
customRules: {
rules: [
{
name: 'GeoRule2'
enabledState: 'Enabled'
priority: 11
ruleType: 'MatchRule'
matchConditions: [
{
matchVariable: 'SocketAddr'
operator: 'GeoMatch'
negateCondition: true
matchValue: [
'US'
'CA'
]
transforms: []
}
{
matchVariable: 'RequestUri'
operator: 'Contains'
negateCondition: false
matchValue: [
'/foo'
'/bar'
]
transforms: []
}
]
action: 'Block'
}
Exemplo do Azure PowerShell - Application Gateway
$RGname = "rg-waf "
$policyName = "waf-pol"
$variable1a = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition1a = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1a -Operator GeoMatch -MatchValue @(“US”, “CA”) -NegationCondition $true
$variable1b = New-AzApplicationGatewayFirewallMatchVariable -VariableName RequestUri
$condition1b = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable1b -Operator Contains -MatchValue @(“/foo”, “/bar”) -NegationCondition $false
$rule1 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule2 -Priority 11 -RuleType MatchRule -MatchCondition $condition1a, $condition1b -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule1)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
Exemplo do Azure PowerShell - Front Door
$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition1a = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue @(“US”, "CA") -NegateCondition $true
$matchCondition1b = New-AzFrontDoorWafMatchConditionObject -MatchVariable RequestUri -OperatorProperty Contains -MatchValue @(“/foo”, “/bar”) -NegateCondition $false
$customRuleObject1 = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule2" -RuleType MatchRule -MatchCondition $matchCondition1a, $matchCondition1b -Action Block -Priority 11
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject1
Cenário 3 - Bloquear o tráfego especificamente do país ou região "x"
Você pode usar regras personalizadas de correspondência geográfica para bloquear o tráfego de países ou regiões específicos. Por exemplo, se seu aplicativo Web receber muitas solicitações maliciosas do país ou região "x", crie uma regra personalizada de correspondência geográfica para bloquear todas as solicitações desse país ou região. Isso protege seu aplicativo Web contra possíveis ataques e reduz a carga de recursos. Aplique esse padrão para bloquear vários países ou regiões mal-intencionados ou hostis. Esta técnica requer uma condição de correspondência para o padrão de tráfego. Para bloquear o tráfego do país ou região "x", consulte os seguintes exemplos de portal, Bíceps e Azure PowerShell.
Exemplo de portal - Application Gateway
Exemplo de portal - Front Door
Exemplo de bíceps - Application Gateway
properties: {
customRules: [
{
name: 'GeoRule3'
priority: 12
ruleType: 'MatchRule'
action: 'Block'
matchConditions: [
{
matchVariables: [
{
variableName: 'RemoteAddr'
}
]
operator: 'GeoMatch'
negationConditon: false
matchValues: [
'US'
]
transforms: []
}
]
state: 'Enabled'
}
Exemplo de bíceps - Front Door
properties: {
customRules: {
rules: [
{
name: 'GeoRule3'
enabledState: 'Enabled'
priority: 12
ruleType: 'MatchRule'
matchConditions: [
{
matchVariable: 'SocketAddr'
operator: 'GeoMatch'
negateCondition: false
matchValue: [
'US'
]
transforms: []
}
]
action: 'Block'
}
Exemplo do Azure PowerShell - Application Gateway
$RGname = "rg-waf "
$policyName = "waf-pol"
$variable2 = New-AzApplicationGatewayFirewallMatchVariable -VariableName RemoteAddr
$condition2 = New-AzApplicationGatewayFirewallCondition -MatchVariable $variable2 -Operator GeoMatch -MatchValue "US" -NegationCondition $false
$rule2 = New-AzApplicationGatewayFirewallCustomRule -Name GeoRule3 -Priority 12 -RuleType MatchRule -MatchCondition $condition2 -Action Block
$policy = Get-AzApplicationGatewayFirewallPolicy -Name $policyName -ResourceGroupName $RGname
$policy.CustomRules.Add($rule2)
Set-AzApplicationGatewayFirewallPolicy -InputObject $policy
Exemplo do Azure PowerShell - Front Door
$RGname = "rg-waf"
$policyName = "wafafdpol"
$matchCondition2 = New-AzFrontDoorWafMatchConditionObject -MatchVariable SocketAddr -OperatorProperty GeoMatch -MatchValue "US" -NegateCondition $false
$customRuleObject2 = New-AzFrontDoorWafCustomRuleObject -Name "GeoRule3" -RuleType MatchRule -MatchCondition $matchCondition2 -Action Block -Priority 12
$afdWAFPolicy= Get-AzFrontDoorWafPolicy -Name $policyName -ResourceGroupName $RGname
Update-AzFrontDoorWafPolicy -InputObject $afdWAFPolicy -Customrule $customRuleObject2
Anti-padrões de regras personalizadas de correspondência geográfica
Evite antipadrões ao usar regras personalizadas de correspondência geográfica, como definir a ação de block
regra personalizada como allow
. Isso pode ter consequências indesejadas, como permitir que o tráfego ignore o WAF e potencialmente expor seu aplicativo Web a outras ameaças.
Em vez de usar uma allow
ação, use uma block
ação com uma condição negada, como mostrado nos padrões anteriores. Isso garante que apenas o tráfego dos países ou regiões desejados seja permitido e o WAF bloqueie todo o outro tráfego.
Cenário 4 - permitir tráfego do país ou região "x"
Evite definir a regra personalizada de correspondência geográfica para permitir o tráfego de um país ou região específico. Por exemplo, se você quiser permitir o tráfego dos Estados Unidos devido a uma grande base de clientes, criar uma regra personalizada com a ação allow
e o valor United States
pode parecer a solução. No entanto, essa regra permite todo o tráfego dos Estados Unidos, independentemente de ter uma carga maliciosa ou não, já que a ação ignora o allow
processamento adicional de regras gerenciadas. Além disso, o WAF ainda processa o tráfego de todos os outros países ou regiões, consumindo recursos. Isso expõe seu aplicativo Web a solicitações maliciosas dos Estados Unidos que, de outra forma, o WAF bloquearia.
Cenário 5 - Permitir tráfego de todos os municípios, exceto "x"
Evite definir a ação da regra e allow
especificar uma lista de países ou regiões a serem excluídos ao usar regras personalizadas de correspondência geográfica. Por exemplo, se você quiser permitir o tráfego de todos os países ou regiões, exceto dos Estados Unidos, onde suspeitar de atividades maliciosas, essa abordagem pode ter consequências indesejadas. Pode permitir o tráfego de países/regiões não verificados ou inseguros ou de países/regiões com baixos ou nenhuns padrões de segurança, expondo a sua aplicação Web a potenciais vulnerabilidades ou ataques. O uso da allow
ação para todos os países ou regiões, exceto os EUA, indica ao WAF para parar de processar cargas úteis de solicitação em conjuntos de regras gerenciados. Toda a avaliação da regra cessa quando a regra personalizada é allow
processada, expondo o aplicativo a ataques mal-intencionados indesejados.
Em vez disso, use uma ação de regra mais restritiva e específica, como bloquear, e especifique uma lista de países ou regiões a serem permitidos com uma condição negada. Isso garante que apenas o tráfego de fontes confiáveis e verificadas possa acessar seu aplicativo da Web enquanto bloqueia qualquer tráfego suspeito ou indesejado.