199 meneos
1339 clics
CloudFlare: 94% del tráfico de Tor que vemos es "malicioso per se" [ENG]
Los usuarios legítimos sufren mientras Tor se convierte en una herramienta favorita de spammers y estafadores. "No quiere decir que sean visitas a contenido polémico, sino que se trata de peticiones automáticas diseñadas para hacer daño a nuestros clientes. Un gran porcentaje del spam en comentarios, fraude en click de publicidad, copias de contenidos y escaneo de logins viene de Tor. Según el proyecto Honey Pot un 18% de todo el spam por mail, 6.5 billones de mensajes, tiene su origen en un bot recolectando direcciones a través de Tor."
|
comentarios cerrados
Y hemos sufrido varios exploits 0-day de servidor y un cliente con un cryptolocker.
En nuestra balanza acabó pesando más los riesgos que los beneficios.
Si te dedicas a la seguridad y tienes un server online lo ves muy claro.
Para una sola conexión que pueda ser legítima, tenemos cientos fraudulentas o directamente agresivas.
Hay momento en que el syslog empieza a tirar mensajes por que no da literalmente a basto.
A nosotros no nos merece la pena.
Es triste, pero es así.
Es como abrir un bar.
Si al final la gran mayoría de los clientes son broncas que no pagan y te roban, acabas cerrando el bar o poniendo un tipo en la puerta.
Y te insisto. Conceptualmente no me gusta. Pero no dejan otra opción si quieres dar un servicio medio decente. Y eso teniendo encuenta que somos unos don-nadie que no aportamos interés para un ataque dirigido. Si fueramos medio conocidos ni te cuento.
Hace un mes decidimos subir el nivel de seguridad mediante bloqueos de IPs basados en listas de reputación.
Estábamos hartos, muy hartos de spam, escaneo, fuerza bruta e intentos de compras online con tarjetas robadas a todas horas.
En un mes hemos registrado 43.000 bloqueos maliciosos.
Nuestros clientes están encantados. Hemos reducido el Spam notablemente, el uso de tarjetas robadas ha cesado prácticamente y los carga de los servidores ha bajado.
Uno de los criterios a valorar fue incluir los listados de los de nodos Tor de salida.
De momento se queda.
El uso legítimo suele ser hecho por humanos interactuando con el ordenador, mientras que el abuso se suele hacer programando a los ordenadores para que hagan la tarea sucia, por ello las estadísticas pueden ser engañosas.
1 www.theatlas.com/i/atlas_NJipnKmq.png
Este tipo de prácticas son las que dejaron bloqueados en su momento a todos los clientes de Telefónica, tuvieran servidor de correo propio o no.
Las técnicas antispam deben abordarse con criterios que apliquen a los correos electrónicos, no a operadores ni a tecnologías y mucho menos a rangos de ips.
Dnsbl + Spamassasin + mod-security más mil cosas y te puedo pasar cientos de lineas de log que no se si dan más rabia que pena.
Usamos listas de reputación dinámicas, no bloqueos a pelo. Si una IP aparece marcada como spammer, o secuestrada (si, se secuestran rangosde ips completos de empresas que los tenian asignados y quebraron y no han expirado las concesiones) va a la lista de bloqueo.
Los bloqueos son revisados periódicamente y al menos una vez al día.
No bloqueados ni por países ni por operadores pero a veces te obligan. Si no puedes dejar una puerta abierta por que te roban todos los días acabas poniendo un cerrojo.
No somos los culpables de esta situación.
Somos las víctimas.
Estás obligando a todos los clientes de Telefónica a cambiar de operador para poder enviar correos electrónicos, o en tu caso estás limitando a todos los usuarios de Tor a renunciar al uso de esta tecnología para poder enviar correos electrónicos.
El enfoque es erróneo, las consecuencias son perjudiciales para todos, la solución no pasa por vetar tecnologías enteras.
Las víctimas de esos actos son todos los ciudadanos que necesitan o deseen usar la red Tor por los motivos que sean, que pueden ser muy legítimos.
Y hemos sufrido varios exploits 0-day de servidor y un cliente con un cryptolocker.
En nuestra balanza acabó pesando más los riesgos que los beneficios.
Si te dedicas a la seguridad y tienes un server online lo ves muy claro.
Para una sola conexión que pueda ser legítima, tenemos cientos fraudulentas o directamente agresivas.
Hay momento en que el syslog empieza a tirar mensajes por que no da literalmente a basto.
A nosotros no nos merece la pena.
Es triste, pero es así.
Es como abrir un bar.
Si al final la gran mayoría de los clientes son broncas que no pagan y te roban, acabas cerrando el bar o poniendo un tipo en la puerta.
Y te insisto. Conceptualmente no me gusta. Pero no dejan otra opción si quieres dar un servicio medio decente. Y eso teniendo encuenta que somos unos don-nadie que no aportamos interés para un ataque dirigido. Si fueramos medio conocidos ni te cuento.
Espero que la calidad de la tecnología aumente y los actos delictivos sean sólo una mínima cifra.
Correos tratados como legítimos: 654
Correos identificados como SPAM por SpamAssasin: 27 (estos están incluidos en los anteriores)
Correos directamente rechazados por DNSBL: 489 (son independientes de los anteriores)
Conexiones bloquedas al SMTP: 91 (son independientes tambien de los anteriores)
Conexiones totales bloqueadas: 2445 (son independientes de los anteriores)
Haz números.
El ratio legítimo/spam es casi al 50% despues de quitarnos los de las listas de IP. Y aún así se cuela SPAM.
El servidor no sabe qué o quién hay detrás de cada conexión.
No está mal para ser unos mindundis....
En mi servidor tengo bloqueadas todas las IP del planeta, excepto Canadá, EEUU y los países, supuestamente, civilizados de Europa.
Y pese a ello, alguna mierda se cuela...
Como he indicado en otro comentario un correo legítimo, uno que realmente aporta valor, ha sido escrito por una persona (no cuento las listas de correo automatizadas, que normalmente son más spam que otra cosa), mientras que un correo malicioso ha sido escrito y enviado por un ordenador pudiendo enviar cientos o miles por segundo. Las estadísticas van en contra de los seres humanos por definición, pero lo que aporta valor compensa con creces las molestias que puedan generar los correos maliciosos automatizados.
No pretendo impresionarte, solo aportar cifras reales, datos, para los que no han tocado servidores y para refutar mi experiencia.
No se trata de valorar humano/máquina.
El problema es que la tecnología de filtrado está en bragas y va tres años por detrás de los delincuentes. No son todo lo eficientes que nos gustaría. No puedes ser pasivo si administras un MTA porque acaba lleno de basura y el servicio que acabas prestando a los humanos que te pagan es pésimo.
Y tienes que acabar tomando medidas que, en mi experiencia, está funcionando para bloquear la máquina y dejar pasar al humano.
Más bien es un problema que tendrá que resolver Tor.
Por cierto #1 yo uso cloudflare. Por $20 me puedo centrar en el contenido y el servicio que ofrece mi web y no pensar mucho en DDoS y otros ataques.
Los dueños de las webs no se van a preocupar de poner filtros.
No sabrían ni de qué les estas hablando. Son todo Pymes y microPymes que ni siquiera tienen departamento de IT propio. No esperamos que ellos lo hagan por que en muchos casos la informática la tienen externalizada con nosotros.
De hecho la gran mayoría no sabe qué es Tor.
Nosotros administramos los servidores donde se alojan sus dominios y creemos que es nuestra responsabilidad mantener los mínimos de seguridad de nuestros clientes.
Por su perfil no se espera que nadie venga por Tor, aunque el concepto de usuario legítimo de Tor es bastante amplio y difuso como para poder determinar con certeza que cliente debería esperar un usuario vía Tor y cual no...
Hasta hora no nos habíamos planteado opciones por el perfil tanto nuestro como de nuestros clientes. Somos todos muy pequeños. Pero lo vamos a valorar.
Cualquier negocio aplica las medidas de seguridad en base al entorno y la coyuntura de su entorno.
Si pongo una pastelería en un centro comercial, necesito menos seguridad que si la pongo en medio de Lavapiés.
No se puede culpar a un administrador de implementar medidas que benefician a los que trabajan en su red. Ser un sysadmin es ser un eterno incomprendido.
Todas las compras que hemos detectado vienen a traves de salidas de VPN de HideMyAss fundamentalmente (y de Alicante para más señas).
Y los pedidos se entregan en un bar de Alcalá de Guadaira.
Estamos por ir a tomar un café allí.
Es un problemón si tu perfil de cliente es de nivel alto porque no puedes distinguir a primera vista si la tarjeta es robada porque hay clientes que compran aceite por valor de miles de euros.
Como el TPV virtual está en modo no seguro1 (ojo con esta definición, que no es lo que parece) el resultado es que procesas la compra porque la pasta la recibes, envias el pedido, te lo recogen y al cabo de varios meses recibes una notificación del banco, del departamento de fraude y quebrantos, que te retrotráen el importe de la compra porque se trata de una compra fraudulenta.
Y el cliente se queda sin producto, porque lo ha entregado, y sin dinero porque el banco carga la responsabilidad de la verificación de la tarjeta en el vendedor, cuando no te insinuan que estas conchabado con el delincuente.
¡Lo cojonudo es que el vendedor nunca ve nada de la tarjeta, ni la tarjeta física, ni los números!
A eso añadele que tu aceite de gran calidad, exclusivo, se acaba vendiendo en mercadillos como aceite barato.
1Modo no seguro: No te envía un código al móvil cuando haces la compra.
1Modo seguro: Te envía un código al móvil cuando haces la compra. El problema es que no todas las tarjetas lo soportan, cada vez menos, y pierdes ventas por no poder cobrar al cliente. Ya ocurre con menos frecuencia pero ocurre, sobre todo con perfiles de compradores poco tecnológicos, que los hay (personas mayores, por ejemplo)
Un ejemplo de hacerlo mal (pero mal de cojones) es lo que hace Godaddy: Inspecciona el cuerpo del mensaje y si tiene alguna URL que no le gusta, borra el email sin más. Es decir, es imposible decirle a un cliente de Godaddy "Echa un vistazo a esta página [que está en un dominio bloqueado por Godaddy]". Nunca llegará ese correo.
Cuando decimos "Todas las compras" nos referimos a los que nos han pedido informe para poner denuncia y por lo tanto hemos hecho análisis forense de toda la transacción.
Nos llegan de más sitios aparte de los de HideMyAss.
La privacidad no la matará la NSA ni pollas, la matarán los putos spamers y demáses "obligando" a los sitios a bloquear VPNs, Tor, etc...
Nosotros nos apoyamos, para bloquear una conexión, en listas de reputación IP que han demostrado ser una amenaza real.
Entre otras nos apoyamos en información de honeypots facilitados por, al menos, los siguientes:
cinsscore.com/
blocklist.de
rules.emergingthreats.net (www.proofpoint.com/us/threat-intelligence-overview)
www.spamhaus.org (estos además para DNSBL del SpamAssasin)
Las ip's de estas listas son dinámicas, hoy estas, mañana no. Hay al menos una actualización diaria en los servidores.
Si estás ahí es porque se ha detectado actividad maliciosa demostrada.
No hacemos bloqueos tipo "Todo lo que me venga de Orange" sino solo lo que me confirmen que hay actividad maliciosa. Si pasas ese primer filtro te aceptamos la conexión al MTA/Web.
La siguiente decisión, y hablo de SPAM, es si la IP está en listas de Spammers puros y duros (www.spamhaus.org , www.spamcop.net y www.barracuda.com fundamentalmente). Esta es en tiempo real.
Si pasas ese filtro, el siguiente paso de SpamAssasin analiza con sus reglas locales y análisis de contenido.
Aquí además se filtran las URLs que aparezcan en el correo (Pyzor y Razor). Cada detalle malicioso suma puntos. Unos más otros menos.
Si el correo alcanza una puntuación de 5 se marca como SPAM y se entrega.
Si pasas todo lo anterior, se entrega como limpio.
Y aún así llega basura.
Por cierto, Hotmail hace lo mismo que GoDaddy. Te acepta el correo pero lo borra silenciosamente sin avisar al usuario final.
A mí me ha pasado alquilar un servidor y que me den una IP que está en 15 listas negras porque el anterior usuario ha abusado de ella todo lo que ha querido y luego la ha abandonado.
Y sí, puedo pedir que borren la IP de la lista, y lo hacen, el problema es que son montones de listas, de alguna puede que no lo hagan rápido, y mientras tanto algunos correos no se pueden mandar. No es que lleguen al spam del usuario final, es que no se pueden entregar en absoluto.
A mí ese corte de comunicación me parece absolutamente excesivo, y si fuera el destinario final y me dijesen que es imposible que tal o cual dominio me manda un correo a pesar de que yo estoy diciendo que lo quiero, mandaría a tomar por culo esa cuenta sin contemplaciones.
Pero gorda.
Pero en todos ellos el motivo ha sido siempre el mismo. Una cuenta de correo con una contraseña debil, un usuario que pilla un troyano que accede a la configuración de correo, o un exploit 0-day (y alguno 180-day ) en un CMS.
Siempre que lo hemos sufrido ha tenido una justificación.
Y dices bien.
Cada server tiene dos IPs, la de producción y la de reserva de blacklist a la que cambiar si caemos en alguna DNSBL. Cuando adquieres una IP no te la dicen de antemano para que la puedas verificar.
A día de hoy llevamos 11 meses sin estar en listas negras, pero hace poco nos comimos el 0-day de Joomla. Fue bestial el barrido que hicieron. Dejaron miles de agujeros durmientes.
A día de hoy hay miles de Joomlas "guardados" para ser explotados mas adelante
Fuimos rápidos y pudimos tapar el boquete y aun así nos cayeron tres dominios que estuvieron a un tris de ir a lista negra.
Desde ese momento decidimos ponernos bordes con el tema de las IPs.
No hay una solución ni buena ni de equilibrio.
Como se te cuelen date por jodido tu y tus clientes.
Son las reglas del juego en internet.
Lo que estás defendiendo son los servicios VIP, que el usuario deba pagar extra para usar un servicio que hasta entonces había estado al alcance de todos, de limitar el acceso a Internet entre los usuarios receptores y los usuarios emisores, haciendo pagar más a éstos últimos por ello (no solo económicamente).
Y por cierto, no hay por qué pagar más. Si es su propio correo puede mandarlo usarlo el SMTP gratuito de por ejemplo Google. Nadie va a rechazar a lo bestia un email que llega de una IP de google, aunque sí se clasificará como spam si corresponde.
Ahora, pretender conectar vía SMTP a pelo desde una IP dinámica de casa para mandar correo desde un dominio que no tiene vinculación técnica alguna con esa IP... pues sí, eso se ha terminado.
No voy a entrar en símiles ya que se desmontan muy fácilmente, por ejemplo en este caso podríamos hablar de Derechos Humanos.
Nadie está discutiendo que se pongan medidas de seguridad, si no el hecho que esas "medidas de seguridad" se basen en bloquear el acceso a tecnologías enteras.
Si random.com es su dominio que lo configure bien. Si es una cuenta de su ISP que use el SMTP de su ISP que estará bien configurado.
Si no quiere hacer ninguna de las dos cosas pues allá él si sus correos no llegan nunca.
Y si tiene que pagar algo pues que lo pague, igual que paga la conexión a internet.
Pero si lo importante es la seguridad, hay que joderse y poner el cepo.
Es injusto que por culpa de las páginas que abusan de la publicidad poniendo anuncios molestos e intrusivos tengas que bloquear a webs que ponen un banner en un lateral, sin tapar el contenido ni apenas molestar. Pero la mayoría de la gente hace uso abusivo de la publicidad, así que la bloqueas toda y que paguen justos por pecadores.
Pues lo que #2 con las conexiones TOR es lo mismo. ¿Qué hay usos legítimos? Pues si, pero si la mayoría provoca molestia, pues les bloqueas a todos.
Si yo en mi cuenta de correo pongo un filtro de usuario que indique que solo acepto correos de mis familiares directos y el resto se van directos a la basura eso es cosa mía, estoy en mi derecho de tomar esa decisión, si esa decisión la toma el administrador del servidor de correo está haciendo una barbaridad inaceptable.
No, no es lo mismo lo que haga un usuario final que lo que haga un proveedor de servicios. Y bloquear a todo el operador de Telefónica o bloquear a toda la red Tor es una injerencia injustificable.
Si bloqueas a todo el operador Telefónica, bloqueas a toda Somalia o a toda la red Tor claro que está bien que el remitente reciba un error indicando que ese rango de ips ha sido bloqueado e incluso el motivo, pero el bloqueo sigue siendo un enfoque erróneo al problema.
Para ciertos filtros de correo no es viable técnicamente avisar al remitente del bloqueo, por ejemplo si necesitas aplicar un análisis heurístico del contenido o descomprimir un zip que lleve el correo para analizar su contenido, en ese supuesto tiene poco sentido mantener la conexión abierta con el servidor que ha enviado el correo e informarle del problema en la misma conexión. Y si la conexión ya está cerrada la única forma para comunicarse con el remitente es enviarle un nuevo correo a ese remitente informándole del error, por desgracia el remitente puede ser falso, y es habitual que lo sea en correos maliciosos, por lo que la respuesta le llegaría a una víctima que nada sabe de ese correo original y nuestro servidor de correo estaría siendo entonces el que estaría llevando a cabo el ataque y podría ser incluído en listas negras.
Otro escenario que puede darse donde avisar del error de recepción puede ser problemático es cuando existe una separación entre el servidor de correo entrante y el servidor de antispam, en cuyo caso cuando éste recibe el correo ya sería tarde para hablar con el servidor que lo ha enviado.
De nuevo, el debate sobre los criterios de exclusión (extensiones en adjuntos, bloqueo de ips, etc.) es paralelo al debate sobre cuándo y cómo informar al emisor del correo.
/mode on
Aunque quizá Hotmail quiere recibirlo sí o sí para ver el contenido.
Para mí es imposible mirar ese correo uno a uno. gmail lo hace por mí, y por supuesto uno de los criterios es de donde viene el correo. Los "falsos positivos" discutibles se clasifican en estos grupos:
- Correo que es spam *para mí*, por ejemplo los de la fnac. ¿por qué son spam? Porque no me puedo dar de baja sin entrar en su puta web, de la que no recuerdo la contraseña. En lugar de un link de unsubscribe pretenden que busque como darme de baja en su web. Pues bueno, me parece fantástico que haya gente que esté deseosa de recibir las ofertas de la semana de la fnac, yo no, y para mí es spam. Esto gmail lo entiende muy bien y va directo a spam.
- Correo que no es spam pero que no cumple los requisitos técnicos de envío y no es culpa del remitente. Esto me pasa sobre todo con correo redirigido de mi primera cuenta a gmail, que deja de cumplir DKIM u otros por la redirección. Ejemplo kickstarter.
- Correo que no es spam pero que está mal configurado en origen. Como gmail me dice por qué está en la bandeja de spam, si me interesa aviso al remitente y si no que le den por saco.
En fin, para mí este trabajo de clasificación es necesario que lo haga alguien que no sea yo, y a la vez que yo pueda revisar ese trabajo y corregir o tunear.
Lo que hacen algunos proveedores de email de rechazar el correo directamente me parece inaceptable. Es más, te diría que incluso rebotar el correo a estas alturas no es una solución válida, porque muchos correos importantes no vienen de personas que vayan a revisar el rechazo.
En cambio, clasificar como spam utilizando todos los criterios disponibles, incluyendo por supuesto si viene de TOR o de una IP dinámica (lo que significa en el 99.99% de los casos un windows infectado y no un usuario avanzado).
Mi crítica ha sido en todo momento al bloqueo a rangos de direcciones Ip o a tecnologías enteras, no he criticado en ningún momento que esa información no se use para ayudar a catalogar un correo como legítimo o spam, dando la última palabra al usuario final.
Google no tiene ningún problema en recibir miles de millones de emails al día y analizar todos uno a uno.
En cambio si tienes un servidor pequeño que gestiona unas pocas cuentas es imposible hacer el trabajo de administración, y directamente puede que el propio servidor no tenga capacidad para hacer el filtrado por mucha voluntad que el administrador tenga.
¿qué haces en este caso? Pues filtras toda el bloque y listo. A fin de cuentas no te pierdes nada...
Vamos, que todo depende del punto de vista. Yo en mis servidores "caseros" donde tengo las webs de mis amigos filtro a saco. Para cosas serias, utilizo servicios serios
Ah, y uso CloudFlare en las webs que no pueden tener downtime. Ya sé lo que es ser víctima de un DDoS y aunque si tienes tu servidor decentemente bien configurado no van a hackeartelo (salvo que vayan a específicamente a por él y sean buenos, entonces date por follado) desde luego sí te pueden dejar sin servicio todo el tiempo que quieran... y eso en el caso mejor, que lo mismo el data center te da una patada por ser problemático.
Un equipo de hace 10 años puede hacer esa tarea sin despeinarse apenas.
También la razón por la que muchísimos usuarios de Google Apps prefieren delegar en google la gestión de su correo a pesar de tener material y personal para hacerlo ellos mismos.
Lo sé porque lo he vivido.
Mira, todavía guardo este email que recibí durante un DDoS:
***********
Hi,
I am the individual ddosing your website, if you wish for this to stop and not get worse or become a regular thing, please send $250 in Bitcoin to the following address [dirección de bitcoin]
once i have confirmed the requested amount has been delivered, i will permanently stop the ddos. You have my word on this [...]
***********
Los logs echaban chispas con conexiones de Tor.
Sería interesante conocer estadísticas que permitan avalar que realmente se esté utilizando la red Tor para hacer ataques DDoS de forma significativa. Sea como fuere las técnicas a aplicar, de nuevo, deben tener como objetivo evitar el ataque pero permitiendo los accesos legítimos. Siguiendo el ejemplo de Telefónica el hecho que vieras en tus logs muchas IPs del operador de Telefónica en el ataque DDoS seguiría siendo inaceptable poner un bloqueo completo a ese operador de forma permanente, ya que impedirías a sus usuarios legítimos acceder a tu sitio y servicios. Lo mismo con la red Tor.
EDIT: + para el DNS.
Si pasaba de X injustificadamente en un tiempo discreto, adiós o capada bestial.
Lo más "rígido" actualmente es DMARC o lo que es lo mismo SPF + DKIM + "Que deben hacer los demas"
SPF: En tu DNS estableces qué servidores y/o IPs están autorizados a enviar correo del dominio fulano. Cualquier otro servidor que intente enviar correo en nombre de ese dominio debe considerarse fraudulento.
El de Meneame es v=spf1 ip4:79.125.22.108 include:amazonses.com include:_spf.google.com ~all
Personalmente preferimos terminar con -all (~ indica que es posible que envies con otro servidor que no esta en la lista; - indica que o es desde estos o el correo no es mio)
DKIM: Es firma PKI (clave privada en el server y pública en DNS).El servidor firma con la clave privada todos los correos salientes. Cualquier destinatario puede comprobar si el mensaje viene firmado por el servidor mediante la clave pública que se da a conocer mediante un puntero DNS también
Es algo como esto: v=DKIM1; k=rsa; p=MIGfMA0GC[resto del chiorizo]/wIDAQAB
DMARC: A los destinatarios les dices que tienen que hacer con el correo que no cumpla alguno de los dos requisitos anteriores y a que cuenta deben informarte de lo que hacen.
Eso autentifica tu correo frente a terceros y evita que nadie envia nada en tu nombre.
Ahora bien.
Te revientan un CMS con un 0-day y mediante PHPMail empiezan a enviar correo con un remitente de tu dominio. El servidor va a firmar todo, no distingue si es legítimo o no, y salvo que el SpamAssasin vea algo raro, vas a empezar a enviar mierda firmada desde tu dominio. En el momento que toques tres honeypots vas a la lista.
Por eso otra medida es limitar el número de correos por usuario/hora y dominio/hora.
En el momento que te revientan van a rebasar el límite y te das cuenta en seguida.
Eeeeso, que no recordaba bien :).
Gracias.
Debes poner ambos en una balanza y quedarte con el que más beneficio de. Aunque claro, aquí entran en juego otros factores como crear reputación y confianza en el cliente. A la larga creo que con el Modo seguro se sale ganando.
Con respecto a los bloqueos son una putada pero a veces no queda mas remedio, nosotros tuvimos en alojamiento un server con administración externa que al final tuvimos que "meterle mano" por que lo habían convertido en un sistema zombie, todo y cada uno de los servicios que ofrecía estaba con algo malicioso, el servidor web concientos de enlace phishing, el correo con todas las cuentas "pirateadas" incluso se habían creado propias para enviar spam y al tenerlo incluido dentro de nuestro rango de IP, estuvimos casi una semana con todos lo servicios bloqueados.
Con el correo hace años que filtramos por IP e incluso con servicios intermedios, si en un día se pierden 2 correos "validos" es por que al menos se han filtrado 2000 de spam.
Lo que hay que hacer es un estándar publicitario que no sea invasivo, respetar las reglas, que google,bing y demás buscadores puntúen de forma mas negativa este tipo de publicidad(no se admita ni en SEM). Y que al contrarío incentive la publicidad "correcta" y adblock(u otros sistemas) antes de bloquear dicha publicidad lo indique.
Estamos como al principio del posicionamiento cuando la gente metía en noscript o en enlaces del mismos color criterios de búsqueda a casco porro y los buscadores se lo tragaban, lo que hay que regular es la publicidad y establecer un mecanismo de buenas formas a nivel internacional.
Al final acabas bloqueando por Ip, usando listas negras y bloqueando países enteros si hace falta.
En una empresa pequeña el tiempo que se va microtuneando los sistemas de seguridad para luchar contra los putos spamers es trabajo no productivo y que te arruina el trabajo productivo.
Al final pones la balanza y te sale bloquear Tor (aunque nosotros solo bloqueamos Tor a nivel web) y con listas negras.
Obviamente un ISP generalista haria otras cosas, pero como a los comentarios que contestas, según el perfil de nuestros clientes es lo que demandan. Ninguno de sus clientes les va a enviar un correo ni va a ver sus páginas web desde Tor
Es que me huelo que esto es el tipico problema-> reaccion-> solucion al que nos tienen acostumbrados los medios de los gobiernos. Tu quieres conseguir legitimacion para eliminar Tor, Bitcoin o invadir un pais, pues creas un problema donde estos temas sean los culpables luego la gente reaccionara para pedirte una solucion y claro tu solucion es cortar por lo sano y es lo que pretendias desde el principio. Yo pienso que la tecnologia al igual que un cuchillo se puede usar para bien o para mal y no por eso habria que bloquear o controlar la tecnologia sino eliminar los riesgos del mal uso de ella en el objetivo.
Un balance adecuado son los sistemas de reputación que dan un scoring automático del cliente basado en email, IP, dirección de entrega, etc, y retiene las compras antes de servirlas para puntuaciones muy bajas. Ahí el vendedor puede decidir si pedir alguna verificación adicional o arriesgarse y servir el pedido.
Puedes tener a un 1% de los clientes algo molestos, pero te quitas el grueso de fraude y no bloqueas a nadie.
El problema es que un sistema así requiere pagar un servicio adicional por parte del comerciante o un desarrollo que normalmente no se puede permitir.
Ojo. Que esto no es algo que haga un cliente de a pie. Proveer servicios en Internet requiere algo de competencia y recursos técnicos. Eso normalmente incluye tener servidores en un centro de datos con IP fija y no una Raspberry Pi debajo de la cama.
Con líneas de mas de 900 caracteres también puede haber problemas de líneas partidas, y el Prestahop, por ejemplo, puede generar emails con todo el mensaje en una línea.
Poner con DMARC que cualquier correo mal firmado sea rechazado puede hacer que pierdas correos legítimos por algún caso extremo o bug en los sistemas de correo.
Al final, cada cliente tiene unas necesidades diferentes y estando en medio no puedes poner sistemas ultra estrictos ni demasiado laxos y estás todo el dia bailando en la cuerda floja.
Incluso en su dia tuve que quitar la reescritura SRS de cabeceras, que permiten el reenvío de correos aun usando SPF, porque habia servidores que tachaban de spam simplemente porque el "envelope" no correspondía con el from.
Ser administrador de correo es un puto infierno. Habría web montar una asociación en plan A.A.
La neutralidad de la red en el mundo del correo, no sé si con la ayuda o la excusa del spam, no existe.
#22 Ahora ya está compensando pasar a modo seguro. En ese caso el perfil de cliente era personas mayores sin smartphones y con baja educación tecnológica. De hecho facilitaban la tarjeta de crédito por teléfono alegremente. Los estudios afirman que se pierde del orden de un 12% de ventas. Tambien hemos entrenado al personal para que aprenda a identificar patrones sospechosos de compra (cliente nuevo, pedido alto, algún error en el teléfono o teléfono inventado, etc.)
#63 Correcto. Solamente la carga de iptables con las 15.000 filas de IPs/rangos tarda casi quince minutos. Tenemos que optimizar mucho el script pero tenemos la ventaja de ser pequeños para clientes pequeños. Con poco nos apañamos y los servidores van suficientemente equipado de recursos con una configuración estándar.
#71 Hotmail es uno de los que se consideran forwarders y alteran la cabecera. Ta apoyo en lo de la asociación.
En este mismo meneo podrás encontrar comentarios que describen los distintos enfoques que se aplican sin hacer uso de ese tipo de bloqueos indiscriminados a operadores y a tecnologías.
El 90% del correo es SPAM, y por eso nadie duda que el correo es una herramienta absolutamente válida.
El riesgo de perder 4 correos lícitos compensa ante todos los contras que son muchos, de soportar una carga bestial de tráfico ílicito, que tienes que tratar y procesar, y encima no vas a poder eliminarlo, dando como consecuencia que para no perder esos 4 lícitos, vas a tener que tragar con 8 malos, soportando las quejas de muchos otros clientes, sumadas al de la gran carga que supone ese tratamiento de filtrado.
Al final, no compensa.
Es cierto, injusto, pero cierto.
Creo que es parte del mismo debate, y dudo que la respuesta esté en los extremos.
Aparte de eso... si solo fuera spam y trolls... una forma algo inocente de verlo.
No puedes elegir "para esta transacción seguro-para esta no seguro" e incluso alternar en función de la IP supondría tener que reprogramar tiendas online estandar (Prestashop, etc) y el cliente no va a pagar por ese cambio.
Por eso es una decisión compleja, porque si lo pones en modo seguro pierdes a bastantes de los abueletes.
Esta claro que ellos no van a usar Tor, ni una VPN. De hecho muchos ni siquiera usan la tienda online
Seguramente a corto plazo forcemos el cambio a modo seguro. Cada vez quedan menos abueletes.
Pero aún así, con eso te quitas el problema del fraude en tarjeta.
Los ataques a la web son otro frente importante que defender y esto es ajeno a la tienda y a sus clientes.
¿Donde está la lista negra?
Hay muchas.
Generalmente son empresas dedicadas a la seguridad que disponen de equipos en internet simulando ser servidores normales y dejando que se les ataque. Con esto se aprende que estrategias de ataque hay, de donde vienen, etc.
Las fundamentales son
Spamhaus www.spamhaus.org/sbl/
Spamcop www.spamcop.net/
Barracuda www.barracudacentral.org/rbl
pero hay cientos.
El tema es que si apareces en alguno de estos tres acabas no pudiendo enviar correo a nadie que use estas listas para comprobar si eres un spammer o no.
Sin embargo lo que se bloquea habitualmente no es el dominio (google.com, meneame.net) sino las IP desde la que te llega la conexión (8.8.8.8 etc)
Hay herramientas muy útiles para verificar si una IP está en una lista negra.
La que usamos a veces es esta mxtoolbox.com/blacklists.aspx
Metes la IP y te dice quien le tiene bloqueado y por qué.
Por ejemplo, una de las listadas: mxtoolbox.com/SuperTool.aspx?action=blacklist:98.218.179.67&run=to
En la configuración del servidor de correo le dices que, antes de aceptar un correo, mire en estas listas si la IP del servidor remitente esta en esas listas. Si lo esta chapas la conexión si más miramientos. Si no lo está lo pasas al analizador de SPAM.
¿Como se saca un dominio?
Habitualmente no puedes o no es fácil.
Si estas en la lista es porque envias spam o ataques. Eso es muy indicativo de que el servidor ha sido reventado y lo tienes lleno de spamers que se han colado y lo están usando. Lo primero es detectar la intrusión, ver que han hecho, corregirlo y despues ponerte en contacto con quien te haya listado para informarle.
No esperes que lo hagan. Muchas veces es esperar a que expire el plazo de bloqueo (a veces horas, otras días). Mientras tanto esa IP está condenada.
Hay algunos como HOTMAIL que nos han tenido bloqueada una IP meses. Sonmuy intransigentes con sus bloqueos.
Tambien hay servicios que te ayudan mucho. Teníamos un servicio mal configurado que generaba un falso positivo. Nos pusimos en contacto con Spamhaus y nos indicaron, tras acreditarnos adecuadamente, donde estaba el problema que hacía que saltara el bloqueo.
Por eso siempre tenemos dos IP por cada server, la sucia y la limpia. La sucia es la que usa el server y la limpia no se usa para nada. Si la sucia cae en una lista, corregimos la intrusión o el problema y cambiamos a la IP limpia.
La neutralidad en la Red no tiene nada que ver con esto.
El problema de las IP dinámicas viene por la escasez de direcciones IP en IPv4. Es un recurso escaso, no hay para todos y por eso es caro en las líneas para consumidor final.
Esas listas alimentan IPTables con lo que si una IP está en cualquiera de esas listas, la cargamos en IPTables. Cualquier conexión desde esas IPs las rechazamos, sean del tipo que sean, Web, SMTP, POP, etc. No hacemos prisioneros. Esto lo implementamos mediante scripts personalizados y Crontab.
A IPTables, en otras cadenas, también van aquellas IPs que cometen más de cinco intentos fallidos de login gracias a Fail2Ban. Aquí leemos los logs de diversos servicios y entre ellos los de los CMS que dejen logs y los de Apache/NGInx.
Eso suele detener decentemente los ataques por fuerza bruta.
En Apache tenemos habilitado MOD_Security (www.modsecurity.org/) y usamos unas reglas básicas que detectan, a partir de la petición, si se está intentando una inyección SQL, un XSS, etc. En la configuración puedes indicar que reglas de control quieres cargar. Las hay gratuitas y de pago (www.modsecurity.org/rules.html)
Esta parte se puede hacer de forma sencilla desde Plesk (v12 o superior), imagino que desde CPanel e ISPCOnfig se podrá hacer igual. No usamos eso paneles de control.
A eso le añadimos algún plugin de seguridad. En el caso de Joomla usamos AdminExile. Este hace que el acceso a la parte administrativa sea diferente y dependa de algo más que de una simple URL(dominio.com/administrator). Además lleva su propio sistema de blacklisting por intentos repetidos.
Lo cierto que en Web quizás no somos demasiado pulcros y tengamos algún que otro punto ciego. Pero desde que cargamos las IPS en IPTAbles nos ha reducido casi por completo la carga por Fail2Ban.
Eso si, la cadena más larga de IPTables tiene 15240 líneas. Cada una de ellas es o una IP o una subred entera.
No es la configuración más optima, posiblemente ni la recomendada, para hosts con mucho tráfico por la sobrecarga y lentitud de recorrido de IPTables.
Aquí lo suyo, por eficiencia y rendimiento sería utilizar IPSET (ipset.netfilter.org/features.html) que es mucho más eficiente en las búsquedas pero tenemos el problema de que al ser un VPS no podemos implementarlo ya que depende del kernel y casca. Nos pasa lo mismo con el NTP.
Si tuviéramos un host físico estaba implementado desde el primer día.
Vamos a empezar a valorar servicios como Cloudflare y otros CDN similares por seguridad y por velocidad.
conclusión: El cliente se queja de que no llegan los correos, y tienes que abrir y permitirlo todo.