Codelab: Cloud Armor e balanceadores de carga de proxy TCP/SSL: limitação de taxa e lista de bloqueio de IP

1. Introdução

O balanceamento de carga do Google Cloud é implantado nos pontos de presença (POP, na sigla em inglês) na borda da rede do Google no mundo todo. O tráfego do usuário que foi direcionado para um balanceador de carga de proxy TCP entra no POP mais próximo e a carga dele é balanceada na rede global do Google, no primeiro back-end que tiver capacidade suficiente disponível.

O Cloud Armor é o sistema de detecção distribuído de negação de serviço e firewall de aplicativos da Web (WAF) do Google. O Cloud Armor está fortemente acoplado ao balanceador de carga de proxy TCP do Google Cloud e permite interrogar o tráfego de entrada sobre solicitações indesejadas. O recurso de limitação de taxa desse serviço permite restringir o tráfego para recursos de back-end com base no volume de solicitações e evita que o tráfego indesejado consuma recursos na rede de nuvem privada virtual (VPC).

Os balanceadores de carga de proxy TCP/SSL do Google Cloud permitem fazer proxy do tráfego do tipo TCP/ SSL entre os serviços de back-end.

Neste codelab, você vai criar um balanceador de carga de proxy TCP/SSL com um serviço de back-end e usar o Cloud Armor para limitar o acesso ao balanceador de carga a apenas um conjunto específico de clientes usuários.

be33dadf836374bb.png

O que você vai aprender

  • Como criar um balanceador de carga de proxy TCP/SSL
  • Como criar uma política de segurança do Cloud Armor
  • Como criar uma regra de lista de negação de IP para o balanceador de carga de proxy TCP/SSL no Cloud Armor
  • Como criar uma regra de limitação de taxa para o balanceador de carga de proxy TCP no Cloud Armor
  • Como adicionar a política de segurança a um serviço de back-end de balanceamento de carga TCP/SSL

O que é necessário

  • Conhecimento básico do Google Compute Engine ( codelab)
  • Conhecimento básico de TCP/IP e redes
  • Conhecimento básico de linha de comando do Unix/Linux
  • É útil fazer um tour de rede no GCP com o curso Networking in the Google Cloud

2. Requisitos

Configuração de ambiente personalizada

  1. Faça login no console do Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

Observação: para acessar facilmente o console do Cloud, basta memorizar o URL, que é console.cloud.google.com.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

Lembre-se do código do projeto, um nome exclusivo em todos os projetos do Google Cloud. O nome acima já foi escolhido e não servirá para você. Faremos referência a ele mais adiante neste codelab como PROJECT_ID.

Observação: se você estiver usando uma conta do Gmail, defina o local padrão como "Sem organização". Se você estiver usando uma conta do Google Workspace, escolha um local adequado para a organização.

  1. Em seguida, será necessário ativar o faturamento no Console do Cloud para usar os recursos do Google Cloud.

A execução deste codelab não será muito cara, se for o caso. Siga todas as instruções na seção "Limpeza", que orienta você sobre como encerrar recursos para não incorrer em cobranças além deste tutorial. Novos usuários do Google Cloud estão qualificados para o programa de US$300 de avaliação sem custo financeiro.

Iniciar o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

bce75f34b2c53987.png

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

f6ef2b5f13479f3a.png

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

Antes de começar

No Cloud Shell, verifique se o ID do projeto está configurado

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID

Ativar APIs

Ative todos os serviços necessários

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com        
gcloud services enable monitoring.googleapis.com

3. Criar serviços de back-end

Crie duas instâncias da seguinte maneira: crie instance1-b1 na 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"

Crie a instância 1-b2 na 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"

Criar um grupo de instâncias vm-ig1

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

Crie uma porta nomeada para o grupo de instâncias. Neste laboratório, vamos usar a porta 110

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

Adicione as instâncias ao grupo de instâncias

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

4. Como configurar o balanceador de carga

Em seguida, criaremos uma verificação de integridade.

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

Criar um serviço de back-end

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

Adicionar o grupo de instâncias ao serviço de back-end

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

Configurar um proxy TCP de destino

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

Reservar endereços IPv4 estáticos globais

