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:
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
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:
configuredActiondebe coincidir con la acción configurada en la regla.namedebe coincidir con el nombre de la política de seguridad de Google Cloud Armor que se vinculó a este servicio de backend.outcomedebe coincidir conconfiguredAction.prioritydebe 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
describeensecurity-policiesen Google Cloud CLI 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:
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 --previewRevisa los registros de HTTP(S) en busca de campos de la solicitud HTTP como
urlycookie. Por ejemplo,requestUrlse 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'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 \ --previewVuelve 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.
Mitiga el riesgo en el cuerpo de POST que supere los 8 KB cuando uses reglas de WAF preconfiguradas
Cuando se evalúa una regla de WAF preconfigurada en una política de seguridad de Google Cloud Armor, se inspeccionan hasta 8 KB del cuerpo de POST en busca de coincidencias de firma con las reglas de WAF. Este enfoque te proporciona inspección y protección de la capa 7 de baja latencia, mientras mantienes la disponibilidad para otros clientes de Google.
Puedes mitigar el riesgo de solicitudes POST más grandes si creas una regla en las políticas de seguridad para asegurarte de que el contenido no inspeccionado llegue a los backends. Crea una regla para denegar el tráfico que supere los 8 KB (8192 bytes) de tamaño del cuerpo de POST. En el siguiente ejemplo de código, se muestra cómo crear esta regla:
gcloud compute security-policies rules create 10 \
--security-policy my-policy \
--expression "int(request.headers['content-length']) > 8192" \
--action deny-403 \
--description "Block requests great than 8KB"
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-example')" \
--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-example\u0027)"}'.
Error parsing Google Cloud Armor rule matcher expression: sourceiplist-example
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.
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.
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.
Asegúrate de que la política de seguridad esté adjunta al servicio de backend correcto:
gcloud compute backend-services describe BACKEND_SERVICE
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 altostrat referer kind: compute#securityPolicyRule match: expr: expression: request.headers['Referer'].contains('altostrat') 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
altostrat. También se enumeran sus respectivas prioridades.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 Usa el Explorador de registros.
A continuación, se muestra un ejemplo de un registro:
httpRequest: { referer: "http://www.altostrat.com/" remoteIp: "23.230.32.10" requestMethod: "HEAD" requestSize: "79" requestUrl: "http://www.example.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 contienealtostrat. Debido a que la solicitud tiene un referente dehttp://www.altostrat.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 el posible ataque disminuye y los patrones de tráfico vuelven al modelo de referencia original, ya sea porque el ataque concluyó o lo bloqueó con las reglas de Google Cloud Armor adecuadas, Adaptive Protection alerta sobre comportamientos de tráfico futuros que considera las 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 la política de seguridad con la acción de redireccionamiento de una evaluación de reCAPTCHA y descubres que algunos usuarios que crees que legítimas no se eximieron 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. Por lo tanto, se esperan al menos dos entradas de registro.
- Si ves
GOOGLE_RECAPTCHAcomo la acción configurada yREDIRECTcomo la acción Resultado, la solicitud se redireccionó para una evaluación de reCAPTCHA. - Si ves
GOOGLE_RECAPTCHAcomo la acción configurada yACCEPTcomo la acción resultado, la solicitud estuvo exenta de ser redireccionada por evaluación de reCAPTCHA. - 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.
- El usuario debe usar un navegador.
- El navegador debe habilitar JavaScript para permitir que el redireccionamiento se cargue correctamente. con reCAPTCHA JavaScript incorporado.
- El navegador debe habilitar las cookies para permitir la configuración y la conexión automática de la cookie de exención.
- El usuario debe aprobar la evaluación de reCAPTCHA. por ejemplo, debe resolver los 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 coincida.
En tercer lugar, la evaluación de reCAPTCHA solo se ejecuta cuando el redireccionamiento que incorpora reCAPTCHA de JavaScript. Para eso el redireccionamiento a la evaluación de reCAPTCHA solo es aplicable para las solicitudes que esperan una respuesta que conduzca a la renderización de la página completa. Otra opción solicitudes, tales como la carga de recursos en una página, o solicitudes derivadas de una una secuencia de comandos incorporada que no espera que se renderice la respuesta, no se espera para obtener una evaluación de reCAPTCHA. 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 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 cambio, puedes aplicar la acción de redireccionamiento para Evaluación de reCAPTCHA para las rutas de URL que alojan páginas web, como la la página web principal u otras páginas web vinculadas.
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 puedes comunicarte con el equipo de Asistencia de Cloud equipo.
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.