É o fim da Amazon AWS, Google GCP, e plataformas em nuvem?

Ultimamente temos visto vários problemas com os serviços em nuvem, como os da Amazon, Google Cloud, e demais serviços.

O principal problema destes serviços, não está relacionado ao seu serviço em si, mas sim ao fato de que estes serviços estão na internet, expostos aos ataques de hackers, que estão realizando vários ataques coordenados de todos os lugares do mundo para simplesmente: gastar seu tráfego de dados.

Reparamos isto quando subimos uma máquina virtual, e mesmo não tendo nenhum serviço relevante hospedado, estava consumindo cerca de 49 GB de tráfego, sendo que o limite mensal do free tier é de apenas 1 GB. Ou seja, se não fosse pelos créditos, poderia ter vindo uma fatura bem gorda.

Analizamos o tráfego de dados que estava chegando a VM utilizando vários conceitos de análise de pacotes, e identificamos que os acessos estavam sendo apenas de tráfego na porta 80 e 443, ou seja, milhares e milhares de requisições apenas para gastar a banda,e fazer a fatura ficar maior, mesmo sem nada relevante hospedado, nem mesmo um ataque de fato para conseguir acesso à máquina.

Veja alguns detalhes que revelam endereços IPs e sites que acessam uma VM que só tem um simples "Hello World" na porta 80:

É possível ver uma grande quantidade de servidores que estão acessando apenas para consumir banda.

Utilizando algumas aplicações para mensurar o tráfego, vemos que de entrada, houve 1,11 Gbyte no período analisado, e 936 Mb de saída de dados.

Estes testes foram feitos em uma máquina dentro do free tier do Google Cloud, que tem um limite de custo de saída de dados acima de 1 Gb, ou seja, em poucos minutos que a instância ficou ativa, já chegou no seu limite mensal, ou seja, em alguns minutos você ficará fora do free tier, e haverá cobranças por estas requisições.

Em outros momentos vemos uma rajada de conexões sendo realizada para um servidor com um simples "Hello World". Este deve ser o site com o maior acesso do mundo, não?

Estes dados foram de apenas um determinado momento, mas repare nos gráficos de utilização deste site com "Hello World" nos relatórios de custo do GCP:

Houve uma saída de 43,95 "Gibibyte" de dados de uma instância que tem uma simples página que deve ter apenas 15 bytes de dados. O custo deste imenso tráfego custou R$ 23,84.

O segundo maior custo aí foi do SSD, pois reparamos que usamos o SSD premium em uma instância do free tier, e vimos que o SSD não entrava no custo gratuito, e sim no custo pago. Deve-se sempre utilizar o disco comum.

Outro detalhe também é que durante este período que consumiu todos estes dados, deixamos o endereço IP protegido pela Cloudflare, mas após o período de maior consumo de dados, expomos o IP apenas para a internet (fora da Cloudflare) e vimos que continuava o tráfego desta forma.

A solução de imediato para o caso foi desligar a instância. Claro que esta não é uma opção para quem ter serviços hospedados, mas para usar apenas dentro do free tier, não é possível manter com custo zero sendo que em apenas alguns minutos a instância já gasta o máximo da free tier do mês.

Não deixa de ser um ataque, afinal, um ataque pode ser apenas o consumo para gerar algum prejuízo para os clientes. E outra coisa que reparamos também é que ao alterar o endereço IP da instância, houve uma melhora significativa, porém, com um endereço IP totalmente diferente, provavelmente de outro pool.

Não sabemos exatamente o motivo da melhora ao trocar o endereço IP, mas conforme o tempo o mesmo volta a ter o consumo nos acessos, ou seja, mais parece que os endereços expostos começam ficar visíveis na internet, e os robôs e atacantes começam consumir dados da porta 80 e 443 apenas para abusar dos recursos a toa.

Se você quer utilizar dentro do free tier, sem gerar um consumo excessivo, para pequenos projetos pessoais, o ideal é ter um controle rígido de endereços IPs na lista de permissões no seu firewall, permitindo apenas as máquinas que você quer que tenha acesso a qualquer porta, principalmente as sensíveis, e qualquer outra para evitar custos extras inesperados.

O Google Cloud não possui um plano de tráfego de dados ilimitados nem mesmo em seus planos pagos, ou seja, um grande ataque de DDoS apenas na porta 80 pode além de tirar o seu site do ar, gerar uma fatura gorda por minuto.

E estes ataques parecem vir da própria Amazon ou Google Cloud, de instâncias de outros clientes. Já que estão no mesmo datacenter, há um aproveito da baixa latência para consumir rapidamente dados de outras instâncias, e fazer sua fatura explodir.

Lembrando que todas estas análises, foram feitas com instâncias novas, contendo apenas um simples "Hello World", com política de firewall abrindo as portas 80, 443, e também abrimos portas adicionais para FTP e demais serviços "comuns", como também um banco de dados MySQL.

Assim que as portas são expostas na internet, apesar do grande volume de dados serem nas portas HTTP, também houveram tráfego nas outras portas, derivada talvez de algum robô tentando acessar demais recursos.

Outra forma de contorno que pode ser pensada é: colocar na página inicial que atende a porta 80, algum delay obrigatório, assim, reduz a quantidade de chamadas.

Outro detalhe que também vimos é que deixamos o Apache com a função keep-alive ativada para reduzir o tempo de resposta entre chamadas, e neste caso, pode também ter sido um recurso útil para atacantes aproveitarem que a porta 80 permanecia aberta para continuar injetando dados só para consumir tráfego a toa.

Recentemente temos visto que a Amazon também sofre de ataques, estes que podem ser semelhantes aos encontrados aqui, que aparentemente o único intuito destes é apenas gastar tráfego e deixar a fatura dos clientes mais cara.

Enquanto não houver um plano de tráfego "gratuito", a Amazon e Google podem perder clientes para soluções proprietárias ou até mesmo para soluções em empresas que estão aptas a não tarifar o cliente se caso houver uma grande saída de dados de forma inesperada.