Você usará esse endereço IP para acessar seu serviço de balanceamento de carga.

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

Configure regras de encaminhamento globais para o endereço IP do LB.

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. Como criar uma regra de firewall para o balanceador de carga do 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

Depois de criar o balanceador de carga, teste-o com o seguinte comando

Curl LB_IP:110

Em seguida, crie VMs para validação da negação de acesso ao LB

Crie duas instâncias, cada uma com um endereço IP público chamados test-server1 e test-server2

6. Criar uma política de segurança no Cloud Armor

Nesta seção, você vai criar uma política de segurança de back-end e duas regras na política do Cloud Armor.

A primeira regra impede que um conjunto limitado de IPs acesse o balanceador de carga TCP, definindo uma política de segurança para negar determinados IPs, e a segunda tem limitações de taxa.

  1. No Cloud Shell(consulte "Iniciar o Cloud Shell" em "Configuração e requisitos" para instruções sobre como usar o Cloud Shell), crie uma política de segurança de serviço de back-end chamada rate-limit-and-deny-tcp conforme a seguir
gcloud compute security-policies create rate-limit-and-deny-tcp \
    --description "policy for tcp proxy rate limiting and IP deny"

Adicionar regras à política de segurança

Em seguida, adicione uma regra de lista de bloqueio à política "rate-limit-and-deny-tcp" do Cloud Armor.

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"

Adicionar uma regra de limitação de taxa à política de segurança "rate-limit-and-deny-tcp" do Cloud Armor

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

Anexe a política ao serviço de back-end do proxy TCP:

Execute o comando a seguir para garantir que a política de segurança esteja anexada ao serviço de back-end do proxy TCP.

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

Ative a geração de registros no balanceador de carga do proxy TCP

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

7. Validar a regra da lista de bloqueio

Valide a regra da lista de bloqueio fazendo login no servidor de teste com o IP especificado nela e executando o comando a seguir.

Curl LB_IP:110

As solicitações imediatas podem gerar uma resposta do LB, mas aguardam até que a solicitação curl seja negada ou descartada e depois confira os registros no Cloud Logging para verificar a entrada de registro para a regra de negação de IP que está sendo acionada.

Acesse o Cloud Logging e, em "Recursos", selecione o tipo de recurso como "tcp_ssl_proxy_rule". e defina o destino do back-end como "my-tcp-lb".

Com os recursos definidos para filtragem, podemos validar se a regra de negação de IP está em vigor usando o valor PRIORITY de 1.000 na entrada de registro e a ação configurada "DENY", já que ambas foram instruídas pela regra de negação e pelo IP que está sendo negado, conforme mostrado abaixo

db9b835e0360dcaf.png

8. Validar a regra de limitação de taxa

Para confirmar se a regra de limite de taxa está em vigor, envie muitas solicitações em um curto período que exceda o limite definido (cinco solicitações por minuto).

Depois disso, clique em "Visualizar registros" no serviço Cloud Armor para acessar o Cloud Logging, onde é possível filtrar os registros pelo balanceador de carga para conferir os registros do Cloud Armor à medida que chegam.

Uma entrada de limitação de taxa deve ser conforme a captura de tela abaixo. É possível validar se a regra de limite de taxa está em vigor usando o valor PRIORITY de 3.000 na entrada de registro e, na ação configurada, se BAN com base na taxa está em vigor conforme instruído na regra de limitação de taxa.

37c76e5d7532623.png

9. Limpeza do ambiente

Certifique-se de limpar a infraestrutura criada para evitar custos de execução de infraestrutura não utilizada.

A maneira mais rápida de fazer isso é excluir todo o projeto no GCP para garantir que não haja mais recursos pendentes. No entanto, exclua os recursos individuais com os comandos a seguir.

O balanceador de carga do proxy TCP

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

O grupo de instâncias

gcloud compute instance-groups unmanaged delete vm-ig1

As duas instâncias de VM de teste criadas

gcloud compute instances delete Instance_name --zone=instance_zone

O serviço de back-end

gcloud compute backend-services delete BACKEND_SERVICE_NAME

As regras do Cloud Armor na 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

A política de segurança do Cloud Armor

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