Tox

Início/Cibersegurança

Proteção contra DDoS e disponibilidade

Os provedores de nuvem absorvem bem os ataques volumétricos de rede. O que costuma passar é o ataque na camada de aplicação: poucas requisições por segundo, mas direcionadas às rotas que mais consomem recursos, como busca, geração de relatório, login e exportação.

O objetivo é descobrir, em ambiente controlado, qual peça cede primeiro. Às vezes é o banco de dados, às vezes uma API de terceiro com limite baixo, às vezes a própria conta da nuvem que atinge o teto de gastos. Com isso em mãos, as proteções são colocadas no lugar certo.

Solicitar proposta

Quando faz sentido

  • O sistema já ficou fora do ar por excesso de acesso, legítimo ou não.
  • Há picos previsíveis de tráfego, como campanhas, abertura de inscrições ou fechamento de mês.
  • A empresa depende do sistema para faturar e não tem plano para um ataque.
  • O custo de infraestrutura subiu sem aumento correspondente de usuários.

O que fazemos

Mapa de rotas caras
Levantamento das operações que mais consomem banco, CPU ou serviços pagos por requisição.
Teste de carga autorizado
Tráfego controlado, em homologação ou em janela combinada, para medir o ponto de saturação de cada rota.
Rate limiting
Limites por IP, por usuário e por rota, com resposta 429 e tempo de espera. Rotas de login e recuperação de senha com limites mais baixos.
CDN e WAF
Cache do conteúdo estático, regras de firewall de aplicação, bloqueio por reputação e desafio para tráfego suspeito.
Limites de custo
Alertas e tetos de gasto na nuvem e nas APIs de terceiros, para que um ataque não vire uma fatura.
Plano de resposta
Quem é acionado, quais regras são ativadas e em que ordem, e como comunicar clientes durante a indisponibilidade.

O que você recebe

  • Relatório com o ponto de saturação de cada rota testada.
  • Configuração de rate limiting, CDN e WAF aplicada ou documentada.
  • Plano de resposta a ataque em uma página, para ficar à mão da equipe.

Referências

  • OWASP API Security Top 10 (2023), API4 (consumo de recursos sem restrição)
  • OWASP Automated Threats to Web Applications
  • OWASP Denial of Service Cheat Sheet
  • RFC 6585, código HTTP 429

Perguntas frequentes

Meu provedor de nuvem já não protege contra DDoS?

Em parte. A AWS aplica o Shield Standard a todos os clientes sem custo adicional, mas essa camada cobre ataques de rede e de transporte. A Cloudflare informa mitigação automática também na camada de aplicação. Mesmo assim, um volume baixo de requisições com aparência legítima, dirigido às rotas que mais consomem banco e CPU, tende a ficar abaixo dos gatilhos automáticos e exige regras escritas para o seu sistema.

Qual a diferença entre um ataque volumétrico e um ataque na camada de aplicação?

O ataque volumétrico tenta esgotar a banda ou a capacidade de rede com um grande fluxo de pacotes, e costuma ser absorvido pela infraestrutura do provedor. O ataque na camada de aplicação usa requisições HTTP que parecem normais e mira operações caras, como busca, login, exportação e geração de relatório. Poucas requisições por segundo bastam para saturar o banco de dados.

Preciso de CDN, WAF ou rate limiting? Por onde começar?

Os três cumprem papéis diferentes. A CDN tira do servidor o conteúdo estático e absorve parte do tráfego. O WAF filtra requisições por padrão, reputação e origem. O rate limiting controla quantas vezes cada usuário ou IP chama cada rota. A ordem certa sai do mapa de rotas caras: primeiro se protege a peça que cede antes.

O rate limiting pode bloquear clientes legítimos?

Pode, se o limite for calibrado sem olhar o tráfego real. Um caso comum é a empresa em que muitos funcionários saem pelo mesmo IP. Por isso os limites são definidos por usuário autenticado sempre que possível e por IP só nas rotas públicas. A resposta usa o código HTTP 429, definido no RFC 6585, com o cabeçalho Retry-After indicando quando tentar de novo.

É permitido simular um ataque DDoS contra o meu próprio sistema na nuvem?

Depende das regras do provedor. A AWS, por exemplo, proíbe DoS, DDoS e inundação de requisições fora das suas políticas próprias de teste de estresse. Por isso o trabalho usa teste de carga controlado, dentro dessas políticas e com autorização formal do cliente, sem reproduzir um ataque real.

O teste de carga afeta meus clientes?

Quando bem planejado, o teste roda em homologação. Em produção, só acontece em janela de baixo uso, com intensidade máxima combinada e alguém da sua equipe acompanhando. Antes de começar, fica definido por escrito como interromper o teste imediatamente se algum indicador sair do previsto.

Um ataque pode causar prejuízo mesmo sem derrubar o sistema?

Pode. A OWASP descreve casos em que um atacante dispara em série uma rota de recuperação de senha que envia SMS e gera milhares de dólares em cobranças de terceiro em poucos minutos. O mesmo vale para funções serverless, armazenamento e APIs cobradas por chamada. Tetos de gasto e alertas de custo fazem parte da proteção.

O que fazer durante um ataque em andamento?

Seguir o plano de resposta na ordem combinada. Primeiro entram as regras de contenção já preparadas, como desafio para tráfego suspeito e limites mais baixos nas rotas afetadas. Depois se confirma que o custo da nuvem está sob controle e se avisam os clientes pelo canal definido. A investigação da origem vem quando o serviço estiver estável.

Setores e serviços relacionados

Fale com a Tox

Conte o que precisa. Respondemos com uma proposta de escopo, prazo e preço.

Solicitar proposta