Bastidores

O meta blog do Manual do Usuário

Lutando contra robôs invasores

22/2/2023

Com o novo sistema de cadastro do Manual do Usuário (você já pode se cadastrar), tive que ir à caça de plugins para WordPress capazes de deixar a experiência da pessoa logada mais agradável.

Nessa, lembrei de um bem útil, que usava na época da Cypher Host (antiga hospedagem) e que não fez a passagem para a Teramundi (a atual): Simple History. Ele apenas gera um relatório simples, contínuo, de (quase) tudo que acontece no site.

Foi um choque. Logo nas primeiras horas, o Simple History mostrou uma horda de robôs tentando logar (leia-se: invadir o site), milhares de tentativas em menos de uma hora:

Relatório com algumas entradas de tentativas de invasão ao WordPress do Manual do Usuário.

A minha senha é bem forte e todos os demais usuários têm poucos privilégios — uma invasão nas contas deles não causaria estragos.

Ainda assim, todas essas tentativas consomem recursos do servidor. Quanto? Não sei. Não era algo crítico, porque o site seguia estável, mas estava longe de ser desejável e, com a abertura do cadastro no site, esses recursos perdidos para os robôs poderiam fazer falta.

A chegada dos robôs talvez tenha sido um problema recente que coincidiu com a reativação do Simple History.

Explico. No dia 9 de fevereiro, pedi à Teramundi para reativar o xml-rpc.php, um arquivo do WordPress que viabiliza interações remotas. A reativação foi pedida para melhorar a integração do site com o IFTTT, que estou usando em algumas rotinas automatizadas de distribuição de conteúdo, como publicar links de novos posts do site no Twitter.

Suspeito que as duas coisas tenham relação porque a Cloudflare, nossa CDN, emitiu um alerta no dia seguinte, 10 de fevereiro, de um aumento de 57% no tráfego automatizado (de robôs) no site.

“Desligar” o xml-rpc.php do WordPress é considerada boa prática porque, no geral, as interações que ele viabiliza não são usadas. Passaram a ser aqui, o que impôs esse novo desafio de lidar com robôs.

Fiz uma volta enorme para chegar à solução na própria Cloudflare. Essa volta consistiu em testar e ativar alguns plugins que (prometem) conter visitantes não humanos. A saber:

(WP Hide Login e Simple Login Captcha não estavam traduzidos para o português. Agora estão.)

Os três plugins, juntos, reduziram drasticamente as tentativas de acesso não autorizado ao Manual. Saímos da casa das milhares diárias para a das poucas centenas.

Essas poucas centenas vinham de lugares aleatórios. O Simple History expõe o IP de quem tenta logar no site e, com esse dado, é possível saber a origem geográfica aproximada dessas tentativas.

Meu plano era bloquear os IPs dos robôs direto no firewall da Cloudflare, impedindo o acesso ao site por completo. Esse expediente, embora trabalhoso, já tinha surtido bom efeito contra ondas de cadastros fantasmas na newsletter.

O problema é que boa parte das tentativas de invasão vem de servidores legítimos — do Google, da Amazon etc. Não dá para bloqueá-los. O risco de bloquear também outros sistemas legítimos e pessoas de carne e osso é grande demais.

Num desses acessos para reforçar o firewall, por acaso topei com um recurso da Cloudflare que estava desativado, o “Bot Fight Mode”, que:

Desafia requisições que batem com padrões de robôs conhecidos antes que eles acessem seu site.

E… bem, parece que resolveu. Depois de ativado esse modo, as tentativas de invasão praticamente cessaram, o que me deu liberdade para desligar, em momentos distintos, os plugins BruteGuard e Simple Login Captcha. O primeiro não fez falta mesmo, mas a ausência do segundo deixou passar 12 tentativas de invasão de um IP da região de Sichuan, na China. É pouco, mas é alguma coisa. Ainda estou avaliando se a mitigação desse risco compensa a chateação imposta a quem visita o site de ter que inserir um captcha de três números para logar.

O Simple History gera um gráfico de eventos diários. Dá para ver com clareza as etapas dessa luta contra robôs na queda das barras:

Gráfico de eventos dentro do WordPress do Manual do Usuário.