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:
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
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.comavrà 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.
