Codelab de Cloud Armor y de proxy TCP/SSL: límite de frecuencia y lista de denegación de IP

1. Introducción

El balanceo de cargas de Google Cloud se implementa en el perímetro de la red de Google en los puntos de presencia (POP) de Google en todo el mundo. El tráfico de usuario dirigido a un balanceador de cargas de proxy TCP ingresa al POP que se encuentra más cerca del usuario. Luego, se balancea su carga a través de la red global de Google al backend más cercano que tenga suficiente capacidad disponible.

Cloud Armor es el sistema de detección de denegación de servicio distribuido y firewall de aplicación web (WAF) de Google. Cloud Armor tiene acoplamiento alto con el balanceador de cargas de proxy TCP de Google Cloud y te permite interrogar el tráfico entrante para detectar solicitudes no deseadas. La función de límite de frecuencia de este servicio te permite restringir el tráfico a los recursos de backend según el volumen de solicitudes y evita que el tráfico no deseado consuma recursos de tu red de nube privada virtual (VPC).

Los balanceadores de cargas de proxy TCP/SSL de Google Cloud te permiten usar un proxy en el tráfico de tipo TCP/ SSL entre tus servicios de backend.

En este codelab, crearás un balanceador de cargas de proxy TCP/SSL con un servicio de backend y usarás Cloud Armor para limitar el acceso al balanceador de cargas solo a un conjunto específico de clientes usuarios.

be33dadf836374bb.png

Qué aprenderás

  • Cómo crear un balanceador de cargas del proxy TCP/SSL
  • Cómo crear una política de seguridad de Cloud Armor
  • Cómo crear una regla de lista de bloqueo de IP para el balanceador de cargas del proxy TCP/SSL en Cloud Armor
  • Cómo crear una regla de límite de frecuencia para el balanceador de cargas del proxy TCP en Cloud Armor
  • Cómo agregar la política de seguridad a un servicio de backend de balanceo de cargas TCP/SSL

Requisitos

  • Conocimiento básico 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 herramientas de redes en GCP con Networking in the Google Cloud.

2. Requisitos

Configuración del entorno de autoaprendizaje

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

Nota: Para acceder a la consola de Cloud con facilidad, memoriza su URL, que es console.cloud.google.com.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

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.

Nota: Si usas una cuenta de Gmail, puedes dejar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

  1. 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 no incurrir en facturación más allá de este instructivo. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de$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:

bce75f34b2c53987.png

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:

f6ef2b5f13479f3a.png

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 el 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 servicios de backend

Crea 2 instancias de la siguiente manera: Crea instance1-b1 en la zona us-central1-b.

gcloud compute instances create vm-1-b1 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags tcp-lb \
    --zone us-central1-b \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
      sudo service apache2 restart
      echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Crea la instancia 1-b2 en la zona us-central1-b.

gcloud compute instances create vm-1-b2 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags tcp-lb \
    --zone us-central1-b \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
      sudo service apache2 restart
      echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Crear un grupo de instancias vm-ig1

gcloud compute instance-groups unmanaged create vm-ig1  --zone us-central1-b

Crea un puerto con nombre para el grupo de instancias. Para este lab, usaremos el puerto 110

    gcloud compute instance-groups set-named-ports vm-ig1 \
--named-ports tcp 110:110 --zone us-central1-b

Agrega las instancias al grupo de instancias

gcloud compute instance-groups unmanaged add-instances vm-ig1 \
   --instances vm-1-b1,vm-1-b2 --zone us-central1-b

4. Configura el balanceador de cargas

A continuación, crearemos una verificación de estado.

gcloud compute health-checks create tcp my-tcp-health-check --port 110

Crear un servicio de backend

gcloud compute backend-services create my-tcp-lb  --global-health-checks --global \
--protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110

Agrega el grupo de instancias al servicio de backend

gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8

Configura un proxy TCP de destino

gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE

Reserva direcciones IPv4 estáticas globales

Usarás esta dirección IP para acceder a tu servicio con balanceo de cargas.

gcloud compute addresses create tcp-lb-static-ipv4  --ip-version=IPV4   --global

Configurar reglas de reenvío globales para la dirección IP del balanceador de cargas.

gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
    --global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110

5. Crea una regla de firewall para el balanceador de cargas del proxy TCP

gcloud compute firewall-rules create allow-tcplb-and-health \
   --source-ranges 130.211.0.0/22,35.191.0.0/16 \
   --target-tags tcp-lb \
   --allow tcp:110

Una vez que hayas creado el balanceador de cargas, pruébalo con el siguiente comando:

Curl LB_IP:110

Luego, crea VMs para la validación de la denegación de acceso al balanceador de cargas

Debes crear 2 instancias, cada una con una dirección IP pública llamada test-server1 y test-server2

