Resumo

  • Um site precisa ser encontrado, mas também precisa se proteger de programas que procuram suas falhas. A pane da Yandex expôs o custo de confundir essas duas necessidades.
  • Na conta de apostas examinada pela Cloudflare, solicitações com os mesmos traços chegaram por outro caminho. A pesquisa não identifica o responsável nem demonstra que todos os bots fizeram essa mudança.

Quem publica uma notícia quer que alguém a encontre. Entre a redação e o leitor, há um visitante quase invisível: o programa que passa pelo site e recolhe páginas para o buscador. Ele não é um leitor, mas pode ajudar a trazer leitores.

O site, porém, não pode receber qualquer programa de braços abertos. Outros visitantes automáticos procuram falhas no software. O trabalho de protegê-lo envolve uma escolha delicada: deixar a notícia ao alcance da busca sem deixar o servidor à mercê dessas sondagens. Um contador de visitas, sozinho, não separa uma coisa da outra.

Na interrupção da Yandex em outubro, foram sobretudo essas visitas de busca verificadas que diminuíram na rede do buscador. A análise da Cloudflare de 14 de outubro não diz quantos leitores um jornal perdeu. Mostra que caiu o trabalho de procurar e recolher conteúdo, uma etapa anterior ao clique humano.

Já uma conta do setor de apostas não se livrou tão facilmente de outro tipo de visita. Solicitações suspeitas continuaram chegando por outros provedores, com traços que permitiam ligá-las ao padrão anterior. Ali, um gráfico em queda no antigo hospedeiro teria contado apenas metade da história.

As solicitações vindas da Yandex.Cloud para essa conta zeraram após o dia 8. Ao mesmo tempo, chegaram outras, com características iguais, por hospedeiros russos como Radist e Selectel. Para o destinatário, o desaparecimento de uma origem não trouxe o desaparecimento daquele padrão. E, para os sites de notícias, o tráfego perdido tinha outra utilidade.

O robô que o jornal quer receber

Na busca, aproximadamente 90% do tráfego anterior para sites de notícias era o YandexBot indexando artigos. Barrar esse visitante pode parecer reduzir o barulho no servidor, mas também atrapalha a tarefa de pôr notícias ao alcance de quem usa a busca.

Na rede de busca como um todo, 99,5% das solicitações observadas eram automáticas. Desses pedidos de bots, 93,6% tinham a verificação da Cloudflare.

O selo funciona como uma credencial, com critérios próprios: o programa deve dizer honestamente quem é e não apresentar comportamento abusivo. Não basta escolher um nome que pareça respeitável. Na amostra estavam YandexBot, YandexRenderResourcesBot e YandexImages, em atividades compatíveis com buscar páginas e imagens e preparar sua apresentação.

Quando essas visitas diminuem, cai o rastreamento e a descoberta de conteúdo na busca da Yandex. Isso não equivale a neutralizar uma ameaça. Para um site que quer ser encontrado, o silêncio de um rastreador tem um significado bem diferente do silêncio de um scanner hostil.

A interrupção tinha um contexto físico. Em 9 de outubro, a Yandex relatou danos graves e paralisação de Sasovo após um ataque de drones na noite de 7 para 8, além de danos a parte da infraestrutura de Kaluga no dia 9. Uma atualização de 11 de outubro acrescentou a parada da instalação de Vladimir. São informações da empresa sobre suas instalações, não uma atribuição das atividades de seus clientes.

A Cloudflare conseguiu acompanhar separadamente a busca e a nuvem porque elas usam redes distintas. Seus identificadores, chamados ASNs, são AS13238 e AS200350. É como distinguir de qual estrada veio um veículo, não descobrir quem estava ao volante.

Os números mostram a dimensão da interrupção na amostra da Cloudflare:

Momento observado Tráfego em comparação com o habitual
11 de outubro Busca 99% abaixo; nuvem 90% abaixo
13 de outubro Ambas ainda entre 86% e 90% abaixo
14 de outubro, 18h UTC Observação posterior registra 85% do nível normal

