Uso de reglas personalizadas de coincidencia geográfica de Azure WAF para mejorar la seguridad de la red
Los firewalls de aplicaciones web (WAF) son una herramienta importante que ayuda a proteger las aplicaciones web frente a ataques dañinos. Pueden filtrar, supervisar y detener el tráfico web mediante reglas preestablecidas y personalizadas. Puede crear su propia regla, que el WAF comprobará para cada solicitud que obtiene. Las reglas personalizadas tienen mayor prioridad que las reglas administradas y se comprueban primero.
Una de las características más eficaces de Azure Web Application Firewall son las reglas personalizadas de coincidencia geográfica. Estas reglas permiten hacer coincidir las solicitudes web con la ubicación geográfica de donde proceden. Es posible que quiera detener las solicitudes de determinados lugares conocidos por actividades perjudiciales o que quiera permitir solicitudes de lugares importantes para su negocio. Las reglas personalizadas de coincidencia geográfica también pueden ayudarle a seguir las leyes de soberanía y privacidad de los datos limitando el acceso a las aplicaciones web en función de la ubicación de las personas que las usan.
Use el parámetro de prioridad con prudencia al usar reglas personalizadas de coincidencia geográfica para evitar conflictos o procesamiento innecesarios. Azure WAF evalúa las reglas en el orden determinado por el parámetro de prioridad, un valor numérico comprendido entre 1 y 100, en el que los valores inferiores indican una prioridad más alta. La prioridad debe ser única entre todas las reglas personalizadas. Asigne mayor prioridad a reglas críticas o específicas para la seguridad de la aplicación web y menor prioridad a reglas menos esenciales o generales. Esto garantiza que WAF aplique las acciones más adecuadas al tráfico web. Por ejemplo, el escenario en el que se identifica una ruta de acceso de URI explícita es el más específico y debe tener una regla de prioridad más alta que otros tipos de patrones. Esto protege una ruta de acceso crítica en la aplicación con la prioridad más alta, al tiempo que permite evaluar el tráfico más genérico en otras reglas personalizadas o conjuntos de reglas administrados.
Para que el párrafo sea más fácil de entender para un público técnico mediante el tiempo presente y la voz activa, se puede reescribir de la siguiente manera:
Pruebe siempre las reglas antes de aplicarlas a producción y supervise periódicamente su rendimiento e impacto. Siguiendo estos procedimientos recomendados, puede mejorar la seguridad de las aplicaciones web mediante la eficacia de las reglas personalizadas de coincidencia geográfica.
En este artículo, se presentan las reglas personalizadas de coincidencia geográfica de Azure WAF y se muestra cómo crearlas y administrarlas mediante Azure Portal, Bicep y Azure PowerShell.
Patrones de reglas personalizadas de coincidencia geográfica
Las reglas personalizadas de coincidencia geográfica permiten cumplir diversos objetivos de seguridad, como bloquear solicitudes de áreas de alto riesgo y permitir solicitudes desde ubicaciones de confianza. Son especialmente eficaces para mitigar los ataques de denegación de servicio distribuido (DDoS), que buscan inundar la aplicación web con una gran cantidad de solicitudes de varios orígenes. Con las reglas personalizadas de coincidencia geográfica, puede identificar y bloquear rápidamente las regiones que generan el mayor tráfico de DDoS, a la vez que se concede acceso a usuarios legítimos. En este artículo, obtendrá información sobre varios patrones de reglas personalizadas que puede emplear para optimizar Azure WAF mediante reglas personalizadas de coincidencia geográfica.
Escenario 1: bloquear el tráfico de todos los países excepto "x"
Las reglas personalizadas de coincidencia geográfica resultan útiles cuando se pretende bloquear el tráfico de todos los países, salvo uno. Por ejemplo, si la aplicación web atiende exclusivamente a usuarios de los Estados Unidos, puede formular una regla personalizada de coincidencia geográfica que obstruya todas las solicitudes que no se originan en los Estados Unidos. Esta estrategia minimiza eficazmente la superficie expuesta a ataques de la aplicación web y disuade el acceso no autorizado desde otras regiones. Esta técnica específica emplea una condición de negación para facilitar este patrón de tráfico. Para crear una regla personalizada de coincidencia geográfica que obstruya el tráfico de todos los países excepto los Estados Unidos, consulte los siguientes ejemplos del portal, Bicep y PowerShell:
Ejemplo del portal: Application Gateway
Ejemplo del portal: Front Door
Nota:
Observe que en el WAF de Azure Front Door se usa SocketAddr como variable de coincidencia y no RemoteAddr. La variable RemoteAddr es la dirección IP del cliente original, que se envía normalmente mediante el encabezado de solicitud X-Forwarded-For. La variable SocketAddr es la dirección IP de origen que ve WAF.
Ejemplo de Bicep: 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'
}
Ejemplo de Bicep: 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'
}
Ejemplo de 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
Ejemplo de 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
Escenario 2: Bloquear el tráfico de todos los países excepto "x" e "y" que tenga como destino el identificador URI "foo" o "bar"
Considere un escenario en el que tiene que usar reglas personalizadas de coincidencia geográfica para bloquear el tráfico de todos los países, excepto para dos específicos o más, que tenga como destino un identificador URI específico. Supongamos que la aplicación web tiene rutas de acceso de identificador URI específicas diseñadas solo para los usuarios de los Estados Unidos y Canadá. En este caso, creará una regla personalizada de coincidencia geográfica que bloquee todas las solicitudes que no se originan en estos países.
Este patrón procesa las cargas de solicitud de los Estados Unidos y Canadá mediante los conjuntos de reglas administradas, detectando cualquier ataque malintencionado, al tiempo que bloquea las solicitudes de todos los demás países. Este enfoque garantiza que solo el público objetivo pueda acceder a la aplicación web, evitando el tráfico no deseado de otras regiones.
Para minimizar posibles falsos positivos, incluya el código de país ZZ en la lista para capturar direcciones IP aún no asignadas a un país en el conjunto de datos de Azure. Esta técnica usa una condición de negación para el tipo de geolocalización y una condición sin negación para la coincidencia de identificador URI.
Para crear una regla personalizada de coincidencia geográfica que bloquee el tráfico de todos los países excepto los Estados Unidos y Canadá a un identificador URI especificado, consulte los ejemplos del portal, Bicep y Azure PowerShell proporcionados.
Ejemplo del portal: Application Gateway
Ejemplo del portal: Front Door
Ejemplo de Bicep: 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'
}
Ejemplo de Bicep: 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'
}
Ejemplo de 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
Ejemplo de 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
Escenario 3: Bloquear el tráfico específicamente desde el país "x"
Puede usar reglas personalizadas de coincidencia geográfica para bloquear el tráfico de países específicos. Por ejemplo, si la aplicación web recibe muchas solicitudes malintencionadas del país "x", cree una regla personalizada de coincidencia geográfica para bloquear todas las solicitudes de ese país. Esto protege la aplicación web frente a posibles ataques y reduce la carga de recursos. Aplique este patrón para bloquear varios países malintencionados u hostiles. Esta técnica requiere una condición de coincidencia para el patrón de tráfico. Para bloquear el tráfico desde el país "x", consulte los siguientes ejemplos del portal, Bicep y Azure PowerShell.
Ejemplo del portal: Application Gateway
Ejemplo del portal: Front Door
Ejemplo de Bicep: 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'
}
Ejemplo de Bicep: 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'
}
Ejemplo de 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
Ejemplo de 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
Antipatrones de reglas personalizadas de coincidencia geográfica
Evite los antipatrones al usar reglas personalizadas de coincidencia geográfica, como establecer la acción de la regla personalizada en allow en lugar de block. Esto puede tener consecuencias imprevistas, como permitir que el tráfico omita el WAF y exponer potencialmente la aplicación web a otras amenazas.
En lugar de usar una acción allow, use una acción block con una condición de negación, como se muestra en los patrones anteriores. Esto garantiza que solo se permita el tráfico de los países deseados y el WAF bloquee todo el resto del tráfico.
Escenario 4: permitir el tráfico desde el país "x"
Evite establecer la regla personalizada de coincidencia geográfica para permitir el tráfico desde un país específico. Por ejemplo, si desea permitir el tráfico desde los Estados Unidos debido a una base de clientes grande, crear una regla personalizada con la acción allow y el valor United States podría parecerse a la solución. Sin embargo, esta regla permite todo el tráfico de los Estados Unidos, independientemente de si tiene una carga malintencionada o no, ya que la acción allow omite el procesamiento de las reglas adicionales de los conjuntos de reglas administrados. Además, el WAF sigue procesando el tráfico de todos los demás países, consumiendo recursos. Esto expone la aplicación web a solicitudes malintencionadas de los Estados Unidos que el WAF bloquearía de otro modo.
Escenario 5: Bloquear el tráfico de todos los países excepto "x"
Evite establecer la acción de la regla en allow y especificar una lista de países que se excluirán al usar reglas personalizadas de coincidencia geográfica. Por ejemplo, si desea permitir el tráfico desde todos los países excepto los Estados Unidos, donde sospecha actividad malintencionada, este enfoque puede tener consecuencias no deseadas. Podría permitir el tráfico de países no seguros, no comprobados o con estándares de seguridad bajos, exponiendo la aplicación web a posibles vulnerabilidades o ataques. El uso de la acción allow para todos los países excepto los Estados unidos indica al WAF que detenga el procesamiento de cargas de solicitudes con conjuntos de reglas administradas. Toda la evaluación de reglas deja de funcionar una vez que se procesa la regla personalizada con allow, exponiendo la aplicación a ataques malintencionados no deseados.
En su lugar, use una acción de regla más restrictiva y específica, como bloquear, y especifique una lista de países que se van a permitir con una condición de negación. Esto garantiza que solo el tráfico de orígenes comprobados y de confianza pueda acceder a la aplicación web mientras bloquea cualquier tráfico sospechoso o no deseado.