Demorou mas aconteceu: este blog foi descoberto pelos spammers. Neste post mostro como adaptei o site, baseado em WordPress, para lidar com o problema sem precisar aumentar a capacidade do servidor.
Evolução do problema
Quando criei /dev/Kico em 2008 era raríssimo receber alguma mensagem de spam por uma razão simples: ninguém acessava este blog. Conforme o tempo foi passando, o spam começou a se manifestar sob a forma de comentários com propaganda.
A partir do meio daquele ano, conforme o número de acessos aumentou, começaram a aparecer os primeiros comentários com spam. Era algo em torno de uns dois ou três por semana. O plugin Akismet os detectava, eu checava se eram realmente spam e, sendo, os apagava. O interessante é que até onde pude perceber, este plugin conseguiu detectar 100% dos casos até os dias de hoje.
Conforme o tempo passa começo a ver dois ou três posts com spam no site. E isto vai progredindo até chegar a uns 400 por dia. Até então era tranquilo: ia na aba de comentários e simplesmente clicava em apagar todo o spam. Só que neste mês comecei a ver 1000, 2000 comentários por dia, até que nesta semana, em um único dia, 40.000 posts foram incluídos!
Para piorar a situação, como meu servidor é bastante modesto, os serviços simplesmente caiam. Se você é visitante contínuo do site deve ter percebido uma “certa” lentidão. Agora sabe a razão. Algo em torno de 60000 acessos/dia, mais da metade bots postando conteúdo.
(dica: sempre tenha um job que de tempos em tempos verifique se os principais serviços estão em execução ;) )
Como resolvi o problema (ao menos por enquanto)
Reduzindo os custos de renderização dos posts e acessos ao MySQL
O primeiro passo é tentar reduzir ao máximo as consultas ao MySQL e o custo de renderização dos posts. O primeiro passo é instalar algum plugin de cacheamento. No caso do /dev/Kico uso o Quick Cache. O funcionamento é simples: no primeiro acesso a um post o plugin irá criar uma versão estática da página e a armazenará em seu servidor. A partir do segundo acesso será servido o conteúdo estático da página. O desempenho do seu site aumenta e as consultas ao SGBD diminuem. Quando um novo comentário é aprovado para o post o cache é removido para ser gerado novamente no próximo acesso.
Isto dá uma bela folga ao servidor, mas ainda não resolveu o problema, pois os bots continuam enviando comentários para o seu site.
Banindo os spammers pelo IP
O plugin Akismet que mencionei acima é maravilhoso: como disse, ele consegue detectar 100% do spam, mas não evita que novos registros sejam inseridos na tabela de comentários do WordPress, pois ele apenas os marca como mensagens indesejadas. Se o número de registros nesta tabela for muito grande seu blog irá sofrer com isto, especialmente quando tentamos acessar a lista de comentários na área administrativa.
A solução para o problema foi bloquear os spammers pelo IP. Há dois caminhos para isto: você pode alterar o firewall do seu servidor ou usar algum plugin do WordPress. Optei pela segunda opção pois assim tenho uma interface mais amigável para este tipo de manutenção e, ao mesmo tempo, não preciso ficar acessando o servidor via SSH. O plugin que adotei foi o WP-Ban.
É muito fácil de usar: observe a imagem abaixo que contém um comentário de spam:
Como pode ser visto, na listagem de comentários do WordPress é exposto o IP de quem enviou a mensagem. No WP-Ban basta fornecer este valor: todos os visitantes provenientes deste endereço sequer acessarão seu blog: eles serão saudados com uma mensagem de bloqueio, simples assim. Qual a vantagem disto? Além de não serem incluídos registros na sua tabela de comentários o processamento do seu servidor para este usuário será significativamente menor. Qual o resultado no meu servidor? Mais memória livre, menos consultas ao SGBD e um desempenho superior aos usuários que realmente me interessam: vocês!
Dica importante: o spammer nunca usa um único IP como na imagem acima. Normalmente é um range. O Wp-Ban me permite incluir máscaras. Sendo assim, incluindo o valor 93.174.*.* já excluí todas as máquinas do spammer acima. Simples e direto.
Otimizando seu banco de dados
Claro, você não irá banir todos os IPs do planeta, sendo assim ainda haverá um ou outro spammer te atazanando de tempos em tempos. Dá pra melhorar ainda mais a situação. Como? Automatizando a exclusão de spam do seu banco de dados.
Se você usa Linux, basta criar uma tarefa com o CRON que esporadicamente exclua todos os registros da tabela comments que possuam o valor ‘spam’ no campo comment_approved. Você perderá a chance de evitar a exclusão de mensagens que não são indesejadas, mas em contrapartida garantirá que sua tabela só contenha comentários reais e mantenha-se com o menor tamanho possível.
No caso de /dev/Kico, esta tarefa é executada agora de duas em duas horas.
Troca do Apache HTTPD pelo Nginx
Sou um cara muito sortudo: mês passado troquei o meu servidor web. Como o número de acessos ao blog vêm crescendo muito, uma ideia que passou de imediato na minha cabeça foi aumentar a capacidade do servidor. Como gosto muito de uma economia, antes de fazer o upgrade, por que não experimentar o Nginx?
Fiz a troca e não me arrependi: o desempenho melhorou significativamente e o consumo de memória foi bastante reduzido. Acredito que se não tivesse feito esta troca o estrago deste mês teria sido muito maior. Sendo assim, fica a dica: se puder, troque seu Apache pelo Nginx pois vale muito à pena.
No final das contas
Estas mudanças no WordPress foram muito fáceis de serem feitas e resolveram por enquanto meu problema com spam. Com elas consegui postergar em alguns meses o upgrade do servidor. Com certeza há soluções mais interessantes ou eficientes, mas o objetivo foi apenas mostrar que com custo mínimo é possível lidar bem com este problema.
A propósito, algum tempo atrás escrevi sobre o primeiro “upgrade” do /dev/Kico. Você pode ler o post neste link.
Muito bom, Kico. Mas que comentários podem ser desejáveis entre os detectados como spam? De qualquer forma, seu CRON pode gerar um log ou um aviso quando a tabela contiver alguma faixa de IP ou conteúdo diferente de algum padrão encontrado nos spams habituais.
Oi Éderson,
No meu caso, até hoje, nenhum, razão pela tornei automático o processo de exclusão.
No caso do cron, é desnecessário pois quem faz isto para mim é o Akismet.
Oi Henrique,
Não entendi onde você diz:
“O plugin Akismet que mencionei acima é maravilhoso: como disse, ele consegue detectar 100% do spam, mas não evita que novos registros sejam inseridos na tabela de comentários do WordPress, pois ele apenas os marca como mensagens indesejadas. Se o número de registros nesta tabela for muito grande seu blog irá sofrer com isto, especialmente quando tentamos acessar a lista de comentários na área administrativa.”
Eu recebia muito spam também, mas instalei o Akismet e acabaram. Mas você diz que ela ficam na tabela de comentários. No admin do meu blog nenhum comentário está aparecendo como spam. Será que posso dormir tranquilo?
Oi Paulo, aparentemente sim.
O Akismet não impede que o comentário seja incluído na tabela de comentários. O que ele realmente faz é apenas marcar o comentário como spam.
Por isto ele apenas resolve a primeira metade do problema. Os spammers continuam enviando spam para o seu blog e sua tabela continua crescendo.
Se na aba spam não aparece nada e você está com o Akismet instalado, tranquilo. Ele tá fazendo seu trabalho. :)
Valeu! E vê se aparece no próximo café com arquitetos.
Saudações,
Paulo Marcio
Com certeza!
No último não fui por nanômetros!
Só uma duvida você excluindo os ips, se for ataque de faculdades e lugares públicos não estaria excluindo uma boa parte do acesso? fora que a maioria dos ips são dinâmicos vai ficar bloqueando ips para sempre?
Oi Bruno, sem dúvida este é um problema e você está certíssimo.
Na realidade o que eu faço é de tempos em tempos executar uma limpeza nesta lista de IPs justamente para evitar que este tipo de coisa ocorra.
No free lunch… :)
Penso que, se em alguma instituição educacional, algum desordeiro quiser atacar ou mandar spam para um site, do Kico ou de quem quer que seja, o IP for bloqueado e aquele lugar utilizar muito o site (por exemplo, para pesquisa), é justo que a escola arque com a responsabilidade de encontrar e aplicar alguma sanção no responsável. Realmente quem não tem nada com a coisa, pagará o pato, mas se criaria a consciência de zelo no lugar, onde os próprios estudantes contribuam com a fiscalização. Desculpe se meu comentário for off topic, mas já que surgiu o assunto dos hackers estudantes, acho relevante a discussão.