Soluciona problemas de Cloud Armor

Usa estas instrucciones para solucionar los problemas con las políticas de seguridad de Google Cloud Armor.

Problemas generales

En esta sección, se abarcan los problemas comunes que se producen cuando se usa Cloud Armor.

Depura las políticas de seguridad

Si necesitas información adicional sobre qué evento específico activa reglas preconfiguradas, lee Usa el registro de solicitudes y habilita el registro detallado. Cloud Logging registra un nivel de detalle más alto en tus registros que puedes usar para analizar y depurar tus políticas y reglas.

Se permite el tráfico a pesar de tener configurada una regla de denegación en la política de seguridad de Cloud Armor

Para solucionar esto, sigue estos pasos:

  1. Asegúrate de que la política de seguridad de Cloud Armor esté vinculada a un servicio de backend de destino. Por ejemplo, mediante el siguiente comando, se describen todos los datos asociados con el servicio de backend BACKEND. En los resultados que se muestran, se debe incluir el nombre de la política de seguridad de Cloud Armor asociada con este servicio de backend.

    gcloud compute backend-services describe BACKEND

    Reemplaza BACKEND por el nombre del servicio de backend.

  2. Revisa los registros de HTTP(S) para determinar la política y la regla que coincidieron con el tráfico y la acción asociada. Para ver los registros, usa Cloud Logging.

    El siguiente es un registro de muestra de una solicitud permitida con los campos interesantes destacados. Verifica los siguientes campos y asegúrate de que coincidan con la regla que configuraste para denegar el tráfico:

    • configuredAction debe coincidir con la acción configurada en la regla.
    • name debe coincidir con el nombre de la política de seguridad de Cloud Armor que se vinculó a este servicio de backend.
    • outcome debe coincidir con configuredAction.
    • priority debe coincidir con el número de prioridad de la regla.
     httpRequest:
  remoteIp: 104.133.0.95
  requestMethod: GET
  requestSize: '801'
  requestUrl: http://74.125.67.38/
  responseSize: '246'
  serverIp: 10.132.0.4
  status: 200
  userAgent: curl/7.35.0
    insertId: ajvis5ev4i60
    internalId:
      projectNumber: '895280006100'
    jsonPayload:
      '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
      enforcedSecurityPolicy:
        configuredAction: ACCEPT
        name: mydev-policy-log-test1
        outcome: ACCEPT
        priority: 2147483647
      statusDetails: response_sent_by_backend
    logName: projects/mydev-staging/logs/requests
    resource:
      labels:
        backend_service_name: BACKEND_SERVICE_NAME
        forwarding_rule_name: FORWARDING_RULE_NAME
        project_id: PROJECT_ID
        target_proxy_name: TARGET_HTTP_PROXY_NAME
        url_map_name: URL_MAP_NAME
        zone: global
      type: http_load_balancer
    severity: INFO
    timestamp: '2017-04-18T18:57:05.845960288Z'

    En esta salida, se incluyen los siguientes valores:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend.
    • FORWARDING_RULE_NAME: el nombre de la regla de reenvío.
    • PROJECT_ID: Es el ID de tu proyecto.
    • TARGET_HTTP_PROXY_NAME: el nombre del proxy HTTP de destino.
    • URL_MAP_NAME: el nombre del mapa de URLs.

  3. Revisa la jerarquía de reglas para asegurarte de que se establezca la coincidencia con la regla correcta. Es posible que una regla con una prioridad más alta que tiene una acción “allow” coincida con tu tráfico. Usa el comando describe en security-policies en Google Cloud CLI para ver el contenido de la política de seguridad de Cloud Armor.

    Por ejemplo, se muestra cómo una regla de permiso de mayor prioridad (con prioridad 100) coincide con el tráfico proveniente de la dirección IP 1.2.3.4, lo que evita que se active y bloquee la regla de rechazo de menor prioridad (con prioridad 200) el tráfico.

    gcloud compute security-policies describe POLICY_NAME

    Reemplaza POLICY_NAME por el nombre de la política de seguridad.

    El resultado es similar a este:

    creationTimestamp: '2017-04-18T14:47:58.045-07:00
