1. Introducción
¡Hola! Te damos la bienvenida al codelab sobre las reglas de WAF preconfiguradas de Cloud Armor.
Google Cloud Armor es la solución de seguridad de red perimetral empresarial de Google que proporciona protección contra DDoS, aplicación de reglas de WAF y capacidad de administración adaptable a gran escala.
Cloud Armor extendió los conjuntos de reglas de WAF preconfiguradas para mitigar las vulnerabilidades de seguridad de aplicaciones web que figuran en la lista OWASP Top 10. Los conjuntos de reglas se basan en la versión 3.0.2 del conjunto de reglas principales para usar con Modsecurity de OWASP y tienen como fin proteger contra algunos de los riesgos de seguridad de aplicaciones web más comunes, entre los que se encuentran la inclusión de archivos locales (LFI), la inclusión de archivos remotos (RFI), la ejecución de código remoto (RCE) y muchos más.
En este codelab, aprenderás a mitigar algunas de las vulnerabilidades comunes con las reglas de WAF de Google Cloud Armor.
Qué aprenderás
- Cómo configurar un grupo de instancias y un balanceador de cargas global para admitir un servicio
- Cómo configurar políticas de seguridad de Cloud Armor con reglas de WAF preconfiguradas para proteger contra LFI, RCE, escáneres, ataques de protocolo y fijación de sesión
- Cómo validar que Cloud Armor mitigó un ataque observando los registros
Requisitos
- Conocimientos básicos de Google Compute Engine ( codelab)
- Conocimiento básico de redes y TCP/IP
- Conocimiento básico de la línea de comandos de Unix/Linux
- Es útil haber completado un recorrido por las redes en GCP con Networking in Google Cloud.
- (Opcional) Completa el lab de Cloud Armor de Cloudnet20 para aprender a proteger cargas de trabajo con reglas basadas en IP, en la ubicación geográfica y en la inyección de SQL.
Topología y caso de uso del codelab
Figura 1: Topología del codelab de reglas de WAF de Cloud Armor
La aplicación OWASP Juice Shop es útil para el entrenamiento y el conocimiento de la seguridad, ya que contiene en su diseño instancias de cada una de las vulnerabilidades de seguridad del documento OWASP Top 10. Un atacante puede aprovecharla para realizar pruebas. En este codelab, la usaremos para demostrar algunos ataques a aplicaciones y luego proteger la aplicación con reglas de WAF de Cloud Armor. La aplicación será frontend con un balanceador de cargas de Google Cloud, al que se aplicarán la política y las reglas de seguridad de Cloud Armor. Se entregará en Internet pública, por lo que se podrá acceder a ella desde casi cualquier lugar y estará protegida con Cloud Armor y reglas de firewall de VPC.
2. Configuración y requisitos
Configuración del entorno de autoaprendizaje
- Accede a la consola de Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
Recuerde el ID de proyecto, un nombre único en todos los proyectos de Google Cloud (el nombre anterior ya se encuentra en uso y no lo podrá usar). Se mencionará más adelante en este codelab como PROJECT_ID.
- A continuación, deberás habilitar la facturación en la consola de Cloud para usar los recursos de Google Cloud recursos.
Ejecutar este codelab no debería costar mucho, tal vez nada. Asegúrate de seguir las instrucciones de la sección “Realiza una limpieza”, en la que se aconseja cómo cerrar recursos para que no se te facture más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.
Inicia Cloud Shell
Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:
El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:
Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.
Antes de comenzar
En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
Habilita las APIs
Habilita todos los servicios necesarios
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. Crea la red de VPC
Crear red de VPC
Desde Cloud Shell
gcloud compute networks create ca-lab-vpc --subnet-mode custom
Salida
Created NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4 ca-lab-vpc CUSTOM REGIONAL
Crear una subred
Desde Cloud Shell
gcloud compute networks subnets create ca-lab-subnet \
--network ca-lab-vpc --range 10.0.0.0/24 --region us-central1
Salida
Created NAME REGION NETWORK RANGE ca-lab-subnet us-central1 ca-lab-vpc 10.0.0.0/24
Crea reglas de firewall de VPC
Después de crear la VPC y la subred, ahora configurarás algunas reglas de firewall. La primera regla de firewall se usará para permitir que todas las IPs accedan a la IP externa del sitio web de la aplicación de prueba en el puerto 3000. La segunda regla de firewall se usará para permitir las verificaciones de estado desde la IP de origen de los balanceadores de cargas.
Desde Cloud Shell
gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc
Salida
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-js-site ca-lab-vpc INGRESS 1000 tcp:3000 False
Crea reglas de FW para permitir las verificaciones de estado de los rangos de verificación de estado de Google.
Desde Cloud Shell
gcloud compute firewall-rules create allow-health-check \
--network=ca-lab-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=allow-healthcheck \
--rules=tcp
Salida
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-health-check ca-lab-vpc INGRESS 1000 tcp False
4. Configura la aplicación de prueba
El siguiente paso es crear la aplicación de prueba, en este caso, el servidor web OWASP Juice Shop.
Cuando creamos la instancia de procesamiento, usamos una imagen de contenedor para garantizar que el servidor tenga los servicios adecuados. Este servidor se implementará en us-central1-c y tendrá una etiqueta de red que permitirá las verificaciones de estado.
Crea la aplicación OWASP Juice Shop
Usa la aplicación de código abierto OWASP Juice Shop ya conocida como la aplicación vulnerable. También puedes usar esta aplicación para realizar desafíos de seguridad de OWASP a través de su sitio web.
Desde Cloud Shell
gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
--network ca-lab-vpc \
--subnet ca-lab-subnet \
--private-network-ip=10.0.0.3 \
--machine-type n1-standard-2 \
--zone us-central1-c \
--tags allow-healthcheck
Salida
NAME ZONE MACHINE_TYPE PREEMPTIBLE owasp-juice-shop-app us-central1-c n1-standard-2 INTERNAL_IP EXTERNAL_IP STATUS 10.0.0.3 <public IP> RUNNING
Configura el componente del balanceador de cargas de Cloud: grupo de instancias
Crea el grupo de instancias no administrado.
Desde Cloud Shell
gcloud compute instance-groups unmanaged create juice-shop-group \
--zone=us-central1-c
Salida
NAME LOCATION SCOPE NETWORK MANAGED INSTANCES juice-shop-group us-central1-c zone 0
Agrega la instancia de GCE de Juice Shop al grupo de instancias no administrado.
Desde Cloud Shell
gcloud compute instance-groups unmanaged add-instances juice-shop-group \
--zone=us-central1-c \
--instances=owasp-juice-shop-app
Salida
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Establece el puerto con nombre en el de la aplicación Juice Shop.
Desde Cloud Shell
gcloud compute instance-groups unmanaged set-named-ports \ juice-shop-group \ --named-ports=http:3000 \ --zone=us-central1-c
Salida
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Ahora que creaste el grupo de instancias no administrado, el siguiente paso es crear una verificación de estado, un servicio de backend, un mapa de URL, un proxy de destino y una regla de reenvío.
Configura el componente del balanceador de cargas de Cloud: verificación de estado
Crea la verificación de estado para el puerto de servicio de Juice Shop.
Desde Cloud Shell
gcloud compute health-checks create tcp tcp-port-3000 \
--port 3000
Salida
Created NAME PROTOCOL tcp-port-3000 TCP
Configura el componente del balanceador de cargas de Cloud: servicio de backend
Crea los parámetros del servicio de backend.
Desde Cloud Shell
gcloud compute backend-services create juice-shop-backend \
--protocol HTTP \
--port-name http \
--health-checks tcp-port-3000 \
--enable-logging \
--global
Salida
NAME BACKENDS PROTOCOL juice-shop-backend HTTP
Agrega el grupo de instancias de Juice Shop al servicio de backend.
Desde Cloud Shell
gcloud compute backend-services add-backend juice-shop-backend \
--instance-group=juice-shop-group \
--instance-group-zone=us-central1-c \
--global
Salida
Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].
Configura el componente del balanceador de cargas de Cloud: mapa de URL
Crea el mapa de URL para enviarlo al backend.
Desde Cloud Shell
gcloud compute url-maps create juice-shop-loadbalancer \
--default-service juice-shop-backend
Salida
NAME DEFAULT_SERVICE juice-shop-loadbalancer backendServices/juice-shop-backend
Configura el componente del balanceador de cargas de Cloud: proxy de destino
Crea el proxy de destino para que se encuentre frente al mapa de URL.
Desde Cloud Shell
gcloud compute target-http-proxies create juice-shop-proxy \
--url-map juice-shop-loadbalancer
Salida
NAME URL_MAP juice-shop-proxy juice-shop-loadbalancer
Configura el componente del balanceador de cargas de Cloud: regla de reenvío
Crea la regla de reenvío para el balanceador de cargas.
Desde Cloud Shell
gcloud compute forwarding-rules create juice-shop-rule \
--global \
--target-http-proxy=juice-shop-proxy \
--ports=80
Salida
Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].
Verifica que el servicio Juice Shop esté en línea
Desde Cloud Shell
PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule --global --format="value(IPAddress)")"
Desde Cloud Shell
echo $PUBLIC_SVC_IP
Salida
<public VIP of service>
Espera unos minutos antes de continuar. Si no lo haces, podrías recibir una respuesta HTTP/1.1 404 No encontrado.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP
Salida
HTTP/1.1 200 OK <...>
También puedes ir al navegador para ver Juice Shop.
Ahora puedes explorar las vulnerabilidades de Juice Shop y cómo protegerte de ellas con conjuntos de reglas de WAF de Cloud Armor.
5. Demuestra vulnerabilidades conocidas
Para ahorrar tiempo, demostraremos los estados antes y después de que las reglas de WAF de Cloud Armor se propaguen en pasos condensados.
Observa una vulnerabilidad de LFI: salto de directorio
La inclusión de archivos locales es el proceso de observar los archivos presentes en el servidor explotando la falta de validación de entrada en la solicitud con el fin de exponer potencialmente datos sensibles. A continuación, se muestra que es posible que se produzca un salto de directorio. En tu navegador o con una cURL, observa una ruta existente que haya entregado la aplicación.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp
Salida
HTTP/1.1 200 OK <...>
También observa que el salto de directorio también funciona:
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp/../
Salida
HTTP/1.1 200 OK <...>
Observa una vulnerabilidad de RCE
La ejecución remota de código incluye varias situaciones de inserción de comandos de UNIX y Windows que permiten a los atacantes ejecutar comandos del SO que, por lo general, están restringidos a usuarios con privilegios. A continuación, se muestra cómo pasa una ejecución simple del comando ls.
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Salida
HTTP/1.1 200 OK <...>
Puedes quitar las marcas de cURL para observar el resultado completo.
Observa el acceso de un escáner reconocido
Existen aplicaciones de análisis comerciales y de código abierto que tienen varios propósitos, como encontrar vulnerabilidades. Estas herramientas usan usuarios-agentes y otros encabezados conocidos. Observa que la cURL funciona con un encabezado de usuario-agente conocido:
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Salida
HTTP/1.1 200 OK <...>
Observa un ataque de protocolo: división de HTTP
Algunas aplicaciones web usan la entrada del usuario para generar los encabezados en las respuestas. Si la aplicación no filtra correctamente la entrada, un atacante puede dañar el parámetro de entrada con la secuencia %0d%0a (la secuencia CRLF que se usa para separar diferentes líneas). Cualquier elemento que analice la respuesta, como un servidor proxy intermediario, podría interpretarla como dos respuestas y, potencialmente, entregar contenido falso en solicitudes posteriores. Insertar la secuencia %0d%0a en el parámetro de entrada puede hacer que se muestre una página engañosa.
Desde Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Salida
HTTP/1.1 200 OK <...>
Observa la fijación de sesión
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H session_id=X
Salida
HTTP/1.1 200 OK <...>
6. Define reglas de WAF de Cloud Armor
Enumera las reglas de WAF preconfiguradas:
Desde Cloud Shell
gcloud compute security-policies list-preconfigured-expression-sets
Salida
EXPRESSION_SET
Sqli-canary
RULE_ID
owasp-crs-v030001-id942110-sqli
owasp-crs-v030001-id942120-sqli
<...>
Crea la política de seguridad de Cloud Armor
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies create block-with-modsec-crs \
--description "Block with OWASP ModSecurity CRS"
Actualiza la regla predeterminada de la política de seguridad
Ten en cuenta que la prioridad de la regla predeterminada tiene un valor numérico de 2147483647.
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules update 2147483647 \
--security-policy block-with-modsec-crs \
--action "deny-403"
Dado que la regla predeterminada está configurada con la acción de denegar, debemos permitir el acceso desde tu IP. Encuentra tu IP pública (cURL, ipmonkey, whatismyip, etc.).
En Cloud Shell, ingresa lo siguiente:
MY_IP=$(curl ifconfig.me)
Agrega la primera regla para permitir el acceso desde tu IP (INSERTA TU IP A CONTINUACIÓN)
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 10000 \
--security-policy block-with-modsec-crs \
--description "allow traffic from my IP" \
--src-ip-ranges "$MY_IP/32" \
--action "allow"
Actualiza la política de seguridad para bloquear los ataques de LFI
Aplica el conjunto de reglas principales para usar con ModSecurity de OWASP, que evita el salto de directorio en las inclusiones de archivos locales.
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 9000 \
--security-policy block-with-modsec-crs \
--description "block local file inclusion" \
--expression "evaluatePreconfiguredExpr('lfi-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear la ejecución remota de código (RCE)
En función del conjunto de reglas principales para ModSecurity de OWASP, aplica reglas que buscan RCE, incluida la inyección de comandos. Se detectan y bloquean los comandos típicos del SO.
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 9001 \
--security-policy block-with-modsec-crs \
--description "block rce attacks" \
--expression "evaluatePreconfiguredExpr('rce-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear los escáneres de seguridad
Aplica el conjunto de reglas principal para ModSecurity de OWASP para bloquear escáneres de seguridad conocidos, clientes HTTP de escritura de secuencias de comandos y rastreadores web.
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 9002 \
--security-policy block-with-modsec-crs \
--description "block scanners" \
--expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear los ataques de protocolo
En función del conjunto de reglas principales para ModSecurity de OWASP, aplica reglas que busquen caracteres de retorno de carro (CR) %0d y salto de línea (LF) %0a, y otros tipos de ataques de protocolo, como el contrabando de solicitudes HTTP.
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 9003 \
--security-policy block-with-modsec-crs \
--description "block protocol attacks" \
--expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
--action deny-403
Actualiza la política de seguridad para bloquear la fijación de sesión
En función del conjunto de reglas principales para ModSecurity de OWASP, aplica reglas que…
En Cloud Shell, ingresa lo siguiente:
gcloud compute security-policies rules create 9004 \
--security-policy block-with-modsec-crs \
--description "block session fixation attacks" \
--expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
--action deny-403
Vincula la política de seguridad al servicio de backend
En Cloud Shell, ingresa lo siguiente:
gcloud compute backend-services update juice-shop-backend \
--security-policy block-with-modsec-crs \
--global
Las reglas pueden tardar un tiempo en propagarse (pero no más de 10 minutos). Una vez que tengas la certeza de que transcurrió el tiempo suficiente, prueba las vulnerabilidades que se demostraron anteriormente para confirmar la aplicación de la regla WAF de Cloud Armor en el siguiente paso.
7. Observa la protección de Cloud Armor con el conjunto de reglas principales para ModSecurity de OWASP
Confirma que se haya mitigado la vulnerabilidad de LFI
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?a=../
Salida
HTTP/1.1 403 Forbidden <...>
Confirma que se mitigó el ataque RCE
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Salida
HTTP/1.1 403 Forbidden <..>
Confirma la detección de un escáner conocido
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Salida
HTTP/1.1 403 Forbidden <..>
Confirma que se mitigó un ataque de protocolo
Según la versión 3.0.2 del conjunto de reglas principales para ModSecurity de OWASP, el ataque de protocolo se mitiga de la siguiente manera:
Desde Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Salida
HTTP/1.1 403 Forbidden <..>
Confirma que se bloquearon los intentos de fijación de sesión
Desde Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?session_id=a
Salida
HTTP/1.1 403 Forbidden <..>
8. Revisa las reglas de seguridad de Cloud Armor
Ahora que creamos la política de seguridad, veamos exactamente qué reglas se configuraron.
Las reglas se evalúan por prioridad: se analizan las cifras más bajas en primer lugar y, una vez que se activa una regla, no se continúa el procesamiento de los valores de prioridad más altos.
- Prioridad 9000: Bloquea LFI (inclusión de archivos locales)
- Prioridad 9001: Bloquea RCE (ejecución de código remoto/inyección de comandos)
- Prioridad 9002: Bloquea escáneres detectados
- Prioridad 9003: Bloquea ataques de protocolo como la división y el contrabando de HTTP
- Prioridad 9004: Bloquea ataques de fijación de sesión
- Prioridad 10000: Permite que tu IP acceda al sitio web
- Prioridad predeterminada: Denegar.
*Observa que la regla "permitir tu IP" está configurada con el número de prioridad más alto para permitir el acceso al sitio, pero bloquea cualquier ataque.
9. Observa los registros de la política de seguridad de Cloud Armor
En la página de la consola de Cloud Armor, puedes ver los detalles de la política de seguridad y hacer clic en la pestaña Logs y, luego, en el vínculo View policy logs para que se te dirija a la página de Cloud Logging. Se filtrará automáticamente en función de la política de seguridad de interés, p.ej., resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs). Observa los códigos de respuesta de error 403 y expande los detalles del registro para ver el nombre de la política de seguridad aplicada, el valor del campo con coincidencias y, más abajo, los IDs de expresión preconfigurados (o el ID de firma). En las siguientes capturas de pantalla, se muestran ejemplos de los registros de las políticas de seguridad aplicadas que se configuraron en este codelab.
Registro de LFI
Registro de RCE
Registro de detección de escáneres
Registro de ataques de protocolo
Registro de fijación de sesión
10. Borra el lab
Limpia los recursos ahora que completaste el lab.
Ejecuta estos comandos para borrar la política de seguridad de Cloud Armor, el balanceador de cargas, las instancias, las reglas de firewall y la red de VPC.
Quita la política de seguridad de Cloud Armor del servicio de backend
gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global
Borra la política de seguridad de Cloud Armor
Si borras la política de seguridad, se borrarán automáticamente las reglas asociadas.
gcloud -q compute security-policies delete block-with-modsec-crs
Borra los recursos del balanceador de cargas
Estos recursos del balanceador de cargas que se borrarán incluyen la regla de reenvío, los proxies HTTP de destino, los mapas de URL, el backend, las verificaciones de estado y el grupo de instancias.
gcloud -q compute forwarding-rules delete juice-shop-rule --global
gcloud -q compute target-http-proxies delete juice-shop-proxy
gcloud -q compute url-maps delete juice-shop-loadbalancer
gcloud -q compute backend-services delete juice-shop-backend \
--global
gcloud -q compute health-checks delete tcp-port-3000
gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c
Borra la instancia
gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c
Borra las reglas de firewall, la subred y la VPC
gcloud -q compute firewall-rules delete allow-health-check gcloud -q compute firewall-rules delete allow-js-site gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1 gcloud -q compute networks delete ca-lab-vpc
11. ¡Felicitaciones!
¡Felicitaciones por completar el codelab sobre las reglas de WAF preconfiguradas de Cloud Armor!
Temas abordados
- Cómo configurar un grupo de instancias y un balanceador de cargas de Cloud global
- Cómo configurar políticas de seguridad de Cloud Armor con reglas de WAF preconfiguradas para proteger contra LFI, RCE, escáneres, ataques de protocolo y fijación de sesión
- Cómo validar que Cloud Armor mitigó algunos de los 10 principales ataques de OWASP a través de los registros
Próximos pasos
- Protege tu aplicación contra las vulnerabilidades de OWASP Top 10 con las reglas de WAF preconfiguradas de Cloud Armor
- Ajusta las reglas según los niveles de sensibilidad
- Usa la referencia del lenguaje de reglas personalizadas para aplicar la seguridad de forma más específica.