São fotografias daquele período, não uma verificação atual de disponibilidade.

Sem selo não significa criminoso

O retrato da nuvem era menos uniforme. Cerca de 95% das solicitações avaliadas eram bots, mas nenhuma solicitação de bot observada tinha o selo de verificação da Cloudflare. A documentação desse selo descreve critérios de identificação e comportamento. A falta dele não prova, por si, que uma aplicação seja maliciosa.

Quase dois terços das solicitações enviavam dados a sites. Ali também havia software e integrações comuns, como programas que precisam trocar informações entre si. A maioria dos pedidos do segmento de software recebia uma resposta de sucesso, o código HTTP 200, antes e durante o evento. Isso diz que o site respondeu ao pedido, não que quem o fez tinha boa intenção.

As atividades suspeitas também diminuíram. As sondagens de plugins do WordPress, que procuram falhas nesses complementos, caíram 90%; os pedidos identificados como scanners, usados para examinar sistemas, caíram 93%. Na rede da nuvem, AS200350, o tráfego de bots recuou cerca de 40%, enquanto os bloqueios de tráfego Yandex.Cloud feitos por clientes diminuíram 70%.

As quatro medidas não são fatias para somar. E nenhuma, isoladamente, conta quantas operações foram encerradas: todas olham para o que deixou de chegar por aquela origem.

O que continuou batendo à porta

Quase todos os pedidos de bots da Yandex.Cloud para o segmento de apostas se dirigiam àquela conta, por seus diferentes nomes de host. Para procurar a continuidade, a Cloudflare não se limitou a contar visitas. Comparou como elas se apresentavam e o que pediam ao site.

As novas solicitações repetiam caminhos e cabeçalhos incomuns, além do texto personalizado com que o programa se identificava, o User-Agent. Também coincidiam em um resumo das características da conexão criptografada, chamado impressão TLS JA4. Vários detalhes se repetiam no mesmo destino justamente quando a origem mudava.

É essa combinação que sustenta a interpretação de migração. Nenhum desses detalhes é a identidade de uma pessoa. O resultado não demonstra que a própria Yandex controlava o fluxo, nem que todos os bots se mudaram.

O movimento não autoriza concluir que toda atividade suspeita escapou ilesa. Mas ajuda a entender por que o destinatário precisa olhar suas próprias solicitações, não apenas esperar que uma pane em outro lugar resolva o problema.

Num recorte mais amplo, os pedidos de bots russos a contas de apostas na amostra subiram de 167,7 milhões para 170,1 milhões, ou 1,4%. Esse agregado abrange contas do setor; não é o volume da única conta descrita acima.

Ao abrir ainda mais o enquadramento, surge outro contraste. A tabela por datas do relatório mostra que a parcela de pedidos automáticos no total global quase não mudou. Entre os pedidos de origem russa, ela caiu:

Período Bots no total HTTP global observado Bots no total HTTP de origem russa
1º a 6 de outubro 39,4% 50,4%
11 de outubro 39,5% 42,2%
13 de outubro 39,5% 42,1%

Cada coluna usa seu próprio total de referência; ambas contam pedidos, não pessoas. Uma proporção mundial quase estável pode conviver com queda regional e com um cliente que continua recebendo visitas suspeitas.

O Radar oferece o contexto de tráfego, sem transformar a amostra da Cloudflare em toda a Internet. A empresa não encontrou apoio para a alegação de que a interrupção paralisou a manipulação de redes sociais, mas ressalvou que uma conclusão mais abrangente exigiria dados de fora de sua rede.

A Nota 65 de Lu Heng entra apenas como uma aproximação editorial. Seu assunto é a governança de números da Internet e a importância de sistemas em funcionamento, não este incidente. Aqui, a aplicação é mais simples: o nome no campo de origem mudou, mas o destinatário ainda reconhecia o padrão que chegava. Esse detalhe explica mais sobre a continuidade do fluxo do que a queda isolada de um provedor.