ML de bot management da Cloudflare

01 · CONTEXTO

Bot bom, bot mau e o problema de classificar cada requisição

Um bot é um programa autônomo que imita ou substitui o comportamento de uma pessoa. A Cloudflare separa os bots úteis, como os de buscadores, dos maliciosos, como os de credential stuffing, de raspagem por terceiros e de spam. Gerenciar bots, nessa definição, é bloquear o tráfego indesejado sem impedir que os bots úteis acessem o site.

Dois requisitos de produto dão o tom do desenho. O primeiro é a precisão: quase nenhum visitante humano deve ser tomado por bot. O segundo é a recuperabilidade: se uma previsão errada acontecer, a pessoa ainda precisa conseguir acessar o site e os bots bons precisam passar.

1. O diagrama mostra o caminho mais simples: o visitante chega à borda e a borda encaminha a requisição à origem.

2. A pergunta do desenho está neste trecho: em que ponto do caminho classificar o visitante antes que a origem o atenda.

02 · REQUISITOS

O que a plataforma precisava cumprir

Além dos requisitos de produto, a engenharia montou uma lista de exigências obrigatórias. A tabela resume as que a fonte destaca entre as mais críticas.

03 · O SCORE

Uma nota como contrato entre detecção e cliente

A resposta ao problema foi um conceito único, o score: um número de 0 a 100 que indica a probabilidade de a requisição ter vindo de uma pessoa (nota alta) ou de um programa automatizado (nota baixa).

O score virou um campo das regras de firewall. Cada cliente ajusta o limiar conforme sua sensibilidade a falsos positivos e falsos negativos, e a Cloudflare pode ampliar as detecções por baixo dos panos sem que o cliente mude alguma configuração.

1. A requisição do visitante passa pelo módulo de Bot Management, que roda em cada máquina da borda.

2. Quando o módulo produz os campos necessários, entre eles o score, o firewall assume a mitigação.

3. Com base no score e no limiar configurado, o firewall bloqueia, desafia ou registra as requisições suspeitas e encaminha as legítimas à origem.

4. O módulo também registra pelos pipelines de dados os detalhes de cada detecção no ClickHouse.

5. Os serviços centrais processam os dados recebidos dos datacenters de borda.

Quem quer mais flexibilidade sobre o que fazer com o score pode usar o Cloudflare Workers, além das ações do firewall.

04 · DETECÇÃO EM CAMADAS

Vários mecanismos, um único score

A plataforma combina cinco mecanismos de detecção complementares, cada um com o próprio score, num score único enviado ao firewall. A maioria roda em toda requisição e alguns são ativados por cliente.

Nem todo problema pede aprendizado de máquina. A fonte observa que, em certos casos, os modelos tendem a render menos do que heurísticas básicas, e que às vezes um único atributo da requisição entrega o bot. As heurísticas ainda alimentam o aprendizado: as requisições que elas classificam são usadas para treinar os modelos.

1. A requisição chega ao módulo e seus atributos são extraídos e transformados para alimentar os mecanismos de detecção.

2. Os modelos de aprendizado de máquina recebem atributos da requisição e atributos entre requisições entregues pela plataforma Gagarin.

3. O motor de heurísticas aplica regras simples; qualquer correspondência atribui o menor score possível, e as requisições que ele classifica servem para treinar os modelos.

4. Os demais mecanismos completam o conjunto: a análise comportamental, não supervisionada; a validação de bots bons por agrupamento de IPs; e o desafio de JavaScript injetado na página pela borda.

5. Os scores dos mecanismos são combinados no score único que segue para o firewall.

05 · INFERÊNCIA NA BORDA

Velocidade, modo shadow e implantação de modelos

O núcleo da detecção por aprendizado de máquina é o CatBoost, biblioteca de gradient boosting sobre árvores de decisão. Segundo a fonte, aplicar qualquer um dos modelos leva menos de 50 microssegundos, e centenas de heurísticas rodam em pouco menos de 20 microssegundos. A maior parte da lógica de negócio da borda é escrita em Lua (LuaJIT), e a API em C e Rust da biblioteca oferece a interface FFI compatível para aplicar os modelos.

Vários modelos CatBoost rodam em modo shadow em toda requisição de toda máquina, e um deles roda em modo ativo, influenciando o score final. Os resultados e atributos de toda detecção por ML são registrados no ClickHouse para análise e melhoria dos modelos.

Novos modelos entram em produção em questão de segundos pelo Quicksilver, o banco de configuração, e o mesmo mecanismo define qual versão de modelo roda em modo ativo para um cliente específico.

1. O módulo na borda aplica vários modelos a cada requisição: um ativo e os demais em modo shadow.

2. Só o modelo ativo influencia o score final que segue para o firewall.

3. Os resultados e atributos das detecções por ML são registrados no ClickHouse.

4. Esses registros servem à análise e à melhoria dos modelos.

5. Novos modelos chegam à borda pelo Quicksilver em segundos, e a mesma configuração escolhe a versão ativa de cada cliente.

06 · LEITURA CRÍTICA

O que levar para a entrevista

Os números da fonte são da época da publicação do texto. A Cloudflare dizia cobrir mais de 26 milhões de propriedades na internet, processar em média 11 milhões de requisições por segundo, com picos acima de 14 milhões, e examinar mais de 250 atributos de cada requisição.

Calcular o score em toda requisição e para todos os clientes tem benefícios que a fonte lista: avaliar como a proteção funcionaria para um cliente antes de ativar o modo ativo e manter um ciclo de feedback que melhora os mecanismos de detecção.