Serviços conectados à Internet dependem de redes e aplicações disponíveis para seus usuários. Um ataque de negação de serviço distribuído (DDoS) tenta interromper essa disponibilidade por meio de tráfego ou requisições vindos de múltiplas origens.
Distributed Denial of Service significa negação de serviço distribuída. O objetivo é tornar um site, aplicação ou serviço de rede indisponível ou degradar seu funcionamento para usuários legítimos. A sobrecarga pode atingir banda, equipamentos de rede, protocolos ou recursos da aplicação.
Uma botnet de dispositivos comprometidos é uma das formas de coordenar o ataque, mas DDoS também pode usar serviços de reflexão e amplificação ou outras fontes distribuídas. A presença de uma botnet não faz parte da definição. O impacto para uma empresa depende do serviço afetado, da duração e da capacidade de resposta.
DoS é a tentativa de negar a disponibilidade de um serviço. Na distinção usual, um ataque DoS parte de uma origem, enquanto o DDoS distribui o tráfego entre múltiplas fontes. Ambos podem explorar falhas ou esgotar recursos; a distribuição, sozinha, não determina a intensidade nem a técnica usada. Para entender os efeitos de uma origem isolada, consulte também nosso artigo sobre ataques DoS.
Ataques DDoS podem visar a capacidade de rede, protocolos de transporte ou recursos de aplicações. O modelo OSI ajuda a descrever onde surgem os efeitos, mas não é um conjunto de caminhos de ataque. A mitigação precisa ser adequada ao tipo de tráfego e à arquitetura protegida. Orientações da CISA.
Uma classificação prática agrupa ataques DDoS em volumétricos, direcionados a protocolos e à camada de aplicação. As categorias podem se sobrepor, e um incidente pode combinar mais de um vetor.
Conheça os três tipos:
O objetivo é consumir capacidade de rede ou dos enlaces que chegam ao destino. Botnets podem gerar parte desse tráfego, mas não são a única fonte possível.
Proprietários de dispositivos comprometidos podem não perceber que eles participam de uma botnet. Por isso, manter dispositivos atualizados e monitorar sinais de abuso ajuda a reduzir o risco.
Do lado do serviço atacado, a primeira indicação pode ser lentidão, erros ou indisponibilidade. Métricas de tráfego e de aplicação ajudam a distinguir sobrecarga de outras falhas.
Em uma aplicação de investimentos, por exemplo, a indisponibilidade impediria o acesso dos clientes durante o incidente. O impacto real dependeria do momento e da duração da falha.
Reflexão e amplificação por serviços como DNS, SSDP ou CLDAP são exemplos de vetores volumétricos. O atacante pode falsificar o endereço da vítima para direcionar respostas a ela; a técnica não exige infectar cada servidor usado como refletor.
Ataques na camada de aplicação enviam requisições que consomem recursos específicos de um site ou API. Algumas se parecem com tráfego legítimo, o que pode tornar a detecção e a mitigação mais difíceis. O volume de banda pode ser relativamente baixo mesmo quando o efeito na aplicação é alto.
Imagine muitas solicitações simultâneas a uma página que exige trabalho do servidor. Se a aplicação não conseguir atendê-las dentro de sua capacidade, usuários legítimos poderão receber respostas lentas ou erros.
O DDoS na camada 7 pode visar uma aplicação específica, enquanto um ataque volumétrico tende a pressionar os enlaces e a infraestrutura de rede.
Controles como limites de requisições, análise de comportamento, cache, desafios e proteção da aplicação podem ajudar, conforme o vetor. Um TCP SYN proxy trata conexões TCP e não substitui uma estratégia para requisições HTTP maliciosas. Orientações da CISA.
Alguns ataques exploram o estado que servidores, firewalls ou balanceadores mantêm para conexões. Uma inundação de pacotes TCP SYN, por exemplo, pode esgotar tabelas ou capacidade de processamento em certas configurações. O efeito depende dos controles presentes e do volume recebido; nem todo pacote TCP incomum constitui um vetor distinto.
As motivações variam e nem sempre são conhecidas durante um incidente. Entre as possibilidades estão extorsão, protesto, vingança, disputa comercial ou busca de notoriedade. Não atribua a autoria ou o motivo apenas pelos sintomas do tráfego.
Um atacante pode exigir pagamento para interromper a sobrecarga. Não há garantia de que o ataque cessará após o pagamento; envolva a equipe de resposta e siga o plano de incidentes da organização.
Um grupo pode tentar interromper um serviço para chamar atenção a uma causa ou prejudicar uma organização. Essas hipóteses exigem evidências antes de se transformarem em conclusão sobre um incidente específico.
Comece pelo serviço que precisa permanecer disponível, pelos caminhos de entrada do tráfego e pela capacidade de resposta da equipe. A combinação de controles depende do tipo de ataque e da arquitetura protegida.
Monitore padrões normais de tráfego, erros e latência. Isso ajuda a reconhecer alterações e a diferenciar uma sobrecarga de falhas de aplicação ou conectividade. Ataques de aplicação podem causar problemas sem grande aumento de banda.
Roteadores de borda podem aplicar filtros e políticas úteis contra alguns ataques, mas a proteção depende de capacidade, configuração e controles em outros pontos da rede. Um ataque volumétrico pode saturar o enlace antes de alcançar o roteador.
Regras locais podem precisar ser combinadas com filtragem a montante, capacidade adicional ou um serviço especializado, conforme o ataque e a topologia da rede.
Capacidade adicional pode absorver parte de um ataque volumétrico, mas não corrige exaustão de recursos da aplicação e pode não bastar quando o enlace de entrada satura.
No blackholing, o operador descarta tráfego para um prefixo ou destino sinalizado. Isso pode preservar o restante da rede, mas também interrompe o serviço legítimo nesse destino; por isso, deve ser uma decisão consciente. RFC 7999.
Firewalls e ACLs podem bloquear padrões específicos de tráfego malicioso quando configurados conforme o serviço protegido. Bloquear indiscriminadamente UDP/53 interromperia DNS legítimo; em reflexão DNS, avalie o fluxo de respostas, filtragem de origem e capacidade de rede antes de definir regras. RFC 5358.
Confirme antecipadamente como acionar operadoras e serviços de mitigação, quais vetores eles cobrem, o tempo de resposta, os limites de capacidade e o tratamento de falsos positivos. Testes e contatos atualizados ajudam a equipe a agir quando o serviço estiver sob ataque. Orientações da CISA.
