Há semanas tentam nos atacar com DDoS, e não estamos fazendo nada

Estamos sofrendo um ataque DDoS, mas não estamos fazendo nada

• Há semanas alguém vem tentando realizar um ataque DDoS.
• Estão despejando milhões de requisições no servidor para tentar baixar um arquivo de configuração milhões de vezes.
• Só nos últimos 5 dias, tentaram fazer o download mais de 800 mil vezes, e o arquivo de configuração tem cerca de 200MB por download.
• A maior parte do tráfego vem da UE, especialmente da Alemanha e do Reino Unido.
• O ataque continua em andamento no momento em que este post está sendo escrito.

O que estamos fazendo nesta situação urgente

• Não bloqueamos os endereços IP do atacante.
• Usamos Cloudflare, mas não ativamos o modo "Under Attack".
• A CPU do servidor fica quase ociosa durante a maior parte do tempo, mesmo sob ataque.
• Em geral, não estamos fazendo quase nada.

Por que isso?

• O serviço consegue processar dezenas de bilhões de requisições por mês sem problemas e sem custo alto.
• Temos cerca de 8 serviços de API e bancos de dados, e mesmo sem cache conseguimos lidar com dezenas de bilhões de requisições por mês.
• Temos Cloudflare e largura de banda ilimitada.

Como isso é possível?

• O design do app TablePlus é simples, e essa filosofia também se aplica aos serviços de backend, que são mantidos no mínimo necessário.
• Não usamos serviços de terceiros como Vercel ou Netlify. Em vez disso, usamos servidores web sem limitações.
• No passado, a arquitetura monolítica virava gargalo por causa de VPS/processadores fracos, mas hoje VPSs potentes conseguem processar dezenas de bilhões de requisições por mês em uma única instância.
• Por isso, construímos serviços monolíticos para cada app. É fácil de implantar e manter.

Vamos falar sobre monolitos

• Há uma tendência de tornar tudo complexo, mas isso não é um problema até que haja pressão ou limitações.
• Escolhemos monolitos porque detestamos complexidade. Integramos em um único serviço tudo o que o app precisa.
• O deploy é simples. Só é necessário um único arquivo de configuração, build e deploy.
• Como há menos dependências, fica mais fácil debugar e identificar gargalos.

Um único framework web em Go ou Rust, se bem implementado, consegue lidar com dezenas de bilhões de requisições por mês

• Escolhemos frameworks de alto desempenho.
• Indexamos o banco de dados para reduzir o tempo de busca à medida que o conjunto de dados cresce.
• Separamos o banco de dados principal do banco de logs/uso para que problemas de desempenho não afetem o negócio principal.
• Usamos um proxy reverso robusto, como o Nginx, para processar e distribuir requisições ao núcleo da API.
• Colocamos tudo atrás do Cloudflare e configuramos corretamente.
• Usamos um CDN com proteção contra DDoS.
• Não colocamos arquivos grandes para download em VPS sem CDN ou cache.

Vamos falar sobre deploy

• Na TablePlus, simplificamos o processo de deploy o máximo possível.
• Não usamos Docker, Kubernetes nem containers, e não precisamos de configuração de ambiente.
• Usamos binários. Eles podem ser copiados e executados como processos em servidores Linux.
• Escolhemos Go e Rust. São linguagens de alto desempenho e conseguem gerar arquivos binários para deploy.

Atualização

• A Vercel entrou em contato e disse que tem recursos que podem proteger o site nesse tipo de situação.
• Com controle de gastos, é possível definir um limite de despesas, e também há um modo de desafio contra ataques, semelhante ao modo "Under Attack" da CF.

Opinião do GN⁺

• Este artigo destaca a importância de uma infraestrutura robusta e de uma estratégia de deploy simplificada para manter a operação estável do serviço, mesmo diante de ataques DDoS.
• A arquitetura monolítica mostra vantagens em reduzir complexidade, simplificar o deploy e favorecer a otimização de desempenho.
• O uso eficaz de serviços em nuvem e CDN para ganhar resiliência contra ataques DDoS pode servir como um bom exemplo para outras empresas.
• Essa abordagem também oferece insights sobre como montar uma infraestrutura com boa relação custo-benefício, especialmente para startups em estágio inicial e pequenas e médias empresas.
• No entanto, como a abordagem monolítica não é adequada para todos os sistemas ou aplicações, é importante escolher a arquitetura de acordo com as necessidades e o contexto de cada caso.

