DDoS: Do Alerta à Escolha do Modelo – Diagnóstico e Proteção Always-On vs. On-Demand

Quando um pico anômalo de tráfego surge nos gráficos de monitoramento, a primeira reação instintiva é ativar filtros e bloquear tudo o que parece suspeito. No entanto, na prática, essa abordagem precipita frequentemente erros. A proteção contra ataques DDoS (Distributed Denial of Service) não começa com a escolha de um serviço ou a configuração de regras, mas sim com um diagnóstico preciso. Neste artigo, exploraremos o ciclo completo: desde o momento em que um alerta surge até a decisão entre os modelos de proteção Always-On e On-Demand.

Parte 1: Diagnóstico e Resposta

É Realmente um Ataque DDoS? Antes de configurar filtros e bloquear sessões suspeitas, é crucial confirmar se você está, de fato, lidando com um ataque DDoS. Um aumento abrupto no tráfego nem sempre é resultado de ações maliciosas. Na prática, uma parcela significativa de incidentes que se assemelham a um ataque são, na verdade, picos de usuários reais ou particularidades da infraestrutura.

Causas Típicas de Falsos Alarmes:

• Atividade de Marketing e Promoções: O resultado de campanhas publicitárias ou promoções pode aparecer nos gráficos de forma idêntica a um DDoS: um pico súbito de requisições e aumento no consumo de recursos. Isso é especialmente verdadeiro se a infraestrutura não estiver preparada para o aumento da carga e a equipe de suporte não for notificada sobre as atividades de marketing.
• Infraestrutura Não Preparada para a Carga: Um site em crescimento orgânico, com tráfego aumentando gradualmente, pode, em algum momento, atingir o limite de capacidade do servidor. Externamente, a situação de um número crescente de usuários pode se assemelhar a um ataque: requisições se acumulam na fila, o tempo de resposta aumenta e a carga cresce exponencialmente. Essa situação é um indicativo da necessidade de escalonar a infraestrutura. Um exemplo notório foi o site "Tanuki" que ficou indisponível na véspera do Dia Internacional da Mulher devido ao grande volume de pedidos reais – não foi um ataque, mas sim a infraestrutura despreparada para o pico sazonal.
• Alterações no Site que Atraem Bots: Atualizações na estrutura de URLs, adição de endpoints de API abertos, modificações no robots.txt ou a publicação de um grande volume de conteúdo novo podem desencadear uma onda de tráfego de robôs de busca, parsers e scrapers. Embora tecnicamente seja tráfego de bots, não se trata de um ataque, mas sim de uma reação natural do ecossistema às mudanças.
• Auto-ataque por Monitoramento Não Otimizado: Um cenário comum é quando o sistema de monitoramento está configurado de tal forma que cada verificação gera requisições pesadas para o site. Se o intervalo de verificação for muito curto ou se a verificação exigir requisições complexas (renderização de páginas, acesso a banco de dados), o próprio monitoramento se torna uma fonte de carga. Essencialmente, é um DDoS do site pelos próprios instrumentos de monitoramento.
• Arquitetura Não Otimizada e Falhas em Cascata: Tarefas cron mal configuradas, redirecionamentos infinitos, chamadas de API cíclicas entre microsserviços, vazamentos de conexões com o banco de dados – tudo isso pode gerar tráfego interno que sobrecarrega o servidor por dentro. Os gráficos de monitoramento mostram uma anomalia, mas a origem não é um invasor externo, mas sim a própria infraestrutura.

Como Distinguir um DDoS de um Pico Legítimo de Atividade: A chave para um diagnóstico correto é a análise dos logs na primeira etapa. Estes sinais ajudarão a distinguir um ataque real:

• Requisições Homogêneas: URLs idênticos, User-Agents repetitivos, distribuição suspeitamente uniforme ao longo do tempo.
• Fontes de Tráfego: Um ataque frequentemente se origina de fontes atípicas para o público-alvo do projeto.
• Correlação com Eventos: O pico não coincide com o lançamento de publicidade, publicações na mídia, início de promoções ou feriados.
• Comportamento no Site: Bots atacantes não executam JavaScript, não carregam CSS/imagens, não navegam por links internos. Usuários reais geram tráfego associado: carregamento de estáticos, requisições AJAX, eventos de análise.
• Padrões Temporais: DDoS frequentemente exibe um nível de requisições anormalmente estável (por exemplo, exatamente 500 RPS). Tráfego real possui ondas características com altos e baixos.

