Há muito mais do que isso na lista, alguma ideia?
Vi isso nos logs de um de nossos clientes hoje, então isso é mais do que uma coincidência.
EDIT: Não, acho que é uma coincidência. Buscar por ymwears .cn mostra mais reclamações sobre spam de referência, como estas (com mais de um ano) Relevanssi shows weird search queries on my page | WordPress.org e Block specific referrer or agent to enter url | WordPress.org
Tive um cliente reclamando disso no mês passado. Bloqueei alguns IPs e considerei configurar o fail2ban para bloquear IPs que buscassem algumas dessas URLs, mas nunca tomei nenhuma medida concreta. Pesquisei sobre bloqueio por região geográfica, mas parece que seria necessário um banco de dados de $20/mês para conseguir isso.
O spam de referrer é um problema bastante grande, que até mesmo os grandes players (ou seja, o Google Analytics) não estão combatendo com 100% de sucesso. Por enquanto, tudo o que consigo pensar é remover essas entradas manualmente.
Como esses sites são aparentemente — pelo menos parcialmente — os mesmos em várias instâncias independentes do Discourse (dado o fato de que nossas capturas de tela mostram praticamente a mesma lista), talvez uma lista negra (dinâmica) seja uma ideia? @codinghorror, você tem alguma sugestão?
Há anos identificamos, tratamos e mitigamos esse problema em grande escala e descobrimos que a maneira mais confiável (nos últimos anos) de bloquear bots maliciosos é bloquear com base na string do User-Agent (UA), às vezes em combinação com informações de GeoIP.
Bloqueamos centenas de milhões de acessos de bots chineses ao longo dos anos e raramente encontramos bloqueios baseados em endereços IP que funcionem tão bem quanto o bloqueio de clientes com base nas strings de UA.
Aqui está um trecho de um código que usamos em um de nossos sites como exemplo:
$user_agents = explode('|',$string_of_bad_user_agents,-1);
$hide_content_useragent = $_SERVER['HTTP_USER_AGENT'];
$IS_A_BAD_BOT = FALSE;
foreach($user_agents as $hcag) {
trim($hcag);
if (preg_match("/$hcag/i", "$hide_content_useragent")) {
$IS_A_BAD_BOT = TRUE;
break;
}
}
Quase todos (mas não todos) os bots maliciosos usam strings de UA que podem ser identificadas e bloqueadas com relativa facilidade (nesta era; não tenho certeza sobre o futuro, à medida que as coisas evoluem). Por isso, abandonamos há anos o método de tentar bloquear bots maliciosos com base em endereços IP. O motivo pelo qual deixamos de bloquear com base em IPs é que muitos países, como China, Rússia, Coreia do Norte e muitos outros, agora operam suas fazendas de bots em servidores localizados em outros países. Endereços IP não são um bom indicador da origem ou intenção reais. Além disso, ao bloquear grandes blocos de endereços IP, endereços legítimos podem ser bloqueados, impedindo o acesso de usuários legítimos.
Por exemplo, a China opera enormes fazendas de servidores de bots no Brasil e em outros países mais próximos (geograficamente dos EUA) para disfarçar sua origem e recuperar dados mais rapidamente (menor alcance na internet).
Às vezes, os dados do WHOIS correspondem a um endereço físico chinês, norte-coreano ou russo (como exemplos), mas outras vezes não, utilizando endereços físicos do país local. Vimos muitos bots maliciosos chineses registrados em empresas brasileiras (nos últimos anos), onde pudemos ver (e confirmar) que as strings de User-Agent correspondiam a bots maliciosos originários da China. Além disso, ao realizar pesquisas no Google com essas strings de UA, vimos que outros também identificaram muitas das mesmas strings como sendo chinesas (por exemplo).
Em resumo, embora muitas pessoas recorram imediatamente ao bloqueio de endereços IP para combater atividades de bots maliciosos, a maioria das fazendas de bots mais sofisticadas é muito boa em operar seus bots a partir de outros países. É fácil configurar um VPS na maioria dos países e, claro, quanto mais próximo o bot estiver do país-alvo, mais dados ele poderá coletar. VPSs podem surgir e desaparecer em minutos, e o software de bots pode ser implantado rapidamente em praticamente qualquer data center de VPS no mundo.
Nos últimos anos, o bloqueio com base na string de UA provou ser o método mais confiável (às vezes em combinação com informações de GeoIP, às vezes não); mas, é claro, spammers, mestres de bots e seus agentes também estão começando a disfarçar as strings de UA, assim como fazem com seus endereços IP (há muitos anos).
Espero que isso ajude.
Abraços e boa caça aos bots!
Sim, concordo plenamente que o bloqueio por IP não é eficaz.
O bloqueio por user agent tende a funcionar bastante bem, exceto quando os spammers o alteram constantemente.
É por isso que minha ideia foi simplesmente listar em preto o URL específico que está sendo alvo de spam de referrer.
Isso apenas “parece melhor” porque não estamos bloqueando algo com base em uma suposição subjacente (ou seja, “este user agent fornece um referrer ruim, então não confiamos nele”), mas estamos realmente bloqueando o que queremos bloquear (“vemos que este site está sendo alvo de spam de referrer em mais sites Discourse; vamos não incluí-lo em nosso banco de dados”). Pelo menos, isso é mais difícil de contornar.
Boas ideias.
Não existe uma solução única para parar bots maliciosos e fora de controle; cada site deve avaliar quais controles funcionam melhor para ele.
Em uma nota similar…
Sites que dependem principalmente de listas negras e bancos de dados de spam ou bots maliciosos também podem ter problemas. Digamos, por exemplo, que alguém não goste do site www.our-arch-rival.com porque esse site é um concorrente (ou simplesmente nos deixou irritados ou ofendidos). Algumas pessoas então enviarão o site www.our-arch-rival.com para uma lista negra ou banco de dados, e outros sites passarão a filtrar um site legítimo por causa dessa espécie de “consequência ruim” do método de listas negras em bancos de dados.
Então, claro, os defensores das listas negras dirão: “você pode ir aos sites de listagem negra e enviar um relatório, pedindo para ser removido”, mas para muitos sites ocupados e de longa data, isso pode ser um desperdício de tempo.
Geralmente, é importante analisar o problema e criar uma estratégia de mitigação baseada no cenário, pois cada “adversário” é diferente. É o antigo “Conheça seu Inimigo” de Sun Tzu e A Arte da Guerra. Cada situação é um pouco diferente no mundo real e, infelizmente, é necessário ter habilidades de análise para que os administradores de sistema criem estratégias de mitigação ótimas contra atividades cibernéticas maliciosas ou indesejadas.
Essa também é uma boa razão para rodar o Discourse atrás de um proxy reverso, pois o proxy reverso é um bom lugar para analisar, classificar e controlar atividades maliciosas antes que esse tráfego atinja o aplicativo Discourse.
Pode ser um trabalho de tempo integral em 2020 tentar controlar e mitigar bots maliciosos e outras atividades maliciosas no ciberespaço. Assim que os administradores criam uma boa estratégia de detecção e mitigação, os spammers e scrapers se ajustam e encontram maneiras de contorná-la. Eu costumo aconselhar as pessoas a dimensionar seus servidores de forma exagerada para garantir que tenham margem de segurança suficiente, já que esse tipo de problema no ciberespaço só vai piorar com o tempo, não melhorar.
Ready Player One!
O que é mais um motivo para se afastar do bloqueio por IP: os spammers saberão que você está tomando medidas.
Acho que consigo bloquear a maioria dos spammers através do Cloudflare, mas não tenho certeza do que colocar nas regras para o User Agent do navegador.
@neounix, o que você quer dizer com “strings de UA”? E como elas podem ser usadas nas regras de firewall do Cloudflare?
Mas isso nem é spam de referrer, certo? É apenas que eles estão fazendo uma busca por essa URL, então na verdade não está fazendo nada, não é? Será que eu entendi totalmente errado o que esse relatório diz? Ele não está disponível para ninguém além dos administradores, certo?
Acho que você está certo, @pfaffman. O relatório parece ser apenas para buscas feitas no fórum. Ele também inclui o CTR, o que não faria sentido se fosse um relatório de referrer.
Não, tecnicamente isso não é spam de referrer, mas não tenho certeza se existe um termo exato para esse tipo específico de abuso. Acho que isso é muito próximo de spam de referrer, mas apenas para um relatório de consultas de busca?
Spam de referrer nunca faz nada; ele serve apenas para aparecer nos relatórios.
Aqui está…
No HTTP, a string de User-Agent é frequentemente usada para negociação de conteúdo, onde o servidor de origem seleciona conteúdo ou parâmetros operacionais adequados para a resposta. Por exemplo, a string de User-Agent pode ser usada por um servidor web para escolher variantes com base nas capacidades conhecidas de uma versão específica de software cliente. O conceito de adaptação de conteúdo está incorporado ao padrão HTTP no RFC 1945 “para adaptar as respostas e evitar limitações específicas do agente de usuário.”
A string de User-Agent é um dos critérios pelos quais os rastreadores da web podem ser excluídos do acesso a certas partes de um site usando o Padrão de Exclusão de Robôs(arquivo robots.txt).
Como muitos outros cabeçalhos de solicitação HTTP, as informações na string “User-Agent” contribuem para as informações que o cliente envia ao servidor, já que a string pode variar consideravelmente de usuário para usuário.[5]
Referência:
@Yassine_Yousfi. Há uma infinidade de referências na internet sobre as strings de User-Agent (UA) do HTTP e como usá-las de várias maneiras, inclusive como um sensor na detecção de bots e outras atividades cibernéticas maliciosas.
Boa caça aos bots!
Observações:
- Você pode ver a
visualização Discoursedos agentes de usuário de bots aqui (algumas strings de UA estão truncadas):
https://discourse.your-great-domain.com/admin/reports/web_crawlers
-
Nenhum algoritmo de detecção consegue identificar todos os bots com 100% de precisão.
-
Você também pode obter as strings de UA a partir dos arquivos de log do seu servidor web e por outros métodos.
Veja também: