Soluciona problemas de Cloud Armor

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

Problemas generales

En esta sección, se abordan los problemas comunes que se encuentran 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.

Identifica y correlaciona las solicitudes bloqueadas en los registros

Cuando Google Cloud Armor bloquea una solicitud en un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico, puedes devolver un ID de seguimiento único al cliente configurando un encabezado de respuesta personalizado que use la variable {cloud_trace_id}. Luego, puedes usar este ID de seguimiento para encontrar la entrada de registro en Logging y determinar por qué se bloqueó la solicitud.

Para exponer el ID de seguimiento y encontrar una solicitud bloqueada en Logging, sigue estos pasos:

  1. Configura un encabezado de respuesta personalizado con la variable {cloud_trace_id} en tu servicio de backend. Por ejemplo, con el siguiente comando, se agrega un encabezado de respuesta X-Cloud-Trace-Id al servicio de backend BACKEND_SERVICE_NAME:

    gcloud compute backend-services update BACKEND_SERVICE_NAME \
   --global \
   --custom-response-header='X-Cloud-Trace-Id:{cloud_trace_id}'

    Reemplaza BACKEND_SERVICE_NAME por el nombre de tu servicio de backend.

    Para obtener más información, consulta Configura encabezados de respuesta personalizados.

  2. Cuando una política de seguridad de Google Cloud Armor rechaza una solicitud, inspecciona los encabezados de respuesta HTTP que se devuelven al cliente para obtener el valor hexadecimal de 32 caracteres del encabezado X-Cloud-Trace-Id.

  3. En la página Explorador de registros, consulta el campo trace con el ID de seguimiento del encabezado de respuesta para encontrar la entrada de registro coincidente:

    resource.type="http_load_balancer"
trace="projects/PROJECT_ID/traces/TRACE_ID"

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID del proyecto que contiene la regla de reenvío y el mapa de URLs del balanceador de cargas
    • TRACE_ID: el ID de seguimiento hexadecimal de 32 caracteres que se muestra en el encabezado de respuesta personalizado

Se permite el tráfico a pesar de que se configuró 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é conectada 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. Los resultados que se devuelvan deben 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 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 adjunta 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 del 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 lo siguiente:

    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 las solicitudes HTTP y otros parámetros de la 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, la regla requestUrl se compara de forma positiva con el ID de regla 941180 de OWASP CRS:

    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 OWASP CRS 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.

No se bloquean ni rechazan los clientes con firmas rechazadas

Si usas Cloud Armor con Cloud CDN, las políticas de seguridad se aplican solo a las solicitudes de contenido dinámico, errores de caché y otras solicitudes que estén destinados al servidor de origen de CDN. Los aciertos de caché se entregan incluso si la política de seguridad posterior 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 con 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 de reglas, puedes habilitar el registro detallado estableciendo la marca --log-level en VERBOSE y usando 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 subexpresión request.body.contains('abc') se evalúa en último lugar. En el siguiente extracto de registro, se muestran 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, se proporcionan instrucciones para solucionar problemas habituales relacionados con la límite de frecuencia.

El tráfico no se limita 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?