OVH Community, your new community space.

Problema critico de Spam


oceano
06/04/2013, 11:20
Hola, buenos días !

Estoy siguiendo con especial interés éste hilo. De momento no he tenido problemas de SPAM, pero aquí no hay nada firmado, igual una mañana te despiertas y tienes la cola llena.

He visto que estáis bastante puestos en el tema, se anima alguien a realizar un HOW-TO si tiene tiempo y ánimos ?

Muchas gracias !!

Un saludo !

Guille
06/04/2013, 09:38
Cita Publicado inicialmente por max
Ah, y ya no dejo gestionar las reglas de SpamAssasin a los usarios.
Yo controlo personalmente el entrenamiento bayesiano del spamassasin.
Tengo una cuenta de correo trampa que recibe el spam y una carpeta en el servidor donde envio todos los correos spam para entrenamiento, y otra para aprender los falsos positivos.
Al cabo de unos meses funciona de maravilla.
Todos los correos etiquetados con X-Spam pasan a una carpeta del servidor IMAP (o no, según quiera el usuario).
Eso combinado con postgrey y unas cuantas RBL.

max
06/04/2013, 01:15
Cita Publicado inicialmente por Ros
Buenos días !!

Alguna recomendación ?
borrar las Bayes de SpamAssasin de todas la cuentas para que se regeneren. A mi me pasó algo parecido y probé usar varias listas diferentes (que luego varias daban problemas) y MailScanner. Hasta que me dio por cargarme las bayes de todas la cuentas y se acabó. Desde entonces sólo con CSf + Spamhaus y SORBS ya va bien y sin nada más.

Si no lo has hecho pruebalo.

Ah, y ya no dejo gestionar las reglas de SpamAssasin a los usarios.

saludos,

jaumas
05/04/2013, 10:47
Cita Publicado inicialmente por Ros

Alguna recomendación ?

Saludos !
Frontales de correo que se comen todo el SPAM y reenvian correo limpio a cada máquina. Con Postfix, Greylist, SpamAssin y Clamav.

La máquina final solo puede recibir correo de las máquinas frontales y la máquina final envía los correos a los frontales para que distribuyan correo.....

Da igual usar Cpanel, Plesk o VIrtualmin....

jaime

bz2
05/04/2013, 09:17
Lo mejor como comentan por aquí es hacer una estrategia a varios niveles, no te limites a implementar una sola política:

- Lo primero de todo, una buena configuración de el servidor
- Greylisting
- Filtros bayesianos (spamassassin, ASSP, DSPAM...)
- RBLs (pero ojo, escoje las más usadas y que tengan más reputación)
- Comprobación de SPF y DKIM

Etc, etc

Kilburn
05/04/2013, 09:13
Cita Publicado inicialmente por jack2
Lo primero es habilitar el greylisting, disminuye inmediatamente los spam que reciben tus usuarios, lo segundo es establecer una efectivas RBL y finalizando spamassassin
Si te refieres al orden en el que *implementar* estos servicios en tu sistema, estoy de acuerdo. Pero si te refieres al orden en que se hagan las comprobaciones una vez tengas todo implementado, difiero. Me explico: los controles "RBL" es mejor hacerlos antes del greylisting, porque de otro modo la base de datos del greylisting se llena de mierda con tripletas (helo, from, to) que luego vas a rechazar igualmente con el RBL.

Así para aclarar, yo os recomiendo encarecidamente el uso de algo tipo policyd-weight en vez de RBLs directamente. La única diferencia es que el primero realiza un puntaje a partir de múltiples listas y comprobaciones sobre IP, rango, helo, etc (todo cosas que implican muy poca carga para el server). Luego se toma la decisión en base al puntaje, de modo que un solo "fallo" (aparecer en una blacklist por ejemplo) no descalifica automáticamente al emisor. Si usas RBLs directamente eres mucho mas propenso a rechazar servidores que por algún motivo puntual han caído en una blacklist en concreto.

Pues parece una buena combinación para frenar el SPAM, seguramente nos tocará hacer algo así, lo que tengo que buscar de tal manera de que integrarlo en más de 20 Servidores con Cpanel no me sea un año de trabajo.

Creéis que montar un par de servidores de correo Externos y conectarlos al Cpanel puede ser buena idea ?
Totalmente. Y si es en dos proveedores distintos mucho mejor (a veces hay bloqueos extraños entre redes, así que teniendo dos entradas por proveedores distintos te ahorras lidiar con eso).

