RE: [Seguridad] Nuevo código de conducta anti-spam en Australia

Lun Abr 3 19:21:07 BRT 2006

Muy buenos comentarios acerca de este servicio que es explotado por acciones
de la ingenieria  social y que es el canal de infeccion por el servicio, y
tal servicio es el vector de explotacion de de vulnerabilidades, en el
ambiente interno de una organizacion, entre ellos el tema en debate.

Coincido contigo sobre el mal diseño del Protocolo, pues tiene tantos años,
pero aun no sale una alternativa, y tampoco llegariamos a acabar con los
efectos sobre el servicio que sostiene el protocolo.

Los puntos descritos en un post  anterior son clave en todo implementación
del servicio de correo, pero a veces poner todo en el mismo servidor,
conlleva a consumir recursos, ya que cada mensaje  tiene que ser evaluado
por cada  subsitema o agente, hablando en cientos de usuarios.

	- SMTP-AUTH+TSL
	- antivirus (clamav,)
	- antispam (spamassassin)
	- RealTime Scanning WarLord
	- Rate control,  (Controla slammers, scam, mail bombing)
	- Greylist (anti slammer, anti spammer, etc.) (*)
	- SMTP flow control, SpamThrottle, (Evitar ataques DoS, DDos)
	- SPF, Domain Keys (Control de fraude, phishing, scam) 
	- Check  domains, CHK_USER (Disponible en Qmail)
	- Politicas para archivos adjuntos, usos, quotas,etc.

Yo utilizo Qmail, defiendo a este MTA, por que es modular, y super
configurable, y puede utilizarse de forma distribuida, en algunos casos,
gracias a su diseño. Y por mas de muchos  años no se encuentra alguna
vulnerabilidad critica en el nucleo, y hay muchos programadores que ha
integrado otras funcionalidades, muy funcionales.

Sobre el GreyList, he tenido un problema con un cliente, ya que representa
una desventaja en el nivel de usuario, y genera muchas confusiones en los
usuarios, y Mas aun si la empresa negocia  bajo este servicio. Me he ganado
muchos llamadas de atencion por implementar esto, por las respuestas 450.

Coincido con algunos sobre los comentarios acerca de la regulacion
australiana, y la no responsabilidad directa  a los ISP's. Creo que deberia
haber un organismo regulatorio que aga auditing a los ISP y SP's, en sus
infraestructuras, ya qyue algunas ofrecen servicios propios que inciden en
la responsabilidad directa.

