Creación y uso de reglas personalizadas de Firewall de aplicaciones web v2 en Application Gateway
El Firewall de aplicaciones web (WAF) v2 de Azure Application Gateway proporciona protección para las aplicaciones web. Esta protección la proporciona el conjunto de reglas básico (CRS) Proyecto de seguridad de aplicación web abierta (OWASP). En algunos casos, es posible que necesite crear reglas personalizadas propias para satisfacer necesidades concretas. Para más información sobre las reglas personalizadas de WAF, vea Reglas personalizadas para el firewall de aplicaciones web.
En este artículo se muestran algunas reglas personalizadas de ejemplo que puede crear y usar con el firewall de aplicaciones web v2. Para obtener información sobre cómo implementar un WAF con una regla personalizada mediante Azure PowerShell, vea Configuración de reglas personalizadas del firewall de aplicaciones web con Azure PowerShell.
Los fragmentos de código JSON que se muestran en este artículo se derivan de un recurso ApplicationGatewayWebApplicationFirewallPolicies.
Nota:
Si la puerta de enlace de aplicaciones no usa el nivel WAF, la opción para actualizar la puerta de enlace de aplicaciones al nivel WAF aparece en el panel derecho.
Ejemplo 1
Sabe que hay un bot denominado evilbot que quiere impedir que rastree el sitio web. En este caso, bloquea evilbot en el agente de usuario en los encabezados de solicitud.
Lógica: 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
Y este es el código JSON correspondiente:
{
"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"
]
}
]
}
]
}
Para ver un WAF implementado mediante esta regla personalizada, vea Configuración de una regla personalizada del firewall de aplicaciones web con Azure PowerShell.
Ejemplo 1a
Puede lograr lo mismo mediante una expresión regular:
$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
Y el código JSON correspondiente:
{
"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"
]
}
]
}
]
}
Ejemplo 2
Quiere permitir el tráfico solo de Estados Unidos mediante el operador GeoMatch y seguir aplicando las reglas administradas:
$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
Y el código JSON correspondiente:
{
"customRules": [
{
"name": "allowUS",
"priority": 2,
"ruleType": "MatchRule",
"action": "Block",
"state": "Enabled",
"matchConditions": [
{
"matchVariables": [
{
"variableName": "RemoteAddr"
}
],
"operator": "GeoMatch",
"negationCondition": true,
"matchValues": [
"US"
],
"transforms": [
"Lowercase"
]
}
]
}
]
}
Ejemplo 3
Quiere bloquear todas las solicitudes desde las direcciones IP del intervalo 198.168.5.0/24.
En este ejemplo, bloquea todo el tráfico que procede de un intervalo de direcciones IP. El nombre de la regla es myrule1 y la prioridad se establece en 10.
Lógica: 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
Este es el código JSON correspondiente:
{
"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": []
}
]
}
]
}
La regla de CRS correspondiente: SecRule REMOTE_ADDR "@ipMatch 192.168.5.0/24" "id:7001,deny"
Ejemplo 4
En este ejemplo, quiere bloquear evilbot en User-Agent y el tráfico en el intervalo 192.168.5.0/24. Para lograr esta acción, puede crear dos condiciones de coincidencia independientes y colocarlas en la misma regla. Esta configuración garantiza que si coinciden evilbot en el encabezado User-Agent y las direcciones IP del intervalo 192.168.5.0/24, la solicitud se bloquea.
Lógica: p y 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
Este es el código JSON correspondiente:
{
"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"
]
}
]
}
]
}
Ejemplo 5
En este ejemplo, quiere que se produzca el bloqueo si la solicitud está fuera del intervalo de direcciones IP 192.168.5.0/24, o bien la cadena de agente de usuario no es chrome (lo que significa que el usuario no usa el explorador Chrome). Como en esta lógica se usa o, las dos condiciones están en reglas independientes como se muestra en el ejemplo siguiente. myrule1 y myrule2 deben coincidir para que se bloquee el tráfico.
Lógica: no (p y q) = no p o no 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
Y el código JSON correspondiente:
{
"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"
]
}
]
}
]
}
Ejemplo 6
Solo quiere permitir solicitudes de agentes de usuario conocidos específicos.
Como la lógica que se usa aquí es o y todos los valores están en el encabezado Usuario-Agente, todos los valores MatchValues pueden estar en una lista separada por comas.
Lógica: p o q o 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
Código JSON correspondiente:
{
"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": []
}
]
}
]
}
Ejemplo 7
No es raro ver Azure Front Door implementado delante de Application Gateway. Para asegurarse de que el tráfico recibido por Application Gateway procede de la implementación de Front Door, el procedimiento recomendado es comprobar si el encabezado X-Azure-FDID
contiene el valor único esperado. Para obtener más información sobre cómo proteger el acceso a la aplicación mediante Azure Front Door, consulte Cómo bloquear el acceso a mi back-end solo a Azure Front Door
Lógica: not 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
Y este es el código JSON correspondiente:
{
"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"
]
}
]
}
]
}
Pasos siguientes
Después de crear las reglas personalizadas, puede aprender a ver los registros del firewall de aplicaciones web. Para más información, consulte Diagnósticos de Application Gateway.