Personalización de reglas del Firewall de aplicaciones web v2 en Azure Application Gateway

Artículo
01/30/2024

Azure Application Gateway Web Application Firewall (WAF) v2 viene con un conjunto de reglas preconfiguradas y administradas por la plataforma que ofrece protección contra muchos tipos diferentes de ataques. Estos ataques incluyen scripts entre sitios, inyección de código SQL y otros. Si es un administrador de WAF, puede escribir reglas propias para aumentar las del conjunto de reglas básico (CRS). Las reglas personalizadas pueden bloquear, permitir o registrar el tráfico solicitado en función de criterios de coincidencia. Si la directiva WAF se establece en modo de detección y se desencadena una regla de bloqueo personalizada, la solicitud se registra y no se realiza ninguna acción de bloqueo.

Las reglas personalizadas permiten crear reglas propias que se evalúan en cada solicitud que pasa por el WAF. Estas reglas tienen una prioridad mayor que el resto de las reglas de los conjuntos de reglas administrados. Las reglas personalizadas contienen un nombre de regla, la prioridad de la regla y una matriz de condiciones de coincidencia. Si estas condiciones se cumplen, se realiza una acción (para permitir, bloquear o registrar). Si se desencadena una regla personalizada y se realiza una acción de permitir o bloquear, no se evaluarán más reglas personalizadas o administradas. Las reglas personalizadas se pueden habilitar o deshabilitar a petición.

Por ejemplo, puede bloquear todas las solicitudes de una dirección IP en el intervalo 192.168.5.0/24. En esta regla, el operador es IPMatch, matchValues es el intervalo de direcciones IP (192.168.5.0/24) y la acción es bloquear el tráfico. Establezca también el nombre de la regla, la prioridad y el estado habilitado o deshabilitado.

Las reglas personalizadas admiten el uso de lógica de composición para crear reglas más avanzadas que solucionen los requisitos de seguridad. Por ejemplo, puede utilizar dos reglas personalizadas para crear la siguiente lógica ((rule1:Condition 1 y rule1:Condition 2) o rule2:Condition 3). Esta lógica significa que si se cumplen la Condición 1 y la Condición 2, o si se cumple la Condición 3, el WAF debe tomar la acción especificada en las reglas personalizadas.

En una misma regla, las condiciones de coincidencia diferentes siempre se combinan mediante y. Por ejemplo, bloquear el tráfico desde una dirección IP específica, y solo si se usa un explorador determinado.

Si quiere usar o entre dos condiciones diferentes, las dos deben estar en reglas distintas. Por ejemplo, bloquear el tráfico desde una dirección IP específica o bloquear el tráfico si se usa un explorador determinado.

En las reglas personalizadas también se admiten expresiones regulares, como en los conjuntos de reglas CRS. Para obtener ejemplos, consulte los ejemplos 3 y 5 en Creación y uso de reglas personalizadas del firewall de aplicaciones web.

Nota:

El número máximo de reglas personalizadas de WAF es 100. Para más información sobre los límites de Application Gateway, vea Suscripción de Azure y límites de servicio, cuotas y restricciones.

Precaución

Todas las reglas de redireccionamiento aplicadas en el nivel de puerta de enlace de aplicaciones omitirán las reglas personalizadas de WAF. Para más información acerca de las reglas de redireccionamiento, consulte Introducción al redireccionamiento de Application Gateway.

Diferencias entre permitir y bloquear

Permitir y bloquear el tráfico es sencillo con las reglas personalizadas. Por ejemplo, puede bloquear todo el tráfico procedente de un intervalo de direcciones IP. Puede crear otra regla para permitir el tráfico si la solicitud proviene de un explorador específico.

Para permitir algo, asegúrese de que el parámetro -Action esté establecido en Allow. Para bloquear algo, asegúrese de que el parámetro -Action esté establecido en 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

La regla $BlockRule anterior se asigna a la siguiente regla personalizada en 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"
            ]
          }
        ]
      }
    ],

Esta regla personalizada contiene un nombre, una prioridad, una acción y la matriz de condiciones de coincidencia que se deben cumplir para que la acción tenga lugar. Para obtener una explicación de estos campos, vea las descripciones siguientes. Para obtener ejemplos de reglas personalizadas, vea Creación y uso de reglas personalizadas del firewall de aplicaciones web.

Campos para reglas personalizadas

Nombre [opcional]

Nombre de la regla. Aparece en los registros.

Habilitar regla [opcional]

Active o desactive esta regla. Las reglas personalizadas están habilitadas de manera predeterminada.

Prioridad [obligatorio]

Determina el orden de evaluación de la regla. Cuanto menor sea el valor, antes se evalúa la regla. El intervalo permitido es de 1 a 100.
Debe ser única en todas las reglas personalizadas. Una regla con prioridad de 40 es evaluada antes que una regla con prioridad de 80.

Tipo de regla [obligatorio]

En la actualidad, debe ser MatchRule.