Sobre  SPF (http://www.openspf.org/) en esta pagina nos ayuda  a como
generar nuestro SPF para nuestros dominios y designar  nuestros Hosts.
Domains Keys, que funciona muy bien, no es  muy facil implementar en
nuestros mail servers, ya que tenemos que obtener la libreria  para
domainsKeys, y parchar nuestro core del MTA, y generar nuestros Keys.

Pero aun asi, con todo esto me ingresa el Spam y hay muchas formas, que los
spammers utilizan, ymas aun con los botnets y los codigo maliciosos este
problema basado en la ingenieria  social, nos con lleva incluso a  usar
expresiones  regulares, listar en los RBL's, hasta blockear segmentos  de
redes  e IP's, de los ISP's. Y es alli el problema, tampoco la
responsabilidad no es directamente de los ISP's, tambien del usuario, que no
es concientizado sobre la seguridad.

Bueno espero mis comentarios quizas un poco subjetivos, no incomoden a la
lista, pero creo que si nos proponemos metas en la lista de LACNIC, para
establecer reglas y concientizar a los usuarios, y hacer un CERT/CIRST,
sobre los temas de la seguridad, incidiendo en el tema del SPAM, ya que
meses atras un pais sudamericano, fue distinguido en el 2do Lugar de
distribucion e infeccion de un codigo malicioso de tipo worm, denominada
CME-24, BlacKMal, kamasutra, Nyxem, VB.Nei,etc, todos ellos alias del
malware. Que ademas ocasiono otras infecciones a nivel mundial, desde esa
region.

Saludos  a todos.

-----------------------------------------------------------
 Anatoly Alexei Pedemonte Ku 
 RAGE SYSTEMS S.A.C.
 http://www.ragesys.net
 Av. Juan Pascal Pringles 1225 (ex- La Fontana)
 Teléfono: 511.7962262 
 Móvil: 511.97167435 
-----------------------------------------------------------
Este correo y su contenido son confidenciales y exclusivos para su
destinatario. Si usted recibe este mensaje por error o no es el destinatario
del mismo, por favor sírvase eliminarlo y notificarle a su originador. Así
mismo, todas las ideas y reflexiones expresadas en esta comunicación
corresponden al originador del correo y NO representa la posición oficial de
su empleador.
----------------------------------------------------------------------------
----------------------------------------------------------
This email is intended only for the addressee(s) and contains information
which may be confidential, legally privileged. If you are not intended
recipient please do not save, forward, disclose or copy the content of this
email. Please delete it completely from your system and notify
originator.Finally, all ideas expressed in this communication are personal
comments and NOT represent official position of his employer.
----------------------------------------------------------------------------
----------------------------------------------------------

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.1 (MingW32)

mQGiBEP74n4RBACWbWMwp0mlBGkv+VsER3gvmt2Y7UmiuDRapL6W2fJkRAiZSNyG
GmQlnnC82G0xyQ2raKRaHyXpL5bx6mP6zoM9ws3xQgLSXN9xepHBBMKxktrsOkmt
wU9fO0j969iE48g2U+T0M3VK9M63d8jVplKJPYSX3d8MSPmCNdznf+6RawCgzEqO
4rtw5qpjsHgpYhfcU67LR1UD/09sgy4NppYkDSIYJhcAJGKOBYT5ap9/u6BbRme2
XV6fzni7/ZyeA+rLsPL2VR9KLDirGCZR0tbUA07tcY8eWqh1yugGXxFA66XH7/Hw
ULi8yEZCHRtx9VFWuUK72SB5yFD8tWS7v2kNElMQ7PtXitSSvkVKgR6HEVA0m77Y
HmbgA/0WE8QrDKdQM8QxqzsIm+o2IaJ32WHrAZXCyueK29LGDpiQ/+n6xQ+naNo6
eXxvRLgZgwkf8CABuzPDBNc0vVz7Bgh2Bv2mUevYiVVT7yqqRDtHNM06CztbRz4a
+oHN0UyyW9pLGw9ImvKHIWlmkc2pCvRzecHMqHT/aUasohco0bQ/QW5hdG9seSBB
LiBQZWRlbW9udGUgS3UgKEdOVSBQR1AgQW5hdG9seSkgPGFuYXRvbHlAcmFnZXN5
cy5uZXQ+iF8EExECACAFAkP74n4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAK
CRDl44NRz+awqjn6AJikjCHB8OG2d1hyMzZBpDfJwG9DAJ9pG2mkTsUso3HOAkij
KlnND+5OHbkCDQRD++KXEAgAvR6UmL6ZjGKLd1yUT/C5aR0eKlHEi0yO73fMBxt+
Lwow28qzBKHrMVGnMRQOl3KgDqVH2OU2fqcLaybqHsE02cwS2IhtzsB/Xi6WyS4q
GYaAGnEbJ7FRIDAAHoc07EWXkzVmNBw/P1Xnj21dAE1VuH28lBwKeuBy19C44wbi
/BzvntzmMTa1PqloubiGauXVbkRmBc6Dn9qHeqoipQvbVyQTimvAH9RaCzehD8WE
W8INRZkPM7R87FGXW2h3+29qVMBxsUU85oLmiUMlR5kqJKcU8h/vhrPq7qa0hudh
wMllE/SOIqa1sVxbIOk5xEV36kbFqXlfb3JXSEngpbre7wADBQf/ZL6o/IpOXOHp
St4aO8NgPrWD+NZLNug9sccqYnlWVGMBH3CjiSUFFNC+hoXjecW4YMh6NUBXbkKX
etDSgrxCc07DSSQ9f5hYB5tP5Sov+j4PJp44iV0uYS7kfugAwWDIkSJJVMv0UIb+
Elf0Ss0VxjmqIv92wDE+XVCEB342DhuhUt8HUmVYVihC0N7pJCEqPGfWgxBZA5nm
loLIAfl8qb1D/FCPvb9Yfj9qn5hTvtZYjgbh1a8awOiodwaPrUP4bTdY/SRKFKBP
0txyJn5h345GZ2zpfGYleEYnVPRZm57/WM5SsPhZ1OoO5imMl7qVsosSSVFGcL17
ZNVqqJOH0IhJBBgRAgAJBQJD++KXAhsMAAoJEOXjg1HP5rCqFOoAnRO+jqkCfn/H
UquknQh/MK9K3+H9AKCciBqvAWaVQ6O5Ek2EEaMlRuGdJw==
=Mnmw
-----END PGP PUBLIC KEY BLOCK-----

-----Mensaje original-----
De: seguridad-bounces en lacnic.net [mailto:seguridad-bounces en lacnic.net] En
nombre de Marcelo Maraboli
Enviado el: Domingo, 02 de Abril de 2006 08:23 p.m.
Para: seguridad en lacnic.net
Asunto: Re: [Seguridad] Nuevo código de conducta anti-spam en Australia

Estimados.

He leído detenidamente todos los comentarios enviados hasta ahora del tema
SPAM, Phishing, virus ,etc y me alegra mucho que existe gente TI competente
en varios países y decidí aportar mi grano de arena...

Mi nombre es Marcelo Maraboli y me desempeño como Jefe Area de Redes y
Comunicaciones (Servicios Internet) de una importante universidad en Chile
(UTFSM). Llevo 10 años en el cargo, y trabajo con Internet casi desde los
comienzos de la Internet en Chile (1990).

Hace más de 3 años vengo estudiando el tema de Fallas y Mecanismos de
Defensa del sistema de Email de Internet (no sólo SPAM, virus y phishing) y
me he dado cuenta que existen 2 deficiencias
generalizadas:

- el gran desconocimiento de cómo realmente funciona SMTP, cuáles son sus
fallas de diseño y cuáles son sus fallas de interacción, en total 14. Me
refiero al desconocimiento de los administradores de los servicios de Email
de Empresas e ISP.

En muchas ocasiones he tenido que "instruir" a otros admin cómo configurar
sus servicios de manera correcta. Me perdonarán la osadía de decir esto,
pero es verdad.

- La gran cantidad de mecanismos de defensa que existen, de los cuales
algunos en conjunto puede solucionar efectivamente una de las 14 fallas, y
otros mecanismos sólo proveen de mitigación del problema y no una soluciòn
final.

Habiendo dicho eso, he implementado las siguientes medidas tendientes a
solucionar las 14 fallas. Mi propuesta es que si todos hacemos esto, el tema
EMAIL pasa a ser un tema agradable y no perderíamos tanto tiempo...

- todos los computadores (PC) tienen denegado salida a Internet hacia el
puerto 25 SMTP, a excepción de servidores SMTP autorizados.
Parece simple, pero he visto varias empresas que no lo tienen habilitado.
Esto erradica la emisión de emails provocados por virus, erradica el SPAM
generado internamente, etc..

- para enviar email, la única manera es vía SMTP_AUTH + TLS. Si algún
usuario se infecta con virus/emailer, no podrá enviar porque dichos emisores
son SMTP simples y no entienden TLS. En cada email (como este) verán la
autenticación realizada y por ende el receptor puede validar al emisor.
Muchas empresas instalan SMTP_AUTH y no agregan el header correspondiente,
por lo que el receptor igual no tiene forma de verificar al emisor.

- Cada email entrante a la Universidad se le aplicada una serie de pruebas:
	- antivirus (clamav)
	- antispam (spamassassin)
	- SPF	(anti fraude, phishing)
	- Domain Keys (igual)
	- greylist (anti slammer, anti spammer)
	- rate control (anti slammer, anti mail bombing)
	- SMTP flow control, cada flujo SMTP con un máximos de bps
		(anti DoS, DDos)
	- domain check : ningún email proveniente desde el exterior
	   puede venir con dirección de la Universidad, dado que
	   claramente es falsificado.
	- reglas clásicas de sendmail (check_domain, check_headers, etc.)

A modo de ilustración, me permito una leve corrección a mi
colega:  Antonio Galicia antoniogc en agc.com.mx dice sobre el "postgrey"...

 >Si consideramos que un muy alto porcentaje del correo no deseado (spam,
>virus, phishing, etc) provienen de máquinas que no tienen un verdadero
>MTA una manera límpia y rápida de evitar ese tráfico son las greylist
>como la que implementa postgrey[1]. Lo que hace es crear un hash a  >partir
de algunos datos del correo como es la IP, el remitente y el  >destinatario.
Si es la primera vez que aparace ese hash simplemente lo  >registra y le
regresa un error 450 al cliente. Si hay un MTA "de verdad"
 >este reintetará pasado un tiempo, postgrey espera la nueva conexión
>pasado un lapso de tiempo (300 segundos por default) y lo deja pasar.
 >¿Resultado? Que los correos "reales" van a tener un retraso de 5 minutos
>la primera vez, el siguente si es en menos de un mes pasará de inmediato
>en tanto que los correos no deseados normalmente no lo intentarán
>nuevamente y simplemente nunca llegarán.

Esto anterior es "casi" verdad. Los emails de un MTA "de verdad"
serán re-transmitidos después de un tiempo que ESE MTA esté programado para
hacerlo, algunos 10m, otros 15m (default de sendmail) y no cuando el
Greylisting lo indique.

Esto me ha causado problemas con varias instituciones chilenas que no tienen
re-transmisión de emails rechazados temporalmente (hablo de CODELCO,
universidades, Ministerios, etc.) donde dichos emails quedan eternamente en
el QUEUE...

¿cómo vamos a implementar greylisting a nivel latino-america si los
email-admins ni siquiera vacían sus QUEUE ? :(

He notado que casi ninguna institucion en Chile ha publicado su registro SPF
o Domain Keys, ¿Qué pasaría si nos ponemos de acuerdo para hacerlo en
Latino-America ? podríamos detectar los fraudes latinos ?

Considero que las únicas medidas decentes de aplicar y que tienen efecto
real son:

- greylisting http://hcpnet.free.fr/milter-greylist/
- Sender Policy Framework - SPF http://spf.pobox.com/
- Domain Keys http://antispam.yahoo.com/domainkeys
- CAMRAM http://www.camram.org/
  (emisor debe realizar un cálculo computacional definido por el receptor
para que éste le acepte su email. Con esto, los spammers se van a 0, porque
el "costo" computacional es muy alto).... inteligente la solución!

Para los realmente interesados en SPAM, vean la última en:
- MIT SPAM Conference 2006 http://www.spamconference.org/

Sobre Australia....uf! 2 cosas antes del tema SPAM..

- en los años 199x, Australia sacó una ley que indica que todo email sigue
siendo propietario de quién lo envía. Por ende, el que recibe un email NO
TIENE DERECHO A HACER UN FORWARD sin el consentimiento del emisor...!

- Por ley, todo sitio web que desee hacer un link a otro sitio web, debe
solicitar por escrito (o por email) una autorización del otro. O sea, no es
llegar un poner un link....

Considero a Australia muy avanzado en el tema legislativo, pero no
necesariamente en la dirección correcta. No puedo hacer responsable a los
ISP del tráfico que circula por sus cables, a excepción que el "criminal"
sea un cliente directo.

Se imaginan que si llamo por AT&T a Osama bin Laden, entonces es posible
demandar a AT&T por terrorismo ?? caso distinto es que AT&T tenga contrato
de cliente con Osama...

Mi estudio sobre SMTP (donde 1 de los temas es SPAM) estará publicado pronto
y por ende libre para hacerles hagar llegar una copia, de los cuales me
gustaría recibir sus  expertas opiniones (buenas y malas)...

disculpen lo extenso...

atentamente,

Webmaster Comtron wrote:
> Ricardo:
> 
> Quien establece este código es la ACMA, Australian Communications and 
> Media Authority, que es una entidad gubernamental, donde se puede ver 
> este link:
> http://www.acma.gov.au/ACMAINTER.65640:STANDARD:304849823:pc=PC_100488
> con la información de prensa referida al mismo.
> 
> El código puede leerse en este pdf: 
> http://www.acma.gov.au/acmainterwr/telcomm/industry_codes/codes/iia%20
> spam%20code%20dec%202005.pdf y por lo que dice ahi, dicho código ha 
> sido escrito entre muchos de los actores tecnológicos para cumplir con 
> lo establecido con la Spam Act 2003 
> http://www.comlaw.gov.au/ComLaw/Legislation/ActCompilation1.nsf/0/DED1
> 53276FD7C6F9CA2570260013908A/$file/SpamAct03WD02.pdf
> y no correr el riesgo de caer en sus penalidades.
> 
> Lamentablemente, no he podido leer estos textos en forma completa, 
> dadas las limitaciones de tiempo que uno tiene, y muchas veces las 
> informaciones periodísticas contienen algunos vicios de resúmen que 
> dejan mas dudas que certezas.
> Calculo que estos documentos van a responder algunas de tus consultas.
> Y otras, como las "limitaciones razonables" que a propósito puse en 
> mayúsculas, las podremos discutir en esta lista, con casos como 
> CUANTOS mails diarios son razonables para un usuario, si habrá que 
> distinguir entre usuarios residenciales y comerciales, si se deberían 
> filtrar o no los datos dirigidos al puerto 25 de una red externa de un 
> ISP, y una larga lista de etcs.
> 
> Saludos
> 
> Javier
> 
> 
> 
>  
> Ricardo Presta escribió:
> 
>> Javier : Gracias por la info, sabés quién establece el código y las
multas?
>> O que sucede con los isp o sistemas de correos globales si no lo
cumplen.?
>>
>> La pregunta es porque no me queda claro si es una ley, un decreto una 
>> resolución o un código gral. entre isp´s agrupados en algun foro o 
>> cámara y como es ese modelo de multas quienes están alcanzados, quien 
>> las paga con que fuerza se puede pretender cobrarlas a que se lo 
>> conisera spam o que son limitaciones razonables etc.
>>
>>
>> Ricardo
>>
>>
>>
>>
>>  
>>
>>  
>>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> http://lacnic.net/mailman/listinfo/seguridad
> 

--
Marcelo Maraboli Rosselott
Jefe Area de Redes y Comunicaciones (Network & UNIX Systems Engineer)
Ingeniero Civil Electronico                     (Electronic Engineer)

Direccion Central de Servicios Computacionales (DCSC)
Universidad Tecnica Federico Santa Maria         phone: +56 32 654237
Chile.                                    http://elqui.dcsc.utfsm.cl/
_______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
http://lacnic.net/mailman/listinfo/seguridad
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3692 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20060403/c1c0663f/attachment.bin>