Somente após confirmar que você está lidando com um ataque, é hora de passar para as medidas de contra-ataque.

Procedimento em Caso de Ataque DDoS Confirmado: Suponha que o monitoramento esteja em chamas: o tráfego aumentou drasticamente, a CPU disparou, os usuários reclamam de timeouts. O que fazer agora?

Passo 1. Ataque Confirmado – Aja:

• Se você possui um serviço externo de anti-DDoS com modelo "On-Demand" (sob demanda) – este é o momento de ativá-lo. O tráfego é redirecionado para os nós de filtragem do provedor, e ele assume o controle. Quanto mais rápido você ativar, menor será a janela em que o site fica vulnerável. Modelos de filtragem pré-configurados e canais de backup são cruciais aqui – sem eles, a transição se prolonga.
• Se você utiliza "Always-On" – o tráfego já passa constantemente pelos nós de filtragem, e o ataque é mitigado automaticamente. Sua tarefa é verificar se a filtragem está correta e não está bloqueando usuários legítimos. Se necessário, ajuste as listas brancas em conjunto com o provedor.
• Se não houver proteção externa, tudo recai sobre você. As ações subsequentes dependem da complexidade do ataque.

Passo 2. Defenda-se com Meios do Servidor (se não houver proteção externa):

• Ataque Simples: Geralmente caracterizado por um padrão previsível: um conjunto limitado de IPs, o mesmo URL, User-Agents idênticos. Com isso, é possível lidar com meios padrão:
  • Rate Limiting no Nginx: Diretivas limit_req_zone e limit_req definem o número máximo de requisições por unidade de tempo de um único IP. Excedentes são rejeitados com código 503.
  • Filtragem por User-Agent: No nível do Nginx, através da diretiva map e da condição if.
  • Bloqueio de IP via iptables: A forma mais rápida se os endereços forem poucos.
  • Automação via fail2ban: Filtragem e bloqueio por regras: número de requisições, padrões nos logs, cabeçalhos anômalos.
  • Bloqueio de Bots com Resposta 444: O Nginx encerra a conexão sem resposta. Eficaz, mas regras agressivas frequentemente afetam usuários reais, tornando o método cada vez menos utilizado.
• Ataque Complexo: Envolve rotação de IPs, mudança de padrões, imitação de comportamento real. Os meios do servidor se esgotam rapidamente. Aqui, a única saída confiável é a conexão de emergência com um serviço externo.

Notas: Na prática, para ataques repetitivos na página principal, uma abordagem eficaz é: um script gera previamente uma cópia HTML estática dela, e no momento do ataque, o tráfego é direcionado para ela. A dinâmica é aliviada, e as demais páginas permanecem acessíveis.

Passo 3. Fim do Ataque: O processo de recuperação geralmente ocorre de forma autônoma e depende de dois fatores:

• Quanto mais poderoso o ataque, maior o tempo para normalização: limpeza de filas, restauração de pools de conexões, reinicialização de processos. Se não houve proteção e a defesa foi manual, o volume de trabalho de recuperação depende do que foi afetado e requer a participação de engenheiros.
• Se um serviço de proteção foi conectado: com Always-On, o serviço continua filtrando o tráfego automaticamente. Com On-Demand, pode haver um pequeno atraso para a desativação manual da proteção. Em caso de ataque refletido, nada precisa ser feito.

A prática demonstra que ataques complexos se tornaram quase um padrão industrial, e um serviço de proteção é agora um item básico. A seguir, analisaremos qual o mínimo básico que se adequa especificamente a você.

Parte 2. Always-On e On-Demand: Análise Detalhada

O que são Always-On e On-Demand – Comparativo Básico: Em sentido amplo, existem dois esquemas de proteção: "Always-On" (proteção contínua) e "On-Demand" (proteção sob demanda). A principal diferença reside no modo de operação: no modelo Always-On, todo o tráfego passa por filtragem constante, enquanto no On-Demand, a proteção é ativada apenas durante um ataque.

Cada esquema possui seus prós e contras.

• Always-On garante que os recursos protegidos estarão disponíveis e que a reação será instantânea, pois o tráfego já está sendo filtrado. A desvantagem deste modelo é o custo: Always-On é mais caro devido à natureza contínua da proteção.
• On-Demand é mais barato, pois a proteção é ativada quando necessário. No entanto, aqui reside a principal desvantagem: a ativação da proteção ocorre apenas após a detecção de um ataque, e esse intervalo entre a identificação do tráfego anômalo e a ativação da proteção cria uma janela de vulnerabilidade que pode resultar em inatividade do recurso.

