Parece que algunos spammers con su cuenta de Gmail bloqueada están logrando pasar con variaciones de puntos, a pesar de tener bloqueada la versión canónica de su correo.
Parece que el bloqueo aún funciona, pero no por completo, ya que sigo viendo coincidencias regulares contra el registro en los registros → correos filtrados, pero no para todas las combinaciones. El usuario pudo crear varias cientos de cuentas hoy usando el mismo correo de Gmail bloqueado.
Las variaciones con puntos que están usando parecen tener entre 6 y 14 puntos; la longitud del correo es de 19 caracteres (antes del @). No están usando variaciones con el signo + (o todas esas variaciones están siendo bloqueadas con éxito).
Podría ser relevante: tengo la distancia de Levenshtein para correos de spammers configurada en 3 (el valor predeterminado es 2). Discourse se actualizó recientemente de la versión 2.6.x a la 2.7.1 estable.
Hmm, olvidé cómo quedamos en esto, @sam, pero eso podría ser un error, ya que dijiste:
Esto significa que si evil.person+77@gmail.com queda bloqueado, procederemos a bloquear evilperson@gmail.com en su lugar. Entonces, cuando e.v.i.l.person@gmail.com intente colarse, será bloqueado debido a la coincidencia canónica.
¿Qué sucede entonces cuando sara.hanson@ hace algo terrible y sarah.anson@ queda atrapada en el fuego cruzado? Es similar a cómo no estoy seguro de que joe98@ y joe99@ puedan considerarse la misma dirección de correo electrónico. Supongo que esto depende de la composición de la comunidad y del nivel de discreción manual utilizado en el proceso de emparejamiento.
El «direcionamiento con signo más» al menos se refiere a una carpeta que pertenece al buzón de la misma dirección de correo electrónico (dado que todo lo anterior al «+» es idéntico).
¿Quizás combatir el registro por rango de IP? Todo esto depende de cuán sofisticados sean los spammers. Al venir de la comunidad de Let’s Encrypt, tenemos un hilo de seguimiento allí que detalla algunas tácticas de spam bastante amplias que se han intentado. Incluso hemos tenido personas que brindaron ayuda técnica real antes de hacer spam semanas después.
Interesante. Nunca me había dado cuenta de que Gmail hacía esa distinción. Hoy he aprendido más de unas cuantas cosas nuevas. Me pregunto por qué lo harían. Parece que consumiría bastante espacio. ¿Son las direcciones de Gmail la única preocupación aquí?
Creo que llegamos a la conclusión de: “Me siento incómodo con el lugar donde terminamos, porque es una pesadilla de soporte y nunca se irá :)”.
Siento que si un sitio es un vector de spam, debería poder decir: “haz que todos mis correos sean canónicos”, no me importan las desventajas.
Es decir, estos dos correos tendrían el canónico samsam@somewhere.com:
sam.sam@somewhere.com
samsam+11@somewhere.com
Si sam.sam@somewhere.com se registró, samsam+11@somewhere.com ya no podrá registrarse.
Esa fue mi solución original, que finalmente revertí (aunque hacía una excepción especial para Google, lo cual, en retrospectiva, no fue lo suficientemente estricto).
Siento que deberíamos dejar esto atrás añadiendo una nueva configuración del sitio para:
“OMG, soy un gigante vector de spam, activa el modo mega gorro de papel de aluminio”
En cuanto al error, ahora las cosas pueden colarse fácilmente si esperas para bloquear. Actualmente es un proceso 100% reactivo.
Es decir, esto funciona perfectamente (siéntete libre de probarlo en la consola @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
El problema es:
# Se crearon cientos de cuentas
ScreenedEmail.block('examplemailaddress@gmail.com')
# Cientos de cuentas siguen ahí
Ah, claro, la solicitud original era bloquear todos los correos electrónicos que contuvieran caracteres especiales, mediante una configuración del sitio. ¿Pensé que había propuesto esto y no te gustó? No lo recuerdo.
Creo que todo esto se reduce a que @markersocial quiere una función (canónico forzado, como lo implementé originalmente) que ninguno de nuestros miles de clientes alojados parece necesitar.
Podemos seguir perfeccionando la función reactiva (buscar canónicos al bloquear y solicitar al administrador que elimine cuentas de ruido). Aunque preferiría escuchar primero algunas quejas repetidas.
El bloqueo basado en expresiones regulares definitivamente no funcionará para @markersocial, pero estoy encantado de que lo confirme.
No tengo una reproducción del problema en la publicación original y sospecho fuertemente que las cuentas problemáticas se crearon antes de que se agregara el bloqueo.
Puedo confirmar que la solución original funcionó perfectamente y resolvió este problema con los correos de Gmail. Sería un salvavidas real si se restableciera este modo opcional.
Los spammers están aprendiendo constantemente nuevas técnicas y aún están burlando con éxito a grandes jugadores como Facebook, Instagram y Twitter. Esto convierte a la mayoría de los demás lugares en “modo fácil”. Para muchos de ellos, esto es un trabajo a tiempo completo, por lo que esencialmente se convierte en:
Si es explotable y (recursos requeridos < dinero ganado), entonces será explotado.
Pueden eludir prácticamente cualquier medida; la única esperanza es aumentar los costos hasta que deje de ser rentable hacerlo.
Poder enviar spam masivo con correos/cuentas casi ilimitados (antes de la detección y el bloqueo retroactivo de su Gmail canónico por parte de un moderador/admin, junto con la eliminación manual de sus publicaciones) es bastante eficiente en cuanto a costos. Más aún si no hay un equipo de moderadores 24/7.
El costo para eludir las medidas antispam sigue disminuyendo. Un ejemplo son los proxies 4G/5G; por algo como 30-50 dólares al mes, las personas pueden acceder a IPs móviles reales prácticamente ilimitadas, de proveedores de servicios de internet (ISP) o sistemas autónomos (ASN) legítimos que rotan automática o manualmente y son compartidos por ciudades o estados enteros de usuarios legítimos de grandes ISPs. Las IPs 4G/5G son compartidas por muchos usuarios simultáneamente.
Bloquear estos ISPs/ASN o IPs no es adecuado (no se puede simplemente bloquear a todos los que usan Verizon, AT&T, etc.). Generalmente usan la IP una vez y la desechan. Las IPs individuales bloqueadas de este grupo también bloquearán a usuarios legítimos que estén compartiendo esa dirección IP al azar. El bloqueo de IPs se está volviendo lentamente una práctica obsoleta (excluyendo los ASN de empresas de hosting conocidas). Puedes ver la punta del iceberg en estos foros:
Creo que los spammers son una mezcla de bots totalmente o parcialmente creados a mano y spam manual. A medida que Discourse capture más cuota de mercado, lo cual claramente está creciendo de manera fantástica, me sorprendería si no se convierte en un objetivo de bots comercialmente disponibles.
Cada vez que Xrumer comience a soportar la última versión de reCAPTCHA, diría que la mayoría de los webmasters en foros legacy notarán un gran aumento en el spam debido al costo ridículamente bajo del spam (ya no es necesario usar una API de resolución de captcha, que ya son muy baratas por cada 1k de resoluciones):
http://botmasterlabs.net/buy1/
La gente ya puede crear sus propios plugins/scripts para soportar prácticamente cualquier plataforma usando Xrumer. Pero si algún día soportan Discourse de inmediato:
No puedo afirmar ser imparcial en esto, ya que tengo una necesidad directa de medidas antispam. El post original sobre el truco del punto en Gmail fue creado por otra persona en 2014 y parece que otro usuario resolvió esto requiriendo aprobación para las primeras x publicaciones, así que quizás haya al menos tres reportes de usuarios.
Perdón por la desviación, volvamos al tema.
En cuanto al bloqueo por regex para correos electrónicos, sí, tienes razón. Es una solución parcial, pero no ideal por estas razones:
Si bloqueas todos los Gmail con 1 punto o más antes de @:
Bloquearás inevitablemente a usuarios legítimos de Gmail que tengan 1 o más puntos en su correo, lo cual es muy común.
Los spammers aún pueden crear muchas variaciones con un solo punto. Por ejemplo, Gmail tiene una longitud máxima de 30 caracteres, por ejemplo: 12345678901234567890123456789.0@gmail.com tendrá 30 combinaciones utilizables con un solo punto.
Si bloqueas todos los Gmail con 2 puntos o más antes de @:
Se bloquearán menos correos legítimos, pero aún así se bloquearán usuarios legítimos de Gmail que tengan más de 1 punto en su correo.
Los spammers pueden crear muchas más variaciones con un solo Gmail de 30 caracteres. Creo que unas 842 combinaciones o así.
Puedo confirmar que las nuevas cuentas llegaron después de que el bloqueo estuviera activo, ya que la fecha de creación del bloqueo es el 1 de febrero. Estaba observando la creación de nuevas cuentas ayer mientras veía ambos casos: la regla de bloqueo teniendo nuevas coincidencias recientes, así como nuevas registraciones entrando usando combinaciones del mismo correo (solo puntos).
Desactivé los registros durante la noche y los volví a activar esta mañana. Han creado 104 nuevas cuentas hasta ahora hoy con permutaciones de esa dirección de Gmail y continúan registrando más. Puedo confirmar que una vez que se eliminan los puntos de los correos de estas cuentas, es una coincidencia exacta con el registro bloqueado de Correos Filtrados.
Intenté probar los bloqueos en rails c como se describió; aquí es donde se pone un poco extraño.
Parece que algunos registros están devolviendo ‘true’ como se esperaba y otros están devolviendo ‘false’, incluso si el correo probado es una coincidencia exacta con el correo canónico bloqueado. Para los registros que devuelven ‘true’, funcionó exactamente como se esperaba y devolvió true para todas las variaciones que probé. Pero para los correos que devuelven false, todas las variaciones que probé también devolvieron false.
Estaba tratando de encontrar alguna correlación. Puedo confirmar que estos no están correlacionados (o al menos no consistentemente):
Longitud del correo (antes de @)
Correo que contiene caracteres y números
Coincidencias (cantidad de veces bloqueado)
Fecha de coincidencia
Parece que sí hay una correlación con la fecha de creación del bloqueo, siendo los más antiguos menos propensos a funcionar (devuelven false). Los registros creados hace 9 días devolvieron una mezcla de true/false, y todos los registros que he probado hasta ahora que fueron creados antes de eso (de 1h a 8d) están devolviendo true.
¿Podría estar relacionado con ‘máxima antigüedad de correos no coincidentes’? Creo que esta opción es algo nueva; la tengo configurada con el valor predeterminado de 365 días.
Bueno, si puedes proporcionar pasos detallados para reproducir un error, definitivamente lo corregiremos.
max age unmatched emails no es una configuración nueva; junto con max age unmatched ips, es una herramienta para limpiar entradas muy antiguas en las listas de IPs y correos electrónicos filtrados, respectivamente, es decir, entradas que no han coincidido con nada en un año.
Te entiendo perfectamente. Creo que la principal objeción que tuvo @codinghorror sobre la implementación original era que estábamos incluyendo lógica específica para Google. Esto inquietaba bastante a Jeff.
Supongo que el refinamiento de “todo se convierte en canónico, independientemente del dominio” alivia un poco esta preocupación.
Por ejemplo:
sam+982@sam.com → permitido registrarse … primero sam@sam.com s.a.m.@sam.com → no permitido registrarse … la segunda vez que noté sam@sam.com y que ese canónico ya estaba registrado.
Esto podría volver algún día; solo necesitamos encontrar ese abuso en otro lugar. La última vez que investigué, no nos encontramos con este tipo de abuso en nuestro hosting.
Solo tengo un poco de tiempo para publicar hoy, pero quería compartir información adicional antes de responder con más detalle.
He descubierto que eliminar un registro que devolvía falso en registros → correo electrónico filtrado (permitir), y luego volver a bloquear el correo electrónico nuevamente (mediante la eliminación del usuario + bloqueo en la página de administración del usuario) ha hecho que una regla que antes fallaba ahora devuelva consistentemente verdadero tanto para la coincidencia directa como para las variaciones.
Esto parece coincidir con la observación de que el problema estaba en registros antiguos. Necesitaré realizar más pruebas.
Parece que consumiría bastante espacio. ¿Son las direcciones de Gmail la única preocupación aquí?