Variable de coincidencia [obligatorio]

Debe ser una de estas variables:

RemoteAddr: Intervalo o dirección IPv4 de la conexión del equipo remoto
RequestMethod: método de solicitud HTTP
QueryString: la variable en el URI
PostArgs: los argumentos enviados en el cuerpo de POST. Las reglas personalizadas que utilizan esta variable de coincidencia solo se aplican si el encabezado "Content-Type" tiene los valores "application/x-www-form-urlencoded" y "multipart/form-data" El tipo de contenido adicional de application/json se admite con CRS versión 3.2 o superior, el conjunto de reglas de protección contra bots y las reglas personalizadas de coincidencia geográfica.
RequestUri: URI de la solicitud
RequestHeaders: los encabezados de la solicitud
RequestBody: esta variable contiene todo el cuerpo de la solicitud en su conjunto. Las reglas personalizadas que usan esta variable de coincidencia solo se aplican si el encabezado "Content-Type" está establecido en el tipo de elementos multimedia application/x-www-form-urlencoded. Los tipos de contenido adicional de application/soap+xml, application/xml, text/xml se admite con CRS versión 3.2 o superior, el conjunto de reglas de protección contra bots y las reglas personalizadas de coincidencia geográfica.
RequestCookies: las cookies de la solicitud

Selector [opcional]

Describe el campo de la colección matchVariable. Por ejemplo, si matchVariable es RequestHeaders, el selector podría estar en el encabezado User-Agent.

Operador [obligatorio]

Debe ser uno de los operadores siguientes:

IPMatch: solo se usa cuando la variable de coincidencia es RemoteAddr, y solo admite IPv4
Equal: la entrada es la misma que MatchValue.
Cualquiera: no debe tener un valor MatchValue. Se recomienda para la variable de coincidencia con un selector válido.
Contains
LessThan
GreaterThan
LessThanOrEqual
GreaterThanOrEqual
BeginsWith
EndsWith
Regex
Geomatch

Negar condición [opcional]

Niega la condición actual.

Transformación [opcional]

Una lista de cadenas con los nombres de las transformaciones que se van a realizar antes de la coincidencia. Pueden ser las siguientes:

Minúsculas
Uppercase
Trim
UrlDecode
UrlEncode
RemoveNulls
HtmlEntityDecode

Valores de coincidencia [obligatorio]

Lista de valores con los que se va a comparar, que se pueden considerar como combinados mediante OR. Por ejemplo, podrían ser direcciones IP u otras cadenas. El formato del valor depende del operador anterior.

Los valores del método de solicitud HTTP admitidos incluyen:

GET
HEAD
POST
OPCIONES
PUT
SUPRIMIR
PATCH

Acción [obligatorio]

En el modo de detección de directivas WAF, si se desencadena una regla personalizada, la acción siempre se registra independientemente del valor de acción establecido en la regla personalizada.

Permitir: autoriza la transacción y se omiten todas las otras reglas. La solicitud especificada se agrega a la lista de permitidos y, una vez que aparece una coincidencia, la solicitud detiene la evaluación adicional y se envía al grupo de back-end. En las reglas que están en la lista de permitidos no se evalúa si hay más reglas administradas o personalizadas.
Bloquear: bloquea o registra la transacción en función de SecDefaultAction (modo de detección o prevención).
- Modo de prevención: bloquea la transacción en función de SecDefaultAction. Como sucede con la acción Allow, una vez que la solicitud se evalúa y se agrega a la lista de bloqueados, la evaluación se detiene y la solicitud se bloquea. Las solicitudes posteriores que cumplan las mismas condiciones no se evaluarán y simplemente se bloquearán.
- Modo de detección: registra la transacción en función de SecDefaultAction, después del cual se detiene la evaluación. Las solicitudes posteriores que cumplan las mismas condiciones no se evaluarán y simplemente se registrarán.
Log: permite que la regla escriba en el registro, pero que las reglas restantes se ejecuten para la evaluación. Las otras reglas personalizadas se evalúan por orden de prioridad, seguidas por las reglas administradas.

Copiar y duplicar reglas personalizadas

Las reglas personalizadas pueden duplicarse dentro de una misma directiva. Al duplicar una regla, es necesario especificar un nombre único para la regla y un valor de prioridad único. Además, las reglas personalizadas se pueden copiar de una directiva WAF de Application Gateway a otra, siempre que ambas directivas estén en la misma suscripción. Al copiar una regla de una directiva a otra, debe seleccionar la directiva WAF de Application Gateway en la que desea copiar la regla. Una vez seleccionada la directiva WAF, hay que dar a la regla un nombre único y asignarle un rango de prioridad.

Reglas personalizadas de geomatch

Las reglas personalizadas permiten la creación de reglas adaptadas para satisfacer las necesidades precisas de las aplicaciones y las directivas de seguridad. Puede restringir el acceso a las aplicaciones web por país o región. Para obtener más información, consulte Reglas personalizadas de Geomatch.

Compartir vía