Entre os bots na Black Friday, o que mais custa a uma loja raramente é o que tenta derrubar o site. É o que compra o estoque da oferta antes do cliente, testa senhas vazadas no login e cartões roubados no checkout e coleta preços para um concorrente, enquanto o cliente real encontra o produto esgotado ou um checkout mais lento do que deveria.
Proteger o e-commerce de bots desse tipo depende de três decisões, que são pontuar a automação nos caminhos onde ela causa prejuízo, dar uma saída a quem foi classificado errado e calibrar a proteção antes do pico, com o tráfego da própria loja, em vez de ajustá-la no meio do evento. A seguir, veja como montar essa proteção na Azion, do login às APIs do app, e como medir se ela funcionou. O mesmo roteiro vale para qualquer pico de vendas, como Cyber Monday, Natal e lançamentos de produto.
O que muda no tráfego de bots na Black Friday?
Nos dias de oferta, o estoque disputado, as contas com saldo e os preços promocionais valem mais para quem opera bots, e é para eles que a automação se volta.
Esse tráfego se concentra em três tipos de ataque, cada um num ponto diferente da loja:
- Scalping e hoarding, em que bots compram ou reservam no carrinho o estoque das ofertas mais disputadas, seja para revender, seja só para tirá-lo de circulação.
- Credential stuffing e teste de cartão, em que bots testam no login listas de senhas vazadas em outros serviços e, no checkout, números de cartão roubados, para descobrir quais ainda funcionam.
- Scraping de preço e estoque, em que concorrentes e revendedores coletam as páginas e as APIs da loja para acompanhar preços e disponibilidade.
Nem sempre o prejuízo vem com volume, já que um script que testa cartões pode passar despercebido nos gráficos de tráfego e ainda assim gerar chargebacks, e por isso a proteção começa pelos caminhos onde cada requisição vale mais.
Por que login, cadastro e checkout pedem tratamento diferente?
Nem toda página da loja merece o mesmo rigor. Um bot de busca na vitrine é bem-vindo, enquanto uma tentativa automatizada de login pode terminar numa conta invadida, e é por isso que o caso de uso Bloquear account takeover em fluxos de login e checkout aplica o Bot Manager só no login, no cadastro e no checkout, com uma resposta diferente para cada um.
No login e no cadastro, quem atinge o limite de score definido pelo time, o threshold, é redirecionado para um desafio, o ALTCHA, uma alternativa open source ao CAPTCHA que roda como função no firewall, e uma pessoa que o resolve segue sem ser desafiada de novo. No checkout, a resposta é o bloqueio com 403, porque um script de teste de cartão não resolve desafios e um cliente com o pagamento em andamento não deve ser interrompido por um.
O WAF (Web Application Firewall) cobre os mesmos três caminhos, procurando payloads de ataque como injeção num campo de formulário, que o Bot Manager não inspeciona.
Na arquitetura de prevenção de fraudes online, a requisição passa pelo firewall nesta ordem: primeiro a regra do ALTCHA, que reconhece quem já resolveu o desafio, depois o WAF e, por último, uma instância do Bot Manager por tipo de caminho.
Só o que fica abaixo do threshold chega à aplicação e, dali, ao sistema de identidade ou ao meio de pagamento, e cada decisão vira uma linha de relatório que vai para o Real-Time Events e, pelo Data Stream, para as ferramentas do time de fraude.
Como funciona o gerenciamento de bots no Bot Manager
O Bot Manager, solução de bot management da Azion, não toma uma decisão de sim ou não. Cada regra que a requisição aciona soma pontos a um score, e as regras se dividem em seis classes, que são assinaturas de bots maliciosos, bots com script, comportamento malicioso de navegador, intenção maliciosa, inteligência de reputação e provedores de nuvem, como explica a página de pontuação de bots. A ação só dispara quando o score chega ao threshold que o seu time definiu, e o que fica abaixo dele segue para a aplicação.
Cada requisição recebe também um veredito, que pode ser tráfego legítimo, bot bom, bot malicioso ou em avaliação, e um cliente visto pela primeira vez fica em avaliação por até 15 minutos em vez de ser recusado por ser novo, o que importa num dia em que muita gente acessa a loja pela primeira vez.
Quando o score chega ao threshold ou o ultrapassa, o Bot Manager executa uma de sete ações, listadas na página de argumentos:
| Ação | O que faz |
|---|---|
allow | Deixa a requisição seguir, seja qual for o score |
deny | Responde com 403 |
drop | Encerra a requisição sem resposta |
redirect | Redireciona para uma URL, como a do desafio ALTCHA |
custom_html | Responde com um HTML e um status definidos por você |
random_delay | Espera de 1 a 10 segundos, escolhidos ao acaso, e deixa a requisição seguir |
hold_connection | Mantém a conexão aberta por 1 minuto e depois a descarta |
As duas últimas são as mais úteis contra o scalping. Um bot que disputa estoque depende de velocidade, e random_delay tira essa vantagem sem recusar a requisição, de modo que um cliente classificado errado ainda completa a compra, só que alguns segundos mais devagar.
O hold_connection vai além e prende a conexão por um minuto antes de descartá-la, o que encarece cada tentativa de quem dispara milhares delas, mas também derruba a requisição de quem foi classificado errado, então reserve essa ação para os scores mais altos.
O scalping acontece antes do checkout, quando o bot adiciona o produto ao carrinho, e por isso pede uma instância própria do Bot Manager no caminho de adicionar ao carrinho, com random_delay, separada da instância do checkout, que continua com deny. O scraping de vitrine e de páginas de produto não é o foco deste guia, mas uma instância nesses caminhos com a ação allow ajuda a medir quanto dele existe antes de decidir como responder.
Como preparar a proteção para qualquer pico de vendas?
O threshold que funciona para uma loja não funciona necessariamente para outra, porque o score do tráfego legítimo depende do público, dos navegadores e dos integradores de cada operação. Por isso, a preparação acontece em quatro fases, com o tráfego real da loja, e cada fase termina quando cumpre um critério, e não quando chega uma data no calendário. Antes de começar, confira que o firewall está associado ao workload da loja, com os módulos WAF e Functions ativos, e que o ALTCHA foi instalado pelo Marketplace. Vale também reunir segurança, fraude e e-commerce para definir os caminhos críticos e quantos desafios a clientes reais o negócio aceita, já que é o time de e-commerce quem sente o falso positivo na conversão.
Fase 1: observar
Coloque o Bot Manager em modo de observação nos caminhos críticos, com a ação allow, que pontua e registra cada requisição sem recusar nenhuma, e com um threshold inicial explícito, já que na edição completa do Bot Manager o padrão é infinito e, sem um valor definido, nenhuma requisição chega a ele. Aplique também o WAF nos mesmos caminhos em modo de registro (Logging), que aponta o que seria bloqueado sem bloquear, com uma exceção, já que mesmo em Logging o WAF recusa requisições POST com formato inválido.
A observação precisa cobrir pelo menos um pico de tráfego real, como uma campanha menor ou uma pré-venda, e serve também para identificar o tráfego legítimo que não é cliente, como monitoramento, parceiros, integradores, retornos do meio de pagamento e bots de busca. Mantenha o threshold fixo durante toda a fase, porque o veredito depende do threshold em vigor e mudá-lo no meio reclassifica o tráfego observado. A fase termina quando esse tráfego está mapeado e você sabe onde fica o score dos seus clientes.
Fase 2: calibrar
Leia o relatório do Bot Manager e a aba Tuning do WAF, separe os scores do tráfego que você reconhece dos scores do tráfego que você não reconhece e escolha o threshold no intervalo entre os dois. As regras que insistem em pontuar tráfego legítimo podem ser desativadas na instância, o que vale para todos os clientes daquele caminho, e quando a regra só incomoda clientes num caminho específico, restringir os caminhos da instância costuma ser a saída melhor.
No WAF, os registros de falso positivo viram exceções. Como o Tuning lê no máximo os últimos 3 dias, a revisão precisa ser semanal, e a fase termina quando duas revisões seguidas não trazem falso positivo novo.
Fase 3: aplicar aos poucos
Ligue o bloqueio caminho por caminho, começando pelo login. O modo do WAF é definido na regra do firewall que o chama, e cada instância do Bot Manager tem a própria ação, então dá para bloquear em /login e manter /checkout só registrando até que os dados dele também estejam limpos.
Um caminho está pronto quando a fatia de desafios resolvidos fica estável, sinal de que o threshold não entrou na faixa de score dos clientes. Nesta fase, crie também a regra que bloqueia os endereços de uma network list de bloqueio temporário, ainda vazia, e combine quem pode incluir endereços nela durante o pico.
Fase 4: operar e revisar
No pico, acompanhe em vez de reconfigurar. Os relatórios do Bot Manager e os eventos do WAF chegam ao SIEM (Security Information and Event Management) pelo Data Stream, onde o time de segurança e o de fraude cruzam as decisões com os próprios sinais, e as linhas de relatório do Bot Manager saem pela fonte de dados de Functions, que exige a assinatura de Functions. Se aparecer um endereço abusivo, quem foi combinado na fase anterior usa o bloqueio temporário e adiciona o IP à lista com uma data de vencimento em UTC, no formato 198.51.100.7 --LTAAAA-MM-DDTHH:MM:SSZ #abuso no login.
Como a regra já existe, a ação mexe só na lista, e não na política do firewall, mas o vencimento não remove a entrada sozinho, porque a Azion só descarta as entradas vencidas na próxima vez que a lista é gravada. Depois do pico, revise os scores, os desafios resolvidos e os endereços bloqueados, e use esses dados como ponto de partida da observação do próximo evento.
Para a Black Friday, comece pelo menos três semanas antes, porque cada fase precisa de ao menos uma revisão semanal. Se o evento já está mais perto, o roteiro continua valendo, só que comprimido, e o passo que não dá para pular é a observação, porque é ela que mostra onde fica o score dos seus clientes.
E no app mobile e nas APIs?
O app e as APIs de estoque e preço são alvo de scraping e de hoarding e não carregam o cookie de sessão que o Bot Manager usa para avaliar navegadores. Por isso, o caso de uso Proteger APIs públicas contra abuso monta um perímetro com quatro regras no firewall, nesta ordem:
- WAF no caminho da API, que, em modo de bloqueio, recusa padrões de ataque, corpos grandes demais e JSON que não pode ser lido.
- Validação de JWT (JSON Web Token), uma integração do Marketplace que roda em Functions e recusa com
400ou401quem chega sem um token válido. - Bot Manager no modo
api, que deixa de lado as verificações de cookie de sessão, feitas para navegadores. Nesse caminho, configure a açãodenyem vez deredirect, porque um cliente de API não resolve desafios. - Rate limit por IP, na última regra, que responde com
429às requisições simultâneas acima do limite.
O rate limit deve partir do IP legítimo mais pesado que aparece nos logs, para não barrar o próprio app, já que em redes móveis muitos clientes podem sair pelo mesmo IP da operadora. A resposta 429 também não diz quando tentar de novo, então combine com o time do app como tratá-la. O modo api é documentado para a edição completa do Bot Manager, e a edição Lite o ignora.
Como saber se a proteção funcionou?
O caso de uso de account takeover propõe três medidas, e todas devem ser lidas com o threshold anotado ao lado, porque o veredito muda junto com ele:
| O que medir | Onde ler | Sinal de que está funcionando |
|---|---|---|
| Tentativas automatizadas bloqueadas | Top Bot Action no painel do Bot Manager, no Real-Time Metrics | deny e redirect concentram o tráfego automatizado nos três caminhos |
| Falso positivo em clientes reais | Desafios resolvidos no mesmo painel e o campo challenge_solved do relatório | Uma fatia estável de desafios resolvidos, já que cada um é uma pessoa que o Bot Manager sinalizou |
| Ataque que ainda chega à origem | Linhas do relatório com ação allow, lidas junto com o score | Nenhum grupo de clientes automatizados parado logo abaixo do threshold |
Os mesmos dados podem ser consultados pela API de GraphQL do Real-Time Metrics. O dataset botManagerMetrics, disponível para contas com o Bot Manager, guarda por dois anos as requisições agrupadas por ação, veredito e resultado do desafio, o que permite acompanhar cada medida ao longo do evento.
Para o falso positivo, acompanhe a fatia de desafios resolvidos e desconfie quando ela sobe de um dia para o outro, sinal de que o threshold entrou na faixa de score dos seus clientes. Já o dataset botManagerBreakdownMetrics mostra as URLs e os IPs que os bots mais acessaram e ajuda a achar um caminho que ficou de fora da proteção.
Checklist por fase
| Fase | O que fazer | Onde |
|---|---|---|
| Observar | Bot Manager com allow, threshold explícito e internal_logs: 2 em login, cadastro, carrinho, checkout e API | Firewall, instâncias de função |
| Observar | WAF em Logging nos mesmos caminhos | Firewall, regra com Set WAF |
| Observar | Data Stream enviando os relatórios para o SIEM | Data Stream |
| Observar | Tráfego legítimo que não é cliente mapeado, como monitoramento, parceiros, meio de pagamento e bots de busca | Relatório do Bot Manager |
| Calibrar | Threshold definido a partir do score dos clientes e regras ruidosas desativadas | Relatório do Bot Manager |
| Calibrar, toda semana | Falsos positivos do WAF transformados em exceções | Aba Tuning do WAF |
| Aplicar aos poucos | Bloqueio ligado caminho por caminho, começando pelo login | Firewall |
| Aplicar aos poucos | random_delay no caminho de adicionar ao carrinho, em instância própria | Instâncias do Bot Manager |
| Aplicar aos poucos | Regra de bloqueio da network list temporária criada, com a lista vazia e um responsável definido | Firewall, network lists |
| Operar e revisar | Acompanhar as métricas e usar o bloqueio temporário para IPs abusivos | Real-Time Metrics, network lists |
| Operar e revisar | Dados do pico revisados como ponto de partida do próximo evento | Relatório do Bot Manager, SIEM |
Como o Bot Manager roda no mesmo firewall e nas mesmas regras do WAF, essa proteção não exige um segundo fornecedor de bots, com outro console e outro contrato, e cada decisão chega às mesmas ferramentas que o time de segurança já usa.
A HeroSpark, plataforma de educação digital, usa essa combinação, e o CTO da empresa resume o resultado no caso de sucesso: “Quando enfrentamos ataques, o WAF, Bot Manager e DDoS Protection nos permitiram mitigar ameaças sem interrupções.”
Para chegar à Black Friday com a proteção calibrada, fale com um especialista da Azion e veja como colocar o Bot Manager em observação no login e no checkout da sua loja, para definir o threshold a partir do tráfego real dos seus clientes. Se preferir começar por conta própria, instale o Bot Manager Lite pelo Marketplace, disponível em qualquer plano da Azion, e passe para a edição completa do Bot Manager quando precisar do modo api e do score dinâmico.
Para outras frentes da preparação, veja também quão rápido sua loja reage a ameaças, segurança de APIs além do WAF e a diferença entre os bots de IA de busca, de agente e de treinamento, que não devem ser tratados da mesma forma que um bot de scalping.
Perguntas frequentes
Como saber se meu e-commerce está sendo atacado por bots?
Os sinais mais comuns são picos de login com falha, típicos de credential stuffing, muitas compras recusadas pelo adquirente em sequência, ofertas esgotadas em segundos e acessos em volume às APIs de preço e estoque. Para confirmar, coloque o Bot Manager em modo de observação nesses caminhos e leia o score de cada requisição.
O que é scalping?
Scalping é o uso de bots para comprar ou reservar o estoque de produtos disputados antes dos clientes, geralmente para revender por um preço maior. Na Black Friday, ele atinge as ofertas com estoque limitado. O random_delay reduz a vantagem de velocidade do bot sem recusar a requisição, e o hold_connection prende a conexão por um minuto antes de descartá-la.
Bloquear bots pode barrar clientes reais?
Pode, se o threshold for definido sem olhar o tráfego da loja. Por isso, a proteção começa em observação, o threshold é escolhido a partir do score dos clientes reais, e o login usa o redirecionamento para um desafio em vez do bloqueio, o que dá a quem foi classificado errado uma forma de seguir.
Quanto tempo antes da Black Friday devo configurar a proteção contra bots?
Para a Black Friday, comece pelo menos três semanas antes, para que haja tempo de observar, calibrar e ligar o bloqueio caminho por caminho, com uma revisão por semana. Como o Tuning do WAF lê só os últimos 3 dias, a revisão dos falsos positivos precisa se repetir toda semana até o evento, e o mesmo roteiro vale para qualquer outro pico de vendas.
Como proteger o app mobile de bots?
Como o app não carrega o cookie de sessão usado para navegadores, use o Bot Manager no modo api, com a ação deny, junto com a validação de JWT, o rate limit por IP no caminho da API e o WAF.