description: ''
fingerprint: Yu5spBjdoC0=
id: '2560355463394441057'
kind: compute#securityPolicy
name: POLICY_NAME
rules:
-action: allow
 description: allow high priority rule
 kind: compute#securityPolicyRule
 match:
   srcIpRanges:
   -'1.2.3.4/32'
 preview: false
 priority: 100
-action: deny
 description: deny lower priority rule
 kind: compute#securityPolicyRule
 match:
   srcIpRanges:
   -'1.2.3.0/24
 preview: false
 priority: 200
-action: deny
 description: default rule
 kind: compute#securityPolicyRule
 match:
   srcIpRanges:
   -'*'
 preview: false
 priority: 2147483647
 selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp

La regla preconfigurada muestra falsos positivos

La detección de XSS y SQLi se basa en la coincidencia de firmas estáticas en los encabezados de la solicitud HTTP y en otros parámetros de capa 7. Estos patrones de expresión regular son propensos a mostrar falsos positivos. Puedes usar la regla preconfigurada para la detección de XSS y SQLi en el modo de vista previa y, luego, verificar el registro en busca de falsos positivos.

Si encuentras un falso positivo, puedes comparar el contenido del tráfico con las reglas de CRS de OWASP. Si migras desde una versión anterior de CRS, consulta la comparación de versiones de reglas de WAF para obtener una lista de los cambios y los cambios de nombre de las reglas. Si la regla no es válida o no es relevante, inhabilítala con la expresión evaluatePreconfiguredWaf y especifica el ID de la regla en el argumento exclude ID list.

Después de revisar los registros y quitar todos los falsos positivos, inhabilita el modo de vista previa.

Para agregar una regla preconfigurada en el modo de vista previa, haz lo siguiente:

  1. Crea una política de seguridad con el conjunto de expresiones preconfiguradas en el modo de vista previa:

     gcloud compute security-policies rules create 1000
     --security-policy POLICY_NAME
     --expression "evaluatePreconfiguredWaf('xss-stable')"
     --action deny-403
     --preview

    Reemplaza POLICY_NAME por el nombre de la política de seguridad.

  2. Revisa los registros de HTTP(S) en busca de campos de la solicitud HTTP como url y cookie. Por ejemplo, requestUrl se compara de forma positiva con el ID de regla 941180 de CRS de OWASP:

    httpRequest:
 remoteIp: 104.133.0.95
 requestMethod: GET
 requestSize: '801'
 requestUrl: http://74.125.67.38/foo?document.cookie=1010"
 responseSize: '246'
 serverIp: 10.132.0.4
 status: 200
 userAgent: curl/7.35.0
insertId: ajvis5ev4i60
internalId:
 projectNumber: '895280006100'
jsonPayload:
 '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
 enforcedSecurityPolicy:
   configuredAction: ACCEPT
   name: POLICY_NAME
   outcome: ACCEPT
   priority: 2147483647
   preconfiguredExprIds: [ 'owasp-crs-v042200-id941180-xss' ]
 statusDetails: response_sent_by_backend
logName: projects/mydev-staging/logs/requests
resource:
 labels:
   backend_service_name: BACKEND_SERVICE
   forwarding_rule_name: mydev-forwarding-rule
   project_id: mydev-staging
   target_proxy_name: mydev-target-http-proxy
   url_map_name: mydev-url-map
   zone: global
 type: http_load_balancer
severity: INFO
timestamp: '2017-04-18T18:57:05.845960288Z'

    Este registro incluye los siguientes valores:

    • POLICY_NAME: el nombre de la política de seguridad.
    • BACKEND_SERVICE: el nombre del servicio de backend.

  3. Excluye el ID de regla 941180 de CRS de OWASP actualizando la regla en la política de seguridad de Cloud Armor:

     gcloud compute security-policies rules update 1000 \
     --security-policy POLICY_NAME \
     --expression "evaluatePreconfiguredWaf('xss-v422-stable', ['owasp-crs-v042200-id941180-xss'])" \
     --action deny-403 \
     --preview

    Reemplaza POLICY_NAME por el nombre de la política de seguridad.

  4. Vuelve a revisar los registros y, luego, inhabilita el modo de vista previa para implementar la regla.

