Sembra che il blocco funzioni ancora, ma non completamente: nei log vedo ancora corrispondenze regolari contro il record → email filtrate, ma non per tutte le combinazioni. L’utente è riuscito a creare diverse centinaia di account oggi utilizzando lo stesso indirizzo Gmail bloccato.
Le variazioni con punti che stanno usando sembrano avere tra 6 e 14 punti; la lunghezza dell’email è di 19 caratteri (prima della @); non stanno usando variazioni con il simbolo + (o tutte quelle variazioni vengono bloccate con successo).
Potrebbe essere rilevante: ho impostato la distanza di Levenshtein per gli email degli spammer a 3 (il valore predefinito è 2). Discourse è stato recentemente aggiornato dalla versione 2.6.x alla 2.7.1 stabile.
Hmm, non ricordo più come abbiamo risolto questa questione, @sam, ma potrebbe essere un bug, dato che hai detto:
Questo significa che se evil.person+77@gmail.com viene bloccato, procederemo a bloccare invece evilperson@gmail.com. Quindi, quando e.v.i.l.person@gmail.com cercherà di infiltrarsi, verrà bloccato grazie alla corrispondenza canonica.
Quindi cosa succede quando sara.hanson@ fa qualcosa di terribile e sarah.anson@ finisce nel mezzo? È proprio come nel caso in cui non sono sicuro che joe98@ e joe99@ possano essere considerati lo stesso indirizzo email. Immagino che dipenda dalla composizione della comunità e dal livello di discrezione manuale utilizzata nel processo di abbinamento.
L’“indirizzamento con plus” si riferisce almeno a una cartella appartenente alla casella di posta dello stesso indirizzo email (dato che tutto ciò che precede il “+” è identico).
Forse si potrebbe combattere la registrazione per intervallo di indirizzi IP? Tutto questo dipende da quanto sono sofisticati gli spammer. Venendo dalla comunità di Let’s Encrypt, abbiamo lì una traccia di discussione che descrive alcune tattiche di spam piuttosto ampie che sono state tentate. Abbiamo persino avuto persone che hanno fornito assistenza tecnica reale prima di inviare spam settimane dopo.
Interessante. Non avevo mai notato che Gmail facesse effettivamente quella distinzione. Oggi ho imparato diverse cose nuove. Mi chiedo perché lo facciano? Sembra che occuperebbe un bel po’ di spazio. Le indirizzi Gmail sono l’unica preoccupazione qui?
Penso che siamo arrivati a: “Sono a disagio per la posizione in cui ci siamo trovati, perché è un incubo per il supporto e non se ne andrà mai :)”.
Penso che se un sito è un vettore di spam, dovrebbe essere consentito dire “rendi canonici tutti i miei indirizzi email”, non mi importano gli svantaggi.
Ciò significa che queste due email hanno entrambe come canonico samsam@somewhere.com:
sam.sam@somewhere.com
samsam+11@somewhere.com
Se sam.sam@somewhere.com si è registrato, samsam+11@somewhere.com non potrà più registrarsi.
Questa era la mia soluzione originale, che alla fine ho annullato (anche se faceva un’eccezione specifica per Google, che a posteriori non è stata abbastanza severa).
Penso che dovremmo semplicemente archiviare questa questione aggiungendo una nuova impostazione del sito per:
“OMG sono un gigantesco vettore di spam, attiva la modalità mega tinfoil”
Per quanto riguarda il bug, ora le cose possono infiltrarsi facilmente se si aspetta di bloccare. Attualmente è un processo al 100% reattivo.
Ciò significa che questo funziona perfettamente (sentiti libero di testarlo nella 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
Il problema è:
# Centinaia di account creati
ScreenedEmail.block('examplemailaddress@gmail.com')
# Centinaia di account sono ancora lì
Ah giusto, la richiesta originale era di bloccare tutti gli email con caratteri speciali, tramite un’impostazione del sito. Pensavo di averlo proposto io e che non ti fosse piaciuto? Non ricordo più.
Credo che tutto si riduca al fatto che @markersocial desideri una funzionalità (canonico forzato, come l’avevo inizialmente implementato) che nessuno dei nostri migliaia di clienti ospitati sembra aver bisogno.
Possiamo continuare a perfezionare la funzionalità reattiva (ricerca di canonici durante il blocco e invito all’amministratore di eliminare account rumorosi). Tuttavia, preferirei sentire prima alcune lamentele ripetute.
Il blocco basato su espressioni regolari sicuramente non funzionerà per @markersocial, ma sono felice che lui lo confermi.
Non ho una riprova del problema nell’OP e sospetto fortemente che gli account problematici siano stati creati prima dell’aggiunta del blocco.
Posso confermare che la soluzione originale ha funzionato perfettamente e ha risolto questo problema con gli indirizzi Gmail. Sarebbe una vera salvezza se questa modalità opzionale venisse ripristinata.
Gli spammer stanno costantemente imparando nuove tecniche e riescono ancora a sfruttare grandi piattaforme come Facebook, Instagram e Twitter. Questo rende la maggior parte degli altri siti un “modo facile”. Per molti di loro è un lavoro a tempo pieno, quindi diventa essenzialmente:
Se è sfruttabile e (risorse richieste < guadagni ottenuti), allora verrà sfruttato.
Possono aggirare praticamente qualsiasi misura; l’unica speranza è aumentare i costi fino a un punto in cui non sia più economicamente vantaggioso farlo.
Potere inviare spam in massa con quasi email/conti illimitati (prima del rilevamento e del blocco retroattivo del loro indirizzo Gmail canonico da parte di un moderatore/amministratore, insieme alla rimozione manuale dei loro post) è piuttosto efficiente in termini di costi. Ancora di più se non c’è un team di moderatori attivo 24/7.
Il costo per aggirare le misure anti-spam continua a diminuire. Un esempio sono i proxy 4/5G: per circa 30-50 dollari al mese, le persone possono ottenere accesso a indirizzi IP mobili reali praticamente illimitati, provenienti da provider di servizi Internet (ISP) o sistemi autonomi (ASN) legittimi che ruotano automaticamente o manualmente e sono condivisi da intere città o stati di utenti legittimi di grandi ISP. Gli indirizzi IP 4/5G sono condivisi da molti utenti simultaneamente.
Bloccare questi ISP/ASN o indirizzi IP non è adatto (non si può semplicemente bloccare chiunque usi Verizon, AT&T, ecc.). In genere usano l’IP una volta e poi lo scartano. Gli indirizzi IP individuali bloccati in questo modo bloccheranno anche utenti legittimi che condividono casualmente quell’indirizzo IP. Il blocco degli indirizzi IP sta lentamente diventando una pratica obsoleta (esclusi gli ASN di noti provider di hosting). Si può vedere la punta dell’iceberg su questi forum:
Credo che gli spammer siano un misto di bot completamente o parzialmente sviluppati in proprio e spam manuale. Man mano che Discourse acquisisce quota di mercato, cosa che sta chiaramente facendo in modo fantastico, non mi sorprenderebbe se non diventasse un bersaglio per bot disponibili commercialmente.
Ogni volta che Xrumer inizierà a supportare l’ultima versione di reCAPTCHA, direi che la maggior parte dei webmaster sui forum legacy noterà un forte aumento dello spam a causa del costo irrisorio dello spamming (non è più necessario utilizzare un’API di risoluzione dei captcha, che sono già molto economici per 1.000 risoluzioni):
http://botmasterlabs.net/buy1/
Le persone possono già creare i propri plugin/script per supportare praticamente qualsiasi piattaforma usando Xrumer. Ma se un giorno supporteranno Discourse “out of the box”:
Non posso affermare di essere imparziale su questo, dato che ho un bisogno diretto di misure anti-spam. Il post originale sul trucco del punto di Gmail è stato creato da qualcun altro nel 2014 e sembra che un altro utente abbia risolto il problema richiedendo l’approvazione per i primi x post, quindi forse ci sono almeno tre segnalazioni da parte degli utenti?
Scusa per la divagazione, torniamo in carreggiata.
Per quanto riguarda il blocco regex per le email, sì, hai ragione. È una soluzione parziale, ma non ideale per questi motivi:
Se si bloccano tutti gli indirizzi Gmail con 1 punto o più prima della @:
Bloccerà inevitabilmente utenti Gmail legittimi che hanno 1 o più punti nel loro indirizzo Gmail, il che è molto comune.
Gli spammer possono comunque creare molte variazioni con un solo punto. Ad esempio, Gmail ha una lunghezza massima di 30 caratteri, ad esempio 12345678901234567890123456789.0@gmail.com avrà 30 combinazioni utilizzabili con un singolo punto.
Se si bloccano tutti gli indirizzi Gmail con 2 punti o più prima della @:
Meno indirizzi Gmail legittimi bloccati, ma bloccherà comunque utenti Gmail legittimi che hanno più di 1 punto nel loro indirizzo email.
Gli spammer possono creare molte più variazioni con un singolo indirizzo Gmail di 30 caratteri. Penso circa 842 combinazioni.
Posso confermare che i nuovi account sono arrivati dopo che il blocco è stato attivo, poiché la data di creazione del blocco è il 1 febbraio. Stavo osservando la creazione di nuovi account ieri, vedendo sia casi in cui la regola di blocco aveva nuove corrispondenze recenti, sia nuove registrazioni in arrivo che utilizzavano le combinazioni dello stesso indirizzo email (solo punti).
Ho disabilitato le registrazioni durante la notte e le ho riabilitate questa mattina. Hanno creato 104 nuovi account finora oggi con permutazioni di quell’indirizzo Gmail e continuano a registrarsene altri. Posso confermare che, una volta rimossi i punti dagli indirizzi email di questi account, corrisponde esattamente al record bloccato negli indirizzi email filtrati.
Ho provato a testare i blocchi in rails c come descritto; è qui che le cose si fanno un po’ strane.
Sembra che alcuni record restituiscano ‘true’ come previsto, mentre altri restituiscano ‘false’ anche se l’email testata è una corrispondenza esatta con l’email canonica bloccata. Per i record che restituiscono ‘true’, ha funzionato interamente come previsto, restituendo true per tutte le variazioni che ho testato. Ma per le email che restituiscono false, tutte le variazioni che ho testato hanno restituito false.
Stavo cercando di trovare eventuali correlazioni. Posso confermare che non sono correlate (o almeno non in modo coerente):
Lunghezza dell’email (prima della @)
Presenza di caratteri e numeri nell’email
Corrispondenze (numero di volte bloccato)
Data di corrispondenza
Sembra invece esserci una correlazione con la data di creazione del blocco: quelli più vecchi hanno meno probabilità di funzionare (restituiscono false). I record creati 9 giorni fa hanno restituito un mix di true/false, mentre tutti i record che ho testato finora creati prima di quel periodo (da 1 ora a 8 giorni) restituiscono true.
Potrebbe essere forse correlato a ‘max age unmatched emails’? Penso che questa opzione sia relativamente nuova; l’ho impostata al valore predefinito di 365 giorni.
Bene, se puoi fornire passaggi dettagliati per riprodurre un bug, lo risolveremo sicuramente.
max age unmatched emails non è una nuova impostazione: insieme a max age unmatched ips, è uno strumento per pulire le voci molto vecchie nelle liste degli indirizzi IP e delle email monitorati, ovvero quelle che non hanno corrisposto a nulla nell’ultimo anno.
Ti capisco perfettamente. Credo che una delle principali obiezioni di @codinghorror riguardo all’implementazione originale fosse il fatto che stavamo includendo una logica specifica per Google. Questo ha reso Jeff piuttosto preoccupato.
Immagino che il perfezionamento di “tutto viene reso canonico, indipendentemente dal dominio” allevi un po’ questa preoccupazione.
Ad esempio:
sam+982@sam.com → consentito registrarsi… prima sam@sam.com s.a.m.@sam.com → non consentito registrarsi… la seconda volta ho notato sam@sam.com e che il canonico era già registrato.
Questo potrebbe essere ripristinato un giorno; dobbiamo solo individuare questo abuso altrove. L’ultima volta che ho indagato, non abbiamo riscontrato questo tipo di abuso sul nostro hosting.
Ho solo un po’ di tempo per pubblicare oggi, ma volevo condividere alcune informazioni aggiuntive prima di rispondere in modo più approfondito.
Ho notato che eliminando un record che restituiva falso da logs → email filtrata (consenti), quindi bloccando nuovamente l’email (eliminando l’utente + bloccando dalla pagina di amministrazione dell’utente), una regola che in precedenza falliva ora restituisce in modo coerente vero sia per la corrispondenza diretta che per le varianti.
Questo sembra corrispondere all’osservazione che il problema riguardi i record più vecchi. Sarà necessario eseguire ulteriori test.
Sembra che occuperebbe un bel po’ di spazio. Le indirizzi Gmail sono l’unica preoccupazione qui?
