Es posible que parte o toda la información de esta página no se aplique a Trusted Cloud by S3NS. Para obtener más información, consulta las diferencias con Google Cloud.

Esta página se ha traducido con Cloud Translation API.

Solucionar problemas de Cloud Armor

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

Incidencias generales

Depurar políticas de seguridad

Si necesitas más información sobre qué evento concreto activa las reglas preconfiguradas, consulta Usar el registro de solicitudes y, a continuación, habilita el registro detallado. Cloud Logging registra un mayor nivel de detalle en tus registros, que puedes usar para analizar y depurar tus políticas y reglas.

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

Para solucionar este problema, sigue estos pasos:

Asegúrate de que la política de seguridad de Cloud Armor esté asociada a un servicio de backend de destino. Por ejemplo, el siguiente comando describe todos los datos asociados al servicio backend BACKEND. Los resultados devueltos deben incluir el nombre de la política de seguridad de Cloud Armor asociada a este servicio de backend.
```
gcloud compute backend-services describe BACKEND
```

Revisa los registros HTTP(S) para determinar qué política y regla se han aplicado a tu tráfico, así como la acción asociada. Para ver los registros, usa Cloud Logging.

A continuación, se muestra un registro de ejemplo de una solicitud permitida con los campos de interés destacados. Comprueba los siguientes campos y asegúrate de que coincidan con la regla que has configurado 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 asociada 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'

Revisa la jerarquía de las reglas para asegurarte de que se aplica la regla correcta. Es posible que una regla de mayor prioridad con una acción de permitir coincida con tu tráfico. Usa el comando describe en la security-policies de la CLI de Google Cloud para ver el contenido de la política de seguridad de Cloud Armor.

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

gcloud compute security-policies describe POLICY_NAME

Resultado:

  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

Una regla preconfigurada devuelve 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 expresiones regulares son propensos a los falsos positivos. Puede usar la regla preconfigurada para la detección de XSS y SQLi en el modo de vista previa y, a continuación, consultar el registro para ver si hay falsos positivos.

Si detecta un falso positivo, puede comparar el contenido del tráfico con las reglas de OWASP CRS. Si la regla no es válida o no es pertinente, 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 eliminar todos los falsos positivos, inhabilita el modo de vista previa.

Para añadir una regla preconfigurada en el modo de vista previa, sigue estos pasos:

Crea una política de seguridad con el conjunto de expresiones preconfigurado 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

Consulta los registros HTTP(S) para ver los campos de solicitud HTTP, como url y cookie. Por ejemplo, requestUrl se compara positivamente 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-v030001-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'

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-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

Vuelve a revisar los registros y, a continuación, 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, solo se aplican políticas de seguridad en el caso de las solicitudes de contenido dinámico, de datos que no están en caché o de otras solicitudes dirigidas al servidor CDN de origen. Los resultados en caché se sirven, incluso aunque la política de seguridad de Cloud Armor de bajada deba evitar que la solicitud llegue al servidor CDN de origen.

Problemas con la limitación de frecuencia

El tráfico no se limita como se esperaba

Puede que detecte que una dirección IP de cliente está enviando grandes cantidades de tráfico a una aplicación a una velocidad que supera el umbral que ha definido, pero el tráfico no se limita como esperaba. Sigue estos pasos para investigar el problema.

Primero, comprueba si una regla de mayor prioridad permite el tráfico de esa dirección IP. Examina los registros para ver si se ha activado una regla de ALLOW para la dirección IP. Puede ser una regla ALLOW por sí sola o en otra regla THROTTLE o RATE_BASED_BAN.

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

Cambia las prioridades para asegurarte de que la regla de limitación de frecuencia tenga una prioridad mayor asignándole un valor numérico inferior.
Excluye la dirección IP de la expresión coincidente en la regla que tenga una prioridad más alta.

También puede que el umbral no esté configurado correctamente. Si es así, las solicitudes se asocian correctamente, pero se activa la acción de conformidad. Examina los registros para confirmar que este es el caso y, a continuación, reduce el umbral de tu regla.

Por último, es posible que la dirección IP no coincida con la regla de limitación o de prohibición basada en la frecuencia. Para solucionarlo, comprueba si hay algún error en la condición de coincidencia y, a continuación, cambia la condición de coincidencia de la regla por el valor correcto.

Siguientes pasos

Obtener asistencia