Diferentes provedores podem atribuir significados distintos a essas definições. Por exemplo, a empresa DDoS-Guard as diferencia também na tipologia de tarifação da proteção de rede: Always-On é filtragem contínua com pagamento mensal, enquanto On-Demand é proteção sob necessidade, com pagamento por pacotes de 24 horas.

Riscos e Vulnerabilidades do On-Demand: A abordagem On-Demand para proteção DDoS é frequentemente vista como a solução ideal em termos de economia. No entanto, na prática, este método apresenta riscos sérios que podem causar danos significativos ao negócio.

Um dos principais problemas é o atraso na ativação dos mecanismos de defesa, que leva a downtime – a tal janela de vulnerabilidade. O sistema precisa de tempo para reconhecer o ataque, decidir que é hora de mudar e implantar a proteção. Mesmo atrasos mínimos podem ser críticos.

Existe também a possibilidade de o recurso ficar indisponível. Por exemplo, em ataques DDoS, a infraestrutura pode ser sobrecarregada antes mesmo que a filtragem seja iniciada. Se uma solução On-Demand, em um ataque do tipo HTTP flood, que gera 10.000 requisições por segundo, só atua após 5 segundos, o servidor provavelmente já estará sobrecarregado.

Em ataques de alta potência – como os populares "pulse wave", onde o tráfego malicioso é direcionado ao recurso em curtos e intensos picos – o On-Demand pode ser um modelo de proteção ineficaz. Se o ataque começa imediatamente com potência máxima, sua primeira onda pode cessar no momento em que o tráfego for redirecionado para os nós de filtragem. Assim que a proteção "sob demanda" for desativada, um novo pico pode começar, e o ciclo se repete.

Ataques complexos na camada de aplicação (L7), que exigem análise detalhada do conteúdo das requisições, representam um perigo particular. Ameaças sofisticadas – como requisições que imitam usuários legítimos, ataques com baixo volume de tráfego ou mudança de padrões – podem passar despercebidas por um longo tempo, até causarem consequências graves: desde vazamento de dados até a paralisação completa do serviço.

Pontos Fortes e Fracos do Always-On: A proteção Always-On DDoS implica filtragem contínua de todo o tráfego através da infraestrutura do provedor de proteção. Essa abordagem cria uma "armadura" robusta contra ataques, mas ao mesmo tempo gera uma série de compromissos que devem ser considerados ao escolher uma solução.

Entre as principais vantagens do Always-On está, antes de tudo, a continuidade da proteção. Ao contrário dos sistemas ativados sob demanda, aqui não há etapa de detecção de ataque e posterior redirecionamento de tráfego – a filtragem começa imediatamente assim que os dados chegam à rede. Isso elimina os intervalos de tempo em que a infraestrutura fica desprotegida, o que é especialmente crítico para serviços com altos requisitos de disponibilidade.

Uma vantagem igualmente importante é a reação instantânea às ameaças emergentes. Como o tráfego é constantemente roteado através dos nós de proteção, o sistema é capaz de neutralizar um ataque sem quaisquer atrasos. Para serviços críticos – como plataformas bancárias, lojas online ou soluções SaaS – a estabilidade operacional se torna um fator chave. Soluções Always-On geralmente possuem capacidade de sobra para suportar grandes ataques. Portanto, essa opção é escolhida onde mesmo uma breve interrupção afeta as finanças ou a reputação.

No entanto, este modelo também tem suas desvantagens. Tomemos um exemplo real: uma determinada empresa firmou um contrato de proteção contínua com um provedor. O ataque pode não ser direcionado a essa empresa, mas a outro cliente do provedor de proteção, e a potência do ataque pode ser tão grande que afete a rede do defensor, bem como seus clientes.

Denis Sivtsov, chefe da área de proteção de rede na camada L3-4 na DDoS-Guard: "Apesar de essa probabilidade existir, hoje os provedores de proteção aprenderam a lidar com essa situação através de canais amplos para recebimento de tráfego, uma grande quantidade de filtros que oferecem amplas possibilidades de supressão de ataques DDoS, e métodos bem estabelecidos de trabalho com clientes frequentemente sujeitos a ataques poderosos."

Outra desvantagem é o preço. Embora seja uma desvantagem discutível: o alto custo das soluções Always-On tem justificativa: a filtragem constante de todo o tráfego requer recursos significativos do provedor, o que se reflete diretamente no preço do serviço. Em comparação com os modelos "sob demanda", o Always-On é consideravelmente mais caro, especialmente para projetos que raramente enfrentam ataques DDoS ou têm um orçamento limitado.