Los clientes con firmas denegadas no se bloquean ni se deniegan

Si usas Cloud Armor con Cloud CDN, las políticas de seguridad solo se aplican a las solicitudes de contenido dinámico, errores de caché u otras solicitudes que están destinadas al servidor de origen de CDN. Los aciertos de caché se entregan incluso si la política de seguridad descendente de Cloud Armor puede impedir que esa solicitud llegue al servidor de origen de CDN.

Problemas con la inspección del cuerpo de la solicitud

Debido a que Cloud Armor evalúa los datos de forma progresiva a medida que se reciben, hasta el límite de inspección configurado, las reglas se pueden evaluar en función de datos del cuerpo incompletos. Para evitar posibles falsos positivos o resultados incompletos, escribe reglas que coincidan con la existencia de datos en lugar de su ausencia. Para obtener más información, consulta Limitación de inspección del cuerpo de la solicitud.

Visualiza las subexpresiones coincidentes en los registros

Cuando solucionas problemas con las reglas, puedes habilitar el registro detallado configurando el indicador --log-level en VERBOSE y usar Cloud Logging para ver qué subexpresiones de una regla coincidieron. Si una regla contiene varias subexpresiones, Cloud Armor solo registra detalles sobre la subexpresión que coincidió más recientemente.

La siguiente expresión de ejemplo contiene dos subexpresiones:

request.url.contains('__') && request.body.contains('abc')

Si envías una solicitud POST con el cuerpo abc a la URL example.com/etc/pass__word, la expresión coincide. Debido a que las subexpresiones se evalúan de izquierda a derecha, la request.body.contains('abc') subexpresión se evalúa en último lugar. El siguiente fragmento de registro muestra los detalles de la subexpresión request.body que coincide:

jsonPayload: {
  [...]
  enforcedSecurityPolicy: {
    [...]
    matchedFieldType: "request.body",
    matchedFieldName: "request.body",
    matchedFieldValue: "abc",
    matchedFieldLength: 3,
    matchedOffset: 0,
    matchedLength: 3,
  }
  [..*]
}

Problemas con el límite de frecuencia

En esta sección, encontrarás ayuda para solucionar problemas frecuentes con el límite de frecuencia.

El tráfico no está limitado como se espera

Es posible que una dirección IP de cliente envíe altos niveles de tráfico a una aplicación a una velocidad superior al límite que estableciste, pero el tráfico no se regula como esperas. Sigue estos pasos para investigar el problema.

Primero, confirma si una regla de mayor prioridad permite el tráfico desde esa dirección IP. Analiza los registros a fin de ver si se activó una regla ALLOW para la dirección IP. Puede ser una regla ALLOW por sí sola, o bien en otra regla THROTTLE o RATE_BASED_BAN.

Si encuentras una regla de mayor prioridad, realiza una de las siguientes acciones:

  1. Cambia las prioridades para asegurarte de que la regla de límite de frecuencia tenga una prioridad más alta mediante la asignación de un valor numérico más bajo.
  2. Excluye la dirección IP de la expresión coincidente en la regla que tiene mayor prioridad.

El problema también puede deberse a que el umbral se estableció de forma incorrecta. Si este es el caso, las solicitudes coinciden de forma precisa, pero se activa la acción de cumplimiento. Examina los registros para confirmar que este sea el caso y, luego, reduce el umbral de tu regla.

Por último, es posible que la dirección IP no coincida con la regla de bloqueo basada en la velocidad o el regulador. Para solucionar este problema, verifica si hay un error en la condición de coincidencia y, luego, cambia la condición de coincidencia de la regla al valor correcto.

¿Qué sigue?