La implementación no es trivial. No sé cómo lo tiene montado mirill, pero yo (que estoy desviado hacia postfix) lo iría montando de la siguiente forma:

1. Implementación inicial de postfix en un servidor frontend:
1.1 Necesitas una forma de consultar *todos* tus dominios en backend, así como a qué servidor hay que entregar cada uno. Esto lo tienes que hacer por cojones, y debería sincronizarse automáticamente cuando cambie algo en los servidores cpanel. Se vale desde un cron guarro que corra cada 5 minutos hasta usar los hooks de cpanel para controlarlo. Usar ese mapa (dominio -> servidor interno) mediante las variables "relay_domain" y "relay_transport" de postfix.
1.2 Necesitas una forma de verificar qué direcciones son correctas y cuales no. Para empezar, no me rompería la cabeza y activaría la address verification que incluye postfix. Con esto postfix comprobará las direcciones simulando un envío contra el servidor final donde está el dominio, pero sin entregar nada. Los resultados se cachean.
1.3 Probar que funciona correctamente hasta aquí. Primero manualmente (telnet y metiendo un mail apelo) y luego cambiando el MX de un dominio poco importante o de pruebas que tengas.

2. Implementación de postgrey. Es realmente sencillo y no necessita personalización alguna ni conocer nada de los servidores backend. La única pega es que los primeros envíos de (servidor, from, to) tardaran unos 5-10 minutillos en llegar. A partir de ahí la tripleta queda cacheada y los siguientes envíos llegan instantaneos.

3. Implementación de policiyd-weight. Tampoco necesitas saber nada concreto de los servidores backend. Aunque las comprobaciones las hará *antes* del greylisting, digo de implementarlo después porque tiene un pequeño problema: vas a tener que mantener una whitelist. Me explico, hay unos cuantos admins inútiles por el mundo. Algún día, policyd-weight (o cualquier otro software que rechace por malformaciones de helo, checkeo de RBLs y demás) rechazará un correo porque el servidor remitente está mal configurado. Pero tu cliente querrá ese correo, y te llamará y se quejará de que no recibe de X persona. Puedes responder que el remitente tiene el servidor de correo mal configurado, pero el administrador inútil del remitente responderá que a otra gente si le llegan sus correos. Total, que al final o les metes en whitelist o perderás un montón de tiempo y esfuerzo convenciendo a tu cliente, al remitente, y al admin del remitente que el problema es que ellos tienen el server mal configurado.

4. Implementación de amavisd-new (que incorpora spamassassin). Esto lo dejo para el final porque es lo más peliagudo de todo.
4.1 Primero, te recomiendo que implementes *before queue* filtering (en postfix, que lo configures como smtpd_proxy_filter en vez de content_filter). De este modo, postfix no acepta ni rechaza el correo hasta que amavis da el OK (o REJECT). Esto es muy importante porque de otro modo, cuando el antispam rechaza un correo, deberías rebotarlo para que el remitente sepa que no ha llegado, o guardarlo en una cuarentena donde el cliente pueda descubrirlo. El problema es que la mayoría de spams son de remitentes inválidos y/o falsos, así que la mayoría de veces rebotarías correos a gente que no los ha enviado. Eso se conoce como "backscatter", y haría que tu servidor perdiera reputación rápidamente. Por otro lado, la solución de la cuarentena no es muy buena tampoco, porque es complicado darles acceso a los clientes. Teniendo amavis en modo *before queue*, simplemente puedes rechazar los correos spam y es al servidor remoto a quien le toca notificar a su usuario de lo que ha pasado, quitándote tu el marrón de encima.
4.2 Amavis también necesita conocer la lista de dominios internos, puesto que sólo añade cabeceras y puntúa diferente cuando los mails son "entrantes" a tus sistemas que cuando son "salientes" (porque el antispam se puede usar para correos salientes también, aunque tu no lo hagas). Esto se especifica con "local_domains_maps".
4.3 Finalmente, queda el tema del filtro bayesiano, que es la parte más conocida de cualquier sistema antispam. El problema es que hay que entrenarlo. Idealmente debes preparar alguna forma para que los usuarios puedan entrenarlo (marcando como spam correos que les han entrado y viceversa). Realiza un poco de investigación sobre las posibilidades, pero ya te digo desde ahora que ninguna es sencilla y da para un post entero.

