Hola, Sigo con el Spamassassin, ahora ya mucho más depurado y funcionando muy bien (filtra una media de correos diarios de 325, con menos de un 2% de falsos positivos). Pero me gustaría darle una vuelta de tuerca más. Tengo algunos dominios (del tipo wanadoo.es, terra.es, etc.) en la lista blanca: whitelist_from *@terra.es whitelist_from *@wanadoo.es (...) Para evitar que se "falseen" estas direcciones (como hacen los virus) y hacer que no pasen por direcciones "buenas" y reciban una puntuación de -100, he visto la opción de "whitelist_from_rcvd" pero no sé cómo se configura correctamente. Ahora lo tengo así: whitelist_from_rcvd *@terra.es terra.es whitelist_from_rcvd *@wanadoo.es wanadoo.es (...) Pero no funciona. Me bajo el correo con Fetchmail, que lo pasa a Postfix y éste al SA que lo filtra. El ISP es Arrakis y las DNS son de Arrakis también. Bien. Entonces ¿qué hay que poner para que una dirección que contenga un "From" falseado de terra.es (por ejemplo) no obtenga una puntuación de -100? Es que he visto que hablan también del parámetro "trusted_networks" en SA y ahí ya me he liado. ¿Qué dirección(es) hay que poner en formato numérico? ¿Las de Arrakis, las entradas MX de los dominios de Terra y Wanadoo, o...cuál? ¿Hay que decirle, además, que haga "dns_checks"? Aunque recibo poca cantidad de este tipo de correos, quiero dejar al asesino "afinado" antes de ponerlo en marcha para otros usuarios. Saludos, -- Camaleón
El 2004-10-15 a las 11:52 +0200, Camaleón escribió:
Pero me gustaría darle una vuelta de tuerca más. Tengo algunos dominios (del tipo wanadoo.es, terra.es, etc.) en la lista blanca:
whitelist_from *@terra.es whitelist_from *@wanadoo.es (...)
Para evitar que se "falseen" estas direcciones (como hacen los virus) y hacer que no pasen por direcciones "buenas" y reciban una puntuación de -100, he
Ahh... claro, whitelist no funciona ahora tan bien, se falsifican rutinariamente los correos. Puedes eliminar previamente los virus, usando amavis_new, por ejemplo. Puedes también inventar una regla que le de algunos puntos negativos a esas direcciones, en vez de 100. Sabes que puedes definir reglas locales para el SA.
visto la opción de "whitelist_from_rcvd" pero no sé cómo se configura correctamente. Ahora lo tengo así:
whitelist_from_rcvd *@terra.es terra.es whitelist_from_rcvd *@wanadoo.es wanadoo.es (...)
Ni yo...
Pero no funciona. Me bajo el correo con Fetchmail, que lo pasa a Postfix y éste al SA que lo filtra. El ISP es Arrakis y las DNS son de Arrakis también.
Bien. Entonces ¿qué hay que poner para que una dirección que contenga un "From" falseado de terra.es (por ejemplo) no obtenga una puntuación de -100?
Muy buena pregunta. Se puede inventar una regla que detecte si ha sido enviado por el servidor de terra - el SA tiene reglas para el yahoo, por ejemplo. Ahora, date cuenta que gente como yo envia con el from de terra, pe, pero sin usar para nada a terra, por lo que esa regla te diría que mi from es falso. Habría que ver como hace el SA para detectar los falsos yahoo, e imitarlo con terra.
Es que he visto que hablan también del parámetro "trusted_networks" en SA y ahí ya me he liado. ¿Qué dirección(es) hay que poner en formato numérico? ¿Las de Arrakis, las entradas MX de los dominios de Terra y Wanadoo, o...cuál? ¿Hay que decirle, además, que haga "dns_checks"?
Los dns detectan muchas spams, es cierto, y al menos usándolos dentro del SA es más justo que usarlo en el psotfix (si lo activas en el postfix, gente como yo los bloqueas).
Aunque recibo poca cantidad de este tipo de correos, quiero dejar al asesino "afinado" antes de ponerlo en marcha para otros usuarios.
Mmmm. Ten en cuenta que en cuanto el SA tiene un tiempo, empiezan a colarse algunos más que antes, y hay que actualizarlo. -- Saludos Carlos Robinson
Carlos E. R. wrote:
Puedes eliminar previamente los virus, usando amavis_new, por ejemplo.
¿Qué tiene el amavis-new que todo el mundo lo utiliza? :) No tengo nada en contra de él, pero siempre me ha gustado utilizar la menor cantidad de programas posibles, así los errores son más sencillos de detectar (al final no sabes si el que falla es el filtro de amavis, postfix o SA).
Puedes también inventar una regla que le de algunos puntos negativos a esas direcciones, en vez de 100. Sabes que puedes definir reglas locales para el SA.
Muy complicado. :-)
Se puede inventar una regla que detecte si ha sido enviado por el servidor de terra - el SA tiene reglas para el yahoo, por ejemplo. Ahora, date cuenta que gente como yo envia con el from de terra, pe, pero sin usar para nada a terra, por lo que esa regla te diría que mi from es falso.
Habría que ver como hace el SA para detectar los falsos yahoo, e imitarlo con terra.
Carlos, SA lo puede hacer sin necesidad de reglas. Simplemente configurando los parámetros de "whitelist_from_rcvd" junto con "trusted_networks". Pero es que no sé qué valores poner en "trusted_networks"...
Los dns detectan muchas spams, es cierto, y al menos usándolos dentro del SA es más justo que usarlo en el psotfix (si lo activas en el postfix, gente como yo los bloqueas).
No creo que los tiros vayan por ahí. Entiendo (según la documentación de SA) que para que SA pueda identificar que un correo ha salido del servidor del que dice pertenecer, tiene que verificar (utilizando la resolución de nombres de los registros MX) que efectivamente es así. Por ejemplo, recibo muchos correos con virus (.zip) que dicen que son de "usuario@terra.es" pero si analizas las cabeceras del correo ves que ha salido de una IP de ADSL de Telefónica. Vamos, que de Terra nada. Si yo tengo en "whitelist_from_rcvd" configuradas las direcciones de *@terra.es solamente, ese correo me pasa como bueno (-50 bayes), pero si se tuviera bien configurada, además, la opción de "trusted_networks", SA se daría cuenta de que ese correo no puede ser bueno porque la cabecera está falseada, y no proviene de Terra, por lo que le afectaría la puntuación normalizada. No creo que esta opción tenga relación alguna con el bloqueo de IP en listas negras, o de rangos de direcciones, eso es otro tema, que por supuesto, no pienso activarlo. Lo que pretendo es que a las direcciones que están en la lista blanca provengan de los servidores de correo a los que pertenecen. En caso contrario, que se les aplique las reglas bayesianas convenientes.
Mmmm. Ten en cuenta que en cuanto el SA tiene un tiempo, empiezan a colarse algunos más que antes, y hay que actualizarlo.
No hay problema. Puede ser entrenado cada x tiempo. :) Saludos, -- Camaleón
El 2004-10-16 a las 10:18 +0200, Camaleón escribió:
Carlos E. R. wrote:
Puedes eliminar previamente los virus, usando amavis_new, por ejemplo.
¿Qué tiene el amavis-new que todo el mundo lo utiliza?
:)
Que es nuevo :-p No, simplemente que es lo que el suse 9.1 trae "de fábrica". Combina la funcionalidad del amavis (detección de virus) y del SA. Se llama desde el propio postfix (o sendmail). Rechaza cualquier correo que contenga ejectuables, aunque vengan dentro de un fichero zip. Ya con eso, no hace falta detectar virus, puesto que los virus por narices son ejecutables. Sin embargo, se puede habilitar la detección de virus (más tiempo de proceso). Y además, también mira el spam - pero como lo hace globalmente, los filtros bayesianos no pueden funcionar tan bien. La ventaja es que al juntar las dos cosas, SA y amavis, el proceso es más rápido, es una unica sesion perl, imagino. Sin embargo, yo le tengo deshabilitada la parte de SA, para dispararla como usuario y afinar el filtro bayesiano (soy yo sólo en ésta máquina). Bueno, y cuando hagan el SA 3, que no se si ha salido ya, todavía irá más rápido. Desventaja (y gorda): que el amavis-new no trae documentación de usuario. Si, vale, el fichero de configuración está ampliamente comentado. No me vale, eso es totalmente comprensible sólo por programadores. No hay documentación con ejemplos y motivaciones de hacer una cosa u otra.
No tengo nada en contra de él, pero siempre me ha gustado utilizar la menor cantidad de programas posibles, así los errores son más sencillos de detectar (al final no sabes si el que falla es el filtro de amavis, postfix o SA).
No es tan complicado. Y o bien amavis o amavis-new hay que ponerlo, para quitar virus: y el amavis-new es muy eficaz en eso. El yast (en 9.1) te inserta el amavis bastante bien, y por defecto es como un tamiz muy tupido, quizás demasiado.
Puedes también inventar una regla que le de algunos puntos negativos a esas direcciones, en vez de 100. Sabes que puedes definir reglas locales para el SA.
Muy complicado. :-)
Yo tengo alguna, para quitar algunos que se me colaban.
Se puede inventar una regla que detecte si ha sido enviado por el servidor de terra - el SA tiene reglas para el yahoo, por ejemplo. Ahora, date cuenta que gente como yo envia con el from de terra, pe, pero sin usar para nada a terra, por lo que esa regla te diría que mi from es falso.
Habría que ver como hace el SA para detectar los falsos yahoo, e imitarlo con terra.
Carlos, SA lo puede hacer sin necesidad de reglas. Simplemente configurando los parámetros de "whitelist_from_rcvd" junto con "trusted_networks". Pero es que no sé qué valores poner en "trusted_networks"...
No se que hacen esos parámetros, así que no opino de momento. [...] Mail::SpamAssassin::Conf(3) whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS. This string is matched against the reverse DNS lookup used dur ing the handover from the untrusted internet to your trusted network's mail exchangers. It can either be the full hostname, or the domain component of that hostname. In other words, if the host that connected to your MX had an IP address that mapped to 'sendinghost.spamassassin.org', you should specify "sendinghost.spamassassin.org" or just "spamassassin.org" here. Note that this requires that "trusted_networks" be correct. For simple cases, it will be, but for a complex network, or if you're running with DNS checks off or with "-L", you may get better results by setting that parameter. e.g. whitelist_from_rcvd joe@example.com example.com whitelist_from_rcvd *@axkit.org sergeant.org Mmm. La primera entrada es el "From", y la segunda debe encajar con el DNS inverso del relay, el que figura en el received del intercambio entre tu red (confiable) e internet (no confiable). Eso exige que trusted_networks esté bien puesto. trusted_networks ip.add.re.ss[/mask] ... (default: none) What networks or hosts are 'trusted' in your setup. Trusted in this case means that relay hosts on these networks are considered to not be potentially operated by spammers, open relays, or open proxies. DNS blacklist checks will never query for hosts on these networks. If a "/mask" is specified, it's considered a CIDR-style 'netmask', specified in bits. If it is not specified, but less than 4 octets are specified with a trailing dot, that's considered a mask to allow all addresses in the remaining octets. If a mask is not specified, and there is not trailing dot, then just the single IP address specified is used, as if the mask was "/32". Examples: trusted_networks 192.168/16 127/8 # all in 192.168.*.* trusted_networks 212.17.35.15 # just that host trusted_networks 127. # all in 127.*.*.* This operates additively, so a "trusted_networks" line after another one will result in all those networks becoming trusted. To clear out the existing entries, use "clear_trusted_networks". If you're running with DNS checks enabled, SpamAssassin includes code to infer your trusted networks on the fly, so this may not be necessary. (Thanks to Scott Banister and Andrew Flury for the inspiration for this algorithm.) This inference works as follows: o if the 'from' IP address is on the same /16 network as the top Received line's 'by' host, it's trusted o if the address of the 'from' host is in a reserved network range, then it's trusted o if any addresses of the 'by' host is in a reserved network range, then it's trusted O sea, que aquí debes poner por lo menos tu propia red privada, y creo que la IP de tu puerta a internet, la de la maquina que corre el servidor de correo externo. Vale. Pues yo lo que te decía es que ésta prueba dará falso, por ejemplo, para cualquier correo privado que yo te pudiera mandar, por ejemplo, porque como yo envio con mi propio postfix, y nunca uso el relay de mi proveedor, la resolución inversa del recieved que te llegue en modo alguno será la de mi from. Y tampoco lo va a ser para aquellos que tengan varias direcciones, y la envien a traves de un relay con autentificación, porque en ese caso el from no es el del servidor que te envia. Puede suceder que en algunos casos de y en otros no, para la misma persona, si anda con un portatil, pe. No lo veo claro. Además, como le da una puntuación de -100, no hay opción a que otras reglas trabajen, se convierte en la única regla.
Los dns detectan muchas spams, es cierto, y al menos usándolos dentro del SA es más justo que usarlo en el psotfix (si lo activas en el postfix, gente como yo los bloqueas).
No creo que los tiros vayan por ahí. Entiendo (según la documentación de SA) que para que SA pueda identificar que un correo ha salido del servidor del que dice pertenecer, tiene que verificar (utilizando la resolución de nombres de los registros MX) que efectivamente es así. Por ejemplo, recibo muchos correos con virus (.zip) que dicen que son de "usuario@terra.es" pero si analizas las cabeceras del correo ves que ha salido de una IP de ADSL de Telefónica. Vamos, que de Terra nada.
Claro, pero eso es lo que te digo que pasaría con cualquier correo mio. Aunque arriba diga tiscali, no he usado el smtp de tiscali, y en realidad la IP es de teleline, alias terra. Si lo que te preocupa son los zips, pon el amavis-new, y te los quita todos. Sólo entran los de datos, o con password.
Si yo tengo en "whitelist_from_rcvd" configuradas las direcciones de *@terra.es solamente, ese correo me pasa como bueno (-50 bayes), pero si se tuviera bien configurada, además, la opción de "trusted_networks", SA se daría cuenta de que ese correo no puede ser bueno porque la cabecera está falseada, y no proviene de Terra, por lo que le afectaría la puntuación normalizada.
No creo que esta opción tenga relación alguna con el bloqueo de IP en listas negras, o de rangos de direcciones, eso es otro tema, que por supuesto, no pienso activarlo.
Es que hay dos maneras de usar las listas negras. Si lo usas en el postfix, es que no llegan a enviarte el correo, el postfix les deniega la conexión. En ese caso, todos los que usemos linux en casa con postfix/sendmail tenemos altas posibilidades de no entrar. La otra manera es que sea el SA quien lo verifique. En ese caso, el correo entero ya está en tu sistema cuando se analiza, por lo que el SA le pasa toda la batería de pruebas de la que dispone, y el RBL es simplemente una prueba más.
Lo que pretendo es que a las direcciones que están en la lista blanca provengan de los servidores de correo a los que pertenecen. En caso contrario, que se les aplique las reglas bayesianas convenientes.
Ah. Mmm. ¿Seguro que se les aplican el resto de reglas? Si es así... Mmm, puede estar bien... :-???
Mmmm. Ten en cuenta que en cuanto el SA tiene un tiempo, empiezan a colarse algunos más que antes, y hay que actualizarlo.
No hay problema. Puede ser entrenado cada x tiempo.
:)
Efestivamente :-) -- Saludos Carlos Robinson
y como le digo al amavis-new, que tengo instalado y andando conel postfix en
mi suse 9.1 que me rechace el spam?
lo pregunto porque diariamente me llegan un monton.
como puedo configurar el amavis-new tambien para eso?
me puedes(podeis) ayudar?
gracias
----- Original Message -----
From: "Carlos E. R."
El 2004-10-16 a las 10:18 +0200, Camaleón escribió:
Carlos E. R. wrote:
Puedes eliminar previamente los virus, usando amavis_new, por ejemplo.
¿Qué tiene el amavis-new que todo el mundo lo utiliza?
:)
Que es nuevo :-p
No, simplemente que es lo que el suse 9.1 trae "de fábrica". Combina la funcionalidad del amavis (detección de virus) y del SA. Se llama desde el propio postfix (o sendmail). Rechaza cualquier correo que contenga ejectuables, aunque vengan dentro de un fichero zip. Ya con eso, no hace falta detectar virus, puesto que los virus por narices son ejecutables. Sin embargo, se puede habilitar la detección de virus (más tiempo de proceso). Y además, también mira el spam - pero como lo hace globalmente, los filtros bayesianos no pueden funcionar tan bien.
La ventaja es que al juntar las dos cosas, SA y amavis, el proceso es más rápido, es una unica sesion perl, imagino.
Sin embargo, yo le tengo deshabilitada la parte de SA, para dispararla como usuario y afinar el filtro bayesiano (soy yo sólo en ésta máquina).
Bueno, y cuando hagan el SA 3, que no se si ha salido ya, todavía irá más rápido.
Desventaja (y gorda): que el amavis-new no trae documentación de usuario. Si, vale, el fichero de configuración está ampliamente comentado. No me vale, eso es totalmente comprensible sólo por programadores. No hay documentación con ejemplos y motivaciones de hacer una cosa u otra.
No tengo nada en contra de él, pero siempre me ha gustado utilizar la menor cantidad de programas posibles, así los errores son más sencillos de detectar (al final no sabes si el que falla es el filtro de amavis, postfix o SA).
No es tan complicado. Y o bien amavis o amavis-new hay que ponerlo, para quitar virus: y el amavis-new es muy eficaz en eso. El yast (en 9.1) te inserta el amavis bastante bien, y por defecto es como un tamiz muy tupido, quizás demasiado.
Puedes también inventar una regla que le de algunos puntos negativos a esas direcciones, en vez de 100. Sabes que puedes definir reglas locales para el SA.
Muy complicado. :-)
Yo tengo alguna, para quitar algunos que se me colaban.
Se puede inventar una regla que detecte si ha sido enviado por el servidor de terra - el SA tiene reglas para el yahoo, por ejemplo. Ahora, date cuenta que gente como yo envia con el from de terra, pe, pero sin usar para nada a terra, por lo que esa regla te diría que mi from es falso.
Habría que ver como hace el SA para detectar los falsos yahoo, e imitarlo con terra.
Carlos, SA lo puede hacer sin necesidad de reglas. Simplemente configurando los parámetros de "whitelist_from_rcvd" junto con "trusted_networks". Pero es que no sé qué valores poner en "trusted_networks"...
No se que hacen esos parámetros, así que no opino de momento.
[...]
Mail::SpamAssassin::Conf(3)
whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS.
This string is matched against the reverse DNS lookup used dur ing the handover from the untrusted internet to your trusted network's mail exchangers. It can either be the full hostname, or the domain component of that hostname. In other words, if the host that connected to your MX had an IP address that mapped to 'sendinghost.spamassassin.org', you should specify "sendinghost.spamassassin.org" or just "spamassassin.org" here.
Note that this requires that "trusted_networks" be correct. For simple cases, it will be, but for a complex network, or if you're running with DNS checks off or with "-L", you may get better results by setting that parameter.
e.g.
whitelist_from_rcvd joe@example.com example.com whitelist_from_rcvd *@axkit.org sergeant.org
Mmm. La primera entrada es el "From", y la segunda debe encajar con el DNS inverso del relay, el que figura en el received del intercambio entre tu red (confiable) e internet (no confiable). Eso exige que trusted_networks esté bien puesto.
trusted_networks ip.add.re.ss[/mask] ... (default: none) What networks or hosts are 'trusted' in your setup. Trusted in this case means that relay hosts on these networks are considered to not be potentially operated by spammers, open relays, or open proxies. DNS blacklist checks will never query for hosts on these networks.
If a "/mask" is specified, it's considered a CIDR-style 'netmask', specified in bits. If it is not specified, but less than 4 octets are specified with a trailing dot, that's considered a mask to allow all addresses in the remaining octets. If a mask is not specified, and there is not trailing dot, then just the single IP address specified is used, as if the mask was "/32".
Examples:
trusted_networks 192.168/16 127/8 # all in 192.168.*.* trusted_networks 212.17.35.15 # just that host trusted_networks 127. # all in 127.*.*.*
This operates additively, so a "trusted_networks" line after another one will result in all those networks becoming trusted. To clear out the existing entries, use "clear_trusted_networks".
If you're running with DNS checks enabled, SpamAssassin includes code to infer your trusted networks on the fly, so this may not be necessary. (Thanks to Scott Banister and Andrew Flury for the inspiration for this algorithm.) This inference works as follows:
o if the 'from' IP address is on the same /16 network as the top Received line's 'by' host, it's trusted
o if the address of the 'from' host is in a reserved network range, then it's trusted
o if any addresses of the 'by' host is in a reserved network range, then it's trusted
O sea, que aquí debes poner por lo menos tu propia red privada, y creo que la IP de tu puerta a internet, la de la maquina que corre el servidor de correo externo.
Vale.
Pues yo lo que te decía es que ésta prueba dará falso, por ejemplo, para cualquier correo privado que yo te pudiera mandar, por ejemplo, porque como yo envio con mi propio postfix, y nunca uso el relay de mi proveedor, la resolución inversa del recieved que te llegue en modo alguno será la de mi from.
Y tampoco lo va a ser para aquellos que tengan varias direcciones, y la envien a traves de un relay con autentificación, porque en ese caso el from no es el del servidor que te envia. Puede suceder que en algunos casos de y en otros no, para la misma persona, si anda con un portatil, pe.
No lo veo claro.
Además, como le da una puntuación de -100, no hay opción a que otras reglas trabajen, se convierte en la única regla.
Los dns detectan muchas spams, es cierto, y al menos usándolos dentro del SA es más justo que usarlo en el psotfix (si lo activas en el postfix, gente como yo los bloqueas).
No creo que los tiros vayan por ahí. Entiendo (según la documentación de SA) que para que SA pueda identificar que un correo ha salido del servidor del que dice pertenecer, tiene que verificar (utilizando la resolución de nombres de los registros MX) que efectivamente es así. Por ejemplo, recibo muchos correos con virus (.zip) que dicen que son de "usuario@terra.es" pero si analizas las cabeceras del correo ves que ha salido de una IP de ADSL de Telefónica. Vamos, que de Terra nada.
Claro, pero eso es lo que te digo que pasaría con cualquier correo mio. Aunque arriba diga tiscali, no he usado el smtp de tiscali, y en realidad la IP es de teleline, alias terra.
Si lo que te preocupa son los zips, pon el amavis-new, y te los quita todos. Sólo entran los de datos, o con password.
Si yo tengo en "whitelist_from_rcvd" configuradas las direcciones de *@terra.es solamente, ese correo me pasa como bueno (-50 bayes), pero si se tuviera bien configurada, además, la opción de "trusted_networks", SA se daría cuenta de que ese correo no puede ser bueno porque la cabecera está falseada, y no proviene de Terra, por lo que le afectaría la puntuación normalizada.
No creo que esta opción tenga relación alguna con el bloqueo de IP en listas negras, o de rangos de direcciones, eso es otro tema, que por supuesto, no pienso activarlo.
Es que hay dos maneras de usar las listas negras. Si lo usas en el postfix, es que no llegan a enviarte el correo, el postfix les deniega la conexión. En ese caso, todos los que usemos linux en casa con postfix/sendmail tenemos altas posibilidades de no entrar.
La otra manera es que sea el SA quien lo verifique. En ese caso, el correo entero ya está en tu sistema cuando se analiza, por lo que el SA le pasa toda la batería de pruebas de la que dispone, y el RBL es simplemente una prueba más.
Lo que pretendo es que a las direcciones que están en la lista blanca provengan de los servidores de correo a los que pertenecen. En caso contrario, que se les aplique las reglas bayesianas convenientes.
Ah. Mmm. ¿Seguro que se les aplican el resto de reglas? Si es así... Mmm, puede estar bien... :-???
Mmmm. Ten en cuenta que en cuanto el SA tiene un tiempo, empiezan a colarse algunos más que antes, y hay que actualizarlo.
No hay problema. Puede ser entrenado cada x tiempo.
:)
Efestivamente :-)
-- Saludos Carlos Robinson
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com
Carlos E. R. wrote:
Rechaza cualquier correo que contenga ejectuables, aunque vengan dentro de un fichero zip.
Pues si hace eso, creo me despiden... :-P Me parece un poco exagerado borrar un adjunto que contenga un .zip. ¿Qué pasará cuando los virus se puedan incrustar dentro de .pdf sencillo (sin macros ni javascript ni esas cosas)? ¿borraremos todos los .pdf? Es tentador, pero no puedo hacerlo. Los adjuntos ejecutables (y los "incrustados") los filtro con Postfix directamente (header_checks), pero los .zip no los he puesto... todavía.
O sea, que aquí debes poner por lo menos tu propia red privada, y creo que la IP de tu puerta a internet, la de la maquina que corre el servidor de correo externo.
La red privada la tengo puesta, y después tengo la IP de los servidores MX de Terra (213.4.129.130), pero no funciona. Sé que el "quid" de todo está en esta página: http://wiki.apache.org/spamassassin/WhitelistFromRcvdAndTrust Pero no sé cómo ejecutar el comando ese que pone de < tstmsg > ... voy a hacer pruebas. El objetivo es el siguiente: - Si un usuario (legal) que aparece en la lista blanca (usuario@terra.es) me manda un correo, quiero que SA le haga la prueba de USER_IN_WHITELIST y le de -100 puntos, aunque sea un mensaje muy enrevesado. - Si un usuario (no legal = spammer) que aparece en la lista blanca (spammer@terra.es) me manda un correo, quiero que SA no le haga la prueba de USER_IN_WHITELIST y no le de -100 puntos y le asigne la puntuación correspondiente (para lo cual tendrá que echar mano del trusted_networks). Este método no afecta a los usuarios que como tú (por ejemplo) quisieran enviar un correo legítimo, porque las reglas bayesianas no te afectarían puesto que tu correo es legal, no spam, y le asignaría una puntuación (más o menos) de 2 ~ 3 puntos, por lo que pasaría el filtro.
No lo veo claro.
¿Lo ves más claro ahora? :)
Ah. Mmm. ¿Seguro que se les aplican el resto de reglas? Si es así... Mmm, puede estar bien... :-???
Exacto... a eso me refiero. Sólo quiero castigar a los malosos, no a la gente de bien. O:-) Ah, y gracias por el interés. Tus explicaciones siempre vienen muy bien, son extensas y muy educativas. ¿No has pensado en la enseñanza? ;-) Saludos, -- Camaleón
El 2004-10-16 a las 22:48 +0200, Camaleón escribió:
Rechaza cualquier correo que contenga ejectuables, aunque vengan dentro de un fichero zip.
Pues si hace eso, creo me despiden...
:-P
X'-) Te entiendo perfectamente. Pero no los borra, los pone en cuarentena. Eso tiene la alternativa de simplemente hacer análisis de virus, con el amavis. la configuración mia tiene: # @bypass_virus_checks_acl = qw( . ); # uncomment to DISABLE anti-virus code @bypass_spam_checks_acl = qw( . ); # uncomment to DISABLE anti-spam code #Cer: el original solo miraba SPAM. Yo solo quiero mirar virus, spam lo hago por usuario - yo. Fíjate que la configuración es MUY ambigua y confusa, para programadores. Para _activar_ la detección de virus, hay que _comentar_ la linea, con un "#" delante. Y para activar la detección de spam, hay que comentar la otra linea. Justo al revés de lo intuitivo. Por defecto viene al revés, analiza spam pero no virus. ¿porqué? Pues porque directamente rechaza los ejecutables, así que analizar virus es inutil. O sea, si quieres que no rechace los ejecutables hay que poner el comentario en lo de virus, como yo arriba. Entonces hay que quitar lo del rechazo de ejecutables, que creo recordar era esta linea: #Cer $bypass_decode_parts = 1; # (defaults to false) Ahora bien... ¿como creo yo que debiera funcionar? 1) Detectar ejecutables. 1.1) Si contiene ejecutables (aunque sea en un zip), investigar virus. 1.1.1) Si tiene virus, rechazar. Informar unicamente al usuario local, sea el remitente, o el destinatario, pero sólo al local, nunca al remoto. 1.1.2) Si no tiene virus, poner en cuarentena. Hacer el mismo aviso que 1.1.1, al usuario local unicamente. 1.2) Si no contiene ejecutables, dejar pasar el fichero. Tal como viene, en cuanto detecta un ejecutable, lo rechaza, sea o no un virus - salvo que venga en un zip con password. ¿No recuerdas un bombardeo de virus que venía precisamente en un fichero zip con password, con la password en el texto? Se hubiera saltado esta protección... pero los antivirus lo detectaban. ¿No es tan sencillo, verdad?
Me parece un poco exagerado borrar un adjunto que contenga un .zip. ¿Qué pasará cuando los virus se puedan incrustar dentro de .pdf sencillo (sin macros ni javascript ni esas cosas)? ¿borraremos todos los .pdf?
Sólo los zips que contengan ejecutables. El que un fichero sea ejcutable lo determina la salida del comando "file". Ojo, que los pdf con formularios rellenables (pe) pueden llevar macros...
Es tentador, pero no puedo hacerlo.
Los adjuntos ejecutables (y los "incrustados") los filtro con Postfix directamente (header_checks), pero los .zip no los he puesto... todavía.
Es lo mismo que hago yo. Pero date cuenta que un unico ejecutable que se te cuele, y que esté infestado y no lo sepas (o sea un troyano no descubierto), te puede hacer una buena gamberrada. Los usuarios de correo no tienen porqué mandarse ejecutables en el correo, ni tienen porqué instalar programas en sus ordenadores, de ninguna clase, en una empresa. Claro, que yo también me he instalado programas en el trabajo :-P
O sea, que aquí debes poner por lo menos tu propia red privada, y creo que la IP de tu puerta a internet, la de la maquina que corre el servidor de correo externo.
La red privada la tengo puesta, y después tengo la IP de los servidores MX de Terra (213.4.129.130), pero no funciona.
Creo que es la IP de tu servidor de correo propio, el del postfix, el que tienes que poner.
Sé que el "quid" de todo está en esta página:
http://wiki.apache.org/spamassassin/WhitelistFromRcvdAndTrust
No lo he mirado...
Pero no sé cómo ejecutar el comando ese que pone de < tstmsg > ... voy a hacer pruebas.
El objetivo es el siguiente:
- Si un usuario (legal) que aparece en la lista blanca (usuario@terra.es) me manda un correo, quiero que SA le haga la prueba de USER_IN_WHITELIST y le de -100 puntos, aunque sea un mensaje muy enrevesado.
Ten en cuenta este comentario: # If ALL recipients of the message either white- or blacklist the sender, # spam scanning (calling the SpamAssassin) is bypassed, saving on time. Es una nota del amavis new, pero creo que el SA hace lo mismo. Es decir, si alguien está en una de las dos listas, no mira nada más.
- Si un usuario (no legal = spammer) que aparece en la lista blanca (spammer@terra.es) me manda un correo, quiero que SA no le haga la prueba de USER_IN_WHITELIST y no le de -100 puntos y le asigne la puntuación correspondiente (para lo cual tendrá que echar mano del trusted_networks).
Si un usuario está en la lista blanca, aunque sea un spammer, entra directamente, sin más. Si está en la de whitelist_from_rcvd, sólo lo considerá como "blanco" si ha llegado a través del relay del servidor correspondiente a su dominio. Si no coincide, no lo considerará blanco, y le aplicará el resto de reglas.
Este método no afecta a los usuarios que como tú (por ejemplo) quisieran enviar un correo legítimo, porque las reglas bayesianas no te afectarían puesto que tu correo es legal, no spam, y le asignaría una puntuación (más o menos) de 2 ~ 3 puntos, por lo que pasaría el filtro.
Vale, pero si me pones en la lista de "whitelist_from_rcvd", es como si no hicieras nada. Probablemente pase, pero la regla en si no hace nada conmigo. Es decir, estoy en la lista blanca, pero no coincide el received: dirá que lo he falseado.
No lo veo claro.
¿Lo ves más claro ahora?
:)
Má o meos. :-)
Ah. Mmm. ¿Seguro que se les aplican el resto de reglas? Si es así... Mmm, puede estar bien... :-???
Exacto... a eso me refiero. Sólo quiero castigar a los malosos, no a la gente de bien.
O:-)
Ya, ya...
Ah, y gracias por el interés. Tus explicaciones siempre vienen muy bien, son extensas y muy educativas. ¿No has pensado en la enseñanza?
;-)
Je, doy clases cuando me salen :-p -- Saludos Carlos Robinson
El 2004-10-16 a las 22:20 +0200, Dionisio Ruiz de Zárate escribió:
y como le digo al amavis-new, que tengo instalado y andando conel postfix en mi suse 9.1 que me rechace el spam? lo pregunto porque diariamente me llegan un monton. como puedo configurar el amavis-new tambien para eso? me puedes(podeis) ayudar? gracias
Para empezar, no reenviado los 14 kilobytes del correo al que contestas a la lista :-P Bueno, creo recordar que por defecto, ya está haciendolo (lo puedes comprobar examinando las cabeceras). Pero recuerda que el programa lo único que hace es marcar el correo como spam, es responsabilidad tuya detectar la marca y mover el spam a una carpeta distinta. El método dependerá de lo que uses. Yo lo hago con procmail, pero también puedes usar los filtros propios del kmail o mozilla. Tu estás usando "Microsoft Outlook Express 6.00", así que ni idea. Por otra parte, como dije hace un rato este método es del tipo "global", que como ya he explicado en otras ocasiones largo y tendido significa que el filtro bayesiano no se puede usar o pierde gran parte de su eficacia. Y el filtro bayesiano es imprescindible para eliminar un porcentaje muy respetable del correo basura. -- Saludos Carlos Robinson
Carlos E. R. wrote:
Si un usuario está en la lista blanca, aunque sea un spammer, entra directamente, sin más.
Claro, por eso ese parámetro no me sirve.
Si está en la de whitelist_from_rcvd, sólo lo considerá como "blanco" si ha llegado a través del relay del servidor correspondiente a su dominio. Si no coincide, no lo considerará blanco, y le aplicará el resto de reglas.
Ese es el objetivo. Pero mis correos tienen 3 cabeceras "Received from:": La de fetchmail (local) --> trusted La del servidor remoto POP3 de donde bajo el correo --> trusted La del usuario que envía el correo --> no trusted Si tengo: whitelist_from_rcvd *@terra.es terra.es trusted_networks 192.168/16 << rango de red interna trusted_networks 213.4.129.130 << ip del mx de terra Si el correo dice que viene de "From: usuario@terra.es"... ¿Cómo distingue SA qué cabecera from es la que tiene que hacer coincidir con la IP de "trusted_networks"? Por otra parte, la IP del equipo con Postfix está dentro de la red interna, es local.
Vale, pero si me pones en la lista de "whitelist_from_rcvd", es como si no hicieras nada. Probablemente pase, pero la regla en si no hace nada conmigo. Es decir, estoy en la lista blanca, pero no coincide el received: dirá que lo he falseado.
Si lo has falseado pueden pasar dos cosas: 1) Que el contenido de tu correo no sea spam, y aunque a tu correo le afecten las reglas bayesianas no será considerado como spam. También está la puntuación de AWL (autowhitelist) si eres un habitual, lo que puede hacer bajar la puntuación. El correo pasa el filtro. 2) Que el contenido de tu correo sea spam y se le asigne una puntuación alta (BAY_99), por lo que será rechazado. Saludos, -- Camaleón
El 2004-10-17 a las 12:19 +0200, Camaleón escribió:
Carlos E. R. wrote:
Si un usuario está en la lista blanca, aunque sea un spammer, entra directamente, sin más.
Claro, por eso ese parámetro no me sirve.
Si está en la de whitelist_from_rcvd, sólo lo considerá como "blanco" si ha llegado a través del relay del servidor correspondiente a su dominio. Si no coincide, no lo considerará blanco, y le aplicará el resto de reglas.
Ese es el objetivo. Pero mis correos tienen 3 cabeceras "Received from:":
La de fetchmail (local) --> trusted La del servidor remoto POP3 de donde bajo el correo --> trusted La del usuario que envía el correo --> no trusted
Si tengo:
whitelist_from_rcvd *@terra.es terra.es
trusted_networks 192.168/16 << rango de red interna trusted_networks 213.4.129.130 << ip del mx de terra
Si el correo dice que viene de "From: usuario@terra.es"...
¿Cómo distingue SA qué cabecera from es la que tiene que hacer coincidir con la IP de "trusted_networks"?
whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS. "el segundo parámetro es un string que debe encajar con la resolución inversa del nombre del relay. Esto aplica al servidor en el que entra el correo - que se supone que es el tuyo, no el de tu isp que provee internet, no el del pop3. No valdrá en ese caso. Me explico. Tomo como ejemplo un correo rebote de un basura (backscatter) para sacarle unas cabeceras. From: MAILER-DAEMON_at_eyou.com Received: from pop.tiscali.es [212.166.64.66] by localhost with POP3 (fetchmail-5.9.0 polling pop.tiscali.es account ****) for cer@localhost (single-drop); Wed, 06 Oct 2004 01:24:25 +0200 (CEST) Received: from eyou.com (61.136.62.74) by netmail.tiscali.es (6.7.021.1) id 4124C82500507F01 for ****@tiscali.es; Wed, 6 Oct 2004 01:05:28 +0200 Inciso. En "netmail.tiscali.es (6.7.021.1)" ahí arriba el número no es la ip, sino la versión del smtp o del sistema; por ejemplo, aquí se ve mejor: Received: from localhost (localhost [127.0.0.1]) by telperion.valinor (Postfix on SuSE Linux) with ESMTP id 62B984DE Además, la he buscado y es del DoD. ;-) La primera cabecera es una que inserta el fetchmail cuando se usa con la clave "tracepolls" (no el postfix). La cabecera que nos interesa es la segunda, donde se ve el "eyou.com". El "From" también era de "eyou.com". Ya tenemos un encaje, valdría, en principio. Y... ¿porqué esa linea? Pues porque tienes que haber citado la ip de tiscali, 212.166.64.74 como "trusted". ¿Porque esa IP? Por esto: cer@nimrodel:~> host netmail.tiscali.es netmail.tiscali.es has address 212.166.64.74 cer@nimrodel:~> host 212.166.64.74 74.64.166.212.in-addr.arpa domain name pointer netmail.tiscalinet.es. 74.64.166.212.in-addr.arpa domain name pointer netmail.tiscali.es. Vale. Pero resulta que el SA, en el received no mira el string "eyou.com" (que es el nombre que el relay dice de si mismo, y puede ser falso), sino la IP "61.136.62.74", que es en cambio conseguida por el servidor smtp que recibe, en este caso, de tiscali, y del cual nos fiamos. A esa IP se le calcula el rDNS, o sea, el resultado de la orden "host" sobre esa IP. Eso te dará un nombre (que puede ser o no "eyou.com"), que digamos será "XXX". En este caso tendríamos un problema grave, porque esa IP de nuestro amigo del "from" no tiene resolución inversa: cer@nimrodel:~> host 61.136.62.74 Host 74.62.136.61.in-addr.arpa not found: 3(NXDOMAIN) Y la directa no da esa IP, aunque en realidad ambas le pertenecen: cer@nimrodel:~> host eyou.com eyou.com has address 61.136.62.73 La configuración del SA sería entonces, si XXXX fuera la resolución inversa de marras: whitelist_from_rcvd eyou.com XXXX trusted_networks 6.7.021.1 Problema: ¿Es realmente confiable esa red? ¿Tiene otros efectos? ¿Varía la IP alguna vez? Ten en cuenta que no es "nuestra"... Mas problemas: Que el remitente no tenga rDNS, o mejor dicho, su proveedor - que como acabas de ver en este caso, ocurre.
Vale, pero si me pones en la lista de "whitelist_from_rcvd", es como si no hicieras nada. Probablemente pase, pero la regla en si no hace nada conmigo. Es decir, estoy en la lista blanca, pero no coincide el received: dirá que lo he falseado.
Si lo has falseado pueden pasar dos cosas:
1) Que el contenido de tu correo no sea spam, y aunque a tu correo le afecten las reglas bayesianas no será considerado como spam. También está la puntuación de AWL (autowhitelist) si eres un habitual, lo que puede hacer bajar la puntuación. El correo pasa el filtro.
2) Que el contenido de tu correo sea spam y se le asigne una puntuación alta (BAY_99), por lo que será rechazado.
Pero la regla "whitelist_from_rcvd" para los mios no actúa, es lo que trato de decirte. Tendrías que poner "whitelist_from" a secas, en cuyo caso te arriesgas a que alguno que se haga pasar por mi te entre. o confiar en el resto de reglas. O dicho de otra forma, ponerme en "whitelist_from_rcvd" es como no hacer nada, por la sencilla razón que no uso el relay de tiscali (ni de otro). -- Saludos Carlos Robinson
Carlos E. R. wrote: Hola Carlos,
Problema: ¿Es realmente confiable esa red? ¿Tiene otros efectos? ¿Varía la IP alguna vez?
Ten en cuenta que no es "nuestra"...
En la lista blanca tengo muy pocos dominios, sólo los justos, y sólo para evitar posibles errores del SA, seguramente las listas blancas dejaré de utilizaras más adelante.
Mas problemas: Que el remitente no tenga rDNS, o mejor dicho, su proveedor - que como acabas de ver en este caso, ocurre.
Bueno, pues en ese caso (que no tenga rDNS o que no corresponda el dominio con la IP), tendrá que obviar la lista blanca y clasificar el correo con las reglas habituales.
Pero la regla "whitelist_from_rcvd" para los mios no actúa, es lo que trato de decirte. Tendrías que poner "whitelist_from" a secas, en cuyo caso te arriesgas a que alguno que se haga pasar por mi te entre. o confiar en el resto de reglas.
No, no actúa, pero eso no me preocupa. Si es spam, irá al hoyo, si no lo es, pasará normalmente.
O dicho de otra forma, ponerme en "whitelist_from_rcvd" es como no hacer nada, por la sencilla razón que no uso el relay de tiscali (ni de otro).
En el whitelist_from_rcvd sólo están unos pocos dominios remotos que gestiono y algunos dominios genéricos (terra, wanadoo), poco más. Las reglas bayesianas para el resto de correos funcionan de Perl(as). ;-) Saludos, P.S. He actualizado a la versión 3.0 del SA, y al final, después de hacer algunas pruebas, he conseguido que los remitentes falsos de terra.es no sean marcados con -100, pero los genuinos (los que vienen del servidor de Terra) sí lo son y reciben puntuación de -100. Esta versión parece más depurada. -- Camaleón
El 2004-10-18 a las 09:17 +0200, Camaleón escribió:
P.S. He actualizado a la versión 3.0 del SA, y al final, después de hacer algunas pruebas, he conseguido que los remitentes falsos de terra.es no sean marcados con -100, pero los genuinos (los que vienen del servidor de Terra) sí lo son y reciben puntuación de -100. Esta versión parece más depurada.
No sabía que ya estaba la 3 fuera. Me pregunto cual tendrá la suse 9.2 :-? -- Saludos Carlos Robinson
participants (3)
-
Camaleón
-
Carlos E. R.
-
Dionisio Ruiz de Zárate