Assim, a proteção Always-On DDoS é mais justificada para serviços que sofrem ataques regularmente, bem como para plataformas onde mesmo interrupções de curta duração são inaceitáveis – por exemplo, sistemas financeiros ou portais governamentais. Nesses casos, os riscos reputacionais de possíveis falhas superam significativamente os custos de manutenção da proteção contínua.

Cenários Adequados: Onde Cada Modelo é Melhor: A escolha entre On-Demand e Always-On não é apenas uma questão de vantagens abstratas. Ela determina diretamente se o negócio resistirá ao ataque e quanto perderá. O On-Demand permanece uma escolha razoável para 70-80% dos projetos que são atacados com menos de uma vez por trimestre.

Serviços/Negócios com Sazonalidade Marcada: O modelo On-Demand é mais adequado para startups e pequenas empresas que enfrentam picos de tráfego episódicos, mas não estão entre os alvos prioritários dos invasores. Podem ser portais corporativos com acesso restrito ou serviços altamente especializados. Para esses projetos, a proteção contínua muitas vezes se torna um gasto excessivo.

Denis Sivtsov, chefe da área de proteção de rede na camada L3-4 na DDoS-Guard: "Não se deve pensar, no entanto, que a proteção "sob demanda" serve apenas para pequenas empresas – grandes empresas também podem usar o On-Demand como seguro. Isso acontece, por exemplo, quando uma grande empresa consegue filtrar ataques até um certo volume de tráfego por conta própria, e tudo o que excede esse limite é delegado a um provedor de proteção especializado, com o qual foi firmado um contrato de proteção "sob demanda"."

O On-Demand tem algumas vantagens significativas. Primeiro, você paga apenas pelo tempo de ataque real. Segundo, para a maioria dos pequenos projetos, um atraso de alguns minutos para ativar a proteção não é crítico – nem todos os ataques começam com potência máxima. No entanto, é importante prever mecanismos de início rápido: modelos de filtragem pré-configurados e canais de backup para comutação de emergência.

Ambientes com Ciclo Contínuo de Transações: O modelo Always-On é vital para organizações onde mesmo interrupções de curta duração levam a perdas sérias. São principalmente instituições financeiras – bancos e sistemas de pagamento, para os quais mesmo um minuto de inatividade pode resultar em perdas de milhões.

Serviços em Tempo Real e de Alta Disponibilidade: O downtime é igualmente crítico para plataformas de jogos e serviços de streaming, cujo funcionamento depende da interação contínua com os usuários. Isso inclui recursos governamentais, frequentemente sujeitos a ataques politicamente motivados.

O modelo Always-On elimina a "janela de vulnerabilidade" durante a comutação. É extremamente importante escolher um provedor com centros de limpeza geograficamente distribuídos – isso minimiza os atrasos. Além disso, é necessário um auditoria regular das regras de filtragem para reduzir o risco de falsos positivos, como o bloqueio de transações legítimas devido a um endereço IP suspeito.

Critérios de Escolha do Tipo de Proteção: Ao escolher um modelo de proteção, vários critérios-chave devem ser considerados:

• Custo do Downtime: Um dos principais fatores: se uma hora de indisponibilidade custa uma quantia significativa ao recurso, a solução Always-On é preferível; se as perdas são toleráveis, pode-se optar pelo On-Demand.
• Tipo de Tráfego: Desempenha um papel significativo. Para APIs com tempos rígidos (por exemplo, negociações em bolsa), a proteção Always-On com nós que garantem atrasos mínimos é ideal. Para conteúdo estático (blogs, landing pages), o On-Demand em combinação com CDN é adequado.
• Recursos da Equipe: A presença de especialistas DevOps capazes de monitorar ameaças e ativar a proteção manualmente permite o uso do On-Demand. Se não houver pessoal dedicado, é melhor escolher Always-On para garantir autonomia.

Exemplos para Setores Específicos: Qual negócio pode se beneficiar da proteção Always-On? Esse modelo é bastante versátil. Principalmente, empresas para as quais o downtime é crítico e que sofrem ataques frequentes devem considerar o Always-On.