Ale, aquí está mi mini-guía para montaje de un servidor frontend filtrador de spam. Esto no es para nada completo, pero indica los pasos mínimos para tener un sistema funcional de este tipo. Si hay palabros extraños que no conocéis, buscadlos en google porque se refieren a algo que debéis conocer si os metéis en este tinglado.

Si no estáis de acuerdo en algo o tenéis dudas sobre el por qué de alguna cosa, comentadlo y lo hablamos

jack2
04/04/2013, 02:46
Lo primero es habilitar el greylisting, disminuye inmediatamente los spam que reciben tus usuarios, lo segundo es establecer una efectivas RBL y finalizando spamassassin

mirill
03/04/2013, 21:51
Hola,

Nosotros lo tenemos montado parecido. Dos servidores hacen de sufridores de SPAM y el correo limpio lo entregan a los servidores legítimos de Cpanel. Si no lo haciamos así al final los Cpanel se morían entre las visitas a la web, wembails y accesos de correo y el propio envío de correo.

Los servidores los tenemos hechos a mano con qmail y cada correo pasa bastantes tests antes de ser entregado: control de rate, RBL, greylisting y malformación de cabeceras.

Además para mejorar el rendimiento los directorios temporales de los sistemas de correo (antispam, antivirus, etc...) están en RAM para que no consuman disco.

Una opción interesante si no quieres currártelo a mano es MailCleaner (ya se ha hablado por aquí) que tiene todas las opciones e incluso permite montarlo en clúster.

Ros
03/04/2013, 11:06
Cita Publicado inicialmente por Kilburn
Buenas Ros,

Yo uso postfix (en vez de exim como cpanel) así que igual no te sirve den de mucho mis aportaciones. De todos modos lo dejo aquí por si le sirve a alguien.

Nosotros controlamos el spam entrante con una combinación de 3 sistemas:

1. policyd-weight se encarga de rechazar envíos desde IPs dinámicas, con HELO's fabricados y/o de IPs en blacklists.

2. Una vez pasados los tests de policyd-weight, aplicamos greylisting a los correos entrantes con postgrey.

3. Finalmente, amavisd-new se encarga de inspeccionar el contenido (con spamassassin y su filtro bayes, que vamos entrenando), verificar las firmas dkim y el SPF, etc..
Pues parece una buena combinación para frenar el SPAM, seguramente nos tocará hacer algo así, lo que tengo que buscar de tal manera de que integrarlo en más de 20 Servidores con Cpanel no me sea un año de trabajo.

Creéis que montar un par de servidores de correo Externos y conectarlos al Cpanel puede ser buena idea ?

Gracias !

Kilburn
03/04/2013, 00:49
Buenas Ros,

Yo uso postfix (en vez de exim como cpanel) así que igual no te sirve den de mucho mis aportaciones. De todos modos lo dejo aquí por si le sirve a alguien.

Nosotros controlamos el spam entrante con una combinación de 3 sistemas:

1. policyd-weight se encarga de rechazar envíos desde IPs dinámicas, con HELO's fabricados y/o de IPs en blacklists.

2. Una vez pasados los tests de policyd-weight, aplicamos greylisting a los correos entrantes con postgrey.

3. Finalmente, amavisd-new se encarga de inspeccionar el contenido (con spamassassin y su filtro bayes, que vamos entrenando), verificar las firmas dkim y el SPF, etc..

Ros
02/04/2013, 23:04
Buenos días !!

Ya hace tiempo que no escribo en este foro, pero siempre ha sido de referencia para mi y me paso una vez mas para un problema que tengo con el SPAM.

Tengo varios servidores que me los están avasallando a SPAM, todos son de hosting compartido con Cpanel y realmente no encontramos la solución para parar este spam a lo bestia de Chinos, rusos, ingleses... uff es insufrible.

Todos los que tenéis servidores con Cpanel o vendéis hosting compartido como solucionáis este problema ? He probado ASSP pero al final el script para Cpanel te cobran un pastón y falla más el correo que una escopeta, no te entra SPAM, pero tampoco te entra ni un correo porque el EXIM pasa mas tiempo caído que arriba...

Alguna recomendación ?

Saludos !