Social Rocket
Tínhamos o Cloudflare Bot Fight Mode ativo. O tráfego suspeito chegava mesmo assim até ao site.
Segundo a nossa experiência como operadores, os desafios de navegador também não funcionavam de forma fiável. O mesmo aconteceu com uma abordagem testada anteriormente chamada „precursor“. No fim, o decisivo não foi mais uma função genérica de bot, mas uma regra adaptada exatamente aos padrões de pedidos que observámos.
Os nossos agentes de IA identificaram dois padrões de scraping distintos no tráfego e traduziram-nos numa estratégia de bloqueio da Cloudflare direcionada. As regras combinam características do navegador, Fetch Metadata, redes de origem, referrers, páginas de entrada e a identificação de crawlers verificados pela Cloudflare. Os pedidos correspondentes são terminados diretamente na edge com HTTP 403.
Propositadamente não publicamos as impressões digitais completas. Uma regra anti-scraping não é um bom lugar para um changelog público destinado aos scrapers.
O que nos chamou a atenção
A primeira pista não veio de um único evento de segurança, mas da combinação de vários pontos de medição.
Um snapshot do Minilytics mostrou 544 sessões diretas com zero conversões de saída medidas. Entre duas horas concluídas, as sessões diretas subiram de 24 para 163.
Ao mesmo tempo, a Cloudflare registou numa janela de 30 minutos analisada aproximadamente 17.700 pedidos HTTP, dos quais cerca de 15.400 chegaram ao origin. Um excerto de cinco minutos do origin continha 1.980 pedidos de 1.238 endereços IP diferentes.
É importante separar as grandezas: um pedido HTTP não é uma sessão. E „zero conversões“ significa, neste contexto, zero eventos de saída configurados disparados – não zero vendas ou zero receita comprovados.
Ainda assim, tínhamos sinal suficiente para decompor o tráfego com mais detalhe.
Padrão 1: o navegador dizia Chrome – os metadados do pedido não batiam certo
O primeiro grande grupo rodava massivamente entre endereços IP e países. Os clientes apresentavam-se como navegadores Chrome em Windows e alternavam entre várias identidades Chrome.
No excerto analisado, 1.628 pedidos de 1.120 endereços IP em 100 países pertenciam a este padrão. Uma grande parte deles consultava adicionalmente os dados de página do Next.js.
Isso, por si só, ainda não é prova de bot. Pedidos RSC também surgem durante a navegação normal em páginas Next.js.
A contradição tornou-se interessante noutro ponto: os pedidos alegavam uma identidade de browser moderna, mas faltava por completo um atributo de Fetch Metadata que esperaríamos neste tipo de pedido.
A nossa primeira lógica de bloqueio combina, por isso, várias condições:
- Pedido para um host da Srocket
- GET
- identidade Windows Chrome compatível com o padrão observado
- cabeçalho Fetch Metadata em falta
- nenhum bot verificado pela Cloudflare
- nenhum caminho interno do Next.js ou da API
A lista concreta de versões não é publicada.
Essa é a diferença decisiva em relação a uma regra grosseira do tipo „bloquear a versão X do Chrome“: não é uma única propriedade que dispara o bloqueio, mas a contradição entre a identidade de browser declarada e o contexto do pedido realmente enviado.
A Cloudflare disponibiliza `cf.client.bot`, um campo que identifica bots e rastreadores conhecidos e legítimos. Estes rastreadores verificados ficam excluídos da nossa lógica de bloqueio.
Padrão 2: desta vez, o pedido do browser parecia plausível
Pouco depois, surgiu um segundo padrão.
Estes pedidos tinham cabeçalhos semelhantes aos de um browser e também um valor `Sec-Fetch-Site` normal. Por isso, não caíam na primeira impressão digital.
Aqui, o sinal estava na combinação de origem, perfil do browser e página de destino.
Observámos entradas diretas em HTML a partir de um conjunto rotativo de redes de origem. Os pedidos usavam apenas poucos perfis de browser exatamente repetidos, chegavam sem referrer e atingiam de forma direcionada um pequeno grupo das nossas páginas de comparação.
São precisamente estas redes de origem rotativas que tornam os endereços IP pouco úteis como impressão digital. Quem quiser perceber melhor o lado técnico encontra no nosso comparativo de proxies as diferenças entre os tipos de proxy e fornecedores mais comuns.
A nossa segunda lógica de bloqueio combina, por isso:
- um conjunto de origem observado
- um dos perfis de browser exatamente repetidos
- GET
- referrer vazio
- um pequeno grupo definido de páginas de entrada afetadas
- nenhum bot verificado pela Cloudflare
Importante: não bloqueamos um ASN inteiro de forma generalizada, nem visitantes sem referrer de forma generalizada. Só a combinação das características conduz ao bloqueio.
Também os blocos de rede concretos, os User Agents e as combinações de páginas permanecem internos.
Porque é que `Sec-Fetch-Site: none` não é um sinal de bot
O segundo padrão mostra bem porque é que cabeçalhos isolados podem ser critérios de bloqueio muito maus.
Segundo a MDN, `Sec-Fetch-Site: none` é um comportamento totalmente normal do navegador, por exemplo quando alguém escreve um URL diretamente na barra de endereços ou abre um marcador.
Um pedido com este valor não é, portanto, automaticamente suspeito.
É por isso que bloqueamos este grupo apenas quando conjunto de origens, perfil exato do navegador, referrer vazio e página de entrada afetada coincidem ao mesmo tempo.
Isto é mais restrito do que uma regra genérica para bots – e de propósito.
A IA não "detetou um bot" – criou dois modelos de regras a partir disso
A parte que nos interessou não foi um modelo olhar para o tráfego e dizer "bot".
A IA só se tornou útil onde, a partir de muitos pedidos individuais, surgiram dois padrões técnicos distinguíveis:
1. Contradição de identidade: perfil do navegador e Fetch Metadata não encaixam entre si. 2. Impressão digital da origem: proveniência, perfil do navegador, entrada direta e página de destino surgem repetidamente em conjunto.
A partir destes padrões, os nossos agentes de IA derivaram uma estratégia para a Cloudflare, que depois testámos contra pedidos reais e acessos normais de navegador.
Esta é, para nós, a forma de IA em operação muito mais interessante: não um chatbot que explica segurança, mas agentes que traduzem telemetria real numa regra de edge controlada.
Já descrevemos noutro local por que razão o tráfego de bots pode distorcer a atribuição e o retargeting. Ao mesmo tempo, o debate atual sobre obrigações de transparência para crawlers de IA mostra como é difícil hoje atribuir de forma limpa o tráfego automatizado.
Sem mais implementação: a regra fica diretamente na Cloudflare
A solução final funciona como uma regra personalizada da Cloudflare existente com a ação Bloquear.
Não tivemos de implementar a aplicação nem consumir mais um lugar de regra. A regra de scanner/flood já existente foi alargada com os dois padrões adicionais.
A lógica só pode ser resumida, de forma deliberada, ao nível do princípio:
- Scanners já confirmados continuam bloqueados.
- O padrão 1 só se aplica quando a identidade do navegador e os Fetch Metadata são contraditórios da forma observada, o pedido é um GET, não é reconhecido nenhum bot verificado e não estão em causa caminhos internos de framework ou de API.
- O padrão 2 só se aplica na combinação de um conjunto de origem observado, um perfil de navegador exatamente recorrente, entrada direta sem referrer e uma das páginas de entrada afetadas.
- Só quando um ramo corresponde por completo é que a ação Block é executada.
As redes concretas, as versões de navegador, os User Agents e a expressão produtiva da Cloudflare não são publicados. Um scraper não precisa de saber mais do que isso sobre a regra.
A própria Cloudflare recomenda Custom Rules quando é preciso combinar vários campos do pedido. Uma ação de bloqueio terminante atua já ao nível das Custom Rules e não deixa os pedidos correspondentes seguir para mecanismos de bot posteriores.
O que aconteceu depois de ativar
Não nos limitámos a verificar se a Cloudflare aceitava a regra. Controlámos se ela acertava efetivamente no padrão pretendido e se os pedidos normais continuavam a funcionar.
Os testes de controlo mostraram:
- Pedido de teste com a primeira impressão digital: Cloudflare 403
- a mesma família de navegadores com características de navegação normais: 200
- página pública de comparação com acesso normal: 200
- evento real do segundo padrão: Custom rules / Block
- correspondências de regra apresentadas durante o teste: cerca de 1.300
A evolução na origem foi particularmente clara: no caso do primeiro padrão, os pedidos correspondentes de 626 caíram para zero no último intervalo de 18 segundos do excerto analisado, dentro de um minuto completo.
Numa verificação posterior no Minilytics, 156 segundos não trouxeram novas sessões diretas sem conversão de saída.
Isto não prova que o tráfego indesejado desapareceu para sempre. Mas mostra que a nova regra intercetou efetivamente no edge os padrões observados.
Porque não afirmamos que não pode haver falsos positivos
Testámos a regra com acessos normais de tipo navegador e limitámo-la de forma deliberadamente estreita.
Ainda assim, "garantidamente sem alarme falso" seria uma afirmação pouco séria.
Um visitante direto real poderia, em teoria, também cumprir simultaneamente várias características do segundo padrão – por exemplo, provir de uma rede de origem afetada, usar um dos perfis de navegador recorrentes e aceder a uma das páginas afetadas.
Por isso não tratamos a regra como uma solução universal anti-bot, mas sim como um fingerprint específico do incidente, com possibilidade documentada de reversão.
O mesmo vale para o primeiro padrão. Se os scrapers alterarem a identidade dos seus pedidos, também um fingerprint pode perder eficácia.
A vantagem reside precisamente no facto de não prometermos uma solução permanente mágica: conseguimos observar, reclassificar e ajustar a regra de edge de forma direcionada.
O que retirámos do incidente
O Bot Fight Mode não foi inútil. Mas uma defesa genérica contra bots não conseguiu bloquear de forma suficiente estes dois padrões de tráfego no nosso caso.
Só a combinação entre telemetria própria, análise de padrões apoiada por IA e uma Custom Rule precisa da Cloudflare fez a diferença.
Os nossos fingerprints concretos não são transferíveis para outros sites. O método, esse, sim:
Não perseguir endereços IP. Não bloquear cabeçalhos isolados. Combinar vários atributos independentes dos pedidos, excluir crawlers verificados, testar acessos normais de navegador e medir o efeito depois.
Assim, os nossos agentes de IA transformaram um problema de tráfego numa regra de edge verificável – sem entregar aos scrapers um guia universal.