Como evitar que os comentários de spam do WordPress quebrem o seu blog WordPress e derrubem o seu servidor

Em primeiro lugar, gostaria apenas de esclarecer que este artigo NÃO é sobre como detectar e sinalizar comentários como spam. O plugin Akismet para WordPress já faz um bom trabalho de triagem e filtragem de comentários de spam tradicionais do WordPress.

Em vez disso, esta postagem é sobre como evitar que o spam de comentários e outras atividades invasoras travem seu servidor e derrubem seu blog .

Foto por BoxChain

Como mencionei no meu último artigo, o tráfego do meu blog dobrou no ano passado.

E, infelizmente, durante esse tempo, a quantidade de comentários de spam também aumentou em uma ordem de magnitude.

Só para se ter uma ideia, houve vários dias em dezembro em que fui bombardeado com mais de 20 comentários de spam a cada poucos segundos.

Sim, você ouviu direito. Sempre que atualizava meu painel, eu via 20 ou mais comentários de spam em meu filtro Akismet. Na verdade, a quantidade de spam tornou todos os sites do meu servidor extremamente lentos ou inacessíveis por um longo período durante aqueles dias.

O problema com o WordPress

Agora, em operação normal, meu blog se sai muito bem com tráfego pesado por causa de um plugin chamado WP Super Cache.

Essencialmente, esse plug-in cria uma versão estática de cada artigo do meu blog para que possa ser veiculada rapidamente ao usuário final.

No entanto, esse plug-in é indefeso contra um grande influxo de comentários porque os comentários exigem que seu servidor acesse o WordPress todas as vezes para processar os comentários um por um.

E como o WordPress é um grande consumidor de recursos, um grande fluxo de comentários de spam pode facilmente derrubar qualquer blog, mesmo se você estiver em um servidor dedicado e usar um plugin de cache.

Não importa se você usa os melhores filtros de spam de comentários do mundo, todos os comentários de spam ainda precisam ser processados ​​pelo WordPress, o que consome uma boa parte dos recursos do servidor.

As características dos bots de spam

Agora, ter um blog lento ou inacessível é uma coisa, mas o spam de comentários também afeta outros sites que estão sendo executados no mesmo servidor, o que é inaceitável. Depois de fazer algumas pesquisas sobre bots de spam, descobri algumas coisas.

• Os bots de spam normalmente não aceitam cookies
• Os bots de spam podem deixar spam de comentários em questão de segundos
• Os bots de spam normalmente não executam javascript

Então o que isso quer dizer? Em termos não técnicos, um bot de spam não se comporta como um usuário comum em um navegador da web. E a chave para resolver meu problema envolvia detectar o bot de spam imediatamente e direcioná-lo para uma página de erro em vez de iniciar o WordPress.

Com base nas características descritas acima, eu poderia detectar bots de spam colocando um cookie na máquina do usuário, desabilitando comentários por muitos segundos após o carregamento de uma página ou criando algum código javascript para detectar o bot de spam.

Resolvendo meu problema de spam de comentários

Depois de muita deliberação, descobri uma correção para inserir secretamente um cookie na máquina do usuário sempre que um acesso é feito a uma página do meu blog. Eu poderia então procurar esse cookie na máquina do usuário antes de permitir a passagem de um comentário.

Como um bot de spam normalmente não aceita cookies, eu poderia facilmente detectar o bot e direcioná-lo para uma página de erro estática.

Originalmente, planejava postar meu código-fonte nesta entrada do blog que escrevi em javascript (ficaria feliz em enviá-lo se você estiver curioso), mas depois de conversar com alguns colegas blogueiros, descobri que o mesmo autor de WP Super Cache, Donncha, já havia escrito um plugin chamado Cookies For Comments que essencialmente faz a mesma coisa que acabei de escrever.

Como o plug-in dele foi escrito com muito mais elegância do que o meu plug-in javascript, recomendo fortemente que você faça o download.

Mas se você planeja usar o plug-in Cookies para comentários de Donncha, certifique-se de fazer as seguintes alterações em seu .htaccess, que difere das instruções de instalação do plug-in.

O que essas 2 linhas fazem? Basicamente, essas linhas de código detectam a presença do cookie secreto que foi inserido na máquina do usuário. Se o cookie não estiver presente, o usuário ou bot de spam é direcionado para a página 404 do WordPress ou “página não encontrada”.

Agora, o problema com essa configuração padrão é que o WordPress ainda é chamado para processar a página 404, que ainda requer muitos recursos do servidor.

A diferença aqui é que o bot de spam é direcionado para uma página de erro completamente estática que evita que o WordPress seja carregado completamente.

Problema resolvido??? Não muito

Portanto, as alterações que descrevi acima corrigiram meu problema de spam de comentários, mas depois de funcionar sem problemas por alguns dias, meu servidor começou a falhar novamente! Olhando para os logs do meu servidor, descobri o seguinte.

mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar

Basicamente, alguma máquina desonesta ficava tentando acessar o mesmo arquivo inexistente no meu servidor repetidamente, o que estava travando o site. Agora, com sites normais, esses acessos desonestos não afetariam o servidor de forma alguma.

No entanto, o WordPress processa todos os acessos a arquivos inexistentes e envia os usuários para a página 404 personalizada ou “página não encontrada” do WordPress.

Eu mencionei que o WordPress é um devorador de recursos? Basta um monte desses acessos falsos e seu servidor ainda cairá, não importa qual plugin de cache você use.

O segredo para resolver esse problema é semelhante ao meu problema de spam de comentários. Idealmente, queremos tirar o WordPress totalmente da equação e enviar o usuário desonesto para uma página de erro completamente estática para economizar recursos do servidor.

O que todo esse código faz? Basicamente, quando um arquivo é solicitado de meu servidor que corresponda a um dos tipos acima, quero que meu servidor ignore o WordPress completamente. Se o arquivo não existir, o usuário será direcionado para uma página de erro estática chamada 404.html.

Mais uma vez, ignorar o WordPress é a chave para resolver meus problemas de travamento. Como o processo invasor em meus logs de servidor está acessando um arquivo .rar, agora redireciono esse usuário malicioso para minha página de erro, que praticamente não consome recursos.

Isso resolve todos os meus problemas?

Portanto, estou executando as 2 alterações acima há algumas semanas e meu servidor está funcionando como um campeão, sem lentidão. Infelizmente, a forma como o WordPress é escrito torna impossível evitar que todos os acessos desonestos travem seu servidor.

Por exemplo, sempre que alguém tenta acessar um artigo que não foi encontrado no meu blog, o WordPress ainda é carregado. Então, em teoria, se alguém quisesse derrubar MyWifeQuitHerJob.com ou qualquer blog WordPress para esse assunto, tudo o que eles teriam que fazer seria acessar páginas inexistentes no site repetidamente.

Mas, nesse ínterim, tudo parece estar estável do meu lado. Esperançosamente, no futuro, o WordPress pode ser corrigido para resolver esses problemas de servidor.