Extorsão DDoS: o que realmente impede um ataque a um site de classificados adultos, e o que não impede

A manhã em que o diretório para de carregar sem motivo aparente

Costuma começar sempre do mesmo jeito. O site fica lento, depois para de carregar completamente, depois volta por dez minutos e cai de novo. O painel de hospedagem não mostra nada estranho: nenhum deploy falhado, nenhum banco de dados no limite, nenhum certificado vencido. Um chamado de suporte ao provedor recebe como resposta que tudo parece normal do lado deles, o que é tecnicamente verdade e completamente inútil, porque o problema não está do lado deles, está no fio entre a internet e o lado deles.

O que realmente está acontecendo, na grande maioria desses casos, é um ataque de negação de serviço distribuído: uma onda de tráfego, geralmente vinda de milhares de dispositivos comprometidos, pensada para impedir que o site responda a visitantes reais. Não é raro nem exótico. A equipe de inteligência de ameaças da Cloudflare relatou ter mitigado cerca de 5.343 ataques DDoS em nível de rede por hora em sua rede no primeiro semestre de 2026, uma média de cerca de 128.000 por dia. A maioria desses ataques é curta e pequena em comparação com os maiores incidentes já registrados: 96,62% ficaram abaixo de 500 Mbps, e 90,60% terminaram em menos de dez minutos. "Pequeno", porém, é relativo: um ataque de 100 Mbps basta para derrubar um servidor típico sem proteção, uma fração do que aparece numa noite comum de semana contra sites de que ninguém jamais ouviu falar.

O motivo de negócio por trás de um ataque específico quase sempre importa menos do que os operadores supõem. Pode ser um diretório rival tentando tirar um concorrente do ar num fim de semana de muito movimento, um anunciante banido se vingando com um serviço barato de ataque sob encomenda, um oportunista entediado que encontrou o site por um escaneamento aleatório, ou o primeiro passo de uma tentativa de extorsão. A resposta que realmente protege o site é quase idêntica independentemente de qual seja, o que é uma boa notícia, porque o motivo quase nunca chega a ser confirmado.

Diretórios de classificados são um alvo mais fácil do que seus donos costumam supor. Muitos funcionam num único VPS econômico escolhido justamente porque aceitava o negócio desde o início, com o DNS apontando direto para esse servidor porque ninguém pensou em fazer diferente quando o domínio foi configurado. A receita depende da disponibilidade de um jeito que um site institucional não conhece: cada hora fora do ar é uma hora de renovações vencidas, cadastros abandonados, e anunciantes que abrem a aba de um concorrente em vez de voltar para checar se o site original se recuperou.

O bilhete de resgate, e por que pagá-lo não resolve nada

Alguns ataques vêm com uma exigência anexada. O padrão, conhecido no setor de segurança como ransom DDoS ou RDoS, geralmente começa com um breve ataque de demonstração ou uma ameaça direta por e-mail, seguida de uma instrução para pagar uma quantia, quase sempre em criptomoeda, para interromper um ataque maior ou evitar que ele comece. Grupos construídos exatamente sobre esse roteiro, DD4BC e o Armada Collective entre os primeiros, usam isso desde cerca de 2014, e atores mais recentes continuam recorrendo à mesma estrutura porque ela segue funcionando com frequência suficiente para valer o esforço.

Pagar parece a saída mais rápida quando cada hora de inatividade custa renovações reais, e é exatamente essa pressão que a exigência foi feita para criar. O problema é que nada na transação obriga o atacante a fazer qualquer coisa. Não há contrato de suporte atrás de um bilhete de resgate. O caso mais citado como alerta é o da ProtonMail em 2015, que pagou e viu os ataques continuarem do mesmo jeito, concluindo depois publicamente que o pagamento não tinha comprado nada. Pesquisadores de segurança que acompanham esses grupos relatam o mesmo padrão com frequência suficiente para tratá-lo como o resultado padrão, não a exceção.

Pagar também muda como a conta é vista na próxima vez. Um alvo conhecido por pagar é um alvo mais atraente, para o mesmo grupo e para outros que ficam sabendo através dos mesmos mercados criminosos que vendem serviços de ataque sob encomenda. O incentivo criado por isso vai exatamente na direção errada para um negócio que preferiria nunca mais passar por isso.

O que realmente ajuda durante uma exigência ativa é chato e burocrático: guardar a mensagem com todos os cabeçalhos em vez de simplesmente ler e apagar, avisar imediatamente a equipe de abuso ou segurança do provedor de hospedagem e da CDN, já que eles podem já estar rastreando o mesmo atacante contra outros clientes, e registrar um boletim na unidade de polícia competente em crimes cibernéticos mesmo sem esperar um retorno rápido, porque são os relatos agregados que, com o tempo, permitem que agências e provedores de infraestrutura ajam contra grupos recorrentes. Nada disso para o ataque por si só. A próxima seção é o que realmente para.

O que realmente para o tráfego antes que ele chegue ao servidor

A solução que funciona é estrutural, não negociável: colocar uma rede de distribuição de conteúdo ou um proxy reverso na frente do site, para que o tráfego de ataque seja absorvido e filtrado na borda, usando a capacidade global de um provedor, antes de chegar ao pequeno servidor que de fato executa o código do diretório. É o mesmo papel que uma CDN já desempenha para desempenho comum, estendido a um tráfego que é ativamente hostil, e não apenas volumoso.

O custo é um obstáculo menor do que os operadores costumam supor. Grandes provedores de CDN costumam incluir mitigação DDoS em nível de rede sempre ativa em seu plano gratuito, como parte do serviço básico e não como um complemento pago, justamente porque absorver esse tipo de tráfego em escala sai mais barato fazer para todo mundo do que revisar e cobrar cada ataque individualmente. A proteção básica de que um diretório de classificados precisa muitas vezes já está disponível sem custo adicional. O problema quase nunca é o preço. É a configuração.