6. Crea una política de seguridad en Cloud Armor

En esta sección, crearás una política de seguridad de backend y 2 reglas en la política en Cloud Armor.

La primera regla denegará el acceso de un conjunto limitado de IP al balanceador de cargas TCP estableciendo una política de seguridad que rechace ciertas IP y la segunda regla aplicará el límite de frecuencia.

  1. En Cloud Shell(consulta "Cómo iniciar Cloud Shell" en "Configuración y requisitos" para obtener instrucciones sobre cómo usar Cloud Shell), crea una política de seguridad para el servicio de backend llamada rate-limit-and-deny-tcp, como se indica a continuación
gcloud compute security-policies create rate-limit-and-deny-tcp \
    --description "policy for tcp proxy rate limiting and IP deny"

Agrega reglas a la política de seguridad

A continuación, agrega una regla de lista de bloqueo a la política de Cloud Armor “rate-limit-and-deny-tcp”.

gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"

Agrega una regla de límite de frecuencia a la política de seguridad de Cloud Armor “rate-limit-and-deny-tcp”

gcloud compute security-policies rules create 3000   \ --security-policy=rate-limit-and-deny-tcp  \       
--expression="true"  --action=rate-based-ban  --rate-limit-threshold-count=5  \          
--rate-limit-threshold-interval-sec=60  --ban-duration-sec=300      \         
--conform-action=allow  --exceed-action=deny-404  --enforce-on-key=IP

Conecta la política al servicio de backend del proxy TCP:

Ejecuta el siguiente comando para asegurarte de que la política de seguridad esté vinculada al servicio de backend del proxy TCP.

gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp

Habilitar el registro en el balanceador de cargas de proxy TCP

gcloud beta compute backend-services update my-tcp-lb \ 
--enable-logging --logging-sample-rate=1

7. Validar regla de lista de bloqueo

Para validar la regla de la lista de bloqueo, accede al servidor de prueba cuya IP se especificó en la regla de la lista de bloqueo y ejecuta el siguiente comando

Curl LB_IP:110

Las solicitudes inmediatas pueden dar una respuesta del balanceador de cargas, pero se espera a que la solicitud curl se rechace o se descarte y, luego, observa los registros en Cloud Logging para verificar la entrada de registro de la regla de denegación de IP que se activa.

Ve a Cloud Logging y, en Recursos, selecciona el tipo de recurso como “tcp_ssl_proxy_rule”. y establece el destino de backend en “my-tcp-lb”.

Con los recursos definidos para el filtrado, podemos validar que la regla de denegación de IP está vigente a partir del valor PRIORITY de 1000 en la entrada de registro y la acción configurada "DENY" está activa, ya que ambas se indicaron mediante la regla de denegación y la IP rechazada, como se muestra a continuación.

db9b835e0360dcaf.png

8. Validar regla de límite de frecuencia

Para validar que la regla de límite de frecuencia esté vigente, envía muchas solicitudes en un período corto que supere el umbral definido (5 solicitudes por minuto).

Una vez hecho esto, haz clic en Ver registros en el servicio de Cloud Armor para acceder a Cloud Logging, donde puedes filtrar los registros por el balanceador de cargas para ver los registros de Cloud Armor a medida que ingresan.

Una entrada de límite de frecuencia debe ser la que se muestra en la siguiente captura de pantalla. Podemos validar que la regla de límite de frecuencia está vigente a partir del valor PRIORITY de 3,000 en la entrada de registro y, a partir de la acción configurada, la acción “RATE BASED BAN” está vigente según las instrucciones de la regla de límite de frecuencia.

8c76e5d7532623.png

9. Limpieza del entorno

Asegúrate de limpiar la infraestructura creada para evitar los costos de ejecución de la infraestructura sin usar.

La forma más rápida es borrar todo el proyecto en GCP para asegurarse de que no quede ningún recurso pendiente.Sin embargo, puede borrar los recursos individuales con los siguientes comandos:

El balanceador de cargas del proxy TCP

gcloud compute target-tcp-proxies delete my-tcp-lb

El grupo de instancias

gcloud compute instance-groups unmanaged delete vm-ig1

Las 2 instancias de VM de prueba creadas

gcloud compute instances delete Instance_name --zone=instance_zone

El servicio de backend

gcloud compute backend-services delete BACKEND_SERVICE_NAME

Las reglas de Cloud Armor dentro de la política

gcloud compute security-policies rules delete 1000  \ --security-policy=rate-limit-and-deny-tcp && 
gcloud compute security-policies rules delete 3000  \ --security-policy=rate-limit-and-deny-tcp

La política de seguridad de Cloud Armor

gcloud compute security-policies delete rate-limit-and-deny-tcp