Parece que alguns spammers com contas do Gmail bloqueadas estão conseguindo passar com variações de pontos, mesmo tendo a versão canônica do e-mail bloqueada.
Parece que o bloqueio ainda está funcionando, apenas não totalmente, pois ainda vejo correspondências regulares contra o registro nos logs → e-mails filtrados, mas não para todas as combinações. O usuário conseguiu criar algumas centenas de contas hoje usando o mesmo e-mail do Gmail bloqueado.
As variações de pontos do Gmail que eles estão usando parecem ter entre 6 e 14 pontos; o comprimento do e-mail é 19 (antes do @); eles não estão usando variações com + (ou todas essas variações estão sendo bloqueadas com sucesso).
Pode ser relevante: tenho a distância de Levenshtein para e-mails de spammers definida como 3 (o padrão é 2). O Discourse foi atualizado recentemente da versão 2.6.x para a 2.7.1 estável.
Hmm, esqueço onde chegamos a um consenso sobre isso, @sam, mas isso provavelmente seria um bug, já que você disse:
Isso significa que, se evil.person+77@gmail.com for bloqueado, bloquearemos evilperson@gmail.com em vez disso. Então, quando e.v.i.l.person@gmail.com tentar se infiltrar, será bloqueado devido à correspondência canônica.
Então, o que acontece quando sara.hanson@ faz algo terrível e sarah.anson@ acaba sendo atingido no fogo cruzado? É como se eu não tivesse certeza se joe98@ e joe99@ poderiam ser considerados o mesmo endereço de e-mail. Suponho que isso dependa da composição da comunidade e do nível de discricionariedade manual utilizado no processo de correspondência.
O “endereçamento com mais” (plus addressing) refere-se, pelo menos, a uma pasta pertencente à caixa de correio do mesmo endereço de e-mail (dado que tudo antes do “+” é idêntico).
Talvez combater o registro por faixa de IP? Tudo isso depende de quão sofisticados são os spammers. Vindos da comunidade do Let’s Encrypt, temos um tópico de acompanhamento lá que detalha algumas táticas de spam bastante amplas que foram tentadas. Até mesmo tivemos pessoas oferecendo ajuda técnica real antes de fazer spam semanas depois.
Interessante. Nunca percebi que o Gmail fazia essa distinção. Aprendi mais do que algumas coisas novas hoje. Me pergunto por que eles fariam isso? Parece que consumiria bastante espaço. As endereços do Gmail são a única preocupação aqui?
Acho que chegamos ao ponto de: “Estou desconfortável com o lugar onde acabamos, porque é um pesadelo de suporte e nunca vai embora :)”.
Sinto que, se um site é um vetor de spam, deveria ser permitido dizer “torne todos os meus e-mails canônicos”. Não me importo com as desvantagens.
Ou seja, esses dois e-mails teriam o canônico samsam@somewhere.com:
sam.sam@somewhere.com
samsam+11@somewhere.com
Se sam.sam@somewhere.com se registrasse, samsam+11@somewhere.com não poderia mais se registrar.
Essa foi minha correção original, que acabei revertendo (embora tivesse um caso especial para o Google — o que, em retrospecto, não foi rigoroso o suficiente).
Sinto que deveríamos simplesmente deixar isso para trás adicionando uma nova configuração de site para:
“OMG, sou um vetor gigante de spam, ative o modo mega tinfoil”
Quanto ao bug, coisas podem entrar facilmente agora se você esperar para bloquear. Atualmente, é um processo 100% reativo.
Ou seja, isso funciona perfeitamente (sinta-se à vontade para testar no console, @markersocial):
./launcher enter app
rails c
ScreenedEmail.block('examplemailaddress@gmail.com')
ScreenedEmail.should_block?('e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com')
# true
O problema é:
# Centenas de contas criadas
ScreenedEmail.block('examplemailaddress@gmail.com')
# Centenas de contas ainda estão lá
Ah, certo, a solicitação original era bloquear todos os e-mails com caracteres especiais, por meio de uma configuração do site. Eu achei que tivesse proposto isso e que você não tivesse gostado? Não me lembro.
Acho que tudo isso se resume ao @markersocial querer um recurso (canônico forçado, como eu implementei originalmente) que nenhum dos nossos milhares de clientes hospedados parece precisar.
Podemos continuar refinando o recurso reativo (buscar por canônicos ao bloquear e solicitar ao administrador que exclua contas indesejadas). No entanto, eu preferiria ouvir algumas reclamações repetidas primeiro.
O bloqueio baseado em Regex certamente não funcionará para o @markersocial, mas estou feliz em que ele confirme.
Não tenho um caso reproduzível do problema no OP e suspeito fortemente que as contas problemáticas foram criadas antes da adição do bloqueio.
Posso confirmar que a correção original funcionou perfeitamente e resolveu esse problema com contas do Gmail. Seria uma verdadeira salvação se esse modo opcional fosse restaurado.
Spammers estão constantemente aprendendo novas técnicas e ainda estão conseguindo explorar grandes players como Facebook, Instagram e Twitter. Isso torna a maioria dos outros lugares “modo fácil”. Para muitos deles, isso se tornou um trabalho de tempo integral, então essencialmente vira:
Se for explorável e (recursos necessários < dinheiro ganho), então será explorado.
Eles podem contornar praticamente qualquer medida; a única esperança é aumentar os custos de fazê-lo até o ponto em que não seja mais financeiramente vantajoso.
Ser capaz de fazer spam em massa com quase emails/contas ilimitados (antes da detecção e de um moderador/admin bloquear retroativamente seu Gmail canônico e remover manualmente suas postagens) é bastante eficiente em termos de custo. Ainda mais se não houver uma equipe de moderadores 24/7.
O custo para contornar medidas anti-spam continua diminuindo. Um exemplo são proxies 4G/5G: por algo como US$ 30–50 por mês, as pessoas podem obter acesso a IPs móveis reais praticamente ilimitados, de provedores de internet/ASNs legítimos que rotacionam automaticamente ou manualmente e são compartilhados por cidades inteiras ou estados de usuários legítimos de grandes ISPs. IPs 4G/5G são compartilhados por muitos usuários simultaneamente.
Bloquear esses ISPs/ASNs ou IPs não é adequado (não dá para simplesmente bloquear todos que usam Verizon, AT&T etc.). Eles geralmente usam o IP uma vez e descartam. Os IPs individuais bloqueados disso também bloquearão usuários legítimos que estão compartilhando aquele endereço IP aleatoriamente. O bloqueio de IPs está se tornando gradualmente uma prática obsoleta (exceto ASNs de empresas de hospedagem conhecidas). Você pode ver a ponta do iceberg nesses fóruns:
Acredito que os spammers sejam uma mistura de bots totalmente ou parcialmente desenvolvidos manualmente e spam manual. À medida que o Discourse ganha mais participação de mercado, o que claramente está crescendo fantasticamente, ficaria surpreso se não se tornasse alvo de bots comercialmente disponíveis.
Sempre que o Xrumer começar a suportar a versão mais recente do reCAPTCHA, eu diria que a maioria dos webmasters em fóruns legados notará um grande aumento no spam devido ao custo extremamente baixo de fazer spam (não será mais necessário usar uma API de resolução de captcha, que já são muito baratas por 1k resoluções):
http://botmasterlabs.net/buy1/
As pessoas já podem criar seus próprios plugins/scripts para suportar praticamente qualquer plataforma usando o Xrumer. Mas se um dia eles passarem a suportar o Discourse nativamente:
Não posso me declarar imparcial sobre isso, já que estou diretamente na necessidade de medidas anti-spam. O post original sobre o truque do ponto do Gmail foi criado por outra pessoa em 2014 e parece que outro usuário resolveu isso exigindo aprovação nas primeiras x postagens, então talvez haja pelo menos três relatórios de usuários?
Desculpe pelo desvio, voltando ao assunto.
Quanto ao bloqueio por regex para emails, sim, você está correto. É uma solução parcial, mas não ideal pelos seguintes motivos:
Se bloquearmos todos os Gmails com 1 ponto ou mais antes do @:
Inevitavelmente bloquearemos usuários reais e legítimos do Gmail que tenham 1 ou mais pontos em seu email, o que é muito comum.
Os spammers ainda podem criar muitas variações com um único ponto. Por exemplo, o Gmail tem um comprimento máximo de 30 caracteres; por exemplo, 12345678901234567890123456789.0@gmail.com terá 30 combinações utilizáveis com um único ponto.
Bloquear todos os Gmails com 2 pontos ou mais antes do @:
Menos emails legítimos do Gmail serão bloqueados, mas ainda bloqueará usuários legítimos do Gmail que tenham mais de 1 ponto em seu email.
Os spammers podem criar muitas mais variações com um único Gmail de 30 caracteres. Acho que ~842 combinações ou algo assim.
Posso confirmar que as novas contas passaram após o bloqueio estar ativo, já que a data de criação do bloqueio é 1º de fevereiro. Eu estava observando a criação de novas contas ontem, vendo tanto casos de regras de bloqueio com correspondências recentes quanto novas inscrições usando combinações do mesmo email (apenas pontos).
Desativei as inscrições durante a noite e as reativei esta manhã. Eles criaram 104 novas contas até agora hoje com permutações desse endereço do Gmail e continuam se registrando mais. Posso confirmar que, uma vez que os pontos são removidos dos emails dessas contas, há uma correspondência exata com o registro de emails bloqueados do Screened Emails.
Tentei testar os blocos no rails c conforme descrito; é aqui que as coisas ficam um pouco estranhas.
Parece que alguns registros retornam ‘true’ conforme o previsto e outros retornam ‘false’, mesmo que o email testado seja uma correspondência exata com o email bloqueado canônico. Para os registros que retornam ‘true’, funcionou inteiramente conforme o previsto e retornou true para todas as variações que testei. Mas os emails que retornam false, todas as variações que testei também retornaram false.
Estava tentando encontrar alguma correlação. Posso confirmar que essas não estão correlacionadas (ou pelo menos não consistentemente correlacionadas):
Comprimento do email (antes do @)
Email contendo caracteres e números
Correspondências (quantidade de vezes bloqueado)
Data de correspondência
Parece haver uma correlação com a data de criação do bloqueio, sendo que registros mais antigos têm menor probabilidade de funcionar (retornam false). Registros criados há 9 dias retornaram uma mistura de true/false, e todos os registros que testei até agora que foram criados antes disso (1h–8d) estão retornando true.
Talvez possa estar relacionado a ‘max age unmatched emails’? Acredito que essa opção seja um pouco nova; eu a configurei no valor padrão de 365 dias.
Bem, se você puder fornecer passos detalhados para reproduzir um bug, com certeza o corrigiremos.
max age unmatched emails não é uma nova configuração — juntamente com max age unmatched ips, é uma ferramenta para limpar entradas muito antigas nas listas de IPs e e-mails filtrados, respectivamente, entradas que não corresponderam a nada há um ano.
Entendo o seu ponto. Acredito que a principal objeção que @codinghorror teve em relação à implementação original era o fato de estarmos carregando lógica específica do Google. Isso deixava o Jeff bastante desconfortável.
Acho que o refinamento de “tudo é convertido para canônico, independentemente do domínio” alivia um pouco essa preocupação.
Por exemplo:
sam+982@sam.com → permitido registrar … primeiro sam@sam.com s.a.m.@sam.com → não permitido registrar … segunda vez que notei sam@sam.com e que o canônico já estava registrado.
Isso pode retornar algum dia; só precisamos encontrar esse tipo de abuso em outro lugar. Na última vez que investiguei, não nos deparamos com esse abuso em nossa hospedagem.
Tenho apenas um pouco de tempo para postar hoje, mas queria compartilhar algumas informações adicionais antes de responder com mais detalhes.
Descobri que excluir um registro que estava retornando falso em logs → e-mail filtrado (permitir) e, em seguida, bloquear o e-mail novamente (excluindo o usuário + bloqueando na página de administração do usuário) fez com que uma regra que antes falhava passasse a retornar true consistentemente agora para a correspondência direta e variações.
Isso parece confirmar a observação de que o problema está relacionado a registros mais antigos. Precisarei testar mais.
Parece que consumiria bastante espaço. As endereços do Gmail são a única preocupação aqui?
