Soluciona problemas de Google 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 Google Cloud Armor

Para solucionar esto, sigue estos pasos:

  1. Asegúrate de que la política de seguridad de Google 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 Google Cloud Armor asociada con este servicio de backend.

    gcloud compute backend-services describe 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 Google 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'
    
  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 la herramienta de línea de comandos de gcloud para ver el contenido de la política de seguridad de Google 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 ModSecurity. Si la regla es no es válida o no es relevante, inhabilítala mediante la expresión evaluatePreconfiguredExpr 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 "evaluatePreconfiguredExpr('xss-stable')"
       --action deny-403
       --preview
    
  2. Revisa los registros de HTTP(S) en busca de campos de la solicitud HTTP como url y cookie. Por ejemplo, requestUrl se compara positivamente con el ID 941180 de la regla de ModSecurity 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'
    
  3. Excluye el ID 941180 de la regla de CRS de ModSecurity mediante la actualización de la regla en la política de seguridad de Google Cloud Armor.

    gcloud compute security-policies rules update 1000 \
        --security-policy POLICY_NAME \
        --expression "evaluatePreconfiguredExpr('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
        --action deny-403 \
        --preview
    
  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 Google 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 posterior de Google Cloud Armor impide que esa solicitud llegue al servidor de origen de CDN.

Problemas con las listas de direcciones IP con nombre

En esta sección, se proporciona información sobre cómo resolver problemas con las listas de direcciones IP con nombre.

Direcciones IP dentro de una lista de direcciones IP con nombre

Las direcciones IP de las listas siempre coinciden con las direcciones IP de los sitios web del proveedor que se enumeran en la guía de las Listas de direcciones IP con nombre de Google Cloud Armor. Si tienes preguntas sobre las listas, comunícate con el equipo de asistencia de Cloud.

Las direcciones IP dentro de una lista de direcciones IP con nombre están inactivas en Google Cloud Armor

Google Cloud Armor sincroniza sus listas a diario con los proveedores de listas de direcciones IP. Es posible que haya datos inactivos que tienen un retraso de unas horas o un día en relación con los datos en un proveedor. Sin embargo, si crees que los datos inactivos se retrasan más de lo previsto, por ejemplo, durante más de una semana, comunícate con el equipo de asistencia de Cloud.

Hay dificultad para crear una política de seguridad que haga referencia a una lista de direcciones IP con nombre

Puedes tratar de crear una política de seguridad que haga referencia a una lista de direcciones IP con nombre, mediante un comando como este:

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-abc')" \
    --action "allow"

Si el comando falla, el error que observas se verá así:

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-abc\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-abc
is not a valid preconfigured expression set.

Asegúrate de que el proveedor determinado sea compatible y que se proporcione el nombre correcto de la lista de direcciones IP. Para verificar esto, usa el siguiente comando de gcloud a fin de enumerar los conjuntos de expresiones preconfigurados actuales:

gcloud compute security-policies list-preconfigured-expression-sets

El tráfico se bloquea a pesar de tener una regla preconfigurada para una lista de direcciones IP permitidas con nombre

Es posible que se haya bloqueado el tráfico de una dirección IP que está incluida en una lista de direcciones IP con nombre.

  1. Asegúrate de que el tráfico provenga de una dirección IP que está incluida en una lista de direcciones IP permitidas con nombre.

  2. Verifica si hay otras reglas de seguridad con una prioridad más alta que puedan bloquear el tráfico. Si aún ves el problema, comunícate con el equipo de asistencia al cliente de Cloud.

  3. Asegúrate de que la política de seguridad esté adjunta al servicio de backend correcto:

    gcloud compute backend-services describe BACKEND_SERVICE
    
  4. Verifica las reglas que se encuentran en la política de seguridad. Por ejemplo:

     gcloud compute security-policies describe POLICY_NAME
    

    El comando muestra información similar a la siguiente:

    ---
    …
    name: POLICY_NAME
    rules:
    -action: allow
     description: allow fastly ip addresses
     kind: compute#securityPolicyRule
     match:
        expr:
          expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
     preview: false
     priority: 100
    -action: deny(403)
     description: Default rule, higher priority overrides it
     kind: compute#securityPolicyRule
     match:
        config:
          srcIpRanges:
          -'*'
        versionedExpr: SRC_IPS_V1
     preview: false
     priority: 2147483647
    -action: deny(404)
     description: deny xyz referer
     kind: compute#securityPolicyRule
     match:
        expr:
          expression: request.headers['Referer'].contains('xyz')
     preview: false
     priority: 50
    …
    

    La política de seguridad anterior contiene tres reglas: una regla de rechazo predeterminada, una regla de permiso para las direcciones IP de Fastly y otra de rechazo para una referencia que contiene xyz. También se enumeran sus respectivas prioridades.

  5. Revisa los registros para determinar qué regla coincide con tu tráfico y con la acción asociada. Para obtener información sobre el registro, consulta Visualiza los registros en el visor de registros heredados de la API de Cloud Logging.

    A continuación, se muestra un ejemplo de un registro:

     httpRequest: {
        referer: "http://www.xyz.com/"
        remoteIp: "23.230.32.10"
        requestMethod: "HEAD"
        requestSize: "79"
        requestUrl: "http://www.abc.com/"
        responseSize: "258"
        status: 404
        userAgent: "Mozilla/5.0"
      }
      …
      jsonPayload: {
        @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
        enforcedSecurityPolicy: {
          configuredAction: "DENY"
          name: "POLICY_NAME"
          outcome: "DENY"
          priority: 50
        }
        statusDetails: "denied_by_security_policy"
      }
      …
    

    En el registro anterior, la solicitud proviene de 23.230.32.10, que está cubierto por la lista de direcciones IP públicas de Fastly. Sin embargo, la solicitud coincide con una regla de denegación que tiene una prioridad más alta, con un valor de 50. En comparación con el contenido de la política de seguridad, la regla corresponde a la regla de denegación de un referente que contiene xyz. Debido a que la solicitud tiene un referente de http://www.xyz.com/, la aplicación de la regla de seguridad funciona de forma adecuada.

Problemas con los hallazgos de Security Command Center

En esta sección, se brinda información sobre los problemas con los hallazgos de Security Command Center.

La tarjeta de Google Cloud Armor no aparece en Security Command Center

Habilita los hallazgos de Google Cloud Armor en la interfaz de Security Command Center.

Los resultados de Google Cloud Armor no aparecen en Security Command Center.

Si los resultados de Google Cloud Armor no aparecen en Security Command Center, es posible que el tráfico a los servicios de backend no cumpla con los criterios para generar un resultado.

Si tienes preguntas sobre el volumen de tráfico a tus backends, verifica las estadísticas de las solicitudes en los paneles de Cloud Monitoring en Políticas de seguridad de red.

Los hallazgos contienen demasiada información irrelevante

Para obtener ayuda con este problema, comunícate con el equipo de asistencia al cliente de Cloud.

Problemas con la Protección adaptable de Google Cloud Armor

Usa estas instrucciones para resolver problemas relacionados con la Protección adaptable.

La Protección adaptable está habilitada para una política de seguridad, pero no hay registros en Cloud Logging

Los registros de protección adaptable se generan por separado de los registros de solicitud de Google Cloud Armor y aparecen bajo un recurso diferente en Cloud Logging. Los registros y eventos de la Protección adaptable están disponibles en el recurso Política de seguridad de red en Cloud Logging. Existe un período de entrenamiento de al menos una hora después de que se habilita la Protección adaptable en una política de seguridad antes de que esta función comience a generar alertas de ataques sospechosos. Durante el período de entrenamiento, la Protección adaptable aprende del tráfico de solicitudes entrantes y desarrolla modelos de referencia distintos para cada servicio de backend protegido por esa política de seguridad. Luego, la Protección adaptable puede identificar actividades sospechosas.

Si habilitas la Protección adaptable para una política de seguridad y no observas ninguna alerta luego de un período de entrenamiento de una hora, esto sugiere que no hay actividad que se pueda identificar como una orientación potencialmente maliciosa de cualquiera de los siguientes servicios de backend asociados a esa política de seguridad.

