
Um ataque Distributed Denial-of-Service (DDoS) ocorre quando um serviço é sobrecarregado por um volume massivo e distribuído de tráfego, “derrubando” o sistema e impedindo o acesso de usuários legítimos. É como se milhares de carros congestionassem uma única rodovia—não por falha dos veículos, mas porque a via ficou completamente bloqueada.
Normalmente, esse tráfego excessivo é proveniente de uma “botnet”—uma rede de computadores ou dispositivos IoT infectados por malware e controlados remotamente para executar solicitações coordenadas. Os alvos incluem sites de exchanges, APIs de dados de mercado/negociação, nós RPC de blockchain e conexões peer-to-peer (P2P) de validadores.
A principal diferença está na escala e distribuição: um ataque DDoS parte de múltiplas fontes ao mesmo tempo, enquanto um Denial-of-Service (DoS) tradicional geralmente tem origem única. Ataques DDoS são muito mais difíceis de bloquear e rastrear, pois o tráfego malicioso é disperso globalmente, como se inúmeras torneiras fossem abertas simultaneamente.
No caso de um ataque DoS, é possível mitigar bloqueando um único endereço IP. Já para um ataque DDoS, é preciso aplicar filtragem upstream e desvio de tráfego próximo aos pontos de entrada da rede, combinados com limitação de taxa no nível de aplicação e estratégias de degradação controlada.
Os ataques DDoS geralmente se dividem em duas categorias principais:
Network Layer Floods: Saturam a largura de banda e os recursos de conexão com grandes volumes de pacotes. Exemplos: SYN floods ou UDP floods, que enviam quantidades massivas de pacotes sem executar lógica de negócio. Também existe a “amplificação por reflexão”, em que o atacante falsifica o IP da vítima e consulta vários serviços abertos (como DNS ou NTP), que então enviam respostas amplificadas para o alvo—como se usassem alto-falantes para aumentar o impacto.
Application Layer Exhaustion: Simulam usuários legítimos fazendo requisições complexas para esgotar CPU ou conexões com banco de dados. Exemplos comuns: HTTP floods ou abuso de WebSocket. Em Web3, endpoints para assinaturas de dados de mercado ou envio de ordens são alvos frequentes. Quando o tráfego malicioso imita o comportamento de usuários reais, pode contornar filtros de rede e consumir diretamente threads da aplicação, cache e pools de conexão com o banco de dados.
No universo Web3, ataques DDoS costumam focar pontos de entrada estratégicos como sites de exchanges, APIs de negociação/dados de mercado, nós RPC de blockchain, portas P2P de nós completos, cross-chain bridges e block explorers.
Por exemplo, numa exchange como a Gate, ataques DDoS a APIs spot e de derivativos podem causar lentidão no carregamento de páginas, interrupções em feeds de candlestick e book de ordens, timeouts em ordens e cancelamentos, além de regras de limite mais rígidas e mais erros para usuários de API. No nível RPC, ataques a nós públicos podem gerar timeouts em consultas de blocos/contas, falhas na atualização de saldo de carteiras e lentidão em chamadas de smart contracts.
Para nós validadores, sondagens excessivas de conexões P2P podem prejudicar a propagação de blocos e comprometer a produção e a sincronização. Se bridges cross-chain expõem interfaces públicas, serviços de assinatura ou prova off-chain podem ficar indisponíveis sob ataque.
Um sinal clássico é a “degradação repentina de performance sem alteração nos indicadores de negócio”: picos de latência, aumento de timeouts e erros 5xx, e crescimento súbito de tráfego sem conversão ou aumento proporcional de transações.
No lado da rede, é possível notar uso anormal de banda nos pontos de entrada, saturação da fila SYN e diversificação geográfica repentina dos IPs de origem. No lado da aplicação, observe QPS (queries por segundo) irregulares, aumento da latência p95, esgotamento do pool de conexões com banco de dados, queda na taxa de acerto do cache e picos em sessões WebSocket.
Assinaturas de log incluem User-Agent repetitivo ou malformado, picos de requisições sem cabeçalho Referrer, um mesmo IP acessando várias URLs em curto período ou ataques a endpoints dinâmicos em vez de recursos estáticos. Para serviços de nó e RPC, padrões comuns são chamadas homogêneas de contrato ou consultas frequentes de baixo valor.
Ative filtragem upstream e limitação de taxa: Se necessário, direcione temporariamente os IPs mais visados para “blackhole” ou redirecione-os para centros de mitigação, protegendo bancos de dados e engines de matching contra sobrecarga.
Implemente degradação de serviço e modos somente leitura: Exchanges devem priorizar o matching engine e a segurança dos ativos, reduzindo funções não essenciais—como carregamento preguiçoso de gráficos, pausa de APIs em lote desnecessárias ou janelas de histórico de candlestick reduzidas.
Alterne rapidamente para Anycast ou domínios de backup: Anycast distribui o mesmo IP em vários locais globais, permitindo que usuários se conectem ao nó mais próximo e o tráfego seja distribuído naturalmente. Domínios de backup isolam pontos de entrada mais atacados.
Reforce desafios e autenticação na camada de aplicação: Adicione CAPTCHAs em endpoints anônimos; implemente limites de taxa mais granulares e controles de pico em chaves de API; aplique validação de assinatura ou caches pré-aquecidos para requisições de alto custo.
Coordene com ISPs e fornecedores de segurança: Ajuste dinamicamente limites e padrões de filtragem mantendo observabilidade—garanta a efetividade de métricas, logs e alertas.
Comunique atualizações de status e alertas de risco aos usuários: Por exemplo, a página de status da Gate pode informar o impacto e o tempo estimado de recuperação. Oriente usuários a definir parâmetros de proteção de preço e risco ao enviar ordens para evitar erros durante períodos de instabilidade.
A defesa de longo prazo exige uma abordagem integrada—combinando desvio, absorção, filtragem e degradação de tráfego. No nível de rede, implemente redundância de alta largura de banda e scrubbing de tráfego nos pontos de entrada. Utilize Anycast com Content Delivery Networks (CDNs) para absorver picos próximos dos usuários; elimine portas de reflexão desnecessárias ou adote controles de acesso em serviços amplificáveis.
No lado da aplicação, implemente cache em múltiplos níveis e separação de leitura e escrita; torne endpoints críticos estáticos ou pré-computados; utilize Web Application Firewalls (WAF) para detectar comportamentos anômalos; aplique limitação de taxa com token bucket nas APIs, com QPS por usuário e controle de bursts; forneça gateways privados, whitelisting e cotas por origem para endpoints RPC.
Do ponto de vista de engenharia e organização: estabeleça simulações e playbooks de resposta que definam responsabilidades e controles em cada cenário; foque o monitoramento em SLOs (Service Level Objectives) críticos como disponibilidade, latência p95 e taxas de erro; avalie o benefício marginal de reservas de banda, serviços de scrubbing e redundância de computação conforme picos de negócio e exposição a riscos.
Ataques DDoS não roubam ativos diretamente, mas desestabilizam negociações e consultas—amplificando slippage, causando erros operacionais e aumentando riscos de latência. Para desenvolvedores, é fundamental projetar defesas em camadas antecipadamente e estabelecer procedimentos emergenciais eficientes para rede e aplicação. Para usuários: se notar problemas de acesso, consulte páginas oficiais de status, utilize apenas portais confiáveis como a Gate, defina parâmetros de limite e risco ao negociar e evite operações grandes ou alavancadas durante instabilidades. Relatórios do setor mostram que ataques DDoS de alto volume e em camada de aplicação continuam crescendo em 2024—com picos de tráfego chegando a níveis de Tbps (fontes: relatórios anuais e trimestrais da Cloudflare e Akamai). A preparação proativa e treinamentos são quase sempre mais econômicos do que a recuperação pós-incidente.
“Distributed” significa que o ataque vem de milhares de dispositivos comprometidos, e não apenas um. O tráfego de um computador isolado é limitado e fácil de ser bloqueado por firewalls. Quando o tráfego malicioso está distribuído globalmente entre muitas máquinas, não é possível bloquear apenas um IP. Essa distribuição aumenta consideravelmente o sucesso e a furtividade do ataque.
A carteira ou conta em si normalmente não é comprometida em ataques DDoS (ou seja, os fundos não são roubados diretamente), mas exchanges ou plataformas de carteira podem ficar fora do ar—impedindo negociações ou saques. Atrasos severos na rede durante o ataque podem causar slippage ou falhas em transações. Em alguns casos, atacantes podem explorar essa janela para outras ações maliciosas. O ideal é utilizar plataformas bem protegidas (como a Gate) com autenticação em dois fatores ativada.
A duração de um ataque DDoS pode variar de minutos a horas ou até dias—dependendo dos objetivos dos atacantes e da capacidade de resposta dos defensores. Ataques de porte médio costumam ser mitigados entre 30 minutos e 2 horas; ataques de grande escala podem levar várias horas para recuperação total. Proteção profissional via CDN e equipes de resposta a incidentes reduzem significativamente o tempo de indisponibilidade.
Hackers podem lançar ataques DDoS por diversos motivos: extorsão (exigindo pagamento de resgate), sabotagem por concorrentes, agendas políticas ou até diversão pessoal. No setor cripto, atacantes podem tentar impedir o lançamento de uma exchange ou projeto, ou explorar períodos de indisponibilidade para outros crimes. Compreender esses objetivos ajuda as organizações a planejar melhor suas defesas.
Ainda que ataques DDoS tenham como alvo principal as plataformas, é possível adotar cuidados: escolha exchanges com infraestrutura robusta de proteção (como a Gate), evite grandes operações durante períodos de instabilidade, ative autenticação multifator, monitore regularmente suas contas para atividades suspeitas e distribua seus ativos entre diferentes plataformas para reduzir a exposição ao risco.


