Es posible que parte o toda la información de esta página no se aplique a Trusted Cloud de S3NS.

Se usó la API de Cloud Translation para traducir esta página.

Soluciona problemas de Cloud Armor

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

Problemas generales

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:

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
```

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'

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

Salida:

  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 L7. 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 la regla es no es válida o no es relevante, inhabilítala mediante 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:

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

Revisa los registros de HTTP(S) en busca de campos de la solicitud HTTP como url y cookie. Por ejemplo, la requestUrl se compara de forma positiva con el ID 941180 de la regla 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-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 941180 de la regla 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-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

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 solo se aplican a las solicitudes de contenido dinámico, errores de caché o cualquier otra solicitud que esté destinada al servidor de origen de CDN. Los aciertos de caché se entregan incluso si la política de seguridad descendente de Cloud Armor impide que esa solicitud llegue al servidor de origen de CDN.

Problemas 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:

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.
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?

Obtén asistencia