Si el ataque o tráfico anómalo potencial persiste durante períodos más largos de tiempo y se extiende por varias horas, la Protección adaptable comienza a considerar ese comportamiento como comportamiento de referencia y no sigue alertando sobre patrones de tráfico similares. Una vez que las posibles vulnerabilidades de ataque y los patrones de tráfico vuelven al modelo de referencia original, ya sea porque el ataque concluyó o los bloqueaste con las reglas apropiadas de Google Cloud Armor, la Protección adaptable envía una alerta sobre los comportamientos de tráfico futuros que se consideren salidas del modelo de referencia.

La Protección adaptable analiza el tráfico que, de lo contrario, se permitiría mediante una política de seguridad de Google Cloud Armor. Si configuras la regla predeterminada para denegar el acceso con una lista de permisos de tráfico restringido, entonces, la Protección adaptable solo detecta actividad maliciosa en el tráfico que pasa la evaluación con respecto a la lista de permiso.

Hay demasiadas alertas o demasiados registros en Cloud Logging desde la Protección adaptable

Una alerta de protección adaptable proporciona una puntuación de confianza que indica cómo los modelos de Protección adaptables identifican de forma sólida la actividad detectada como anómala y un ataque potencial. Puedes filtrar en la entrada específica del registro a través de Cloud Logging para que solo aparezca (o reenvíe) las alertas que tienen una puntuación de confianza por encima de un límite determinado.

La Protección adaptable proporciona un mecanismo para informar alertas como falsos positivos, que se describen en la sección Supervisión, comentarios y errores de los eventos. Ten en cuenta que es posible que el informe de falsos positivos no genere cambios inmediatos en las alertas de la Protección adaptable. Con el tiempo, los modelos de Protección adaptable aprenden que esos patrones de tráfico son normales y aceptables, y detienen las alertas sobre estos patrones.

Si las alertas de la Protección adaptativa son demasiado frecuentes en un subconjunto de servicios de backend, en una política de seguridad, esto podría sugerir que el tráfico normal de estos servicios tiene fluctuaciones significativas que la Protección adaptable identificó de manera sistemática como comportamientos anómalos. Puedes crear una política de seguridad independiente sin la Protección adaptable habilitada y asociar estos servicios de backend con la política de seguridad nueva.

Un incidente en particular informado por la Protección adaptable se considera un falso positivo o no es relevante

La Protección adaptable proporciona un mecanismo para informar alertas de falsos positivos. Sigue el procedimiento que se describe en la sección Supervisión, comentarios y errores de los eventos. Ten en cuenta que es posible que el informe de falsos positivos no genere cambios inmediatos en las alertas de la Protección adaptable. Con el tiempo, los modelos de Protección adaptable aprenden que esos patrones de tráfico son normales y aceptables, y detienen las alertas sobre estos patrones.

¿Cómo sé que se aplican mis políticas de seguridad perimetral?

Para verificar las acciones realizadas en las políticas de seguridad perimetral, verifica los paneles de supervisión, las métricas de supervisión o el registro por solicitud.

Paneles de supervisión

Cloud Monitoring está disponible en la página Políticas de seguridad de red en Monitoring. Puedes usar el desglose por política de seguridad en la página para medir la cantidad de solicitudes permitidas y denegadas por la política de seguridad perimetral configurada. También puedes examinar el desglose por servicio de backend para depurar un servicio de backend en particular. Para obtener detalles sobre el panel de Cloud Monitoring, consulta Supervisa las políticas de seguridad de Google Cloud Armor.

Métricas de supervisión

Las métricas sin procesar que miden las solicitudes permitidas y rechazadas están disponibles para las políticas de seguridad perimetral. Si deseas obtener más información, consulta Supervisa métricas para las políticas de seguridad.

Registro por solicitud

La decisión de la política de seguridad perimetral se registra en los registros de solicitud de balanceo de cargas en enforcedEdgeSecurityPolicy. Esto es independiente de enforcedSecurityPolicy, que captura la decisión de la política de seguridad de backend.

