Definição: o que é DDoS, na prática

DDoS (Distributed Denial of Service) é uma forma de ataque em que muitos fluxos tentam sobrecarregar recursos de um sistema, como largura de banda, CPU, memória ou capacidade de conexão. O objetivo costuma ser reduzir a disponibilidade do serviço para usuários legítimos.

Mesmo quando alguém fala “DDoS em si mesmo”, a ideia normalmente envolve gerar tráfego ou carga de forma que o sistema fique instável ou indisponível. Isso é o ponto central: se o comportamento é de saturação/restrição de serviço, ele se aproxima do que é conhecido como negação de serviço, independentemente de o alvo ser “o próprio” equipamento ou domínio.

Em geral, não dá para concluir que é automaticamente legal só porque o alvo é seu. A legalidade depende de fatores do caso concreto, como:

  • se houve geração de tráfego que impactou serviços de terceiros (por exemplo, roteadores, links de provedores, IPs compartilhados ou infra de terceiros)
  • se você tinha autorização clara para conduzir o teste naquele ambiente
  • se o teste foi feito com controle e limites que evitassem interrupções reais
  • como o comportamento foi documentado e por que finalidade foi conduzido

Na prática, “ser seu” pode reduzir a chance de haver violação ligada a acesso ou uso de infraestrutura de terceiros. Porém, ainda pode haver consequências se o teste causar indisponibilidade, alterar condições de rede fora do esperado ou se enquadrar como uso abusivo de serviços de internet.

Diferenças importantes: DDoS x testes de carga e resiliência

A principal alternativa “legítima” costuma ser substituir ataques por testes planejados de desempenho e resiliência. Em vez de tentar imitar a dinâmica de um DDoS, os testes de carga e estresse em geral seguem um roteiro de:

  • metas técnicas (por exemplo, qual número de requisições o sistema suporta)
  • limites de impacto (para não derrubar o serviço inteiro nem afetar vizinhos na rede)
  • ambientes controlados (ex.: homologação/ambiente dedicado quando possível)
  • observabilidade (monitorar CPU, memória, latência, taxa de erros e gargalos)

Isso não significa que toda forma de teste de carga seja “sempre permitida”. Mas muda a natureza do experimento: o foco é medir e validar capacidade, não causar indisponibilidade como efeito colateral.

Também vale considerar que “fazer em si mesmo” pode, na prática, acionar roteadores/links, políticas do provedor ou redes compartilhadas. Assim, mesmo um teste “interno” pode transbordar para fora do que você controla.

O que você pode checar antes de testar

Se sua intenção é verificar robustez, você pode se orientar por verificações não sensíveis a “atalhos”:

  • Você tem clareza do escopo (qual serviço, qual janela, qual limite de impacto)?
  • Há um plano para interromper o teste se começar a afetar disponibilidade além do esperado?
  • O ambiente de teste é separado quando necessário (homologação, infraestrutura dedicada, regras de rate/filtragem)?
  • Você consegue medir e explicar o resultado sem depender de indisponibilidade prolongada?
  • As políticas do provedor/infra permitem testes desse tipo no seu contrato e na sua configuração?

Se você não tiver essas garantias, trate o tema como de alto risco operacional e legal no mundo real. Em vez de “fazer DDoS em si mesmo”, procure métodos de validação de desempenho e resiliência que sejam mais previsíveis e controláveis.