• Hosters: Eles hospedam centenas, milhares de clientes (sites de todos os tipos e escalas, projetos de jogos, serviços e muito mais). Um grande número de clientes diferentes = um grande número de projetos = maior probabilidade de ataque. Nessas condições, a proteção contínua é lógica.
• Provedores de Internet: Semelhante aos hosters, os provedores de internet lidam com um grande número de clientes e recursos. A diferença é que o cliente final neste caso pode ser qualquer um – desde o próprio hoster com muitos clientes até grandes corporações com milhares de funcionários, e se ocorrer um ataque DDoS, o downtime custará muito caro à empresa.
• Setor Financeiro: Aqui, o Always-On é o modelo básico, complementado pelo trabalho de um centro de monitoramento de segurança (SOC) e sistemas de detecção de anomalias por IA. Essa arquitetura complexa é justificada pela criticidade excepcional dos dados: o vazamento de informações financeiras pode levar a processos judiciais multimilionários e à perda de licença.

Requisitos regulatórios – como a Lei Federal 152, regulamentos do Banco Central da Rússia e os europeus PSD2 e GDPR – prescrevem monitoramento contínuo e resposta rápida a incidentes. Ao mesmo tempo, a natureza das ameaças em fintech é de alta complexidade: phishing, transações fraudulentas, ataques de ameaças persistentes avançadas (APT) exigem detecção em tempo real. Sistemas baseados em inteligência artificial permitem identificar padrões atípicos – como transferências anômalas – significativamente mais rápido do que regras manuais.

A ausência de proteção abrangente em fintech acarreta sérias consequências. Primeiro, é uma violação direta dos requisitos regulatórios, que pode resultar em multas ou revogação da licença. Segundo, abre oportunidades para ataques direcionados, incluindo fraudes no sistema SWIFT. Terceiro, qualquer vazamento ou incidente mina a confiança dos clientes em uma instituição financeira, o que, a longo prazo, pode destruir o negócio.

A proteção "sob demanda" é mais procurada por empresas com atividade sazonal, infraestrutura não crítica e orçamento limitado. O On-Demand também é adequado quando o recurso é atacado raramente.

• Serviços de Eventos: A proteção "sob demanda" é relevante durante a venda de ingressos.
• Plataformas Educacionais: Podem sofrer picos de carga durante o recrutamento de estudantes ou exames.
• Mídia e Recursos de Notícias: Podem atrair a atenção de invasores ou um grande número de visitantes em períodos de eventos importantes que cobrem.

Assim, a escolha do modelo de proteção não é um detalhe técnico, mas uma decisão estratégica que afeta a estabilidade financeira da empresa, sua conformidade com as normas legais e o nível de confiança dos usuários.

Recomendações: Com base na experiência prática, podemos formular recomendações-chave:

• Não espere o primeiro ataque. Conectar a proteção em modo de emergência é estressante e propenso a erros. É melhor incluir a proteção DDoS na arquitetura desde a fase de planejamento.
• Primeiro diagnóstico, depois bloqueios. Certifique-se de que o pico de tráfego é realmente um ataque, e não o resultado de atividade de marketing, crescimento de audiência ou problemas de infraestrutura.
• Tenha um plano B pronto. Scripts para gerar páginas estáticas, modelos de regras Nginx e iptables, fail2ban configurado.
• Escolha o modelo de acordo com o perfil de risco. Always-On – para projetos críticos com ataques frequentes. On-Demand – para orçamento limitado e incidentes raros.
• Considere a evolução dos ataques. Se os ataques se repetem – eles se tornam mais complexos. Após cada incidente, analise os logs: qual foi o vetor, quais regras funcionaram, quais passaram. Revise os limites de rate-limiting e as regras do WAF trimestralmente.
• Monitore falsos positivos. Atualização de listas brancas, ajuste de limites, análise de bloqueios – uma tarefa constante.
• Não bloqueie o tráfego cegamente. Métodos agressivos (por exemplo, código 444 do Nginx) podem descartar usuários reais.

DDoS-ataques já se tornaram uma atividade maliciosa cotidiana, e a proteção DDoS se tornou uma ferramenta básica: como backup ou monitoramento.

É importante saber distinguir ataques DDoS de outras causas de aumento abrupto de carga, ter um plano de resposta e um serviço de proteção contra DDoS.

A escolha entre os modelos Always-On e On-Demand deve depender dos riscos específicos do seu projeto, e não do que é "melhor em princípio". Para sistemas críticos com altos requisitos de disponibilidade, o Always-On é justificado. Para a maioria dos outros projetos, que sofrem ataques raramente ou irregularmente, o On-Demand permanece um compromisso razoável entre riscos e custo da ferramenta.

Interessantes detalhes e notícias da ITSumma – em nosso canal do Telegram.