[LACNIC/Seguridad] [Seguridad] Nuevo código de conducta anti-spam en Australia

[Reinaldo Mayol Arnao]

Yo estoy de acuerdo con Nicolás pero reconozco que no tenemos suficiente
experiencia como ISP. Al final alguien tiene tiene una estadística
confiable de cuantas son las excepciones comparadas con el universo de
usuarios ? Ese es el único valor que verdaderamente nos daría un
elemento para decir si es "difícil y costoso". Mi experiencia dice que
no es ni lo uno ni lo otro.

S'
Reinaldo


Nicolás Ruiz wrote:

> Webmaster wrote:
>
> >El Martes, 25 de Abril de 2006 09:39, Jorge F. Messano escribió:
>
> >>>Yo no tendria problema si mi ISP (en mi casa) establece al momento de
> >>>firmar el contrato una clausula como "por omisión cerramos el puerto 25
> >>>para evitar spam saliente, si quiere permitirlo, metase en esta URL".
> >>
> >>De acuerdo tambien. Asi deberia ser.
>
> >Jorge:
> >No entiendo.
> >Puede que yo esté interpretando muy mal lo que dice Nicolás, pero si
> el ISP
> >permite que uno elija si puede o no bypassear el bloqueo de puerto 25
> >entonces todo aquel que quiere hacer spam es libre de hacerlo.
>
>
> La mayoria de los agentes que envian spam desde los clientes ISP son
> máquinas comprometidas que estan corriendo un servicio de envio de spam
> sin el conocimiento del dueño/administrador del computador (tipo 1). Hay
> unos pocos clientes ISP que corren mail exploders a propósito (tipo 2).
>
> Al establecer un mecanismo manual a través del cual el dueño del
> computador pueda permitir el acceso de su equipo al puerto 25, creas una
> situación en la cual (a) la mayoria de los clientes no lo van a
> habilitar porque no lo necesitan (b) no puede ser hecho automáticamente
> por el malware que se utiliza para enviar spam, bloqueando a los tipo 1
> (c) le da a los ISP una lista (relativamente) corta y conveniente de
> sistemas a los cuales se monitorea la actividad del puerto 25 (los
> mismos que permites pasar en los ACL son monitoreados en el NIDS). En
> caso de actividad inusual a través del puerto 25, se pueden tomar
> medidas de corrección contra los tipo2.
>
> Si bien este mecanismo es más complejo que simplemente bloquear el
> puerto 25, son todavia bastante sencillas y rápidas de implementar.
>
> Todo esto funciona relativamente bien siempre y cuando la mayoria de los
> clientes del ISP no habiliten el acceso al puerto 25. Para esto el ISP
> puede presentar la información de una manera que tienda al usuario a
> elegir la opción de NO habilitarlo, posiblemente (adicionalmente)
> presentandolo en un lenguaje altamente técnico (para tratar de que los
> usuarios que permitan SMTP sean relativamente educados, tecnologicamente
> hablando).
>
> >Todavía no le encuentro la vuelta rápida, sencilla y barata de
> >permitir excepciones y al mismo tiempo poder monitorear que dicha
> >excepción no sea una puerta abierta a la salida de spam sin que eso
> >implique los costos operativos de filtrado a nivel de identifiación de
> >usuario.
>
>
> creo que es imposible que no incurra en costos operativos. No tengo
> claro si los ISP mantienen un mapeo constante de userID a dirección IP,
> pero me imagino que sí. Y de ser así, es trivial mantener un mapeo de
> las preferencias-userID-dirección IP. Fijate que ni siquiera necesitas
> que los clientes si-25 tengan direcciones IP fijas. Basta con tener 2
> pools de direcciones, uno para los no-25 (más grande) y otro para los
> si-25 (más pequeño). Ambos pools pueden provenir de la misma subred, y
> cuando el cliente hace una solicitud DHCP, se le entrega una dirección
> que proviene del pool de su preferencia.
>
> --
> Juan Nicolás Ruiz        | Corporación Parque Tecnológico de Mérida
> Investigación/Desarrollo | Centro de Tecnologias de Información
> nicolas en ula.ve           | Edif B (Fac. Ingeniería) Nivel Plaza, Ala Sur
> +58-(0)274-240-3889      | La Hechicera, Mérida - Edo. Mérida. Venezuela


-------------------------

_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
http://lacnic.net/mailman/listinfo/seguridad

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: mayol.vcf
Type: text/x-vcard
Size: 632 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060425/feac2f85/attachment.vcf>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4501 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060425/feac2f85/attachment.bin>