Mailinglist Archive: opensuse-es (2177 mails)

< Previous Next >
Re: [suse-linux-s] Depurando al "asesino"
  • From: "Carlos E. R." <robin1.listas@xxxxxxxxxx>
  • Date: Sat, 16 Oct 2004 20:50:22 +0200 (CEST)
  • Message-id: <Pine.LNX.4.58.0410161504180.7265@xxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxx" 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


< Previous Next >