[GN⁺]

Opiniões no Hacker News

• Resumo do primeiro comentário:

  • O comentarista acha que se gabar do desempenho do site foi exagerado.
  • "1 bilhão de requisições por mês" equivale a apenas algumas centenas de requisições por segundo, o que é um nível trivial e não pode ser considerado um ataque DDoS.
  • Como o site está atrás de uma CDN (Cloudflare), não parece que tenham feito nada de especial em relação a desempenho.
  • Um arquivo de 200MB ser armazenado em cache e servido por uma CDN é algo esperado, e se gabar disso parece sinal de um projeto inadequado.

• Resumo do segundo comentário:

  • 4TB de tráfego por mês dificilmente pode ser visto como um ataque DDoS.
  • 6 milhões de requisições por mês equivalem a apenas 2 requisições por segundo, então operar um serviço monolítico nesse porte não é problema.
  • Presume-se que a maioria das requisições seja atendida pelo cache da Cloudflare no nível da CDN.

• Resumo do terceiro comentário:

  • O site é apenas um site estático simples de marketing, sem fórum de discussão, e o feedback é tratado via issues no GitHub.
  • É estranho se gabar de que um deploy simples consegue lidar com milhões de downloads diários de arquivos estáticos.
  • A Cloudflare está fazendo todo o trabalho de mitigação e, na prática, o tráfego real pode até ser baixo demais para precisar disso.

• Resumo do quarto comentário:

  • O tráfego adicional descrito parece um "abuso sem sentido do serviço" e dificilmente pode ser visto como um ataque DDoS de verdade.
  • Se esse abuso não causar custos nem exaustão de recursos, pode ser ignorado.
  • Histórias de infraestrutura com autoescalonamento em que a maior parte não realiza trabalho útil são comuns, então vale a pena observar o tráfego.
  • Há uma reclamação sobre logging, mas se o armazenamento de logs for barato e abundante isso não seria um problema; ainda assim, seria bom classificar automaticamente o tráfego abusivo e suprimir seu tratamento rotineiro.

• Resumo do quinto comentário:

  • 50 milhões de requisições por mês vindas do Reino Unido é um volume que pode ser causado pela execução de um único script.
  • O autor espera que um servidor Go consiga lidar com 250 vezes mais requisições por segundo, mesmo sem otimização.
  • O conselho em si não é ruim, mas os números deles não servem como evidência desse conselho.

• Resumo do sexto comentário:

  • Distribuir binários pode ser preferível a usar Docker, mas existem preocupações de segurança em relação ao host que executa esses binários.
  • Um serviço monolítico hospedado em uma única VPS é barato e pode ser bom, mas se houver problema de hardware o tempo de indisponibilidade pode ser considerável.
  • Ao consolidar tudo em um único serviço, pode-se perder defesa em profundidade, o que pode permitir acesso ao armazenamento de dados caso surja um problema de segurança.

• Resumo do sétimo comentário:

  • "1 bilhão de requisições por mês" é um volume que um único servidor consegue atender, e um único script mal escrito pode gerar esse nível de tráfego.

• Resumo do oitavo comentário:

  • Questiona-se se alguns bilhões de requisições por mês realmente seriam considerados um grande ataque DDoS.

• Resumo do nono comentário:

  • Construir um serviço monolítico para cada app facilita o deploy e a manutenção.
  • Basta distribuir apenas o arquivo binário, sem Docker, Kubernetes, dependências ou ambiente de runtime.

• Resumo do décimo comentário:

  • Ao ler o título, esperava-se algo maior, mas estar atrás da Cloudflare é um fator importante.
  • Dependendo da distribuição do tráfego, o serviço poderia até funcionar bem em uma VPS sem a Cloudflare.
  • Ataques DDoS layer 7 vindos da Rússia podem ser grandes a ponto de grandes provedores falharem por limitações de capacidade.