O erro de configuração mais comum é deixar o endereço IP real do servidor de origem descobrível mesmo depois de colocar uma CDN na frente do domínio principal. Um registro de servidor de e-mail, um subdomínio antigo de staging, um painel de administração com seu próprio hostname, ou um registro DNS que ninguém lembrou de atualizar ao configurar a CDN podem continuar apontando direto para a origem. Um atacante que encontra esse IP, muitas vezes com nada mais sofisticado que uma busca no histórico de DNS passivo, ataca o servidor real diretamente e passa direto pela CDN que deveria estar protegendo-o. A solução é uma auditoria completa de cada registro DNS do domínio, confirmando que cada um passa pela CDN ou que realmente não precisa ser público, e então tratar o IP de origem como algo a ser ocultado ativamente, não um detalhe de fundo de que ninguém mais se lembra depois do dia da configuração.

Essa configuração precisa ser testada antes de um ataque, não durante. Um operador que nunca confirmou de fato que cada registro passa pela CDN, ou que não sabe de cabeça para qual segunda CDN o negócio migraria se a atual caísse, descobre as falhas no pior momento possível. Revisar a configuração uma vez, numa tarde tranquila, custa uma hora. Descobrir uma falha no meio de um ataque custa muito mais do que isso.

Escolher um fornecedor que realmente queira manter a conta

Nem todo provedor de CDN ou anti-DDoS trata conteúdo adulto legal da mesma forma, e vale a pena verificar isso antes de construir uma configuração em torno de um, não depois. Alguns dos maiores provedores de infraestrutura operam seu serviço de segurança e roteamento de tráfego de forma genuinamente neutra em relação ao conteúdo, atendendo quase qualquer material legal sem isolar conteúdo adulto como categoria, o que ajuda a explicar por que de vez em quando atraem críticas públicas pelo punhado de sites que terminam protegendo. Outros escrevem uma proibição direta de material "obsceno ou pornográfico" diretamente em sua política de uso aceitável padrão, o mesmo tipo de cláusula que aparece em contratos de hospedagem e registro de domínio para esse setor. A reputação de um provedor como focado em segurança, e não em conteúdo, não diz a um operador em qual categoria ele se encaixa; só ler a política de fato diz.

É a mesma margem de decisão que já governa se um host, uma CDN ou um registrador decidem que um negócio de classificados não é bem-vindo em sua infraestrutura, um nível mais próximo da questão específica da mitigação DDoS do que da hospedagem em geral. Um provedor que aceita a conta hoje sob uma cláusula vaga ou nunca testada ainda pode agir sobre essa cláusula depois, e um operador que só descobre com que tipo de provedor está lidando depois de um aviso de rescisão já perdeu a chance de escolher com calma uma alternativa.

A verificação prática é simples e leva poucos minutos: buscar na política de uso aceitável ou nos termos de serviço do provedor as palavras adult, pornographic, obscene e escort antes de assinar, em vez de supor que um fornecedor de segurança é neutro por padrão só porque não é um processador de pagamentos nem um banco. Se a política for silenciosa sobre isso, esse silêncio também não é garantia nenhuma, só uma cláusula que ainda ninguém testou. Manter um segundo provedor em mente, com uma configuração de DNS capaz de apontar para ele em uma hora em vez de um dia, importa aqui exatamente como importa para a hospedagem em geral.

Quanto uma queda realmente custa, depois que termina

Mesmo um ataque mitigado rapidamente deixa custos que aparecem depois que o tráfego para. Um site instável por algumas horas, em vez de totalmente fora do ar, ainda pode quebrar os processos silenciosos de fundo que mantêm um negócio de assinatura funcionando: uma bandeira de cartão tentando alcançar um webhook de cobrança durante uma queda intermitente se comporta como uma tentativa de renovação que nunca chega à rede do cartão, e o anunciante do outro lado só vê um cartão recusado, sem ideia de que a causa real foi um ataque que não tinha nada a ver com ele.

Os buscadores são igualmente implacáveis ao distinguir entre "sob ataque" e "fora do negócio". Um domínio inacessível por um período prolongado é tratado por um rastreador do mesmo jeito em qualquer um dos dois casos, e páginas que estavam bem posicionadas antes da queda não necessariamente voltam à mesma posição depois que o site volta ao ar, somando um segundo custo, mais lento, às horas realmente perdidas.

Um aviso breve e claro aos anunciantes não custa nada e evita um resultado pior do que o próprio ataque: um anunciante que vê erros intermitentes sem explicação tende a supor que o negócio fracassou silenciosamente e começa a olhar para um concorrente, enquanto o mesmo anunciante, informado claramente de que o site está sob ataque, que a cobrança está pausada durante a interrupção e que o serviço deve voltar dentro de um prazo informado, geralmente espera em vez de ir embora.

A versão útil deste artigo é a que se lê antes de tudo isso acontecer, não durante. Confirme, hoje, que cada registro DNS que aponta para o site passa por uma CDN em vez de expor a origem diretamente. Confirme que a mitigação DDoS do nível básico da CDN está de fato ativada, e não apenas presumida, porque alguns provedores a entregam desativada por padrão em certos planos. Anote, num lugar que sobreviva à queda do site principal, os contatos reais de suporte e abuso do host e da CDN, com os números de conta ao lado. Nada disso é caro ou técnico demais para precisar de um especialista. Só precisa acontecer antes que a primeira exigência chegue, porque não existe versão desse problema que fique mais fácil de resolver enquanto já está acontecendo.