Administración de bots

Esta sección contiene información para solucionar problemas relacionados con la administración de bots.

Los usuarios no están exentos como se esperaba

Es posible que hayas configurado reglas de política de seguridad con la acción de redireccionamiento para la evaluación de reCAPTCHA Enterprise y descubriste que algunos usuarios que consideras legítimos no están exentos como se esperaba. Sigue los pasos que se indican a continuación para solucionar problemas.

En primer lugar, revisa los registros por solicitud para ver si hay una regla de política de seguridad con una prioridad más alta que coincida con el tráfico, en la que la acción sea diferente. En particular, busca los campos configured_action y outcome. Ten en cuenta que, para que un usuario esté exento, se deben incluir, al menos, dos solicitudes. La solicitud inicial viene sin una cookie de exención y las solicitudes siguientes vienen con una cookie de exención si el usuario pasa la evaluación de reCAPTCHA Enterprise. Por lo tanto, se esperan al menos dos entradas de registro.

  • Si ves GOOGLE_RECAPTCHA como la acción configurada y REDIRECT como el resultado, la solicitud se redireccionó para la evaluación de reCAPTCHA Enterprise.
  • Si ves GOOGLE_RECAPTCHA como la acción configurada y ACCEPT como el resultado, la solicitud estaba exenta de redireccionarse para la evaluación de reCAPTCHA Enterprise.
  • Si ves valores diferentes en los campos anteriores, se detectó una coincidencia con una regla que tiene una acción diferente. En ese caso, se espera que el usuario no se redireccione ni esté exento.

En segundo lugar, existen varios requisitos para que el usuario se exima de la redirección a la evaluación de reCAPTCHA Enterprise.

  1. El usuario debe usar un navegador.
  2. El navegador debe habilitar JavaScript para permitir la carga adecuada de la página de redireccionamiento con JavaScript de reCAPTCHA Enterprise incorporado.
  3. El navegador debe habilitar las cookies para permitir la configuración y la conexión automática de la cookie de exención.
  4. El usuario debe pasar la evaluación de reCAPTCHA Enterprise. Por ejemplo, debe resolver desafíos emergentes si los hay.

Se espera que los usuarios que no puedan cumplir con ninguno de los requisitos anteriores no reciban la exención, aunque una regla con la acción de redireccionamiento para la evaluación de reCAPTCHA Enterprise coincida.

Por último, la evaluación de reCAPTCHA Enterprise solo se ejecuta cuando se renderiza la página de redireccionamiento que incorpora JavaScript de reCAPTCHA Enterprise. Por ese motivo, el redireccionamiento para la evaluación de reCAPTCHA Enterprise solo se aplica a las solicitudes que esperan una respuesta que conduzca a una renderización completa de la página. No se espera que otras solicitudes, como la carga de elementos dentro de una página o las solicitudes derivadas de una secuencia de comandos incorporada que no esperan la respuesta para renderizarse, obtengan la evaluación de reCAPTCHA Enterprise. Por lo tanto, te recomendamos que apliques esta acción con una condición de coincidencia para las rutas de URL que cumplan con esta condición.

Por ejemplo, supón que tienes una página web que contiene elementos incorporados, como imágenes, vínculos a otras páginas web y secuencias de comandos. No recomendamos aplicar la acción de redireccionamiento para la evaluación de reCAPTCHA Enterprise destinada a rutas de URL que alojan imágenes o a las que se debe acceder mediante secuencias de comandos en las que no se espera una renderización completa de la página. En su lugar, puedes aplicar la acción de redireccionamiento para la evaluación de reCAPTCHA Enterprise destinada a rutas de URL que alojan páginas web, como la página principal o cualquier otra página web vinculada.

Por último, si la página de redireccionamiento se renderiza correctamente, consulta la herramienta para desarrolladores que proporciona el navegador a fin de ver si se configuró una cookie de exención y si está adjunta en las solicitudes subsiguientes del mismo sitio. Para obtener más ayuda, puedes comunicarte con el equipo de Asistencia de Cloud.

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:

  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?